On Tue, May 25, 2010 at 10:43:22AM +0200, Peter Kjellerstedt wrote: > > > > > I think this boils down to having a few people who are allowed to > > > > push merges because they can make these decisions. Even if people > > > > don't merge "origin" but their own branches they can create a mess, > > > > so you cannot differentiate based on that. > > > > > > In a larger organization this does not work. Most of our developers > > > are responsible for at least one subsystem and expected to be the one > > > responsible for its master branch. > > > > Right. Now, if only one person who is responsible for this subsystem is > > expected to be able to push changes to the master branch then this > > person will never need "git pull --ff-only". In fact, when he pulls > > Well, most of our subsystems have at least one backup maintainer Which is very reasonable, but I do not see how it contradicts to anything what I said above... > > changes from others, he needs a real merge. So, this alone a very > > strong argument against making ff-only by default in any configuration. > > Well, we use a central repository with development made on official > topic branches, so he is not supposed to pull from others. I am not sure what kind of workflow you are talking here, but in any case, the maintainer can pull those official topic branches when he believes it is ready for integration... > He will > fetch from the central repository and merge the topic branches. of course, you can do that using two commands instead of one... > That way the user > would have to take an explicit action, and decide whether he should > do a git pull --rebase, put his local changes on a branch or resolve > the problem some other way (initially that would probably be by > asking me what is going on and what to do, and that way learn how to > handle the situation). Silently creating an automatic merge that does It is as much automatic as those that are created by "git merge". If someone says "git pull", it means to do merge. In fact, before Git 1.5, "git pull" was the only porcelain command to do local merges (while "git merge" was a plumbing command with a different arguments than it has now). So, if you are only interested in fetching new changes then you should use "git fetch". Changing the default for "git pull" to do --ff-only is akin changing "git merge" to do --ff-only... > not have any meaning and will just confuse anyone looking at the > revision history later is not something that I want, especially as it > would make the job harder for the maintainer who is supposed to merge > the changes later and then has to untangle the mess. First, when you make a presentation of Git and the workflow that you are going to use, you can explicitly say what commands should be and what should not be normally used in this workflow. Second, when a maintainer sees a mess, he can just tell to this developer to rebase his changes and never use "git pull"... In fact, this is the least problem comparing to all other typical mistakes that inexperience developers do, such as, writing meaningless comments to commits, failure to split changes in logic steps, forget to test changes, etc... > > > And if you think that "pull --ff-only" is very useful for some reason, > > nobody prevents to add an alias for that command, but this command > > should never be called as "pull", because "pull" has always been about > > merging changes, and if it does something different, you should call it > > differently. Why don't call it as "fast-forward" or "ff" for short? > > I do not agree with you. When I do git pull it is to get all changes > made to the official repository. I do not want any local changes I have > to be merged with the official changes, but rather I want my changes > to stay separate, either by using git pull --rebase (if I have hacked > on the same branch for some reason), or by using a private topic branch > that I keep rebasing on master. If you want to get changes then you should use "git fetch", and not "git pull", because the latter is about getting and _merging_. Why are you trying so hard to change a well established meaning of the pull command? 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