Using bookmarks in Mercurial itself

[Martin Geisler]

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.

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.

>> 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.

> 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.

-- 
Martin Geisler

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