{"thread":{"id":"2339","subject":"Trying to Update All Heads of a Repository","startedAt":"2005-11-04T00:23:59Z","lastAt":"2005-11-06T09:23:53Z","messageCount":6,"participants":["Jon Loeliger","Linus Torvalds","Junio C Hamano","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"11102","messageId":"E1EXpN9-00034x-7g@jdl.com","threadId":"2339","inReplyTo":null,"subject":"Trying to Update All Heads of a Repository","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2005-11-04T00:23:59Z","receivedAt":"2005-11-04T00:23:59Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"\nGuys and Gals,\n\n*sigh*\n\nThis is the sort of thing that mystifies me still.\nI think there is (should be?) an easy command and\nI just missed that day in class.  Feel free to\nsmack me with the obvious as needed...\n\nI re-cloned (rsync) by git.git tree yesteday.\nToday is a new day, and I want to start with\na fresh update of the entire git.git tree.\nI have not changed anything in my copy yet.\nMy goal is a simple update of the entire repository.\n\n    % git --version\n    git version 0.99.9.GIT\n\nUh, foo.  That's a version from 02-Nov-2005.  I guess I could\ndig out a SHA1 and we'd know exactly what version it is.\n\n(Request:  Does it make sense to have a hard SHA1 as\n           part of git's output version string?)\n\nFirst, I have this, because it came with a git-clone:\n\n    % cat .git/remotes/origin\n    URL: rsync://rsync.kernel.org/pub/scm/git/git.git\n    Pull: master:origin\n\nI don't know how to say \"Grab all the updates for\nall the heads for which I have heads in my .git/refs\".\n\nSo I hope \"git pull --help\" will tell me:\n\n    % git pull --help\n    usage: git-fetch-pack [-q] [-v] [--exec=upload-pack] [host:]directory <refs>...\n    Fetch failure: --help\n\nThat would be no.  So I hit the man page, and I can't\nquite decipher it.  I'm dense, so I have to re-read it\na few more times until I fully grok it.  Dinner interferes.\n\nLike could I have just said?:\n\n    % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git\nor\n    % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git master:origin\n    % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git pu:pu\n    % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git todo:todo\n\nDunno yet.\n\n\nIn the meantime, I figure I can effectively achieve my\ngoal by:\n\n    for each head $h\n        git checkout -f $h\n        git pull rsync://rsync.kernel.org/pub/scm/git/git.git $h:$h\n\nSo I start with master.  I know I can cheat here and rely\non the \"Pull: master:origin\":\n\n    % git pull origin\n    receiving file list ... done\n\n    sent 102 bytes  received 12339 bytes  8294.00 bytes/sec\n    total size is 4708148  speedup is 378.44\n    * committish: a3114b3428595710d4719dd668531210af5993c9\n      branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git\n    * refs/heads/origin: same as branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git\n    Already up-to-date.\n\nThat worked fine:\n\n    % git show-branch | head -15\n    ! [maint] GIT 0.99.9b\n     * [master] Document --since and --until options to rev-parse.\n      ! [origin] Document --since and --until options to rev-parse.\n       ! [pu] Merge branch 'master'\n\t! [todo] GIT 0.99.9\n    -----\n\t+ [todo] GIT 0.99.9\n\t+ [todo^] 2005-10-26 (prepare for 0.99.9)\n\t+ [todo~2] Update 2005-10-19 afternoon.\n\t+ [todo~3] 2005-10-18 midnight\n\t+ [todo~4] 2005-10-16 early afternoon.\n\t+ [todo~5] 2005-10-16 midnight.\n\t+ [todo~6] Updates 2005-10-14 night\n\t+ [todo~7] Updates 2005-10-12 night.\n\nOn to the pu branch:\n\n    % git checkout -f pu\n    % git show-branch | head -10\n    ! [maint] GIT 0.99.9b\n     ! [master] Document --since and --until options to rev-parse.\n      ! [origin] Document --since and --until options to rev-parse.\n       * [pu] Merge branch 'master'\n\t! [todo] GIT 0.99.9\n    -----\n\t+ [todo] GIT 0.99.9\n\t+ [todo^] 2005-10-26 (prepare for 0.99.9)\n\t+ [todo~2] Update 2005-10-19 afternoon.\n\t+ [todo~3] 2005-10-18 midnight\n\nAnd pull it now:\n\n    % git pull rsync://rsync.kernel.org/pub/scm/git/git.git pu:pu\n\n    receiving file list ... done\n\n    sent 102 bytes  received 12325 bytes  8284.67 bytes/sec\n    total size is 4708148  speedup is 378.86\n    * committish: 6c86914344ea64e3a7b287721bdeaa7d41f8a1c3\n      branch 'pu' of rsync://rsync.kernel.org/pub/scm/git/git\n    * refs/heads/pu: does not fast forward to branch 'pu' of rsync://rsync.kernel.org/pub/scm/git/git;\n      not updating.\n    Trying really trivial in-index merge...\n    fatal: Merge requires file-level merging\n    Nope.\n    Trying simple merge.\n    Simple merge failed, trying Automatic merge.\n    Auto-merging Makefile.\n    ERROR: git-merge-ours.sh: Not handling case  -> a64704f3e52be43b427792ef9c1bbe42af057c87 -> 4f3d053889de4a5ba8e6e5d519c014a51220accd\n    fatal: merge program failed\n    Automatic merge failed; fix up by hand\n\nRats.  But why did this fail?  I've changed nothing in my tree.\nI'm pulling remote pu into local pu directly.  I think this\nshould Just Work...\n\nUh, now what?\n\n    % git status\n\n    # On branch refs/heads/pu\n    #\n    # Updated but not checked in:\n    #   (will commit)\n    #\n    #       new file: Documentation/git-http-push.txt\n    #       modified: Documentation/git-rev-parse.txt\n    #       modified: Makefile\n    #       modified: commit.c\n    #       modified: config.c\n    #       modified: fetch-pack.c\n    #       modified: git-branch.sh\n    #       modified: git-checkout.sh\n    #       unmerged: git-merge-ours.sh\n    #       modified: git-push.sh\n    #       new file: git-shallow-pack.sh\n    #       modified: git-svnimport.perl\n    #       new file: http-push.c\n    #       modified: ls-files.c\n    #       modified: name-rev.c\n    #       modified: send-pack.c\n    #       modified: server-info.c\n    #       modified: sha1_name.c\n    #       modified: t/t3001-ls-files-others-exclude.sh\n    #       modified: tag.c\n    #       modified: tag.h\n    #       modified: upload-pack.c\n    #\n    #\n    # Changed but not updated:\n    #   (use git-update-index to mark for commit)\n    #\n    #       unmerged: git-merge-ours.sh\n    #\n    #\n    # Untracked files:\n    #   (use \"git add\" to add to commit)\n    #\n    #       git-merge-ours.sh\n\n    % git diff\n    * Unmerged path git-merge-ours.sh\n\n    % cat .git/HEAD\n    0e6a92bd0b33b3461fb7b7f7eb34647ad93d451d\n\n    % cat .git/FETCH_HEAD\n    6c86914344ea64e3a7b287721bdeaa7d41f8a1c3                branch 'pu' of rsync://rsync.kernel.org/pub/scm/git/git\n\nSo.  Yes, I know I can \"git-add git-merge-ours.sh\" and then\ndo a \"git-update-index git-merge-ours.sh\" and get a spiffy\nnew index.  And then I can \"git-commit\" it all, and that\nshould be everything.\n\nBut I really thought that this should Just Work?\nShouldn't this be a fast forward, nice-n-clean-n-easy?\n\nDo I need to add .git/remote entries for each head?\nCan I place multiple \"Pull: pu:pu\" type refspecs into\nthe one .git/remote/origin?  Is that what people do?\nEven if that I do that, I still have to manually iterate:\n\n    for each head $h\n        git checkout -f $h\n        git pull origin $h\n\nMore tequilla.\n\nThanks,\njdl\n"},{"id":"11105","messageId":"Pine.LNX.4.64.0511031655350.27915@g5.osdl.org","threadId":"2339","inReplyTo":"E1EXpN9-00034x-7g@jdl.com","subject":"Re: Trying to Update All Heads of a Repository","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-04T01:04:09Z","receivedAt":"2005-11-04T01:04:09Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 3 Nov 2005, Jon Loeliger wrote:\n> \n> I don't know how to say \"Grab all the updates for\n> all the heads for which I have heads in my .git/refs\".\n\nWell, you can't per se - there's no guarantee that the heads on the other \nside match, and in fact usually they won't (at the very minimum, the \nremote \"master\" tends to be the local \"origin\", although if you never do \nany development at _all_, you can make even that match).\n\nI sent out a patch some time ago that added \"--all\" and \"--tags\", but only \nthe \"--tags\" part was accepted. Arguably for good reasons.\n\nBut \"git fetch\" will take a list of heads. So you can do\n\n\tgit fetch repo master:origin pu todo\n\nand it will update the three local heads (origin, pu and todo) from the \nremote heads master, pu and todo respectively).\n\nIF you have a 100% match between heads names locally and remotely, you \ncould also do something like\n\n\tgit fetch repo $(cd .git/refs ; echo heads/*)\n\nwhich is pretty cheesy, but should work ;)\n\nAs to your experiences with \"git pull\" - it should work fine too, but you \nreally do need to make sure that the branch you are in always matches the \nbranch you're pulling. Otherwise you'll be doing a merge between two \ndifferent branches - which is a valid operation, but not what you're \ntrying to achieve here.\n\nAs we saw earlier, the way to undo an unsuccessful \"git pull\" is to do a \n\"git reset --hard\". Undoing a _successful_ git pull is actually slightly \nharder in the general case (it's really undoing a series of commit), but \nif you do it right after the pull, you can do\n\n\tgit reset --hard ORIG_HEAD\n\nbecause \"git pull\" will save the original head before pulling.\n\n\t\t\tLinus\n"},{"id":"11108","messageId":"7vy8453zhu.fsf@assigned-by-dhcp.cox.net","threadId":"2339","inReplyTo":"E1EXpN9-00034x-7g@jdl.com","subject":"Re: Trying to Update All Heads of a Repository","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-04T02:42:21Z","receivedAt":"2005-11-04T02:42:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@freescale.com> writes:\n\n> First, I have this, because it came with a git-clone:\n>\n>     % cat .git/remotes/origin\n>     URL: rsync://rsync.kernel.org/pub/scm/git/git.git\n>     Pull: master:origin\n>\n> I don't know how to say \"Grab all the updates for\n> all the heads for which I have heads in my .git/refs\".\n\nMy \"guinea pig\" repository has this in $GIT_DIR/remotes/origin:\n\n        URL: git://git.kernel.org/pub/scm/git/git.git\n        Pull: master:origin\n        Pull: +pu:pu\n        Pull: maint:maint\n\nThis means that my \"master\" is copied to the \"origin\" branch of\nthe guinea pig repository and \"pu\" and \"maint\" are copies of my\n\"pu\" and \"maint\" branches.  You never do your own development on\nbranches that appear on the right hand side of colon on \"Pull\"\nlines (i.e. origin, pu and maint) in this repository.  They are\nto be updated by git-fetch.\n\nAnd the regular workflow over there is:\n\n\t$ cd over-there\n        $ git checkout master\n        $ git pull\n        ... build, test, install\n\n> So I hope \"git pull --help\" will tell me:\n\nYou're right.  We need to add --help to that command.\n\n> Like could I have just said?:\n>\n>     % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git\n> or\n>     % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git master:origin\n>     % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git pu:pu\n>     % git fetch rsync://rsync.kernel.org/pub/scm/git/git.git todo:todo\n\nYou could.  Alternatively, with your original remotes/origin\nfile, you should be able to do:\n\n\t$ git checkout master\n\t$ git fetch origin master:origin +pu:pu maint:maint\n        $ git pull . origin\n\n> On to the pu branch:\n>\n> Rats.  But why did this fail?  I've changed nothing in my tree.\n> I'm pulling remote pu into local pu directly.  I think this\n> should Just Work...\n\nMy \"pu\" is somewhat special; it is rewound and rebased all the\ntime, so merging with its older self would conflict with it.\nThat's why my example remotes/origin file has '+' in front of\nit.  It tells git-fetch that the other side _might_ rebase and\nfetch would not result in a fast-forward merge when that happens.\n\nI should advertise that fact more often, for people who came\nhere after I did the last such advertisement.\n\n> But I really thought that this should Just Work?\n> Shouldn't this be a fast forward, nice-n-clean-n-easy?\n\nSorry, my \"pu\" does not fast forward.  The branch is to showcase\nwhat I've received or picked up from the list, and what changes\nare under consideration for inclusion.\n\nThe \"pu\" head is built by pulling a handful topic branches on\ntop of the \"master\" branch.  My private repository right now\nlooks like this:\n\n    ! [hold/draw] Illustration: \"Commit DAG Revision Naming\"\n     ! [hold/http] [PATCH 2/2] Add support for git-http-push to git-pu...\n      ! [hold/svn] Several fixes to import mono's svn tree\n       ! [jcmu] git-tag: Do not assume the working tree root is writab...\n        ! [maint] GIT 0.99.9c\n         * [master] Illustration: \"Commit DAG Revision Naming\"\n          ! [pu] Merge branch 'toys'\n           ! [toys] git-shallow-pack\n    --------\n          +  [pu] Merge branch 'toys'\n          ++ [toys] git-shallow-pack\n          +  [pu^] Merge branches 'hold/svn' and 'hold/http'\n     +    +  [hold/http] [PATCH 2/2] Add support for git-http-push to ...\n     +    +  [hold/http^] [PATCH 1/2] Add support for pushing to a rem...\n      +   +  [hold/svn] Several fixes to import mono's svn tree\n       +  +  [jcmu] git-tag: Do not assume the working tree root is wr...\n        +    [maint] GIT 0.99.9c\n    +  ++++  [hold/draw] Illustration: \"Commit DAG Revision Naming\"\n    +  ++++  [hold/draw^] Illustration: \"Git Diff Types\"\n    +  ++++  [hold/draw~2] Illustration: \"Fundamental Git Index Operat...\n    +  ++++  [hold/draw~3] git-merge-ours: make sure our index matches...\n    +  ++++  [hold/draw~4] Add 'ours' merge strategy.\n    +  ++++  [hold/draw~5] Add --no-commit to git-merge/git-pull.\n    +  ++++  [hold/draw~6] Document --since and --until options to rev...\n    ++++++++ [hold/draw~7] Be careful when dereferencing tags.\n\nThe \"hold/draw\" topic branch (thanks for your ASCII art) is\nfully merged into my \"master\"; in fact it's head is the master\nbranch head.  Nick's http-push and Yaacov's svnimport fixes are\nkept in separate topic branches, which originated at the\nprevious \"master\" (now master~7 == hold/draw~7), and they have\nnot been rebased, partly I am lazy and partly there are no\nchanges that would cause merge conflicts with other branches.\n\nOn the other hand, the commit structure of my public repository\nright now looks like this:\n\n    ! [maint] GIT 0.99.9c\n     * [master] Illustration: \"Commit DAG Revision Naming\"\n      ! [pu] Merge branch 'toys'\n    ---\n      + [pu] Merge branch 'toys'\n      + [pu^2] git-shallow-pack\n      + [pu^] Merge branches 'hold/svn' and 'hold/http'\n      + [pu^^3] [PATCH 2/2] Add support for git-http-push to git-push script\n      + [pu^^3^] [PATCH 1/2] Add support for pushing to a remote reposito...\n      + [pu^^2] Several fixes to import mono's svn tree\n      + [pu~2] git-tag: Do not assume the working tree root is writable.\n    +   [maint] GIT 0.99.9c\n    +++ [master] Illustration: \"Commit DAG Revision Naming\"\n\nThat is, I do not publish the heads of my topic branches, but\nyou can get them yourselves by looking at the merge logs in the\n\"pu\" branch.  \"toys\" head is pu^2, \"hold/svn\" head is pu^^2, etc.\n\nI think this \"bundling together into one pu\" head policy\nsomewhat discourages contributor developments on top of \"pu\"\nmaterial, but on the other hand the topic branches in my\nrepository tend to have relatively short lifespan, and I'd\nrather not clutter people's cloned repositories with these\ntransient branches.\n\nIf you wanted to try out Nick's http-push from \"hold/http\"\nbranch, for example, but prefer not to worry about bugs in other\nthings in \"pu\", you need to do this:\n\n1. Find out if I keep the change as a separate topic branch.\n   Either run \"gitk --all\" and inspect the commit structure\n   between \"master\" and \"pu\", or look at the \"pu\" merge log from\n   \"git-show-branch\" output above.\n\n2. Isolate the topic branch from \"pu\", discarding other stuff\n   you are not interested in.  After step 1, you figured out\n   that pu^^3 is the tip of hold/http branch, so make a local\n   branch for that, and merge the tip of \"origin\" on top of it,\n   because hold/http branch may not have been rebased to the\n   current master:\n\n    $ git checkout -b http-push pu^^3\n    $ git pull -n . origin\n    $ git show-branch origin http-push http-push^\n    ! [origin] Illustration: \"Commit DAG Revision Naming\"\n     * [http-push] Merge branch 'master'\n      ! [http-push^] [PATCH 2/2] Add support for git-http-push to ...\n    ---\n     +  [http-push] Merge branch 'master'\n    ++  [origin] Illustration: \"Commit DAG Revision Naming\"\n    ++  [origin^] Illustration: \"Git Diff Types\"\n    ++  [origin~2] Illustration: \"Fundamental Git Index Operations\"\n    ++  [origin~3] git-merge-ours: make sure our index matches HEAD\n    ++  [origin~4] Add 'ours' merge strategy.\n    ++  [origin~5] Add --no-commit to git-merge/git-pull.\n    ++  [origin~6] Document --since and --until options to rev-parse.\n     ++ [http-push^] [PATCH 2/2] Add support for git-http-push to ...\n     ++ [http-push^^] [PATCH 1/2] Add support for pushing to a rem...\n    +++ [http-push^~2] Be careful when dereferencing tags.\n\n3. Build, test, install and have fun.\n\n4. Suppose you came up with a neat enhancement idea or two to\n   Nick's http-push.  Do your development and make commits on\n   top of the current branch.  Your commit structure would look\n   like this after a couple of commits:\n\n    $ git show-branch origin http-push\n    ! [origin] Illustration: \"Commit DAG Revision Naming\"\n     * [http-push] Add feature nitfol.\n    --\n     + [http-push] Add feature nitfol.\n     + [http-push^] Add feature frotz.\n     + [http-push~2] Merge branch 'master'\n    ++ [origin] Illustration: \"Commit DAG Revision Naming\"\n\n5. Then feed me your changes, perhaps CC:ing the original author:\n\n    $ git format-patch -k -m http-push~2\n    * 0001-Add-feature-frotz.txt\n    * 0002-Add-feature-nitfol.txt\n\nYou could publish the head of this branch and tell me to pull\nfrom there, but I have a slight preference to receiving e-mail\npatches if the changes are about the material still in \"pu\".\n"},{"id":"11163","messageId":"Pine.LNX.4.64.0511041745480.25300@iabervon.org","threadId":"2339","inReplyTo":"7vy8453zhu.fsf@assigned-by-dhcp.cox.net","subject":"Re: Trying to Update All Heads of a Repository","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-11-04T23:47:21Z","receivedAt":"2005-11-04T23:47:21Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 3 Nov 2005, Junio C Hamano wrote:\n\n> Jon Loeliger <jdl@freescale.com> writes:\n> \n> > First, I have this, because it came with a git-clone:\n> >\n> >     % cat .git/remotes/origin\n> >     URL: rsync://rsync.kernel.org/pub/scm/git/git.git\n> >     Pull: master:origin\n> >\n> > I don't know how to say \"Grab all the updates for\n> > all the heads for which I have heads in my .git/refs\".\n> \n> My \"guinea pig\" repository has this in $GIT_DIR/remotes/origin:\n> \n>         URL: git://git.kernel.org/pub/scm/git/git.git\n>         Pull: master:origin\n>         Pull: +pu:pu\n>         Pull: maint:maint\n\nShouldn't approximately this be what git-clone sets up for you? If it's \ngetting those heads initially, it should keep the information for future \nuse. The only thing it wouldn't know would be the \"+\" on pu.\n\nOn the \"pu\" issue, maybe \"pu\" shouldn't be a branch, but should be \nsomething different, like a tag. I think, actually, that a tag would \ndescribe \"pu\" pretty well: no development happens on its line; rather, \ndevelopment happens elsewhere (topic branches), and a merge of some of \nthem is then released as being interesting. What is interesting as \"pu\" \ntoday isn't necessarily related to yesterday or tomorrow. Then you \nwouldn't exactly be rebasing things all the time, but you'd instead be \nmarking different and unrelated commits in the same way at different \ntimes. (Probably need to do more to handle the case where a tag ref \nchanges and define the semantics properly)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"11164","messageId":"7v64r7sv7o.fsf@assigned-by-dhcp.cox.net","threadId":"2339","inReplyTo":"Pine.LNX.4.64.0511041745480.25300@iabervon.org","subject":"Re: Trying to Update All Heads of a Repository","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-05T02:07:55Z","receivedAt":"2005-11-05T02:07:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> Shouldn't approximately this be what git-clone sets up for you? If it's \n> getting those heads initially, it should keep the information for future \n> use. The only thing it wouldn't know would be the \"+\" on pu.\n\nYes, and I am actually thinking along the lines of:\n\n         URL: git://git.kernel.org/pub/scm/git/git.git\n         Pull: master:origin/master\n         Pull: +pu:origin/pu\n         Pull: maint:origin/maint\n\nto further prevent the puller's namespace being cluttered.  This\nhas an added benefit that it gives a convention that\n\"remotes/origin\" file describes the \"refs/heads/origin\"\nhierarchy.  In the past, somebody complained that branches/*\nfiles are configuration per local branch, but remotes/* files\nare not.\n\n> On the \"pu\" issue, maybe \"pu\" shouldn't be a branch, but should be \n> something different, like a tag. I think, actually, that a tag would \n> describe \"pu\" pretty well: no development happens on its line; rather, \n> development happens elsewhere (topic branches), and a merge of some of \n> them is then released as being interesting.\n\nHmph.  That is a thought.\n\nAnother thing that bothers me somewhat about git.git/ repository\nis the todo branch.  The \"todo\" branch does not have any common\ncommit from the mainline and it is deliberately so --- I'd want\nto maintain a unified TODO list even after we go 1.0, at that\ntime I plan to have master that continues post 1.0 development,\nmaint which corresponds the current maint (i.e. maintenance for\npost 1.0 releases) and maint1.0 which is for backporting\nimportant fixes to frozen 1.0.  I could maintain separate\nTODO-for-post-1.0 and TODO-for-1.0-maint, but that is rather a\nwaste --- items on the two list both end up requirign attention\nand time from the same brain.  Also merging \"todo\" into master\nand maint1.0 the way \"gitk\" project was merged into git.git\nwould not make much sense, because that merge is pretty much\none-way street.\n\nThe first thing I clone from git.git/ repository is almost\nalways \"rm -f .git/refs/heads/todo\", because it clutters\ngit-show-branch output otherwise ;-).  In fact, it comes from\ntotally separate repository on my private end, and just happens\nto be pushed into the same git.git/ repository (partly because I\ndo not have any other repository there at kernel.org; i.e.\n/pub/scm/git/ is not writable by me).\n"},{"id":"11190","messageId":"7v1x1u1652.fsf@assigned-by-dhcp.cox.net","threadId":"2339","inReplyTo":"Pine.LNX.4.64.0511041745480.25300@iabervon.org","subject":"[PATCH] Set up remotes/origin to track all remote branches.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-06T09:23:53Z","receivedAt":"2005-11-06T09:23:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> On Thu, 3 Nov 2005, Junio C Hamano wrote:\n>\n>> My \"guinea pig\" repository has this in $GIT_DIR/remotes/origin:\n>> \n>>         URL: git://git.kernel.org/pub/scm/git/git.git\n>>         Pull: master:origin\n>>         Pull: +pu:pu\n>>         Pull: maint:maint\n>\n> Shouldn't approximately this be what git-clone sets up for you? If it's \n> getting those heads initially, it should keep the information for future \n> use. The only thing it wouldn't know would be the \"+\" on pu.\n\nI think this makes sense, and especially so, once we later\nchange the default behaviour of 'git clone' to clone but rename\nthe remote refs to somewhere else.\n\n-- >8 -- cut here -- >8 --\n\nThis implements the idea Daniel Barkalow came up with, to match\nthe remotes/origin created by clone by default to the workflow I\nuse myself in my guinea pig repository, to have me eat my own\ndog food.\n\nWe probably would want to use either .git/refs/local/heads/*\n(idea by Linus) or .git/refs/heads/origin/* instead to reduce\nthe local ref namespace pollution.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n Documentation/git-clone.txt |    3 ++-\n git-clone.sh                |   12 ++++++++++--\n 2 files changed, 12 insertions(+), 3 deletions(-)\n\napplies-to: 9cc3928769f8f4e3597fa446321112c0568514df\na0b45ee2b1362d664cca2d81f2915ed3b903b252\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex cbd83f3..fefd298 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -25,7 +25,8 @@ This is to help the typical workflow of \n remote `master` branch.  Every time `git pull` without argument\n is run, the progress on the remote `master` branch is tracked by\n copying it into the local `origin` branch, and merged into the\n-branch you are currently working on.\n+branch you are currently working on.  Remote branches other than\n+`master` are also added there to be tracked.\n \n \n OPTIONS\ndiff --git a/git-clone.sh b/git-clone.sh\nindex 1adf604..4fdd652 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -202,8 +202,16 @@ then\n \t\tmkdir -p .git/remotes &&\n \t\techo >.git/remotes/origin \\\n \t\t\"URL: $repo\n-Pull: $head_points_at:origin\"\n-\t\tcp \".git/refs/heads/$head_points_at\" .git/refs/heads/origin\n+Pull: $head_points_at:origin\" &&\n+\t\tcp \".git/refs/heads/$head_points_at\" .git/refs/heads/origin &&\n+\t\tfind .git/refs/heads -type f -print |\n+\t\twhile read ref\n+\t\tdo\n+\t\t\thead=`expr \"$ref\" : '.git/refs/heads/\\(.*\\)'` &&\n+\t\t\ttest \"$head_points_at\" = \"$head\" ||\n+\t\t\ttest \"origin\" = \"$head\" ||\n+\t\t\techo \"Pull: ${head}:${head}\"\n+\t\tdone >>.git/remotes/origin\n \tesac\n \n \tcase \"$no_checkout\" in\n---\n0.99.9.GIT\n"}]}