From: Junio C Hamano <hidden> Date: 2016-06-15 22:58:37
Felipe Contreras [off-list ref] writes:
On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano [off-list ref] wrote:
quoted
Felipe Contreras [off-list ref] writes:
quoted
Junio already sent a similar patch, but I think this is simpler.
I agree that this is simpler, but I am not sure if the behaviour is
necessarily better (note that this is different from saying "I think
the behaviour of this patch is worse"). The motivation I read from
the original discussion was that new people did "git pull" (no other
parameters) to "sync my tree with the central repository" as if it
were SVN, and because we are not SVN, projects that prefer rebases
were unhappy, and the other one was to address *only* that use case.
I do not personally like that special casing (i.e. "only when no
'integrate with what from where' is given"), and applying the "you
must be explicit between rebase and merge" like this series does
uniformly might (or might not) be a good thing. I dunno.
As I already said; there's is essentially no difference between "git
pull" and "git pull origin".
We know what you said earlier. That does not make it right or wrong,
but I do not think it is in line with the original discussion (that
is why John Keeping is kept on the Cc: line).
quoted
The difference in changes needed to the test suite is illustrative;
this series affects any use of "git pull" (with or without explicit
"what to integrate with and from where"), unlike the other one that
only affects the case where "git pull" was not given "what to
integrate with and from where". I think an earlier draft I did for
the previous one did not special case "only when no 'integrate with
what from where' is given" and had to touch all the places in the
test in a similar way.
Yeah, that version affects less, but it also doesn't achieve what we
actually want.
I do not think we know what we want is to affect "git pull origin".
From: Felipe Contreras <hidden> Date: 2016-06-15 22:58:37
On Tue, Sep 3, 2013 at 5:38 PM, Junio C Hamano [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano [off-list ref] wrote:
quoted
Felipe Contreras [off-list ref] writes:
quoted
Junio already sent a similar patch, but I think this is simpler.
I agree that this is simpler, but I am not sure if the behaviour is
necessarily better (note that this is different from saying "I think
the behaviour of this patch is worse"). The motivation I read from
the original discussion was that new people did "git pull" (no other
parameters) to "sync my tree with the central repository" as if it
were SVN, and because we are not SVN, projects that prefer rebases
were unhappy, and the other one was to address *only* that use case.
I do not personally like that special casing (i.e. "only when no
'integrate with what from where' is given"), and applying the "you
must be explicit between rebase and merge" like this series does
uniformly might (or might not) be a good thing. I dunno.
As I already said; there's is essentially no difference between "git
pull" and "git pull origin".
We know what you said earlier. That does not make it right or wrong,
but I do not think it is in line with the original discussion (that
is why John Keeping is kept on the Cc: line).
And nobody provided any argument against that claim. People staying
silent doesn't make it wrong.
quoted
quoted
The difference in changes needed to the test suite is illustrative;
this series affects any use of "git pull" (with or without explicit
"what to integrate with and from where"), unlike the other one that
only affects the case where "git pull" was not given "what to
integrate with and from where". I think an earlier draft I did for
the previous one did not special case "only when no 'integrate with
what from where' is given" and had to touch all the places in the
test in a similar way.
Yeah, that version affects less, but it also doesn't achieve what we
actually want.
I do not think we know what we want is to affect "git pull origin".
Of course we do.
What we want is to make "git pull" more user-friendly, specially to
newcomers, and specially those that come from centralized VCS, where
"tool pull" updates the checkout, and thus we want "git pull" not to
create merges inadvertently, and the best way to do that is to warn
the user that the merge is non-fast-forward, and he should do a merge
or rebase.
The fact that a particular user might have learned about remotes and
did "git pull origin" instead is irrelevant, he would still want to be
warned about non-fast-forward merges.
Everybody would want to be warned about that by default, I know I
would, I might even start using 'git pull' again, and so countless
people that have stopped using 'git pull' precisely for this reason.
--
Felipe Contreras
From: John Keeping <hidden> Date: 2016-06-15 22:58:37
On Tue, Sep 03, 2013 at 03:38:58PM -0700, Junio C Hamano wrote:
Felipe Contreras [off-list ref] writes:
quoted
On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano [off-list ref] wrote:
quoted
Felipe Contreras [off-list ref] writes:
quoted
Junio already sent a similar patch, but I think this is simpler.
I agree that this is simpler, but I am not sure if the behaviour is
necessarily better (note that this is different from saying "I think
the behaviour of this patch is worse"). The motivation I read from
the original discussion was that new people did "git pull" (no other
parameters) to "sync my tree with the central repository" as if it
were SVN, and because we are not SVN, projects that prefer rebases
were unhappy, and the other one was to address *only* that use case.
I do not personally like that special casing (i.e. "only when no
'integrate with what from where' is given"), and applying the "you
must be explicit between rebase and merge" like this series does
uniformly might (or might not) be a good thing. I dunno.
As I already said; there's is essentially no difference between "git
pull" and "git pull origin".
We know what you said earlier. That does not make it right or wrong,
but I do not think it is in line with the original discussion (that
is why John Keeping is kept on the Cc: line).
I think there are two distinct uses for pull, which boil down to:
(1) git pull
(2) git pull $remote $branch
For (1) a merge is almost always the wrong thing to do since it will be
backwards and break --first-parent.
But for (2) a merge is almost always the correct thing to do (in fact it
may even be correct to create a merge commit even when this fast
forwards) because this most likely comes for a pull request workflow.
I do not think we know what we want is to affect "git pull origin".
I consider "git pull $remote" to be an artifact of the way git-pull is
implemented on top of git-fetch; perhaps I'm missing something but I
can't see a scenario where this is useful. In the series currently in
"next", we treat this as (2) above but that's primarily because it is
difficult to differentiate these in git-pull.sh without adding code to
understand all of the options to git-fetch (or at least those that can
accept unstuck arguments).
Changing this so that "git pull $remote" is treated as (1) would be
better, but I think it is more important to avoid catching case (1) in
the same net which is why jc/pull-training-wheel simply checks if "$#"
is zero; the cost of getting this completely right outweighed the
benefit of getting code in that will catch 99% of users.
From: Jeff King <hidden> Date: 2016-06-15 22:58:37
On Wed, Sep 04, 2013 at 09:10:47AM +0100, John Keeping wrote:
I think there are two distinct uses for pull, which boil down to:
(1) git pull
(2) git pull $remote $branch
For (1) a merge is almost always the wrong thing to do since it will be
backwards and break --first-parent.
Is it always wrong? You are assuming a topic-branch workflow where
--first-parent is actually meaningful. What about a centralized workflow
where everyone works on "master"? The correct thing to do on a non-ff
push in that case is "git pull && git push". Some people would argue
that the pull should rebase there, but I think there are valid arguments
either way. We can discuss in that direction if you want.
I can perhaps buy the argument that it is better to help people who are
using a topic branch workflow (which we generally want to encourage) to
avoid making backwards merges, and the cost is that people with sloppy
workflows will have to do more work / configuration. But we should be
clear that this is a tradeoff we are making.
The patch in jc/pull-training-wheel talks about annoying old timers, but
I think you may also be annoying clueless new users who simply want an
svn-like workflow without thinking too hard about it.
quoted
I do not think we know what we want is to affect "git pull origin".
I consider "git pull $remote" to be an artifact of the way git-pull is
implemented on top of git-fetch; perhaps I'm missing something but I
can't see a scenario where this is useful.
Imagine a workflow where each topic is in its own repository instead of
in its own branch inside a repository. Or where each developer has his
or her own repository, but everybody just works on the master branch of
their repository (or perhaps uses branches, but keeps master as a stable
base). Alice is the integration manager; Bob tells her that he has work
ready to integrate. She runs "git pull ~bob/project", which will merge
Bob's HEAD.
This is not very different from the kernel workflow, where Linus may do
a "git pull $remote" to fetch a sub-system maintainer's work, except
that these days people typically mark the to-be-integrated work in a
"for-linus" branch or tag. However, you can find many "Merge git://"
entries even in recent kernel history.
I think this kind of pull would fall into the same situation as your (2)
above.
-Peff
From: John Keeping <hidden> Date: 2016-06-15 22:58:37
On Wed, Sep 04, 2013 at 05:25:27AM -0400, Jeff King wrote:
On Wed, Sep 04, 2013 at 09:10:47AM +0100, John Keeping wrote:
quoted
I think there are two distinct uses for pull, which boil down to:
(1) git pull
(2) git pull $remote $branch
For (1) a merge is almost always the wrong thing to do since it will be
backwards and break --first-parent.
Is it always wrong? You are assuming a topic-branch workflow where
--first-parent is actually meaningful. What about a centralized workflow
where everyone works on "master"? The correct thing to do on a non-ff
push in that case is "git pull && git push". Some people would argue
that the pull should rebase there, but I think there are valid arguments
either way. We can discuss in that direction if you want.
I'm one of the people who argues that it should rebase there ;-) The
point of jc/pull-training-wheel is to help users think about that.
I can perhaps buy the argument that it is better to help people who are
using a topic branch workflow (which we generally want to encourage) to
avoid making backwards merges, and the cost is that people with sloppy
workflows will have to do more work / configuration. But we should be
clear that this is a tradeoff we are making.
The patch in jc/pull-training-wheel talks about annoying old timers, but
I think you may also be annoying clueless new users who simply want an
svn-like workflow without thinking too hard about it.
The scenario I have is a central repository where some developers use a
topic branch workflow but others are less familiar with Git and don't
really think about what they're doing.
quoted
quoted
I do not think we know what we want is to affect "git pull origin".
I consider "git pull $remote" to be an artifact of the way git-pull is
implemented on top of git-fetch; perhaps I'm missing something but I
can't see a scenario where this is useful.
Imagine a workflow where each topic is in its own repository instead of
in its own branch inside a repository. Or where each developer has his
or her own repository, but everybody just works on the master branch of
their repository (or perhaps uses branches, but keeps master as a stable
base). Alice is the integration manager; Bob tells her that he has work
ready to integrate. She runs "git pull ~bob/project", which will merge
Bob's HEAD.
This is not very different from the kernel workflow, where Linus may do
a "git pull $remote" to fetch a sub-system maintainer's work, except
that these days people typically mark the to-be-integrated work in a
"for-linus" branch or tag. However, you can find many "Merge git://"
entries even in recent kernel history.
I think this kind of pull would fall into the same situation as your (2)
above.
OK - so I was missing this. Given this, the jc/pull-training-wheel
series is doing the right thing here.
From: Felipe Contreras <hidden> Date: 2016-06-15 22:58:40
On Wed, Sep 4, 2013 at 4:25 AM, Jeff King [off-list ref] wrote:
The patch in jc/pull-training-wheel talks about annoying old timers, but
I think you may also be annoying clueless new users who simply want an
svn-like workflow without thinking too hard about it.
How? Subversion would complain if you have local changes when you do
'svn pull', there's no notion of remotes, branches and merges are
rare, and forget about rebases.
quoted
quoted
I do not think we know what we want is to affect "git pull origin".
I consider "git pull $remote" to be an artifact of the way git-pull is
implemented on top of git-fetch; perhaps I'm missing something but I
can't see a scenario where this is useful.
Imagine a workflow where each topic is in its own repository instead of
in its own branch inside a repository. Or where each developer has his
or her own repository, but everybody just works on the master branch of
their repository (or perhaps uses branches, but keeps master as a stable
base). Alice is the integration manager; Bob tells her that he has work
ready to integrate. She runs "git pull ~bob/project", which will merge
Bob's HEAD.
These integrators should know what they are doing, so they can do 'git
pull --merge', or better 'git config pull.mode merge', as Linus
himself suggested (or something like that).
The defaults should care most about the clueless users.
--
Felipe Contreras
From: Jeff King <hidden> Date: 2016-06-15 22:58:40
On Sat, Sep 07, 2013 at 09:52:16PM -0500, Felipe Contreras wrote:
On Wed, Sep 4, 2013 at 4:25 AM, Jeff King [off-list ref] wrote:
quoted
The patch in jc/pull-training-wheel talks about annoying old timers, but
I think you may also be annoying clueless new users who simply want an
svn-like workflow without thinking too hard about it.
How? Subversion would complain if you have local changes when you do
'svn pull', there's no notion of remotes, branches and merges are
rare, and forget about rebases.
By "svn-like", I mean the people whose workflow is:
$ hack hack hack
$ git commit
$ git push ;# oops, somebody else pushed in the meantime
$ git pull
$ git push
without using branches or worrying about the shape of history. I do not
know what you mean by "svn pull", since that command does not exist
(unless you are talking about svk?). In subversion, that workflow would
be:
$ hack hack hack
$ svn commit ;# oops, somebody else committed in the meantime
$ svn update
$ svn commit
Those people would now have to learn enough to choose between merge and
rebase when running the "git pull".
It may be OK to say "we do not care about that case, and it is a good
thing that they learn enough to make the choice consciously." But I do
think they exist.
quoted
quoted
quoted
I do not think we know what we want is to affect "git pull origin".
I consider "git pull $remote" to be an artifact of the way git-pull is
implemented on top of git-fetch; perhaps I'm missing something but I
can't see a scenario where this is useful.
Imagine a workflow where each topic is in its own repository instead of
in its own branch inside a repository. Or where each developer has his
or her own repository, but everybody just works on the master branch of
their repository (or perhaps uses branches, but keeps master as a stable
base). Alice is the integration manager; Bob tells her that he has work
ready to integrate. She runs "git pull ~bob/project", which will merge
Bob's HEAD.
These integrators should know what they are doing, so they can do 'git
pull --merge', or better 'git config pull.mode merge', as Linus
himself suggested (or something like that).
The defaults should care most about the clueless users.
In this part of the email you are quoting I was not intending to say
anything about clueless users at all, nor even about what defaults there
are. John indicated that he could not imagine a scenario of "git pull
$remote", so I gave an example.
-Peff
From: Felipe Contreras <hidden> Date: 2016-06-15 22:58:40
On Sat, Sep 7, 2013 at 11:18 PM, Jeff King [off-list ref] wrote:
On Sat, Sep 07, 2013 at 09:52:16PM -0500, Felipe Contreras wrote:
quoted
On Wed, Sep 4, 2013 at 4:25 AM, Jeff King [off-list ref] wrote:
quoted
The patch in jc/pull-training-wheel talks about annoying old timers, but
I think you may also be annoying clueless new users who simply want an
svn-like workflow without thinking too hard about it.
How? Subversion would complain if you have local changes when you do
'svn pull', there's no notion of remotes, branches and merges are
rare, and forget about rebases.
By "svn-like", I mean the people whose workflow is:
$ hack hack hack
$ git commit
$ git push ;# oops, somebody else pushed in the meantime
$ git pull
$ git push
But that's not svn-like at all.
without using branches or worrying about the shape of history. I do not
know what you mean by "svn pull", since that command does not exist
(unless you are talking about svk?). In subversion, that workflow would
be:
$ hack hack hack
$ svn commit ;# oops, somebody else committed in the meantime
$ svn update
$ svn commit
Those people would now have to learn enough to choose between merge and
rebase when running the "git pull".
But that's only if they don't care about the shape of history. In my
experience the people that cling more to centralized VCS do not like
merges, so they rebase everything to make it a straight line. That is
much more "svn-like".
So chances are they are already doing 'git pull --rebase' (or
similar), so their workflow wouldn't be affected.
It may be OK to say "we do not care about that case, and it is a good
thing that they learn enough to make the choice consciously." But I do
think they exist.
Yeah, I'm sure they exist, but they are a tiny minority compared to
the amount of people who don't actually understand what 'git pull' is
doing and do merges by mistake.
--
Felipe Contreras
From: Jeff King <hidden> Date: 2016-06-15 22:58:40
On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
quoted
By "svn-like", I mean the people whose workflow is:
$ hack hack hack
$ git commit
$ git push ;# oops, somebody else pushed in the meantime
$ git pull
$ git push
But that's not svn-like at all.
It's not if you understand the difference between merge-then-commit and
commit-then-merge. But for a clueless user who has been told "replace
svn commit" with "git commit && git push" and replace "svn update" with
"git pull", it is quite similar.
quoted
Those people would now have to learn enough to choose between merge and
rebase when running the "git pull".
But that's only if they don't care about the shape of history. In my
experience the people that cling more to centralized VCS do not like
merges, so they rebase everything to make it a straight line. That is
much more "svn-like".
So chances are they are already doing 'git pull --rebase' (or
similar), so their workflow wouldn't be affected.
I think we are talking about two classes of users. People who truly
don't care about the shape of history will also not care about using
"git pull --rebase", because the only reason to use it is to impact the
shape of history.
I agree there is also a set of people coming from the centralized vcs
world who want to keep a linear history.
-Peff
From: Felipe Contreras <hidden> Date: 2016-06-15 22:58:40
On Sat, Sep 7, 2013 at 11:43 PM, Jeff King [off-list ref] wrote:
On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
quoted
quoted
By "svn-like", I mean the people whose workflow is:
$ hack hack hack
$ git commit
$ git push ;# oops, somebody else pushed in the meantime
$ git pull
$ git push
But that's not svn-like at all.
It's not if you understand the difference between merge-then-commit and
commit-then-merge. But for a clueless user who has been told "replace
svn commit" with "git commit && git push" and replace "svn update" with
"git pull", it is quite similar.
Well, yeah, but if they are so clueless they have to be told what to
do, they can be told to do 'git pull --merge' instead, no?
quoted
quoted
Those people would now have to learn enough to choose between merge and
rebase when running the "git pull".
But that's only if they don't care about the shape of history. In my
experience the people that cling more to centralized VCS do not like
merges, so they rebase everything to make it a straight line. That is
much more "svn-like".
So chances are they are already doing 'git pull --rebase' (or
similar), so their workflow wouldn't be affected.
I think we are talking about two classes of users. People who truly
don't care about the shape of history will also not care about using
"git pull --rebase", because the only reason to use it is to impact the
shape of history.
I agree there is also a set of people coming from the centralized vcs
world who want to keep a linear history.
Yeah, and based on the evidence, one set of people is much much larger
than the other; the people that care what the history look like.
Either way, we can start by making it a warning, and then an error,
and if more people complain that they have to do 'git pull --merge'
now (I bet there won't be any), then you would be right, and we
revert. No problem.
--
Felipe Contreras
From: Jeff King <hidden> Date: 2016-06-15 22:58:40
On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:
quoted
It's not if you understand the difference between merge-then-commit and
commit-then-merge. But for a clueless user who has been told "replace
svn commit" with "git commit && git push" and replace "svn update" with
"git pull", it is quite similar.
Well, yeah, but if they are so clueless they have to be told what to
do, they can be told to do 'git pull --merge' instead, no?
I think it's fine to tell them to do "git pull --merge". What I'd worry
more about is somebody who is suddenly presented with the choice between
"--rebase" and "--merge" and doesn't know which to choose. We've created a
cognitive load on the user, and even more load if they choose --rebase
and don't quite understand what it means.
The current warning message in jc/pull-training-wheel is quite neutral
between the two options. Perhaps we should lean more towards merging?
I guess that works against John's case, though, which is clueless people
working on a project that _does_ care about the shape of history. At
least they would have to stop and think for a moment, though, which
might help (and maybe convince them to ask more clueful project
members). I don't know.
-Peff
From: Felipe Contreras <hidden> Date: 2016-06-15 22:58:40
On Sun, Sep 8, 2013 at 12:21 AM, Jeff King [off-list ref] wrote:
On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:
quoted
quoted
It's not if you understand the difference between merge-then-commit and
commit-then-merge. But for a clueless user who has been told "replace
svn commit" with "git commit && git push" and replace "svn update" with
"git pull", it is quite similar.
Well, yeah, but if they are so clueless they have to be told what to
do, they can be told to do 'git pull --merge' instead, no?
I think it's fine to tell them to do "git pull --merge". What I'd worry
more about is somebody who is suddenly presented with the choice between
"--rebase" and "--merge" and doesn't know which to choose. We've created a
cognitive load on the user, and even more load if they choose --rebase
and don't quite understand what it means.
If that happens they will go back to the guy that told them to run
those commands.
Fortunately there probably are very few of these users.
The current warning message in jc/pull-training-wheel is quite neutral
between the two options. Perhaps we should lean more towards merging?
I don't like that message. I would like this for the deprecation period:
"The pull was not fast-forward, in the future you would have to choose
a merge or a rebase, merging automatically for now. Read 'man git
pull' for more help."
Then when obsolete:
The pull was not fast-forward, please either merge or rebase.
"Any more babysitting with essay long messages is counter-productive
to the vast majority of Git users."
I guess that works against John's case, though, which is clueless people
working on a project that _does_ care about the shape of history. At
least they would have to stop and think for a moment, though, which
might help (and maybe convince them to ask more clueful project
members). I don't know.
Or google 'git pull' 'git merge' 'git rebase' or 'git non-fast-forward'.
--
Felipe Contreras
From: Jeff King <hidden> Date: 2016-06-15 22:58:40
On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote:
quoted
I think it's fine to tell them to do "git pull --merge". What I'd worry
more about is somebody who is suddenly presented with the choice between
"--rebase" and "--merge" and doesn't know which to choose. We've created a
cognitive load on the user, and even more load if they choose --rebase
and don't quite understand what it means.
If that happens they will go back to the guy that told them to run
those commands.
I think "the guy" may be git itself. For example, here is a possible
session with jc/pull-training-wheel:
$ git push
To ...
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to '...'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
$ git pull
The pull does not fast-forward; please specify
if you want to merge or rebase.
Use either
git pull --rebase
git pull --merge
You can also use 'git config pull.rebase true' (if you want --rebase) or
'git config pull.rebase false' (if you want --merge) to set this once for
this project and forget about it.
The user is pointed at "pull" from "push", and then gets presented with
the "merge or rebase" choice. It may be that the advice you can find by
googling "merge vs rebase" is enough to then help the person along
(and/or we may need to improve the manpages in that respect).
I am genuinely curious what people in favor of this feature would want
to say in the documentation to a user encountering this choice for the
first time. In my experience, rebasing introduces more complications,
specifically:
1. the merge is "backwards" with respect to ours/theirs
2. you may end up with difficult conflict resolution due to repeated
changes over the same section of code. E.g., you write some buggy
code and then fix it, but upstream has changed the same area.
Rebasing involves first resolving your buggy version with the
upstream code, and then resolving the fix on top of the previous
resolution.
3. rewriting of commits found in other branches, which then need
rebased on top of the branch you just rebased
4. a previously bug-free commit can show a bug after the rebase if
other parts of the project changed (whereas with a merge, the bug
would be attributable to the merge)
I know those are all balanced by some advantages of rebasing, but I also
think they are things that can be troublesome for a user who does not
fully grok the rebase process. I'm just wondering if we should mention
both, but steer people towards merging as the safer alternative (you
might have ugly history, but you are less likely to create a mess with
duplicate commits or badly-resolved conflicts).
Fortunately there probably are very few of these users.
Maybe. I am not sure how one would measure.
If you are interested, I can ask the opinion of some of the GitHub
trainers. They see a lot of new users and have a sense of what kinds of
confusion come up most frequently, what kinds of workflows they tend to
see, etc. Their experience may be biased towards corporate-ish users,
though, because those are the people who pay for training.
quoted
The current warning message in jc/pull-training-wheel is quite neutral
between the two options. Perhaps we should lean more towards merging?
I don't like that message. I would like this for the deprecation period:
"The pull was not fast-forward, in the future you would have to choose
a merge or a rebase, merging automatically for now. Read 'man git
pull' for more help."
Then when obsolete:
The pull was not fast-forward, please either merge or rebase.
A deprecation message helps people who are making the transition from an
older behavior to a newer one. It cannot help new users who start with a
git version after the deprecation period.
"Any more babysitting with essay long messages is counter-productive
to the vast majority of Git users."
From: Felipe Contreras <hidden> Date: 2016-06-15 22:58:40
On Sun, Sep 8, 2013 at 1:54 AM, Jeff King [off-list ref] wrote:
On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote:
quoted
quoted
I think it's fine to tell them to do "git pull --merge". What I'd worry
more about is somebody who is suddenly presented with the choice between
"--rebase" and "--merge" and doesn't know which to choose. We've created a
cognitive load on the user, and even more load if they choose --rebase
and don't quite understand what it means.
If that happens they will go back to the guy that told them to run
those commands.
I think "the guy" may be git itself. For example, here is a possible
session with jc/pull-training-wheel:
$ git push
Who told him to use 'git push'? Certainly not git.
To ...
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to '...'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
$ git pull
The pull does not fast-forward; please specify
if you want to merge or rebase.
Use either
git pull --rebase
git pull --merge
You can also use 'git config pull.rebase true' (if you want --rebase) or
'git config pull.rebase false' (if you want --merge) to set this once for
this project and forget about it.
Why stop there? Post the whole man page already.
Moreover, it's overly verbose on all the wrong and irrelevant
information. If you are going to waste precious screen state, explain
wth a "non fast-forward" is; people can figure out what a merge is,
and maybe a rebase, but a "non fast-forward" definitely not.
The user is pointed at "pull" from "push", and then gets presented with
the "merge or rebase" choice. It may be that the advice you can find by
googling "merge vs rebase" is enough to then help the person along
(and/or we may need to improve the manpages in that respect).
Yes, but that's not the use-case we are talking about. You mentioned
specifically a "svn-like" worfklow where the guy was told by somebody
else to replace the svn commands with git ones.
If we are talking about a guy that is learning git, that's and
entirely different case.
I am genuinely curious what people in favor of this feature would want
to say in the documentation to a user encountering this choice for the
first time. In my experience, rebasing introduces more complications,
specifically:
Yes, but it's what the user might want.
I know those are all balanced by some advantages of rebasing, but I also
think they are things that can be troublesome for a user who does not
fully grok the rebase process. I'm just wondering if we should mention
both, but steer people towards merging as the safer alternative (you
might have ugly history, but you are less likely to create a mess with
duplicate commits or badly-resolved conflicts).
The purpose of this change in the code is not to change the user
behavior. The choice of merge vs. rebase is entirely up to the user,
and we are not changing that.
The purpose of this change is to avoid doing a merge when the user
wanted a rebase, or maybe something more complicated. So a rebase
being complicated is not an issue, because we know that's what the
user wants, that's the whole reason we are trying to avoid the
automated merge.
quoted
Fortunately there probably are very few of these users.
Maybe. I am not sure how one would measure.
If you are interested, I can ask the opinion of some of the GitHub
trainers. They see a lot of new users and have a sense of what kinds of
confusion come up most frequently, what kinds of workflows they tend to
see, etc. Their experience may be biased towards corporate-ish users,
though, because those are the people who pay for training.
Ask. I'm sure they will tell you doing merges by mistake with 'git
pull' is an issue.
quoted
quoted
The current warning message in jc/pull-training-wheel is quite neutral
between the two options. Perhaps we should lean more towards merging?
I don't like that message. I would like this for the deprecation period:
"The pull was not fast-forward, in the future you would have to choose
a merge or a rebase, merging automatically for now. Read 'man git
pull' for more help."
Then when obsolete:
The pull was not fast-forward, please either merge or rebase.
A deprecation message helps people who are making the transition from an
older behavior to a newer one. It cannot help new users who start with a
git version after the deprecation period.
The new users are told to either merge or rebase, if they don't know
what that means, they will go on look it up, just like they looked up
the 'git pull' command in the first place.
quoted
"Any more babysitting with essay long messages is counter-productive
to the vast majority of Git users."
I think that is what we have advice.* for.
I don't understand what that means.
--
Felipe Contreras
From: Jeff King <hidden> Date: 2016-06-15 22:58:40
On Sun, Sep 08, 2013 at 02:15:17AM -0500, Felipe Contreras wrote:
quoted
I think "the guy" may be git itself. For example, here is a possible
session with jc/pull-training-wheel:
$ git push
Who told him to use 'git push'? Certainly not git.
Any of the hundreds of existing tutorials that teach basic git commands
like "push"?
quoted
To ...
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to '...'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
[...]
Why stop there? Post the whole man page already.
Moreover, it's overly verbose on all the wrong and irrelevant
information. If you are going to waste precious screen state, explain
wth a "non fast-forward" is; people can figure out what a merge is,
and maybe a rebase, but a "non fast-forward" definitely not.
Note that I was not trying to defend any of the messages, but only
showing a plausible mechanism by which a user with basic knowledge that
he wants to push may arrive at the question "what is the difference
between merge and rebase?".
If you want to suggest revisions for the push message, go ahead. The
push advice _is_ an attempt to define non-fast-forwards in plain
language without taking up too much space, but perhaps you can do
better. You could even suggest omitting it entirely, but I'm not sure if
that is a good idea. It was not added in a vacuum; we lacked that advice
for many years, and people complained about it quite a bit until it was
added.
quoted
The user is pointed at "pull" from "push", and then gets presented with
the "merge or rebase" choice. It may be that the advice you can find by
googling "merge vs rebase" is enough to then help the person along
(and/or we may need to improve the manpages in that respect).
Yes, but that's not the use-case we are talking about. You mentioned
specifically a "svn-like" worfklow where the guy was told by somebody
else to replace the svn commands with git ones.
No, I mentioned an "svn-like" workflow. I didn't say anything about how
they were told. They might have been told by a co-worker, or read a
brief tutorial on git, or read something like "Git-SVN Crash Course".
If we are talking about a guy that is learning git, that's and
entirely different case.
That is certainly what I meant to be talking about.
The purpose of this change in the code is not to change the user
behavior. The choice of merge vs. rebase is entirely up to the user,
and we are not changing that.
Right, but by not doing anything by default, you are forcing the user to
make a decision. Right now, we strongly encourage merging by making it
the default, and you have to learn about rebasing separately. But a
message that mentions them both as equals is going to lead to extra work
for the user; they have to figure out which one is most appropriate. My
concern is that this is non-trivial for new users, and that they may end
up arbitrarily picking rebase, which is probably not doing them any
favors if they do not understand it.
For clueful users, choosing between the two is not hard. But some people
seem to have trouble understanding the DAG. I don't know how large a
group that is, and how any pain caused by this change might compare to
the times it will help.
quoted
If you are interested, I can ask the opinion of some of the GitHub
trainers. They see a lot of new users and have a sense of what kinds of
confusion come up most frequently, what kinds of workflows they tend to
see, etc. Their experience may be biased towards corporate-ish users,
though, because those are the people who pay for training.
Ask. I'm sure they will tell you doing merges by mistake with 'git
pull' is an issue.
I've sent an email. I'll post the response when I get it.
quoted
quoted
"Any more babysitting with essay long messages is counter-productive
to the vast majority of Git users."
I think that is what we have advice.* for.
I don't understand what that means.
It means that some time ago, after many people complained that git did
not give enough hints, we added many hints. Some people who did not need
these hints would want to disable them, and we have the "advice.*"
config options to do so. So we can have a longer message for new users,
and a shorter one for people who do not want to be bothered with the
long advice.
-Peff
From: Felipe Contreras <hidden> Date: 2016-06-15 22:58:40
On Sun, Sep 8, 2013 at 2:50 AM, Jeff King [off-list ref] wrote:
On Sun, Sep 08, 2013 at 02:15:17AM -0500, Felipe Contreras wrote:
quoted
quoted
I think "the guy" may be git itself. For example, here is a possible
session with jc/pull-training-wheel:
$ git push
Who told him to use 'git push'? Certainly not git.
Any of the hundreds of existing tutorials that teach basic git commands
like "push"?
You can't use a tutorial out there that just tells you to replace svn
commands with git alternatives, go to work and mess up the repository
history.
I'm trying to take the point of view of your hypothetical user working
on a repository where history is not important, but it seems more and
more than this person is just not real. If it's OK to push crappy
merges, somebody must have told him that was OK and provided him with
the commands.
If it's just some random person that read some random tutorial from
'svn' -> 'git' working on a random repository that happens to accept
merges all over the place. Well I think that's a very very exceptional
situation.
And this person still wouldn't have a problem finding another tutorial
explaining what a merge is.
quoted
quoted
To ...
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to '...'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
[...]
Why stop there? Post the whole man page already.
Moreover, it's overly verbose on all the wrong and irrelevant
information. If you are going to waste precious screen state, explain
wth a "non fast-forward" is; people can figure out what a merge is,
and maybe a rebase, but a "non fast-forward" definitely not.
Note that I was not trying to defend any of the messages, but only
showing a plausible mechanism by which a user with basic knowledge that
he wants to push may arrive at the question "what is the difference
between merge and rebase?".
If you want to suggest revisions for the push message, go ahead. The
push advice _is_ an attempt to define non-fast-forwards in plain
language without taking up too much space, but perhaps you can do
better.
I definitely can, but you would disagree.
But anyway, you are relying on the user having pushed first, what if
he is pulling first, or what if he doesn't have write access and is
only pulling?
You could even suggest omitting it entirely, but I'm not sure if
that is a good idea. It was not added in a vacuum; we lacked that advice
for many years, and people complained about it quite a bit until it was
added.
I would have to see the evidence, as I have never seen any complaints
about that. The complains are about the UI, and they still remain.
quoted
quoted
The user is pointed at "pull" from "push", and then gets presented with
the "merge or rebase" choice. It may be that the advice you can find by
googling "merge vs rebase" is enough to then help the person along
(and/or we may need to improve the manpages in that respect).
Yes, but that's not the use-case we are talking about. You mentioned
specifically a "svn-like" worfklow where the guy was told by somebody
else to replace the svn commands with git ones.
No, I mentioned an "svn-like" workflow. I didn't say anything about how
they were told. They might have been told by a co-worker, or read a
brief tutorial on git, or read something like "Git-SVN Crash Course".
Once again, this doesn't make any sense. People can't just push crap
merges to any repository.
quoted
If we are talking about a guy that is learning git, that's and
entirely different case.
That is certainly what I meant to be talking about.
If he is learning Git, then he will be looking for the meaning of a
merge and a rebase. The fact that the repository accepts crappy merges
wouldn't be relevant.
quoted
The purpose of this change in the code is not to change the user
behavior. The choice of merge vs. rebase is entirely up to the user,
and we are not changing that.
Right, but by not doing anything by default, you are forcing the user to
make a decision.
No, it would be a warning first, he wouldn't be *forced* to make a
decision, only after the deprecation period is over.
Then yes, if by then he hasn't learned that what he wants is a merge,
he would be forced to learn it.
Right now, we strongly encourage merging by making it
the default, and you have to learn about rebasing separately. But a
message that mentions them both as equals is going to lead to extra work
for the user; they have to figure out which one is most appropriate.
No, they don't need to figure out which is most appropriate, they only
need to figure out they have been doing merges all along.
My warning message achieves precisely that:
"The pull was not fast-forward, in the future you would have to choose
a merge or a rebase, merging automatically for now. For more
information read 'git
pull --help'."
The part "merging automatically for now". This teaches the user that
'git pull' is doing a merge, so by the time 'git pull' errors out, he
knows he wants a merge, all he needs to figure out is how to do it,
and 'git pull --help' would tell him that. Perhaps adding a "(git pull
--merge)" to the deprecation warning would help, but I still don't see
the need in the final error.
Once again, nobody is forcing anybody to change their workflows.
My
concern is that this is non-trivial for new users, and that they may end
up arbitrarily picking rebase, which is probably not doing them any
favors if they do not understand it.
Why would they pick a rebase? If git tells them 'git pull' is doing a
merge for months, why would they choose to do something different?
For clueful users, choosing between the two is not hard. But some people
seem to have trouble understanding the DAG. I don't know how large a
group that is, and how any pain caused by this change might compare to
the times it will help.
They don't need to learn what's more appropriate, they can keep doing
what they have been doing.
quoted
quoted
If you are interested, I can ask the opinion of some of the GitHub
trainers. They see a lot of new users and have a sense of what kinds of
confusion come up most frequently, what kinds of workflows they tend to
see, etc. Their experience may be biased towards corporate-ish users,
though, because those are the people who pay for training.
Ask. I'm sure they will tell you doing merges by mistake with 'git
pull' is an issue.
I've sent an email. I'll post the response when I get it.
quoted
quoted
quoted
"Any more babysitting with essay long messages is counter-productive
to the vast majority of Git users."
I think that is what we have advice.* for.
I don't understand what that means.
It means that some time ago, after many people complained that git did
not give enough hints, we added many hints. Some people who did not need
these hints would want to disable them, and we have the "advice.*"
config options to do so. So we can have a longer message for new users,
and a shorter one for people who do not want to be bothered with the
long advice.
I don't see Junio's proposal being affected by this advice thing.
And I have used and contributed to Git for many years, used it since
day one, and this is the first time I hear about it. I doubt even a
tiny fraction of Git users know about it. Where is the documentation
about that?
--
Felipe Contreras
From: John Keeping <hidden> Date: 2016-06-15 22:58:41
On Sun, Sep 08, 2013 at 02:54:20AM -0400, Jeff King wrote:
I am genuinely curious what people in favor of this feature would want
to say in the documentation to a user encountering this choice for the
first time. In my experience, rebasing introduces more complications,
specifically:
1. the merge is "backwards" with respect to ours/theirs
2. you may end up with difficult conflict resolution due to repeated
changes over the same section of code. E.g., you write some buggy
code and then fix it, but upstream has changed the same area.
Rebasing involves first resolving your buggy version with the
upstream code, and then resolving the fix on top of the previous
resolution.
3. rewriting of commits found in other branches, which then need
rebased on top of the branch you just rebased
4. a previously bug-free commit can show a bug after the rebase if
other parts of the project changed (whereas with a merge, the bug
would be attributable to the merge)
I know those are all balanced by some advantages of rebasing, but I also
think they are things that can be troublesome for a user who does not
fully grok the rebase process. I'm just wondering if we should mention
both, but steer people towards merging as the safer alternative (you
might have ugly history, but you are less likely to create a mess with
duplicate commits or badly-resolved conflicts).
The really correct thing to do here is to encourage a feature branch
workflow, but in my experience people are happier to walk through a
rebase than to switch over to feature branches completely.
An alternative pull mode would be:
git reset --keep @{u} &&
git merge @{-1}
which gets a sensible history shape without any of your disadvantages
above. But that didn't go anywhere last time it came up [1] [2].
[1] http://article.gmane.org/gmane.comp.version-control.git/210246
[2] http://article.gmane.org/gmane.comp.version-control.git/210625
quoted
Fortunately there probably are very few of these users.
Maybe. I am not sure how one would measure.
If you are interested, I can ask the opinion of some of the GitHub
trainers. They see a lot of new users and have a sense of what kinds of
confusion come up most frequently, what kinds of workflows they tend to
see, etc. Their experience may be biased towards corporate-ish users,
though, because those are the people who pay for training.
I expect corporate environments are the ones in which this is relevant.
Open source projects that care about the shape of history can have one
person able to write to the central repository who can enforce the
policy they want. This tends to be more difficult in a corporate
environment, particularly one that was previously using a centralised
VCS.
From: brian m. carlson <hidden> Date: 2016-06-15 22:58:41
On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
On Sat, Sep 7, 2013 at 11:18 PM, Jeff King [off-list ref] wrote:
quoted
By "svn-like", I mean the people whose workflow is:
$ hack hack hack
$ git commit
$ git push ;# oops, somebody else pushed in the meantime
$ git pull
$ git push
It's possible that some teams at work may be using this workflow. It's
more likely that there would be a rebase if the push failed, but some
teams might do a merge. I don't know because we don't dictate workflow
to individual teams for the reasons I get into below. Regardless,
merges are our typical workflow, so forcing rebase mode all the time
wouldn't be appropriate for us.
quoted
$ hack hack hack
$ svn commit ;# oops, somebody else committed in the meantime
$ svn update
$ svn commit
Those people would now have to learn enough to choose between merge and
rebase when running the "git pull".
But that's only if they don't care about the shape of history. In my
experience the people that cling more to centralized VCS do not like
merges, so they rebase everything to make it a straight line. That is
much more "svn-like".
So chances are they are already doing 'git pull --rebase' (or
similar), so their workflow wouldn't be affected.
We end up squashing each project branch into one commit (usually using
git reset --soft), so we don't care about the shape of history. Over
the course of a project branch, in fact, there may be many merges from
the main release branches (including other projects), so history is
going to be very messy otherwise.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
From: Felipe Contreras <hidden> Date: 2016-06-15 22:58:41
On Sun, Sep 8, 2013 at 12:26 PM, brian m. carlson
[off-list ref] wrote:
On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
quoted
On Sat, Sep 7, 2013 at 11:18 PM, Jeff King [off-list ref] wrote:
quoted
quoted
$ hack hack hack
$ svn commit ;# oops, somebody else committed in the meantime
$ svn update
$ svn commit
Those people would now have to learn enough to choose between merge and
rebase when running the "git pull".
But that's only if they don't care about the shape of history. In my
experience the people that cling more to centralized VCS do not like
merges, so they rebase everything to make it a straight line. That is
much more "svn-like".
So chances are they are already doing 'git pull --rebase' (or
similar), so their workflow wouldn't be affected.
We end up squashing each project branch into one commit (usually using
git reset --soft), so we don't care about the shape of history. Over
the course of a project branch, in fact, there may be many merges from
the main release branches (including other projects), so history is
going to be very messy otherwise.
Yeah, but the key question at hand in this discussion is; what happens
when 'git pull' stops working for them, and they don't know what to
do, will they choose 'git pull --rebase' by mistake?
I say the answer is no, because:
1) As you say in your scenario, somebody is telling these guys what to
do, so when 'git pull' fails, somebody will figure out that they were
doing a merge, so 'git pull --merge' is what they want to type from
now on.
2) Git itself would be warning them for months that a 'non
fast-forward was found, and a merge will be done for them', so when
the warning turns to an error, they'll know they want a merge, so
they'll do 'git pull --merge', either because the warning told them
that's git was doing all along, or because they figured that out by
googling, or reading the man page, or whatever.
Either way, it would not be a big deal for these people, their
user-experience wouldn't be totally broken by this proposed change,
and that is the important conclusion.
--
Felipe Contreras
From: brian m. carlson <hidden> Date: 2016-06-15 22:58:41
On Sun, Sep 08, 2013 at 05:38:50PM -0500, Felipe Contreras wrote:
Yeah, but the key question at hand in this discussion is; what happens
when 'git pull' stops working for them, and they don't know what to
do, will they choose 'git pull --rebase' by mistake?
I agree, they will not choose git pull --rebase by mistake.
I say the answer is no, because:
1) As you say in your scenario, somebody is telling these guys what to
do, so when 'git pull' fails, somebody will figure out that they were
doing a merge, so 'git pull --merge' is what they want to type from
now on.
Yes, that would be me. My hesitance here is that as the one usually
driving git updates (which so far have happened once a year), I will end
up retraining forty developers. I don't think the current behavior is
broken or really problematic at all: merging has always been the
default, and people have come to expect that. People using workflows
that don't want merge have always either needed to set a configuration
option or use --rebase. As the man page says, --rebase is unsafe, and
that's why it's not the default.
I would be much less unhappy with your earlier change that did not
affect uses with arguments. That would limit the number of use cases
affected.
2) Git itself would be warning them for months that a 'non
fast-forward was found, and a merge will be done for them', so when
the warning turns to an error, they'll know they want a merge, so
they'll do 'git pull --merge', either because the warning told them
that's git was doing all along, or because they figured that out by
googling, or reading the man page, or whatever.
Again, you assume that git updates happen on a regular basis, and you
assume that most developers really know what happens under the hood.
I don't see a warning now; in fact, I see:
vauxhall ok % git status
# On branch master
# Your branch and 'upstream/master' have diverged,
# and have 1 and 128 different commits each, respectively.
# (use "git pull" to merge the remote branch into yours)
#
The current behavior of git is to explicitly encourage this behavior,
and now you want to make it not work. I think this change is a bad
idea, and I think the number of changes required to the test suite
indicates that. If there's going to be a change here, it should have a
deprecation period with the above message changed and appropriate
warnings, not a flag day; your patches don't do that.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
From: Felipe Contreras <hidden> Date: 2016-06-15 22:58:41
On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson
[off-list ref] wrote:
On Sun, Sep 08, 2013 at 05:38:50PM -0500, Felipe Contreras wrote:
quoted
Yeah, but the key question at hand in this discussion is; what happens
when 'git pull' stops working for them, and they don't know what to
do, will they choose 'git pull --rebase' by mistake?
I agree, they will not choose git pull --rebase by mistake.
quoted
I say the answer is no, because:
1) As you say in your scenario, somebody is telling these guys what to
do, so when 'git pull' fails, somebody will figure out that they were
doing a merge, so 'git pull --merge' is what they want to type from
now on.
Yes, that would be me. My hesitance here is that as the one usually
driving git updates (which so far have happened once a year), I will end
up retraining forty developers. I don't think the current behavior is
broken or really problematic at all: merging has always been the
default, and people have come to expect that.
It may not be broken for you, but it is for other people. Would you be
so egocentric as to ignore everybody else because "it works for you"?
People using workflows
that don't want merge have always either needed to set a configuration
option or use --rebase. As the man page says, --rebase is unsafe, and
that's why it's not the default.
Yes, but the problem is that people using other workflows end up
avoiding 'git pull' at all, so at the end of the day we have one core
command that the majority of users avoid, that's not good.
I would be much less unhappy with your earlier change that did not
affect uses with arguments. That would limit the number of use cases
affected.
I have no problem with:
git pull $remote $branch
Allowing non-fast-forward merges.
And:
git pull $remote
git pull
Not allowing them by default.
But the problem is that it's not easy to implement.
Either way, I'll venture that you don't want 'git pull $remote' to
change, so it would be a waste of the time to try to get the above to
work.
quoted
2) Git itself would be warning them for months that a 'non
fast-forward was found, and a merge will be done for them', so when
the warning turns to an error, they'll know they want a merge, so
they'll do 'git pull --merge', either because the warning told them
that's git was doing all along, or because they figured that out by
googling, or reading the man page, or whatever.
Again, you assume that git updates happen on a regular basis, and you
assume that most developers really know what happens under the hood.
No. The developers don't have to know what happens under the hood, Git
would be telling them "WARNING: we are doing a merge", what else is
the developer to think, but that 'git pull' is doing a merge?
As for the updates, yes, I assume updates happen at least each three
months. If your company updates each year, I don't see what much more
we can do to you help you. Doing a single change per year is certainly
going to hold the project back.
Fortunately this was only point 2), there's still point 1); you can
tell them to use 'git pull --merge' from now on, and since you update
once every year, you can do it while you give the training for the
year.
Or there's another option:
3) Distribute Git in your company with /etc/gitconfig having pull.mode
= merge. This way nothing will change.
I think we are being very accommodating to your company's use-case
which is very far from the norm. Even in the absolute worst case
scenario, you would have to tell people to use 'git pull --merge'
instead, is that really so horrible? Should we really halt Git's
progress because you would have to tell people to type nine extra
characters or run one configuration command?
I don't see a warning now; in fact, I see:
vauxhall ok % git status
# On branch master
# Your branch and 'upstream/master' have diverged,
# and have 1 and 128 different commits each, respectively.
# (use "git pull" to merge the remote branch into yours)
#
The current behavior of git is to explicitly encourage this behavior,
and now you want to make it not work.
Yes, that's why it's a change.
I think this change is a bad
idea, and I think the number of changes required to the test suite
indicates that. If there's going to be a change here, it should have a
deprecation period with the above message changed and appropriate
warnings, not a flag day; your patches don't do that.
My patches pretty much do nothing else but introduce a warning.
Nothing is broken, nothing is changed in the test suite:
http://article.gmane.org/gmane.comp.version-control.git/233669
You are confusing my proposal with Junio's one.
Also, my proposal was to enable this behavior (pull.mode =
merge-ff-only) only for Git v2.0, which might happen probably way
later than a year from now, so you your users might actually see the
warning after all. But yeah, that's _my_ proposal.
--
Felipe Contreras
Actually my mistake. My patches don't even add a warning, so nothing
is changed at all (unless you manually configure pull.mode =
merge-ff-only).
I only suggested to add the warning, but didn't actually implement it.
I'll do that soon.
--
Felipe Contreras
Actually my mistake. My patches don't even add a warning, so nothing
is changed at all (unless you manually configure pull.mode =
merge-ff-only).
I only suggested to add the warning, but didn't actually implement it.
I'll do that soon.
I still wouldn't be crazy about the change, but if there's a warning, I
could live with it. I think that's probably the best course of action
if there's going to be a change here.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
From: Jeff King <hidden> Date: 2016-06-15 22:58:42
On Sun, Sep 08, 2013 at 11:03:52AM +0100, John Keeping wrote:
quoted
I know those are all balanced by some advantages of rebasing, but I also
think they are things that can be troublesome for a user who does not
fully grok the rebase process. I'm just wondering if we should mention
both, but steer people towards merging as the safer alternative (you
might have ugly history, but you are less likely to create a mess with
duplicate commits or badly-resolved conflicts).
The really correct thing to do here is to encourage a feature branch
workflow, but in my experience people are happier to walk through a
rebase than to switch over to feature branches completely.
An alternative pull mode would be:
git reset --keep @{u} &&
git merge @{-1}
which gets a sensible history shape without any of your disadvantages
above. But that didn't go anywhere last time it came up [1] [2].
FWIW, that approach makes some sense to me. De-coupling for a moment the
idea of "what is the default" from "what are the options", it seems like
doing a reverse-merge would be a good option to have in the toolbox.
It would also have other uses beyond "git pull". For example, in
development of GitHub itself, we use topic branches. But before merging
them to master, we often test-deploy the topic to the live site. Before
doing so, you have to merge the topic with the latest master to make
sure you are not un-deploying anybody else's recently graduated topics.
You can do so by creating a temporary merge branch and deploying that,
or you can simply merge master back into the topic. We generally choose
the latter, because it leaves any conflict resolution in an obvious
place (and doesn't need repeating).
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:58:42
On Sun, Sep 08, 2013 at 03:50:46AM -0400, Jeff King wrote:
quoted
quoted
If you are interested, I can ask the opinion of some of the GitHub
trainers. They see a lot of new users and have a sense of what kinds of
confusion come up most frequently, what kinds of workflows they tend to
see, etc. Their experience may be biased towards corporate-ish users,
though, because those are the people who pay for training.
Ask. I'm sure they will tell you doing merges by mistake with 'git
pull' is an issue.
I've sent an email. I'll post the response when I get it.
Here is what I sent them (I am leaving both my mail and theirs unedited
to avoid any "telephone"-like confusion in trying to summarize):
Right now, running "git pull" will always create a merge, unless
the user has specifically configured it to perform a rebase.
Some people find this problematic, because the project may care
about the order of merges (e.g., so that --first-parent
traversals do the right thing), and some users may accidentally
do "backwards" merges from a main branch into a topic (either
because they are clueless, or because they simply forgot).
There is a proposal being considered to have "git pull" do
nothing by default, but instead ask the user to specify whether
to merge or rebase (with the option of setting a config value if
you want it to do one by default).
One concern I have is that new users may run across this
relatively early. For example, the first time they "git push"
and get a non-fast-forward because somebody else has already
pushed, git suggests to run "git pull". At which point they will
have to decide whether to merge or rebase. So what I'd like your
opinions on is:
1. Do new users have trouble with the concept of rebase vs
merge? How would they handle this change of behavior?
2. Do new users have trouble with rebases in general? There
are some complications over doing a normal merge, but I
don't know how often they trip people up in practice.
And the responses I got were:
1. New users definitely have trouble distinguishing between
rebase and merge. Even people who have been using Git for a
while on a basic level are sometimes confused by this.
2. Most people we teach—even the ones who have been using Git
for a while—don't know what a rebase is at all. They've heard of
it, but they don't get it. It takes careful explanation to get
the concept across and explain why it is not the same thing as a
merge.
Speaking for myself, about half of the time in the Foundations
class I'll explain `pull --rebase` and `branch.autosetuprebase`.
(Whether we get to it depends on class interest and ability.)
When we do address that topic, we always recommend that
rebase-on-pull is the right thing to do, since the merges Git
creates are just noise that makes history hard to work with in
the ways you have pointed out. (For smart classes, I like to
make the analogy of Git to a distributed database, and point out
how the merge on pull is just Git's mechanism for resolving
split-brain writes. I explain that those merges aren't a
deficiency in Git; they're just what has to happen by default.
The fact that Git handles split-brain writes so well by itself
is amazing.)
My input would be to continue to have `pull` merge by default.
Those merges aren't great, but new users won't have any idea how
to make a decision about them at that point. As it is, it just
works, and it works quite elegantly. Once you start to learn
some things, you can tune Git up to work even more elegantly by
rebasing, but having to understand that concept and make a
decision on your first (or second or third or twentieth) pull is
probably asking too much.
and:
Just a few more elements to add:
* I have been teaching rebase and what it means in _some_ of my
Git Foundations classes as of late. But "some" means there are
a majority that do not get it.
* These are the people that get "formal" training on Git. What
about all the newbies? They really won't have a foundation for
what these two "flavors" mean.
* The merge is very different from what Subversion presents as a
default. That's a possible point in the "option's favor."
* In the end though, the "simplest thing that works" should be
the default without a choice. To me, a choice implies knowledge
of the benefits of each option. I would say that the majority
of our Git students do not, at the beginning of Git usage,
understand the difference.
I did not specifically ask in the original about whether backwards
merges were a problem, though I think that is touched on in the
responses.
If you'd like me to ask something specifically, I can relay the
question, or I can ask them to come join the discussion here.
-Peff
From: Felipe Contreras <hidden> Date: 2016-06-15 22:58:42
On Mon, Sep 9, 2013 at 3:17 PM, Jeff King [off-list ref] wrote:
On Sun, Sep 08, 2013 at 03:50:46AM -0400, Jeff King wrote:
quoted
quoted
quoted
If you are interested, I can ask the opinion of some of the GitHub
trainers. They see a lot of new users and have a sense of what kinds of
confusion come up most frequently, what kinds of workflows they tend to
see, etc. Their experience may be biased towards corporate-ish users,
though, because those are the people who pay for training.
Ask. I'm sure they will tell you doing merges by mistake with 'git
pull' is an issue.
I've sent an email. I'll post the response when I get it.
Here is what I sent them (I am leaving both my mail and theirs unedited
to avoid any "telephone"-like confusion in trying to summarize):
Right now, running "git pull" will always create a merge, unless
the user has specifically configured it to perform a rebase.
Some people find this problematic, because the project may care
about the order of merges (e.g., so that --first-parent
traversals do the right thing), and some users may accidentally
do "backwards" merges from a main branch into a topic (either
because they are clueless, or because they simply forgot).
There is a proposal being considered to have "git pull" do
nothing by default, but instead ask the user to specify whether
to merge or rebase (with the option of setting a config value if
you want it to do one by default).
One concern I have is that new users may run across this
relatively early. For example, the first time they "git push"
and get a non-fast-forward because somebody else has already
pushed, git suggests to run "git pull". At which point they will
have to decide whether to merge or rebase. So what I'd like your
opinions on is:
1. Do new users have trouble with the concept of rebase vs
merge? How would they handle this change of behavior?
2. Do new users have trouble with rebases in general? There
are some complications over doing a normal merge, but I
don't know how often they trip people up in practice.
And the responses I got were:
1. New users definitely have trouble distinguishing between
rebase and merge. Even people who have been using Git for a
while on a basic level are sometimes confused by this.
2. Most people we teach—even the ones who have been using Git
for a while—don't know what a rebase is at all. They've heard of
it, but they don't get it. It takes careful explanation to get
the concept across and explain why it is not the same thing as a
merge.
Speaking for myself, about half of the time in the Foundations
class I'll explain `pull --rebase` and `branch.autosetuprebase`.
(Whether we get to it depends on class interest and ability.)
When we do address that topic, we always recommend that
rebase-on-pull is the right thing to do, since the merges Git
creates are just noise that makes history hard to work with in
the ways you have pointed out. (For smart classes, I like to
make the analogy of Git to a distributed database, and point out
how the merge on pull is just Git's mechanism for resolving
split-brain writes. I explain that those merges aren't a
deficiency in Git; they're just what has to happen by default.
The fact that Git handles split-brain writes so well by itself
is amazing.)
My input would be to continue to have `pull` merge by default.
Those merges aren't great, but new users won't have any idea how
to make a decision about them at that point. As it is, it just
works, and it works quite elegantly. Once you start to learn
some things, you can tune Git up to work even more elegantly by
rebasing, but having to understand that concept and make a
decision on your first (or second or third or twentieth) pull is
probably asking too much.
and:
Just a few more elements to add:
* I have been teaching rebase and what it means in _some_ of my
Git Foundations classes as of late. But "some" means there are
a majority that do not get it.
* These are the people that get "formal" training on Git. What
about all the newbies? They really won't have a foundation for
what these two "flavors" mean.
* The merge is very different from what Subversion presents as a
default. That's a possible point in the "option's favor."
* In the end though, the "simplest thing that works" should be
the default without a choice. To me, a choice implies knowledge
of the benefits of each option. I would say that the majority
of our Git students do not, at the beginning of Git usage,
understand the difference.
Wall these concerns can be tackled with an error message that says:
"The pull was not fast-forward, please either merge or rebase. If
unsure, run 'git pull --merge'."
--
Felipe Contreras