{"thread":{"id":"3691","subject":"What's in git.git","startedAt":"2006-03-22T01:58:28Z","lastAt":"2006-03-22T19:15:02Z","messageCount":10,"participants":["Junio C Hamano","Randal L. Schwartz","Bertrand Jacquin","Petr Baudis","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"17748","messageId":"7vodzzb5q3.fsf@assigned-by-dhcp.cox.net","threadId":"3691","inReplyTo":null,"subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-22T01:58:28Z","receivedAt":"2006-03-22T01:58:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"* The 'master' branch has these since the last announcement.\n\n - git.el updates (Alexandre Julliard)\n - git-svn updates (Eric Wong)\n - git-blame updates (Fredrik Kuivinen)\n - documentation updates (Francis Daly, Jon Loeliger)\n - Makefile: Add TAGS and tags targets (Fredrik Kuivinen)\n - http-push support for deleting remote branches (Nick Hengeveld)\n\n - assorted minor fixes and tweaks (Alexandre Julliard, Mark\n   Hollomon, Shawn Pearce, Yasushi SHOJI, Nicolas Pitre, Randal\n   L. Schwartz and me)\n\n* The 'next' branch, in addition, has two important fixes and\n  enhancements, and it probably is a good time to do a 1.3\n  release when they graduate to \"master\" and prove stable.\n\n - quicker and dirtier rename detection by Linus and me.\n\n   I've been using this myself and haven't seen major\n   misdetection so far, but I do not use much renames.  Maybe\n   it's time to push this out and see what happens.  This is\n   _not_ the \"important\" part.\n\n - cvsimport post-import checkout fix.\n\n   Earlier we had a workaround to deal with people who import\n   into the current branch by not checking out.  After\n   incrementally importing from the same CVS repository again,\n   however, the code did update the branch head.  This made the\n   working tree and the index stale and was causing more\n   confusion than it avoided.\n\n   This fix is to make re-importing act more like git-pull, not\n   git-fetch.  So if you run an incremental import into the\n   current branch, it tries to fast-forward the working tree and\n   index (your current branch head, index and working tree had\n   better be pristine with respect to the CVS repository for\n   this, but that is already an requirement for a tracking\n   branch anyway) when your current branch is the tracking\n   branch, or merge the imported result into your current branch\n   if you are using a separate tracking branch.\n\n   I've done some testing on this myself, but am waiting for\n   independent confirmations from cvsimport users.  Merlyn?\n\n - refs/remotes support.\n\n   This has been the recent hot topic, on git-clone.\n\n   First, not so controversial one.  A new option --reference\n   can be used to help cloning a project similar to what you\n   already have over thin wire:\n\n\t$ git clone --reference /git/linux-2.6.git \\\n          git://git.kernel.org/pub/.../jgarzik/libata-dev.git/ \\\n          libata-dev\n\n   What happens here is that the new repository (libata-dev you\n   are creating by cloning from Jeff) is set up to borrow from\n   vanilla Linus repository you already keep track of, and the\n   initial clone downloads and expands objects that are only\n   present in Jeff's tree.\n\n   Another new option, --use-separate-remote, changes the way\n   $GIT_DIR/remotes/origin file and your tracking branches are\n   set up after the initial cloning.  Without it, all the remote\n   heads are copied to your $GIT_DIR/refs/heads/ and a copy of\n   the remote HEAD is made as $GIT_DIR/refs/heads/origin, and\n   remotes/origin file is set up to keep this structure up to\n   date.  This is the traditional behaviour.\n\n   When --use-separate-remote is in effect, the tracking\n   branches are created in $GIT_DIR/refs/remotes/origin/ and you\n   will not get the extra \"origin\" head.  Your local branch\n   namespace under $GIT_DIR/refs/heads/ will only have \"master\".\n   In addition, a symref $GIT_DIR/refs/remotes/origin/HEAD\n   points at the primary branch of the remote repository.\n   Similar to a filename in $GIT_DIR/refs/{heads,tags} that can\n   be used to name a ref (e.g. when you say \"git diff frotz\",\n   you are telling git to read from $GIT_DIR/refs/heads/frotz\n   and use that commit ID to diff your working tree against), a\n   directory that has such a symref under $GIT_DIR/refs/remotes\n   can be used to name the ref.  IOW, \"git diff origin\" in a\n   repository a cloned this way means you want a diff against\n   $GIT_DIR/refs/remotes/origin/HEAD.\n\n   I've done reasonable amount of testing over git:// transport,\n   and some with http:// as well, but I do not know if rsync://\n   works at all (I never use rsync:// transport myself).  If\n   anybody cares about rsync:// transport, please test it while\n   it still is in \"next\" to keep things working for you.\n\n   A new configuration option, 'core.warnambiguousrefs', can be\n   set to warn you if you use \"frotz\" to name a ref when you\n   have more than one \"frotz\" under $GIT_DIR/refs (e.g. you have\n   both branch \"frotz\" and tag \"frotz\", and/or you have\n   refs/remotes/frotz/HEAD).\n\n   It also has changes by Eric Wong to teach git-fetch about\n   $GIT_DIR/refs/remotes hierarchy.\n"},{"id":"17749","messageId":"86y7z3mdcz.fsf@blue.stonehenge.com","threadId":"3691","inReplyTo":"7vodzzb5q3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-03-22T02:18:04Z","receivedAt":"2006-03-22T02:18:04Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano <junkio@cox.net> writes:\n\nJunio>  - cvsimport post-import checkout fix.\n\nJunio>    Earlier we had a workaround to deal with people who import\nJunio>    into the current branch by not checking out.  After\nJunio>    incrementally importing from the same CVS repository again,\nJunio>    however, the code did update the branch head.  This made the\nJunio>    working tree and the index stale and was causing more\nJunio>    confusion than it avoided.\n\nJunio>    This fix is to make re-importing act more like git-pull, not\nJunio>    git-fetch.  So if you run an incremental import into the\nJunio>    current branch, it tries to fast-forward the working tree and\nJunio>    index (your current branch head, index and working tree had\nJunio>    better be pristine with respect to the CVS repository for\nJunio>    this, but that is already an requirement for a tracking\nJunio>    branch anyway) when your current branch is the tracking\nJunio>    branch, or merge the imported result into your current branch\nJunio>    if you are using a separate tracking branch.\n\nJunio>    I've done some testing on this myself, but am waiting for\nJunio>    independent confirmations from cvsimport users.  Merlyn?\n\nI'm waiting for that CVS tree to change again.  It changes every\n4-5 days.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"17752","messageId":"86hd5rma75.fsf@blue.stonehenge.com","threadId":"3691","inReplyTo":"86y7z3mdcz.fsf@blue.stonehenge.com","subject":"Re: What's in git.git","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-03-22T03:26:22Z","receivedAt":"2006-03-22T03:26:22Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Randal\" == Randal L Schwartz <merlyn@stonehenge.com> writes:\n\nRandal> I'm waiting for that CVS tree to change again.  It changes every\nRandal> 4-5 days.\n\nSpeaking of which, I *know* you sent me a patch to apply to incorporate the\none difference, but is there a more automatic way of cherry-picking\ngit-cvsimport.perl from \"next\" into a new topic branch of mine?\n\nFor example, I can do this:\n\n$ git-checkout next\n$ cp git-cvsimport.perl DUMMY\n$ git-checkout -b my-playground\n$ mv DUMMY git-cvsimport.perl\n$ git-commit -a -m 'trying that other version'\n\nBut this wastes a commit.  Is there any way to get an index that simply\nincludes the file from that other branch?\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"17757","messageId":"7vacbjawyu.fsf@assigned-by-dhcp.cox.net","threadId":"3691","inReplyTo":"86hd5rma75.fsf@blue.stonehenge.com","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-22T05:07:37Z","receivedAt":"2006-03-22T05:07:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> For example, I can do this:\n>\n> $ git-checkout next\n> $ cp git-cvsimport.perl DUMMY\n> $ git-checkout -b my-playground\n> $ mv DUMMY git-cvsimport.perl\n> $ git-commit -a -m 'trying that other version'\n>\n> But this wastes a commit.  Is there any way to get an index that simply\n> includes the file from that other branch?\n\n        $ git checkout master\n        $ git checkout next git-cvsimport.perl\n"},{"id":"17758","messageId":"867j6nm47b.fsf@blue.stonehenge.com","threadId":"3691","inReplyTo":"7vacbjawyu.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-03-22T05:35:52Z","receivedAt":"2006-03-22T05:35:52Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano <junkio@cox.net> writes:\n\n>> But this wastes a commit.  Is there any way to get an index that simply\n>> includes the file from that other branch?\n\nJunio>         $ git checkout master\nJunio>         $ git checkout next git-cvsimport.perl\n\nYow.  How simple is *that*?  Thanks.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>\nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"17759","messageId":"7v64m7av6o.fsf@assigned-by-dhcp.cox.net","threadId":"3691","inReplyTo":"867j6nm47b.fsf@blue.stonehenge.com","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-22T05:46:07Z","receivedAt":"2006-03-22T05:46:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>>>>> \"Junio\" == Junio C Hamano <junkio@cox.net> writes:\n>\n>>> But this wastes a commit.  Is there any way to get an index that simply\n>>> includes the file from that other branch?\n>\n> Junio>         $ git checkout master\n> Junio>         $ git checkout next git-cvsimport.perl\n>\n> Yow.  How simple is *that*?  Thanks.\n\nThere is one thing you would want to be careful about.\nThis updates the index.\n"},{"id":"17764","messageId":"4fb292fa0603220221q5f3bf9c7pd73154a34e79a523@mail.gmail.com","threadId":"3691","inReplyTo":"7vodzzb5q3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Bertrand Jacquin","fromEmail":"beber.mailing@gmail.com","sentAt":"2006-03-22T10:21:45Z","receivedAt":"2006-03-22T10:21:45Z","isPatch":false,"sender":{"key":"beber.mailing@gmail.com","avatar":null},"body":"On 3/22/06, Junio C Hamano <junkio@cox.net> wrote:\n>\n>    A new configuration option, 'core.warnambiguousrefs', can be\n>    set to warn you if you use \"frotz\" to name a ref when you\n>    have more than one \"frotz\" under $GIT_DIR/refs (e.g. you have\n>    both branch \"frotz\" and tag \"frotz\", and/or you have\n>    refs/remotes/frotz/HEAD).\n\nAh cool :) I had the problem recently.\nAlso, Would could I know all configuration option ?\n\n--\nBeber\n#e.fr@freenode\n"},{"id":"17766","messageId":"20060322115218.GT18185@pasky.or.cz","threadId":"3691","inReplyTo":"7vodzzb5q3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-03-22T11:52:18Z","receivedAt":"2006-03-22T11:52:18Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Mar 22, 2006 at 02:58:28AM CET, I got a letter\nwhere Junio C Hamano <junkio@cox.net> said that...\n>    When --use-separate-remote is in effect, the tracking\n>    branches are created in $GIT_DIR/refs/remotes/origin/ and you\n>    will not get the extra \"origin\" head.  Your local branch\n>    namespace under $GIT_DIR/refs/heads/ will only have \"master\".\n>    In addition, a symref $GIT_DIR/refs/remotes/origin/HEAD\n>    points at the primary branch of the remote repository.\n>    Similar to a filename in $GIT_DIR/refs/{heads,tags} that can\n>    be used to name a ref (e.g. when you say \"git diff frotz\",\n>    you are telling git to read from $GIT_DIR/refs/heads/frotz\n>    and use that commit ID to diff your working tree against), a\n>    directory that has such a symref under $GIT_DIR/refs/remotes\n>    can be used to name the ref.  IOW, \"git diff origin\" in a\n>    repository a cloned this way means you want a diff against\n>    $GIT_DIR/refs/remotes/origin/HEAD.\n\nSounds very good.\n\n>    A new configuration option, 'core.warnambiguousrefs', can be\n>    set to warn you if you use \"frotz\" to name a ref when you\n>    have more than one \"frotz\" under $GIT_DIR/refs (e.g. you have\n>    both branch \"frotz\" and tag \"frotz\", and/or you have\n>    refs/remotes/frotz/HEAD).\n\nIs there any reason why this isn't enabled by default?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nRight now I am having amnesia and deja-vu at the same time.  I think\nI have forgotten this before.\n"},{"id":"17769","messageId":"Pine.LNX.4.64.0603220820090.26286@g5.osdl.org","threadId":"3691","inReplyTo":"7v64m7av6o.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-22T16:21:23Z","receivedAt":"2006-03-22T16:21:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 21 Mar 2006, Junio C Hamano wrote:\n\n> merlyn@stonehenge.com (Randal L. Schwartz) writes:\n> \n> >>>>>> \"Junio\" == Junio C Hamano <junkio@cox.net> writes:\n> >\n> >>> But this wastes a commit.  Is there any way to get an index that simply\n> >>> includes the file from that other branch?\n> >\n> > Junio>         $ git checkout master\n> > Junio>         $ git checkout next git-cvsimport.perl\n> >\n> > Yow.  How simple is *that*?  Thanks.\n> \n> There is one thing you would want to be careful about.\n> This updates the index.\n\nYes. Btw, I've been bitten by that. I think it might be better to _not_ \nupdate the index when we check out a file from another branch than the one \nwe're on (or rather, we should perhaps update the index with the value \nfrom the current branch every time, even though the _working_tree_ is \nupdated from another branch)\n\n\t\tLinus\n"},{"id":"17773","messageId":"7vmzfi8f61.fsf@assigned-by-dhcp.cox.net","threadId":"3691","inReplyTo":"20060322115218.GT18185@pasky.or.cz","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-22T19:15:02Z","receivedAt":"2006-03-22T19:15:02Z","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>>    A new configuration option, 'core.warnambiguousrefs', can be\n>>    set to warn you if you use \"frotz\" to name a ref when you\n>>    have more than one \"frotz\" under $GIT_DIR/refs (e.g. you have\n>>    both branch \"frotz\" and tag \"frotz\", and/or you have\n>>    refs/remotes/frotz/HEAD).\n>\n> Is there any reason why this isn't enabled by default?\n\nNot in particular, other than Inertia and trying one baby step\nat a time.\n"}]}