Using bookmarks in Mercurial itself

Idan Kamara idankk86 at gmail.com
Sun Jun 19 13:55:47 CDT 2011


On Sun, Jun 19, 2011 at 8:14 PM, Martin Geisler <mg at lazybytes.net> wrote:
>
> Pierre-Yves David <pierre-yves.david at ens-lyon.org> writes:
>
> > On Fri, Jun 17, 2011 at 11:34:45PM +0200, Arne Babenhauserheide wrote:
> >> On Friday 17 June 2011 14:17:22 Pierre-Yves David wrote:
> >
> >> I still think that liquid history is a nice idea, but it is a
> >> different usecase: You try to get the history nice by hiding how you
> >> got there instead of making it easier to read but keeping the way you
> >> took.
> >>
> >> From a copyright perspective going the second route might even be
> >> imperative: Only with that can you track who exactly added which
> >> change.
> >
> > Nothing should prevent you to keep intermediate version of rewritten
> > changeset.
> >
> > Again, the issue with (grouped) branch + merge is that it prevent you
> > to[1]:
> >
> >     * Summit multiple clean changeset that finally lead to an higher
> >       level feature (macro-change)
> >     * Reorder "macro-change"
> >     * Split "macro-change" in multiple "macro-change"
> >
> > This lead to poorer history.
>
> It is a trade-off, as you are no doubt very well aware: what you call a
> poor history might be called a more correct and rich history by others.
>
> 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.

>
> The real way to collaborate is to commit, pull, merge, repeat. This is
> the way I can explain to "normal" developers at the companies I visit.
> There is no way I can get 3 guys working together on a feature using a
> versioned MQ patch series.

In a real world company, I agree. There you don't have the prerogative we have:
sit on a bunch of changes until you and others think they're good enough.

There you have to fix something, quite often without anyone reviewing it,
test it, but more importantly publish your work because -others depend
on it- in one way or another.

>
> Unless the conflict resolution of the future history rewriting system
> will be extraordinarily intelligent, then I fear that it will be equally
> difficult to make 3 developers work together on a feature branch when
> they have to grasp the idea of a meta-history in addition to doing what
> they are paid for: solving some problem for a customer.
>
>
> We have bugfixes in the Mercurial history today -- though we try hard to
> double-check everything, no code is perfect when we accept the patches.
> That is why I feel that we should accept that there will be bugfixes and
> aim to optimize the overall process using the tools we have already.

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?

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

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.

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.

(not strictly related, but still I found this to be a nice read:
http://kerneltrap.org/Linux/Git_Management )

>
> We should be able to have branches where we let the code mature. Patrick
> had some 30 patches in his queue for patch.py, I have some patches for
> localizing the man pages, Matt had patches for filesets (yay!), etc.
> Does this notion of publishing works in progress in the form of commits,
> not patches, sound completely crazy?

No, but I think there should be a distinction between work in progress/
publishing for review, and preparing it for inclusion in the main repo.

For the former, again, do whatever you want on the side with your
collaborators.

But for the latter, keep the interesting things only: if you started
with data structure X and later realized that Y is so much
better, go back to the relevant patch, (put a comment while
you're at it), and fix it there. Of course this isn't always possible,
but if it is, why not take advantage of it?

>
> --
> Martin Geisler
>
> Mercurial links: http://mercurial.ch/
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>


More information about the Mercurial-devel mailing list