Using bookmarks in Mercurial itself

[Idan Kamara]

On Mon, Jun 20, 2011 at 11:33 AM, Martin Geisler <mg at aragost.com> wrote:
> Idan Kamara <idankk86 at gmail.com> writes:
>
>> On Sun, Jun 19, 2011 at 8:14 PM, Martin Geisler <mg at lazybytes.net> wrote:
>>
>>> With today's Mercurial, there is a non-significant cost associated
>>> with maintaining a clean history: you have to use MQ or similar and
>>> that destroys *collaboration* -- unless you are okay with dealing
>>> with patches to patches.
>>
>> I don't think it does. Like others have said, there's nothing
>> preventing you from publishing a public repo, where all interested
>> individuals can collaborate.
>
> I claim that you cannot collaborate (efficiently) on a versioned patch
> repository. I've never seen it happen. It is hard enough to work
> together on files using patches -- working together on second-order
> patches makes things much harder.

I haven't suggested otherwise. I'm just saying that if you want to
collaborate, do it on a separate repo, without mq.

>
> Personally, I've worked on a set of versioned MQ patches with Henrik and
> I think it only worked because we took turns editing the patches.
>
>>> We have bugfixes in the Mercurial history today [...]
>>
>> Of course no code is perfect. But if you have the option of not having
>> that extra commit for the bug fix, which is what we strive for by
>> sending patches to the list for others to review, would you not prefer
>> that?
>
> Not necessarily. That way of thinking can be a waste of time -- trying
> to make the history look nice instead of letting it be informative.
>

I don't know, I guess it depends. When working on a series in an
organized manner (patches split up nicely etc), I find it natural,
not a waste of time.

>>> One tool that we don't really use today is the merge commit. We
>>> almost only merge because we have to: main and crew diverged and
>>> needs to be merged. The other merge commits are accidental and carry
>>> no interesting commit message or meaning. The only significant merges
>>> are when default is merged into stable in preparation for a release.
>>
>> That's because there's no need to.
>
> I think it is because we've told everybody: "send us a patch and we'll
> rebase it for you when we apply it -- it's now your own problem to get
> rid of your old changeset". It is *strange* to me that the development
> of Mercurial itself builds so heavily on discouraged practices such as
> strip and rebase.
>

I agree here. I think it might be nicer for contributors if their
patches got applied with --exact and merged into the main line,
rather than rebased.

My usual workflow is something like this:

$ hg qnew patch1
...
$ hg qnew patch2
...
$ hg email -o
<patches get queued upstream>
$ hg pull
$ hg qpop -a
$ hg qrm patch1 patch2 ...
$ hg upd

Sometimes I qfinish+strip.

Where it could have been:

$ hg pull <brings merge commit>
$ hg qfinish -a
$ hg upd

For a couple of patches it's no big deal. But if I have a lot
of patches waiting to be queued/still in progress, it can
be a mess sometimes.

OTOH if you look at git's graph, it's not so easy on the eyes:

http://paste.pocoo.org/show/416271/
http://i.imgur.com/CoXmZ.png

It does however, allow you to see all csets on a certain
feature branch, next to each other in a nice way.

>> Imagine every contributor would merge upstream to his series every
>> time he pulled instead of rebasing.
>>
>> It would clutter the history to the point it becomes unreadable, those
>> merges aren't interesting to anyone. The merges you and whoever's
>> working with you on your feature are no different imo.
>
> It would only be branches where people collaborate (published branches)
> that would use merge, private branches can still be rebased.
>
> But yes, the history will be more complicated. We're building a tool
> that can handle this, right? :-)
>
>> If you look at the kernel, where it's split to subsystems and
>> maintainers pull other peoples work, then merging makes sense. Because
>> people pull from the maintainers, and rebasing would make those
>> peoples redo all their work.
>
> I know, I know... we have the same with the hg-i18n repository. I'm just
> wondering if we're silly for not using that model more.
>
> I cannot be the only one who have looked at our development process and
> thought "hey, wait a moment... they use *patches*? and they implicitly
> *rebase* them all the time? Why don't they use their own tool more?"
>
> I know the answer is that email is incredibly flexible, but I also know
> that we've talked about the problem of losing patches at the last two
> sprints. Bitbucket just launched a nice 'pull request' feature that
> would let us get some overview back: people make a pull request on
> Bitbucket and we can reject/accept them there.

Yeah that sounds nice, although I think the main review process
should stay in the mailing list.

It might also help crew members to pull changes that way
rather than doing it from the mailbox, depends on their workflow.
(but since Matt is queuing like 95% of the patches, he might
not want to change his workflow)

>
> --
> Martin Geisler
>
> aragost Trifork
> Professional Mercurial support
> http://mercurial.aragost.com/kick-start/
>