{"thread":{"id":"25344","subject":"Useful tracking branches and auto merging","startedAt":"2010-10-04T20:44:24Z","lastAt":"2010-10-10T17:48:24Z","messageCount":13,"participants":["Felipe Contreras","Jonathan Nieder","Junio C Hamano","Clemens Buchacher"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"152589","messageId":"AANLkTimq0sKUavKiXepDOz+DvrymuRAVUyAyV+FzbCBD@mail.gmail.com","threadId":"25344","inReplyTo":null,"subject":"Useful tracking branches and auto merging","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2010-10-04T20:44:24Z","receivedAt":"2010-10-04T20:44:24Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nFor some time now I've stopped using 'git pull', and used 'git fetch',\nand now 'git remote update', however, this is still not ideal.\n\n Your branch is behind 'origin/master' by 17 commits, and can be fast-forwarded.\n\nThis message doesn't tell me _how_ I can 'fast-forward', I do 'git\nmerge origin/master' but if git already knows 'master' is tracking\n'origin/master' why should I specify that? Perhaps 'git merge\n--tracking'.\n\nBut, while we are on that, why not automatically merge the tracking\nbranches? Perhaps 'git remote update --auto-merge', configurable so I\ncan make auto-merge the default, and perhaps make it the default in\n1.8. Also, maybe some people would like them to be auto merged only\nwhen they can be fast-forwarded.\n\nI believe this would make remote tracking branches much more useful.\nWhat do you think?\n\nCheers\n\n-- \nFelipe Contreras\n"},{"id":"152590","messageId":"20101004204625.GH6466@burratino","threadId":"25344","inReplyTo":"AANLkTimq0sKUavKiXepDOz+DvrymuRAVUyAyV+FzbCBD@mail.gmail.com","subject":"Re: Useful tracking branches and auto merging","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-04T20:46:25Z","receivedAt":"2010-10-04T20:46:25Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Felipe Contreras wrote:\n\n> Your branch is behind 'origin/master' by 17 commits, and can be fast-forwarded.\n> \n> This message doesn't tell me _how_ I can 'fast-forward', I do 'git\n> merge origin/master' but if git already knows 'master' is tracking\n> 'origin/master' why should I specify that? Perhaps 'git merge\n> --tracking'.\n\ngit merge @{u}\n\n> But, while we are on that, why not automatically merge the tracking\n> branches?\n\nMaybe 'git pull --all' could be taught to eventually do this? That\nwould be incompatible with its current behavior of fetching everything\nand merging some random branch, but I don't think anyone is relying\non that.\n"},{"id":"152592","messageId":"AANLkTikkXdDepdeOY4MZvgfCEgX69Tx6d0-QS-g3bWK-@mail.gmail.com","threadId":"25344","inReplyTo":"20101004204625.GH6466@burratino","subject":"Re: Useful tracking branches and auto merging","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2010-10-04T20:56:02Z","receivedAt":"2010-10-04T20:56:02Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Oct 4, 2010 at 11:46 PM, Jonathan Nieder wrote:\n> Felipe Contreras wrote:\n>>  Your branch is behind 'origin/master' by 17 commits, and can be fast-forwarded.\n>>\n>> This message doesn't tell me _how_ I can 'fast-forward', I do 'git\n>> merge origin/master' but if git already knows 'master' is tracking\n>> 'origin/master' why should I specify that? Perhaps 'git merge\n>> --tracking'.\n>\n> git merge @{u}\n\nInteresting, I don't find anything like that in the documentation.\nMoreover, wouldn't it make sense to make 'git merge' = 'git merge\n@{u}'?\n\n>> But, while we are on that, why not automatically merge the tracking\n>> branches?\n>\n> Maybe 'git pull --all' could be taught to eventually do this?  That\n> would be incompatible with its current behavior of fetching everything\n> and merging some random branch, but I don't think anyone is relying\n> on that.\n\nMaybe, I feel 'git pull' is for single branches or repos, whereas 'git\nremote update' is pretty clear it's for all the repos, so if some\nmerging is to be done for all the repos, it should be some form of\n'git remote', no?\n\n-- \nFelipe Contreras\n"},{"id":"152594","messageId":"20101004205725.GJ6466@burratino","threadId":"25344","inReplyTo":"AANLkTikkXdDepdeOY4MZvgfCEgX69Tx6d0-QS-g3bWK-@mail.gmail.com","subject":"Re: Useful tracking branches and auto merging","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-10-04T20:57:25Z","receivedAt":"2010-10-04T20:57:25Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Felipe Contreras wrote:\n> On Mon, Oct 4, 2010 at 11:46 PM, Jonathan Nieder wrote:\n\n>> git merge @{u}\n>\n> Interesting, I don't find anything like that in the documentation.\n\nThe @{upstream} notation is documented in gitrevisions(7). But yes,\na more prominent mention (maybe some examples?) would be nice.\n\n> Moreover, wouldn't it make sense to make 'git merge' = 'git merge\n> @{u}'?\n\nI think so, yes. :)\n\n>> Maybe 'git pull --all' could be taught to eventually do this?  That\n>> would be incompatible with its current behavior of fetching everything\n>> and merging some random branch, but I don't think anyone is relying\n>> on that.\n>\n> Maybe, I feel 'git pull' is for single branches or repos, whereas 'git\n> remote update' is pretty clear it's for all the repos\n\nIf I remember correctly, the current status is:\n\n - 'git remote' is for adding, removing, and pruning remotes\n - 'git fetch ' and 'git fetch --all' are for updating them, and\n - 'git remote update' is for backward compatibility.\n"},{"id":"152596","messageId":"AANLkTi=nsv58ai1G6DhN935FY20U3AAjSC3OoitB-8st@mail.gmail.com","threadId":"25344","inReplyTo":"20101004205725.GJ6466@burratino","subject":"Re: Useful tracking branches and auto merging","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2010-10-04T21:06:17Z","receivedAt":"2010-10-04T21:06:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Oct 4, 2010 at 11:57 PM, Jonathan Nieder wrote:\n> Felipe Contreras wrote:\n>> On Mon, Oct 4, 2010 at 11:46 PM, Jonathan Nieder wrote:\n>>> git merge @{u}\n>>\n>> Interesting, I don't find anything like that in the documentation.\n>\n> The @{upstream} notation is documented in gitrevisions(7).  But yes,\n> a more prominent mention (maybe some examples?) would be nice.\n>\n>> Moreover, wouldn't it make sense to make 'git merge' = 'git merge\n>> @{u}'?\n>\n> I think so, yes. :)\n\nGreat :)\n\n> If I remember correctly, the current status is:\n>\n>  - 'git remote' is for adding, removing, and pruning remotes\n>  - 'git fetch ' and 'git fetch --all' are for updating them, and\n>  - 'git remote update' is for backward compatibility.\n\nOh, I thought 'git remote update' was newer. If 'git fetch --all' is\nsupposed to be used instead, then I guess 'git pull --all' makes\nsense, but personally I would like it to error out if the merge is not\nfast-forward.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"152690","messageId":"7vk4lw7g2m.fsf@alter.siamese.dyndns.org","threadId":"25344","inReplyTo":"20101004204625.GH6466@burratino","subject":"Re: Useful tracking branches and auto merging","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-10-05T16:35:45Z","receivedAt":"2010-10-05T16:35:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Maybe 'git pull --all' could be taught to eventually do this? That\n> would be incompatible with its current behavior of fetching everything\n> and merging some random branch, but I don't think anyone is relying\n> on that.\n\nI vaguely recall that we had discussions to disable \"git pull --all\",\nwhich most likely is a mistake?\n"},{"id":"152695","messageId":"AANLkTinXJ5E_U=5uP_zvWLQBssQsYC74JyVv1N3-eMXK@mail.gmail.com","threadId":"25344","inReplyTo":"7vk4lw7g2m.fsf@alter.siamese.dyndns.org","subject":"Re: Useful tracking branches and auto merging","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2010-10-05T17:49:25Z","receivedAt":"2010-10-05T17:49:25Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Oct 5, 2010 at 7:35 PM, Junio C Hamano wrote:\n> Jonathan Nieder writes:\n>\n>> Maybe 'git pull --all' could be taught to eventually do this?  That\n>> would be incompatible with its current behavior of fetching everything\n>> and merging some random branch, but I don't think anyone is relying\n>> on that.\n>\n> I vaguely recall that we had discussions to disable \"git pull --all\",\n> which most likely is a mistake?\n\nI believe this use-case is valid:\n\n * The user wants *all* his remote tracking branches to point to the\nlatest branch head in all the repos in the case the can be\nfast-forwarded, and in the case they can't, print an error and\ncontinue with the rest.\n\nRight now I would have to do 'git fetch --all' go to every remote\ntracking branch, and do 'git merge @{upstream}'.\n\nDo you have a better idea how to achieve that instead of 'git pull --all'?\n\n-- \nFelipe Contreras\n"},{"id":"152707","messageId":"7vvd5g5rjq.fsf@alter.siamese.dyndns.org","threadId":"25344","inReplyTo":"AANLkTinXJ5E_U=5uP_zvWLQBssQsYC74JyVv1N3-eMXK@mail.gmail.com","subject":"Re: Useful tracking branches and auto merging","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-10-05T20:10:49Z","receivedAt":"2010-10-05T20:10:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> I believe this use-case is valid:\n>\n> * The user wants *all* his remote tracking branches to point to the\n> latest branch head in all the repos in the case the can be\n> fast-forwarded, and in the case they can't, print an error and\n> continue with the rest.\n\nI would not be so sure about the validity of that use case.\n\nIf your tracking branches are always trailing, never having any real work\nof your own, there is no reason to have them locally, instead of checking\nthem out on demand. So let's forget about that case.\n\nWhen you are collaborating with somebody else, sharing a topic branch, and\nyou are behind because you were not working on it while the other parties\nprogressed the shared topic, it would be convenient if your local branch\nis fast-forwarded before you start to work on it. One possible solution\nfor that would be to teach \"git pull\" to fast-forward such backgrounded\ntracking branches that are not checked out. Another obvious alternative\nis to teach \"git checkout\" tell you where you are, and even tell you that\nyou could fast-forward [*1*].\n\nOn the other hand, if you have forked a topic branch to build your new\nnifty feature at some known point (e.g. immediately after the upstream\nreached a new stable point), but you haven't done any real work on it, it\nis doubtful that it is even a good idea to fast-forward it automatically\nto begin with. C.f.\n\n Message-ID: \n\n \"The real problem is that maintainers often pick random - and not at\n all stable - points for their development to begin with. They just\n pick some random \"this is where Linus -git tree is today\", and do\n their development on top of that. THAT is the problem - they are\n unaware that there's some nasty bug in that version.\"\n\nIOW, once I decided one point is a good place to fork a topic, created a\nbranch off of it, but didn't have a chance to do a real work on it yet, it\nwould be very irritating if \"git pull\" updated that branch only because I\ndo not have my own commit on it yet.\n\nI see little sanity in doing this with any option whose name has \"all\"; it\nlargely depends on the workflow, and in a single repository, some branches\nmay want to get fast-forwarded automatically while others don't [*2*].\n\n\n[Footnotes]\n\n*1* It is plausible that you could go one step further and define\nbranch.frotz.autofastforward configuration variable to tell \"git checkout\"\nto fast-forward in such a case, perhaps only when the working tree and the\nindex are clean.\n\n*2* It also is plausible that the same branch.frotz.autofastforward\nconfiguration variable can be noticed by \"git pull\".\n"},{"id":"152865","messageId":"AANLkTinqw06t88fkbyW3BbU-ZpWFAWBmjMQLPrTkXrci@mail.gmail.com","threadId":"25344","inReplyTo":"7vvd5g5rjq.fsf@alter.siamese.dyndns.org","subject":"Re: Useful tracking branches and auto merging","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2010-10-07T10:04:30Z","receivedAt":"2010-10-07T10:04:30Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Oct 5, 2010 at 11:10 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> I believe this use-case is valid:\n>>\n>> * The user wants *all* his remote tracking branches to point to the\n>> latest branch head in all the repos in the case the can be\n>> fast-forwarded, and in the case they can't, print an error and\n>> continue with the rest.\n>\n> I would not be so sure about the validity of that use case.\n>\n> If your tracking branches are always trailing, never having any real work\n> of your own, there is no reason to have them locally, instead of checking\n> them out on demand.  So let's forget about that case.\n\nDon't be so quick. Typing 'master' is certain easier than\n'origin/master', or 'stable' rather than 'linux-stable/master', or\n'vj-feature-1' rather than 'whatever-repo-this-came-from/feature-1'.\nThe fact that you don't do it doesn't mean it's not a valid use-case.\n\n> On the other hand, if you have forked a topic branch to build your new\n> nifty feature at some known point (e.g. immediately after the upstream\n> reached a new stable point), but you haven't done any real work on it, it\n> is doubtful that it is even a good idea to fast-forward it automatically\n> to begin with.  C.f.\n\nFortunately we have 'git checkout --no-track -b origin/foo'. Problem solved.\n\nBut rather, what I do is:\n% git branch -t origin/foo\n% git checkout -b nifty-feature foo\n\n>   Message-ID: \n>\n>   \"The real problem is that maintainers often pick random - and not at\n>    all stable - points for their development to begin with. They just\n>    pick some random \"this is where Linus -git tree is today\", and do\n>    their development on top of that. THAT is the problem - they are\n>    unaware that there's some nasty bug in that version.\"\n>\n> IOW, once I decided one point is a good place to fork a topic, created a\n> branch off of it, but didn't have a chance to do a real work on it yet, it\n> would be very irritating if \"git pull\" updated that branch only because I\n> do not have my own commit on it yet.\n\nThen either:\n1) fork of a local branch\n2) use --no-track\n3) don't do 'git pull --all'\n\n> I see little sanity in doing this with any option whose name has \"all\"; it\n> largely depends on the workflow, and in a single repository, some branches\n> may want to get fast-forwarded automatically while others don't [*2*].\n\nI think if you are issuing 'git pull --all' you want your remote\ntracking branches to fast forward if possible, if not, why are you\ndoing 'git pull --all'?\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"153148","messageId":"20101010171505.GA15495@localhost","threadId":"25344","inReplyTo":"AANLkTikkXdDepdeOY4MZvgfCEgX69Tx6d0-QS-g3bWK-@mail.gmail.com","subject":"Re: Useful tracking branches and auto merging","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2010-10-10T17:15:05Z","receivedAt":"2010-10-10T17:15:05Z","isPatch":false,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Mon, Oct 04, 2010 at 11:56:02PM +0300, Felipe Contreras wrote:\n>\n> Moreover, wouldn't it make sense to make 'git merge' = 'git merge\n> @{u}'?\n\nIsn't that what 'git pull' does? Especially after using 'git\nfetch'?\n\nI prefer 'git merge' as one of the few git commands without magic\nbehavior and DWIMery.\n\nClemens\n"},{"id":"153151","messageId":"AANLkTimFYExqr_OcYMJ0kTv5K-wtu3pzsAu=rhq+19W-@mail.gmail.com","threadId":"25344","inReplyTo":"20101010171505.GA15495@localhost","subject":"Re: Useful tracking branches and auto merging","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2010-10-10T17:30:22Z","receivedAt":"2010-10-10T17:30:22Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Oct 10, 2010 at 8:15 PM, Clemens Buchacher wrote:\n> On Mon, Oct 04, 2010 at 11:56:02PM +0300, Felipe Contreras wrote:\n>>\n>> Moreover, wouldn't it make sense to make 'git merge' = 'git merge\n>> @{u}'?\n>\n> Isn't that what 'git pull' does? Especially after using 'git\n> fetch'?\n\nNo, it hits the network again: git pull = git fetch + git merge @{u}\n\nIf I already did 'git fetch' why should I do it again?\n\n> I prefer 'git merge' as one of the few git commands without magic\n> behavior and DWIMery.\n\nThere's no magic involved, it's just what you would expect, what else\nshould 'git merge' (without arguments) do?\n\n-- \nFelipe Contreras\n"},{"id":"153152","messageId":"20101010174521.GC15495@localhost","threadId":"25344","inReplyTo":"AANLkTimFYExqr_OcYMJ0kTv5K-wtu3pzsAu=rhq+19W-@mail.gmail.com","subject":"Re: Useful tracking branches and auto merging","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2010-10-10T17:45:21Z","receivedAt":"2010-10-10T17:45:21Z","isPatch":false,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Sun, Oct 10, 2010 at 08:30:22PM +0300, Felipe Contreras wrote:\n> \n> There's no magic involved, it's just what you would expect, what else\n> should 'git merge' (without arguments) do?\n\nI would expect it to do nothing, or just output a usage. The\nproposed behavior is also unexpected because git-pull already does\n(almost) the same thing.\n\nClemens\n"},{"id":"153153","messageId":"AANLkTikfwHZVSyffEb5b77OAxcdmYsvy7e72=JngZ4x+@mail.gmail.com","threadId":"25344","inReplyTo":"20101010174521.GC15495@localhost","subject":"Re: Useful tracking branches and auto merging","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2010-10-10T17:48:24Z","receivedAt":"2010-10-10T17:48:24Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sun, Oct 10, 2010 at 8:45 PM, Clemens Buchacher wrote:\n> On Sun, Oct 10, 2010 at 08:30:22PM +0300, Felipe Contreras wrote:\n>>\n>> There's no magic involved, it's just what you would expect, what else\n>> should 'git merge' (without arguments) do?\n>\n> I would expect it to do nothing, or just output a usage.\n\nSo you are not going to type this command, how can such change in\nbehavior affect you?\n\n> The\n> proposed behavior is also unexpected because git-pull already does\n> (almost) the same thing.\n\nNot true. By your logic 'git fetch' should also do nothing because\n'git pull' does \"the same thing\".\n\n-- \nFelipe Contreras\n"}]}