Thread (13 messages) flat view 13 messages, 7 authors, 2016-06-16

Re: Use "git pull --ff-only" by default?

From: Dmitry Potapov <hidden>
Date: 2016-06-15 22:48:52

On Tue, May 25, 2010 at 10:43:22AM +0200, Peter Kjellerstedt wrote:
quoted
quoted
quoted
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...
quoted
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...
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help