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

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

[Peter Kjellerstedt]

Is there some way to make "git pull --ff-only" be the default?
I could not find anything about this in "git config --help" and
also the lack of a --no-ff-only option for git pull (it exists 
for git merge) indicates that there is no such support.

I did considered the branch.<name>.mergeoptions configuration
option, but it does not seem appropriate as it only applies to
a specific branch, whereas I want it to apply to all branches
by default.

Yes, I know I could do "git config alias.pl 'pull --ff-only'",
but since my intensions are for this to be the default for all
developers in our organization (most of whom have no git knowledge
at all yet) to avoid unnecessary branches caused by the developers 
hacking directly on master rather than a topic branch, I would 
very much prefer a configuration option rather than an alias (as 
I am unlikely to get the developers to remember to do "git pl" 
instead of "git pull").

My idea was to add something like merge.options and pull.options
as configuration options (I want to be able to specify the options
separately for pull and merge). However, I wanted throw this out
here first before starting to hack away at the code, in case I
missed something obvious, or if others find this to be an
incredibly stupid idea...

//Peter

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

[Ævar Arnfjörð Bjarmason]

On Fri, May 21, 2010 at 12:59, Peter Kjellerstedt
<peter.kjellerstedt@axis.com> wrote:
> Is there some way to make "git pull --ff-only" be the default?

Not with a config option, no.

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

[Michael J Gruber]

Peter Kjellerstedt venit, vidit, dixit 21.05.2010 14:59:
> Is there some way to make "git pull --ff-only" be the default?
> I could not find anything about this in "git config --help" and
> also the lack of a --no-ff-only option for git pull (it exists 
> for git merge) indicates that there is no such support.
> 
> I did considered the branch.<name>.mergeoptions configuration
> option, but it does not seem appropriate as it only applies to
> a specific branch, whereas I want it to apply to all branches
> by default.
> 
> Yes, I know I could do "git config alias.pl 'pull --ff-only'",
> but since my intensions are for this to be the default for all
> developers in our organization (most of whom have no git knowledge
> at all yet) to avoid unnecessary branches caused by the developers 
> hacking directly on master rather than a topic branch, I would 
> very much prefer a configuration option rather than an alias (as 
> I am unlikely to get the developers to remember to do "git pl" 
> instead of "git pull").

Problem is they have to remember to set your new config, or, if you are
able to set all developers system config, they have to refrain from
overriding it.

> My idea was to add something like merge.options and pull.options
> as configuration options (I want to be able to specify the options
> separately for pull and merge). However, I wanted throw this out
> here first before starting to hack away at the code, in case I
> missed something obvious, or if others find this to be an
> incredibly stupid idea...
> 

In general, you can't control reliably what people do in their repos.
But you can control what kind of pushes into a central repo you allow.
That is the usual approach: Let them mess up their repos, they'll learn
their lesson when they can't push ;)

Michael

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

[Peter Kjellerstedt]

> -----Original Message-----
> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
> Behalf Of Michael J Gruber
> Sent: den 21 maj 2010 15:49
> To: Peter Kjellerstedt
> Cc: git@vger.kernel.org
> Subject: Re: Use "git pull --ff-only" by default?
> 
> Peter Kjellerstedt venit, vidit, dixit 21.05.2010 14:59:
> > Is there some way to make "git pull --ff-only" be the default?
> > I could not find anything about this in "git config --help" and
> > also the lack of a --no-ff-only option for git pull (it exists
> > for git merge) indicates that there is no such support.
> >
> > I did considered the branch.<name>.mergeoptions configuration
> > option, but it does not seem appropriate as it only applies to
> > a specific branch, whereas I want it to apply to all branches
> > by default.
> >
> > Yes, I know I could do "git config alias.pl 'pull --ff-only'",
> > but since my intensions are for this to be the default for all
> > developers in our organization (most of whom have no git knowledge
> > at all yet) to avoid unnecessary branches caused by the developers
> > hacking directly on master rather than a topic branch, I would
> > very much prefer a configuration option rather than an alias (as
> > I am unlikely to get the developers to remember to do "git pl"
> > instead of "git pull").
> 
> Problem is they have to remember to set your new config, or, if you are
> able to set all developers system config, they have to refrain from
> overriding it.

They would get it by default from our setup scripts. If they then 
choose to turn it off, so be it.

> > My idea was to add something like merge.options and pull.options
> > as configuration options (I want to be able to specify the options
> > separately for pull and merge). However, I wanted throw this out
> > here first before starting to hack away at the code, in case I
> > missed something obvious, or if others find this to be an
> > incredibly stupid idea...
> 
> In general, you can't control reliably what people do in their repos.

I sure wish I had more control over it, but that is a separate 
discussion. ;)

> But you can control what kind of pushes into a central repo you allow.
> That is the usual approach: Let them mess up their repos, they'll learn
> their lesson when they can't push ;)

Can you differentiate between an automatic merge which happened
because the user had made some local changes before pulling (which
I do not want to appear in the central repo), and a real merge of 
a topic branch (which I do want)?

> Michael

//Peter

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

[Michael J Gruber]

Peter Kjellerstedt venit, vidit, dixit 21.05.2010 16:47:
>> -----Original Message-----
>> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
>> Behalf Of Michael J Gruber
>> Sent: den 21 maj 2010 15:49
>> To: Peter Kjellerstedt
>> Cc: git@vger.kernel.org
>> Subject: Re: Use "git pull --ff-only" by default?
>>
>> Peter Kjellerstedt venit, vidit, dixit 21.05.2010 14:59:
>>> Is there some way to make "git pull --ff-only" be the default?
>>> I could not find anything about this in "git config --help" and
>>> also the lack of a --no-ff-only option for git pull (it exists
>>> for git merge) indicates that there is no such support.
>>>
>>> I did considered the branch.<name>.mergeoptions configuration
>>> option, but it does not seem appropriate as it only applies to
>>> a specific branch, whereas I want it to apply to all branches
>>> by default.
>>>
>>> Yes, I know I could do "git config alias.pl 'pull --ff-only'",
>>> but since my intensions are for this to be the default for all
>>> developers in our organization (most of whom have no git knowledge
>>> at all yet) to avoid unnecessary branches caused by the developers
>>> hacking directly on master rather than a topic branch, I would
>>> very much prefer a configuration option rather than an alias (as
>>> I am unlikely to get the developers to remember to do "git pl"
>>> instead of "git pull").
>>
>> Problem is they have to remember to set your new config, or, if you are
>> able to set all developers system config, they have to refrain from
>> overriding it.
> 
> They would get it by default from our setup scripts. If they then 
> choose to turn it off, so be it.

If you're relying on setup scripts, you can

git config alias.pull 'pull --ff-only'

> 
>>> My idea was to add something like merge.options and pull.options
>>> as configuration options (I want to be able to specify the options
>>> separately for pull and merge). However, I wanted throw this out
>>> here first before starting to hack away at the code, in case I
>>> missed something obvious, or if others find this to be an
>>> incredibly stupid idea...
>>
>> In general, you can't control reliably what people do in their repos.
> 
> I sure wish I had more control over it, but that is a separate 
> discussion. ;)
> 
>> But you can control what kind of pushes into a central repo you allow.
>> That is the usual approach: Let them mess up their repos, they'll learn
>> their lesson when they can't push ;)
> 
> Can you differentiate between an automatic merge which happened
> because the user had made some local changes before pulling (which
> I do not want to appear in the central repo), and a real merge of 
> a topic branch (which I do want)?

I can't, and neither can Git. Who can?

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.

Michael

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

[Peter Krefting]

Peter Kjellerstedt:

> Can you differentiate between an automatic merge which happened because 
> the user had made some local changes before pulling (which I do not want 
> to appear in the central repo), and a real merge of a topic branch (which 
> I do want)?

Sort of, by looking at the commit message. An auto-generated pull-merge will 
contain the branch name twice, once with the remote repository path, and 
once with the local repository path. You could walk the history that the 
user tries to push, looking for this kind of auto-generated merge messages.

This may of course teach your users to re-write the commit message into 
something more sensible, but that can only be a good thing :-)

-- 
\\// Peter - http://www.softwolves.pp.se/

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

[Jay Soffian]

On Fri, May 21, 2010 at 11:18 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:

> git config alias.pull 'pull --ff-only'

That won't work. You cannot override built-in commands. Look at
run.argv() in git.c and notice it doesn't process aliases unless
handle_internal_command() and execv_dashed_external() fail.

j.

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

[Michael J Gruber]

Jay Soffian venit, vidit, dixit 21.05.2010 21:13:
> On Fri, May 21, 2010 at 11:18 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
> 
>> git config alias.pull 'pull --ff-only'
> 
> That won't work. You cannot override built-in commands. Look at
> run.argv() in git.c and notice it doesn't process aliases unless
> handle_internal_command() and execv_dashed_external() fail.

I was sure it worked at some point. Maybe I'm just so used to my "ci"
(read: check-in) alias for "commit" that being able to override that one
(to "commit -s" for git.git) fooled my perception. Sorry!

Michael

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

[Peter Kjellerstedt]

> -----Original Message-----
> From: Michael J Gruber [mailto:git@drmicha.warpmail.net]
> Sent: den 21 maj 2010 17:18
> To: Peter Kjellerstedt
> Cc: git@vger.kernel.org
> Subject: Re: Use "git pull --ff-only" by default?
> 
> Peter Kjellerstedt venit, vidit, dixit 21.05.2010 16:47:
> >> -----Original Message-----
> >> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org]
> >> On Behalf Of Michael J Gruber
> >> Sent: den 21 maj 2010 15:49
> >> To: Peter Kjellerstedt
> >> Cc: git@vger.kernel.org
> >> Subject: Re: Use "git pull --ff-only" by default?
> >>
> >> Peter Kjellerstedt venit, vidit, dixit 21.05.2010 14:59:
> >>> Is there some way to make "git pull --ff-only" be the default?
> >>> I could not find anything about this in "git config --help" and
> >>> also the lack of a --no-ff-only option for git pull (it exists
> >>> for git merge) indicates that there is no such support.
> >>>
> >>> I did considered the branch.<name>.mergeoptions configuration
> >>> option, but it does not seem appropriate as it only applies to
> >>> a specific branch, whereas I want it to apply to all branches
> >>> by default.
> >>>
> >>> Yes, I know I could do "git config alias.pl 'pull --ff-only'",
> >>> but since my intensions are for this to be the default for all
> >>> developers in our organization (most of whom have no git knowledge
> >>> at all yet) to avoid unnecessary branches caused by the developers
> >>> hacking directly on master rather than a topic branch, I would
> >>> very much prefer a configuration option rather than an alias (as
> >>> I am unlikely to get the developers to remember to do "git pl"
> >>> instead of "git pull").
> >>
> >> Problem is they have to remember to set your new config, or, if you
> >> are able to set all developers system config, they have to refrain 
> >> from overriding it.
> >
> > They would get it by default from our setup scripts. If they then
> > choose to turn it off, so be it.
> 
> If you're relying on setup scripts, you can
> 
> git config alias.pull 'pull --ff-only'

I forgot to mention that I had tried that. It does not work as git 
explicitly does not allow one to use a git command name as an alias 
name. And I think this is a good policy since it prevents people 
from aliasing plumbing commands to do weird things. However, I would
like to see some way to affect the defaults of porcelain commands.

> >>> My idea was to add something like merge.options and pull.options
> >>> as configuration options (I want to be able to specify the options
> >>> separately for pull and merge). However, I wanted throw this out
> >>> here first before starting to hack away at the code, in case I
> >>> missed something obvious, or if others find this to be an
> >>> incredibly stupid idea...
> >>
> >> In general, you can't control reliably what people do in their
> >> repos.
> >
> > I sure wish I had more control over it, but that is a separate
> > discussion. ;)
> >
> >> But you can control what kind of pushes into a central repo you
> >> allow. That is the usual approach: Let them mess up their repos, 
> >> they'll learn their lesson when they can't push ;)
> >
> > Can you differentiate between an automatic merge which happened
> > because the user had made some local changes before pulling (which
> > I do not want to appear in the central repo), and a real merge of
> > a topic branch (which I do want)?
> 
> I can't, and neither can Git. Who can?

Exactly. Which is why I would like for --ff-only to be the default
as I think that is more sane in an environment where most of the
users are git newbies.

> 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. We cannot rely on a few git veterans 
to be the only ones with merging rights; it would never be accepted by 
the management...

> Michael

//Peter

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

[Dmitry Potapov]

On Mon, May 24, 2010 at 10:22:45AM +0200, Peter Kjellerstedt wrote:
> 
> I forgot to mention that I had tried that. It does not work as git 
> explicitly does not allow one to use a git command name as an alias 
> name. And I think this is a good policy since it prevents people 
> from aliasing plumbing commands to do weird things. However, I would
> like to see some way to affect the defaults of porcelain commands.

Though, some porcelain commands (such as "branch") should never be used
in scripts, many others do not have low-level analogue, so they are
commonly used in scripts.

> 
> > 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
changes from others, he needs a real merge. So, this alone a very strong
argument against making ff-only by default in any configuration.

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?


Dmitry

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

[Peter Kjellerstedt]

> -----Original Message-----
> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
> Behalf Of Dmitry Potapov
> Sent: den 24 maj 2010 14:57
> To: Peter Kjellerstedt
> Cc: Michael J Gruber; git@vger.kernel.org
> Subject: Re: Use "git pull --ff-only" by default?
> 
> On Mon, May 24, 2010 at 10:22:45AM +0200, Peter Kjellerstedt wrote:
> >
> > I forgot to mention that I had tried that. It does not work as git
> > explicitly does not allow one to use a git command name as an alias
> > name. And I think this is a good policy since it prevents people
> > from aliasing plumbing commands to do weird things. However, I would
> > like to see some way to affect the defaults of porcelain commands.
> 
> Though, some porcelain commands (such as "branch") should never be used
> in scripts, many others do not have low-level analogue, so they are
> commonly used in scripts.

Well, then I guess it would have to be either specific options for
specific commands, or more generic as any options for specific commands.
The problem then becomes selecting which options and which commands
are allowed to take default values.

> > > 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 
(we cannot stop development just because the main maintainer is home
sick, or on leave), so this is not necessarily true in our case.

> 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. He will 
fetch from the central repository and merge the topic branches. And
I do not expect anyone to merge using git pull, but rather using an
explicit git merge. This is why I want to prevent accidental merges 
using git pull by giving the --ff-only option. 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 
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.

> 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. And having --ff-only by default would 
save me from mishaps in case I forget to give the --rebase option.

And knowing that all our developers come from CVS, I expect it to take
quite a while until they have learned to not just start hacking and
doing occasional git pulls, but rather create separate topic branches 
and rebasing. And in the meantime I want to protect our repositories
from the automatic merges introduces by git pull without --ff-only 
and/or --rebase. 

I have also refrained from setting branch.autosetuprebase to remote 
since I prefer the users to make an active choice as to how to resolve 
updating their branches (and because of the note given for 
branch.<name>.rebase marking it as possibly dangerous to use by default).

> Dmitry

//Peter

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

[Dmitry Potapov]

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

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

[Monsignor]

For people who still find this thread in Google, there is a way to do that
now:

*git config --add pull.ff only*

>From the documentation:

pull.ff
    By default, Git does not create an extra merge commit when merging a
commit that is a descendant of the current commit. Instead, the tip of the
current branch is fast-forwarded. When set to false, this variable tells Git
to create an extra merge commit in such a case (equivalent to giving the
--no-ff option from the command line). When set to only, only such
fast-forward merges are allowed (equivalent to giving the --ff-only option
from the command line). This setting overrides merge.ff when pulling.




--
View this message in context: http://git.661346.n2.nabble.com/Use-git-pull-ff-only-by-default-tp5084103p7654696.html
Sent from the git mailing list archive at Nabble.com.