* Summary of the problems with git pull
@ 2014-05-05 0:29 Felipe Contreras
2014-05-06 20:03 ` Damien Robert
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Felipe Contreras @ 2014-05-05 0:29 UTC (permalink / raw)
To: git
Cc: W. Trevor King, Philip Oakley, Marc Branchaud, Richard Hansen,
Andreas Krey, Marat Radchenko
Hi,
There has been a lot of discussion about why `git pull` is broken for so
many many workflows: [1][2][3][4][5], even as far back as [6].
Many issues has been brought up, and many proposed solutions, probably
too many for most people properly digest them, so here I'll try to
synthesize them.
Mainly there are two core problems with `git pull`:
1) Many times it does a merge when it's not when people want
2) Many times it does a merge opposite of the desired direction
The issue comes in trying to solve these problems in a way that would
not affect anybody negatively.
The simplest way to fix these issues unobtrusively would be to add
configurations for the new behavior. However, this wouldn't solve the
problem because as it has been discussed the vast majority of people
doing these "bad merges" are not advanced users, so they wouldn't
activate these options.
What is needed is to change the default behavior, but in a way that is
not obtrusive, and with backwards compatibility configuration.
The most concrete proposal is my patch series that puts everything in
place to enable fast-forward merged by default only. However, that still
doesn't solve the problem of the ordering of parents. Normally these two
issues would be independent of each other, but after further analysis I
think they are not.
== Two different kinds of pulls ==
It has become clear that the `git pull` command is in fact used to do
two very different things:
1) Update the current branch
Most people do `git pull` like they would do `svn update`; to update
their current branch.
2) Merge a remote branch
There are many use-cases of this.
The agreement so far is that 1) is the one that is broken, that is; a)
by default only fast-forwards should be allowed, and b) when a merge
happens the parents should be reverted (merge 'master' to
'origin/master').
It would be possible to differentiate these kinds by saying a `git pull`
that doesn't specify the location can be assumed as 1), and a
`git pull remote branch` that does as 2). Another possibility is to
assume only the upstream branch corresponds to 1).
Unfortunately it's the feeling of many people that this solution is not
"clean", because it's two very different behaviors for the same command.
Furthermore even deeper analysis of the use-cases demonstrates there
would be a need to have different configurations for the different modes
(e.g. pull.updateMode and pull.integrateMode).
== git update ==
Another proposed solution is to have a new command: `git update`. This
command would be similar to `git pull --ff-only` by default, but it
could be configured to do merges instead, and when doing so in reverse.
An interesting side-effect of this new command is that it opens the
possibility of thinking about `git update --rebase` vs.
`git pull --rebase`.
For example:
a) git update --merge
Merge HEAD into @{upstream}
b) git update --rebase
Rebase HEAD onto @{upstream}
c) git pull --merge github john
Merge github/john into HEAD
d) git pull --rebase github john
Rebase github/john onto HEAD
Notice how the relationships between them are nice and consistent. Also,
d) was not possible before.
This solves essentially all the issues people presented in their
use-cases, except the differentiation between merging topic and upstream
branches, for which we might want to add different options in
`git pull`, but that's independent from the issues I mentioned at the
beginning.
Nothing changes for the users of `git pull`, except that perhaps we
would want --rebase to work in reverse, since the current
`git pull --rebase` would already rebase HEAD onto @{upstream}.
Personally my next step would be to port the changes I did for
pull.mode = merge-ff-only into a new command `git update`, which would
probably be a copy-paste from `git pull` and see how that turns out. In
addition, when running `git pull` without arguments we might want to add
a temporary notice explaining that perhaps the user wanted to type
`git update` instead.
Cheers.
[1] http://article.gmane.org/gmane.comp.version-control.git/233554
[2] http://article.gmane.org/gmane.comp.version-control.git/234295
[3] http://article.gmane.org/gmane.comp.version-control.git/225146
[4] http://article.gmane.org/gmane.comp.version-control.git/247237
[5] http://article.gmane.org/gmane.comp.version-control.git/247939
[6] http://article.gmane.org/gmane.comp.version-control.git/130819
--
Felipe Contreras
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Summary of the problems with git pull
2014-05-05 0:29 Summary of the problems with git pull Felipe Contreras
@ 2014-05-06 20:03 ` Damien Robert
2014-05-07 10:39 ` Ping Yin
2014-05-10 8:53 ` Felipe Contreras
2 siblings, 0 replies; 7+ messages in thread
From: Damien Robert @ 2014-05-06 20:03 UTC (permalink / raw)
To: git
Felipe Contreras wrote in message
<5366db742d494_18f9e4b308aa@nysa.notmuch>:
> == git update ==
>
> Another proposed solution is to have a new command: `git update`. This
> command would be similar to `git pull --ff-only` by default, but it
> could be configured to do merges instead, and when doing so in reverse.
Thanks for the nice summary.
As a user, I am very much in favor of adding a `git update` command. In
fact I already have a ruby script that does such a thing (fast-forward all my
local branches that have an upstream configured), so it would be nice to
have it directly in git core.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Summary of the problems with git pull
2014-05-05 0:29 Summary of the problems with git pull Felipe Contreras
2014-05-06 20:03 ` Damien Robert
@ 2014-05-07 10:39 ` Ping Yin
2014-05-10 8:53 ` Felipe Contreras
2 siblings, 0 replies; 7+ messages in thread
From: Ping Yin @ 2014-05-07 10:39 UTC (permalink / raw)
To: Felipe Contreras
Cc: git mailing list, W. Trevor King, Philip Oakley, Marc Branchaud,
Richard Hansen, Andreas Krey, Marat Radchenko
Ping Yin
On Mon, May 5, 2014 at 8:29 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Hi,
>
> == git update ==
>
> Another proposed solution is to have a new command: `git update`. This
> command would be similar to `git pull --ff-only` by default, but it
> could be configured to do merges instead, and when doing so in reverse.
>
+1 for git update
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Summary of the problems with git pull
2014-05-05 0:29 Summary of the problems with git pull Felipe Contreras
2014-05-06 20:03 ` Damien Robert
2014-05-07 10:39 ` Ping Yin
@ 2014-05-10 8:53 ` Felipe Contreras
2014-05-28 7:13 ` Philippe Vaucher
2 siblings, 1 reply; 7+ messages in thread
From: Felipe Contreras @ 2014-05-10 8:53 UTC (permalink / raw)
To: Felipe Contreras, git
Cc: W. Trevor King, Philip Oakley, Marc Branchaud, Richard Hansen,
Andreas Krey, Marat Radchenko
Felipe Contreras wrote:
> == git update ==
>
> Another proposed solution is to have a new command: `git update`. This
> command would be similar to `git pull --ff-only` by default, but it
> could be configured to do merges instead, and when doing so in reverse.
And here it is:
https://github.com/felipec/git/commits/fc/update
Here's the documentation:
https://github.com/felipec/git/wiki/git-update
Works exactly as expected: non-fast-forwards are rejected by default,
but can be configured, and parents are reversed when merging.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Summary of the problems with git pull
2014-05-10 8:53 ` Felipe Contreras
@ 2014-05-28 7:13 ` Philippe Vaucher
2014-05-28 8:39 ` Felipe Contreras
0 siblings, 1 reply; 7+ messages in thread
From: Philippe Vaucher @ 2014-05-28 7:13 UTC (permalink / raw)
To: Felipe Contreras, Junio C Hamano
Cc: git, W. Trevor King, Philip Oakley, Marc Branchaud,
Richard Hansen, Andreas Krey, Marat Radchenko
> Felipe Contreras wrote:
>> == git update ==
>>
>> Another proposed solution is to have a new command: `git update`. This
>> command would be similar to `git pull --ff-only` by default, but it
>> could be configured to do merges instead, and when doing so in reverse.
>
> And here it is:
>
> https://github.com/felipec/git/commits/fc/update
>
> Here's the documentation:
>
> https://github.com/felipec/git/wiki/git-update
>
> Works exactly as expected: non-fast-forwards are rejected by default,
> but can be configured, and parents are reversed when merging.
I know patches from Felipe are sensitive subject and that a lot of
people probably simply ignore him entirely, however I think this patch
deserves more attention.
>From what I read, it seems to really improve the "pull" issues and is
more or less in line with what Junio suggested what should be done in
[1]. So the goal of this mail is just to make sure people consider it
for inclusion.
Sorry if I missed a thread where it was already decided not to include it.
Felipe, please don't use this to start any non-constructive behavior
(rant on who is right/wrong, "my patches are not accepted", etc).
Philippe
[1] http://article.gmane.org/gmane.comp.version-control.git/248258
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Summary of the problems with git pull
2014-05-28 7:13 ` Philippe Vaucher
@ 2014-05-28 8:39 ` Felipe Contreras
0 siblings, 0 replies; 7+ messages in thread
From: Felipe Contreras @ 2014-05-28 8:39 UTC (permalink / raw)
To: Philippe Vaucher, Felipe Contreras, Junio C Hamano
Cc: git, W. Trevor King, Philip Oakley, Marc Branchaud,
Richard Hansen, Andreas Krey, Marat Radchenko
Philippe Vaucher wrote:
> Sorry if I missed a thread where it was already decided not to include
> it.
>
> Felipe, please don't use this to start any non-constructive behavior
> (rant on who is right/wrong, "my patches are not accepted", etc).
I never sent those patches. I gave up on the Git project.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 7+ messages in thread
* Summary of the problems with git pull
@ 2014-05-06 10:58 Felipe Contreras
0 siblings, 0 replies; 7+ messages in thread
From: Felipe Contreras @ 2014-05-06 10:58 UTC (permalink / raw)
To: git
Cc: W. Trevor King, Philip Oakley, Marc Branchaud, Richard Hansen,
Andreas Krey, Marat Radchenko
Hi,
There has been a lot of discussion about why `git pull` is broken for so
many many workflows: [1][2][3][4][5], even as far back as [6].
Many issues has been brought up, and many proposed solutions, probably
too many for most people properly digest them, so here I'll try to
synthesize them.
Mainly there are two core problems with `git pull`:
1) Many times it does a merge when it's not when people want
2) Many times it does a merge opposite of the desired direction
The issue comes in trying to solve these problems in a way that would
not affect anybody negatively.
The simplest way to fix these issues unobtrusively would be to add
configurations for the new behavior. However, this wouldn't solve the
problem because as it has been discussed the vast majority of people
doing these "bad merges" are not advanced users, so they wouldn't
activate these options.
What is needed is to change the default behavior, but in a way that is
not obtrusive, and with backwards compatibility configuration.
The most concrete proposal is my patch series that puts everything in
place to enable fast-forward merged by default only. However, that still
doesn't solve the problem of the ordering of parents. Normally these two
issues would be independent of each other, but after further analysis I
think they are not.
== Two different kinds of pulls ==
It has become clear that the `git pull` command is in fact used to do
two very different things:
1) Update the current branch
Most people do `git pull` like they would do `svn update`; to update
their current branch.
2) Merge a remote branch
There are many use-cases of this.
The agreement so far is that 1) is the one that is broken, that is; a)
by default only fast-forwards should be allowed, and b) when a merge
happens the parents should be reverted (merge 'master' to
'origin/master').
It would be possible to differentiate these kinds by saying a `git pull`
that doesn't specify the location can be assumed as 1), and a
`git pull remote branch` that does as 2). Another possibility is to
assume only the upstream branch corresponds to 1).
Unfortunately it's the feeling of many people that this solution is not
"clean", because it's two very different behaviors for the same command.
Furthermore even deeper analysis of the use-cases demonstrates there
would be a need to have different configurations for the different modes
(e.g. pull.updateMode and pull.integrateMode).
== git update ==
Another proposed solution is to have a new command: `git update`. This
command would be similar to `git pull --ff-only` by default, but it
could be configured to do merges instead, and when doing so in reverse.
An interesting side-effect of this new command is that it opens the
possibility of thinking about `git update --rebase` vs.
`git pull --rebase`.
For example:
a) git update --merge
Merge HEAD into @{upstream}
b) git update --rebase
Rebase HEAD onto @{upstream}
c) git pull --merge github john
Merge github/john into HEAD
d) git pull --rebase github john
Rebase github/john onto HEAD
Notice how the relationships between them are nice and consistent. Also,
d) was not possible before.
This solves essentially all the issues people presented in their
use-cases, except the differentiation between merging topic and upstream
branches, for which we might want to add different options in
`git pull`, but that's independent from the issues I mentioned at the
beginning.
Nothing changes for the users of `git pull`, except that perhaps we
would want --rebase to work in reverse, since the current
`git pull --rebase` would already rebase HEAD onto @{upstream}.
Personally my next step would be to port the changes I did for
pull.mode = merge-ff-only into a new command `git update`, which would
probably be a copy-paste from `git pull` and see how that turns out. In
addition, when running `git pull` without arguments we might want to add
a temporary notice explaining that perhaps the user wanted to type
`git update` instead.
Cheers.
[1] http://article.gmane.org/gmane.comp.version-control.git/233554
[2] http://article.gmane.org/gmane.comp.version-control.git/234295
[3] http://article.gmane.org/gmane.comp.version-control.git/225146
[4] http://article.gmane.org/gmane.comp.version-control.git/247237
[5] http://article.gmane.org/gmane.comp.version-control.git/247939
[6] http://article.gmane.org/gmane.comp.version-control.git/130819
--
Felipe Contreras
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-05-28 8:50 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-05 0:29 Summary of the problems with git pull Felipe Contreras
2014-05-06 20:03 ` Damien Robert
2014-05-07 10:39 ` Ping Yin
2014-05-10 8:53 ` Felipe Contreras
2014-05-28 7:13 ` Philippe Vaucher
2014-05-28 8:39 ` Felipe Contreras
2014-05-06 10:58 Felipe Contreras
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).