Using bookmarks in Mercurial itself

Peter Arrenbrecht peter.arrenbrecht at gmail.com
Fri Jun 17 09:50:41 CDT 2011


On Fri, Jun 17, 2011 at 2:17 PM, Pierre-Yves David
<pierre-yves.david at logilab.fr> wrote:
> On Fri, Jun 17, 2011 at 01:08:14PM +0200, Martin Geisler wrote:
>
>> > I thought the whole point of sending patches to the list is to have a
>> > discussion and let others review -before- committing stuff.
>>
>> That is the purpose and the result is a pretty nice history in
>> Mercurial: very linear and very good commits.
>>
>> But don't you also think that it is strange that we have such a fine
>> tool available and then we're still hesitant to commit things for real?
>>
>
> Committing half-baked commit add a lot a noise. Greatly reducing audit and
> bisect possibility. I would refer to my talk at the 1.9 sprint, we want the tip
> most part of the history to be easily mutable not a crappy history of changeset
> backouting one another.

It's not necessarily half-baked. It's what a knowledgable crew member
considered a good stab at solving the problem. Then you add on top of
that refinements contributed by others. All trackable, but not - by
default - in your face. So this is not about *mutable* history. It's
for the case where a crew member today might just push stuff, as
opposed to sending an RFC. If such things were pushed to separate
branches and refined there as well, it might be easier to follow the
evolution of a particular major feature.

As for your thoughts from the 1.9 sprint on how one would wish to be
able to collaborate on mutable history, I still fully agree of course.
-parren

> Currently mercurial have some history rewriting capability but no proper
> solution to easily share this mutable part with other. (the only current option
> is versionned MQ).
>
> To be able to easily share and work together on the mutable section of the
> history we need the same tool than we set up to share and work together on
> file:
>
>    **We want some mechanism to version changeset**
>
> As explained in my talk this changeset history better be perpendicular to the
> file history.
>
>> It's of course just a gut feeling, but I feel that a DVCS should allow
>> us to commit and experiment more freely than we do today.
>
> I'm working on state//obsolete concept to add some capability to mercurial. You
> are free to join me in the effort.
>
>>   hg merge --hide-second-parent feature-x
>
>
> During discussion about keeping history clean but sharing mutable part of the
> history, this proposal (to have merge considered as single changeset) are often
> suggested. The main limitation of this approach is that is make it hard to
> split your work in small, clean, atomical changeset easy to review and prevent
> reordoring your change.
>
> I see the "hide-second-parent" as hacky method to get a "poor man rewritable"
> history. I'll insist that in my opinion the way to got is perpendicular history
> for changeset. I, again, encourage anyone interressed to join me in the effort.
>
>
> --
> Pierre-Yves David
>
> http://www.logilab.fr/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk37RdIACgkQElczi7p/bN/owQCePf9Ays57ZG2w4wApys2eGhib
> PVYAnAy4LfOCzeyc1iuKt6Yxfb1robpy
> =zrMZ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
>


More information about the Mercurial-devel mailing list