Possible change to the "git push" behavior

1 view
Skip to first unread message

Angel Ezquerra Moreu

unread,
Mar 20, 2012, 3:02:10 AM3/20/12
to mercurial-devel
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?

Angel
_______________________________________________
Mercurial-devel mailing list
Mercuri...@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel

Greg Ward

unread,
Mar 20, 2012, 9:01:40 AM3/20/12
to Angel Ezquerra Moreu, mercurial-devel
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'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?"

Martin Geisler

unread,
Mar 20, 2012, 9:28:10 AM3/20/12
to Angel Ezquerra Moreu, Sune Foldager, Henrik Stuart, mercurial-devel
Greg Ward <gr...@gerg.ca> writes:

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

Pierre-Yves David

unread,
Mar 20, 2012, 9:31:17 AM3/20/12
to Martin Geisler, Henrik Stuart, Sune Foldager, mercurial-devel
On Tue, Mar 20, 2012 at 02:28:10PM +0100, Martin Geisler 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 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.

the following alias is wonderful:

nudge=push -r .


--
Pierre-Yves David

http://www.logilab.fr/

signature.asc

Angel Ezquerra

unread,
Mar 20, 2012, 9:42:19 AM3/20/12
to Martin Geisler, Sune Foldager, Henrik Stuart, mercurial-devel

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

Martin Geisler

unread,
Mar 20, 2012, 10:42:06 AM3/20/12
to Angel Ezquerra, Sune Foldager, Henrik Stuart, mercurial-devel
Angel Ezquerra <angel.e...@gmail.com> writes:

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/

Augie Fackler

unread,
Mar 20, 2012, 12:44:45 PM3/20/12
to Martin Geisler, Henrik Stuart, Sune Foldager, mercurial-devel

I'm actually stunned they're even considering changing this behavior.

Na'Tosha Bard

unread,
Mar 20, 2012, 12:50:21 PM3/20/12
to Augie Fackler, Sune Foldager, Martin Geisler, Henrik Stuart, mercurial-devel
2012/3/20 Augie Fackler <li...@durin42.com>

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.

Cheers,
Na'Tosha

--
Na'Tosha Bard
Build & Infrastructure Developer | Unity Technologies - Copenhagen

Skype: natosha.bard

Na'Tosha Bard

unread,
Mar 20, 2012, 12:52:24 PM3/20/12
to Augie Fackler, Sune Foldager, Martin Geisler, Henrik Stuart, mercurial-devel
2012/3/20 Augie Fackler <li...@durin42.com>
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.

OK, right, from that perspective, I can understand the shock.

Augie Fackler

unread,
Mar 20, 2012, 12:51:23 PM3/20/12
to Na'Tosha Bard, Sune Foldager, Martin Geisler, Henrik Stuart, mercurial-devel
On Tue, Mar 20, 2012 at 11:50 AM, Na'Tosha Bard <nat...@unity3d.com> wrote:

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
>

Martin Geisler

unread,
Mar 21, 2012, 5:07:19 AM3/21/12
to Augie Fackler, Sune Foldager, Henrik Stuart, mercurial-devel
Augie Fackler <li...@durin42.com> writes:

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

Pierre-Yves David

unread,
Mar 21, 2012, 5:40:34 AM3/21/12
to Martin Geisler, Sune Foldager, mercurial-devel, Henrik Stuart
On Wed, Mar 21, 2012 at 10:07:19AM +0100, Martin Geisler wrote:
> Augie Fackler <li...@durin42.com> writes:
>
> > 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.

the one who synchronize multiple repositories ?

signature.asc

Kevin Bullock

unread,
Mar 21, 2012, 12:05:31 PM3/21/12
to Augie Fackler, Henrik Stuart, Sune Foldager, Martin Geisler, mercurial-devel
On Mar 20, 2012, at 11:51 AM, Augie Fackler wrote:

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 default
behavior 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 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. This has been the way git has worked for 4+ years,
it's going to be pretty entrenched.

Don't most Git users have `git push origin master` finger-macro'd anyway?

I'll point out that if your workflow is pull-based, then the behavior of push doesn't matter much. Moreover, in real-world distributed workflows where developers push to their own repo on a public server (github, kernel.org), and integrators pull from those individual repos, it makes a lot of sense to have this particular asymmetry between push and pull. But this is all theoretical for us because of backwards compatibility.

All that being said, I'm also unimpressed that they'd make such a huge change. Glad once again to be a Mercurial user. :)

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock

Reply all
Reply to author
Forward
0 new messages