Re: Pull is Mostly Evil
After poking this hornet's nest I pretty much have stood back and not participated in the ensuing discussions. But having unleashed the hornets I feel I should at least say something, if only to assure people that I'm not ignoring their plight. There have been various proposals to modify git-pull's defaults, and/or extend it with new configuration settings, and/or add a new command. As I don't use git pull I feel I'm not in any position to comment about the particulars of these proposals. However I remain skeptical that these proposals, in any form, will really be all that helpful to new users. That's because in order to know whether or not git pull (or git update) does what the user wants, the user has to understand the intricacies of both their own workflow and how git can work within that workflow. By the time a user gains that understanding, she is no longer a new user. Still, I do think the pull command is useful. In particular I think that a project can benefit greatly by tailoring pull's behaviour to match its workflow, and that a project's participants can be told how to configure git so that pull works properly for that project. Maybe even such configuration -- a workflow blueprint if you will -- can be tracked inside the project itself, so that a fresh project clone can automatically have git pull properly configured. To me this seems like a fabulous feature for git. But for now I go back to what I said before: Give git pull enough knobs to let people tailor it to their individual projects' needs. But also disable git pull by default, because nobody should run it until they've considered how they want it to work. 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
Beginner question on Pull is mostly evil
During my initial self-education I came across the maxim don't pull, fetch+merge instead and have been doing that. I think I followed most of the pull is (mostly) evil discussion but one facet still puzzles me: the idea that pull will do a merge in the wrong direction sometimes. Do I understand correctly that this occurs only in the presence of multiple remotes? Can someone provide a simple example of a situation where pull would do the wrong thing? Thanks -- 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: Beginner question on Pull is mostly evil
Jim Garrison jim.garri...@nwea.org writes: During my initial self-education I came across the maxim don't pull, fetch+merge instead and have been doing that. I think I followed most of the pull is (mostly) evil discussion but one facet still puzzles me: the idea that pull will do a merge in the wrong direction sometimes. Do I understand correctly that this occurs only in the presence of multiple remotes? Can someone provide a simple example of a situation where pull would do the wrong thing? That's basically unavoidable. Two opposing directions are actually part of the same workflow usually handled by git pull: Codeveloper X sends a pull request to Y who maintains the mainline. Y executes git pull to merge X' sidebranch into the mainline. Codeveloper X executes git pull in order to merge the mainline from Y back into his private sidebranch. -- 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: Beginner question on Pull is mostly evil
On Wed, May 07, 2014 at 03:40:28PM +, Jim Garrison wrote: During my initial self-education I came across the maxim don't pull, fetch+merge instead and have been doing that. I think I followed most of the pull is (mostly) evil discussion but one facet still puzzles me: the idea that pull will do a merge in the wrong direction sometimes. Do I understand correctly that this occurs only in the presence of multiple remotes? No, it does not have to do with multiple remotes. It is about X merged into Y versus Y merged into X. The ordering of parents in a merge doesn't matter for the merge result, but git must choose some order, and it always uses your current HEAD first, and then the commit you are merging second (and so on, in an octopus merge). As a result, you can use git log --first-parent to follow the line of development that always got merged into. In a strict topic-branch workflow like git.git, this will show you just what happened on master: a linear sequence of merges of topic branches, with occasional direct-to-master commits like version bumps. For an integrator who is pulling from other people, git pull bob topic from master does the right thing: master is the first parent, and topic is the second parent. For somebody with a centralized repo who follows the push was a non-fastforward, so pull then push advice, the merge between their work and master will be backwards. The merge commit will have upstream's work (i.e., master) merged into their topic. Following --first-parent will walk down their work instead of the merge commits on master. Does that explain it? -Peff -- 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: Beginner question on Pull is mostly evil
Jim Garrison jim.garri...@nwea.org writes: During my initial self-education I came across the maxim don't pull, fetch+merge instead and have been doing that. I think I followed most of the pull is (mostly) evil discussion but one facet still puzzles me: the idea that pull will do a merge in the wrong direction sometimes. [administrivia: wrap your lines to reasonable length like ~70 cols, please] Do I understand correctly that this occurs only in the presence of multiple remotes? No. This is most often true for people who use a single repository as a place for everybody to meet, in the same way as SVN. Suppose that that central repository has this history: ---o---o---A which ends at commit A (time flows from left to right and each node in the graph is a commit, lines between them indicating parent-child relationship). Then you clone it and work on your own commits, which leads you to have this in *your* repository: ---o---o---A---B---C Imagine your coworker did the same and built on top of A in *his* repository this history in the meantime, and then pushed it to the central repository: ---o---o---A---X---Y---Z Now, if you git push at this point, beause your history that leads to C lack X, Y and Z, it will fail. You need to somehow make the tip of your history a descendant of Z. One way that mostly evil thread discusses is to pull, which is fetch and then merge (note that I am saying don't pull, instead fetch and merge is not an advice to solve pull is mostly evil issue at all). If you fetch, your repository will have a history like this: ---o---o---A---B---C \ X---Y---Z And then if you did merge after that, while still on *your* branch, i.e. C, you will create a merge M and make the history look like this: ---o---o---A---B---C---M \ / X---Y---Z M is a descendant of Z, so you can push to update the central repository. Such a merge M does not lose any commit in both histories, so in that sense it may not be wrong, but when people would want to talk about the authoritative canonical history that is shared among the project participants, i.e. the trunk, the way they often use is to do: $ git log --first-parent For all other people who observed the central repository after your coworker pushed Z but before you pushed M, the commit on the trunk used to be o-o-A-X-Y-Z. But because you made M while you were on C, M's first parent is C, so by pushing M to advance the central repository, you made X-Y-Z a side branch, not on the trunk. You would rather want to have a history of this shape: ---o---o---A---X---Y---Z---M' \ / B---C so that in the first-parent chain, it is clear that the project first did X and then Y and then Z and merged a change that consists of two commits B and C that achieves a single goal. You may have worked on fixing the bug #12345 with these two patches, and the merge M' with swapped parents can say in its log message Merge 'fix-bug-12345'. Note that I said achieves a single goal above, because this is important. swapping the merge order only covers a special case where the project does not care too much about having unrelated things done on a single merge but cares a lot about first-parent chain. There are multiple schools of thought about the trunk management. 1. Some projects want to keep a completely linear history without any merges. Obviously, swapping the merge order would not help their taste. You would need to flatten your history on top of the updated upstream to result in a history of this shape instead: ---o---o---A---X---Y---Z---B---C with git pull --rebase or something. 2. Some projects tolerate merges in their history, but do not worry too much about the first-parent order, and allows fast-forward merges. To them, swapping the merge order does not hurt, but it is unnecessary. 3. Some projects want each commit on the trunk to do one single thing. The output of git log --first-parent in such a project would show either a merge of a side branch that completes a single theme, or a single commit that completes a single theme by itself. If your two commits B and C (or they may even be two groups of commits) were solving two independent issues, then the merge M' we made in the earlier example by swapping the merge order is still not up to the project standard. It merges two unrelated efforts B and C at the same time. For projects in the last category (git itself is one of them), individual developers would want to prepare a history more like this: C0--C1--C2 topic-c / ---o---o---Amaster \ B0--B1--B2 topic-b That is, keeping separate topics on separate branches, perhaps like so: $ git clone $URL work cd work
RE: Beginner question on Pull is mostly evil
-Original Message- From: Junio C Hamano Sent: Wednesday, May 07, 2014 1:16 PM Subject: Re: Beginner question on Pull is mostly evil No. This is most often true for people who use a single repository as a place for everybody to meet, in the same way as SVN. [snip lots of excellent detail] HTH. Wow. That helps tremendously, and should be incorporated somewhere in the Git documentation. Thank you for your immensely detailed response. Apologies about not breaking lines... I'll remember that in future. -- 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: Beginner question on Pull is mostly evil
Jim Garrison jim.garri...@nwea.org writes: -Original Message- From: Junio C Hamano Sent: Wednesday, May 07, 2014 1:16 PM Subject: Re: Beginner question on Pull is mostly evil No. This is most often true for people who use a single repository as a place for everybody to meet, in the same way as SVN. [snip lots of excellent detail] HTH. Wow. That helps tremendously, and should be incorporated somewhere in the Git documentation. Thank you for your immensely detailed response. We used to collect useful list postings in Documentation/howto/; perhaps somebody wants to do the minimum copyediting of the message and send a patch? -- 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 Mostly Evil
Hi. I might be late to this discussion, but here either something I don't understand or something is missed. On Sat, May 03, 2014 at 03:56:51AM -0400, Richard Hansen wrote: In my experience 'git pull' is mostly (only?) used for the following three tasks: 1. update a local branch to incorporate the latest upstream changes In this case, the local branch (master) is a derivative of the upstream branch (origin/master). The user wants all of the commits in the remote branch to be in the local branch. And the user would like the local changes, if any, to descend from the tip of the remote branch. For this case, 'git pull --ff-only' followed by 'git rebase -p' works well, as does 'git pull --rebase=preserve' if the user is comfortable rebasing without reviewing the incoming commits first. A plain 'git pull' or 'git pull --ff' is suboptimal due to the awkward backwards-parents merge commit. This is actually not a finally defined use case. What kind of local changes user can have ahead of the remote? As far I understand, there are 3 cases: 1a. Changes that are going to be merged back to the master, but not yet ready to be there. This is essentially the same as case 2, but it does not name the development branch explicitely. Switching parents for this case is not desirable. 1b. Some truly local changes which never goes anywhere. For this case the parent order does not matter. 1c. The local changes prepared for integration, but instead of filing a pull request of otherwise publishing the branch for integrator, the leaf developer does the integrator's job and merges it back to master and then publishing the master. As far as I understand, this is the only case when somebody would want the parents to be switched. And this does not seem to be a good practice, because it's prone to push races and requires letting everyone to push to master. So maybe git should not encourage people to do so. And the name update, proposed here, does not seem to be correct. Because what happens is not updating, but merging feature to master and closing it. 2. update a published feature branch with the latest changes from its parent branch 3. integrate a more-or-less complete feature/fix back into the line of development it forked off of -- Max -- 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: Beginner question on Pull is mostly evil
I'll create a patch. On Wednesday, May 07, 2014 01:51:04 PM Junio C Hamano wrote: Jim Garrison jim.garri...@nwea.org writes: -Original Message- From: Junio C Hamano Sent: Wednesday, May 07, 2014 1:16 PM Subject: Re: Beginner question on Pull is mostly evil No. This is most often true for people who use a single repository as a place for everybody to meet, in the same way as SVN. [snip lots of excellent detail] HTH. Wow. That helps tremendously, and should be incorporated somewhere in the Git documentation. Thank you for your immensely detailed response. We used to collect useful list postings in Documentation/howto/; perhaps somebody wants to do the minimum copyediting of the message and send a patch? -- 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 -- 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 Mostly Evil
Jeff King p...@peff.net writes: I realize this has veered off into talking about an update command, and not necessarily pull, but since there a lot of proposals floating around, I wanted to make one point: if we are going to do such a switch, let's please make it something the user explicitly turns on. I mentioned update in an attempt to suggest some way to avoid breaking git pull for people who do want to advane the history with real work (i.e. not just following along with fast-forwarding). A failed git push that suggests to pull first, which came from the original To emulate CVS workflow, you can pull, work, push, and if the push fails, pull again and then push in the early tutorial, turns out to be very bad in the trunk centric worldview. And I think the solution is to realize that we use git pull for two fairly differnt workflows. - You know you own the tip of the trunk (in the global view). You merge from other people to advance the global world view in a way that makes sense in the first-parent chain is the trunk worldview. That is what git pull [--no-ff] was designed to do, and it does it very well. - You have some work of yours (either you committed directly, you merged your own work done on a side branch, or you merged from other people using git pull) on top of a commit that used to be at the tip of the global world. You want to make sure that branch you are on is not missing what has happened while you are not communicating with the outside world. The problematic case is the latter, and by introducing a new command to do that well (which is *not* just about swapping the order of the parents, by the way), updating the leaf developer section of Everyday Git document and tutorials, and suggesting to use that upon failed git push, I think users would get a more pleasant experience. And move git pull into integrator section, a command that is not necessary for leaf developers. I am not married to the name update. I think the ideal behaviour of that leaf-developer command would be something along the lines of the following: - If we can fast-forward, do so and we are done. - Otherwise, we have a history of this shape: O \ -ABC \ X---Y---Z where A was where we forked, B was a merge the user made, C was a commit the user directly made, and X, Y, and Z (some of them may be merges) are the trunk history git pull would create a merge M whose parents are C Z, which is wrong from the first-parent is the trunk worldview. But recording the merge to have parents Z C does not give us the first-parent is the trunk worldview, in the presense of B. We would prefer to end up with a history more like this: -A O \ \ X---Y---Z---B'--C' so that your work, your contribution with two commits of yours, was to merge the work done on a side branch and then made one commit directly on top of it. Hence, I think the ideal behaviour of the new command is to replay the first-parent history on top of the updated tip of your upstream (which by the way is different from how rebase --preserve-merges works; it is more like how J6t wanted to make rebase --preserve-merges work, IIRC). After that, you can attempt to push, and it may fail again (because somebody has grown the shared history to have a child W of Z at the tip), in which case exactly the same git update would attempt to recreate a history of this shape: -A O \ \ X---Y---Z---W---B--C During a long transition period (essentially, waiting for the current crop of documents and tutorials to die out), we will need extra safety to prevent people, who merely wanted to bring their branch up to date, from running git pull, and I think the command needs to: - check which branch of what repository it is trying to pull; - check which branch of what repository it is going to update if git push is given; - if they are the same, then you are attempting to update from your upstream, so either warn or error out. If we are going to warn but make a merge anyway, the warning message *must* come at the very end of the output (and tell the user the way to recover is to reset one away and run the other command). Or something like that. -- 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 Mostly Evil
Junio C Hamano wrote: But recording the merge to have parents Z C does not give us the first-parent is the trunk worldview, in the presense of B. We would prefer to end up with a history more like this: -A O \ \ X---Y---Z---B'--C' so that your work, your contribution with two commits of yours, was to merge the work done on a side branch and then made one commit directly on top of it. Yes, _ideally_, but as it has been explained multiple times most Git beginners have no idea what is a rebase. We might evenaully do this by default, but first we should start rejecting the update by default and recommending `git update --merge` as it has been discussed quite a lot should be the behavior of `git pull`. Hence, I think the ideal behaviour of the new command is to replay the first-parent history on top of the updated tip of your upstream (which by the way is different from how rebase --preserve-merges works; it is more like how J6t wanted to make rebase --preserve-merges work, IIRC). What is the difference with 'rebase -p'? -- 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 Mostly Evil
On 2014-05-03 06:00, John Szakmeister wrote: FWIW, at my company, we took another approach. We introduced a `git ffwd` command that fetches from all remotes, and fast-forwards all your local branches that are tracking a remote, and everyone on the team uses it all the time. It should be said this team also likes to use Git bare-metal, because they like knowing how things work out-of-the-box. But they all use the command because it's so convenient. I also wrote a script to fast-forward all local branches to their configured upstream refs. I finally got around to uploading it somewhere public: https://github.com/richardhansen/git-update-branch I use it in my 'git up' alias: git config --global alias.up \ '!git remote update -p; git update-branch -a' If there's interest I can tweak the style to conform to Documentation/CodingGuidelines and stick it in contrib/ or something. -Richard -- 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 Mostly Evil
Richard Hansen wrote: On 2014-05-03 06:00, John Szakmeister wrote: FWIW, at my company, we took another approach. We introduced a `git ffwd` command that fetches from all remotes, and fast-forwards all your local branches that are tracking a remote, and everyone on the team uses it all the time. It should be said this team also likes to use Git bare-metal, because they like knowing how things work out-of-the-box. But they all use the command because it's so convenient. I also wrote a script to fast-forward all local branches to their configured upstream refs. I finally got around to uploading it somewhere public: https://github.com/richardhansen/git-update-branch I use it in my 'git up' alias: git config --global alias.up \ '!git remote update -p; git update-branch -a' If there's interest I can tweak the style to conform to Documentation/CodingGuidelines and stick it in contrib/ or something. I think this would fit perfectly in the proposed `git update` command as an option: `git update --all`. -- 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 Mostly Evil
Felipe Contreras felipe.contre...@gmail.com writes: David Lang wrote: note that this is one person taking the I don't see any commits from you so your opinion doesn't count attitude. Wrong. I said it doesn't count for the project. There are a number of commits from me that actually count. A few old core performance ones might have actually have affected my carbon footprint noticeably. The one currently in pu will probably not be called often enough for that but will at least have practical consequences. Do you honestly believe Junio cares about what some random guy on the list thinks about default aliases? No. Putting aside my code contributions: Git is a comparatively small project, so if the main project you are working on with Git is Git, your experience is limited. So yes, input from people who are _not_ heavy Git developers is important, since the heavy Git developers do not get to see the heavy Git use cases a lot. It's actually the exact opposite. I don't care what is the track record of the people in the discussion. If their argument is good, their argument is good. More like if they are around, they are worth getting plastered with your frustration. It's the others that focus on the carisma and credentials of the people in the discussion, rather than the arguments. I think you are confusing inertia with resistance. -- 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 Mostly Evil
Felipe Contreras wrote: David Lang wrote: the vast majority of people here do not take that attitude. It's actually the exact opposite. I don't care what is the track record of the people in the discussion. Ah, yes, like that discussion we once had where you totally didn't run `git log | grep James Denholm` at one point to demonstrate that I had not yet made any contributions,instead of actually engaging in discussion. Oh, wait. If their argument is good, their argument is good. The problem, though, is that time and time again you've shown that you value your own arguments to the exclusion of all others. You can't tell if someone else's argument is good, because it runs against yours, and yours must be right because you hold it. Regards, James Denholm. -- 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 Mostly Evil
James Denholm nod.h...@gmail.com writes: Felipe Contreras wrote: David Lang wrote: the vast majority of people here do not take that attitude. It's actually the exact opposite. I don't care what is the track record of the people in the discussion. Ah, yes, like that discussion we once had where you totally didn't run `git log | grep James Denholm` at one point to demonstrate that I had not yet made any contributions,instead of actually engaging in discussion. Oh, wait. It's called an ad hominem attack, and it's a very common and very effective rhetorical device. Cf URL:http://thread.gmane.org/gmane.comp.version-control.git/246598/focus=247002 The problem, though, is that time and time again you've shown that you value your own arguments to the exclusion of all others. You can't tell if someone else's argument is good, because it runs against yours, and yours must be right because you hold it. If he considered others capable of independent thought, would he call out their imperviousness to rhetorics as a deficiency? -- 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 Mostly Evil
On 2014-05-03 23:08, Felipe Contreras wrote:
Richard Hansen wrote:
Or are you proposing that pull --merge should reverse the parents if and
only if the remote ref is @{u}?
Only if no remote or branch are specified `git pull --merge`.
OK. Let me summarize to make sure I understand your full proposal:
1. if plain 'git pull', default to --ff-only
2. if 'git pull --merge', default to --ff. If the local branch can't
be fast-forwarded to the upstream branch, then create a merge
commit where the local branch is the *second* parent, not the first
3. if 'git pull $remote [$refspec]', default to --merge --ff. If the
local branch can't be fast-forwarded to the remote branch, then
create a merge commit where the remote branch is the second parent
(the current behavior)
Is that accurate?
If we change 'git pull' to default to --ff-only but let 'git pull
$remote [$refspec]' continue to default to --ff then we have two
different behaviors depending on how 'git pull' is invoked. I'm worried
that this would trip up users. I'm not convinced that having two
different behaviors would be bad, but I'm not convinced that it would be
good either.
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives in my
earlier email (though not in the form of code), and others have too. In
particular:
* create a new 'git integrate' command/alias that behaves like 'git
pull --no-ff'
* change 'git pull' and 'git pull $remote [$refspec]' to do --ff-only
by default
Another option that I just thought of: Instead of your proposed
pull.mode and branch.name.pullmode, add the following two sets of configs:
* pull.updateMode, branch.name.pullUpdateMode:
The default mode to use when running 'git pull' without naming a
remote repository or when the named remote branch is @{u}. Valid
options: ff-only (default), merge-ff, merge-ff-there, merge-no-ff,
merge-no-ff-there, rebase, rebase-here, rebase-here-then-merge-no-ff
* pull.integrateMode, branch.name.pullIntegrateMode:
The default mode to use when running 'git pull $remote [$refspec]'
when '$remote [$refspec]' is not @{u}. Valid options are the same
as those for pull.updateMode. Default is merge-ff.
This gives the default split behavior as you propose, but the user can
reconfigure to suit personal preference (and we can easily change the
default for one or the other if there's too much outcry).
Moreover, while it's a bit worrisome, it wouldn't create any actual
problems. Since `git pull $what` remains the same, there's no problems
there. The only change would be on `git pull`.
Since most users are not going to do `git pull $what` therefore it would
only be a small subset of users that would notice the discrepancy
between running with $what, or not. And the only discrepancy they could
notice is that when they run `git pull $what` they expect it to be
--ff-only, or when the run `git pull` they don't. Only the former could
be an issue, but even then, it's highly unlikely that `git pull $what`
would ever be a fast-forward.
So althought conceptually it doesn't look clean, in reality there
wouldn't be any problems.
Yes, it might not be a problem, but I'm still nervous. I'd need more
input (e.g., user survey, broad mailing list consensus, long beta test
period, decree by a benevolent dictator) before I'd be comfortable with it.
3. integrate a more-or-less complete feature/fix back into the line
of development it forked off of
In this case the local branch is a primary line of development and
the remote branch contains the derivative work. Think Linus
pulling in contributions. Different situations will call for
different ways to handle this case, but most will probably want
some or all of:
* rebase the remote commits onto local HEAD
No. Most people will merge the remote branch as it is. There's no reason
to rebase, specially if you are creating a merge commit.
I disagree. I prefer to rebase a topic branch before merging (no-ff) to
the main line of development for a couple of reasons:
Well that is *your* preference. Most people would prefer to preserve the
history.
Probably. My point is that the behavior should be configurable, and I'd
like that particular behavior to be one of the options (but not the
default -- that wouldn't be appropriate).
* It makes commits easier to review.
The review in the vast majority of cases happens *before* the
integration.
True, although even when review happens before integration there is
value in making code archeology easier.
And the problem comes when the integrator makes a mistake, which they
inevitable do (we all do), then there's no history about how the
conflict was resolved, and what whas the original patch.
Good point, although if I was the integrator and there was a
particularly hairy conflict I'd still rebase but
Re: Pull is Mostly Evil
James Denholm wrote: Felipe Contreras wrote: David Lang wrote: the vast majority of people here do not take that attitude. It's actually the exact opposite. I don't care what is the track record of the people in the discussion. Ah, yes, like that discussion we once had where you totally didn't run `git log | grep James Denholm` at one point to demonstrate that I had not yet made any contributions,instead of actually engaging in discussion. Oh, wait. You mean this thread[1] in which I sent 14 mails directly to you? Yeah, I din't engage in that discussion at all! And the point I was making is that if I manage to show the community was wrong in some thing (as you claimed), that community wouldn't include you. If their argument is good, their argument is good. The problem, though, is that time and time again you've shown that you value your own arguments to the exclusion of all others. You can't tell if someone else's argument is good, because it runs against yours, and yours must be right because you hold it. I can show you evidence of how that's a blatant lie. Just two days ago I changed my mind because somebody provided a good argument. But I'm not going to bother any more with you, you are just spreading lies and tainting the discussion. [1] http://thread.gmane.org/gmane.comp.version-control.git/247188/focus=247584 -- 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 Mostly Evil
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
Richard Hansen wrote:
Or are you proposing that pull --merge should reverse the parents if and
only if the remote ref is @{u}?
Only if no remote or branch are specified `git pull --merge`.
OK. Let me summarize to make sure I understand your full proposal:
1. if plain 'git pull', default to --ff-only
2. if 'git pull --merge', default to --ff. If the local branch can't
be fast-forwarded to the upstream branch, then create a merge
commit where the local branch is the *second* parent, not the first
3. if 'git pull $remote [$refspec]', default to --merge --ff. If the
local branch can't be fast-forwarded to the remote branch, then
create a merge commit where the remote branch is the second parent
(the current behavior)
Is that accurate?
Yes, that is accurate. Note that 3. is the current behavior.
If we change 'git pull' to default to --ff-only but let 'git pull
$remote [$refspec]' continue to default to --ff then we have two
different behaviors depending on how 'git pull' is invoked. I'm worried
that this would trip up users. I'm not convinced that having two
different behaviors would be bad, but I'm not convinced that it would be
good either.
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives in my
earlier email (though not in the form of code), and others have too. In
particular:
* create a new 'git integrate' command/alias that behaves like 'git
pull --no-ff'
Yeah but that's for a different issue altogheter. I doesn't solve the
problems in 1. nor 2. nor 3.
* change 'git pull' and 'git pull $remote [$refspec]' to do --ff-only
by default
Another option that I just thought of: Instead of your proposed
pull.mode and branch.name.pullmode, add the following two sets of configs:
* pull.updateMode, branch.name.pullUpdateMode:
The default mode to use when running 'git pull' without naming a
remote repository or when the named remote branch is @{u}. Valid
options: ff-only (default), merge-ff, merge-ff-there, merge-no-ff,
merge-no-ff-there, rebase, rebase-here, rebase-here-then-merge-no-ff
Those are way too many options to be able to sensibly explain them.
* pull.integrateMode, branch.name.pullIntegrateMode:
The default mode to use when running 'git pull $remote [$refspec]'
when '$remote [$refspec]' is not @{u}. Valid options are the same
as those for pull.updateMode. Default is merge-ff.
This gives the default split behavior as you propose, but the user can
reconfigure to suit personal preference (and we can easily change the
default for one or the other if there's too much outcry).
If we reduce the number of options to begin with (more can be added
later), then it might make sense to have these two options.
However, that doesn't change the proposal you described above (1. 2.
3.).
Moreover, while it's a bit worrisome, it wouldn't create any actual
problems. Since `git pull $what` remains the same, there's no problems
there. The only change would be on `git pull`.
Since most users are not going to do `git pull $what` therefore it would
only be a small subset of users that would notice the discrepancy
between running with $what, or not. And the only discrepancy they could
notice is that when they run `git pull $what` they expect it to be
--ff-only, or when the run `git pull` they don't. Only the former could
be an issue, but even then, it's highly unlikely that `git pull $what`
would ever be a fast-forward.
So althought conceptually it doesn't look clean, in reality there
wouldn't be any problems.
Yes, it might not be a problem, but I'm still nervous. I'd need more
input (e.g., user survey, broad mailing list consensus, long beta test
period, decree by a benevolent dictator) before I'd be comfortable with it.
The user surveys are not happening any more. The results were ignored by
the developers anyway.
Mailing list consensus might be possible, but that wouldn't tell us
much.
There's something we can do, and let me clarify my proposal. What you
described above is what I think should happen eventually, however, we
can start by doing something like what my patch series is doing; issue a
warning that the merge is not fast-forward and things might change in
the future.
If people find this behavior confusing they will complain in the mailing
list. Although I suspect it would be for other reasons, not the 'git
pull'/'git pull $there' division. Either way we would see in the
discussion.
3. integrate a more-or-less complete feature/fix back into the line
of development it forked off of
In this case the local branch is a primary line of development and
the remote branch contains the derivative work. Think Linus
pulling in contributions. Different situations will
Re: Pull is Mostly Evil
On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: Felipe Contreras wrote: David Lang wrote: the vast majority of people here do not take that attitude. It's actually the exact opposite. I don't care what is the track record of the people in the discussion. Ah, yes, like that discussion we once had where you totally didn't run `git log | grep James Denholm` at one point to demonstrate that I had not yet made any contributions,instead of actually engaging in discussion. Oh, wait. You mean this thread[1] in which I sent 14 mails directly to you? Yeah, I din't engage in that discussion at all! Yeah, you didn't. Instead you danced, but I guess it's really all said and done now so eh, have your point. If their argument is good, their argument is good. The problem, though, is that time and time again you've shown that you value your own arguments to the exclusion of all others. You can't tell if someone else's argument is good, because it runs against yours, and yours must be right because you hold it. I can show you evidence of how that's a blatant lie. Just two days ago I changed my mind because somebody provided a good argument. And I can show you evidence of you being indiscourseable on the topic of your pet proposals, but I won't, because you're indiscourseable on the meta similarly. But I'm not going to bother any more with you, you are just spreading lies and tainting the discussion. Well, maybe we'll see what other folks think. Regards, James Denholm. -- 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 Mostly Evil
James Denholm nod.h...@gmail.com writes: On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: But I'm not going to bother any more with you, you are just spreading lies and tainting the discussion. Well, maybe we'll see what other folks think. According to whose summary? URL:https://www.youtube.com/watch?v=2eMkth8FWno -- 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 Mostly Evil
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives in my
earlier email (though not in the form of code), and others have too. In
particular:
* create a new 'git integrate' command/alias that behaves like 'git
pull --no-ff'
Yeah but that's for a different issue altogheter. I doesn't solve the
problems in 1. nor 2. nor 3.
'git integrate' would handle usage cases #2 (update a published branch
to its parent branch) and #3 (integrate a completed task into the main
line of development), making it feasible to change 'git pull' and 'git
pull $remote [$refspec]' to default to --ff-only to handle usage case #1
(update local branch to @{u}).
* change 'git pull' and 'git pull $remote [$refspec]' to do --ff-only
by default
Another option that I just thought of: Instead of your proposed
pull.mode and branch.name.pullmode, add the following two sets of configs:
* pull.updateMode, branch.name.pullUpdateMode:
The default mode to use when running 'git pull' without naming a
remote repository or when the named remote branch is @{u}. Valid
options: ff-only (default), merge-ff, merge-ff-there, merge-no-ff,
merge-no-ff-there, rebase, rebase-here, rebase-here-then-merge-no-ff
Those are way too many options to be able to sensibly explain them.
Certainly this is too many options for a first patch series, but I don't
think they're unexplainable. (I listed a bunch of options because I was
trying to envision where this might take us in the long run.)
For the first patch series, I'd expect: merge (which uses the merge.ff
option to determine whether to ff, ff-only, or no-ff), rebase, and ff-only.
Later ff-only would be made the default.
Later some or all of the other options would be added depending on user
interest.
* pull.integrateMode, branch.name.pullIntegrateMode:
The default mode to use when running 'git pull $remote [$refspec]'
when '$remote [$refspec]' is not @{u}. Valid options are the same
as those for pull.updateMode. Default is merge-ff.
This gives the default split behavior as you propose, but the user can
reconfigure to suit personal preference (and we can easily change the
default for one or the other if there's too much outcry).
If we reduce the number of options to begin with (more can be added
later),
yup
then it might make sense to have these two options.
However, that doesn't change the proposal you described above (1. 2.
3.).
Not sure what you mean. I oulined three usage cases:
#1 update local branch to @{u}
#2 update a published branch to its parent branch
#3 integrate a completed task into the main line of development
Having these two sets of options (updateMode and integrateMode) would
make it possible to configure plain 'git pull' to handle usage case #1
and 'git pull $remote [$refspec]' to handle usage cases #2 and #3.
Or the user could configure 'git pull' and 'git pull $remote [$refspec]'
to behave the same, in case they find the different behaviors to be too
confusing.
There's something we can do, and let me clarify my proposal. What you
described above is what I think should happen eventually, however, we
can start by doing something like what my patch series is doing; issue a
warning that the merge is not fast-forward and things might change in
the future.
OK, let me rephrase to make sure I understand:
1. leave the default behavior as-is for now (merge with local
branch the first parent)
2. add --merge argument
3. add ff-only setting
4. plan to eventually change the plain 'git pull' default to ff-only,
but don't change the default yet
5. add a warning if the plain 'git pull' is a non-ff
6. wait and see how users react. If they're OK with it, switch the
default of the plain 'git pull' to ff-only.
Is that accurate? If so, sounds OK to me.
If people find this behavior confusing they will complain in the mailing
list.
true
Although I suspect it would be for other reasons, not the 'git
pull'/'git pull $there' division.
probably
Either way we would see in the discussion.
sounds good to me
3. integrate a more-or-less complete feature/fix back into the line
of development it forked off of
In this case the local branch is a primary line of development and
the remote branch contains the derivative work. Think Linus
pulling in contributions. Different situations will call for
different ways to handle this case, but most will probably want
some or all of:
* rebase the remote commits onto local HEAD
No. Most people will merge the remote branch as it is. There's no reason
to rebase, specially if you are creating a merge commit.
I disagree. I prefer to rebase a topic branch before merging (no-ff) to
the main line of development for a
Re: Pull is Mostly Evil
Richard Hansen wrote:
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives in my
earlier email (though not in the form of code), and others have too. In
particular:
* create a new 'git integrate' command/alias that behaves like 'git
pull --no-ff'
Yeah but that's for a different issue altogheter. I doesn't solve the
problems in 1. nor 2. nor 3.
'git integrate' would handle usage cases #2 (update a published branch
to its parent branch) and #3 (integrate a completed task into the main
line of development),
But these cases are completely different. One should reverse the
parents, the other one not.
I feel if a new command is to be added, it should be the one that is
introducing the brand new behavior: switching the parents. So it would
be appropriate for 1. and 2.
* change 'git pull' and 'git pull $remote [$refspec]' to do --ff-only
by default
Another option that I just thought of: Instead of your proposed
pull.mode and branch.name.pullmode, add the following two sets of
configs:
* pull.updateMode, branch.name.pullUpdateMode:
The default mode to use when running 'git pull' without naming a
remote repository or when the named remote branch is @{u}. Valid
options: ff-only (default), merge-ff, merge-ff-there, merge-no-ff,
merge-no-ff-there, rebase, rebase-here, rebase-here-then-merge-no-ff
Those are way too many options to be able to sensibly explain them.
Certainly this is too many options for a first patch series, but I don't
think they're unexplainable. (I listed a bunch of options because I was
trying to envision where this might take us in the long run.)
Actually I think they are too many for any point in time.
Maybe pull.updateArgs would make more sense.
For the first patch series, I'd expect: merge (which uses the merge.ff
option to determine whether to ff, ff-only, or no-ff), rebase, and ff-only.
Seems sensible.
then it might make sense to have these two options.
However, that doesn't change the proposal you described above (1. 2.
3.).
Not sure what you mean. I oulined three usage cases:
#1 update local branch to @{u}
#2 update a published branch to its parent branch
#3 integrate a completed task into the main line of development
Having these two sets of options (updateMode and integrateMode) would
make it possible to configure plain 'git pull' to handle usage case #1
and 'git pull $remote [$refspec]' to handle usage cases #2 and #3.
Not if by default they are already handled.
There's something we can do, and let me clarify my proposal. What you
described above is what I think should happen eventually, however, we
can start by doing something like what my patch series is doing; issue a
warning that the merge is not fast-forward and things might change in
the future.
OK, let me rephrase to make sure I understand:
1. leave the default behavior as-is for now (merge with local
branch the first parent)
2. add --merge argument
3. add ff-only setting
4. plan to eventually change the plain 'git pull' default to ff-only,
but don't change the default yet
5. add a warning if the plain 'git pull' is a non-ff
6. wait and see how users react. If they're OK with it, switch the
default of the plain 'git pull' to ff-only.
Is that accurate? If so, sounds OK to me.
That is what my patch series is doing already, basically.
The new warning I'm proposing would be for the split behavior of 'git
merge' and 'git merge $there'. Which is what is worrysome.
mode = rebase-here-then-merge-no-ff would do what I described
I think that mode is way too specific to be useful for most people.
--
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 Mostly Evil
On 2014-05-04 17:13, Felipe Contreras wrote: Richard Hansen wrote: On 2014-05-04 06:17, Felipe Contreras wrote: Richard Hansen wrote: On 2014-05-03 23:08, Felipe Contreras wrote: It is the only solution that has been proposed. It's not the only proposal -- I proposed a few alternatives in my earlier email (though not in the form of code), and others have too. In particular: * create a new 'git integrate' command/alias that behaves like 'git pull --no-ff' Yeah but that's for a different issue altogheter. I doesn't solve the problems in 1. nor 2. nor 3. 'git integrate' would handle usage cases #2 (update a published branch to its parent branch) and #3 (integrate a completed task into the main line of development), But these cases are completely different. One should reverse the parents, the other one not. No -- for both #2 and #3 I want the remote branch to be merged into the local branch. In the example I gave for use case #2, foo is a local branch with origin/foo as the configured upstream and origin/foo was forked off of origin/master. Someone pushed new stuff to origin/master, and the user wants the new stuff to also be in origin/foo. So the user does this: git checkout foo git pull --ff-only # this is use case #1 git pull origin master # this is use case #2 git push The merge commit created by 'git pull origin master' should have origin/master as the second parent, not the first. -Richard -- 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 Mostly Evil
Richard Hansen wrote: On 2014-05-04 17:13, Felipe Contreras wrote: Richard Hansen wrote: On 2014-05-04 06:17, Felipe Contreras wrote: Richard Hansen wrote: On 2014-05-03 23:08, Felipe Contreras wrote: It is the only solution that has been proposed. It's not the only proposal -- I proposed a few alternatives in my earlier email (though not in the form of code), and others have too. In particular: * create a new 'git integrate' command/alias that behaves like 'git pull --no-ff' Yeah but that's for a different issue altogheter. I doesn't solve the problems in 1. nor 2. nor 3. 'git integrate' would handle usage cases #2 (update a published branch to its parent branch) and #3 (integrate a completed task into the main line of development), But these cases are completely different. One should reverse the parents, the other one not. No -- for both #2 and #3 I want the remote branch to be merged into the local branch. I didn't mean #2 and #3, I meant (#1) vs. (#2, #3). -- 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 Mostly Evil
On 2014-05-02 14:13, Junio C Hamano wrote: Stepping back even further, and thinking what is different between these two pulls, we notice that the first one is pulling from the place we push back to. I think the fundamental difference is in the relationship between the local and the remote branch (which branch derives from the other). The relationship between the branches determines what the user wants from 'git pull'. In my experience 'git pull' is mostly (only?) used for the following three tasks: 1. update a local branch to incorporate the latest upstream changes In this case, the local branch (master) is a derivative of the upstream branch (origin/master). The user wants all of the commits in the remote branch to be in the local branch. And the user would like the local changes, if any, to descend from the tip of the remote branch. For this case, 'git pull --ff-only' followed by 'git rebase -p' works well, as does 'git pull --rebase=preserve' if the user is comfortable rebasing without reviewing the incoming commits first. A plain 'git pull' or 'git pull --ff' is suboptimal due to the awkward backwards-parents merge commit. 2. update a published feature branch with the latest changes from its parent branch In this case, the local branch (foo) is a derivative of the upstream branch (origin/foo) which is itself a derivative of another branch (origin/master). All commits in origin/master should be in origin/foo, and ideally all commits unique to origin/foo would descend from the tip of origin/master. The relationship between origin/foo and origin/master is similar to the relationship between master and origin/master in case #1 above, but rebase is frowned upon because the feature branch has been shared with other developers (and the shared repository might reject non-ff updates). This case is sort-of like case #1 above (updating) and sort-of like case #3 below (integrating). For this case, after the local branch foo is updated (case #1 above), 'git pull --ff origin master' or 'git fetch --all git merge --ff origin/master' work well to update origin/foo. 3. integrate a more-or-less complete feature/fix back into the line of development it forked off of In this case the local branch is a primary line of development and the remote branch contains the derivative work. Think Linus pulling in contributions. Different situations will call for different ways to handle this case, but most will probably want some or all of: * rebase the remote commits onto local HEAD * merge into local HEAD so that the first parent (if a real merge and not a ff) is the previous version of the main line of development and the second parent is the derivative work * merge --no-ff so that: - the merge can serve as a cover letter (who reviewed it, which bug reports were fixed, where the changes came from, etc.) - the commits that compose the new topic are grouped together - the first-parent path represents a series of completed tasks (I prefer to do all three, although I may skip the rebase if the commits came from another public repository so as to not annoy users of that downstream repository.) For this case, 'git pull --no-ff' is better than 'git pull --ff' (for the reasons listed above), but perhaps something more elaborate would be ideal (e.g., rebase there onto here, then merge --no-ff). These three usage patterns are at odds; it's hard to change the default behavior of 'git pull' to favor one usage case without harming another. Perhaps this is why there's so much disagreement about what 'git pull' should do. I see a few ways to improve the situation: 1. Add one or two new commands to split up how the three cases are handled. For example: * Add a new 'git update' command that is friendly for case #1. Update tutorials to recommend 'git update' instead of 'git pull'. It would behave like 'git pull --ff-only' by default. It could behave like 'git pull --rebase[=preserve]' instead, but this has a few downsides: - It doesn't give the user an opportunity to review the incoming commits before rebasing (e.g., to see what sort of conflicts to expect). - It subjects new users to that scary rebase thing before they are prepared to handle it. - The branch to be updated must be checked out. If 'git update' used --ff-only, then 'git update --all' could fast-forward all local branches to their configured upstreams when possible. (How cool would that be?) * Leave 'git pull' and 'git pull $remote [$refspec]' alone -- the current defaults are acceptable (though maybe not ideal) for cases #2 and #3. Another example:
Re: Pull is Mostly Evil
Richard Hansen rhan...@bbn.com writes: These three usage patterns are at odds; it's hard to change the default behavior of 'git pull' to favor one usage case without harming another. Perhaps this is why there's so much disagreement about what 'git pull' should do. Should a screwdriver be turning clockwise or counterclockwise by default? There are valid arguments for either. -- 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 Mostly Evil
David Kastrup wrote: Richard Hansen rhan...@bbn.com writes: These three usage patterns are at odds; it's hard to change the default behavior of 'git pull' to favor one usage case without harming another. Perhaps this is why there's so much disagreement about what 'git pull' should do. Should a screwdriver be turning clockwise or counterclockwise by default? There are valid arguments for either. If you don't have anything to contribute don't disturb the people that actually care and are trying to improve Git. Thanks. -- 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 Mostly Evil
Richard Hansen wrote: I think the fundamental difference is in the relationship between the local and the remote branch (which branch derives from the other). The relationship between the branches determines what the user wants from 'git pull'. In my experience 'git pull' is mostly (only?) used for the following three tasks: I agree. 1. update a local branch to incorporate the latest upstream changes In this case, the local branch (master) is a derivative of the upstream branch (origin/master). The user wants all of the commits in the remote branch to be in the local branch. And the user would like the local changes, if any, to descend from the tip of the remote branch. My current propsal of making `git pull` by default do --ff-only would solve this. In addition I think by default 'master' should be merged to 'origin/master', if say --merge is given. For this case, 'git pull --ff-only' followed by 'git rebase -p' works well, as does 'git pull --rebase=preserve' if the user is comfortable rebasing without reviewing the incoming commits first. I suppose you mean a `git rebase -p` if the `git pull --ff-only` failed. This might be OK on most projects, but not all. What happens after a `git pull --ff-only` fails should be totally up to the user. 2. update a published feature branch with the latest changes from its parent branch In this case, the local branch (foo) is a derivative of the upstream branch (origin/foo) which is itself a derivative of another branch (origin/master). All commits in origin/master should be in origin/foo, and ideally all commits unique to origin/foo would descend from the tip of origin/master. I don't understand why are you tainting the example with 'origin/foo', 'foo' and 'origin/master' are enough for this example. In fact, the mention of 'origin/master' made it wrong: after the pull not all the commits of origin/master would be in origin/foo, you need a push for that. We have enough in our plate to taint this with yet another branch and push. For this case `git pull origin master` already work correctly for most projects. We probably shouldn't change that. 3. integrate a more-or-less complete feature/fix back into the line of development it forked off of In this case the local branch is a primary line of development and the remote branch contains the derivative work. Think Linus pulling in contributions. Different situations will call for different ways to handle this case, but most will probably want some or all of: * rebase the remote commits onto local HEAD No. Most people will merge the remote branch as it is. There's no reason to rebase, specially if you are creating a merge commit. * merge into local HEAD so that the first parent (if a real merge and not a ff) is the previous version of the main line of development and the second parent is the derivative work * merge --no-ff so that: - the merge can serve as a cover letter (who reviewed it, which bug reports were fixed, where the changes came from, etc.) - the commits that compose the new topic are grouped together - the first-parent path represents a series of completed tasks It is very rare that an integrator is even able to do a fast-forward merge anyway. So being explicit about --no-ff might better, but it would hardly make a difference. Either way, a good integrator would configure pull.ff = false. I'd say `git pull origin master` already works fine for this 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 Mostly Evil
Felipe Contreras felipe.contre...@gmail.com writes: David Kastrup wrote: Richard Hansen rhan...@bbn.com writes: These three usage patterns are at odds; it's hard to change the default behavior of 'git pull' to favor one usage case without harming another. Perhaps this is why there's so much disagreement about what 'git pull' should do. Should a screwdriver be turning clockwise or counterclockwise by default? There are valid arguments for either. If you don't have anything to contribute don't disturb the people that actually care and are trying to improve Git. Thanks. No need to expand on the welcoming atmosphere here. My heinous plot to subvert the quality of Git has already been thwarted by making sure that its meritocracy continues relying only on input from those with an independent income. I'm just sticking around until my current contributions move into master so that I can summarize the resulting low-hanging fruit that the meritorious can then pick at great fanfare. The sooner my work moves from pu into master, the sooner y'all be rid of me. -- 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 Mostly Evil
On Fri, May 2, 2014 at 2:13 PM, Junio C Hamano gits...@pobox.com wrote: [snip] Your earlier long-hand, together with the two examples that pulls into the same maint branch Brian gave us, may give us a better starting points to think about a saner way. To me, the problem sounds like: Tutorials of Git often says use 'git pull' to catch up your branch with your upstream work and then 'git push' back (and worse yet, 'git push' that does not fast-forward suggests doing so), but 'git pull' that creates a merge in a wrong direction is not the right thing for many people. Yes, that's a good portion of the problem. And proposed solutions range from let's write 'pull' off as a failed experiment to let's forbid any merge made by use of 'pull' by default, because it is likely that merge may be in reverse. FWIW, at my company, we took another approach. We introduced a `git ffwd` command that fetches from all remotes, and fast-forwards all your local branches that are tracking a remote, and everyone on the team uses it all the time. It should be said this team also likes to use Git bare-metal, because they like knowing how things work out-of-the-box. But they all use the command because it's so convenient. I had started making a C version a while back, but never completed it. I could take a stab at doing so again, if there's interest. -John -- 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 Mostly Evil
From: Felipe Contreras felipe.contre...@gmail.com Sent: Saturday, May 03, 2014 12:23 AM Philip Oakley wrote: From: Felipe Contreras felipe.contre...@gmail.com So? No defaults can please absolutely everyone, the best anybody can do is try to please the majority of people, and merging fast-forwards only does that. That assumes that doing something is better than doing nothing, When doing something is better for the vast majority of people, that's what should be done by default, unless the results are catastrophic for the minority. Since doing something is not catastrophic to the minority, it follows that the default should be to do something. That 'Since' and 'it follows' are where we have a diverging understanding about the solution approach... It's a simple as that. ... which makes it not quite as simple as that ;-) [evidence: the ongoing dialog among all and sundry] -- Felipe Contreras -- 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 Mostly Evil
Philip Oakley wrote: From: Felipe Contreras felipe.contre...@gmail.com When doing something is better for the vast majority of people, that's what should be done by default, unless the results are catastrophic for the minority. Since doing something is not catastrophic to the minority, it follows that the default should be to do something. It's a simple as that. ... which makes it not quite as simple as that ;-) [evidence: the ongoing dialog among all and sundry] The dialog is not simple becuase it's not easy to make `git pull` do the sensible thing. That doesn't mean `git pull` should do *nothing*, that doesn't follow from the argument above. -- 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 Mostly Evil
From: Jonathan Nieder jrnie...@gmail.com
Sent: Friday, May 02, 2014 11:53 PM
Hi,
Philip Oakley wrote:
That assumes that [git pull] doing something is better than doing
nothing,
which is appropriate when the costs on either side are roughly
similar.
I think the conversation's going around in circles.
I agree it's going around, but it's a non-exact recurrence. Issues are
being surfaced.
Potential next steps:
a. Documentation or test patch illustrating desired behavior
b. More traditional formal design doc explaining desired behavior and
the thinking behind it (problem, overview of solution,
alternatives rejected, complications, example, open
questions).
c. Implementation patch
d. Someone takes an existing patch and figures out the next step
toward getting it ready for application.
My preference is for (a), I guess.
I disagree about the leap to the presentation discussion of a
'solution' in these awkward scenarios (the old joke about if I were you
I wouldn't start from here, when asking for directions tends to apply).
This is the same point made by Brooks in the 'Mythical Man Month'. A
leap to code is no guarantee of success.
The point being that something more concrete (code or a design doc)
makes it easier to avoid talking past each other. And having
something concrete to edit makes the stakes clearer so people can make
it incrementally better without being distracted by unimportant parts.
We've had Junio's training wheel, and now Filipe's n'th attempt at code
examples, so my bad code wouldn't help ;-). As a systems engineer I've
seen these confusions quite a few times in different guises.
I tend to fall back to P Checkland's Systems Thinking, Systems
Practice model of the various processes that have to go on [1] to
improve the situation (note he doesn't expect a solved solution in most
cases, just an improvement in the situation). At the moment most of the
discussion is in the unstructured parts of the processes. He also
identifies 6 elements 'CATWOE' [2] that need to be considered when
studying these problems.
Most of the discussion/arguments here are about the different
'Weltanshaung's (world views) of the contributors.
In terms of the new user pull problem, what needs to be modeled is the
new user's and their weltanshaung, not how we ('experienced' users?)
might 'solve' the problem.
The pull problem is, I believe part of the bigger problem of the
mind-set shift required for the transition to a DVCS for most new users.
Git has grown organically, so still has some soft (unclear) edges, which
probably needs more than just a transition plan for Filipe's pull
changes, and its choice of the final default (or lack of).
For example, if users aren't understanding the differences between
remote branches, remote tracking branches, and branches, which is part
of the pull problem; have we made it easy for them to understand? [They
already have to comprehend the 'staging' concept, so are already
cognitively fully loaded].
For the branch type example, some cleaner naming may help, such as:
'remote branch', 'Tracking branch', and '(local) branch', which excludes
the noiseword 'remote' from 'Tracking branches' (my deliberate 'T'
emphasis). Though that does still leave the confusion between remote
servers and remote repos, where the latter may actually be local, and if
a file path, be the local '.' repo itself!
Thanks and hope that helps,
Sorry if this went off at a tangent, but I believe it's important to get
to the bottom of the new user problems, which are deeper than just a few
command defaults.
Jonathan
--
Philip
--
[1]
http://40qx6d15vq6j25i83v3ks8nxfux.wpengine.netdna-cdn.com/files/2012/08/seven-steps2.gif
or http://portals.wi.wur.nl/spicad/?Soft_Systems_Methodology Checkland's
7 Steps.
[2] CATWOE: customers, actors, transformation, weltanshaung, owners,
environment.
--
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 Mostly Evil
On 2014-05-03 05:26, Felipe Contreras wrote:
Richard Hansen wrote:
I think the fundamental difference is in the relationship between the
local and the remote branch (which branch derives from the other).
The relationship between the branches determines what the user wants
from 'git pull'.
In my experience 'git pull' is mostly (only?) used for the following
three tasks:
I agree.
1. update a local branch to incorporate the latest upstream changes
In this case, the local branch (master) is a derivative of the
upstream branch (origin/master). The user wants all of the
commits in the remote branch to be in the local branch. And the
user would like the local changes, if any, to descend from the tip
of the remote branch.
My current propsal of making `git pull` by default do --ff-only would
solve this.
It would go a long way toward improving the situation, yes.
In addition I think by default 'master' should be merged to
'origin/master', if say --merge is given.
This would break cases #2 and #3. (With cases #2 and #3 you want the
fetched branch to be the second parent, not the first.)
Or are you proposing that pull --merge should reverse the parents if and
only if the remote ref is @{u}?
For this case, 'git pull --ff-only' followed by 'git rebase -p'
works well, as does 'git pull --rebase=preserve' if the user is
comfortable rebasing without reviewing the incoming commits first.
I suppose you mean a `git rebase -p` if the `git pull --ff-only` failed.
Yes.
This might be OK on most projects, but not all.
The rebase only affects the local repository (the commits haven't been
pushed yet or else they'd be in @{u} already), so I'd say it's more of
an individual developer decision than a project decision.
In my opinion rebase would be the best option here, but if the project
is OK with developers pushing merge or merge-there commits and the
developer isn't yet comfortable with rebasing, then merge is also an
acceptable option.
What happens after a `git pull --ff-only` fails should be totally
up to the user.
I tend to agree, mostly because I want users to have an opportunity to
review incoming commits before action is taken. Also, though rebasing
would yield the nicest history, some users aren't yet comfortable with
rebase. If a project is OK with silly little merge commits from users
that aren't comfortable with rebase, then I don't want to force everyone
to rebase by default.
As an added bonus: Defaulting to --ff-only makes it possible for 'git
pull --all' to fast-forward every local branch to their configured
upstream, not just the currently checked-out branch. I think this would
be a huge usability win.
2. update a published feature branch with the latest changes from its
parent branch
In this case, the local branch (foo) is a derivative of the
upstream branch (origin/foo) which is itself a derivative of
another branch (origin/master). All commits in origin/master
should be in origin/foo, and ideally all commits unique to
origin/foo would descend from the tip of origin/master.
I don't understand why are you tainting the example with 'origin/foo',
Originally I didn't have this case in my list, but I added it after
thinking about Peff's comment:
On 2014-05-02 17:48, Jeff King wrote:
One common workflow for GitHub users is to back-merge master into a
topic, because they want the final integrated version on the topic
branch.
This almost but doesn't quite fit neatly into the other two cases. It's
not case #1 because the shared nature of origin/foo means that rebasing
origin/foo onto origin/master is usually bad instead of usually good.
It's not case #3 because rebasing origin/master commits onto origin/foo
(assuming that the user would usually want to rebase the topic branch
when integrating) would definitely be bad.
'foo' and 'origin/master' are enough for this example. In fact, the
mention of 'origin/master' made it wrong: after the pull not all the
commits of origin/master would be in origin/foo, you need a push for
that.
The push of foo to origin/foo was meant to be implied.
We have enough in our plate to taint this with yet another branch
and push.
For this case `git pull origin master` already work correctly for most
projects.
Yes, it does.
We probably shouldn't change that.
If we change 'git pull' to default to --ff-only but let 'git pull
$remote [$refspec]' continue to default to --ff then we have two
different behaviors depending on how 'git pull' is invoked. I'm worried
that this would trip up users. I'm not convinced that having two
different behaviors would be bad, but I'm not convinced that it would be
good either.
3. integrate a more-or-less complete feature/fix back into the line
of development it forked off of
In this case the local branch is a primary line of development and
the remote branch contains the derivative work.
Re: Pull is Mostly Evil
Richard Hansen wrote:
On 2014-05-03 05:26, Felipe Contreras wrote:
Richard Hansen wrote:
I think the fundamental difference is in the relationship between the
local and the remote branch (which branch derives from the other).
The relationship between the branches determines what the user wants
from 'git pull'.
In my experience 'git pull' is mostly (only?) used for the following
three tasks:
I agree.
1. update a local branch to incorporate the latest upstream changes
In this case, the local branch (master) is a derivative of the
upstream branch (origin/master). The user wants all of the
commits in the remote branch to be in the local branch. And the
user would like the local changes, if any, to descend from the tip
of the remote branch.
My current propsal of making `git pull` by default do --ff-only would
solve this.
It would go a long way toward improving the situation, yes.
In addition I think by default 'master' should be merged to
'origin/master', if say --merge is given.
This would break cases #2 and #3. (With cases #2 and #3 you want the
fetched branch to be the second parent, not the first.)
Or are you proposing that pull --merge should reverse the parents if and
only if the remote ref is @{u}?
Only if no remote or branch are specified `git pull --merge`.
For this case, 'git pull --ff-only' followed by 'git rebase -p'
works well, as does 'git pull --rebase=preserve' if the user is
comfortable rebasing without reviewing the incoming commits first.
I suppose you mean a `git rebase -p` if the `git pull --ff-only` failed.
Yes.
This might be OK on most projects, but not all.
The rebase only affects the local repository (the commits haven't been
pushed yet or else they'd be in @{u} already), so I'd say it's more of
an individual developer decision than a project decision.
In my opinion rebase would be the best option here, but if the project
is OK with developers pushing merge or merge-there commits and the
developer isn't yet comfortable with rebasing, then merge is also an
acceptable option.
Precisely for that reason.
2. update a published feature branch with the latest changes from its
parent branch
We probably shouldn't change that.
If we change 'git pull' to default to --ff-only but let 'git pull
$remote [$refspec]' continue to default to --ff then we have two
different behaviors depending on how 'git pull' is invoked. I'm worried
that this would trip up users. I'm not convinced that having two
different behaviors would be bad, but I'm not convinced that it would be
good either.
It is the only solution that has been proposed.
Moreover, while it's a bit worrisome, it wouldn't create any actual
problems. Since `git pull $what` remains the same, there's no problems
there. The only change would be on `git pull`.
Since most users are not going to do `git pull $what` therefore it would
only be a small subset of users that would notice the discrepancy
between running with $what, or not. And the only discrepancy they could
notice is that when they run `git pull $what` they expect it to be
--ff-only, or when the run `git pull` they don't. Only the former could
be an issue, but even then, it's highly unlikely that `git pull $what`
would ever be a fast-forward.
So althought conceptually it doesn't look clean, in reality there
wouldn't be any problems.
3. integrate a more-or-less complete feature/fix back into the line
of development it forked off of
In this case the local branch is a primary line of development and
the remote branch contains the derivative work. Think Linus
pulling in contributions. Different situations will call for
different ways to handle this case, but most will probably want
some or all of:
* rebase the remote commits onto local HEAD
No. Most people will merge the remote branch as it is. There's no reason
to rebase, specially if you are creating a merge commit.
I disagree. I prefer to rebase a topic branch before merging (no-ff) to
the main line of development for a couple of reasons:
Well that is *your* preference. Most people would prefer to preserve the
history.
* It makes commits easier to review.
The review in the vast majority of cases happens *before* the
integration.
And the problem comes when the integrator makes a mistake, which they
inevitable do (we all do), then there's no history about how the
conflict was resolved, and what whas the original patch.
That's why most people don't do this.
* Rebasing makes the commit history pretty and easier to understand.
It is more important to be able to track integration errors than to have
a pretty history. That is for most people.
I like to have a pretty history for my own local branches, but once
something gets integrated it's important to see who did exactly what
(the integrator did the merge).
Re: Pull is Mostly Evil
On Sat, 3 May 2014, David Kastrup wrote: Felipe Contreras felipe.contre...@gmail.com writes: David Kastrup wrote: Richard Hansen rhan...@bbn.com writes: These three usage patterns are at odds; it's hard to change the default behavior of 'git pull' to favor one usage case without harming another. Perhaps this is why there's so much disagreement about what 'git pull' should do. Should a screwdriver be turning clockwise or counterclockwise by default? There are valid arguments for either. If you don't have anything to contribute don't disturb the people that actually care and are trying to improve Git. Thanks. No need to expand on the welcoming atmosphere here. note that this is one person taking the I don't see any commits from you so your opinion doesn't count attitude. the vast majority of people here do not take that attitude. David Lang My heinous plot to subvert the quality of Git has already been thwarted by making sure that its meritocracy continues relying only on input from those with an independent income. I'm just sticking around until my current contributions move into master so that I can summarize the resulting low-hanging fruit that the meritorious can then pick at great fanfare. The sooner my work moves from pu into master, the sooner y'all be rid of me.
Re: Pull is Mostly Evil
David Lang wrote: note that this is one person taking the I don't see any commits from you so your opinion doesn't count attitude. Wrong. I said it doesn't count for the project. Do you honestly believe Junio cares about what some random guy on the list thinks about default aliases? No. If he doesn't care what literally everyone thinks about the name index, why would he care about that random guy? the vast majority of people here do not take that attitude. It's actually the exact opposite. I don't care what is the track record of the people in the discussion. If their argument is good, their argument is good. It's the others that focus on the carisma and credentials of the people in the discussion, rather than the arguments. -- 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 Mostly Evil
(Apologies for not CCing all the folks who've participated in the Pull is Evil thread -- I couldn't find a good branch of that thread for this message.) OK, so maybe git pull is just Mostly Evil. People seem to have found many different ways to make it work for them. But in reality git pull has become a chimera that confuses a large number of new users, and that experienced users either avoid entirely or customize to give them a convenient shorthand for working in their particular environment. As a tool for new git users, it just doesn't seem to be achieving its goals. I think the git project as a whole would benefit if it started to treat git pull as an advanced command, in the sense that it needs to be configured by an experienced user in order to make it correctly follow a project's workflow. Once it's configured properly, git pull is a powerful tool that gives users an easy way to do complex things. In that sense, it may be appropriate for a project to tailor git pull as it likes, then teach its own users to use the command. However, when it comes to teaching people how to use git qua git, git pull should be the last thing they learn about, because it's only after you understand various basic git concepts that you can configure git pull to do the right thing. To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. It'll take quite a bit of time, but I think that if we change our attitude towards git pull and take this unconfigured-by-default approach, then in a few years the entire git ecosystem will be in a better place. 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 Mostly Evil
Marc Branchaud marcn...@xiplink.com writes: To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. Fetching is uncontentious, and I _think_ that fast-forwards are pretty uncontentious as well. It's just when the merge-left/merge-right/rebase-left/rebase-right decision kicks in that prescribing one git-pull behavior looks like a recipe for trouble. -- 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 Mostly Evil
From: David Kastrup d...@gnu.org Marc Branchaud marcn...@xiplink.com writes: To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. Fetching is uncontentious, and I _think_ that fast-forwards are pretty uncontentious as well. While the fast forward is /pretty/ uncontentious, it still maybe contentious for some. But more importantly (in my mind) is the fact that it (git pull) hasn't been configured, and pressing for _that_ to happen is the big benefit. I'm more than happy that the fast-forward should be the recommended 'if you don't know, choose this' option, as you say, its pretty uncontentious and has easy mechanisms for backing out which are well illustrated across the internet. It would still need a few cycles of ramping up the warnings to ease folk in gently. One has to beware of the issues at both ends of the Kruger Dunning curve. This thread discussion in some ways has suffered from the inverse K-D effect. It's just when the merge-left/merge-right/rebase-left/rebase-right decision kicks in that prescribing one git-pull behavior looks like a recipe for trouble. -- David Kastrup -- 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 Mostly Evil
Marc Branchaud marcn...@xiplink.com writes: (Apologies for not CCing all the folks who've participated in the Pull is Evil thread -- I couldn't find a good branch of that thread for this message.) OK, so maybe git pull is just Mostly Evil. People seem to have found many different ways to make it work for them. But in reality git pull has become a chimera that confuses a large number of new users, and that experienced users either avoid entirely or customize to give them a convenient shorthand for working in their particular environment. As a tool for new git users, it just doesn't seem to be achieving its goals. I think the git project as a whole would benefit if it started to treat git pull as an advanced command, in the sense that it needs to be configured by an experienced user in order to make it correctly follow a project's workflow. Once it's configured properly, git pull is a powerful tool that gives users an easy way to do complex things. In that sense, it may be appropriate for a project to tailor git pull as it likes, then teach its own users to use the command. However, when it comes to teaching people how to use git qua git, git pull should be the last thing they learn about, because it's only after you understand various basic git concepts that you can configure git pull to do the right thing. To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. It'll take quite a bit of time, but I think that if we change our attitude towards git pull and take this unconfigured-by-default approach, then in a few years the entire git ecosystem will be in a better place. Your earlier long-hand, together with the two examples that pulls into the same maint branch Brian gave us, may give us a better starting points to think about a saner way. To me, the problem sounds like: Tutorials of Git often says use 'git pull' to catch up your branch with your upstream work and then 'git push' back (and worse yet, 'git push' that does not fast-forward suggests doing so), but 'git pull' that creates a merge in a wrong direction is not the right thing for many people. And proposed solutions range from let's write 'pull' off as a failed experiment to let's forbid any merge made by use of 'pull' by default, because it is likely that merge may be in reverse. Let's look at Brian's examples, which may point at a good direction. When he becomes in charge of producing a new 'maint' (in his original, he says 'maintenance-branch'), he first does this: $ git checkout maint $ git pull --ff-only [ origin maint ] He may have a stale 'maint' branch for a variety of reasons. He may have been the pumpking in the past, worked on his local 'maint' to advance its tip with merges in the right direction and pushed the result out to the central repository when he was done, and kept that then-current 'maint' in his repository without removing when he passed the pumpkin to somebody else. As you said in the thread, this could have been done on a detached head, but keeping the local branch around is more convenient (you may want to do a disconnected development and having a reference point is handy). Or he may be the long-term pumpking for 'maint' branch, but is working on a machine different from the one he updated the shared 'maint' the last time. In either case, what is most important for this 'pull' is that he is catching up with today's central repository, without losing any old work that he forgot to push out when he was playing the pumpking the last time (hence --ff-only to cause it to fail if that is the case) in this local repository. Then he integrates a topic by another and push the result with: $ git pull [--no-ff] developer-remote topic-branch $ git push [ origin maint ] For this 'pull', he knows that this may not fast-forward (the $DAYJOB convention to use a real merge even when the merge fast-forwards is optional). Even with the proposed pull.mode or branch.maint.pullmode, these two 'pull' cannot be given a convenient default. The best we can do with the approach is to set pull.mode to ff-only for safety to protect his first 'pull' from the origin/maint, and have him remember to override it from the command line with --merge --no-ff [*1*]. If we step back a bit, because we are forcing him to differentiate these two pulls in his mental model anyway, perhaps it may help people (both new and old) if we had a new command to make the distinction stand out more. What if the command sequence were like this instead? $ git checkout maint $ git update [ origin maint ] $ git pull [--no-ff] developer-remote topic-branch $ git push [ origin maint ] where the new command 'update' enforces the '--ff-only' update. And then we would stop telling 'git pull' first when a push
Re: Pull is Mostly Evil
Philip Oakley wrote: From: David Kastrup d...@gnu.org Marc Branchaud marcn...@xiplink.com writes: To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. Fetching is uncontentious, and I _think_ that fast-forwards are pretty uncontentious as well. While the fast forward is /pretty/ uncontentious, it still maybe contentious for some. So? No defaults can please absolutely everyone, the best anybody can do is try to please the majority of people, and merging fast-forwards only does that. -- 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 Mostly Evil
Junio C Hamano wrote: If we step back a bit, because we are forcing him to differentiate these two pulls in his mental model anyway, perhaps it may help people (both new and old) if we had a new command to make the distinction stand out more. What if the command sequence were like this instead? $ git checkout maint $ git update [ origin maint ] $ git pull [--no-ff] developer-remote topic-branch $ git push [ origin maint ] where the new command 'update' enforces the '--ff-only' update. And then we would stop telling 'git pull' first when a push does not fast-forward. In addition to barf when it's not a fast-forward, such command can switch the parents, so it appears 'maint' was merged to 'origin/maint'. Many people have complained about this order. Stepping back even further, and thinking what is different between these two pulls, we notice that the first one is pulling from the place we push back to. Perhaps a way to solve this issue, without having to introduce a new 'git update' and updating the tutorials, may be disallow fetch+merge by default only when pulling from the place the result is going to be pushed back to? Which is basically essentially the same as not specifying anything, or rather, running `git pull` without arguments. -- 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 Mostly Evil
On Fri, 2 May 2014, David Kastrup wrote: Date: Fri, 02 May 2014 17:45:23 +0200 From: David Kastrup d...@gnu.org To: git@vger.kernel.org Subject: Re: Pull is Mostly Evil Marc Branchaud marcn...@xiplink.com writes: To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. Fetching is uncontentious, and I _think_ that fast-forwards are pretty uncontentious as well. so those people just need to use fetch instead of pull. This seems fairly straightforward fetch, get the data but don't integrate it pull, get the data and ff along it if possible pull with options, merge/rebase left/right based on options when ff is not possible. Pull was created with one workflow in mind, Changing it to require explcitly specifying the option (in a config, with appropriate transition, handholding) is not completly unreasonable, and given the confusion this causes, may be very reasonable. But saying that ff isn't always right, so make pull go away altogether (or don't change anything because there isn't 100% agreement on the result paralysis) doesn't seem right. It's just when the merge-left/merge-right/rebase-left/rebase-right decision kicks in that prescribing one git-pull behavior looks like a recipe for trouble. confusion at least. It's not fatal confusion, people have been using it for years after all. David Lang -- 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 Mostly Evil
Felipe Contreras felipe.contre...@gmail.com writes: Stepping back even further, and thinking what is different between these two pulls, we notice that the first one is pulling from the place we push back to. Perhaps a way to solve this issue, without having to introduce a new 'git update' and updating the tutorials, may be disallow fetch+merge by default only when pulling from the place the result is going to be pushed back to? Which is basically essentially the same as not specifying anything, or rather, running `git pull` without arguments. I cannot tell if you are agreeing or disagreeing, and with what. Using the special case 'git pull' without arguments heuristics would take us back to the old jc/pull-training-wheel patch http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=230856 which we agreed to drop in http://thread.gmane.org/gmane.comp.version-control.git/233554/focus=234365 to favor the old series you did with pull.mode, and we rejected that patch in $gmane/230856 for a sound reason, I would think. You are pulling from the place the result is going to be pushed back to is different from 'git pull' was run without arguments. In the pumpking example in the message you are responding to: When he becomes in charge of producing a new 'maint' (in his original, he says 'maintenance-branch'), he first does this: $ git checkout maint $ git pull --ff-only [ origin maint ] the heuristics would trigger the safety only when the optional origin maint are not given, but we do have enough information to see git pull origin maint (with where from and what to pull explicitly specified on the command line) falls into the case where the user needs protection, don't we? Also, with the triangular push configuration, git pull without argument will fetch from one place that is different from where the current branch is going to pushed to, so that heuristics would not work at all. So... -- 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 Mostly Evil
David Lang da...@lang.hm writes: On Fri, 2 May 2014, David Kastrup wrote: It's just when the merge-left/merge-right/rebase-left/rebase-right decision kicks in that prescribing one git-pull behavior looks like a recipe for trouble. confusion at least. It's not fatal confusion, people have been using it for years after all. It's one of the most frequent causes for educating newcomers what they have been doing wrong in the LilyPond project. Including the occasional blunder from experienced people who did not notice that they got a non-ff merge as a mergeday present. It's one of the main things putting new contributors on edge and causing anxiety about messing up again. -- 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 Mostly Evil
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Stepping back even further, and thinking what is different between these two pulls, we notice that the first one is pulling from the place we push back to. Perhaps a way to solve this issue, without having to introduce a new 'git update' and updating the tutorials, may be disallow fetch+merge by default only when pulling from the place the result is going to be pushed back to? Which is basically essentially the same as not specifying anything, or rather, running `git pull` without arguments. I cannot tell if you are agreeing or disagreeing, and with what. I'm agreeing that 'git pull repo branch' is different than 'git pull', and 'git pull' is the problem. I'm not certain about 'git pull repo', but I think that probably shouldn't change either. Using the special case 'git pull' without arguments heuristics would take us back to the old jc/pull-training-wheel patch http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=230856 If you mean adding back the 'test $# = 0', then yes, if you mean going back to 'pull.rebase=false' to force merges (and a bunch of other stuff), then no. which we agreed to drop in http://thread.gmane.org/gmane.comp.version-control.git/233554/focus=234365 to favor the old series you did with pull.mode, and we rejected that patch in $gmane/230856 for a sound reason, I would think. Because the 'pull.mode=merge' mode option was simply sensible. You are pulling from the place the result is going to be pushed back to is different from 'git pull' was run without arguments. In the pumpking example in the message you are responding to: When he becomes in charge of producing a new 'maint' (in his original, he says 'maintenance-branch'), he first does this: $ git checkout maint $ git pull --ff-only [ origin maint ] the heuristics would trigger the safety only when the optional origin maint are not given, but we do have enough information to see git pull origin maint (with where from and what to pull explicitly specified on the command line) falls into the case where the user needs protection, don't we? I think 'git pull' and 'git pull origin maint' are different, regardless of the fact that origin/maint is the upstream. In the former I would expect 'maint' to be merged to 'origin/maint', in the latter I would expect 'origin/maint' to be merged into 'maint'. And if the user has specified that he wants to merge 'origin/maint' into 'maint', I don't see why a non-fast-forward should fail. Also, with the triangular push configuration, git pull without argument will fetch from one place that is different from where the current branch is going to pushed to, so that heuristics would not work at all. I think that's irrelevant. Both the upstream and publish tracking branches don't matter when the user has specifically asked for a branch to be pulled. -- 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 Mostly Evil
On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote: Junio C Hamano wrote: If we step back a bit, because we are forcing him to differentiate these two pulls in his mental model anyway, perhaps it may help people (both new and old) if we had a new command to make the distinction stand out more. What if the command sequence were like this instead? $ git checkout maint $ git update [ origin maint ] $ git pull [--no-ff] developer-remote topic-branch $ git push [ origin maint ] where the new command 'update' enforces the '--ff-only' update. And then we would stop telling 'git pull' first when a push does not fast-forward. In addition to barf when it's not a fast-forward, such command can switch the parents, so it appears 'maint' was merged to 'origin/maint'. Many people have complained about this order. I realize this has veered off into talking about an update command, and not necessarily pull, but since there a lot of proposals floating around, I wanted to make one point: if we are going to do such a switch, let's please make it something the user explicitly turns on. One common workflow for GitHub users is to back-merge master into a topic, because they want the final integrated version on the topic branch. That lets it get review, run tests, and even get test-deployed from there before merging to master (and then when it does merge to master, we know the result will be a trivial merge). This workflow helps spread out the load (there is no central integration person or script, and the merge itself becomes a possible part of the review/test cycle). Some projects will do this by rebasing the topic, but that has its own complications (like making collaboration harder because the commits are being frequently rewritten). Such users are going to run git pull origin master or just git pull to get that merge. A switch to disallowing non-ff is going to disrupt that workflow. I think we can live with that, as they should be able to stop and say no, my workflow wants these merges, set a config variable, and be done. But I think that is the same moment they should probably be deciding on whether their workflow wants regular or reverse merges. And I do not think the decision between the two has an obvious split over which is better. So it makes sense to me to take the opportunity when the user is thinking about their workflow to have them specify one or the other. -Peff -- 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 Mostly Evil
Jeff King wrote: On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote: Junio C Hamano wrote: If we step back a bit, because we are forcing him to differentiate these two pulls in his mental model anyway, perhaps it may help people (both new and old) if we had a new command to make the distinction stand out more. What if the command sequence were like this instead? $ git checkout maint $ git update [ origin maint ] $ git pull [--no-ff] developer-remote topic-branch $ git push [ origin maint ] where the new command 'update' enforces the '--ff-only' update. And then we would stop telling 'git pull' first when a push does not fast-forward. In addition to barf when it's not a fast-forward, such command can switch the parents, so it appears 'maint' was merged to 'origin/maint'. Many people have complained about this order. I realize this has veered off into talking about an update command, and not necessarily pull, but since there a lot of proposals floating around, I wanted to make one point: if we are going to do such a switch, let's please make it something the user explicitly turns on. This is sensible, but with warning X will be the default in the future, just like we did with push.default = simple. One common workflow for GitHub users is to back-merge master into a topic, because they want the final integrated version on the topic branch. That lets it get review, run tests, and even get test-deployed from there before merging to master (and then when it does merge to master, we know the result will be a trivial merge). This workflow helps spread out the load (there is no central integration person or script, and the merge itself becomes a possible part of the review/test cycle). Some projects will do this by rebasing the topic, but that has its own complications (like making collaboration harder because the commits are being frequently rewritten). They can do: % git pull origin master That shouldn't revese the bases. Such users are going to run git pull origin master or just git pull to get that merge. I'd say the vast majority of users running git pull want the parents reversed, the minority that doesn't can switch to git pull origin master (or add a configuration). A switch to disallowing non-ff is going to disrupt that workflow. Only if the refuse to do git pull origin master. But I think that is the same moment they should probably be deciding on whether their workflow wants regular or reverse merges. And I do not think the decision between the two has an obvious split over which is better. Because there hasn't been enough discussion on this topic. I'm fairly certain there will be consensus once concrete proposals are properly discussed. Most likely the consensus and the proposals will be ignored and nothing will change as usual, but that's a different thing. -- 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 Mostly Evil
From: Marc Branchaud marcn...@xiplink.com Sent: Friday, May 02, 2014 4:37 PM (Apologies for not CCing all the folks who've participated in the Pull is Evil thread -- I couldn't find a good branch of that thread for this message.) OK, so maybe git pull is just Mostly Evil. People seem to have found many different ways to make it work for them. But in reality git pull has become a chimera that confuses a large number of new users, and that experienced users either avoid entirely or customize to give them a convenient shorthand for working in their particular environment. As a tool for new git users, it just doesn't seem to be achieving its goals. I think the git project as a whole would benefit if it started to treat git pull as an advanced command, in the sense that it needs to be configured by an experienced user in order to make it correctly follow a project's workflow. Once it's configured properly, git pull is a powerful tool that gives users an easy way to do complex things. In that sense, it may be appropriate for a project to tailor git pull as it likes, then teach its own users to use the command. However, when it comes to teaching people how to use git qua git, git pull should be the last thing they learn about, because it's only after you understand various basic git concepts that you can configure git pull to do the right thing. To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. I tend to agree. The hard part is making sure folk have enough prior learning to make a choice that their will fit their real needs. It'll take quite a bit of time, but I think that if we change our attitude towards git pull and take this unconfigured-by-default approach, then in a few years the entire git ecosystem will be in a better place. M. -- 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 Mostly Evil
From: Felipe Contreras felipe.contre...@gmail.com Sent: Friday, May 02, 2014 8:05 PM Philip Oakley wrote: From: David Kastrup d...@gnu.org Marc Branchaud marcn...@xiplink.com writes: To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run git help pull for guidance. Fetching is uncontentious, and I _think_ that fast-forwards are pretty uncontentious as well. While the fast forward is /pretty/ uncontentious, it still maybe contentious for some. So? No defaults can please absolutely everyone, the best anybody can do is try to please the majority of people, and merging fast-forwards only does that. That assumes that doing something is better than doing nothing, which is appropriate when the costs on either side are roughly similar. However in this case, as we have essentially all agreed, there have been some bad down sides. In that case a precautionary principle is more appropriate where doing nothing (that is git pull does nothing until user configured) is better. While a shift to merging fast-forwards would reduce the cost difference, they have to be matched against the potential user confusions when comparing to all the old web miss-instructions, hence my shift away from trying to best guess a default, rather than simply suggest it as a suitable user choice. -- Felipe Contreras -- 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 Mostly Evil
On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote: They can do: % git pull origin master That shouldn't revese the bases. Then they have to remember to do that every time, no? That seems a little error-prone versus setting a config option. Such users are going to run git pull origin master or just git pull to get that merge. I'd say the vast majority of users running git pull want the parents reversed, the minority that doesn't can switch to git pull origin master (or add a configuration). I'm not sure I agree, but I don't think either of us has actual data. Most likely the consensus and the proposals will be ignored and nothing will change as usual, but that's a different thing. Is it truly necessary to make sniping comments like this at the end of each email? It _is_ being discussed right now, and these comments do nothing except irritate your readers. Please stop. -Peff -- 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 Mostly Evil
Hi, Philip Oakley wrote: That assumes that [git pull] doing something is better than doing nothing, which is appropriate when the costs on either side are roughly similar. I think the conversation's going around in circles. Potential next steps: a. Documentation or test patch illustrating desired behavior b. More traditional formal design doc explaining desired behavior and the thinking behind it (problem, overview of solution, alternatives rejected, complications, example, open questions). c. Implementation patch d. Someone takes an existing patch and figures out the next step toward getting it ready for application. My preference is for (a), I guess. The point being that something more concrete (code or a design doc) makes it easier to avoid talking past each other. And having something concrete to edit makes the stakes clearer so people can make it incrementally better without being distracted by unimportant parts. Thanks and hope that helps, 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 Mostly Evil
Philip Oakley wrote: From: Felipe Contreras felipe.contre...@gmail.com So? No defaults can please absolutely everyone, the best anybody can do is try to please the majority of people, and merging fast-forwards only does that. That assumes that doing something is better than doing nothing, When doing something is better for the vast majority of people, that's what should be done by default, unless the results are catastrophic for the minority. Since doing something is not catastrophic to the minority, it follows that the default should be to do something. It's a simple as that. -- 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 Mostly Evil
Jeff King wrote: On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote: They can do: % git pull origin master That shouldn't revese the bases. Then they have to remember to do that every time, no? That seems a little error-prone versus setting a config option. Yes. However, since not many people do this, and they don't do it that often that's not a big deal. It's much more important to fix the issue the vast majority of users face constantly. Such users are going to run git pull origin master or just git pull to get that merge. I'd say the vast majority of users running git pull want the parents reversed, the minority that doesn't can switch to git pull origin master (or add a configuration). I'm not sure I agree, but I don't think either of us has actual data. Do you want me to go dig in the mailing list and point you to the endless discussions? I assure you, if this is not changed, we will have this discussion again. Most likely the consensus and the proposals will be ignored and nothing will change as usual, but that's a different thing. Is it truly necessary to make sniping comments like this at the end of each email? It _is_ being discussed right now, and these comments do nothing except irritate your readers. Please stop. And it has been discussed before. If history is any indication, it will be discussed again. -- 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 Mostly Evil
Jeff King p...@peff.net writes: On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote: Junio C Hamano wrote: If we step back a bit, because we are forcing him to differentiate these two pulls in his mental model anyway, perhaps it may help people (both new and old) if we had a new command to make the distinction stand out more. What if the command sequence were like this instead? $ git checkout maint $ git update [ origin maint ] $ git pull [--no-ff] developer-remote topic-branch $ git push [ origin maint ] where the new command 'update' enforces the '--ff-only' update. And then we would stop telling 'git pull' first when a push does not fast-forward. In addition to barf when it's not a fast-forward, such command can switch the parents, so it appears 'maint' was merged to 'origin/maint'. Many people have complained about this order. I realize this has veered off into talking about an update command, and not necessarily pull, but since there a lot of proposals floating around, I wanted to make one point: if we are going to do such a switch, let's please make it something the user explicitly turns on. A safety catch defaulting to a factory position of off is not going to stop inexperienced people from shooting themselves in the foot. -- 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
