{"thread":{"id":"20755","subject":"Question regarding git fetch","startedAt":"2009-08-27T15:30:45Z","lastAt":"2009-08-28T13:24:12Z","messageCount":17,"participants":["Tom Lambda","Avery Pennarun","Eric Raible","Björn Steinbrink","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"121868","messageId":"1251387045053-3527289.post@n2.nabble.com","threadId":"20755","inReplyTo":null,"subject":"Question regarding git fetch","fromName":"Tom Lambda","fromEmail":"tom.lambda@gmail.com","sentAt":"2009-08-27T15:30:45Z","receivedAt":"2009-08-27T15:30:45Z","isPatch":false,"sender":{"key":"tom.lambda@gmail.com","avatar":null},"body":"\nI noticed that git-fetch seems smarter when it is run without a \nargument than when one specifies a branch name. I use a simple setup where a\nremote central repository is defined when it is cloned the first time (clone\n-o central ...). This leads to these default parameters:\n\nremote.central.fetch=+refs/heads/*:refs/remotes/central/*\nbranch.master.remote=central\nbranch.master.merge=refs/heads/master\n\nWhen I use \"git fetch central\" each branch in central's refs/heads/ is\nautomatically fetched to my refs/remotes/central/ as expected.\n\nWhat was a little bit surprising to me is that running \"git fetch central\nmaster\" does not update refs/remotes/central/master but simply updates\nFETCH_HEAD.\n\nI read the manual and I know that updating FETCH_HEAD is the expected\ndefault behavior for git-fetch. However, I really like the fact that git\nfetch (without ) knows that ANY branch in refs/heads/ corresponds\nto refs/remotes/central/. Is there a way to change the configuration to have\n\"git fetch central branch\" always updating refs/remotes/central/branch\nwhatever the specified branch.\n\nI would prefer not to have to specify the each time:\ngit fetch central branch:remotes/central/branch\n\nThank you,\nTom\n\n-- \nView this message in context: http://n2.nabble.com/Question-regarding-git-fetch-tp3527289p3527289.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"121870","messageId":"32541b130908270836m50553ccatddf4c870eec54ddb@mail.gmail.com","threadId":"20755","inReplyTo":"1251387045053-3527289.post@n2.nabble.com","subject":"Re: Question regarding git fetch","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-08-27T15:36:53Z","receivedAt":"2009-08-27T15:36:53Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, Aug 27, 2009 at 3:30 PM, Tom Lambda wrote:\n> What was a little bit surprising to me is that running \"git fetch central\n> master\" does not update refs/remotes/central/master but simply updates\n> FETCH_HEAD.\n\nI've often wanted this myself, especially when doing things like \"git\npull origin master\". However, I know the current behaviour is also\nuseful sometimes, and changing it would introduce an unexpected side\neffect. Git currently promises that your refs/remotes/* branches will\nnever be updated unless you explicitly request it, even if you're\nfetching, merging, and pulling other stuff. This means you can write\nscripts to do complicated things without triggering unexpected\nuser-visible side effects.\n\nSo basically, I agree that it would often be much more user-friendly\nto do what you're asking. But it would be less scripting-friendly. I\ndon't think anyone has thought of an answer that better balances the\ntwo.\n\nHave fun,\n\nAvery\n"},{"id":"121876","messageId":"loom.20090827T180201-590@post.gmane.org","threadId":"20755","inReplyTo":"32541b130908270836m50553ccatddf4c870eec54ddb@mail.gmail.com","subject":"Re: Question regarding git fetch","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2009-08-27T16:21:37Z","receivedAt":"2009-08-27T16:21:37Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"Avery Pennarun gmail.com> writes:\n\n> Git currently promises that your refs/remotes/* branches will\n> never be updated unless you explicitly request it, even if you're\n> fetching, merging, and pulling other stuff.\n\nSo your claim is that \"git fetch central\" is somehow more\nexplicit than \"git fetch central master\"?\n\nI understand that \"git fetch central\" will use\nremote.central.fetch (which _is_ explicit), but\nthe command itself is certainly _less_ explicit about\nspecifying the remote branch.\n\nEither way, AFAICT it seems purely historical that\n\"git fetch central master\" doesn't update remotes/central.\n\n- Eric\n"},{"id":"121880","messageId":"32541b130908270928i528fa754o16f4cc7a141417c9@mail.gmail.com","threadId":"20755","inReplyTo":"loom.20090827T180201-590@post.gmane.org","subject":"Re: Question regarding git fetch","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-08-27T16:28:07Z","receivedAt":"2009-08-27T16:28:07Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, Aug 27, 2009 at 4:21 PM, Eric Raible wrote:\n> Avery Pennarun gmail.com> writes:\n>\n>> Git currently promises that your refs/remotes/* branches will\n>> never be updated unless you explicitly request it, even if you're\n>> fetching, merging, and pulling other stuff.\n>\n> So your claim is that \"git fetch central\" is somehow more\n> explicit than \"git fetch central master\"?\n\nIt is, because there's nothing else you could possibly do with it. It\nfetches too many things, so you don't know their names (other than the\nones it puts into refs/remotes/*).\n\nSo it's not exactly that it's more explicit - in fact it's rather\nconfusing and non-explicit that the three-parameter version does\nsomething almost entirely different from the four-parameter one - but\nthe three-parameter version is at least completely unambiguous.\n\n> Either way, AFAICT it seems purely historical that\n> \"git fetch central master\" doesn't update remotes/central.\n\nThis seems true to me.\n\nHave fun,\n\nAvery\n"},{"id":"121882","messageId":"20090827164657.GA17090@atjola.homenet","threadId":"20755","inReplyTo":"32541b130908270836m50553ccatddf4c870eec54ddb@mail.gmail.com","subject":"Re: Question regarding git fetch","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-08-27T16:46:57Z","receivedAt":"2009-08-27T16:46:57Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.08.27 15:36:53 +0000, Avery Pennarun wrote:\n> On Thu, Aug 27, 2009 at 3:30 PM, Tom Lambda wrote:\n> > What was a little bit surprising to me is that running \"git fetch central\n> > master\" does not update refs/remotes/central/master but simply updates\n> > FETCH_HEAD.\n> \n> I've often wanted this myself, especially when doing things like \"git\n> pull origin master\". However, I know the current behaviour is also\n> useful sometimes, and changing it would introduce an unexpected side\n> effect. Git currently promises that your refs/remotes/* branches will\n> never be updated unless you explicitly request it, even if you're\n> fetching, merging, and pulling other stuff. This means you can write\n> scripts to do complicated things without triggering unexpected\n> user-visible side effects.\n> \n> So basically, I agree that it would often be much more user-friendly\n> to do what you're asking. But it would be less scripting-friendly. I\n> don't think anyone has thought of an answer that better balances the\n> two.\n\nIt would also be pretty hard to implement that. Given the default fetch\nrefspec, it would \"simply\" be a matter of mapping the given ref to the\nrefspec, so e.g. \"foo\" becomes \"refs/heads/foo:refs/remotes/origin/foo\".\nBut even just using \"git remote add -t master foo git://...\" breaks\nthat, as the fetch refspec in the config will no longer be a glob, and\nthus no such mapping is possible.\n\nBjörn\n"},{"id":"121884","messageId":"32541b130908271022i6a825198i37e2ec82ed5f833c@mail.gmail.com","threadId":"20755","inReplyTo":"20090827164657.GA17090@atjola.homenet","subject":"Re: Question regarding git fetch","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-08-27T17:22:55Z","receivedAt":"2009-08-27T17:22:55Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"2009/8/27 Björn Steinbrink :\n> It would also be pretty hard to implement that. Given the default fetch\n> refspec, it would \"simply\" be a matter of mapping the given ref to the\n> refspec, so e.g. \"foo\" becomes \"refs/heads/foo:refs/remotes/origin/foo\".\n> But even just using \"git remote add -t master foo git://...\" breaks\n> that, as the fetch refspec in the config will no longer be a glob, and\n> thus no such mapping is possible.\n\nHmm, I don't really see why that introduces a problem. If you use -t\nto override explicitly which refs you want to save, then it's not a\nproblem if git doesn't save other refs, right?\n\nI'd be more concerned about the inconsistency between\n\n git fetch git://whatever master\nand\n git fetch origin master\n\nThere's no really good way for the first one to know it needs to\nupdate any branches, even though 'origin' might be an alias for\ngit://whatever. So users will still be confused.\n\nThinking of that also reminds me of another surprise. If you do:\n\n git fetch git://whatever\n\n...it seems to do nothing at all, as far as I can see. Which makes\nsense, I guess, since I wouldn't really expect it to be meaningful.\nBut it seems to connect up to the remote server anyway just in case.\n\nI suppose I have no useful suggestions here, other than an\ninterpretation of why users find the current behaviour confusing.\n\nHave fun,\n\nAvery\n"},{"id":"121912","messageId":"20090827204835.GC4399@coredump.intra.peff.net","threadId":"20755","inReplyTo":"32541b130908271022i6a825198i37e2ec82ed5f833c@mail.gmail.com","subject":"Re: Question regarding git fetch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-27T20:48:35Z","receivedAt":"2009-08-27T20:48:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 27, 2009 at 05:22:55PM +0000, Avery Pennarun wrote:\n\n> 2009/8/27 Björn Steinbrink :\n> > It would also be pretty hard to implement that. Given the default fetch\n> > refspec, it would \"simply\" be a matter of mapping the given ref to the\n> > refspec, so e.g. \"foo\" becomes \"refs/heads/foo:refs/remotes/origin/foo\".\n> > But even just using \"git remote add -t master foo git://...\" breaks\n> > that, as the fetch refspec in the config will no longer be a glob, and\n> > thus no such mapping is possible.\n> \n> Hmm, I don't really see why that introduces a problem. If you use -t\n> to override explicitly which refs you want to save, then it's not a\n> problem if git doesn't save other refs, right?\n\nI think you can handle both cases just by matching the fetched refs to\nthe LHS of the refspec.\n\nSo if you fetch \"refs/heads/foo\", and if you have a refspec of:\n\n refs/heads/*:refs/remotes/origin/*\n\nthen you see that the LHS glob matches, and the RHS expands to\nrefs/remotes/origin/foo. And if you have a more restrictive refspec,\nthat would work, too:\n\n refs/heads/foo:refs/remotes/origin/foo\n\nwould still match, but\n\n refs/heads/bar:refs/remotes/origin/bar\n\ndoes not match on the LHS, so you write nothing. It would even handle\nmultiple refspecs properly.\n\nAnd this matching is not really any different than what the fetch code\ndoes when applying the refspec to what the remote offers. So I don't\nthink it should be any significant new code; it's just a matter of\nactivating that matching and updating the local tracking refs based on\nwhat we actually fetched, instead of what the remote advertised.\n\n> I'd be more concerned about the inconsistency between\n> \n> git fetch git://whatever master\n> and\n> git fetch origin master\n> \n> There's no really good way for the first one to know it needs to\n> update any branches, even though 'origin' might be an alias for\n> git://whatever. So users will still be confused.\n\nWell, you can always reverse-lookup each remote to see if the URL\nmatches. Of course you would never know that \"http://whatever\" is an\nalias for \"git://whatever\". Personally, I don't imagine that users\nreally expect git to reverse-map remotes in that way (after all, why\nwould they input git://whatever long-hand if they knew that it was a\nremote).\n\n> Thinking of that also reminds me of another surprise. If you do:\n> \n> git fetch git://whatever\n> \n> ...it seems to do nothing at all, as far as I can see. Which makes\n> sense, I guess, since I wouldn't really expect it to be meaningful.\n> But it seems to connect up to the remote server anyway just in case.\n\nShouldn't it fetch HEAD from the remote and store it in FETCH_HEAD? And\nthen tell you that it did that?\n\nI get:\n\n $ mkdir foo && cd foo && git init\n Initialized empty Git repository in /home/peff/foo/.git/\n\n $ git fetch ~/compile/git\n remote: Counting objects: 85011, done.\n remote: Compressing objects: 100% (23942/23942), done.\n remote: Total 85011 (delta 61389), reused 83076 (delta 59655)\n Receiving objects: 100% (85011/85011), 19.03 MiB | 11385 KiB/s, done.\n Resolving deltas: 100% (61389/61389), done.\n From /home/peff/compile/git\n * branch HEAD -> FETCH_HEAD\n\n $ git fetch git://git.kernel.org/pub/scm/git/git.git\n From git://git.kernel.org/pub/scm/git/git\n * branch HEAD -> FETCH_HEAD\n\n-Peff\n"},{"id":"121918","messageId":"7viqg9q7gx.fsf@alter.siamese.dyndns.org","threadId":"20755","inReplyTo":"32541b130908270836m50553ccatddf4c870eec54ddb@mail.gmail.com","subject":"Re: Question regarding git fetch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-27T21:20:46Z","receivedAt":"2009-08-27T21:20:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Avery Pennarun writes:\n\n> On Thu, Aug 27, 2009 at 3:30 PM, Tom Lambda wrote:\n>> What was a little bit surprising to me is that running \"git fetch central\n>> master\" does not update refs/remotes/central/master but simply updates\n>> FETCH_HEAD.\n>\n> I've often wanted this myself, especially when doing things like \"git\n> pull origin master\". However, I know the current behaviour is also\n> useful sometimes, and changing it would introduce an unexpected side\n> effect. Git currently promises that your refs/remotes/* branches will\n> never be updated unless you explicitly request it, even if you're\n> fetching, merging, and pulling other stuff. This means you can write\n> scripts to do complicated things without triggering unexpected\n> user-visible side effects.\n\nI think it is reasonable, in 1.7.0, to change \"git fetch\" with command\nline refspacs that lack colon (i.e. saying \"fetch this ref\" without saying\n\"and store it here\") so that it updates remote tracking refs if and only\nif an appropriate remote.$remote.fetch is configured to do so. E.g. when\nI fetch from Eric for git-svn updates with\n\n\t$ git pull git-svn master\n\nbecause I do have\n\n\t[remote \"git-svn\"]\n url = git://yhbt.net/git-svn\n fetch = +refs/heads/*:refs/remotes/git-svn/*\n\ndefined, it is Ok to update refs/remotes/git-svn/master (but not others).\n\nOn the other hand, if my refspecs for \"git svn\" _were_ like this:\n\n\t[remote \"git-svn\"]\n\t\turl = git://yhbt.net/git-svn\n fetch = +refs/heads/master:refs/remotes/git-svn/master\n\nthen I would _not_ want this:\n\n\t$ git fetch git-svn dev\n\nto create a new tracking branch refs/remotes/git-svn/dev.\n\nIt used to be that the only way to check the progress of other people\nwere to do this:\n\n\t$ git fetch git-svn master\n\t$ git log git-svn/master..FETCH_HEAD\n\nBut these days, even if we changed the \"git fetch\" semantics, we can still\nrely on reflogs to do the equivalent with:\n\n\t$ git fetch git-svn\n\t$ git log git-svn/master@{1}..git-svn/master\n\nIn other words, I think the \"feature\" that an explicit \"fetch but do not\nstore this time\" request to prevent \"git fetch\" from updating the tracking\nbranches outlived its usefulness.\n"},{"id":"121920","messageId":"20090827213426.GD4399@coredump.intra.peff.net","threadId":"20755","inReplyTo":"20090827204835.GC4399@coredump.intra.peff.net","subject":"Re: Question regarding git fetch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-27T21:34:26Z","receivedAt":"2009-08-27T21:34:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 27, 2009 at 04:48:35PM -0400, Jeff King wrote:\n\n> And this matching is not really any different than what the fetch code\n> does when applying the refspec to what the remote offers. So I don't\n> think it should be any significant new code; it's just a matter of\n> activating that matching and updating the local tracking refs based on\n> what we actually fetched, instead of what the remote advertised.\n\nSure enough, here is a really simple proof of concept. This is the first\ntime I have really looked into the fetch code, so I hope I'm not totally\nbreaking something else. :)\n\nBasically it works like this. Both \"git fetch remote\" and \"git fetch\nremote refspec\" work by making a \"ref map\" via get_ref_map. This is a\nlist of refs, with some refs having a \"peer ref\" that points to the\nlocal counterpart. Those without a peer are just stored in FETCH_HEAD.\nThe function works by starting with a list of possible remote refs, and\nthen applying the refspecs to it.\n\nCalling fetch without explicit refspecs means we will create the map\nusing the configured refspecs. Calling with commandline refspecs means\nwe will use those. So what this patch does is to first apply the\ncommandline refspecs to narrow the list, and then apply the configured\nrefspecs on top of that to make a new list, and then concatenate the\nlists.\n\nSo you will end up with \"two\" refs to fetch, which just happen to match\nthe same source. One will go to FETCH_HEAD, and one will go to the\ntracking ref. I.e.:\n\n $ git remote add origin ~/compile/git\n $ git fetch origin next\n From /home/peff/compile/git\n * branch next -> FETCH_HEAD\n * [new branch] next -> origin/next\n\nAnd it should work the same if you supply a more interesting refspec,\ntoo:\n\n $ git fetch -v origin next:foo\n From /home/peff/compile/git\n * [new branch] next -> foo\n = [up to date] next -> origin/next\n\nor even a wildcard:\n\n $ git fetch -v origin refs/heads/*:refs/foo/*\n From /home/peff/compile/git\n * [new branch] master -> refs/foo/master\n * [new branch] next -> refs/foo/next\n * [new branch] master -> origin/master\n = [up to date] next -> origin/next\n\nI haven't thought long enough to be convinced there aren't any bad side\neffects, though. I guess if you had non-traditional configured refspecs,\nyou might be surprised to see them applied in this case. Something like:\n\n # we usually fetch the remote's master straight into our production\n # branch for deployment\n $ git config remote.origin.fetch refs/heads/master:refs/heads/production\n\n # but today let's demo it first\n $ git fetch origin master:demo\n\nI don't know if people are actually using refspecs in that way. But we\ndo need to consider that this is a potentially destructive change.\n\nAnyway, here is the patch.\n\n---\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex 817dd6b..d9e44c7 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -119,6 +119,9 @@ static struct ref *get_ref_map(struct transport *transport,\n \tconst struct ref *remote_refs = transport_get_remote_refs(transport);\n \n \tif (ref_count || tags == TAGS_SET) {\n+\t\tstruct ref *tracking_refs = NULL;\n+\t\tstruct ref **tracking_tail = &tracking_refs;\n+\n \t\tfor (i = 0; i < ref_count; i++) {\n \t\t\tget_fetch_map(remote_refs, &refs[i], &tail, 0);\n \t\t\tif (refs[i].dst && refs[i].dst[0])\n@@ -129,6 +132,12 @@ static struct ref *get_ref_map(struct transport *transport,\n \t\t\trm->merge = 1;\n \t\tif (tags == TAGS_SET)\n \t\t\tget_fetch_map(remote_refs, tag_refspec, &tail, 0);\n+\n+\t\tfor (i = 0; i < transport->remote->fetch_refspec_nr; i++)\n+\t\t\tget_fetch_map(ref_map, &transport->remote->fetch[i],\n+\t\t\t\t\t&tracking_tail, 0);\n+\t\t*tail = tracking_refs;\n+\t\ttail = tracking_tail;\n \t} else {\n \t\t/* Use the defaults */\n \t\tstruct remote *remote = transport->remote;\n"},{"id":"121922","messageId":"20090827213924.GE4399@coredump.intra.peff.net","threadId":"20755","inReplyTo":"7viqg9q7gx.fsf@alter.siamese.dyndns.org","subject":"Re: Question regarding git fetch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-27T21:39:24Z","receivedAt":"2009-08-27T21:39:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 27, 2009 at 02:20:46PM -0700, Junio C Hamano wrote:\n\n> I think it is reasonable, in 1.7.0, to change \"git fetch\" with command\n> line refspacs that lack colon (i.e. saying \"fetch this ref\" without saying\n> \"and store it here\") so that it updates remote tracking refs if and only\n> if an appropriate remote.$remote.fetch is configured to do so. E.g. when\n> I fetch from Eric for git-svn updates with\n> \n> \t$ git pull git-svn master\n> \n> because I do have\n> \n> \t[remote \"git-svn\"]\n> url = git://yhbt.net/git-svn\n> fetch = +refs/heads/*:refs/remotes/git-svn/*\n\nDoes the colon really matter? That is, should\n\n $ git fetch git-svn master\n\nstore a tracking ref, but\n\n $ git fetch git-svn master:foo\n\nnot? In both cases, git has learned during the course of an operation\nwhat the new value of the tracking ref could be, so why not store it?\n\nThe obstacle I see is that somebody may be using configured refspecs as\nsomething other than a tracking ref. That is, they care about _when_\nthose refs on the RHS of the refspec are updated, and are not treating\nthem just as a cache of what the remote side has.\n\n> On the other hand, if my refspecs for \"git svn\" _were_ like this:\n> \n> \t[remote \"git-svn\"]\n> \t\turl = git://yhbt.net/git-svn\n> fetch = +refs/heads/master:refs/remotes/git-svn/master\n> \n> then I would _not_ want this:\n> \n> \t$ git fetch git-svn dev\n> \n> to create a new tracking branch refs/remotes/git-svn/dev.\n\nOf course not. It's not in your configured refspec, so you have\nrequested no such tracking ref. I think we would have to limit ourselves\nto how the tracking refs are defined in the refspecs. Otherwise how\nwould we know to put the tracking ref in refs/remotes/git-svn and not\nsome other place?\n\nSo I think it is a simple matter of applying the configured refspecs\nwith information we happen to have gotten during the course of a\nsomewhat-related operation.\n\n-Peff\n"},{"id":"121923","messageId":"7v7hwpors9.fsf@alter.siamese.dyndns.org","threadId":"20755","inReplyTo":"20090827213426.GD4399@coredump.intra.peff.net","subject":"Re: Question regarding git fetch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-27T21:44:54Z","receivedAt":"2009-08-27T21:44:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> # we usually fetch the remote's master straight into our production\n> # branch for deployment\n> $ git config remote.origin.fetch refs/heads/master:refs/heads/production\n>\n> # but today let's demo it first\n> $ git fetch origin master:demo\n\nI think this is a good example that any change results from this\ndiscussion should apply _only_ to cases where command line refspecs lack\ncolon (i.e. used to mean \"do not store this anywhere but in FETCH_HEAD\").\n"},{"id":"121925","messageId":"20090827215007.GA6231@coredump.intra.peff.net","threadId":"20755","inReplyTo":"7v7hwpors9.fsf@alter.siamese.dyndns.org","subject":"Re: Question regarding git fetch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-27T21:50:07Z","receivedAt":"2009-08-27T21:50:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 27, 2009 at 02:44:54PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > # we usually fetch the remote's master straight into our production\n> > # branch for deployment\n> > $ git config remote.origin.fetch refs/heads/master:refs/heads/production\n> >\n> > # but today let's demo it first\n> > $ git fetch origin master:demo\n> \n> I think this is a good example that any change results from this\n> discussion should apply _only_ to cases where command line refspecs lack\n> colon (i.e. used to mean \"do not store this anywhere but in FETCH_HEAD\").\n\nI don't think the colon is the issue. Consider the same situation, but I\nsay:\n\n # but today let's demo it first\n $ git fetch origin master\n $ git checkout -b demo FETCH_HEAD\n\nI'm still screwed. The issue is that you consider your configured\nrefspec destinations to be precious, and not merely a cache for what's\nhappening on the remote side.\n\n-Peff\n"},{"id":"121927","messageId":"20090827215305.GA6348@coredump.intra.peff.net","threadId":"20755","inReplyTo":"20090827215007.GA6231@coredump.intra.peff.net","subject":"Re: Question regarding git fetch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-27T21:53:05Z","receivedAt":"2009-08-27T21:53:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 27, 2009 at 05:50:07PM -0400, Jeff King wrote:\n\n> > I think this is a good example that any change results from this\n> > discussion should apply _only_ to cases where command line refspecs lack\n> > colon (i.e. used to mean \"do not store this anywhere but in FETCH_HEAD\").\n> \n> I don't think the colon is the issue. Consider the same situation, but I\n> say:\n> \n> # but today let's demo it first\n> $ git fetch origin master\n> $ git checkout -b demo FETCH_HEAD\n> \n> I'm still screwed. The issue is that you consider your configured\n> refspec destinations to be precious, and not merely a cache for what's\n> happening on the remote side.\n\nWhich, btw, led me to consider whether there are heuristics for deciding\nwhen a fetch refspec means one thing and not the other. I don't think\nthere are reliable ones (probably the default configured\nrefs/remotes/$remotename/* would not yield false positives, but I think\nlimiting to that would yield false negatives). So maybe this is\nsomething that should be configurable, disabled by default for now, and\nmaybe enabled by default in the future (v1.7.0?).\n\n-Peff\n"},{"id":"121929","messageId":"32541b130908271512h255834adl5a606054f6ab20e4@mail.gmail.com","threadId":"20755","inReplyTo":"20090827215007.GA6231@coredump.intra.peff.net","subject":"Re: Question regarding git fetch","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-08-27T22:12:50Z","receivedAt":"2009-08-27T22:12:50Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, Aug 27, 2009 at 9:50 PM, Jeff King wrote:\n> I don't think the colon is the issue. Consider the same situation, but I\n> say:\n>\n>  # but today let's demo it first\n>  $ git fetch origin master\n>  $ git checkout -b demo FETCH_HEAD\n>\n> I'm still screwed. The issue is that you consider your configured\n> refspec destinations to be precious, and not merely a cache for what's\n> happening on the remote side.\n\nIs the \"precious remote ref\" concept perhaps an imaginary one?\n\nAfter all, if I *really* care about the prior state of the remote, I\ncan just make it a remote branch. And if (as often happens) I just\nwant to know what's new in that ref since last time I merged, it's\nsimply\n\n git log master..origin/master\n\nThis works even if master has extra commits vs. origin/master, since\nthe double-dot invokes git-merge-base.\n\nI think this might be a much more common than the case where people\nactually want to see \"what's changed since last time I checked what's\nchanged.\" At least, the latter question has never been very\ninteresting to me, or if it is, it's easy for me to tell by eye.\n\nAvery\n"},{"id":"121930","messageId":"20090827221631.GA7058@coredump.intra.peff.net","threadId":"20755","inReplyTo":"32541b130908271512h255834adl5a606054f6ab20e4@mail.gmail.com","subject":"Re: Question regarding git fetch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-27T22:16:31Z","receivedAt":"2009-08-27T22:16:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 27, 2009 at 10:12:50PM +0000, Avery Pennarun wrote:\n\n> > I'm still screwed. The issue is that you consider your configured\n> > refspec destinations to be precious, and not merely a cache for what's\n> > happening on the remote side.\n> \n> Is the \"precious remote ref\" concept perhaps an imaginary one?\n\nMaybe. I certainly don't use it. But I am trying to consider corner\ncases where somebody who _isn't_ me is going to get screwed by a\nchange we make.\n\n> After all, if I *really* care about the prior state of the remote, I\n> can just make it a remote branch. And if (as often happens) I just\n\nDo you mean \"local branch\" here?\n\n> want to know what's new in that ref since last time I merged, it's\n> simply\n> \n> git log master..origin/master\n> \n> This works even if master has extra commits vs. origin/master, since\n> the double-dot invokes git-merge-base.\n\nWell, \"..\" doesn't use git-merge-base. But yes, I actually do this,\nexcept I do:\n\n gitk master...origin/master\n\n-Peff\n"},{"id":"121933","messageId":"32541b130908271524o163809alc2f6926d110667b3@mail.gmail.com","threadId":"20755","inReplyTo":"20090827221631.GA7058@coredump.intra.peff.net","subject":"Re: Question regarding git fetch","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-08-27T22:24:34Z","receivedAt":"2009-08-27T22:24:34Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, Aug 27, 2009 at 10:16 PM, Jeff King wrote:\n> On Thu, Aug 27, 2009 at 10:12:50PM +0000, Avery Pennarun wrote:\n>> After all, if I *really* care about the prior state of the remote, I\n>> can just make it a remote branch.  And if (as often happens) I just\n>\n> Do you mean \"local branch\" here?\n\nYes.\n\n>> want to know what's new in that ref since last time I merged, it's\n>> simply\n>>\n>>    git log master..origin/master\n>>\n>> This works even if master has extra commits vs. origin/master, since\n>> the double-dot invokes git-merge-base.\n>\n> Well, \"..\" doesn't use git-merge-base. But yes, I actually do this,\n> except I do:\n>\n>  gitk master...origin/master\n\nSorry, not my day for accuracy, it seems. I use both, and I should\nhave remembered that the triple-dot is the one that worries about the\nmerge-base.\n\nHave fun,\n\nAvery\n"},{"id":"122000","messageId":"1251465852993-3534609.post@n2.nabble.com","threadId":"20755","inReplyTo":"1251387045053-3527289.post@n2.nabble.com","subject":"Re: Question regarding git fetch","fromName":"Tom Lambda","fromEmail":"tom.lambda@gmail.com","sentAt":"2009-08-28T13:24:12Z","receivedAt":"2009-08-28T13:24:12Z","isPatch":false,"sender":{"key":"tom.lambda@gmail.com","avatar":null},"body":"\nThank you all for your answers and the interesting following discussion.\n\n>From a user perspective (I do not know how git works internally), the\napproach proposed by Juno looks very intuitive to me. Now I understand there\nare other cases and users to take into account, which make the\nimplementation complex. I hope this will be part of git 1.7.0.\n\n--Tom\n\n-- \nView this message in context: http://n2.nabble.com/Question-regarding-git-fetch-tp3527289p3534609.html\nSent from the git mailing list archive at Nabble.com.\n"}]}