On Wed, Mar 14, 2012 at 1:07 PM, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > Dmitry Potapov <dpotapov@xxxxxxxxx> writes: > >> If there is a centralized workflow with only one branch then >> everything is simple, but it is not so with other workflows. > > I don't get this. With either 'current' or 'upstream', both pull and > push deal with one local and one remote branch. The only asymetry is the > case of non-fast forward (push fails, pull merges). But it's all about > transmitting changes from a branch to another, in one or another > direction. If a user has 'master' after cloning and then create another branch with different names, are you sure that the user expects that this second branch to be pushed to a remote 'master'? And then what about his stale local 'master'? Those who understand the concept tracking may be happy with 'upstream' but when it comes to the least surprise principle for beginner , I believe 'current' is better. Maybe it would be even better if it did not create a new remote branch without asking first: Staying on foo-branch, you do: $ git push Warning: foo-branch does not exist on the remote, if you want to create it, type: "git push foo-branch" In this way, it will be safer. > >> Moreover, doing 'git pull' too often (unless it is 'git pull --rebase) >> pollutes history with useless merges, making more difficult to review >> changes, or doing git-bisect. > > What's your point here? How does it invalidate the rule of thumb above? The point is that you still need to understand what you are doing. It is not 'pull' magically resolve the problem. On the other hand, if you really want a workflow similar to CVS then you need "git pull --rebase" (you can configure 'pull' to do rebase by default, but beginners do not know about it). BTW, whether you do merge or rebase, you still need to test the result before pushing. Even if there was no conflicts, it may not work anymore. And while you are merging and testing everything, somebody else could push his changes. So, a centralized workflow may appear simple, but it does not scale well, and often leads to many untested and hastily merged commits. >> I agree that the current diagnostic is not suitable for beginners. >> Not-fast-forward push is something that beginners should never use, >> but from this message is not clear what is the alternative to forcing >> non-fast-forward push. > > Again, what would you suggest? Teach --force to beginners? Not of course. I said above non-fast forward push should not be used by beginners. However, if you have branches and merge them (using 'pull' or 'merge'), it is silly pretend that they do not exist. If you happy with CVS-like behavior then just do "pull --rebase". > >>> One can easily get in this situation even in a kernel-style workflow: >>> work from your desktop, push, work from your laptop, try to push and it >>> fails. >> >> IMHO, when you often switch between your desktop and laptop, 'matching' >> makes much more sense. > > Then, if you worked on branch 'foo' from your desktop, and 'bar' on your > laptop, you'll get errors about non-fast forward push from both machines. Right... and then I look at the cause, and usually I have made some minor fixes to some series of patches. So when I make my mind, I do non-fast forward push, but I do not think it is how beginners should start to use 'git'. > >> If 'push' fails then usually I want to force non- fast-forward push, >> because the new series contain reworked patches that already were on >> the other computer. > > ... but if they were not, you've just silently errased your previous > work. I have no problem with you working like this, but please don't > teach that to beginners. Basically, it is same as doing 'git reset --hard somewhere'. I use it sometimes, but I have never suggested that for beginners... Dmitry -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html