{"thread":{"id":"23866","subject":"Use \"git pull --ff-only\" by default?","startedAt":"2010-05-21T12:59:07Z","lastAt":"2016-04-29T06:38:50Z","messageCount":13,"participants":["Peter Kjellerstedt","Ævar Arnfjörð Bjarmason","Michael J Gruber","Peter Krefting","Jay Soffian","Dmitry Potapov","Monsignor"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"142026","messageId":"A612847CFE53224C91B23E3A5B48BAC74483234E90@xmail3.se.axis.com","threadId":"23866","inReplyTo":null,"subject":"Use \"git pull --ff-only\" by default?","fromName":"Peter Kjellerstedt","fromEmail":"peter.kjellerstedt@axis.com","sentAt":"2010-05-21T12:59:07Z","receivedAt":"2010-05-21T12:59:07Z","isPatch":false,"sender":{"key":"peter.kjellerstedt@axis.com","avatar":"https://gravatar.com/avatar/6d5a0182283c8eccd7b134a54dbfd5f30038f3ad4d38b96f424884b614a61ca2?d=mp&s=160"},"body":"Is there some way to make \"git pull --ff-only\" be the default?\nI could not find anything about this in \"git config --help\" and\nalso the lack of a --no-ff-only option for git pull (it exists \nfor git merge) indicates that there is no such support.\n\nI did considered the branch.<name>.mergeoptions configuration\noption, but it does not seem appropriate as it only applies to\na specific branch, whereas I want it to apply to all branches\nby default.\n\nYes, I know I could do \"git config alias.pl 'pull --ff-only'\",\nbut since my intensions are for this to be the default for all\ndevelopers in our organization (most of whom have no git knowledge\nat all yet) to avoid unnecessary branches caused by the developers \nhacking directly on master rather than a topic branch, I would \nvery much prefer a configuration option rather than an alias (as \nI am unlikely to get the developers to remember to do \"git pl\" \ninstead of \"git pull\").\n\nMy idea was to add something like merge.options and pull.options\nas configuration options (I want to be able to specify the options\nseparately for pull and merge). However, I wanted throw this out\nhere first before starting to hack away at the code, in case I\nmissed something obvious, or if others find this to be an\nincredibly stupid idea...\n\n//Peter\n"},{"id":"142027","messageId":"AANLkTikVp6_FW0Eq-PHRjXDvWBChuMGfOUrfkxIdW6Y8@mail.gmail.com","threadId":"23866","inReplyTo":"A612847CFE53224C91B23E3A5B48BAC74483234E90@xmail3.se.axis.com","subject":"Re: Use \"git pull --ff-only\" by default?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-05-21T13:46:19Z","receivedAt":"2010-05-21T13:46:19Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, May 21, 2010 at 12:59, Peter Kjellerstedt\n<peter.kjellerstedt@axis.com> wrote:\n> Is there some way to make \"git pull --ff-only\" be the default?\n\nNot with a config option, no.\n"},{"id":"142028","messageId":"4BF68F5F.9010309@drmicha.warpmail.net","threadId":"23866","inReplyTo":"A612847CFE53224C91B23E3A5B48BAC74483234E90@xmail3.se.axis.com","subject":"Re: Use \"git pull --ff-only\" by default?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-21T13:49:19Z","receivedAt":"2010-05-21T13:49:19Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Peter Kjellerstedt venit, vidit, dixit 21.05.2010 14:59:\n> Is there some way to make \"git pull --ff-only\" be the default?\n> I could not find anything about this in \"git config --help\" and\n> also the lack of a --no-ff-only option for git pull (it exists \n> for git merge) indicates that there is no such support.\n> \n> I did considered the branch.<name>.mergeoptions configuration\n> option, but it does not seem appropriate as it only applies to\n> a specific branch, whereas I want it to apply to all branches\n> by default.\n> \n> Yes, I know I could do \"git config alias.pl 'pull --ff-only'\",\n> but since my intensions are for this to be the default for all\n> developers in our organization (most of whom have no git knowledge\n> at all yet) to avoid unnecessary branches caused by the developers \n> hacking directly on master rather than a topic branch, I would \n> very much prefer a configuration option rather than an alias (as \n> I am unlikely to get the developers to remember to do \"git pl\" \n> instead of \"git pull\").\n\nProblem is they have to remember to set your new config, or, if you are\nable to set all developers system config, they have to refrain from\noverriding it.\n\n> My idea was to add something like merge.options and pull.options\n> as configuration options (I want to be able to specify the options\n> separately for pull and merge). However, I wanted throw this out\n> here first before starting to hack away at the code, in case I\n> missed something obvious, or if others find this to be an\n> incredibly stupid idea...\n> \n\nIn general, you can't control reliably what people do in their repos.\nBut you can control what kind of pushes into a central repo you allow.\nThat is the usual approach: Let them mess up their repos, they'll learn\ntheir lesson when they can't push ;)\n\nMichael\n"},{"id":"142032","messageId":"A612847CFE53224C91B23E3A5B48BAC74483234EDE@xmail3.se.axis.com","threadId":"23866","inReplyTo":"4BF68F5F.9010309@drmicha.warpmail.net","subject":"RE: Use \"git pull --ff-only\" by default?","fromName":"Peter Kjellerstedt","fromEmail":"peter.kjellerstedt@axis.com","sentAt":"2010-05-21T14:47:49Z","receivedAt":"2010-05-21T14:47:49Z","isPatch":false,"sender":{"key":"peter.kjellerstedt@axis.com","avatar":"https://gravatar.com/avatar/6d5a0182283c8eccd7b134a54dbfd5f30038f3ad4d38b96f424884b614a61ca2?d=mp&s=160"},"body":"> -----Original Message-----\n> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On\n> Behalf Of Michael J Gruber\n> Sent: den 21 maj 2010 15:49\n> To: Peter Kjellerstedt\n> Cc: git@vger.kernel.org\n> Subject: Re: Use \"git pull --ff-only\" by default?\n> \n> Peter Kjellerstedt venit, vidit, dixit 21.05.2010 14:59:\n> > Is there some way to make \"git pull --ff-only\" be the default?\n> > I could not find anything about this in \"git config --help\" and\n> > also the lack of a --no-ff-only option for git pull (it exists\n> > for git merge) indicates that there is no such support.\n> >\n> > I did considered the branch.<name>.mergeoptions configuration\n> > option, but it does not seem appropriate as it only applies to\n> > a specific branch, whereas I want it to apply to all branches\n> > by default.\n> >\n> > Yes, I know I could do \"git config alias.pl 'pull --ff-only'\",\n> > but since my intensions are for this to be the default for all\n> > developers in our organization (most of whom have no git knowledge\n> > at all yet) to avoid unnecessary branches caused by the developers\n> > hacking directly on master rather than a topic branch, I would\n> > very much prefer a configuration option rather than an alias (as\n> > I am unlikely to get the developers to remember to do \"git pl\"\n> > instead of \"git pull\").\n> \n> Problem is they have to remember to set your new config, or, if you are\n> able to set all developers system config, they have to refrain from\n> overriding it.\n\nThey would get it by default from our setup scripts. If they then \nchoose to turn it off, so be it.\n\n> > My idea was to add something like merge.options and pull.options\n> > as configuration options (I want to be able to specify the options\n> > separately for pull and merge). However, I wanted throw this out\n> > here first before starting to hack away at the code, in case I\n> > missed something obvious, or if others find this to be an\n> > incredibly stupid idea...\n> \n> In general, you can't control reliably what people do in their repos.\n\nI sure wish I had more control over it, but that is a separate \ndiscussion. ;)\n\n> But you can control what kind of pushes into a central repo you allow.\n> That is the usual approach: Let them mess up their repos, they'll learn\n> their lesson when they can't push ;)\n\nCan you differentiate between an automatic merge which happened\nbecause the user had made some local changes before pulling (which\nI do not want to appear in the central repo), and a real merge of \na topic branch (which I do want)?\n\n> Michael\n\n//Peter\n"},{"id":"142039","messageId":"4BF6A445.1030105@drmicha.warpmail.net","threadId":"23866","inReplyTo":"A612847CFE53224C91B23E3A5B48BAC74483234EDE@xmail3.se.axis.com","subject":"Re: Use \"git pull --ff-only\" by default?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-21T15:18:29Z","receivedAt":"2010-05-21T15:18:29Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Peter Kjellerstedt venit, vidit, dixit 21.05.2010 16:47:\n>> -----Original Message-----\n>> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On\n>> Behalf Of Michael J Gruber\n>> Sent: den 21 maj 2010 15:49\n>> To: Peter Kjellerstedt\n>> Cc: git@vger.kernel.org\n>> Subject: Re: Use \"git pull --ff-only\" by default?\n>>\n>> Peter Kjellerstedt venit, vidit, dixit 21.05.2010 14:59:\n>>> Is there some way to make \"git pull --ff-only\" be the default?\n>>> I could not find anything about this in \"git config --help\" and\n>>> also the lack of a --no-ff-only option for git pull (it exists\n>>> for git merge) indicates that there is no such support.\n>>>\n>>> I did considered the branch.<name>.mergeoptions configuration\n>>> option, but it does not seem appropriate as it only applies to\n>>> a specific branch, whereas I want it to apply to all branches\n>>> by default.\n>>>\n>>> Yes, I know I could do \"git config alias.pl 'pull --ff-only'\",\n>>> but since my intensions are for this to be the default for all\n>>> developers in our organization (most of whom have no git knowledge\n>>> at all yet) to avoid unnecessary branches caused by the developers\n>>> hacking directly on master rather than a topic branch, I would\n>>> very much prefer a configuration option rather than an alias (as\n>>> I am unlikely to get the developers to remember to do \"git pl\"\n>>> instead of \"git pull\").\n>>\n>> Problem is they have to remember to set your new config, or, if you are\n>> able to set all developers system config, they have to refrain from\n>> overriding it.\n> \n> They would get it by default from our setup scripts. If they then \n> choose to turn it off, so be it.\n\nIf you're relying on setup scripts, you can\n\ngit config alias.pull 'pull --ff-only'\n\n> \n>>> My idea was to add something like merge.options and pull.options\n>>> as configuration options (I want to be able to specify the options\n>>> separately for pull and merge). However, I wanted throw this out\n>>> here first before starting to hack away at the code, in case I\n>>> missed something obvious, or if others find this to be an\n>>> incredibly stupid idea...\n>>\n>> In general, you can't control reliably what people do in their repos.\n> \n> I sure wish I had more control over it, but that is a separate \n> discussion. ;)\n> \n>> But you can control what kind of pushes into a central repo you allow.\n>> That is the usual approach: Let them mess up their repos, they'll learn\n>> their lesson when they can't push ;)\n> \n> Can you differentiate between an automatic merge which happened\n> because the user had made some local changes before pulling (which\n> I do not want to appear in the central repo), and a real merge of \n> a topic branch (which I do want)?\n\nI can't, and neither can Git. Who can?\n\nI think this boils down to having a few people who are allowed to push\nmerges because they can make these decisions. Even if people don't merge\n\"origin\" but their own branches they can create a mess, so you cannot\ndifferentiate based on that.\n\nMichael\n"},{"id":"142063","messageId":"alpine.DEB.2.00.1005211848160.9961@perkele.intern.softwolves.pp.se","threadId":"23866","inReplyTo":"A612847CFE53224C91B23E3A5B48BAC74483234EDE@xmail3.se.axis.com","subject":"RE: Use \"git pull --ff-only\" by default?","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2010-05-21T17:49:52Z","receivedAt":"2010-05-21T17:49:52Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Peter Kjellerstedt:\n\n> Can you differentiate between an automatic merge which happened because \n> the user had made some local changes before pulling (which I do not want \n> to appear in the central repo), and a real merge of a topic branch (which \n> I do want)?\n\nSort of, by looking at the commit message. An auto-generated pull-merge will \ncontain the branch name twice, once with the remote repository path, and \nonce with the local repository path. You could walk the history that the \nuser tries to push, looking for this kind of auto-generated merge messages.\n\nThis may of course teach your users to re-write the commit message into \nsomething more sensible, but that can only be a good thing :-)\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"142068","messageId":"AANLkTilfD1jhDcyuK9zAthlW4vRU-15TmBgYlc16W0Ux@mail.gmail.com","threadId":"23866","inReplyTo":"4BF6A445.1030105@drmicha.warpmail.net","subject":"Re: Use \"git pull --ff-only\" by default?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2010-05-21T19:13:38Z","receivedAt":"2010-05-21T19:13:38Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Fri, May 21, 2010 at 11:18 AM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n\n> git config alias.pull 'pull --ff-only'\n\nThat won't work. You cannot override built-in commands. Look at\nrun.argv() in git.c and notice it doesn't process aliases unless\nhandle_internal_command() and execv_dashed_external() fail.\n\nj.\n"},{"id":"142091","messageId":"4BF7C1EB.8040702@drmicha.warpmail.net","threadId":"23866","inReplyTo":"AANLkTilfD1jhDcyuK9zAthlW4vRU-15TmBgYlc16W0Ux@mail.gmail.com","subject":"Re: Use \"git pull --ff-only\" by default?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-22T11:37:15Z","receivedAt":"2010-05-22T11:37:15Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jay Soffian venit, vidit, dixit 21.05.2010 21:13:\n> On Fri, May 21, 2010 at 11:18 AM, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n> \n>> git config alias.pull 'pull --ff-only'\n> \n> That won't work. You cannot override built-in commands. Look at\n> run.argv() in git.c and notice it doesn't process aliases unless\n> handle_internal_command() and execv_dashed_external() fail.\n\nI was sure it worked at some point. Maybe I'm just so used to my \"ci\"\n(read: check-in) alias for \"commit\" that being able to override that one\n(to \"commit -s\" for git.git) fooled my perception. Sorry!\n\nMichael\n"},{"id":"142181","messageId":"A612847CFE53224C91B23E3A5B48BAC74483234FAA@xmail3.se.axis.com","threadId":"23866","inReplyTo":"4BF6A445.1030105@drmicha.warpmail.net","subject":"RE: Use \"git pull --ff-only\" by default?","fromName":"Peter Kjellerstedt","fromEmail":"peter.kjellerstedt@axis.com","sentAt":"2010-05-24T08:22:45Z","receivedAt":"2010-05-24T08:22:45Z","isPatch":false,"sender":{"key":"peter.kjellerstedt@axis.com","avatar":"https://gravatar.com/avatar/6d5a0182283c8eccd7b134a54dbfd5f30038f3ad4d38b96f424884b614a61ca2?d=mp&s=160"},"body":"> -----Original Message-----\n> From: Michael J Gruber [mailto:git@drmicha.warpmail.net]\n> Sent: den 21 maj 2010 17:18\n> To: Peter Kjellerstedt\n> Cc: git@vger.kernel.org\n> Subject: Re: Use \"git pull --ff-only\" by default?\n> \n> Peter Kjellerstedt venit, vidit, dixit 21.05.2010 16:47:\n> >> -----Original Message-----\n> >> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org]\n> >> On Behalf Of Michael J Gruber\n> >> Sent: den 21 maj 2010 15:49\n> >> To: Peter Kjellerstedt\n> >> Cc: git@vger.kernel.org\n> >> Subject: Re: Use \"git pull --ff-only\" by default?\n> >>\n> >> Peter Kjellerstedt venit, vidit, dixit 21.05.2010 14:59:\n> >>> Is there some way to make \"git pull --ff-only\" be the default?\n> >>> I could not find anything about this in \"git config --help\" and\n> >>> also the lack of a --no-ff-only option for git pull (it exists\n> >>> for git merge) indicates that there is no such support.\n> >>>\n> >>> I did considered the branch.<name>.mergeoptions configuration\n> >>> option, but it does not seem appropriate as it only applies to\n> >>> a specific branch, whereas I want it to apply to all branches\n> >>> by default.\n> >>>\n> >>> Yes, I know I could do \"git config alias.pl 'pull --ff-only'\",\n> >>> but since my intensions are for this to be the default for all\n> >>> developers in our organization (most of whom have no git knowledge\n> >>> at all yet) to avoid unnecessary branches caused by the developers\n> >>> hacking directly on master rather than a topic branch, I would\n> >>> very much prefer a configuration option rather than an alias (as\n> >>> I am unlikely to get the developers to remember to do \"git pl\"\n> >>> instead of \"git pull\").\n> >>\n> >> Problem is they have to remember to set your new config, or, if you\n> >> are able to set all developers system config, they have to refrain \n> >> from overriding it.\n> >\n> > They would get it by default from our setup scripts. If they then\n> > choose to turn it off, so be it.\n> \n> If you're relying on setup scripts, you can\n> \n> git config alias.pull 'pull --ff-only'\n\nI forgot to mention that I had tried that. It does not work as git \nexplicitly does not allow one to use a git command name as an alias \nname. And I think this is a good policy since it prevents people \nfrom aliasing plumbing commands to do weird things. However, I would\nlike to see some way to affect the defaults of porcelain commands.\n\n> >>> My idea was to add something like merge.options and pull.options\n> >>> as configuration options (I want to be able to specify the options\n> >>> separately for pull and merge). However, I wanted throw this out\n> >>> here first before starting to hack away at the code, in case I\n> >>> missed something obvious, or if others find this to be an\n> >>> incredibly stupid idea...\n> >>\n> >> In general, you can't control reliably what people do in their\n> >> repos.\n> >\n> > I sure wish I had more control over it, but that is a separate\n> > discussion. ;)\n> >\n> >> But you can control what kind of pushes into a central repo you\n> >> allow. That is the usual approach: Let them mess up their repos, \n> >> they'll learn their lesson when they can't push ;)\n> >\n> > Can you differentiate between an automatic merge which happened\n> > because the user had made some local changes before pulling (which\n> > I do not want to appear in the central repo), and a real merge of\n> > a topic branch (which I do want)?\n> \n> I can't, and neither can Git. Who can?\n\nExactly. Which is why I would like for --ff-only to be the default\nas I think that is more sane in an environment where most of the\nusers are git newbies.\n\n> I think this boils down to having a few people who are allowed to push\n> merges because they can make these decisions. Even if people don't\n> merge \"origin\" but their own branches they can create a mess, so you \n> cannot differentiate based on that.\n\nIn a larger organization this does not work. Most of our developers\nare responsible for at least one subsystem and expected to be the one \nresponsible for its master branch. We cannot rely on a few git veterans \nto be the only ones with merging rights; it would never be accepted by \nthe management...\n\n> Michael\n\n//Peter\n"},{"id":"142202","messageId":"20100524125637.GE3005@dpotapov.dyndns.org","threadId":"23866","inReplyTo":"A612847CFE53224C91B23E3A5B48BAC74483234FAA@xmail3.se.axis.com","subject":"Re: Use \"git pull --ff-only\" by default?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-24T12:56:37Z","receivedAt":"2010-05-24T12:56:37Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, May 24, 2010 at 10:22:45AM +0200, Peter Kjellerstedt wrote:\n> \n> I forgot to mention that I had tried that. It does not work as git \n> explicitly does not allow one to use a git command name as an alias \n> name. And I think this is a good policy since it prevents people \n> from aliasing plumbing commands to do weird things. However, I would\n> like to see some way to affect the defaults of porcelain commands.\n\nThough, some porcelain commands (such as \"branch\") should never be used\nin scripts, many others do not have low-level analogue, so they are\ncommonly used in scripts.\n\n> \n> > I think this boils down to having a few people who are allowed to push\n> > merges because they can make these decisions. Even if people don't\n> > merge \"origin\" but their own branches they can create a mess, so you \n> > cannot differentiate based on that.\n> \n> In a larger organization this does not work. Most of our developers\n> are responsible for at least one subsystem and expected to be the one \n> responsible for its master branch.\n\nRight. Now, if only one person who is responsible for this subsystem is\nexpected to be able to push changes to the master branch then this\nperson will never need \"git pull --ff-only\". In fact, when he pulls\nchanges from others, he needs a real merge. So, this alone a very strong\nargument against making ff-only by default in any configuration.\n\nAnd if you think that \"pull --ff-only\" is very useful for some reason,\nnobody prevents to add an alias for that command, but this command\nshould never be called as \"pull\", because \"pull\" has always been about\nmerging changes, and if it does something different, you should call it\ndifferently. Why don't call it as \"fast-forward\" or \"ff\" for short?\n\n\nDmitry\n"},{"id":"142256","messageId":"A612847CFE53224C91B23E3A5B48BAC74483677DDC@xmail3.se.axis.com","threadId":"23866","inReplyTo":"20100524125637.GE3005@dpotapov.dyndns.org","subject":"RE: Use \"git pull --ff-only\" by default?","fromName":"Peter Kjellerstedt","fromEmail":"peter.kjellerstedt@axis.com","sentAt":"2010-05-25T08:43:22Z","receivedAt":"2010-05-25T08:43:22Z","isPatch":false,"sender":{"key":"peter.kjellerstedt@axis.com","avatar":"https://gravatar.com/avatar/6d5a0182283c8eccd7b134a54dbfd5f30038f3ad4d38b96f424884b614a61ca2?d=mp&s=160"},"body":"> -----Original Message-----\n> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On\n> Behalf Of Dmitry Potapov\n> Sent: den 24 maj 2010 14:57\n> To: Peter Kjellerstedt\n> Cc: Michael J Gruber; git@vger.kernel.org\n> Subject: Re: Use \"git pull --ff-only\" by default?\n> \n> On Mon, May 24, 2010 at 10:22:45AM +0200, Peter Kjellerstedt wrote:\n> >\n> > I forgot to mention that I had tried that. It does not work as git\n> > explicitly does not allow one to use a git command name as an alias\n> > name. And I think this is a good policy since it prevents people\n> > from aliasing plumbing commands to do weird things. However, I would\n> > like to see some way to affect the defaults of porcelain commands.\n> \n> Though, some porcelain commands (such as \"branch\") should never be used\n> in scripts, many others do not have low-level analogue, so they are\n> commonly used in scripts.\n\nWell, then I guess it would have to be either specific options for\nspecific commands, or more generic as any options for specific commands.\nThe problem then becomes selecting which options and which commands\nare allowed to take default values.\n\n> > > I think this boils down to having a few people who are allowed to\n> > > push merges because they can make these decisions. Even if people\n> > > don't merge \"origin\" but their own branches they can create a mess, \n> > > so you cannot differentiate based on that.\n> >\n> > In a larger organization this does not work. Most of our developers\n> > are responsible for at least one subsystem and expected to be the one\n> > responsible for its master branch.\n> \n> Right. Now, if only one person who is responsible for this subsystem is\n> expected to be able to push changes to the master branch then this\n> person will never need \"git pull --ff-only\". In fact, when he pulls\n\nWell, most of our subsystems have at least one backup maintainer \n(we cannot stop development just because the main maintainer is home\nsick, or on leave), so this is not necessarily true in our case.\n\n> changes from others, he needs a real merge. So, this alone a very\n> strong argument against making ff-only by default in any configuration.\n\nWell, we use a central repository with development made on official\ntopic branches, so he is not supposed to pull from others. He will \nfetch from the central repository and merge the topic branches. And\nI do not expect anyone to merge using git pull, but rather using an\nexplicit git merge. This is why I want to prevent accidental merges \nusing git pull by giving the --ff-only option. That way the user \nwould have to take an explicit action, and decide whether he should\ndo a git pull --rebase, put his local changes on a branch or resolve\nthe problem some other way (initially that would probably be by \nasking me what is going on and what to do, and that way learn how to\nhandle the situation). Silently creating an automatic merge that does \nnot have any meaning and will just confuse anyone looking at the \nrevision history later is not something that I want, especially as it\nwould make the job harder for the maintainer who is supposed to merge\nthe changes later and then has to untangle the mess.\n\n> And if you think that \"pull --ff-only\" is very useful for some reason,\n> nobody prevents to add an alias for that command, but this command\n> should never be called as \"pull\", because \"pull\" has always been about\n> merging changes, and if it does something different, you should call it\n> differently. Why don't call it as \"fast-forward\" or \"ff\" for short?\n\nI do not agree with you. When I do git pull it is to get all changes\nmade to the official repository. I do not want any local changes I have \nto be merged with the official changes, but rather I want my changes\nto stay separate, either by using git pull --rebase (if I have hacked\non the same branch for some reason), or by using a private topic branch\nthat I keep rebasing on master. And having --ff-only by default would \nsave me from mishaps in case I forget to give the --rebase option.\n\nAnd knowing that all our developers come from CVS, I expect it to take\nquite a while until they have learned to not just start hacking and\ndoing occasional git pulls, but rather create separate topic branches \nand rebasing. And in the meantime I want to protect our repositories\nfrom the automatic merges introduces by git pull without --ff-only \nand/or --rebase. \n\nI have also refrained from setting branch.autosetuprebase to remote \nsince I prefer the users to make an active choice as to how to resolve \nupdating their branches (and because of the note given for \nbranch.<name>.rebase marking it as possibly dangerous to use by default).\n\n> Dmitry\n\n//Peter\n"},{"id":"142460","messageId":"20100527180908.GA10398@dpotapov.dyndns.org","threadId":"23866","inReplyTo":"A612847CFE53224C91B23E3A5B48BAC74483677DDC@xmail3.se.axis.com","subject":"Re: Use \"git pull --ff-only\" by default?","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-05-27T18:09:08Z","receivedAt":"2010-05-27T18:09:08Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, May 25, 2010 at 10:43:22AM +0200, Peter Kjellerstedt wrote:\n> \n> > > > I think this boils down to having a few people who are allowed to\n> > > > push merges because they can make these decisions. Even if people\n> > > > don't merge \"origin\" but their own branches they can create a mess, \n> > > > so you cannot differentiate based on that.\n> > >\n> > > In a larger organization this does not work. Most of our developers\n> > > are responsible for at least one subsystem and expected to be the one\n> > > responsible for its master branch.\n> > \n> > Right. Now, if only one person who is responsible for this subsystem is\n> > expected to be able to push changes to the master branch then this\n> > person will never need \"git pull --ff-only\". In fact, when he pulls\n> \n> Well, most of our subsystems have at least one backup maintainer \n\nWhich is very reasonable, but I do not see how it contradicts to\nanything what I said above...\n\n> > changes from others, he needs a real merge. So, this alone a very\n> > strong argument against making ff-only by default in any configuration.\n> \n> Well, we use a central repository with development made on official\n> topic branches, so he is not supposed to pull from others.\n\nI am not sure what kind of workflow you are talking here, but in any\ncase, the maintainer can pull those official topic branches when he\nbelieves it is ready for integration...\n\n> He will \n> fetch from the central repository and merge the topic branches.\n\nof course, you can do that using two commands instead of one...\n\n> That way the user \n> would have to take an explicit action, and decide whether he should\n> do a git pull --rebase, put his local changes on a branch or resolve\n> the problem some other way (initially that would probably be by \n> asking me what is going on and what to do, and that way learn how to\n> handle the situation). Silently creating an automatic merge that does \n\nIt is as much automatic as those that are created by \"git merge\". If\nsomeone says \"git pull\", it means to do merge. In fact, before Git 1.5,\n\"git pull\" was the only porcelain command to do local merges (while\n\"git merge\" was a plumbing command with a different arguments than it\nhas now). So, if you are only interested in fetching new changes then\nyou should use \"git fetch\". Changing the default for \"git pull\" to\ndo --ff-only is akin changing \"git merge\" to do --ff-only...\n\n> not have any meaning and will just confuse anyone looking at the \n> revision history later is not something that I want, especially as it\n> would make the job harder for the maintainer who is supposed to merge\n> the changes later and then has to untangle the mess.\n\nFirst, when you make a presentation of Git and the workflow that you are\ngoing to use, you can explicitly say what commands should be and what\nshould not be normally used in this workflow. Second, when a maintainer\nsees a mess, he can just tell to this developer to rebase his changes\nand never use \"git pull\"... In fact, this is the least problem comparing\nto all other typical mistakes that inexperience developers do, such as,\nwriting meaningless comments to commits, failure to split changes in\nlogic steps, forget to test changes, etc...\n\n> \n> > And if you think that \"pull --ff-only\" is very useful for some reason,\n> > nobody prevents to add an alias for that command, but this command\n> > should never be called as \"pull\", because \"pull\" has always been about\n> > merging changes, and if it does something different, you should call it\n> > differently. Why don't call it as \"fast-forward\" or \"ff\" for short?\n> \n> I do not agree with you. When I do git pull it is to get all changes\n> made to the official repository. I do not want any local changes I have\n> to be merged with the official changes, but rather I want my changes\n> to stay separate, either by using git pull --rebase (if I have hacked\n> on the same branch for some reason), or by using a private topic branch\n> that I keep rebasing on master.\n\nIf you want to get changes then you should use \"git fetch\", and not \"git\npull\", because the latter is about getting and _merging_. Why are you\ntrying so hard to change a well established meaning of the pull command?\n\n\nDmitry\n"},{"id":"284893","messageId":"1461911930694-7654696.post@n2.nabble.com","threadId":"23866","inReplyTo":"A612847CFE53224C91B23E3A5B48BAC74483234E90@xmail3.se.axis.com","subject":"Re: Use \"git pull --ff-only\" by default?","fromName":"Monsignor","fromEmail":"3pzqma+9rz4ms8xqpvbw@sharklasers.com","sentAt":"2016-04-29T06:38:50Z","receivedAt":"2016-04-29T06:38:50Z","isPatch":false,"sender":{"key":"3pzqma+9rz4ms8xqpvbw@sharklasers.com","avatar":null},"body":"For people who still find this thread in Google, there is a way to do that\nnow:\n\n*git config --add pull.ff only*\n\n>From the documentation:\n\npull.ff\n    By default, Git does not create an extra merge commit when merging a\ncommit that is a descendant of the current commit. Instead, the tip of the\ncurrent branch is fast-forwarded. When set to false, this variable tells Git\nto create an extra merge commit in such a case (equivalent to giving the\n--no-ff option from the command line). When set to only, only such\nfast-forward merges are allowed (equivalent to giving the --ff-only option\nfrom the command line). This setting overrides merge.ff when pulling.\n\n\n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/Use-git-pull-ff-only-by-default-tp5084103p7654696.html\nSent from the git mailing list archive at Nabble.com.\n"}]}