John Keeping [off-list ref] writes:
I have to wonder how often "git pull" with no arguments actually does
what users really want (even if they don't know it!) when it doesn't
result in a fast-forward (and pull.rebase isn't configured).
If you are in a totally centralized shared repository mindset
without using topic branch workflow, --first-parent would not help
you. In your history the second parent is more likely to be the
mainline.
So for them "git pull" that either fast-forward when it can, or
makes a merge that records the then-current state of the central
shared repository, is perfectly sensible. They will view gitk and
see all the changes, "git shortlog" and "git log --no-merges" will
give them what they expect.
Hence my suggestion to error when "git pull" doesn't result in a
fast-forward and no branch name is specified. We could give some advice
like:
Your local changes are not included in the local branch and you
haven't told Git how to preserve them.
If you want to rebase your changes onto the modified upstream
branch, run:
git pull --rebase
I can parse the first paragraph above, but cannot make much sense
out of it. Unless you are talking about local changes that are not
committed yet, that is. But in that case I fail to see what it has
to do with the current discussion, or suggestion to use rebase.
quoted
But people need to realize that it is not solving the other half, a
more fundamental problem some people have in their workflow.
Yes, but some users don't realise that their workflow is broken, and
perhaps we can nudge them in the right direction.
I actually avoided mentioning that deliberately, because I think the
"flip the head when merging" encourages people to (1) work directly
on 'master' and (2) pull too often when they shouldn't.
That is detrimental if your goal is to nudge them in the right
direction.
On Thu, May 23, 2013 at 02:01:39PM -0700, Junio C Hamano wrote:
John Keeping [off-list ref] writes:
quoted
I have to wonder how often "git pull" with no arguments actually does
what users really want (even if they don't know it!) when it doesn't
result in a fast-forward (and pull.rebase isn't configured).
If you are in a totally centralized shared repository mindset
without using topic branch workflow, --first-parent would not help
you. In your history the second parent is more likely to be the
mainline.
So for them "git pull" that either fast-forward when it can, or
makes a merge that records the then-current state of the central
shared repository, is perfectly sensible. They will view gitk and
see all the changes, "git shortlog" and "git log --no-merges" will
give them what they expect.
Yes, but for people used to a cleaner history it's confusing to see the
mainline branch and one small change the wrong way round. When I see
people doing this, it's normally something like:
... do some work for several hours...
git commit -a
git push
# fails because it's not a fast forward
git pull
git push
In this scenario, just adding --rebase to "git pull" actually results in
a much more sensible history.
quoted
Hence my suggestion to error when "git pull" doesn't result in a
fast-forward and no branch name is specified. We could give some advice
like:
Your local changes are not included in the local branch and you
haven't told Git how to preserve them.
If you want to rebase your changes onto the modified upstream
branch, run:
git pull --rebase
I can parse the first paragraph above, but cannot make much sense
out of it. Unless you are talking about local changes that are not
committed yet, that is. But in that case I fail to see what it has
to do with the current discussion, or suggestion to use rebase.
This isn't about "swap parents", it's about helping people realise that
just "git pull" isn't necessarily the best thing for them to do, and
that they may want --rebase.
So I was asking if it would be sensible (possibly in Git 2.0) to make
git-pull pass --ff-only to git-merge by default.
On Thu, May 23, 2013 at 4:55 PM, John Keeping [off-list ref] wrote:
So I was asking if it would be sensible (possibly in Git 2.0) to make
git-pull pass --ff-only to git-merge by default.
Definitely yes.
--
Felipe Contreras