{"thread":{"id":"1939","subject":"GIT 0.99.7d, and end of week status.","startedAt":"2005-09-25T08:36:25Z","lastAt":"2005-09-29T05:11:20Z","messageCount":23,"participants":["Junio C Hamano","Alan Chandler","Tom Prince","Petr Baudis","Jon Loeliger","Josef Weidendorfer","Matthias Urlichs"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"9255","messageId":"7vll1lr1bq.fsf@assigned-by-dhcp.cox.net","threadId":"1939","inReplyTo":null,"subject":"GIT 0.99.7d, and end of week status.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-25T08:36:25Z","receivedAt":"2005-09-25T08:36:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"* The fourth minor fix release, GIT 0.99.7d, is available at the\n  usual places.\n\n  RPMs and Debs are found in http://kernel.org/pub/software/scm/\n\n  With git:\n\n  $ git fetch http://kernel.org/pub/scm/git/git.git tag v0.99.7d\n  $ git checkout -b <new-branch> v0.99.7d\n\n  Fixes since 0.99.7c are:\n\n  - Fix show-branch output that named commits incorrectly.\n  - Fix git-grep -e not passing -e to underlying grep.\n\n* Recent updates to the master branch includes:\n\n  - The GIT_VERSION is now 0.99.7.GIT (thanks Pasky for the\n    idea).\n\n  - The symlinks for backward compatible names are not installed\n    anymore (but existing ones are not automatically removed).\n\n  - git-diff-* family acquired a new option, --name-status, to\n    show the status and name for changed files.  Also -l<num>\n    option disables rename/copy detection when the number of\n    rename target candidates are more than <num> (idea by Linus\n    some time ago).\n\n* Proposed updates, not yet graduated to the master branch\n  includes:\n\n  - git-merge fix, not to require a clean tree.\n\n  - Likewise for git-revert and git-cherry-pick fix, not to\n    require a clean tree.\n\n  - Use git-merge from git-pull, again.\n\n  - A couple of test fixes for further Solaris portability.\n\n  - update-index takes -z --stdin to read NUL terminated list of\n    paths from the standard input instead of from the command\n    line.  This is to help platforms with xargs that cannot grok\n    -0.  git-commit is updated to use this.\n"},{"id":"9256","messageId":"200509251032.22662.alan@chandlerfamily.org.uk","threadId":"1939","inReplyTo":"7vll1lr1bq.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2005-09-25T09:32:22Z","receivedAt":"2005-09-25T09:32:22Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Sunday 25 Sep 2005 09:36, Junio C Hamano wrote:\n> * The fourth minor fix release, GIT 0.99.7d, is available at the\n>   usual places.\n\nI can't find it.  Is this a propogation timing issue?\n\nI tried both ip addresses quoted as being kernel.org\n\n\n\n\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\n"},{"id":"9266","messageId":"7vaci1nfwa.fsf@assigned-by-dhcp.cox.net","threadId":"1939","inReplyTo":"7vll1lr1bq.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-25T18:47:33Z","receivedAt":"2005-09-25T18:47:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I said:\n\n> * The fourth minor fix release, GIT 0.99.7d, is available at the\n>   usual places.\n>\n>   With git:\n>\n>   $ git fetch http://kernel.org/pub/scm/git/git.git tag v0.99.7d\n>   $ git checkout -b <new-branch> v0.99.7d\n\nIf you pick a suitable name as <new-branch> that the repository\nin which you keep track git.git does not yet have, \"maint997\" for\nexample, and if your working tree is identical to whatever your\nHEAD happens to be, then the above instruction should be read as:\n\n    $ git fetch http://kernel.org/pub/scm/git/git.git tag v0.99.7d\n    $ git checkout -b maint997 v0.99.7d\n\nand that would give you the exact contents of v0.99.7d in your\nworking tree.\n\nBut this was really a stupid way to give instructions, and would\nprobably have caused confusion.  Sorry about that, if you were\none of the people who were bitten.\n\nI deliberately did not say:\n\n    $ git pull http://kernel.org/pub/scm/git/git.git tag v0.99.7d\n\nbecause the result would be affected by whatever the random\nstate the repository was in.\n\nFolks using CVS seem to announce \"A new release is available and\ntagged as r0.99.7d\", people seem to know what they need to do\nwhen seeing that announcement (\"cvs update -r r0.99.7d\"), and\nthis command line, as long as the working tree tracks that\nremote project CVS repository, would give more-or-less the same\nresult for everyone no matter what the original state of the\nworking tree was.  GIT is a bit different in that branch names\nare local and you do not really \"check out a tag\".\n\nOne straightforward way which would work for everybody would be\n(provided you do not have git-src in the current directory):\n\n   $ git clone http://kernel.org/pub/scm/git/git.git git-src\n   $ cd git-src\n   $ git reset --hard v0.99.7d\n\nThis will give all the public branches and tags (renaming of\npublic \"master\" to \"origin\" is done by \"git clone\"), and match\nyour \"master\" to \"v0.99.7d\".\n\nWhen you already have a repository to track git.git, I would\nrecommend to have something like this in .git/remote/origin:\n\n    URL: http://kernel.org/pub/scm/git/git.git\n    Pull: master:origin maint:maint +pu:pu\n\nThen you can say:\n\n    $ git fetch origin tag v0.99.7d\n\nThis only updates your .git/refs/tags/v0.99.7d and downloads\nnecessary objects.  To see them in your working tree (e.g. for\ncompilation), you would need to check it out.\n\nNow, how would you check out the v0.99.7d tag?  There are two\nways to think about it.\n\nIf the reason you want v0.99.7d, not \"master\" nor \"pu\", is you\nwould want to stay with the 0.99.7 but get all the latest safer\nfixes, then you can just checkout \"maint\" branch instead, like\nthis:\n\n    $ git checkout -f maint\n\nThis will get you everything in the maintenance branch and may\ncontain fixes that happened after v0.99.7d -- you are taking my\n0.99.7d announce as just a hint to say: \"Junio has accumulated\nenough maintenance fixes in the maint branch and tagged its tip\".\n\nAnd the announcement is just that.  I try to make sure that what\nare in the maint branch are just \"safer fixes that do not break\nexisting setup\", but I do not do any more special testing than\nwhat I already do to make commits into the maint branch when I\ntag the tip of it.  In other words, the one that happens to be\ntagged as 0.99.7d is not any safer than the next commit that\ncomes on the maint branch (there is none at this moment).  The\nlater tip of the maint branch had better be more correct than\nv0.99.7d -- that is what \"fix\" usually means ;-).\n\nOn the other hand, if the reason you want v0.99.7d is to point\nout things broke at that exact commit, you would need to check\nout that exact version, not just a random commit that happens to\nbe at the tip of maint.  And you need a branch to check it out\nonto in that case.  Assuming that you do not have a branch\ncalled \"throwaway\":\n\n    $ git checkout -f -b throwaway v0.99.7d\n\nwould give you the working tree that matches what is in v0.99.7d\nand a new branch \"throwaway\" whose tip is the commit tagged as\nv0.99.7d.  The usual caveat applies: if your working tree and\nindex had changes since the HEAD commit you had before you did\nthe above checkout, that change may be lost with '-f' flag.  But\nthe point of this checkout is to get what is in the named tag\nexactly, you would want to lose them -- otherwise make a commit\nto your branch, or stash away 'git diff HEAD' output, before\ndoing the checkout.\n\nAfter that, if you want to see what v0.99.7c used to do, you\ncould (still remaining on the \"throwaway\" branch):\n\n    $ git reset --hard v0.99.7c\n\n[jc: maybe somebody can send a patch to add the later part of\nthis message as Documentation/howto/checking-out-a-tag.txt ].\n"},{"id":"9278","messageId":"200509252143.23905.alan@chandlerfamily.org.uk","threadId":"1939","inReplyTo":"7vaci1nfwa.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2005-09-25T20:43:23Z","receivedAt":"2005-09-25T20:43:23Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Sunday 25 Sep 2005 19:47, Junio C Hamano wrote:\n...\n>\n> One straightforward way which would work for everybody would be\n> (provided you do not have git-src in the current directory):\n>\n>    $ git clone http://kernel.org/pub/scm/git/git.git git-src\n>    $ cd git-src\n\nI did the above just after your announcement but before the tags etc had got \nthere (see my earlier question in this thread).\n\n\n>    $ git reset --hard v0.99.7d\n\nDidn't do this\n...\n> Then you can say:\n>\n>     $ git fetch origin tag v0.99.7d\n Did this\n...\n> Now, how would you check out the v0.99.7d tag?  There are two\n> ways to think about it.\n>\n> If the reason you want v0.99.7d, not \"master\" nor \"pu\", is you\n> would want to stay with the 0.99.7 but get all the latest safer\n> fixes, then you can just checkout \"maint\" branch instead, like\n> this:\n>\n>     $ git checkout -f maint\n>\n\nI am rather new to all this, but this last step puzzles me.\n\nBefore this step, and using gitk --all, I can see the maintenance branch, but \nits currently connected to the point where the v0.99.7c tag is and not where \nyour latest tag is.\n\nSo if I followed these instructions, now, wouldn't I just get the v0.997c tag?\n\nDoes that mean I have missed some step along the way to get the maint branch \nposition moved to the new tag?\n\n\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\n"},{"id":"9285","messageId":"87psqwzs3x.fsf@ualberta.net","threadId":"1939","inReplyTo":"7vaci1nfwa.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Tom Prince","fromEmail":"tom.prince@ualberta.net","sentAt":"2005-09-25T22:42:58Z","receivedAt":"2005-09-25T22:42:58Z","isPatch":false,"sender":{"key":"tom.prince@ualberta.net","avatar":"https://gravatar.com/avatar/a0ad19caee7618876339485106ec994f5202505eecd210ba5c0bd869feaa555a?d=mp&s=160"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n>\n> When you already have a repository to track git.git, I would\n> recommend to have something like this in .git/remote/origin:\n>\n>     URL: http://kernel.org/pub/scm/git/git.git\n>     Pull: master:origin maint:maint +pu:pu\n>\n\nA warning when you do this. If you say \n\n  git pull origin\n\nthen your master will be updated with an octopus merge of the three heads.\n\n  Tom\n"},{"id":"9287","messageId":"7v7jd4n22i.fsf@assigned-by-dhcp.cox.net","threadId":"1939","inReplyTo":"87psqwzs3x.fsf@ualberta.net","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-25T23:46:13Z","receivedAt":"2005-09-25T23:46:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tom Prince <tom.prince@ualberta.net> writes:\n\n>> When you already have a repository to track git.git, I would\n>> recommend to have something like this in .git/remote/origin:\n>>\n>>     URL: http://kernel.org/pub/scm/git/git.git\n>>     Pull: master:origin maint:maint +pu:pu\n>>\n>\n> A warning when you do this. If you say \n>\n>   git pull origin\n>\n> then your master will be updated with an octopus merge of the three heads.\n\nAhhhhhhhh.  That is true.  I always do \"git fetch\" and never do\n\"git pull\" against anything but a local repository, heads\nexplicitly specified.  You are right.  The defaulting behaviour\nis incredibly broken.\n\nDo people agree it is a good idea to change the \"git pull\norigin\" to mean \"fetch all the default refs specified on Pull:\nlines, and merge only the first one into the current branch\"?\n\n\"git pull\" without remote nor refspecs is a synonym to \"git pull\norigin\" as before, and 99.99% of the time \"git pull\" from a\nremote repo without explicit refspec is doing just one head\nmerge, so I think this is a sane default, much saner than the\ncurrent mess, while still allowing you to keep track of what's\nhappening in the other branches by doing fetches of all the\nheads at once.\n\nOpinions?\n"},{"id":"9288","messageId":"7v1x3cn1cj.fsf@assigned-by-dhcp.cox.net","threadId":"1939","inReplyTo":"200509252143.23905.alan@chandlerfamily.org.uk","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-26T00:01:48Z","receivedAt":"2005-09-26T00:01:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alan Chandler <alan@chandlerfamily.org.uk> writes:\n\n> Does that mean I have missed some step along the way to get the maint branch \n> position moved to the new tag?\n\nTo recap, you did:\n\n    (before 0.99.7d propagated to the mirrors)\n    $ git clone http://kernel.org/pub/scm/git/git.git git-src\n    $ cd git-src\n\n    (after 0.99.7d propagated to the mirrors)\n    $ git fetch origin tag v0.99.7d\n    $ git checkout -f maint\n\nThe 'fetch origin tag v0.99.7d' step should have left\nthe new file .git/refs/tags/v0.99.7d _after_ downloading all the\nobjects necessary to reconstruct the history to get there.  \n\nAh, you are right.  My instruction did not update other branches\nfor you.  My bad.\n\nAssuming people stay on their \"master\" branch, and have the\nrecommended .git/remotes/origin contents in my previous message,\nthen the steps \"after 0.99.7d propagated to the mirrors\" would\njust be:\n\n    $ git fetch\n\nwhich would fetch all the branches mentioned in the remotes\nfile, and then:\n\n    $ git checkout -f maint\n\nwhich would switch your working tree to maint branch.\n\nNOTE NOTE NOTE.  The above assumes you are on your \"master\"\nbranch when you run 'git fetch' --- if you are on any of the\nbranches that is being updated (you can check which branch you\nare on with 'git branch' without argument, or just with 'ls -l\n.git/HEAD') 'git fetch' will complain because doing so without\nupdating them to match the updated branch head would make your\nindex file and working tree inconsistent with your .git/HEAD,\nbut 'git fetch' is supposed to be only fetching without touching\nthe working tree.\n"},{"id":"9296","messageId":"200509260709.12937.alan@chandlerfamily.org.uk","threadId":"1939","inReplyTo":"7v1x3cn1cj.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2005-09-26T06:09:12Z","receivedAt":"2005-09-26T06:09:12Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Monday 26 Sep 2005 01:01, Junio C Hamano wrote:\n> Alan Chandler <alan@chandlerfamily.org.uk> writes:\n> > Does that mean I have missed some step along the way to get the maint\n> > branch position moved to the new tag?\n>\n> To recap, you did:\n>\n>     (before 0.99.7d propagated to the mirrors)\n>     $ git clone http://kernel.org/pub/scm/git/git.git git-src\n>     $ cd git-src\n>\n>     (after 0.99.7d propagated to the mirrors)\n>     $ git fetch origin tag v0.99.7d\n>     $ git checkout -f maint\n\nActually, I got as far as doing the fetch, but I didn't checkout anything.  I \njust ran gitk --all \n\nI would have been on the branch that the git clone would have left me on \n(presumably master)\n\n>\n> The 'fetch origin tag v0.99.7d' step should have left\n> the new file .git/refs/tags/v0.99.7d _after_ downloading all the\n> objects necessary to reconstruct the history to get there.\n>\n\nYes - I gitk showed had all the objects - but v0.99.7d was a a tag at the tip \nof an unamed branch\n\n> Ah, you are right.  My instruction did not update other branches\n> for you.  My bad.\n>\n> Assuming people stay on their \"master\" branch, and have the\n> recommended .git/remotes/origin contents in my previous message,\n> then the steps \"after 0.99.7d propagated to the mirrors\" would\n> just be:\n>\n>     $ git fetch\n\nIts not the \"other\" branches that I was concerned about, it was the \"maint\" \nbranch reference which seemed to still be still at the same commit as the \nv0.99.7c tag, at least that was what gitk --all showed me, after the fetch. \n\n\n>\n> which would fetch all the branches mentioned in the remotes\n> file, and then:\n>\n>     $ git checkout -f maint\n\nThis is where I get puzzled.  Fetch on its own didn't move where \"maint\" \npointed to so doing this checkout would have left me at the v0.99.7c tag (I \ndidn't actually do it - as I was then puzzling over the documentation trying \nto see what I did wrong)\n\nI realise I could have just manually moved it - but none of the steps in your \ninstructions seemed to move it for me.\n\nIn the end - I blew my git away and repeated the clone exercise after the \nmirrors had updated - in this version the \"maint\" branch was co-incident with \nthe v0.99.7d tag\n\n>\n> which would switch your working tree to maint branch.\n>\n> NOTE NOTE NOTE.  The above assumes you are on your \"master\"\n> branch when you run 'git fetch' --- if you are on any of the\n> branches that is being updated (you can check which branch you\n> are on with 'git branch' without argument, or just with 'ls -l\n> .git/HEAD') 'git fetch' will complain because doing so without\n> updating them to match the updated branch head would make your\n> index file and working tree inconsistent with your .git/HEAD,\n> but 'git fetch' is supposed to be only fetching without touching\n> the working tree.\n\n\n\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\n"},{"id":"9315","messageId":"20050926191037.GD26340@pasky.or.cz","threadId":"1939","inReplyTo":"7v7jd4n22i.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-26T19:10:37Z","receivedAt":"2005-09-26T19:10:37Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Sep 26, 2005 at 01:46:13AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Tom Prince <tom.prince@ualberta.net> writes:\n> \n> >> When you already have a repository to track git.git, I would\n> >> recommend to have something like this in .git/remote/origin:\n> >>\n> >>     URL: http://kernel.org/pub/scm/git/git.git\n> >>     Pull: master:origin maint:maint +pu:pu\n> >>\n> >\n> > A warning when you do this. If you say \n> >\n> >   git pull origin\n> >\n> > then your master will be updated with an octopus merge of the three heads.\n> \n> Ahhhhhhhh.  That is true.  I always do \"git fetch\" and never do\n> \"git pull\" against anything but a local repository, heads\n> explicitly specified.  You are right.  The defaulting behaviour\n> is incredibly broken.\n> \n> Do people agree it is a good idea to change the \"git pull\n> origin\" to mean \"fetch all the default refs specified on Pull:\n> lines, and merge only the first one into the current branch\"?\n\nI don't like that, the notion that you are fetching different stuff that\nyou are merging then seems quite confusing to me. But fetching just the\nfirst revision will be confusing too. Either way, git-pull won't be\nequivalent to git-fetch && git-merge (or git-resolve or whatever is the\ncore porcelain command) anymore. Well, the remotes stuff never got close\nto my heart.\n\nOne alternative I can think of is, in case there are multiple heads,\nrequire the user to explicitly specify the head he wants (origin#maint).\nThis comes from the idea that multi-head remotes are there really\nprimarily for fetching, not for pulling. There is also no potential for\nconfusion. In addition, there might another line \"Default\" in the remote\nfile, which could specify the default choice. It's just that choosing\nthe first one implicitly makes me a bit nervous and has potential for\nbad mistakes. At least for Cogito, I would be reluctant to use it.\n\ngit-pull --merge-all or something to still do the octopus merge might be\nuseful in some cases (or as well might not - perhaps the best strategy\nis to let whoever cares make a patch ;).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9319","messageId":"1127765852.5735.36.camel@cashmere.sps.mot.com","threadId":"1939","inReplyTo":"7v7jd4n22i.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2005-09-26T20:17:32Z","receivedAt":"2005-09-26T20:17:32Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Sun, 2005-09-25 at 18:46, Junio C Hamano wrote:\n> Tom Prince <tom.prince@ualberta.net> writes:\n> \n> >> When you already have a repository to track git.git, I would\n> >> recommend to have something like this in .git/remote/origin:\n> >>\n> >>     URL: http://kernel.org/pub/scm/git/git.git\n> >>     Pull: master:origin maint:maint +pu:pu\n> >>\n> >\n> > A warning when you do this. If you say \n> >\n> >   git pull origin\n> >\n> > then your master will be updated with an octopus merge of the three heads.\n> \n> Ahhhhhhhh.  That is true.  I always do \"git fetch\" and never do\n> \"git pull\" against anything but a local repository, heads\n> explicitly specified.  You are right.  The defaulting behaviour\n> is incredibly broken.\n> \n> Do people agree it is a good idea to change the \"git pull\n> origin\" to mean \"fetch all the default refs specified on Pull:\n> lines, and merge only the first one into the current branch\"?\n> \n> \"git pull\" without remote nor refspecs is a synonym to \"git pull\n> origin\" as before, and 99.99% of the time \"git pull\" from a\n> remote repo without explicit refspec is doing just one head\n> merge, so I think this is a sane default, much saner than the\n> current mess, while still allowing you to keep track of what's\n> happening in the other branches by doing fetches of all the\n> heads at once.\n> \n> Opinions?\n\nHmmm...  Would it make sense to introduce something\nlike this instead:\n\n    # When fetching, get bits from here:\n    URL: http://...../git.git\n    # When fetching, grab and map like this:\n    Fetch: master:origin maint:maint +pu:pu\n    # When merging, merge origin, maint and pu into master\n    Merge: master origin maint pu\n\nWith the intent that the \"Fetch:\" line effectively\nlimits the fetching operation to git-fetch, and doesn't\nspecify how to merge.  Then, the \"Merge:\" line specifies\nhow to do the git-merge bits.  If you didn't want to\nmerge in the maint and pu bits, this would have been\nthe line instead:\n\n    # Merge into master the just the origin bits\n    Merge: master origin\n\nIf you want the dual-step fetch+merge, the leave the \"Pull:\"\nline as originally written:\n\n    # Fetch and merge\n    Pull: master:origin maint:maint +pu:pu\n\nSyntax can be argued, of course.  My point being to\nintroduce another line to the remote file that\ndistinguishes the default behavior for each step\nalong the way.\n\nThanks,\njdl\n"},{"id":"9322","messageId":"7vwtl3h936.fsf@assigned-by-dhcp.cox.net","threadId":"1939","inReplyTo":"200509260709.12937.alan@chandlerfamily.org.uk","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-26T20:23:25Z","receivedAt":"2005-09-26T20:23:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alan Chandler <alan@chandlerfamily.org.uk> writes:\n\n> This is where I get puzzled.  Fetch on its own didn't move where \"maint\" \n> pointed to so doing this checkout would have left me at the v0.99.7c tag (I \n> didn't actually do it - as I was then puzzling over the documentation trying \n> to see what I did wrong)\n\nBecause \"git fetch origin tag v0.99.7d\" fetched only that tag --\ngit-fetch command is not told to fetch anything else.  Most\nimportantly, it did not tell it to update \"maint\" branch head\nfrom the remote.  That was why I said that instrucition was\nbusted.\n"},{"id":"9323","messageId":"7vll1jh8zr.fsf@assigned-by-dhcp.cox.net","threadId":"1939","inReplyTo":"20050926191037.GD26340@pasky.or.cz","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-26T20:25:28Z","receivedAt":"2005-09-26T20:25:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> ... Either way, git-pull won't be equivalent to git-fetch &&\n> git-merge (or git-resolve or whatever is the core porcelain\n> command) anymore.\n\n\"pull = fetch + merge\" is a reasonable approximation to use when\nyou explain what they are to somebody, but taking it literally\nwould harm usefulness.\n\nIt is what you have already lived with for a while.  \"git pull\n.../linux/2.6.git v2.6.11-tree v2.6.12\" would fetch both heads\nbut merges v2.6.12 head only (because v2.6.11-tree is not\nsomething you can merge with).\n\nThe typical use cases are:\n\n - The remote does not have more than one head (majority of the\n   kernel.org repositories are single head repositories).  You\n   could say \"Pull: master:somebody\" in .git/remotes/somebody\n   and say \"git pull somebody\" and pull is fetch + merge.  The\n   proposed fix does not affect this case.\n\n - The remote has more than one heads, and they are usually both\n   interesting.  Some kernel.org repositories have release and\n   test heads and people who are interested in what is happening\n   in that subsystem are likely to want to inspect both, so\n   fetching both makes a lot of sense (especially given\n   multi-head fetch over git-native protocol is more efficieint\n   than fetching them separately), but obviously merging both\n   into an Octopus does not make any sense most of the time.\n\n   You could say \"Pull: release:a/release test:a/test\" in\n   .git/remotes/subsys and \"git fetch subsys\" would fetch both\n   and store them locally.  \"git pull subsys\" would fetch both\n   but merges only subs/release, which is far more useful than\n   attempting to make an Octopus with both heads.  You could\n   still say \"git pull subsys test\" to only fetch and merge\n   test, if you needed to do something different from what the\n   \"merge only the first one by default\" rule gives.\n\n - The remote has 47 different heads, and they are more or less\n   independent developments in the same area (\"topic branches\").\n   Jeff's libata-dev repository may be a good example.  \"Pull:\n   ALL:libata-dev/ALL ncq:libata-dev/ncq\n   chs-support:libata-dev/chs-support ...\"  would be what one\n   would place in .git/remotes/libata-dev.  This list can be a\n   subset of the heads that exist at remote but only the heads\n   one is interested in.  \"git fetch libata-dev\" would get all\n   the heads in that repository one is interested in, \"git pull\n   libata-dev\" would merge in ALL (which is premerged at the\n   remote side) thanks to the \"merge only first one by default\"\n   rule.  If you want to make Octopus with selected heads (not\n   the one Jeff made in ALL), you still can say \"git pull\n   libata-dev ncq chs-support\" to do so.\n"},{"id":"9335","messageId":"7vr7bba3lo.fsf@assigned-by-dhcp.cox.net","threadId":"1939","inReplyTo":"1127765852.5735.36.camel@cashmere.sps.mot.com","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-26T22:03:47Z","receivedAt":"2005-09-26T22:03:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@freescale.com> writes:\n\nThere is a small problem in that proposal.  \"Merging\" in git\ndoes not work that way.  Specifically,\n\n>     # When merging, merge origin, maint and pu into master\n>     Merge: master origin maint pu\n>     # Merge into master the just the origin bits\n>     Merge: master origin\n\nthe problem with these is that you may be in your \"test\" branch\nand say \"git pull\".  'git pull' does not let you say 'pull into\nthis branch which is not my current branch', and \"into master\"\npart would not work -- merge in git always merges things into\nthe current branch, so writing\n\n>     # When merging, merge origin, maint and pu into the current\n>     Merge: origin maint pu\n>     # Merge just the origin bits into the current\n>     Merge: origin\n\nmay make sense.\n\nHaving said that I doubt Octopus is what people do regularly, so\nbeing able to write \"Merge: origin maint pu\" (or \"Merge: ncq\nchs-support\") as a short-hand makes much sense.\n\nThere is not much inherent reason to require that the merge\nhappens only to the current branch, if we stop using the files\nin the working tree for resolving conflicts (either manually or\nautomatically).  We could rewrite 'git pull' like this:\n\n - have it take 'merge into this branch' parameter, defaulting\n   to the current branch, or your \"Merge: <into> <remote>...\"\n   proposal.\n\n - if the merge is not to happen in the current branch, then\n   use a temporary index file and a temporary working directory\n   to do the merge -- when manual conflict resolution is needed,\n   ask the user to go to that temporary working directory and\n   resolve conflicts there and make commits there.  The\n   temporary working directory is actually cheap because we do\n   not have to checkout all the paths -- only the paths involved\n   in the merge.\n\nI remember the merge Linus originally envisioned would have\nworked along the above lines, until he changed his mind around\n2a68a8659f7dc55fd285d235ae2d19e7a8116c30 commit, beginning of\nJune, for 1.0 (ewww, we were already aiming for 1.0 back then).\n\n\thttp://marc.theaimsgroup.com/?l=git&m=111806925225305&w=2\n\ndeclared the merge in separate directory is post 1.0 item, and I\ntend to agree with that.  Most of the time you will be merging\ninto the current branch, and otherwise you could make it so by\nswitching to that branch before pulling.\n"},{"id":"9371","messageId":"7vu0g72c4y.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1939","inReplyTo":"7vr7bba3lo.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Fix default pull not to do an unintended Octopus.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-27T07:38:53Z","receivedAt":"2005-09-27T07:38:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This is what I ended up doing Sunday night before the discussion\nstarted, and what I still have in the proposed updates branch.\n\nIt implements the 'when puling using a shorthand without\nexplicitly telling which refs to pull, only use the first ref\nfound from Pull: lines for merging -- creating Octopus using all\ndefault refs is not useful 99.99% of the time' behaviour I\noutlined yesterday.\n\nI think it could be modified without too much pain to take\n\"which heads to use for merge by default\" information from\nseparate \"Merge: \" line as Jon proposed, if enough people like\nthat idea better.  Personally I do not think it would make much\npractical difference from the end users' point of view, but I've\nbeen proven wrong more often than not in the past, so...\n\nAs Pasky said in another thread, git-fetch is not the most\nelegantly written script on earth, and it is not my favorite\nscript either -- it needs to do complex things, like interacting\nwith the later git-pull stage.\n\n------------\nThe refspecs specified in the .git/remotes/<remote> on the \"Pull: \"\nlines are for fetching multiple heads in one go, but most of the time\nmaking an Octopus out of them is not what is wanted.  Make git-fetch\nleave the marker in .git/FETCH_HEAD file so that later stages can\ntell which heads are for merging and which are not.\n\nTom Prince made me realize how stupid the original behaviour was.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n git-fetch.sh           |   32 ++++++++++++++++++++++++++++----\n git-fmt-merge-msg.perl |    4 +++-\n git-parse-remote.sh    |   11 +++++++++--\n git-pull.sh            |    4 +++-\n 4 files changed, 43 insertions(+), 8 deletions(-)\n\n44dbc712fe3dd045550123e1cc689c41482c62e5\ndiff --git a/git-fetch.sh b/git-fetch.sh\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -54,6 +54,10 @@ append_fetch_head () {\n     remote_name_=\"$3\"\n     remote_nick_=\"$4\"\n     local_name_=\"$5\"\n+    case \"$6\" in\n+    t) not_for_merge_='not-for-merge' ;;\n+    '') not_for_merge_= ;;\n+    esac\n \n     # remote-nick is the URL given on the command line (or a shorthand)\n     # remote-name is the $GIT_DIR relative refs/ path we computed\n@@ -78,10 +82,11 @@ append_fetch_head () {\n     if git-cat-file commit \"$head_\" >/dev/null 2>&1\n     then\n \theadc_=$(git-rev-parse --verify \"$head_^0\") || exit\n-\techo \"$headc_\t$note_\" >>$GIT_DIR/FETCH_HEAD\n+\techo \"$headc_\t$not_for_merge_\t$note_\" >>$GIT_DIR/FETCH_HEAD\n \techo >&2 \"* committish: $head_\"\n \techo >&2 \"  $note_\"\n     else\n+\techo \"$head_\tnot-for-merge\t$note_\" >>$GIT_DIR/FETCH_HEAD\n \techo >&2 \"* non-commit: $head_\"\n \techo >&2 \"  $note_\"\n     fi\n@@ -157,6 +162,13 @@ do\n \n     # These are relative path from $GIT_DIR, typically starting at refs/\n     # but may be HEAD\n+    if expr \"$ref\" : '\\.' >/dev/null\n+    then\n+\tnot_for_merge=t\n+\tref=$(expr \"$ref\" : '\\.\\(.*\\)')\n+    else\n+\tnot_for_merge=\n+    fi\n     if expr \"$ref\" : '\\+' >/dev/null\n     then\n \tsingle_force=t\n@@ -216,7 +228,8 @@ do\n \tcontinue ;;\n     esac\n \n-    append_fetch_head \"$head\" \"$remote\" \"$remote_name\" \"$remote_nick\" \"$local_name\"\n+    append_fetch_head \"$head\" \"$remote\" \\\n+    \t\"$remote_name\" \"$remote_nick\" \"$local_name\" \"$not_for_merge\"\n \n done\n \n@@ -241,16 +254,27 @@ http://* | https://* | rsync://* )\n \t    case \"$ref\" in\n \t    +$remote_name:*)\n \t\tsingle_force=t\n+\t\tnot_for_merge=\n+\t\tfound=\"$ref\"\n+\t\tbreak ;;\n+\t    .+$remote_name:*)\n+\t\tsingle_force=t\n+\t\tnot_for_merge=t\n+\t\tfound=\"$ref\"\n+\t\tbreak ;;\n+\t    .$remote_name:*)\n+\t        not_for_merge=t\n \t\tfound=\"$ref\"\n \t\tbreak ;;\n \t    $remote_name:*)\n+\t    \tnot_for_merge=\n \t\tfound=\"$ref\"\n \t\tbreak ;;\n \t    esac\n \tdone\n-\n \tlocal_name=$(expr \"$found\" : '[^:]*:\\(.*\\)')\n-\tappend_fetch_head \"$sha1\" \"$remote\" \"$remote_name\" \"$remote_nick\" \"$local_name\"\n+\tappend_fetch_head \"$sha1\" \"$remote\" \\\n+\t\t\"$remote_name\" \"$remote_nick\" \"$local_name\" \"$not_for_merge\"\n     done || exit\n     ;;\n esac\ndiff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl\n--- a/git-fmt-merge-msg.perl\n+++ b/git-fmt-merge-msg.perl\n@@ -31,6 +31,8 @@ while (<>) {\n \tmy ($bname, $tname, $gname, $src);\n \tchomp;\n \ts/^[0-9a-f]*\t//;\n+\tnext if (/^not-for-merge/);\n+\ts/^\t//;\n \tif (s/ of (.*)$//) {\n \t\t$src = $1;\n \t} else {\n@@ -86,7 +88,7 @@ for my $src (@src) {\n \t\t\t    $src{$src}{GENERIC});\n \tmy $this = join(', ', @this);\n \tif ($src ne '.') {\n-\t\t$this .= \" from $src\";\n+\t\t$this .= \" of $src\";\n \t}\n \tpush @msg, $this;\n }\ndiff --git a/git-parse-remote.sh b/git-parse-remote.sh\n--- a/git-parse-remote.sh\n+++ b/git-parse-remote.sh\n@@ -65,8 +65,11 @@ get_remote_default_refs_for_push () {\n \tesac\n }\n \n-# Subroutine to canonicalize remote:local notation\n+# Subroutine to canonicalize remote:local notation.\n canon_refs_list_for_fetch () {\n+\t# Leave only the first one alone; add prefix . to the rest\n+\t# to prevent the secondary branches to be merged by default.\n+\tdot_prefix=\n \tfor ref\n \tdo\n \t\tforce=\n@@ -91,7 +94,8 @@ canon_refs_list_for_fetch () {\n \t\theads/* | tags/* ) local=\"refs/$local\" ;;\n \t\t*) local=\"refs/heads/$local\" ;;\n \t\tesac\n-\t\techo \"${force}${remote}:${local}\"\n+\t\techo \"${dot_prefix}${force}${remote}:${local}\"\n+\t\tdot_prefix=.\n \tdone\n }\n \n@@ -107,6 +111,9 @@ get_remote_default_refs_for_fetch () {\n \t\techo \"refs/heads/${remote_branch}:refs/heads/$1\"\n \t\t;;\n \tremotes)\n+\t\t# This prefixes the second and later default refspecs\n+\t\t# with a '.', to signal git-fetch to mark them\n+\t\t# not-for-merge.\n \t\tcanon_refs_list_for_fetch $(sed -ne '/^Pull: */{\n \t\t\t\t\t\ts///p\n \t\t\t\t\t}' \"$GIT_DIR/remotes/$1\")\ndiff --git a/git-pull.sh b/git-pull.sh\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -24,7 +24,9 @@ then\n \t\tdie \"You need to first update your working tree.\"\n fi\n \n-merge_head=$(sed -e 's/\t.*//' \"$GIT_DIR\"/FETCH_HEAD | tr '\\012' ' ')\n+merge_head=$(sed -e '/\tnot-for-merge\t/d' \\\n+\t-e 's/\t.*//' \"$GIT_DIR\"/FETCH_HEAD | \\\n+\ttr '\\012' ' ')\n \n case \"$merge_head\" in\n '')\n"},{"id":"9377","messageId":"20050927095142.GB30889@pasky.or.cz","threadId":"1939","inReplyTo":"1127765852.5735.36.camel@cashmere.sps.mot.com","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-27T09:51:42Z","receivedAt":"2005-09-27T09:51:42Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Sep 26, 2005 at 10:17:32PM CEST, I got a letter\nwhere Jon Loeliger <jdl@freescale.com> told me that...\n> Hmmm...  Would it make sense to introduce something\n> like this instead:\n> \n>     # When fetching, get bits from here:\n>     URL: http://...../git.git\n>     # When fetching, grab and map like this:\n>     Fetch: master:origin maint:maint +pu:pu\n>     # When merging, merge origin, maint and pu into master\n>     Merge: master origin maint pu\n> \n> With the intent that the \"Fetch:\" line effectively\n> limits the fetching operation to git-fetch, and doesn't\n> specify how to merge.  Then, the \"Merge:\" line specifies\n> how to do the git-merge bits.  If you didn't want to\n> merge in the maint and pu bits, this would have been\n> the line instead:\n> \n>     # Merge into master the just the origin bits\n>     Merge: master origin\n> \n> If you want the dual-step fetch+merge, the leave the \"Pull:\"\n> line as originally written:\n> \n>     # Fetch and merge\n>     Pull: master:origin maint:maint +pu:pu\n> \n> Syntax can be argued, of course.  My point being to\n> introduce another line to the remote file that\n> distinguishes the default behavior for each step\n> along the way.\n\nYes, this is basically the idea behind my \"Default\" line, but arguably\nnicer and more flexible. I fully agree with Junio that pulling should\nmerge to your current branch, but I like your idea otherwise.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9378","messageId":"200509271152.42963.Josef.Weidendorfer@gmx.de","threadId":"1939","inReplyTo":"7vu0g72c4y.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Fix default pull not to do an unintended Octopus.","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-09-27T09:52:42Z","receivedAt":"2005-09-27T09:52:42Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 27 September 2005 09:38, Junio C Hamano wrote:\n> I think it could be modified without too much pain to take\n> \"which heads to use for merge by default\" information from\n> separate \"Merge: \" line as Jon proposed, if enough people like\n> that idea better.  Personally I do not think it would make much\n> practical difference from the end users' point of view, but I've\n> been proven wrong more often than not in the past, so...\n\nHmm...\nWhat is the \"intuitive\" thing a user would expect when looking at\na remotes file? It looks like including lists of default heads which\nare used for git commands when no further head is specified, i.e.\nwhich are automatically appended to the command line.\n\nE.g. with .git/remotes/remoterep looking like\n\n\tURL: ...\n\tPull: local1:remote1 local2:remote2\n\tPush: local3:remote3 local4:remote4\n\na\n\tgit push remoterep\n\nexpands to (AFAIK)\n\n\tgit push remoterep local3:remote3 local4:remote4\n\nSo for\n\tgit pull remoterep\n\nthe expected command seems to be\n\n\tgit pull local1:remote1 local2:remote2\n\nand of course this does an octopus merge at the end.\nIt may be a strange thing to do, but if the user does *not* want to do\noctopus merges, he probably only will give one default head in the Pull\nline of the remotes file.\n\nSo I would not change the current behavior.\n\nIt seems better to me to support an additional \"Fetch:\" line.\nIMHO, a \"Merge:\" lines does not make sense, as \"git merge\" has\nnothing to do with remote repositories at all [I just looked up\nthe man page of git-merge, and confusingly it talks about \"remotes\",\nwhich are in fact local heads to be merged].\n\n> As Pasky said in another thread, git-fetch is not the most\n> elegantly written script on earth, and it is not my favorite\n> script either -- it needs to do complex things, like interacting\n> with the later git-pull stage.\n\nLike Pasky, I am not really comfortable with this remotes stuff.\nAFAIK, it was introduced to shorten some command line by providing defaults\n(to be used by the \"GIT core porcelain\"). But I still have to provide the \nremote shortcut on the command line.\n\nAs Cogito does, I expect the porcelain to store the mapping of a\nlocal head to a remote head, automatically using the right remote\nrepository.\n\nI want to type \"git fetch maint\" to get the maintanance branch of\ngit, and not specify an additionally introduced arbitrary short name\nfor the remote git repo (which is used quite less often than my\nhead names: heads appear in gitk, I switch among heads...).\nAnd using the same name for a remote shortcut and a local head can\nconfuse people.\n\nSo IMHO default actions should be stored for branches, not for shortcuts\nof remote positions. The branches stuff matches this better, as one\nfile in branches/ corresponds exactly to one head with the same name,\nand specifies the attributes \"remote repository\" and \"remote head\".\n\nThis also shortens command lines much better then the remotes stuff,\nas you implicity specify a default head: The one you are on.\n\nPerhaps we should have extended the branches file to allow different\nremote reps and heads depending on the command (fetch/pull/merge/push).\nA \"URL:\" is not needed, as you probably like to have different repos for pull \nand push. And in contrast to the remotes stuff above, a \"Merge:\" line makes \nquite sense here: When on \"mybranch\", a merge should default to merging\nthe heads specified on the Merge line in branches/mybranch.\n\nWhen cloning a remote head, Cogito creates a local \"origin\" head and\ncorresponding mapping in branches/origin. Afterwards, it automatically\ngenerates a new local branch \"master\", which branches of at the\norigin. Further \"cg-updates\" (=git fetch+merge) fetch origin, and merge\norigin into master.\nI assume that this currently is hardcoded in scripts?\nShouldn't there be created a branches/master, specifying that a default\nmerge should happen with \"origin\"? This way, an \"cg-update\" would look\ninto \"branches/master\" on the \"Merge:\" line. It sees that \"origin\" is\nbound to a remote head, and thus, does a fetch before merging.\n\nOpinions?\n\nJosef\n"},{"id":"9380","messageId":"20050927101306.GC30889@pasky.or.cz","threadId":"1939","inReplyTo":"7vr7bba3lo.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-27T10:13:06Z","receivedAt":"2005-09-27T10:13:06Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 27, 2005 at 12:03:47AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n>  - if the merge is not to happen in the current branch, then\n>    use a temporary index file and a temporary working directory\n>    to do the merge -- when manual conflict resolution is needed,\n>    ask the user to go to that temporary working directory and\n>    resolve conflicts there and make commits there.  The\n>    temporary working directory is actually cheap because we do\n>    not have to checkout all the paths -- only the paths involved\n>    in the merge.\n\nBy the way, this is how Cogito did merging for some (rather short) time\nperiod (actually, there's perhaps still some remnant of this, I think\nCogito still by default ignores ,,merge* which was the subdirectory\nwhere the merge happenned). I removed it because IIRC the people weren't\neventually all that excited about it after all and Linus changed his\nmind too.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9382","messageId":"20050927101744.GD30889@pasky.or.cz","threadId":"1939","inReplyTo":"7vll1jh8zr.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-27T10:17:44Z","receivedAt":"2005-09-27T10:17:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Sep 26, 2005 at 10:25:28PM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Petr Baudis <pasky@suse.cz> writes:\n> \n> > ... Either way, git-pull won't be equivalent to git-fetch &&\n> > git-merge (or git-resolve or whatever is the core porcelain\n> > command) anymore.\n> \n> \"pull = fetch + merge\" is a reasonable approximation to use when\n> you explain what they are to somebody, but taking it literally\n> would harm usefulness.\n> \n> It is what you have already lived with for a while.  \"git pull\n> .../linux/2.6.git v2.6.11-tree v2.6.12\" would fetch both heads\n> but merges v2.6.12 head only (because v2.6.11-tree is not\n> something you can merge with).\n\nYes, but that's a rather obscure case. :-) But well, your use cases\nconvinced me that the behaviour to fetch multiple heads even if you are\ngoing to merge just one of them is useful enough. However, I still think\nthat the user should be required to specify the to-be-merged head\nmanually if the default choice isn't explicitly written in the remotes\nfile.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9387","messageId":"20050927125434.GF30889@pasky.or.cz","threadId":"1939","inReplyTo":"200509271152.42963.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] Fix default pull not to do an unintended Octopus.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-27T12:54:34Z","receivedAt":"2005-09-27T12:54:34Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 27, 2005 at 11:52:42AM CEST, I got a letter\nwhere Josef Weidendorfer <Josef.Weidendorfer@gmx.de> told me that...\n> As Cogito does, I expect the porcelain to store the mapping of a\n> local head to a remote head, automatically using the right remote\n> repository.\n\nYes. I'm actually inclined to keep this setup, simply because it is\n\n  * easy\n  * simple\n  * sufficient in most of the cases\n\nCogito's fetch/update should certainly support the remotes stuff, since\nthey are obviously much more useful and practical for more complicated\nsetup, but I think I will keep the branches/ setup (the name of the\ndirectory is the only thing I don't like on it ;) as the primary mean of\nconfiguring remote branches.  I will only have to add possibility to\ncg-fetch multiple branches at once, which could also make branches/\nsignificantly more practical.\n\n> Perhaps we should have extended the branches file to allow different\n> remote reps and heads depending on the command (fetch/pull/merge/push).\n> A \"URL:\" is not needed, as you probably like to have different repos for pull \n> and push. And in contrast to the remotes stuff above, a \"Merge:\" line makes \n> quite sense here: When on \"mybranch\", a merge should default to merging\n> the heads specified on the Merge line in branches/mybranch.\n\nNo. If you are in the branches/ playground, please keep it strictly\none-to-one mapping. That's what makes it easy and simple and that's what\nmakes it good.\n\n> When cloning a remote head, Cogito creates a local \"origin\" head and\n> corresponding mapping in branches/origin. Afterwards, it automatically\n> generates a new local branch \"master\", which branches of at the\n> origin. Further \"cg-updates\" (=git fetch+merge) fetch origin, and merge\n> origin into master.\n> I assume that this currently is hardcoded in scripts?\n\nYes.\n\n> Shouldn't there be created a branches/master, specifying that a default\n> merge should happen with \"origin\"? This way, an \"cg-update\" would look\n> into \"branches/master\" on the \"Merge:\" line. It sees that \"origin\" is\n> bound to a remote head, and thus, does a fetch before merging.\n\nIf ever doing that, this should be done at some other place than\nbranches/. And I'm sceptical about it anyway. Really, introducing some\nnew configuration mechanism just to tell Cogito what default branch name\nshould it pick up when you call fetch/update/merge without a parameter?\nI don't know if that wouldn't make more evil than good.\n\nWell, if you _really_ _really_ badly want it, we can make\n.git/default-origin/ or something... duh, what a stupid name. :)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"9389","messageId":"200509271635.12907.Josef.Weidendorfer@gmx.de","threadId":"1939","inReplyTo":"20050927125434.GF30889@pasky.or.cz","subject":"Re: [PATCH] Fix default pull not to do an unintended Octopus.","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-09-27T14:35:12Z","receivedAt":"2005-09-27T14:35:12Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Tuesday 27 September 2005 14:54, you wrote:\n> Yes. I'm actually inclined to keep this setup, simply because it is\n>\n>   * easy\n>   * simple\n>   * sufficient in most of the cases\n\nI would almost say: sufficient for all cases.\nThe .git/remotes stuff is about providing a shortcut for remote\nrepositories and about defaults for this repository.\nI am not really sure this is needed, and this second use of a name\n(additionally to head names) can be confusing.\n\n> > Perhaps we should have extended the branches file to allow different\n> > remote reps and heads depending on the command (fetch/pull/merge/push).\n> > A \"URL:\" is not needed, as you probably like to have different repos for\n> > pull and push. And in contrast to the remotes stuff above, a \"Merge:\"\n> > line makes quite sense here: When on \"mybranch\", a merge should default\n> > to merging the heads specified on the Merge line in branches/mybranch.\n>\n> No. If you are in the branches/ playground, please keep it strictly\n> one-to-one mapping. That's what makes it easy and simple and that's what\n> makes it good.\n\nAh, no. Any line in a branches/ file is a pure attribute for the given\nhead, and does not change its 1:1 relationship.\n\nE.g. a branches/master file with\n\n\tPush: git:/.../git.git#public-master\n\tMerge: origin\n\nwould specify:\n- If the current head is master, a cg-merge will merge with\nhead origin\n- If the current head is master, a cg-push will publish the\nlocal master to the given remote URL\n\nThe branches/master does nothing say about the origin branch/head.\n\n> > When cloning a remote head, Cogito creates a local \"origin\" head and\n> > corresponding mapping in branches/origin. Afterwards, it automatically\n> > generates a new local branch \"master\", which branches of at the\n> > origin. Further \"cg-updates\" (=git fetch+merge) fetch origin, and merge\n> > origin into master.\n> > I assume that this currently is hardcoded in scripts?\n>\n> Yes.\n>\n> > Shouldn't there be created a branches/master, specifying that a default\n> > merge should happen with \"origin\"? This way, an \"cg-update\" would look\n> > into \"branches/master\" on the \"Merge:\" line. It sees that \"origin\" is\n> > bound to a remote head, and thus, does a fetch before merging.\n>\n> If ever doing that, this should be done at some other place than\n> branches/.\n\nHmm, perhaps. We could go with .git/push-defaults and .git/merge-defaults.\nBut then, IMHO .git/branches should be renamed to .git/fetch-defaults,\nas it holds the remote URL needed for fetching changes.\n\nBy creating the needed defaults on a cg-clone, you can get rid of the\nabove mentioned hardcoded things.\n\n> And I'm sceptical about it anyway. Really, introducing some \n> new configuration mechanism just to tell Cogito what default branch name\n> should it pick up when you call fetch/update/merge without a parameter?\n\nIt is about storing pull/push remote URLs for a given head.\nOk, in the case \"merge\", it is about defaults (useful to\nget rid of the hardcoding of merging origin into master on a cg-update).\n\nI really think that the \"push\" URL currently is missing in Cogito.\nPushing the master by using the origin URL works, but I would like to\nsee this working for arbitrary heads.\n\nBy the way, am I correct than cogito currently misses a command to\nswitch the branch? cg-seek is only for temporal switching. What are\nthe prefered options? A \"cg-seek -f\", a \"cg-jump\" or \"cg-switch\"?\n\nJosef\n"},{"id":"9411","messageId":"7vachyywrp.fsf@assigned-by-dhcp.cox.net","threadId":"1939","inReplyTo":"200509271635.12907.Josef.Weidendorfer@gmx.de","subject":"Re: [PATCH] Fix default pull not to do an unintended Octopus.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-27T22:24:26Z","receivedAt":"2005-09-27T22:24:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:\n\n> On Tuesday 27 September 2005 14:54, you wrote:\n>> Yes. I'm actually inclined to keep this setup, simply because it is\n>>\n>>   * easy\n>>   * simple\n>>   * sufficient in most of the cases\n>\n> I would almost say: sufficient for all cases.\n> The .git/remotes stuff is about providing a shortcut for remote\n> repositories and about defaults for this repository.\n> I am not really sure this is needed, and this second use of a name\n> (additionally to head names) can be confusing.\n\nI suspect you've never played with remote repositories with 47\ndifferent heads.\n"},{"id":"9452","messageId":"pan.2005.09.29.04.40.14.655977@smurf.noris.de","threadId":"1939","inReplyTo":"20050927101744.GD30889@pasky.or.cz","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-09-29T04:40:14Z","receivedAt":"2005-09-29T04:40:14Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Petr Baudis wrote:\n\n> However, I still think\n> that the user should be required to specify the to-be-merged head manually\n> if the default choice isn't explicitly written in the remotes file.\n\nI tend to agree -- intentional octopus merges are rare enough.\nFor most people, anyway. ;-)\n\n-- \nMatthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nIt is not a good omen when goldfish commit suicide.\n"},{"id":"9456","messageId":"7vk6h0o3uv.fsf@assigned-by-dhcp.cox.net","threadId":"1939","inReplyTo":"pan.2005.09.29.04.40.14.655977@smurf.noris.de","subject":"Re: GIT 0.99.7d, and end of week status.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-29T05:11:20Z","receivedAt":"2005-09-29T05:11:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Urlichs <smurf@smurf.noris.de> writes:\n\n> I tend to agree -- intentional octopus merges are rare enough.\n> For most people, anyway. ;-)\n\nI agree, *and* I think what I proposed is consistent with that.\nEssentially, you cannot create an Octopus without asking from\nthe command line, period.\n"}]}