Since mercurial bookmarks are meant (AFAIK) to behave similarly to git
branches, would mercurial change the way bookmarks work if git changes
the way git branches work? How would that work given mercurial's
backwards compatibility policy?
Angel
_______________________________________________
Mercurial-devel mailing list
Mercuri...@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel
I don't speak for Matt or for anyone else, but I suspect the answer is
"not bloody likely". "hg update" does not behave the same way as "cvs
update" does, so why should "hg push" behave the same way as "git
push"? Mercurial is its own project with its own aims and its own
policies.
That said, the "push all changesets by default" policy could be a
minor annoyance when using bookmarks. I've pondered ways to improve
things that don't break compatbility or seem insane, but have not
thought of anything so far. I certainly haven't looked to git for
inspiration, because I always feel like a total newbie when I use git.
(And that's with, what, 3+ years of occasional experience. I've
actually been using git for longer than I've been using hg, and I
still feel like a newbie.)
Greg
--
Greg Ward http://www.gerg.ca/
"Question authority!" "Oh yeah? Says who?"
> On 20 March 2012, Angel Ezquerra Moreu said:
>> It seems that the Git project is considering changing the default
>> behavior for the "git push" command (http://lwn.net/Articles/487131).
>>
>> Since mercurial bookmarks are meant (AFAIK) to behave similarly to git
>> branches, would mercurial change the way bookmarks work if git changes
>> the way git branches work? How would that work given mercurial's
>> backwards compatibility policy?
>
> I don't speak for Matt or for anyone else, but I suspect the answer is
> "not bloody likely". "hg update" does not behave the same way as "cvs
> update" does, so why should "hg push" behave the same way as "git
> push"? Mercurial is its own project with its own aims and its own
> policies.
>
> That said, the "push all changesets by default" policy could be a
> minor annoyance when using bookmarks.
I know this is about bookmarks, but as a related data point, I can
mention that Henrik and Sune's repoman wrapper always operates with a -b
flag in order to push/pull the right named branch instead of operating
on all of them.
Last time I spoke with them about it, they said that it would be
impossible (very impractical) for them to push/pull everything by
default.
--
Martin Geisler
aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/
the following alias is wonderful:
nudge=push -r .
--
Pierre-Yves David
Yes, I was referring to the way bookmarks are pushed specifically. I
am not suggesting that mercurial's push should be the same as git's
push. I just wonder whether the idea is for mercurial's bookmarks to
closely follow git's branch behavior. If that is the case and git
changes the way it pushes branches, what will mercurial do?
As for the fact that hg push pushes all branches that is one of those
things that cause a little surprise to new users. In TortoiseHg we've
added a setting called "Default Push" whose valid values are "all",
"branch" and "revision". The default is "all", since that matches
mercurial's default push behavior, but I know quite a few people who
have changed it.
Angel
Mercurial's bookmarks were inspired by Git branches in the sense that
they're pointers to changesets that move on commit. But it's not a goal
to replicate Git branches 100% and users should not expect changes in
Git to propagate directly to Mercurial bookmarks.
--
Martin Geisler
aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/
I'm actually stunned they're even considering changing this behavior.
Think of all the deployed software out there that depends on the
existing behavior. This has been the way git has worked for 4+ years,
it's going to be pretty entrenched.
Think of all the deployed software out there that depends on the
existing behavior. This has been the way git has worked for 4+ years,
it's going to be pretty entrenched.
>
> Cheers,
> Na'Tosha
>
> --
> Na'Tosha Bard
> Build & Infrastructure Developer | Unity Technologies - Copenhagen
>
> E-Mail: nat...@unity3d.com
> Skype: natosha.bard
>
> On Tue, Mar 20, 2012 at 11:50 AM, Na'Tosha Bard <nat...@unity3d.com> wrote:
>
>> Augie Fackler <li...@durin42.com> writes:
>>
>>> On Tue, Mar 20, 2012 at 9:42 AM, Martin Geisler <m...@aragost.com> wrote:
>>>
>>>> Mercurial's bookmarks were inspired by Git branches in the sense
>>>> that they're pointers to changesets that move on commit. But it's
>>>> not a goal to replicate Git branches 100% and users should not
>>>> expect changes in Git to propagate directly to Mercurial bookmarks.
>>>
>>> I'm actually stunned they're even considering changing this behavior.
>>
>> Really? "Push only the branch I'm working on" is the behavior most
>> users expect, in my experience, and pushing everything at once by
>> default is actually an inconvenience.
>
> Think of all the deployed software out there that depends on the
> existing behavior.
What kind of automated software depends on pushing all available
branches? The cronjobs I've seen/written all depend on knowing exactly
which branches they push -- normally a single branch named 'production',
'stable' or similar.
--
Martin Geisler
aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/
the one who synchronize multiple repositories ?
On Tue, Mar 20, 2012 at 11:50 AM, Na'Tosha Bard <nat...@unity3d.com> wrote:2012/3/20 Augie Fackler <li...@durin42.com>On Tue, Mar 20, 2012 at 9:42 AM, Martin Geisler <m...@aragost.com> wrote:Angel Ezquerra <angel.e...@gmail.com> writes:On Tue, Mar 20, 2012 at 2:28 PM, Martin Geisler <m...@aragost.com> wrote:Greg Ward <gr...@gerg.ca> writes:On 20 March 2012, Angel Ezquerra Moreu said:It seems that the Git project is considering changing the defaultbehavior for the "git push" command(http://lwn.net/Articles/487131).
[…]
I'm actually stunned they're even considering changing this behavior.Really? "Push only the branch I'm working on" is the behavior most usersexpect, in my experience, and pushing everything at once by default isactually an inconvenience.
Think of all the deployed software out there that depends on the
existing behavior. This has been the way git has worked for 4+ years,
it's going to be pretty entrenched.