Re: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 06:53:36PM -0500, Felipe Contreras wrote: The alternatives are these: a) you annoy the vast majority of the user-base by making 'git pull' a dangerous operation that should be avoided, and replaced with 'git fetch'+'git rebase'. b) you annoy a minority of the user-base by making 'git pull' not do the merge the expected, so they have to do +'git merge' (which is already less of a change than a)), or configure the default (which they most likely are able to do, if they did intent to do a merge). Note that in my email that started this, I tried to be clear that I was talking about git pull *without a branch name*. If this user explicitly says git pull remote branch then I consider that a clear indication that they really do mean to perform a merge; I would not recommend changing the current behaviour in that case. If the user just says git pull then it is more likely that they are just trying to synchronise with the upstream branch, in which case they probably don't actually want a merge. -- 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: first parent, commit graph layout, and pull merge direction
Am 23.05.2013 21:25, schrieb Andreas Krey: On Thu, 23 May 2013 11:06:57 +, Andreas Krey wrote: ... ... Don't do that, then. Ouch, you're right. The problem is not actually in the pull; only the *last* pull into a feature branch that then get pushed back ff to master needs to be reversed. And at that time you don't know it's the last one - swap parents before the push if necessary. if you have to be so careful to ensure the correct ordering of parents it almost defeats the initial objective to make commit graphs in gitk look nice without re-educating/restricting other users. A solution that works for everyone should work without users having to think about it. Here is an idea (probably already discussed in the long history of git): 1) the branch name is recorded in a commit (for merges the branch that is updated) 2) unique identifier of repository is recorded in commit (optional) 3) simple configurable ordering and/or coloring scheme in gitk based on committer,branch name and repo (with wildcards). With this users could pull and push as often as they like, the main branches would always be ordered and straight lines. If instead you already do the work to keep your history clean you could just use the coloring scheme and see committers color coded in gitk. Further benefit: the history of really old commits could be more easily remembered if you knew in what branch they originated Is this a bad idea or just no one did it yet? -- 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: first parent, commit graph layout, and pull merge direction
On Fri, May 24, 2013 at 4:29 AM, John Keeping j...@keeping.me.uk wrote: [snip] Note that in my email that started this, I tried to be clear that I was talking about git pull *without a branch name*. If this user explicitly says git pull remote branch then I consider that a clear indication that they really do mean to perform a merge; I would not recommend changing the current behaviour in that case. If the user just says git pull then it is more likely that they are just trying to synchronise with the upstream branch, in which case they probably don't actually want a merge. This makes a lot of sense to me. I was going to write earlier that I almost wish there was a separate command for getting your local branch in sync with the remote one. BTW, it also doesn't help that `git pull` is suggested as the answer anytime a push cannot succeed. I've warned my users about using `git pull`, and--unfortunately--they sometimes forget because the advice is right there in front of them. I agree with John here: it's a bare `git pull` that is often the culprit. Of course, the asymmetry between `git pull` and `git pull remote branch` is a little bothersome too, but the team does that *far* less often. -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: first parent, commit graph layout, and pull merge direction
On Fri, 24 May 2013 11:29:00 +, Holger Hellmuth (IKS) wrote: ... Here is an idea (probably already discussed in the long history of git): 1) the branch name is recorded in a commit (for merges the branch that is updated) The branch name is almost completely meaningless. I could just do my feature in my local master and never have a different name. Or commit something onto tmp that I then fast-forward into my (properly named) feature branch. 2) unique identifier of repository is recorded in commit (optional) That is pure noise (in my workflow). 3) simple configurable ordering and/or coloring scheme in gitk based on committer,branch name and repo (with wildcards). Ok, gitk could use some features. :-) ... Is this a bad idea or just no one did it yet? Possibly not bad (hg does parts of it), but un-git-ish? (I'm not sure that it was *intended* that the parents of a merge commit have an order, except that they need to for deterministic hashes.) Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: first parent, commit graph layout, and pull merge direction
Am 24.05.2013 15:42, schrieb Andreas Krey: On Fri, 24 May 2013 11:29:00 +, Holger Hellmuth (IKS) wrote: ... Here is an idea (probably already discussed in the long history of git): 1) the branch name is recorded in a commit (for merges the branch that is updated) The branch name is almost completely meaningless. I could just do my feature in my local master and never have a different name. In which case parent switching in the commit wouldn't help you either. But even you could keep your master always on the left side of gitk if you deem it special. And you could keep longer running cooperative branches (the main develop and the release branch of your project for example) in a seperate lane. Depending on your use of branches many branches won't get any ordering, but at a minimum important branches can easily be highlighted. Or commit something onto tmp that I then fast-forward into my (properly named) feature branch. Yes, but then you would see a feature branch in its expected column in gitk and you would also see (even years later) that it didn't start as a feature but later was made into one. Cues like this help to remember what happened even if you forgot to mention them in the commit message 2) unique identifier of repository is recorded in commit (optional) That is pure noise (in my workflow). It is important to differentiate between branches of the same name in different repositories. For example if your project has a central repository with master getting all the release stuff you want to sort that master differently than your own master. The unique identifier might be just a random number or string created at init time of the repo. 3) simple configurable ordering and/or coloring scheme in gitk based on committer,branch name and repo (with wildcards). Ok, gitk could use some features. :-) Without additional information about the commit history gitk can do exactly what it does now. ... Is this a bad idea or just no one did it yet? Possibly not bad (hg does parts of it), but un-git-ish? Don't know. No CVS does branches as good as git. But then it drops that information which depending on development style could be useful or not. Not that useful for people who keep their history clean, a lot for people who don't. -- 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: first parent, commit graph layout, and pull merge direction
Felipe Contreras felipe.contre...@gmail.com writes: ... but I don't see why something small like that wouldn't make sense: The pull was not fast-forward, please either merge or rebase. OK, I think I got what John was getting at and this single liner message is a good summary of it. Instead of telling them you cannot push this thing without losing history from the location you are pushing to; you need to become up to date with respect to them before pushing upon seeing a non ff push failure, we can tell them you cannot update your history to what the place you get new changes from has without losing your history; you need to integrate the two. Initially I said limiting git pull to --ff-only by default did not make sense, but when we view it that way, I now see how such a default makes sense. In another subthread, John Szakmeister mentioned that the please 'git pull' first message that a push gives when it stops due to non-ff nudges the users in a wrong direction, because they often take that 'git pull' too literally (e.g. 'pull --rebase' may be necessary in their project, not 'git pullENTER'). The original message deliberately avoided mentioning 'git pull' for that exact reason, but in mid 2010 we made it worse. The log of that change says that it attempted to ... remains fuzzy to include git pull, git pull --rebase and others, but directs the user to the simplest solution in the vast majority of cases. but this thread shows that it did not work; the simplest solution was a wrong one. The message also may need to be rethought to complement this direction being proposed for pull. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: first parent, commit graph layout, and pull merge direction
On Thu, 23 May 2013 09:01:15 +, Junio C Hamano wrote: ... Instead of having a nice these six commits marked as 'x' were done on a branch forked some time ago, to address only this one issue and to address it fully history that explains how these commits were related and these commits are the full solution to a single issue: x---x---x---x---x---x / \ ---o---o---o---o---o---o---M---o---o---... they end up with something like this, even with the flip the heads of a merge option, by pulling too often: x---x x---x---x x / \ / \ / \ ---o---o---M---o---o---M---M---o---o---... Wouldn't that be (you don't want to put your work back into master before it's done) the following? x---x---M---x---x---M--x / / /\ ---o---o---M---o---o---M--o---M---o---o---... With a bit of luck the first-parent strands will also run like this. I know that rebasing topic branches is better than updating, but my monetary upstream is busy letting go a clearcase-minted mindset. Teaching them rebasing will take a while, and as long as tthat we will have the picture above. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: first parent, commit graph layout, and pull merge direction
On Fri, 24 May 2013 17:05:26 +, Holger Hellmuth (IKS) wrote: Am 24.05.2013 15:42, schrieb Andreas Krey: ... The branch name is almost completely meaningless. I could just do my feature in my local master and never have a different name. In which case parent switching in the commit wouldn't help you either. Oh, it does; I tried. Names are meaningless, the parent ordering isn't. ( [And at least, it's already in there.] But even you could keep your master always on the left side of gitk if you deem it special. And you could keep longer running cooperative branches (the main develop and the release branch of your project for example) in a seperate lane. I need gitk (or similar) to do it. Will take some time to understand the code (and triggers the 'I can write it (the interesting part) faster than I can grok gitk'). ... Without additional information about the commit history gitk can do exactly what it does now. Most definitely not. There are quite some situations where the graph deteriorates pretty heavily, even when not expecting it to pay attention to first parent. When you have two branches, of which one regularly gets merge into the other, it sometimes manages to display first the one, then the other branch, with a log of merge edges going upwards in parallel, for example. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: first parent, commit graph layout, and pull merge direction
Andreas Krey a.k...@gmx.de writes: On Thu, 23 May 2013 09:01:15 +, Junio C Hamano wrote: ... Instead of having a nice these six commits marked as 'x' were done on a branch forked some time ago, to address only this one issue and to address it fully history that explains how these commits were related and these commits are the full solution to a single issue: x---x---x---x---x---x / \ ---o---o---o---o---o---o---M---o---o---... they end up with something like this, even with the flip the heads of a merge option, by pulling too often: x---x x---x---x x / \ / \ / \ ---o---o---M---o---o---M---M---o---o---... Wouldn't that be (you don't want to put your work back into master before it's done) the following? x---x---M---x---x---M--x / / /\ ---o---o---M---o---o---M--o---M---o---o---... That is what you would get if you pull from my upstream with the current software. And that is what triggered this discussion thread in which some people said that they do not want that shape of the history. At the leftmost merge M you drew on the upper line (i.e. your topic), the merge pulls in other's commits that are unrelated to each other as if it were a meaningful group of commits on a side branch. They want to see the merge going other way around, pulling your work done on a side branch, integrating into the mainline. The second illustration you are commenting on were done to explain why such a when pulling from my upstream, I want the order of parents swapped, so that mainline appears as the first parent is not solving the whole issue. The time series would go more like this: (1) While you were working on two 'x's, others have worked to advance the mainline: x---x Your 'master' / ---o---o Mainline (2) You cannot push without losing others work, so you pull, but in order to avoid the others work on mixed on a single side branch issue, you use the fictional flip heads of a merge option, and push the result out. That becomes the tip of the mainline: x---x / \ ---o---o---M (3) Then you keep working to build more commits on top. x---x x---x---x / \ / ---o---o---M (4) And others also keep working. x---x x---x---x / \ / ---o---o---M---o---o -- 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: first parent, commit graph layout, and pull merge direction
On Wed, 22 May 2013 11:07:07 +, Junio C Hamano wrote: ... If you have a four-commit segment in your commit ancestry graph I never had yet. :-( (time flows from left to right; turn your head 90-degrees to the right if you want a gitk representation): ---A--X \/ /\ ---B--Y where X and Y are both merges between A and B, having A as their first parent, how would you express such a graph with first-parent chain going a straight line? Of course there are multiple possible straight lines and how it looks depends on the order I use the existing heads to fish them out. (That is, when the straight lines join, I need to bend one of them.) Assuming I take the one where X is on, I expect a look like -A---X- \ | +- Y | | -B+--+ Branch heads that are reachable from other head are picked after those that aren't reachable. The point is to get the feature branches being displayed on separate lanes (and thus visibly sticking out) and not being intermingled with the longer-living branches. ... Don't do that, then. :-) Problem is, in this case 'I' expands to about 17 people I need to educate on this. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 5:06 AM, Andreas Krey a.k...@gmx.de wrote: [snip] ... Don't do that, then. :-) Problem is, in this case 'I' expands to about 17 people I need to educate on this. This is a feature of `git pull` that I really despise. I really wish `git pull` treated the remote as the first parent in its merge operation. -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: first parent, commit graph layout, and pull merge direction
- Mail original - On Thu, May 23, 2013 at 5:06 AM, Andreas Krey a.k...@gmx.de wrote: [snip] ... Don't do that, then. :-) Problem is, in this case 'I' expands to about 17 people I need to educate on this. This is a feature of `git pull` that I really despise. I really wish `git pull` treated the remote as the first parent in its merge operation. seconded... github's network pages (which display the commit graph of projects) seems to follow the first parent at the top rule and the pull merges are standing out as wrong because of 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: first parent, commit graph layout, and pull merge direction
On Thu, 23 May 2013 05:48:38 +, John Szakmeister wrote: ... This is a feature of `git pull` that I really despise. I really wish `git pull` treated the remote as the first parent in its merge operation. I'd actually only like it that way when pulling from the tracking branch, not for any pull. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 12:29:59PM +0200, Andreas Krey wrote: On Thu, 23 May 2013 05:48:38 +, John Szakmeister wrote: ... This is a feature of `git pull` that I really despise. I really wish `git pull` treated the remote as the first parent in its merge operation. I'd actually only like it that way when pulling from the tracking branch, not for any pull. I'll add my voice to the annoyed by this pile ;-) I've been annoyed by this at $DAYJOB recently. A lot of people seem to blindly git pull without much thought about how the history is ending up and what they actually want to do. I wonder if it would make sense for git pull (with no arguments) to pass --ff-only to git-merge, allowing this to be overridden with --rebase and --merge (which doesn't currently exist). With some suitable advice output we could hopefully educate users about how to shape their history. -- 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: first parent, commit graph layout, and pull merge direction
On Wed, May 22, 2013 at 6:50 AM, Andreas Krey a.k...@gmx.de wrote: Hi everyone, I'm just looking into better displays of the commit graph (as displayed with gitk, smartgit, fisheye) - they tend to quickly dissolve into a heap of spaghetti. We had the idea that treating the first parent specially would have some advantage here - including graphically indicating which one of the parents of a commit is the first parent. (For instance, by letting that line leave the commit node at the top/bottom, and the other(s) to the side.) I don't understand; gitk already shows the first parent starting from the bottom, and the merge commits arrive from the right side. What am I missing? -- 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: first parent, commit graph layout, and pull merge direction
On Thu, 23 May 2013 06:34:38 +, Felipe Contreras wrote: ... I don't understand; gitk already shows the first parent starting from the bottom, and the merge commits arrive from the right side. What am I missing? That this isn't (consistently) the case in complicated situations. I'll need to make a picture (as in png). Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: first parent, commit graph layout, and pull merge direction
John Keeping j...@keeping.me.uk writes: I've been annoyed by this at $DAYJOB recently. A lot of people seem to blindly git pull without much thought about how the history is ending up and what they actually want to do. I think these two are essentially the same thing, and having an option to flip the heads of a merge only solves a half of the problem. A merge that shows everybody else's work merged into your history means you are the integrator, the keeper of the main history. And the first-parent view of the history is useful only when the keeper of the main history takes good care of the main history. When you are using a central shared repository workflow, if you had and used an option to flip the heads of a merge to record what you have done so far as a side branch of what everybody else did to do the merge, or if you rebased your work on top of what everybody else did, the first-parent view would make a bit more sense than what you currently get. At least, everybody else's work will not appear as a side branch that does 47 unrelated things, and your work will appear as a side branch. That is a big plus. But the other half of the problem still remains, i.e. what they actually want to do. People tend to do too many pull when their work is not ready, only to catch up, and that is the real problem. Instead of having a nice these six commits marked as 'x' were done on a branch forked some time ago, to address only this one issue and to address it fully history that explains how these commits were related and these commits are the full solution to a single issue: x---x---x---x---x---x / \ ---o---o---o---o---o---o---M---o---o---... they end up with something like this, even with the flip the heads of a merge option, by pulling too often: x---x x---x---x x / \ / \ / \ ---o---o---M---o---o---M---M---o---o---... The result fragments otherwise a logical and clean single strand of pearls to fully address the issue, consisting of 6 commits, into separate and seemingly unrelated pieces. Imagine that other people are working the same way, and the commits marked with 'o' are merges of side branches they add their half-way work to the main history similar to what happened in the second illustration above. You would get this history: x---x x---x---x x / \ / \ / \ ---o---o---M---o---M---M---M---o---o---... \ / y---y Nothing, other than the labels I used in the picture, ties these 'x's together while differentiating them from 'y's, so you lost an important information. Unless people stop doing that too many pulls that are used only to catch up, even with the flip the heads of a merge option, you will not get a history that yields a good first-parent view. That gets back to what I said in the second paragraph of this message. When you pull from the central shared repository, with the flip the heads of a merge option, you are acting as the keeper of the main history at that point, and you are responsible for taking good care of it. If you make a 2+3+1=6 mess as depicted in the last illustration above, you are failing to do so. One obvious way to solve it is to use a topic branch workflow (the first picture above; 'x's are built not on local 'master'), and you do a git pull from the shared repository while you are on your 'master', which is free of your 'x's until that 6-commit series is complete and ready. Then you locally merge that topic branch and push it back for everybody to see, which will give you the first picture in this message. Incidentally, this does not need the flip the heads option. Solving half a problem is better than solving no problem, and especially because not all changes need to be multi-commit series but can be done directly, perfectly and fully on the local 'master' (i.e. 2+3+1=6 split would not happen for such changes). For these reasons, I personally am not strongly opposed to a flip the heads option, if implemented cleanly. But people need to realize that it is not solving the other half, a more fundamental problem some people have in their workflow. -- 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: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 09:01:15AM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: I've been annoyed by this at $DAYJOB recently. A lot of people seem to blindly git pull without much thought about how the history is ending up and what they actually want to do. I think these two are essentially the same thing, and having an option to flip the heads of a merge only solves a half of the problem. A merge that shows everybody else's work merged into your history means you are the integrator, the keeper of the main history. And the first-parent view of the history is useful only when the keeper of the main history takes good care of the main history. When you are using a central shared repository workflow, if you had and used an option to flip the heads of a merge to record what you have done so far as a side branch of what everybody else did to do the merge, or if you rebased your work on top of what everybody else did, the first-parent view would make a bit more sense than what you currently get. At least, everybody else's work will not appear as a side branch that does 47 unrelated things, and your work will appear as a side branch. That is a big plus. But the other half of the problem still remains, i.e. what they actually want to do. People tend to do too many pull when their work is not ready, only to catch up, and that is the real problem. ... One obvious way to solve it is to use a topic branch workflow (the first picture above; 'x's are built not on local 'master'), and you do a git pull from the shared repository while you are on your 'master', which is free of your 'x's until that 6-commit series is complete and ready. Then you locally merge that topic branch and push it back for everybody to see, which will give you the first picture in this message. Incidentally, this does not need the flip the heads option. Yes, I don't think this is as much of a problem when using a topic branch workflow, because it's clear what the history should look like and users are expected to get it right. Where I see this is when people are aiming for a linear history but don't get that because with git pull to catch up they end up with these backwards merges. In these cases, I think what users really want is git pull --rebase. I have to wonder how often git pull with no arguments actually does what users really want (even if they don't know it!) when it doesn't result in a fast-forward (and pull.rebase isn't configured). Hence my suggestion to error when git pull doesn't result in a fast-forward and no branch name is specified. We could give some advice like: Your local changes are not included in the local branch and you haven't told Git how to preserve them. If you want to rebase your changes onto the modified upstream branch, run: git pull --rebase Solving half a problem is better than solving no problem, and especially because not all changes need to be multi-commit series but can be done directly, perfectly and fully on the local 'master' (i.e. 2+3+1=6 split would not happen for such changes). For these reasons, I personally am not strongly opposed to a flip the heads option, if implemented cleanly. But people need to realize that it is not solving the other half, a more fundamental problem some people have in their workflow. Yes, but some users don't realise that their workflow is broken, and perhaps we can nudge them in the right direction. -- 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: first parent, commit graph layout, and pull merge direction
On Thu, 23 May 2013 11:06:57 +, Andreas Krey wrote: ... ... Don't do that, then. Ouch, you're right. The problem is not actually in the pull; only the *last* pull into a feature branch that then get pushed back ff to master needs to be reversed. And at that time you don't know it's the last one - swap parents before the push if necessary. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: first parent, commit graph layout, and pull merge direction
John Keeping j...@keeping.me.uk writes: I have to wonder how often git pull with no arguments actually does what users really want (even if they don't know it!) when it doesn't result in a fast-forward (and pull.rebase isn't configured). If you are in a totally centralized shared repository mindset without using topic branch workflow, --first-parent would not help you. In your history the second parent is more likely to be the mainline. So for them git pull that either fast-forward when it can, or makes a merge that records the then-current state of the central shared repository, is perfectly sensible. They will view gitk and see all the changes, git shortlog and git log --no-merges will give them what they expect. Hence my suggestion to error when git pull doesn't result in a fast-forward and no branch name is specified. We could give some advice like: Your local changes are not included in the local branch and you haven't told Git how to preserve them. If you want to rebase your changes onto the modified upstream branch, run: git pull --rebase I can parse the first paragraph above, but cannot make much sense out of it. Unless you are talking about local changes that are not committed yet, that is. But in that case I fail to see what it has to do with the current discussion, or suggestion to use rebase. But people need to realize that it is not solving the other half, a more fundamental problem some people have in their workflow. Yes, but some users don't realise that their workflow is broken, and perhaps we can nudge them in the right direction. I actually avoided mentioning that deliberately, because I think the flip the head when merging encourages people to (1) work directly on 'master' and (2) pull too often when they shouldn't. That is detrimental if your goal is to nudge them in the right direction. -- 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: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 02:01:39PM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: I have to wonder how often git pull with no arguments actually does what users really want (even if they don't know it!) when it doesn't result in a fast-forward (and pull.rebase isn't configured). If you are in a totally centralized shared repository mindset without using topic branch workflow, --first-parent would not help you. In your history the second parent is more likely to be the mainline. So for them git pull that either fast-forward when it can, or makes a merge that records the then-current state of the central shared repository, is perfectly sensible. They will view gitk and see all the changes, git shortlog and git log --no-merges will give them what they expect. Yes, but for people used to a cleaner history it's confusing to see the mainline branch and one small change the wrong way round. When I see people doing this, it's normally something like: ... do some work for several hours... git commit -a git push # fails because it's not a fast forward git pull git push In this scenario, just adding --rebase to git pull actually results in a much more sensible history. Hence my suggestion to error when git pull doesn't result in a fast-forward and no branch name is specified. We could give some advice like: Your local changes are not included in the local branch and you haven't told Git how to preserve them. If you want to rebase your changes onto the modified upstream branch, run: git pull --rebase I can parse the first paragraph above, but cannot make much sense out of it. Unless you are talking about local changes that are not committed yet, that is. But in that case I fail to see what it has to do with the current discussion, or suggestion to use rebase. This isn't about swap parents, it's about helping people realise that just git pull isn't necessarily the best thing for them to do, and that they may want --rebase. So I was asking if it would be sensible (possibly in Git 2.0) to make git-pull pass --ff-only to git-merge by default. -- 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: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 4:55 PM, John Keeping j...@keeping.me.uk wrote: So I was asking if it would be sensible (possibly in Git 2.0) to make git-pull pass --ff-only to git-merge by default. Definitely yes. -- Felipe Contreras -- 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: first parent, commit graph layout, and pull merge direction
John Keeping j...@keeping.me.uk writes: This isn't about swap parents, it's about helping people realise that just git pull isn't necessarily the best thing for them to do, and that they may want --rebase. So I was asking if it would be sensible (possibly in Git 2.0) to make git-pull pass --ff-only to git-merge by default. Unless your primary user base is those who use Git as a deployment tool to always follow along the tip of some external repository without doing anything on your own on the branch you run your git pull on, defaulting it to --ff-only does not make much sense to me. If the proposal were to make pull.rebase the default at a major version bump and force all integrators and other people who are happy with how pull = fetch + merge (not fetch + rebase) works to say pull.rebase = false in their configuration, I think I can see why some people may think it makes sense, though. But neither is an easy sell, I would imagine. It is not about passing me, but about not hurting users like kernel folks we accumulated over 7-8 years. Also rebase of the branch you attempted to push out is sometimes a good solution (fixing just a small change on 'master' that was beaten by somebody else pushing first), but is a bad workaround (you had many changes on that branch, which would have been better if they were done on a topic branch, but you do not want to merge with the upstream because you worked on 'master') some other times, so I have this suspicion that 'pull.rebase' is not necessarily a good thing to encourage in the first place. -- 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: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote: John Keeping j...@keeping.me.uk writes: This isn't about swap parents, it's about helping people realise that just git pull isn't necessarily the best thing for them to do, and that they may want --rebase. So I was asking if it would be sensible (possibly in Git 2.0) to make git-pull pass --ff-only to git-merge by default. Unless your primary user base is those who use Git as a deployment tool to always follow along the tip of some external repository without doing anything on your own on the branch you run your git pull on, defaulting it to --ff-only does not make much sense to me. A lot of people do stuff, but the rebase it. If the proposal were to make pull.rebase the default at a major version bump and force all integrators and other people who are happy with how pull = fetch + merge (not fetch + rebase) works to say pull.rebase = false in their configuration, I think I can see why some people may think it makes sense, though. That makes perfect sense, because the people that are not familiar with Git more often than not end up making merges by mistake, and the ones that are familiar with it can easily configure it to do what they want, or just 'git pull --merge', or 'git fetch'+'git merge' (we should make merge.defaulttoupstream=true as well). But neither is an easy sell, I would imagine. It is not about passing me, but about not hurting users like kernel folks we accumulated over 7-8 years. I've worked in the Linux kernel, and in my experience the vast vast majority of kernel developers don't do merges; they send patches. It's only the lieutenants that might do that, and although there are a lot, they don't surpass the 200, and they most definitely know how to configure Git to do what they need. And even then, most of them don't do merges, but create a linear history for Linus to merge. So the only one who does really rely on merges is Linus, I think he would have no problems configuring Git. It is also my experience that most people don't do 'git pull', because it rarely does what one wants; 'upstream' is still too cumbersome for most people. Also rebase of the branch you attempted to push out is sometimes a good solution (fixing just a small change on 'master' that was beaten by somebody else pushing first), but is a bad workaround (you had many changes on that branch, which would have been better if they were done on a topic branch, but you do not want to merge with the upstream because you worked on 'master') some other times, so I have this suspicion that 'pull.rebase' is not necessarily a good thing to encourage in the first place. Too bad, that's what most people recommend; 'git fetch'+'git rebase'. That's the only way newcomers can avoid the ugliness of 'upstream', and avoid making atrocious merges. It's silly that the people familiar with Git has to explain this to each and every newcomer. -- 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: first parent, commit graph layout, and pull merge direction
Felipe Contreras felipe.contre...@gmail.com writes: On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote: John Keeping j...@keeping.me.uk writes: This isn't about swap parents, it's about helping people realise that just git pull isn't necessarily the best thing for them to do, and that they may want --rebase. So I was asking if it would be sensible (possibly in Git 2.0) to make git-pull pass --ff-only to git-merge by default. Unless your primary user base is those who use Git as a deployment tool to always follow along the tip of some external repository without doing anything on your own on the branch you run your git pull on, defaulting it to --ff-only does not make much sense to me. A lot of people do stuff, but the rebase it. If I am parsing the above properly, I think that is only saying that pull --rebase makes sense for people who do real work, which I am not disagreeing. If the proposal were to make pull.rebase the default at a major version bump and force all integrators and other people who are happy with how pull = fetch + merge (not fetch + rebase) works to say pull.rebase = false in their configuration, I think I can see why some people may think it makes sense, though. That makes perfect sense, because the people that are not familiar with Git more often than not end up making merges by mistake, and the ones that are familiar with it can easily configure it to do what they want Yes, in theory. The transition needs a major version bump, but it is doable (with unknown level of resistance). But neither is an easy sell, I would imagine. It is not about passing me, but about not hurting users like kernel folks we accumulated over 7-8 years. I've worked in the Linux kernel, and in my experience the vast vast majority of kernel developers don't do merges; they send patches. It's only the lieutenants that might do that, and although there are a lot, they don't surpass the 200, and they most definitely know how to configure Git to do what they need. And even then, most of them don't do merges, but create a linear history for Linus to merge. So the only one who does really rely on merges is Linus, I think he would have no problems configuring Git. That is not something I can agree or disagree without looping somebody whose judgement I can trust from the kernel circle ;-). -- 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: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 5:54 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote: John Keeping j...@keeping.me.uk writes: This isn't about swap parents, it's about helping people realise that just git pull isn't necessarily the best thing for them to do, and that they may want --rebase. So I was asking if it would be sensible (possibly in Git 2.0) to make git-pull pass --ff-only to git-merge by default. Unless your primary user base is those who use Git as a deployment tool to always follow along the tip of some external repository without doing anything on your own on the branch you run your git pull on, defaulting it to --ff-only does not make much sense to me. A lot of people do stuff, but the rebase it. If I am parsing the above properly, I think that is only saying that pull --rebase makes sense for people who do real work, which I am not disagreeing. You claimed that 'git pull' (--ff-only) only makes sense if the primary user-base doesn't do any work on it, but that's not true; they can do a 'git rebase' after such pull (or a merge). We don't have to assume our primary user-base wants to do full fledged merges, in fact, such assumption would be wrong. If the proposal were to make pull.rebase the default at a major version bump and force all integrators and other people who are happy with how pull = fetch + merge (not fetch + rebase) works to say pull.rebase = false in their configuration, I think I can see why some people may think it makes sense, though. That makes perfect sense, because the people that are not familiar with Git more often than not end up making merges by mistake, and the ones that are familiar with it can easily configure it to do what they want Yes, in theory. The transition needs a major version bump, but it is doable (with unknown level of resistance). Isn't that what wer are discussing here? But neither is an easy sell, I would imagine. It is not about passing me, but about not hurting users like kernel folks we accumulated over 7-8 years. I've worked in the Linux kernel, and in my experience the vast vast majority of kernel developers don't do merges; they send patches. It's only the lieutenants that might do that, and although there are a lot, they don't surpass the 200, and they most definitely know how to configure Git to do what they need. And even then, most of them don't do merges, but create a linear history for Linus to merge. So the only one who does really rely on merges is Linus, I think he would have no problems configuring Git. That is not something I can agree or disagree without looping somebody whose judgement I can trust from the kernel circle ;-). See section 16) in Documentation/SubmittingPatches, notice how the whole section is written with Linus in mind. Some maintainers do have sub-maintainers that send pull requests to them, not Linus, but they are the minority. But most definitely pull requests are not for the general population (except in a few very rare exceptions maybe). -- 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: first parent, commit graph layout, and pull merge direction
Felipe Contreras felipe.contre...@gmail.com writes: Unless your primary user base is those who use Git as a deployment tool to always follow along the tip of some external repository without doing anything on your own on the branch you run your git pull on, defaulting it to --ff-only does not make much sense to me. A lot of people do stuff, but the rebase it. If I am parsing the above properly, I think that is only saying that pull --rebase makes sense for people who do real work, which I am not disagreeing. You claimed that 'git pull' (--ff-only) only makes sense if the primary user-base doesn't do any work on it, but that's not true; they can do a 'git rebase' after such pull (or a merge). Either you misread what I wrote or I was unclear. I really meant anything on your own *ON* THE BRANCH YOU RUN your git pull on. With git checkout frotz ; git pull --ff-only you do not do anything on frotz other than following along. You can of course commit, rebase and all others on other branches like xyzzy and push them out directly. But you cannot even do this once git checkout frotz; git merge xyzzy if you expect the next git checkout frotz; git pull --ff-only will keep working usefuly. We don't have to assume our primary user-base wants to do full fledged merges, in fact, such assumption would be wrong. I think we are in agreement on that point already. An assumption that people who do merges are somehow more well versed in Git and are more capable than others to configure their repository or they will not be annoyed if you asked them a single configuration change is also wrong, though. -- 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: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 6:26 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Unless your primary user base is those who use Git as a deployment tool to always follow along the tip of some external repository without doing anything on your own on the branch you run your git pull on, defaulting it to --ff-only does not make much sense to me. A lot of people do stuff, but the rebase it. If I am parsing the above properly, I think that is only saying that pull --rebase makes sense for people who do real work, which I am not disagreeing. You claimed that 'git pull' (--ff-only) only makes sense if the primary user-base doesn't do any work on it, but that's not true; they can do a 'git rebase' after such pull (or a merge). Either you misread what I wrote or I was unclear. I really meant anything on your own *ON* THE BRANCH YOU RUN your git pull on. With git checkout frotz ; git pull --ff-only you do not do anything on frotz other than following along. You can of course commit, rebase and all others on other branches like xyzzy and push them out directly. But you cannot even do this once git checkout frotz; git merge xyzzy if you expect the next git checkout frotz; git pull --ff-only will keep working usefuly. Unless you rebase. We could of course have a 'branch.name.allow_merge' configuration that gets automatically turned on the first time a 'git merge' is executed, but I feel that creates more inconsistency. We don't have to assume our primary user-base wants to do full fledged merges, in fact, such assumption would be wrong. I think we are in agreement on that point already. An assumption that people who do merges are somehow more well versed in Git and are more capable than others to configure their repository or they will not be annoyed if you asked them a single configuration change is also wrong, though. s/people who do merges/people who should do merges/ And no, it's not wrong. People who do merges should know what they are doing. The alternatives are these: a) you annoy the vast majority of the user-base by making 'git pull' a dangerous operation that should be avoided, and replaced with 'git fetch'+'git rebase'. b) you annoy a minority of the user-base by making 'git pull' not do the merge the expected, so they have to do +'git merge' (which is already less of a change than a)), or configure the default (which they most likely are able to do, if they did intent to do a merge). b) is clearly superior. -- 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: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 3:11 PM, Junio C Hamano gits...@pobox.com wrote: If the proposal were to make pull.rebase the default at a major version bump and force all integrators and other people who are happy with how pull = fetch + merge (not fetch + rebase) works to say pull.rebase = false in their configuration, I think I can see why some people may think it makes sense, though. But neither is an easy sell, I would imagine. It is not about passing me, but about not hurting users like kernel folks we accumulated over 7-8 years. It would be a *horrible* mistake to make rebase the default, because it's so much easier to screw things up that way. That said, making no-ff the default, and then if that fails, saying The pull was not a fast-forward pull, please say if you want to merge or rebase. Use either git pull --rebase git pull --merge You can also use git config pull.merge true or git config pull.rebase true to set this once for this project and forget about it. That way, people who want the existing behavior could just do that git config pull.merge true once, and they'd not even notice. Hmm? Better yet, make it per-branch. Linus -- 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: first parent, commit graph layout, and pull merge direction
Linus Torvalds torva...@linux-foundation.org writes: It would be a *horrible* mistake to make rebase the default, because it's so much easier to screw things up that way. That said, making no-ff the default, and then if that fails, saying The pull was not a fast-forward pull, please say if you want to merge or rebase. Use either git pull --rebase git pull --merge You can also use git config pull.merge true or git config pull.rebase true to set this once for this project and forget about it. That way, people who want the existing behavior could just do that git config pull.merge true once, and they'd not even notice. Hmm? Better yet, make it per-branch. I would assume that no-ff above was meant to be --ff-only from the first part of the message. I also would assume that I can rephrase that setting pull.merge (which does not exist) as setting pull.rebase explicitly to false instead (i.e. missing pull.rebase and pull.rebase that is explicitly set to false would mean two different things). I have to think about this a bit to convince myself that the message is clear enough and useful for those this updated behaviour is trying to help. After reading the above message three times, I still cannot shake the impression that we are just covering our backside to be able to say we told you already and you chose poorly, in case things go wrong for them later. -- 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: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 5:21 PM, Junio C Hamano gits...@pobox.com wrote: I would assume that no-ff above was meant to be --ff-only from the first part of the message. Yeah, I may need more coffee.. I also would assume that I can rephrase that setting pull.merge (which does not exist) as setting pull.rebase explicitly to false instead (i.e. missing pull.rebase and pull.rebase that is explicitly set to false would mean two different things). Yeah, sounds good to me, and doesn't really sound like it would confuse/annoy anybody as long as it was clearly documented. Linus -- 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: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano gits...@pobox.com wrote: Linus Torvalds torva...@linux-foundation.org writes: It would be a *horrible* mistake to make rebase the default, because it's so much easier to screw things up that way. That said, making no-ff the default, and then if that fails, saying The pull was not a fast-forward pull, please say if you want to merge or rebase. Use either git pull --rebase git pull --merge You can also use git config pull.merge true or git config pull.rebase true to set this once for this project and forget about it. That way, people who want the existing behavior could just do that git config pull.merge true once, and they'd not even notice. Hmm? Better yet, make it per-branch. I would assume that no-ff above was meant to be --ff-only from the first part of the message. I also would assume that I can rephrase that setting pull.merge (which does not exist) as setting pull.rebase explicitly to false instead (i.e. missing pull.rebase and pull.rebase that is explicitly set to false would mean two different things). I have to think about this a bit to convince myself that the message is clear enough and useful for those this updated behaviour is trying to help. After reading the above message three times, I still cannot shake the impression that we are just covering our backside to be able to say we told you already and you chose poorly, in case things go wrong for them later. FWIW this is the message Mercurial users get (and they often say Mercurial's UI makes more sense): pushing to /tmp/foo searching for changes abort: push creates new remote head 77eafc4313d5! (you should pull and merge or use push -f to force) -- 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: first parent, commit graph layout, and pull merge direction
On Thu, May 23, 2013 at 7:25 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano gits...@pobox.com wrote: Linus Torvalds torva...@linux-foundation.org writes: It would be a *horrible* mistake to make rebase the default, because it's so much easier to screw things up that way. That said, making no-ff the default, and then if that fails, saying The pull was not a fast-forward pull, please say if you want to merge or rebase. Use either git pull --rebase git pull --merge You can also use git config pull.merge true or git config pull.rebase true to set this once for this project and forget about it. That way, people who want the existing behavior could just do that git config pull.merge true once, and they'd not even notice. Hmm? Better yet, make it per-branch. I would assume that no-ff above was meant to be --ff-only from the first part of the message. I also would assume that I can rephrase that setting pull.merge (which does not exist) as setting pull.rebase explicitly to false instead (i.e. missing pull.rebase and pull.rebase that is explicitly set to false would mean two different things). I have to think about this a bit to convince myself that the message is clear enough and useful for those this updated behaviour is trying to help. After reading the above message three times, I still cannot shake the impression that we are just covering our backside to be able to say we told you already and you chose poorly, in case things go wrong for them later. FWIW this is the message Mercurial users get (and they often say Mercurial's UI makes more sense): pushing to /tmp/foo searching for changes abort: push creates new remote head 77eafc4313d5! (you should pull and merge or use push -f to force) Er, that's for push, but I don't see why something small like that wouldn't make sense: The pull was not fast-forward, please either merge or rebase. -- 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: first parent, commit graph layout, and pull merge direction
Andreas Krey a.k...@gmx.de writes: A short trial showed that representing first parent chains as straight lines in the graph does actually improve understandability, as feature branches clearly stand out as separate lines even when they no longer carry a branch name. If you have a four-commit segment in your commit ancestry graph (time flows from left to right; turn your head 90-degrees to the right if you want a gitk representation): ---A--X \/ /\ ---B--Y where X and Y are both merges between A and B, having A as their first parent, how would you express such a graph with first-parent chain going a straight line? Also, there is an implication with 'git pull': You'd expect the master branch to be a first parent line, but when I do a small thing directly on master and need to pull before pushing back, then origin/master is merged into my branch, and thus my side branch becomes the first parent line. Don't do that, then. -- 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
