Re: Pull is Evil
On Fri, 02 May 2014 10:46:09 +, David Kastrup wrote: ... What the gibbins? I don't even use git pull. I do, but I watch for the fast-forward message and undo as appropriate. I use git fetch, and then, depending on my needs, I rebase or merge. I wouldn't mind that, but I have a century of newbies who are used to having other people's changes appear in their workspace without any interaction. Teaching them the mainline thing (aka first-parent) and the commands to properly mergepush is...tricky. And that goes for every user base, so some improvement would be greatly appreciated. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Andreas Krey a.k...@gmx.de writes: On Fri, 02 May 2014 10:46:09 +, David Kastrup wrote: ... What the gibbins? I don't even use git pull. I do, but I watch for the fast-forward message and undo as appropriate. I use git fetch, and then, depending on my needs, I rebase or merge. I wouldn't mind that, but I have a century of newbies who are used to having other people's changes appear in their workspace without any interaction. Teaching them the mainline thing (aka first-parent) and the commands to properly mergepush is...tricky. And that goes for every user base, so some improvement would be greatly appreciated. I've seen the proposals for git update and whatever. It's sort of like having an assembly line where there are separate automatic screw drivers for screwing and unscrewing. The latter are hard to find in the rare case you need them, with quite different handling and looks. This is modeled after the successful fastening model for nails, where hammer and pliers look and behave quite differently, so people are used to handle and arrange hammer and pliers on different racks and have different numbers for them. Since this model works well for nails, let's employ it for screws as well and call right-turning screwdrivers hammers and left-turning screwdrivers pliers and sort them accordingly in order to avoid confusion for beginners and help them learn to deal with screws properly and deftly. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On Thu, 01 May 2014 16:21:42 +, Marc Branchaud wrote: ... But these days there's hardly any risk to using a detached HEAD. Plus nowadays I think it's commonly accepted that using topic branches is a git best practice. The notion of doing work on a generically-named branch like maint seems archaic. So what benefit does git pull provide? It provides the moral equivalent of 'cvs update', 'svn update', and 'clearcase do nothing'. Even when I'm on a feature branch, there are cases where I have that branch as the current one in multiple repos (on different machines because testing), or multiple people working on that branch. A 'git pull' is the obvious way to get divergent branches back together. In cvssvn a local workspace can't ever be more than half a commit ahead, and what an 'update' does is most similar to a rebase in git. But I'm not eager to teach this future userbase rebases, and also a rebase loses expensive test results that are tied to the commit ids. My personal beef with 'git pull' is still that sometimes (namely in the 'git pull git push' sequence) it should reverse the order of the parents in the merge commit, so that *my* commits look like an integrated topic branch, instead of the former mainline. Unfortunately the answers to the question what to do instead of 'git pull' are, in increasing order of teaching needed: - Ok, just 'git pull' sigh. - Please do a 'git pull --rebase'; I'll show you how. - Something involving switching branches and doing the merge in the other direction (I'm coming from a 'blessed repo where everybody pushes to' setup, and we're considering a server trigger that refuses pushes where the previous head is not a *first* parent of the new head, in order not to accidentally mess up the mainline.) Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote: ... I didn't mean replace 'pull' with 'update' everywhere. I meant Introduce 'update' that lets integrate your history into that from the remote, which is to integrate in a direction opposite from how 'pull' does. That still doesn't quite solve my problem. If I'm tracking origin/master in a local master branch, I can just use 'git pull' to get my 'feature' branch (which is named master) updated to the current state of the origin. This amounts to 'integrating' origin/master into my master. When I finally want to deliver and push to origin/master, I put on the integrator's hat, and I cat do a 'git update' that will do the merge in reverse, and push the result to origin/master. The result will look like origin pulled my master branch into his. Problem is that whether to use pull or update depends on whether I intend to push afterwards; and additionally, if I can push fast-forward without needing to 'git update' the integration into origin/master will look weird. (Oh, and please don't name it 'update' - we have an important alias of that name.) Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Andreas Krey wrote: My personal beef with 'git pull' is still that sometimes (namely in the 'git pull git push' sequence) it should reverse the order of the parents in the merge commit, so that *my* commits look like an integrated topic branch, instead of the former mainline. I haven't really thought much about this but it does make sense. How about changing the behavior so `git pull` by default changes the order of the parents, but `git pull repo branch` doesn't. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Andreas Krey a.k...@gmx.de writes: On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote: ... I didn't mean replace 'pull' with 'update' everywhere. I meant Introduce 'update' that lets integrate your history into that from the remote, which is to integrate in a direction opposite from how 'pull' does. That still doesn't quite solve my problem. If I'm tracking origin/master in a local master branch, I can just use 'git pull' to get my 'feature' branch (which is named master) updated to the current state of the origin. This amounts to 'integrating' origin/master into my master. This discussion makes as much sense to me as debating whether git fiddle should, in case a simple git hammer does not apply, should translate to an implied git screwdriver, and when it does, whether more people's workflows involve turning a screw left rather than right by default. What the gibbins? I don't even use git pull. I use git fetch, and then, depending on my needs, I rebase or merge. git pull is not part of my workflow exactly because it does non-connected things not translating unambiguously to a particular identifiable workflow. It might sometimes, more by accident than design, do what I would have done anyway. But I prefer making that choice on my own, depending on the particular circumstances. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: W. Trevor King wrote: My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” Unfortunately those folks by definition wouldn't know about the --prompt option. But once such folks are identified, you just have to convince them (once) to set the pull.prompt config. That's a lot easier than convincing them (for every pull) to set the appropriate ff flag. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Pull is Evil
W. Trevor King wrote: On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: W. Trevor King wrote: My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” Unfortunately those folks by definition wouldn't know about the --prompt option. But once such folks are identified, you just have to convince them (once) to set the pull.prompt config. That's a lot easier than convincing them (for every pull) to set the appropriate ff flag. It wouldn't matter if by the default non-fast-forward merges are rejected. -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: W. Trevor King wrote: My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” Unfortunately those folks by definition wouldn't know about the --prompt option. But once such folks are identified, you just have to convince them (once) to set the pull.prompt config. That's a lot easier than convincing them (for every pull) to set the appropriate ff flag. It wouldn't matter if by the default non-fast-forward merges are rejected. It would matter if you didn't want them making non-fast-forward merges (e.g. for explicitly-merged topic branches). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Pull is Evil
W. Trevor King wk...@tremily.us writes: On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: W. Trevor King wrote: My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” Unfortunately those folks by definition wouldn't know about the --prompt option. But once such folks are identified, you just have to convince them (once) to set the pull.prompt config. That's a lot easier than convincing them (for every pull) to set the appropriate ff flag. It wouldn't matter if by the default non-fast-forward merges are rejected. It would matter if you didn't want them making non-fast-forward merges (e.g. for explicitly-merged topic branches). s/didn't want/only wanted/ -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
W. Trevor King wrote: On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote: W. Trevor King wrote: My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” Unfortunately those folks by definition wouldn't know about the --prompt option. But once such folks are identified, you just have to convince them (once) to set the pull.prompt config. That's a lot easier than convincing them (for every pull) to set the appropriate ff flag. It wouldn't matter if by the default non-fast-forward merges are rejected. It would matter if you didn't want them making non-fast-forward merges (e.g. for explicitly-merged topic branches). It would matter almost exactly zero. And just as they can do pull.promot = true, they can do pull.mode = fetch-only. -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Marc Branchaud marcn...@xiplink.com writes: I may be mistaken, but I think git pull evolved to try to address the detached-HEAD risk (at least in part). You are totally mistaken. git pull was part of the things to make git usable by Linus before 1.0 release, and matches the integrator workflow perfectly well. The detached HEAD came much much later. The issue we are discussing with git pull is that if a non integrator does a git pull from the upstream, in order to push the result of integrating the local work with it back to the upstream, by default git pull creates a merge in a direction that is wrong when seen in the first-parent chain is the trunk point of view. One way to solve that _might_ be to use the detached HEAD as you illustrated in your long-hand in the thread that had Brian's example, but that is not even a failed 'git push' recommends to do to the users, and there was no link between how 'git pull' behaves and use of detached HEAD at all. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
W. Trevor King wrote [1]:
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My proposed --prompt behavior is for folks who think “I often run
this command without thinking it through all the way. I'm also
not used to reading Git's output and using 'reset --hard' with the
reflog to reverse changes. Instead of trusting me to only say
what I mean or leaving me to recover from mistakes, please tell me
what's about to change and let me opt out if I've changed my
mind.”
Unfortunately those folks by definition wouldn't know about the
--prompt option.
But once such folks are identified, you just have to convince them
(once) to set the pull.prompt config. That's a lot easier than
convincing them (for every pull) to set the appropriate ff flag.
It wouldn't matter if by the default non-fast-forward merges are
rejected.
It would matter if you [only wanted] them making non-fast-forward
merges (e.g. for explicitly-merged topic branches).
It would matter almost exactly zero.
Some folks have explicit merge policies, and deciding how much that
matters is probably best left up to the projects themselves and not
decided in Git code. I like having a place to explain why a feature
is useful and has been included in projects I maintain.
And just as they can do pull.promot = true, they can do pull.mode =
fetch-only.
Why would you run a fetch-only pull instead of running 'git fetch'? I
think it would make more sense to have 'pull.mode = none' with which
'git pull …' turns into a no-op suggesting an explicit
fetch/{merge|rebase}. Having something like that available would
help with the training issue that pull.prompt was addressing.
Cheers,
Trevor
[1]: With David Kastrup's only wanted typo fix.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: Pull is Evil
Junio C Hamano gits...@pobox.com writes: Marc Branchaud marcn...@xiplink.com writes: I may be mistaken, but I think git pull evolved to try to address the detached-HEAD risk (at least in part). You are totally mistaken. git pull was part of the things to make git usable by Linus before 1.0 release, and matches the integrator workflow perfectly well. The detached HEAD came much much later. The issue we are discussing with git pull is that if a non integrator does a git pull from the upstream, in order to push the result of integrating the local work with it back to the upstream, by default git pull creates a merge in a direction that is wrong when seen in the first-parent chain is the trunk point of view. One way to solve that _might_ be to use the detached HEAD as you illustrated in your long-hand in the thread that had Brian's example, but that is not even a failed 'git push' recommends to do to the users, and there was no link between how 'git pull' behaves and use of detached HEAD at all. One other thing to keep in mind is that the first-parent view itself is fairly new, compared to git pull (and it is even newer than detached HEAD IIRC, but I do not think detached HEAD has much to do with the current 'git pull' is often harmful confusion, except that it may be one ingredient for a possible solution). Back when we started A simple CVS/SVN like workflow can be done by cycles of 'git pull', do your work, 'git push', the order of parents in resulting merges was not an issue. I am only saying these to give people the historical background to discuss a possible solution. I am not saying that it is a possible solution to discourage the first-parent chain is the mainline of the development world view. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
W. Trevor King wrote:
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
It would matter almost exactly zero.
Some folks have explicit merge policies, and deciding how much that
matters is probably best left up to the projects themselves and not
decided in Git code.
Let's make some fake numbers to see around how much this would matter.
The amount of people that are not used to Git could be around 60%.
Of these, the amount that would be doing integration is probably 30%, as
those tasks would be relegated to more advanced users. A project that
lets non-advanced users to integration probably wouldn't care if the
merges are fast-forward or not, but let's say 10% of them do. That makes
3%.
On the other hand, user might do merges when trying to bring their local
repositories up-to-date, let's say 100% of them do. Of those, the ones
in a project that doesn't want fast-forward merges is probably 10%. That
makes 10%. However, such projects wouldn't want them merging
'origin/master' to 'master', but 'topic' to 'master', so they shouldn't
be using `git pull` anyway, but for the sake of argument let's say that
they do.
That would make around 8%, and 6% of those wouldn't be using `git pull`
anyway.
So no, for all intents and purposes it doesn't matter. I would rather
concentrate on the issue more than 90% of the users face.
And just as they can do pull.promot = true, they can do pull.mode =
fetch-only.
Why would you run a fetch-only pull instead of running 'git fetch'? I
think it would make more sense to have 'pull.mode = none' with which
'git pull …' turns into a no-op suggesting an explicit
fetch/{merge|rebase}. Having something like that available would
help with the training issue that pull.prompt was addressing.
I fail to see how training them to do this:
% git config --global pull.mode none
% git pull
% git fetch
% git merge --no-ff
Is preferable than training them to do:
% git pull --no-ff
--
Felipe Contreras--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
It would matter almost exactly zero.
Some folks have explicit merge policies, and deciding how much
that matters is probably best left up to the projects themselves
and not decided in Git code.
Let's make some fake numbers to see around how much this would matter.
The point isn't that this is a huge flaw, the point is that we should
be able to configure Git to match sane workflows. Saying “that's
unlikely to happen” doesn't solve the problem that some newcomers have
trouble matching their project's desired workflow.
So no, for all intents and purposes it doesn't matter. I would rather
concentrate on the issue more than 90% of the users face.
You don't have to concentrate on it, because I'm willing to write up
the patch, I'm just trying to find a consensus spec before writing the
patch. If you don't have strong feelings about a pull.prompt
proposal, I won't mind ;). I just don't want to write it up and
*then* hear “that's a terrible idea, you should have just done $x.”.
And just as they can do pull.promot = true, they can do pull.mode =
fetch-only.
Why would you run a fetch-only pull instead of running 'git fetch'? I
think it would make more sense to have 'pull.mode = none' with which
'git pull …' turns into a no-op suggesting an explicit
fetch/{merge|rebase}. Having something like that available would
help with the training issue that pull.prompt was addressing.
I fail to see how training them to do this:
% git config --global pull.mode none
% git pull
% git fetch
% git merge --no-ff
Is preferable than training them to do:
% git pull --no-ff
The goal is to train them to do:
% git config --global pull.mode none
% git fetch
% git merge --no-ff
The 'git pull' (with 'none' mode) explainer just helps retrain folks
that are already using the current 'git pull' incorrectly.
The benefit is that the repeated pair of commands (fetch/merge) takes
longer to type, which gives them longer to realize that they should
think about what they're doing and abort. That's all a pull.prompt
would be doing anyway.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: Pull is Evil
W. Trevor King wrote: On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote: It would matter almost exactly zero. Some folks have explicit merge policies, and deciding how much that matters is probably best left up to the projects themselves and not decided in Git code. Let's make some fake numbers to see around how much this would matter. The point isn't that this is a huge flaw, the point is that we should be able to configure Git to match sane workflows. The point is that we are tainting a discussion about how to improve the defaults for the vast majority of users, and given Git's history, the most likely outcome is that nothing will happen, neither for the majority, nor the tiny minority. Saying “that's unlikely to happen” doesn't solve the problem that some newcomers have trouble matching their project's desired workflow. % git config --global pull.ff false Done. The goal is to train them to do: % git config --global pull.mode none % git fetch % git merge --no-ff The 'git pull' (with 'none' mode) explainer just helps retrain folks that are already using the current 'git pull' incorrectly. If you are going to train them to use a configuration, it should be: % git config --global pull.ff false -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil)
On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote: It would matter almost exactly zero. Some folks have explicit merge policies, and deciding how much that matters is probably best left up to the projects themselves and not decided in Git code. Let's make some fake numbers to see around how much this would matter. The point isn't that this is a huge flaw, the point is that we should be able to configure Git to match sane workflows. The point is that we are tainting a discussion about how to improve the defaults for the vast majority of users I've renamed this sub-thread (which started around $gmane/247835) to avoid potential confusion/dilution. The goal is to train them to do: % git config --global pull.mode none % git fetch % git merge --no-ff Sticking to my 'no-ff' topic branch example, this should have been: git merge --no-ff remote branch I want folks to use --ff-only when pulling their default upstream. The 'git pull' (with 'none' mode) explainer just helps retrain folks that are already using the current 'git pull' incorrectly. If you are going to train them to use a configuration, it should be: % git config --global pull.ff false I don't want all pulls to be --no-ff, only pulls from topic branches. I think adding a prompt or making the integration a two-step fetch/merge are both ways to jog a user into consciously evaluating their actions. I don't see how a changing the default single-step pull strategy (whatever it is) will. I also don't look forward to explaining an adaptive strategy that tries to get my workflow right without command-line ff options to folks on their first day using Git. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
RE: pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil)
W. Trevor King wrote: I've renamed this sub-thread (which started around $gmane/247835) to avoid potential confusion/dilution. Thanks. The goal is to train them to do: % git config --global pull.mode none % git fetch % git merge --no-ff Sticking to my 'no-ff' topic branch example, this should have been: git merge --no-ff remote branch I want folks to use --ff-only when pulling their default upstream. That's proposed to be the default anyway, so they won't need it. The 'git pull' (with 'none' mode) explainer just helps retrain folks that are already using the current 'git pull' incorrectly. If you are going to train them to use a configuration, it should be: % git config --global pull.ff false I don't want all pulls to be --no-ff, only pulls from topic branches. Pulling some branch to a topic branch, or pulling a topic branch to another branch? Either way, since I think these two are different modes: 1) git pull 2) git pull origin topic Maybe it would actually make sense to have a configuration specific to 2): pull.topicmode. This way they could do pull.topicmode = merge-no-ff. Or maybe we need arguments: pull.topicargs = --merge --no-ff. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote: Marc Branchaud wrote: On 14-04-30 04:14 PM, Felipe Contreras wrote: What is wrong when `git pull` merges a fast-forward? Nothing. Everything. It depends. It depends on what? I don't see how a fast-forward `git pull` could possibly have any trouble. The problems with `git pull` come when you can't do a fast-forward merge, right? Some of them, maybe most of them. Name one problem with a fast-forward merge. At work, we have a workflow where we merge topic branches as non-fast-forward, so that we have a record of the history (including who reviewed the code), but when we want to just update our local branches, we always want fast-forward: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD So there are times when fast-forward merges are the right thing, and times when they're not, and as you can see, this depends on context and isn't per-repository. -- 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 signature.asc Description: Digital signature
Re: Pull is Evil
brian m. carlson wrote: On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote: Marc Branchaud wrote: On 14-04-30 04:14 PM, Felipe Contreras wrote: What is wrong when `git pull` merges a fast-forward? Nothing. Everything. It depends. It depends on what? I don't see how a fast-forward `git pull` could possibly have any trouble. The problems with `git pull` come when you can't do a fast-forward merge, right? Some of them, maybe most of them. Name one problem with a fast-forward merge. At work, we have a workflow where we merge topic branches as non-fast-forward, so that we have a record of the history (including who reviewed the code), but when we want to just update our local branches, we always want fast-forward: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD So there are times when fast-forward merges are the right thing, and times when they're not, and as you can see, this depends on context and isn't per-repository. That's not what I asked. I didn't ask you if fast-forward merges were the right thing to do in every situation. I asked you, *when* people do a fast-forward merge (that is; when it's possible and desirable), what are the problems that a fast-forward merge causes? I tired of waiting, so I'll answer for you: there are absolutely no problems. The problems are only on non-fast-forward merges, and we have a solution. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On 14-05-01 05:46 AM, brian m. carlson wrote: On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote: Marc Branchaud wrote: On 14-04-30 04:14 PM, Felipe Contreras wrote: What is wrong when `git pull` merges a fast-forward? Nothing. Everything. It depends. It depends on what? I don't see how a fast-forward `git pull` could possibly have any trouble. The problems with `git pull` come when you can't do a fast-forward merge, right? Some of them, maybe most of them. Name one problem with a fast-forward merge. At work, we have a workflow where we merge topic branches as non-fast-forward, so that we have a record of the history (including who reviewed the code), but when we want to just update our local branches, we always want fast-forward: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD Thanks for the nice example. To me this looks like an advanced use of git pull. A new user could be taught to work like this, but I don't think a new user would come up with it on their own (until they became an experienced user). What's more, it seems to me that the only real advantage git pull provides here is a less typing compared to the non-pull equivalent: git fetch main-repo git checkout main-repo/maintenance-branch git fetch developer-remote git merge --no-ff developer-remote/topic-branch git push main-repo HEAD I suggest that this approach is superior for new users (despite the increased risk of finger cramps), because if main-repo's maintenance-branch is updated in the interim and the push fails, the user can use the exact same commands to resolve the situation. Sure, the non-pull approach makes use of Scary Branch Stuff (remotes and namespaces and detached HEADs -- oh my!). But trying to avoid that stuff is precisely the slippery slope that led to pull's misguided gymnastics. We've gone down that slope, slipped and fallen over, and now we're wallowing in the muck. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Felipe Contreras felipe.contre...@gmail.com writes: brian m. carlson wrote: .. At work, we have a workflow where we merge topic branches as non-fast-forward, so that we have a record of the history (including who reviewed the code), but when we want to just update our local branches, we always want fast-forward: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD So there are times when fast-forward merges are the right thing, and times when they're not, and as you can see, this depends on context and isn't per-repository. That's not what I asked. I didn't ask you if fast-forward merges were the right thing to do in every situation. I asked you, *when* people do a fast-forward merge (that is; when it's possible and desirable), what are the problems that a fast-forward merge causes? But then I think you asked a wrong question. The opposite case of the question tells me what is wrong in it: When people do a real merge (that is: when it's possible and desirable), there is no reason to forbid 'git pull' from creating a real merge. What are the problems that a real merge causes under that condition? By definition, because of when it's possible and DESIRABLE part, the answer is absolutely zero. That is not an interesting question, is it? My reading of the design of the let's forbid non-ff merge when people do 'git pull' is based on this reasonong: - Most people are not integrators, and letting git pull run on their work based on a stale upstream to sync with an updated upstream would create a merge in a wrong direction and letting user continue on it. We need to have a way to prevent this. - Forbid git pull when the HEAD is based on a stale upstream, i.e. the pull does not fast-forward. Integrators that would want to _allow_ real merges may be inconvenienced so we will give a configuration to let them say that with pull.mode=merge. - We do not forbid git pull if the pull will fast-forward. We do not do anything for that case, because everybody will accept fast-forward, whether he is a contributor or an integrator. Doesn't Brian's case show the justification because everybody will accept fast-forward does not hold? It shows that the user do not necessarily know when it's possible and DESIRABLE, and updating the command is about helping people avoid an action that may not be desirable in the end. Brian needs a way to make sure he fast-forwards when pulling the project's maintenance-branch into his maintenance-branch, and also he does *not* fast-forward when pulling developer's fix branch into that same maintenance-branch of his. So neither pull.mode nor branch.*.pullmode would help him and the example may show we need a bit more work to help that case, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote: On 14-05-01 05:46 AM, brian m. carlson wrote: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD … What's more, it seems to me that the only real advantage git pull provides here is a less typing compared to the non-pull equivalent: git fetch main-repo git checkout main-repo/maintenance-branch git fetch developer-remote git merge --no-ff developer-remote/topic-branch git push main-repo HEAD You're missing Brian's fast-forward merge here. It should be: git checkout maintenance-branch git fetch main-repo git merge --ff-only main-repo/maintenance-branch git fetch developer-remote … Sure, the non-pull approach makes use of Scary Branch Stuff (remotes and namespaces and detached HEADs -- oh my!). No need for detached heads with Brian's local maintenance-branch. If you're teaching and just need folks merging the remote's HEAD, you can avoid namespaces and remotes entirely: git fetch git://example.net/main-repo.git git merge --ff-only FETCH_HEAD although I doubt “the remote's HEAD” will be easier to explain than the namespaced, remote-tracking branches it replaces. It's certainly not worth the hassle of un-training FETCH_HEAD-merges later on ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] Re: Pull is Evil
On 14-05-01 01:56 PM, W. Trevor King wrote: On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote: On 14-05-01 05:46 AM, brian m. carlson wrote: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD … What's more, it seems to me that the only real advantage git pull provides here is a less typing compared to the non-pull equivalent: git fetch main-repo git checkout main-repo/maintenance-branch git fetch developer-remote git merge --no-ff developer-remote/topic-branch git push main-repo HEAD You're missing Brian's fast-forward merge here. It should be: git checkout maintenance-branch git fetch main-repo git merge --ff-only main-repo/maintenance-branch git fetch developer-remote … I think you're mistaken -- I checked out main-repo/maintenance-branch directly, so there's no need to fast-forward a local branch. Sure, the non-pull approach makes use of Scary Branch Stuff (remotes and namespaces and detached HEADs -- oh my!). No need for detached heads with Brian's local maintenance-branch. Yes. OTOH, no need to bother keeping a local maintenance-branch up to date if you use a detached HEAD. If you're teaching and just need folks merging the remote's HEAD, you can avoid namespaces and remotes entirely: git fetch git://example.net/main-repo.git git merge --ff-only FETCH_HEAD although I doubt “the remote's HEAD” will be easier to explain than the namespaced, remote-tracking branches it replaces. It's certainly not worth the hassle of un-training FETCH_HEAD-merges later on ;). Agreed. I wouldn't advocate teaching people about FETCH_HEAD as if it were something they should use regularly. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: brian m. carlson wrote: .. At work, we have a workflow where we merge topic branches as non-fast-forward, so that we have a record of the history (including who reviewed the code), but when we want to just update our local branches, we always want fast-forward: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD So there are times when fast-forward merges are the right thing, and times when they're not, and as you can see, this depends on context and isn't per-repository. That's not what I asked. I didn't ask you if fast-forward merges were the right thing to do in every situation. I asked you, *when* people do a fast-forward merge (that is; when it's possible and desirable), what are the problems that a fast-forward merge causes? But then I think you asked a wrong question. I asked the simple uncontroversial question as a rhetorical aid. I hoped I would get the obvious answer, but I didn't even get that, so what hope is there of convincing these people of the one that needs real pondering? The opposite case of the question tells me what is wrong in it: When people do a real merge (that is: when it's possible and desirable), there is no reason to forbid 'git pull' from creating a real merge. What are the problems that a real merge causes under that condition? By definition, because of when it's possible and DESIRABLE part, the answer is absolutely zero. That is not an interesting question, is it? That's right, but we are discussing the default behavior of `git pull`, which if we agree has no problems when the ff is a) possible, and b) desirable, the problems must come when either one of those is not met. a) If the fast-forward is not possible, that creates problems, because a real merge might happen, and it's not desirable. However, if we don't allow real merges to happen by default this couldn't be a problem. b) If the fast-forward is not desirable, then the user wouldn't be running `git pull`, would be running `git pull --no-ff`. In other words, after the proposed changes `git pull` by default would have no issues. Doesn't Brian's case show the justification because everybody will accept fast-forward does not hold? It shows that the user do not necessarily know when it's possible and DESIRABLE, and updating the command is about helping people avoid an action that may not be desirable in the end. No, it doesn't hold. As I said, if we change the default the fact that it's not possible is not an issue. The only problem would be when it's not desirable, however, that's a problem of the user's ignorance, and the failure of the project's policity to communicate clearly to him that he should be running `git merge --no-ff`. There's absolutely nothing we can do to help him. The only thing we could do is not allow fast-forward merges either, in which case `git pull` becomes a no-op that can't possibly do anything ever. Brian needs a way to make sure he fast-forwards when pulling the project's maintenance-branch into his maintenance-branch, and also he does *not* fast-forward when pulling developer's fix branch into that same maintenance-branch of his. First of all this use-case is not realistic. The moment he merges a developer branch, hes maintenance and the probject's diverge, and all the pulls after that cannot be fast-forward. It's pointless to add something that just doesn't happen. It will be possible to do the fast-forward merges only early on the life of this branch, not afterwards. For this short period of time he can just simply use his fingers to type `git merge --no-ff`. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Marc Branchaud wrote: What's more, it seems to me that the only real advantage git pull provides here is a less typing compared to the non-pull equivalent: git fetch main-repo git checkout main-repo/maintenance-branch git fetch developer-remote git merge --no-ff developer-remote/topic-branch git push main-repo HEAD You mean `git push main-repo HEAD:maintenance-branch`, right? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
brian m. carlson wrote: At work, we have a workflow where we merge topic branches as non-fast-forward, so that we have a record of the history (including who reviewed the code), but when we want to just update our local branches, we always want fast-forward: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only If we make it the default, you only need to type `git pull`. git pull --no-ff developer-remote topic-branch I don't see anything wrong with having to type --no-ff if that's what you really want. git push main-repo HEAD main-repo/maintenance-branch should be the upstream of maintenance-branch, in which hase: % git push -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On 14-05-01 03:22 PM, Felipe Contreras wrote: Marc Branchaud wrote: What's more, it seems to me that the only real advantage git pull provides here is a less typing compared to the non-pull equivalent: git fetch main-repo git checkout main-repo/maintenance-branch git fetch developer-remote git merge --no-ff developer-remote/topic-branch git push main-repo HEAD You mean `git push main-repo HEAD:maintenance-branch`, right? Right. Sorry, for that command I thoughtlessly just copied Brian's example. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote: The only problem would be when it's not desirable, however, that's a problem of the user's ignorance, and the failure of the project's policity to communicate clearly to him that he should be running `git merge --no-ff`. There's absolutely nothing we can do to help him. I think “user ignorange” is the *only* problem with git pull. Once you understand the ff flags, you can set them however you like, and pull will do what you tell it to. The only thing we could do is not allow fast-forward merges either, in which case `git pull` becomes a no-op that can't possibly do anything ever. My interest in all of the proposed git-pull-training-wheel patches is that they give users a way to set a finger-breaking configuration that makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who compulsively run 'git pull' (e.g. because SVN habits die slowly) can set an option that gives them something to think about before going ahead and running the pull anyway. The space in 'git pull' makes a shell-side: $ alias 'git pull'='echo try fetch/merge!' solution unfeasible, and clobbering /usr/libexec/git-core/git-pull seems a bit extreme. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] Re: Pull is Evil
On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote: On 14-05-01 01:56 PM, W. Trevor King wrote: On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote: On 14-05-01 05:46 AM, brian m. carlson wrote: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD … What's more, it seems to me that the only real advantage git pull provides here is a less typing compared to the non-pull equivalent: git fetch main-repo git checkout main-repo/maintenance-branch git fetch developer-remote git merge --no-ff developer-remote/topic-branch git push main-repo HEAD You're missing Brian's fast-forward merge here. It should be: git checkout maintenance-branch git fetch main-repo git merge --ff-only main-repo/maintenance-branch git fetch developer-remote … I think you're mistaken -- I checked out main-repo/maintenance-branch directly, so there's no need to fast-forward a local branch. I find a local branch useful to mark the amount of the upstream branch that I've reviewed. The reflog helps a bit, but I may go several fetches between reviews. For newbies, I recommend avoiding detached HEADs, where possible, so they don't have to rely on the reflog if they accidentally commit and then checkout something else (ignoring Git's warning). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] Re: Pull is Evil
On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote: My interest in all of the proposed git-pull-training-wheel patches is that they give users a way to set a finger-breaking configuration that makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who compulsively run 'git pull' (e.g. because SVN habits die slowly) can set an option that gives them something to think about before going ahead and running the pull anyway. Actually, what do we think about an -i/--interactive flag (with an associated pull.interactive boolean config to setup global/per-repo defaults)? Then after the fetch, you'd get one of the following: Merge $count commits from $repository $refspec into $current_branch? Rebase $count commits from $current_branch onto $repository $refpec? Fast-forward $current_branch by $count commits to $repository $refpec? and have a chance to bail out if you saw: Merge 1003 commits from git://example.net/main.git master into my-feature? because you forgot which branch you were on. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] Re: Pull is Evil
On 14-05-01 02:30 PM, W. Trevor King wrote: I find a local branch useful to mark the amount of the upstream branch that I've reviewed. The reflog helps a bit, but I may go several fetches between reviews. For newbies, I recommend avoiding detached HEADs, where possible, so they don't have to rely on the reflog if they accidentally commit and then checkout something else (ignoring Git's warning). All sound practices that I think are perfectly fine. I may be mistaken, but I think git pull evolved to try to address the detached-HEAD risk (at least in part). This risk was pretty real before the reflog came about (I'm under the impression -- and too lazy to check -- that git pull predates the reflog; please forgive me if I'm mis-perceiving the timeline). But these days there's hardly any risk to using a detached HEAD. Plus nowadays I think it's commonly accepted that using topic branches is a git best practice. The notion of doing work on a generically-named branch like maint seems archaic. So what benefit does git pull provide? In your particular case, you're using git pull to help you track your reviews of the upstream branch. To me this seems more like you taking advantage of a git pull side-effect than using the command as it is intended to be used. Certainly there are other ways that git can track this for you. A simple, aliasable, git tag -f LastReviewPoint upstream/branch seems just as effective to me (but then, I'm not you). M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
From: Marc Branchaud marcn...@xiplink.com Sent: Wednesday, April 30, 2014 8:45 PM [...] I don't think we'll ever be able to create a One Git Pull To Rule Them All. At best we'll end up with something with enough knobs that it could be configured to work in most workflows (I think we're actually pretty close to that). But for new users that defeats the purpose. It means that git pull is really an advanced command, and beginners should avoid it until they understand enough of git to configure it properly. So rather than perpetuate the myth that one command can always (or even just usually) do the right thing, let's just retire the command. All that said, I don't object to any attempts at improving the command either. But I also don't see any kind of improvement that would lead me to start using git pull let alone recommending it to new users. M. [1] By significant I mean enough to perpetually create new mailing list threads about changing 'git pull'. [general reply to all, rather than to anyone in particular, using Marc's summary] The point that there is no easy solution to an updated default pull action that is right for everybody, straight out of the box, I think is now fairly obvious, a summarised by Marc. I certainly avoid pull. My 'solution', if it could be called that, would be that at the point of switch over, after a period of release note warning and then code warning, that the plain 'git pull' would not even do the no-ff, but would simply refuse to do anything unless the user had explicitly set the [new] config variable(s) to a value of _their_ choice. The message could give guidance based on their old setting(s) and the new options as appropriate, i.e. if they have an old definitive setting then the new setting may be an obvious one. During the warning period between the release cycles, we may have a two step ramp up of the warning, where the first cycle allows users who have read the release notes to choose their new setting and it's auto detected from there on, then in the second cycle Git detects the lack of a setting and gives a warning prompt (just like the Git 2.0 warning), and finally the change over release makes a 'git pull' without a config setting an error. I know that for some it's a phaff that appears to waste time (been there, been that person), but it does allow the stragglers time to pick up the hints and not be too surprised, which will include many otherwise professional folks who just happen to have other priorities [e.g. this message typed from a Win XP machine!]. The approach does have a solid heritage, and avoids anyone (on the coding side) having to decide on an initial default, when it should be a user choice. Though I do agree with Filipe that the '--no-ff merge' would probably be the least worst for the new user and likely be a suitable 'if you don't know use this one' suggestion. Philip -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Oops.. From: Philip Oakley philipoak...@iee.org From: Marc Branchaud marcn...@xiplink.com Sent: Wednesday, April 30, 2014 8:45 PM [...] I don't think we'll ever be able to create a One Git Pull To Rule Them All. At best we'll end up with something with enough knobs that it could be configured to work in most workflows (I think we're actually pretty close to that). But for new users that defeats the purpose. It means that git pull is really an advanced command, and beginners should avoid it until they understand enough of git to configure it properly. So rather than perpetuate the myth that one command can always (or even just usually) do the right thing, let's just retire the command. All that said, I don't object to any attempts at improving the command either. But I also don't see any kind of improvement that would lead me to start using git pull let alone recommending it to new users. M. [1] By significant I mean enough to perpetually create new mailing list threads about changing 'git pull'. [general reply to all, rather than to anyone in particular, using Marc's summary] The point that there is no easy solution to an updated default pull action that is right for everybody, straight out of the box, I think is now fairly obvious, a summarised by Marc. I certainly avoid pull. My 'solution', if it could be called that, would be that at the point of switch over, after a period of release note warning and then code warning, that the plain 'git pull' would not even do the no-ff, but s/no-ff/--ff/g that is, only 'merge' if it's a fast forward. would simply refuse to do anything unless the user had explicitly set the [new] config variable(s) to a value of _their_ choice. The message could give guidance based on their old setting(s) and the new options as appropriate, i.e. if they have an old definitive setting then the new setting may be an obvious one. During the warning period between the release cycles, we may have a two step ramp up of the warning, where the first cycle allows users who have read the release notes to choose their new setting and it's auto detected from there on, then in the second cycle Git detects the lack of a setting and gives a warning prompt (just like the Git 2.0 warning), and finally the change over release makes a 'git pull' without a config setting an error. I know that for some it's a phaff that appears to waste time (been there, been that person), but it does allow the stragglers time to pick up the hints and not be too surprised, which will include many otherwise professional folks who just happen to have other priorities [e.g. this message typed from a Win XP machine!]. The approach does have a solid heritage, and avoids anyone (on the coding side) having to decide on an initial default, when it should be a user choice. Though I do agree with Filipe that the '--no-ff merge' s/no-ff/--ff/ would probably be the least worst for the new user and likely be a suitable 'if you don't know use this one' suggestion. Philip -- sorry for the finger-brain failures. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
W. Trevor King wrote: On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote: The only problem would be when it's not desirable, however, that's a problem of the user's ignorance, and the failure of the project's policity to communicate clearly to him that he should be running `git merge --no-ff`. There's absolutely nothing we can do to help him. I think “user ignorange” is the *only* problem with git pull. That, and the fact that 'git pull' does something wrong by default. The only thing we could do is not allow fast-forward merges either, in which case `git pull` becomes a no-op that can't possibly do anything ever. My interest in all of the proposed git-pull-training-wheel patches is that they give users a way to set a finger-breaking configuration that makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who compulsively run 'git pull' (e.g. because SVN habits die slowly) can set an option that gives them something to think about before going ahead and running the pull anyway. The space in 'git pull' makes a shell-side: $ alias 'git pull'='echo try fetch/merge!' solution unfeasible, and clobbering /usr/libexec/git-core/git-pull seems a bit extreme. What is wrong with 'git pull' doing a merge when it can be fast-forward? -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
W. Trevor King wrote: On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote: My interest in all of the proposed git-pull-training-wheel patches is that they give users a way to set a finger-breaking configuration that makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who compulsively run 'git pull' (e.g. because SVN habits die slowly) can set an option that gives them something to think about before going ahead and running the pull anyway. Actually, what do we think about an -i/--interactive flag (with an associated pull.interactive boolean config to setup global/per-repo defaults)? Then after the fetch, you'd get one of the following: Merge $count commits from $repository $refspec into $current_branch? Rebase $count commits from $current_branch onto $repository $refpec? Not much interactivity in those options. Maybe --prompt would make more sense. Fast-forward $current_branch by $count commits to $repository $refpec? Why would anyone say 'no' to this one? But your wording made me realize that my proposed option 'merge-ff-only' is not appropriate, because in theroy the user can think about it as 'rebase-ff-only'; in other words, a 'fast-forward' is not really a merge, and not really a rebase. and have a chance to bail out if you saw: Merge 1003 commits from git://example.net/main.git master into my-feature? because you forgot which branch you were on. Yes, that might be nice. But we still need to change the defaults. -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
Marc Branchaud wrote: So what benefit does git pull provide? The same that 'hg update' provies: a way for the user fetch/pull the latest changes and check them out into the working directory. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Philip Oakley wrote: The point that there is no easy solution to an updated default pull action that is right for everybody, straight out of the box, I think is now fairly obvious, a summarised by Marc. I certainly avoid pull. Yes, I avoid it too, and quite a lot of people. My 'solution', if it could be called that, would be that at the point of switch over, after a period of release note warning and then code warning, that the plain 'git pull' would not even do the no-ff, but would simply refuse to do anything... I still haven't heard a single argument why a fast-forward by default wouldn't be desirable. Remember that we are talking about inexperienced users here. Experienced users can simply do `git pull --no-ff` or do the right configuration. The problem we want to track is newcomers doing merges (real ones) by mistake. Nobody ever complained about somebody doing a fast-forward by mistake. I think a non-fast-forward warning by default, and eventually rejecting them is the most sensible approach. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote: On 14-05-01 01:56 PM, W. Trevor King wrote: On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote: On 14-05-01 05:46 AM, brian m. carlson wrote: git checkout maintenance-branch # Update our maintenance branch to the latest from the main repo. git pull --ff-only git pull --no-ff developer-remote topic-branch git push main-repo HEAD … What's more, it seems to me that the only real advantage git pull provides here is a less typing compared to the non-pull equivalent: git fetch main-repo git checkout main-repo/maintenance-branch git fetch developer-remote git merge --no-ff developer-remote/topic-branch git push main-repo HEAD You're missing Brian's fast-forward merge here. It should be: git checkout maintenance-branch git fetch main-repo git merge --ff-only main-repo/maintenance-branch git fetch developer-remote … I think you're mistaken -- I checked out main-repo/maintenance-branch directly, so there's no need to fast-forward a local branch. I actually need my local copy to be up-to-date. Part of my workflow, which I omitted for the sake of brevity, is running scripts that rely on my local branch's name, format, and contents. My use case is that I'm one of several code reviewers, and I update my branch, merge in another developer's changes, review them, and then push them if they're good. I need to pull from the main repo immediately before merging, to minimize the chances that someone else will have pushed before me, which would result in me having to redo the merge (because the push has to be fast-forward). I just used this to illustrate the fact that there isn't actually one completely correct case with pull. I have aliases for pull (and merge) --ff-only and --no-ff, and I never actually use plain git pull unless I really don't care whether or not it's a fast-forward. So I'm okay with the status quo because I have distinct choices for merge, no merge, and don't care. I don't really have a strong opinion, though, as long as those three options remain. -- 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 signature.asc Description: Digital signature
Re: [git] Re: Pull is Evil
brian m. carlson wrote: I just used this to illustrate the fact that there isn't actually one completely correct case with pull. Nobody is arguing otherwise. The argument is that `git pull` by default can be made more sensible. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote: Nobody ever complained about somebody doing a fast-forward by mistake. Unless they fast-forward merged a feature branch into master, but the project prefers explicitly-merged feature branches with a cover-letter explaination in the merge commit [1]. On the one hand, folks integrating feature branches are likely more experienced Git users. On the other hand, I know several project maintainers who integrate feature branches that are pull-happy. I agree that accidental ff-merges are likely to be less troublesome than accidental non-ff merge/rebases, but I don't think changing the default to ff-only is a perfect fix. Cheers, Trevor [1]: http://article.gmane.org/gmane.comp.version-control.git/247807 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [git] Re: Pull is Evil
On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote: My interest in all of the proposed git-pull-training-wheel patches is that they give users a way to set a finger-breaking configuration that makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who compulsively run 'git pull' (e.g. because SVN habits die slowly) can set an option that gives them something to think about before going ahead and running the pull anyway. Actually, what do we think about an -i/--interactive flag (with an associated pull.interactive boolean config to setup global/per-repo defaults)? Then after the fetch, you'd get one of the following: Merge $count commits from $repository $refspec into $current_branch? Rebase $count commits from $current_branch onto $repository $refpec? Not much interactivity in those options. Maybe --prompt would make more sense. I think matching rm, mv, cp, etc. is good, but I'd be ok with --prompt. Fast-forward $current_branch by $count commits to $repository $refpec? Why would anyone say 'no' to this one? Because the want explicit merges when they bring in topic branches? and have a chance to bail out if you saw: Merge 1003 commits from git://example.net/main.git master into my-feature? because you forgot which branch you were on. Yes, that might be nice. But we still need to change the defaults. So I should submit an orthogonal patch with -i/--interative/--prompt? Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Pull is Evil
W. Trevor King wrote: On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote: Nobody ever complained about somebody doing a fast-forward by mistake. Unless they fast-forward merged a feature branch into master, but the project prefers explicitly-merged feature branches with a cover-letter explaination in the merge commit [1]. On the one hand, folks integrating feature branches are likely more experienced Git users. Exactly. That's barely an issue. I agree that accidental ff-merges are likely to be less troublesome than accidental non-ff merge/rebases, but I don't think changing the default to ff-only is a perfect fix. I don't see what else we could do. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: Pull is Evil
W. Trevor King wrote: On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote: My interest in all of the proposed git-pull-training-wheel patches is that they give users a way to set a finger-breaking configuration that makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who compulsively run 'git pull' (e.g. because SVN habits die slowly) can set an option that gives them something to think about before going ahead and running the pull anyway. Actually, what do we think about an -i/--interactive flag (with an associated pull.interactive boolean config to setup global/per-repo defaults)? Then after the fetch, you'd get one of the following: Merge $count commits from $repository $refspec into $current_branch? Rebase $count commits from $current_branch onto $repository $refpec? Not much interactivity in those options. Maybe --prompt would make more sense. I think matching rm, mv, cp, etc. is good, but I'd be ok with --prompt. Those are actually interactive. `git mergetool --prompt` is an exactly of a configration where it's interactivity is constrainted to a single input. Fast-forward $current_branch by $count commits to $repository $refpec? Why would anyone say 'no' to this one? Because the want explicit merges when they bring in topic branches? If that was the case the user wouls have run `git merge --no-ff`. Only expereinced users would answer 'no'. and have a chance to bail out if you saw: Merge 1003 commits from git://example.net/main.git master into my-feature? because you forgot which branch you were on. Yes, that might be nice. But we still need to change the defaults. So I should submit an orthogonal patch with -i/--interative/--prompt? I'm not entirely sure what would be the ideal behavior. For example, I'm thinking that by default when the a fast-forward is possible, just do it, when it's not, ask if the user wants to do a merge or a rebase, if the user just press 'enter' a merge is attempted. In addition a summary of the commits ahead behind would be helpful. If the user wants to cancel the operation, he can just do CTRL+C. -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote: W. Trevor King wrote: On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote: W. Trevor King wrote: Fast-forward $current_branch by $count commits to $repository $refpec? Why would anyone say 'no' to this one? Because the want explicit merges when they bring in topic branches? If that was the case the user wouls have run `git merge --no-ff`. Only expereinced users would answer 'no'. Folks who are setting any ff options don't need any of these training wheels. My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” and have a chance to bail out if you saw: Merge 1003 commits from git://example.net/main.git master into my-feature? because you forgot which branch you were on. Yes, that might be nice. But we still need to change the defaults. So I should submit an orthogonal patch with -i/--interative/--prompt? I'm not entirely sure what would be the ideal behavior. For example, I'm thinking that by default when the a fast-forward is possible, just do it, … But just because a ff is possible doesn't mean it's what the user/project wants. It may be the most likely guess, but why guess when they've explicitly asked for a prompt? when it's not, ask if the user wants to do a merge or a rebase, if the user just press 'enter' a merge is attempted. I'll just mimic however mergetool currently handles prompt accept/decline. In addition a summary of the commits ahead behind would be helpful. Good idea. If the user wants to cancel the operation, he can just do CTRL+C. I'll just mimic mergetool. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: Pull is Evil
W. Trevor King wrote: On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote: If that was the case the user wouls have run `git merge --no-ff`. Only expereinced users would answer 'no'. Folks who are setting any ff options don't need any of these training wheels. Indeed. My proposed --prompt behavior is for folks who think “I often run this command without thinking it through all the way. I'm also not used to reading Git's output and using 'reset --hard' with the reflog to reverse changes. Instead of trusting me to only say what I mean or leaving me to recover from mistakes, please tell me what's about to change and let me opt out if I've changed my mind.” Unfortunately those folks by definition wouldn't know about the --prompt option. For example, I'm thinking that by default when the a fast-forward is possible, just do it, … But just because a ff is possible doesn't mean it's what the user/project wants. Yeah, so? We cannot read minds, especially not the minds of the people that are not sitted in from of the computer. It may be the most likely guess, but why guess when they've explicitly asked for a prompt? *If* the user has specifically asked for a prompt, sure, ask. But I'm not particularly interested in that, because I'm certain very very few people would use --prompt. I'm interested in the defaults. -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)
On 14-04-28 02:41 PM, Junio C Hamano wrote: Marat Radchenko ma...@slonopotamus.org writes: Problem #1: TortoiseGit GUI windows for common tasks have a heck lots of controls that a common Git user will never need. Do people around TortoiseGit lurk on this list? Otherwise this may not be something we can help you with here. Problem #2 occured the first day we started using Git on real project. It is explained in detail in older post to Git ML [3]. I call it swapped/reverse merge problem. In short: 1. Hack, hack, hack 2. Commit 3. Push, woops, reject (non-ff) 4. Pull 5. Push The root of evil is step #4 that creates a merge commit with swapped parents. Yes, this is a real issue, and I do not mind seeing a patch to improve the situation (there may be different approaches, and one random approach somebody takes may not necessarily be a good way to improve the situation though). - Perhaps by allowing an option to tell the pull at the fourth step to record swapped parents in the merge? - Perhaps in step #3, stop suggesting to pull first and instead tell them to fetch upstream, rebase your work on it and then push? This approach would be my preference. But I'm definitely biased because I think pull is pretty much broken: * New users are encouraged to use pull, but all too often the default fetch-then-merge behaviour doesn't match their expectations and they end up starting threads like this one on the mailing list. * If we change pull's default behaviour, we'll just be shifting the mismatched expectations onto the other half of the new users who would be happy with fetch-then-merge. * I'm not sure why new users are taught to use pull. I suspect it's because it tries to hide the idea of local-vs-remote branches, and people writing git tutorials don't want to overwhelm new users with what seems to be an internal detail. But these notions are really fundamental to using git effectively, and I think pull does everyone a disservice by trying to gloss them over. Anyway, rather than ranting on I'll just suggest that there's not enough commonality between the ways people use git to make it worthwhile trying to teach pull how to deal with a significant number of them. I think the pull command should be deprecated and quietly retired as a failed experiment. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)
Marc Branchaud marcn...@xiplink.com writes: But I'm definitely biased because I think pull is pretty much broken: * New users are encouraged to use pull, but all too often the default fetch-then-merge behaviour doesn't match their expectations and they end up starting threads like this one on the mailing list. * If we change pull's default behaviour, we'll just be shifting the mismatched expectations onto the other half of the new users who would be happy with fetch-then-merge. * I'm not sure why new users are taught to use pull. I suspect it's because it tries to hide the idea of local-vs-remote branches, and people writing git tutorials don't want to overwhelm new users with what seems to be an internal detail. But these notions are really fundamental to using git effectively, and I think pull does everyone a disservice by trying to gloss them over. Anyway, rather than ranting on I'll just suggest that there's not enough commonality between the ways people use git to make it worthwhile trying to teach pull how to deal with a significant number of them. I think the pull command should be deprecated and quietly retired as a failed experiment. I almost agree with the first sentence in the last paragraph, and your bulletted list above supports it. I am not sure how the second sentence can follow as its consequence. If the conclusion were maybe adding a 'git update' to match the expectation of those who build on top of the work of others (aka CVS/SVN style) more closely and teaching new users to use that instead of 'git pull' may be a good way forward, I can sort of understand (if I may not be able to immediately agree with, until I can regurgitate the ramifications of such a change) it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)
Marc Branchaud wrote: But I'm definitely biased because I think pull is pretty much broken: * New users are encouraged to use pull, but all too often the default fetch-then-merge behaviour doesn't match their expectations and they end up starting threads like this one on the mailing list. Yes, this has been discussed many times in the past, and everyone agrees the default behavior is not correct. Most people agree it has to be changed. And we have patches for it[1]. But it's not going to change. Why? No reason given, it's just not going to. * If we change pull's default behaviour, we'll just be shifting the mismatched expectations onto the other half of the new users who would be happy with fetch-then-merge. Not true. As it has been agreed in the discussions, very few people would be affected negatively by this change, and even then an appropriate error message like: The pull was not fast-forward, please either merge or rebase. If unsure, run 'git pull --merge'. Should do the trick. [1] http://article.gmane.org/gmane.comp.version-control.git/247567 -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Felipe Contreras felipe.contre...@gmail.com writes: Marc Branchaud wrote: But I'm definitely biased because I think pull is pretty much broken: * New users are encouraged to use pull, but all too often the default fetch-then-merge behaviour doesn't match their expectations and they end up starting threads like this one on the mailing list. Yes, this has been discussed many times in the past, and everyone agrees the default behavior is not correct. You definitely have a strange notion of everyone. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Matthieu Moy wrote: Felipe Contreras felipe.contre...@gmail.com writes: Marc Branchaud wrote: But I'm definitely biased because I think pull is pretty much broken: * New users are encouraged to use pull, but all too often the default fetch-then-merge behaviour doesn't match their expectations and they end up starting threads like this one on the mailing list. Yes, this has been discussed many times in the past, and everyone agrees the default behavior is not correct. You definitely have a strange notion of everyone. Do I? Let's look at some of the discussions: http://thread.gmane.org/gmane.comp.version-control.git/225146 * W. Trevor King agrees the default should change * Junio C Hamano agrees the default should change * John Keeping agrees the default should change * Matthieu Moy doesn't agree anything should change * Linus Torvalds agrees changing the default is fine http://thread.gmane.org/gmane.comp.version-control.git/233554 * Richard Hansen agrees with my proposal * Ramkumar Ramachandra agrees with my proposal * Brian M. Carlson is not happy but can live with my proposal * Jeff King accepts my proposal is a good way to move forward * Matthieu Moy is OK with change, but only if the default remains the same So, by everyone I mean everyone but one person (you). Rational people don't think in absolute terms, everyone means virtually everyone, which is the case. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Felipe Contreras felipe.contre...@gmail.com writes: Matthieu Moy wrote: Felipe Contreras felipe.contre...@gmail.com writes: ... Yes, this has been discussed many times in the past, and everyone agrees the default behavior is not correct. You definitely have a strange notion of everyone. Do I? Let's look at some of the discussions: http://thread.gmane.org/gmane.comp.version-control.git/225146 * W. Trevor King agrees the default should change * Junio C Hamano agrees the default should change * John Keeping agrees the default should change * Matthieu Moy doesn't agree anything should change * Linus Torvalds agrees changing the default is fine http://thread.gmane.org/gmane.comp.version-control.git/233554 * Richard Hansen agrees with my proposal * Ramkumar Ramachandra agrees with my proposal * Brian M. Carlson is not happy but can live with my proposal * Jeff King accepts my proposal is a good way to move forward * Matthieu Moy is OK with change, but only if the default remains the same So, by everyone I mean everyone but one person (you). I looked at the latter thread and re-read what Peff wrote (added to Cc). I think the most relevant (other than solving it in quite a different way $gmane/233554) one to your version of the solution is this: http://thread.gmane.org/gmane.comp.version-control.git/233554/focus=234365 where he responds to my how about this way forward with this: ... I think other people are also in agreement. So perhaps: - drop jc/pull-training-wheel and revert its merge from 'next'; - update Felipe's series with a bit of tweak to make it less impactful by demoting error into warning and advice. would be a good way forward? I think that would address the concern I raised, because it does not create a roadblock to new users accomplishing their task. They can ignore the warning, or choose merge as the default to shut up the warning (and it is easy to choose that if you are confused, because it is what git is doing by default alongside the warning). While I do not quite see the previous discussion as deciding the particular implementation is good without further tweaks, I would say that everybody agrees that the default behaviour is not good for everybody and therefore should (or for Linus, it is OK to) change. Rational people don't think in absolute terms, everyone means virtually everyone, which is the case. True for should change, not virtually everyone for should change with that particular solution. But after re-reading the series description 0/n this round in the other thread, I think the overall direction is good (just like Peff said in the previous thread), especially if there is a warning not error period. The step (I am not sure you have it in your series or not, but I would strongly recommend adding one if it doesn't yet) that gives a will change the default, and here is how to configure warning when we see an actual merge made (or rebased) after git pull without --merge/--rebase is not just a way to prepare existing users, but is a good way to bring new goodness to newbies. The session might go like this: $ git pull ... fetching ... ... merging ... ... diffstat ... warning: you merged the $branch from $remote into your warning: work, which may not be what you wanted to do unless warning: you are acting as a project integrator. If that is warning: the case, git config --set pull.mode ff-only to warning: cause git pull to refuse working when it does not warning: fast-forward. Use pull.mode=merge if you did mean warning: it, to squelch this message. I am not advocating the exact wording above, but am illustrating that there is a place for us to tell the new people to live in a better future before the switchover happens. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Matthieu Moy wrote: Felipe Contreras felipe.contre...@gmail.com writes: ... Yes, this has been discussed many times in the past, and everyone agrees the default behavior is not correct. You definitely have a strange notion of everyone. While I do not quite see the previous discussion as deciding the particular implementation is good without further tweaks, I would say that everybody agrees that the default behaviour is not good for everybody and therefore should (or for Linus, it is OK to) change. Yes. The only aspect I didn't see consensus is whether 'git pull $remote' should reject non-ff merges by default as well. I argued that 'git pull $remote' shouldn't behave differently than 'git pull', but I got no responses. Rational people don't think in absolute terms, everyone means virtually everyone, which is the case. True for should change, not virtually everyone for should change with that particular solution. I said 'everyone agrees the default behavior is not correct', which is true. But after re-reading the series description 0/n this round in the other thread, I think the overall direction is good (just like Peff said in the previous thread), especially if there is a warning not error period. The step (I am not sure you have it in your series or not, but I would strongly recommend adding one if it doesn't yet) that gives a will change the default, and here is how to configure warning when we see an actual merge made (or rebased) after git pull without --merge/--rebase is not just a way to prepare existing users, but is a good way to bring new goodness to newbies. The session might go like this: $ git pull ... fetching ... ... merging ... ... diffstat ... warning: you merged the $branch from $remote into your warning: work, which may not be what you wanted to do unless warning: you are acting as a project integrator. If that is warning: the case, git config --set pull.mode ff-only to warning: cause git pull to refuse working when it does not warning: fast-forward. Use pull.mode=merge if you did mean warning: it, to squelch this message. I am not advocating the exact wording above, but am illustrating that there is a place for us to tell the new people to live in a better future before the switchover happens. As I said, I already sent a patch similar to that, but I dropped it since this was for v2.0, and since I excepted this series to be ignored like so many. I'll resend. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On 14-04-30 10:55 AM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: But I'm definitely biased because I think pull is pretty much broken: * New users are encouraged to use pull, but all too often the default fetch-then-merge behaviour doesn't match their expectations and they end up starting threads like this one on the mailing list. * If we change pull's default behaviour, we'll just be shifting the mismatched expectations onto the other half of the new users who would be happy with fetch-then-merge. * I'm not sure why new users are taught to use pull. I suspect it's because it tries to hide the idea of local-vs-remote branches, and people writing git tutorials don't want to overwhelm new users with what seems to be an internal detail. But these notions are really fundamental to using git effectively, and I think pull does everyone a disservice by trying to gloss them over. Anyway, rather than ranting on I'll just suggest that there's not enough commonality between the ways people use git to make it worthwhile trying to teach pull how to deal with a significant number of them. I think the pull command should be deprecated and quietly retired as a failed experiment. I almost agree with the first sentence in the last paragraph, and your bulletted list above supports it. I am not sure how the second sentence can follow as its consequence. If the conclusion were maybe adding a 'git update' to match the expectation of those who build on top of the work of others (aka CVS/SVN style) more closely and teaching new users to use that instead of 'git pull' may be a good way forward, I can sort of understand (if I may not be able to immediately agree with, until I can regurgitate the ramifications of such a change) it. (Yum! You know, regurgitated ramifications aren't just for breakfast anymore... :) ) I think we would run into much the same problem with git update as we do with git pull. To wit, any git pull (or git update) implementation needs to make certain workflow assumptions. I think that no matter which assumptions are made, there will always be a significant proportion of new users[1] for whom the assumptions are wrong. This is why the command is broken. It's also why the let's change git pull discussions never seem to get anywhere: Attempting to make the command work in new user X's environment will make it not work in new user Y's. Whatever change is made to git pull, after a few months new user Y comes along and says it's wrong. And now we're seeing third-party tools, like TortoiseGit, using git pull (or the default git pull workflow model) and exposing yet more new users to workflow dissonance. I don't think we'll ever be able to create a One Git Pull To Rule Them All. At best we'll end up with something with enough knobs that it could be configured to work in most workflows (I think we're actually pretty close to that). But for new users that defeats the purpose. It means that git pull is really an advanced command, and beginners should avoid it until they understand enough of git to configure it properly. So rather than perpetuate the myth that one command can always (or even just usually) do the right thing, let's just retire the command. All that said, I don't object to any attempts at improving the command either. But I also don't see any kind of improvement that would lead me to start using git pull let alone recommending it to new users. M. [1] By significant I mean enough to perpetually create new mailing list threads about changing 'git pull'. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Matthieu Moy wrote: Felipe Contreras felipe.contre...@gmail.com writes: ... Yes, this has been discussed many times in the past, and everyone agrees the default behavior is not correct. You definitely have a strange notion of everyone. While I do not quite see the previous discussion as deciding the particular implementation is good without further tweaks, I would say that everybody agrees that the default behaviour is not good for everybody and therefore should (or for Linus, it is OK to) change. ... I said 'everyone agrees the default behavior is not correct', which is true. Isn't that what I said a few lines above? Why are you still arguing? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Marc Branchaud marcn...@xiplink.com writes: On 14-04-30 10:55 AM, Junio C Hamano wrote: Marc Branchaud marcn...@xiplink.com writes: ... Anyway, rather than ranting on I'll just suggest that there's not enough commonality between the ways people use git to make it worthwhile trying to teach pull how to deal with a significant number of them. I think the pull command should be deprecated and quietly retired as a failed experiment. I almost agree with the first sentence in the last paragraph, and your bulletted list above supports it. I am not sure how the second sentence can follow as its consequence. If the conclusion were maybe adding a 'git update' to match the expectation of those who build on top of the work of others (aka CVS/SVN style) more closely and teaching new users to use that instead of 'git pull' may be a good way forward, I can sort of understand (if I may not be able to immediately agree with, until I can regurgitate the ramifications of such a change) it. I think we would run into much the same problem with git update as we do with git pull Maybe I was unclear. I didn't mean replace 'pull' with 'update' everywhere. I meant Introduce 'update' that lets integrate your history into that from the remote, which is to integrate in a direction opposite from how 'pull' does. Then the downstream people (i.e. by definition, most of us) would use git update while integrators would use git pull. There is no workflow assumption if we do so. I don't think we'll ever be able to create a One Git Pull To Rule Them All. Yes, that is exactly why I mentioned git update. Another way not to make any workflow assumption is to ask the user to tell us. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Marc Branchaud wrote: All that said, I don't object to any attempts at improving the command either. But I also don't see any kind of improvement that would lead me to start using git pull let alone recommending it to new users. If git pull starts using --ff-only by default then I might start recommending it. I'm a little scared to look at the details of this thread. Hopefully once the topic matures and settles down a little it will be worthwhile to review, or if there's any way I can help before then, feel free to ask me privately. Thanks for your work, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Matthieu Moy wrote: Felipe Contreras felipe.contre...@gmail.com writes: ... Yes, this has been discussed many times in the past, and everyone agrees the default behavior is not correct. You definitely have a strange notion of everyone. While I do not quite see the previous discussion as deciding the particular implementation is good without further tweaks, I would say that everybody agrees that the default behaviour is not good for everybody and therefore should (or for Linus, it is OK to) change. ... I said 'everyone agrees the default behavior is not correct', which is true. Isn't that what I said a few lines above? Why are you still arguing? I'm not arguing, I'm clarifying what I said for Matthieu. What I said was a response to him. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Marc Branchaud wrote: All that said, I don't object to any attempts at improving the command either. But I also don't see any kind of improvement that would lead me to start using git pull let alone recommending it to new users. What is wrong when `git pull` merges a fast-forward? The problems with `git pull` come when you can't do a fast-forward merge, right? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On 14-04-30 04:01 PM, Junio C Hamano wrote: Maybe I was unclear. I didn't mean replace 'pull' with 'update' everywhere. I meant Introduce 'update' that lets integrate your history into that from the remote, which is to integrate in a direction opposite from how 'pull' does. That's what I understood. Then the downstream people (i.e. by definition, most of us) would use git update while integrators would use git pull. There is no workflow assumption if we do so. Isn't merge-or-rebase a workflow assumption? I don't think there's a good rule of thumb for that choice. Downstream-vs-Integrator doesn't seem like enough, nor does it seem as simple as 'git pull' should merge and 'git update' should rebase (or vice-versa). But maybe I'm wrong and there really is only one salient axis (be it that one or another). I don't think we'll ever be able to create a One Git Pull To Rule Them All. Yes, that is exactly why I mentioned git update. I doubt that a new, additional command with different workflow assumptions will be any more successful. Another way not to make any workflow assumption is to ask the user to tell us. Yes. But I wouldn't expect a new user to be able to answer. M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
On 14-04-30 04:14 PM, Felipe Contreras wrote: Marc Branchaud wrote: All that said, I don't object to any attempts at improving the command either. But I also don't see any kind of improvement that would lead me to start using git pull let alone recommending it to new users. What is wrong when `git pull` merges a fast-forward? Nothing. Everything. It depends. The problems with `git pull` come when you can't do a fast-forward merge, right? Some of them, maybe most of them. But the reason git pull is broken is that any solution to the problems that arise depend on the project's workflow. That would be fine if there was a workflow that suited some large majority of users, but there doesn't seem to be one. aside I dug up the workflows question from the 2012 user survey[1], but it's less revealing than one might like: 19. What git workflow(s) is used by projects in which development you participate? single developer, only private repository (no interaction) 67% centralized workflow (push to common repository)69% branched centralized (push to different branches in common repository) 50% peer-to-peer workflow (all repositories roughly equal) 9% integration-manager workflow (maintainer pulls/applies patches to blessed repository))19% dictator and lieutenants workflow (hierarchical workflow)5% using collaborative code review tool, e.g. Gerrit 13% other workflow, please explain 2% Total respondents 4352 Respondents who skipped this question 135 (IIRC, this was a check all that apply question.) I don't think this lets us conclude anything about the popularity of merging or rebasing, even though many respondents use a centralized workflow. I use a centralized workflow, and I will sometimes merge and sometimes rebase. It depends on the work I'm doing. /aside M. [1] https://www.survs.com/results/QPESOB10/ME8UTHXM4M -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pull is Evil
Marc Branchaud wrote: On 14-04-30 04:14 PM, Felipe Contreras wrote: Marc Branchaud wrote: All that said, I don't object to any attempts at improving the command either. But I also don't see any kind of improvement that would lead me to start using git pull let alone recommending it to new users. What is wrong when `git pull` merges a fast-forward? Nothing. Everything. It depends. It depends on what? I don't see how a fast-forward `git pull` could possibly have any trouble. The problems with `git pull` come when you can't do a fast-forward merge, right? Some of them, maybe most of them. Name one problem with a fast-forward merge. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
