{"thread":{"id":"12457","subject":"git fetch: where are the downloaded objects stored?","startedAt":"2008-03-03T12:40:50Z","lastAt":"2008-03-03T19:43:56Z","messageCount":12,"participants":["Paolo Ciarrocchi","Matthieu Moy","Nicolas Pitre","Jakub Narebski","Sergei Organov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"70779","messageId":"4d8e3fd30803030440s7239c83cj8bf69401dd76bad@mail.gmail.com","threadId":"12457","inReplyTo":null,"subject":"git fetch: where are the downloaded objects stored?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-03-03T12:40:50Z","receivedAt":"2008-03-03T12:40:50Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"Hi all,\nI'm thinking about writing some documentation including diagrams about\nthe common git operation like pull, fetch, merge and so on in order\nto give a \"visual\" learning procedure about:\n- local and remote branches\n- index\n- checkout dir\n-\n"},{"id":"70782","messageId":"vpqskz82bm3.fsf@bauges.imag.fr","threadId":"12457","inReplyTo":"4d8e3fd30803030440s7239c83cj8bf69401dd76bad@mail.gmail.com","subject":"Re: git fetch: where are the downloaded objects stored?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-03-03T13:14:28Z","receivedAt":"2008-03-03T13:14:28Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Paolo Ciarrocchi\" <paolo.ciarrocchi@gmail.com> writes:\n\n> What is still not clear to me is where git is storing\n> the objects downloaded during a git fetch operation.\n\ngit fetch downloads the objects to the object database, i.e.\n.git/objects/, usualy as a pack.\n\nNow, just \"having\" the objects locally doesn't change much, an object\nstarts being really interesting if you have a reference (typically, a\nbranch) pointing to it. \"git fetch\" will update the remote references\n(for example, origin/master), but won't touch the working tree, and\nwon't do any merge, fast-forward or not, to a local branch. So, most\nlikely, \"git fetch\" will be followed by either a merge or a rebase.\n\n-- \nMatthieu\n"},{"id":"70785","messageId":"4d8e3fd30803030633nf6266d5qab0df4ba4c539e0b@mail.gmail.com","threadId":"12457","inReplyTo":"vpqskz82bm3.fsf@bauges.imag.fr","subject":"Re: git fetch: where are the downloaded objects stored?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-03-03T14:33:23Z","receivedAt":"2008-03-03T14:33:23Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On Mon, Mar 3, 2008 at 2:14 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:\n> \"Paolo Ciarrocchi\" <paolo.ciarrocchi@gmail.com> writes:\n>\n>  > What is still not clear to me is where git is storing\n>  > the objects downloaded during a git fetch operation.\n>\n>  git fetch downloads the objects to the object database, i.e.\n>  .git/objects/, usualy as a pack.\n\nOk, thanks.\n\n>  Now, just \"having\" the objects locally doesn't change much, an object\n>  starts being really interesting if you have a reference (typically, a\n>  branch) pointing to it. \"git fetch\" will update the remote references\n>  (for example, origin/master), but won't touch the working tree, and\n>  won't do any merge, fast-forward or not, to a local branch. So, most\n>  likely, \"git fetch\" will be followed by either a merge or a rebase.\n\nYes, your explanation perfectly match my understanding.\n\nI was, and I'm still, confused by the following sentence in the git merge\ndocumentation:\n\"A merge is always between the current HEAD and one or more remote\nbranch heads\"\n\nIf I think to the following scenario:\n\n git fetch\n git diff (to look at what I downloaded via git fetch)\n gir merge\n\nI don't see a merge between the current HEAD and a _remote_ branch.\n\nCiao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"70791","messageId":"vpq63w325px.fsf@bauges.imag.fr","threadId":"12457","inReplyTo":"4d8e3fd30803030633nf6266d5qab0df4ba4c539e0b@mail.gmail.com","subject":"Re: git fetch: where are the downloaded objects stored?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-03-03T15:21:46Z","receivedAt":"2008-03-03T15:21:46Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Paolo Ciarrocchi\" <paolo.ciarrocchi@gmail.com> writes:\n\n> \"A merge is always between the current HEAD and one or more remote\n> branch heads\"\n\nI think this is just wrong. Would this be correct?\n\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex 0c9ad7f..e46dea1 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -68,7 +68,7 @@ HOW MERGE WORKS\n ---------------\n \n A merge is always between the current `HEAD` and one or more\n-remote branch heads, and the index file must exactly match the\n+branch heads (remote or local), and the index file must exactly match the\n tree of `HEAD` commit (i.e. the contents of the last commit) when\n it happens.  In other words, `git-diff --cached HEAD` must\n report no changes.\n\n\n-- \nMatthieu\n"},{"id":"70792","messageId":"4d8e3fd30803030740i18ca8db1y681b4f10797f8c83@mail.gmail.com","threadId":"12457","inReplyTo":"vpq63w325px.fsf@bauges.imag.fr","subject":"Re: git fetch: where are the downloaded objects stored?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-03-03T15:40:11Z","receivedAt":"2008-03-03T15:40:11Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On Mon, Mar 3, 2008 at 4:21 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:\n> \"Paolo Ciarrocchi\" <paolo.ciarrocchi@gmail.com> writes:\n>\n> > \"A merge is always between the current HEAD and one or more remote\n> > branch heads\"\n>\n> I think this is just wrong. Would this be correct?\n\nSounds better than the original document,\nhowever I'm still having some problems in visualizing what happens\nwhen I type \"git fetch\" followed by \"git merge\".\n\n> diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\n> index 0c9ad7f..e46dea1 100644\n> --- a/Documentation/git-merge.txt\n> +++ b/Documentation/git-merge.txt\n> @@ -68,7 +68,7 @@ HOW MERGE WORKS\n>  ---------------\n>\n>  A merge is always between the current `HEAD` and one or more\n> -remote branch heads, and the index file must exactly match the\n> +branch heads (remote or local), and the index file must exactly match the\n\nWhen I run the command git fetch the objects are downloaded from the remote\nbranch and locally stored in the objects database.\nBoth the working tree and index are not touched by this operation.\nIs this correct?\n\nHow can I look to what I just downloaded?\nShould I simply do a git diff?\n\nBacking to the documentation, your proposal is:\n A merge is always between the current `HEAD` and one or more\n branch heads (remote or local), and the index file must exactly match the\n\nIn case of a git fetch + git merge the merge is between the current\n`HEAD` and the\ndownloaded objects. Is correct to define it `branch heads`?\n\nMaybe (read it: for sure) I'm a bit confused by the git terminology\nbut I really feel that\nother newbies are not easily understanding this process.\n\nThanks.\n\nciao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"70796","messageId":"alpine.LFD.1.00.0803031057140.2899@xanadu.home","threadId":"12457","inReplyTo":"4d8e3fd30803030740i18ca8db1y681b4f10797f8c83@mail.gmail.com","subject":"Re: git fetch: where are the downloaded objects stored?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-03-03T16:29:54Z","receivedAt":"2008-03-03T16:29:54Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 3 Mar 2008, Paolo Ciarrocchi wrote:\n\n> On Mon, Mar 3, 2008 at 4:21 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:\n> > \"Paolo Ciarrocchi\" <paolo.ciarrocchi@gmail.com> writes:\n> >\n> > > \"A merge is always between the current HEAD and one or more remote\n> > > branch heads\"\n> >\n> > I think this is just wrong. Would this be correct?\n> \n> Sounds better than the original document,\n> however I'm still having some problems in visualizing what happens\n> when I type \"git fetch\" followed by \"git merge\".\n> \n> > diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\n> > index 0c9ad7f..e46dea1 100644\n> > --- a/Documentation/git-merge.txt\n> > +++ b/Documentation/git-merge.txt\n> > @@ -68,7 +68,7 @@ HOW MERGE WORKS\n> >  ---------------\n> >\n> >  A merge is always between the current `HEAD` and one or more\n> > -remote branch heads, and the index file must exactly match the\n> > +branch heads (remote or local), and the index file must exactly match the\n\nYes, this is much better.  A merge may occur with any other branches, \nlocal or remote, or even with a tag, or any other random commit \nreference for that matter.\n\n> When I run the command git fetch the objects are downloaded from the remote\n> branch and locally stored in the objects database.\n> Both the working tree and index are not touched by this operation.\n> Is this correct?\n\nYes.  The fetch operation will figure out, with the remote machine, what \nis the set of objects that you already have and the set that you don't \nhave so the remote machine will create and send you a pack of only the \nobjects you're missing.  And the remote machine will also reduce it to \ndeltas against objects that you already have when possible so the \ntransferred pack is even smaller.  Once that pack has successfully been \nreceived, then the branch head for which this pack was requested will be \nupdated to point at the latest commit for that branch.\n\n> How can I look to what I just downloaded?\n> Should I simply do a git diff?\n\nIf you have reflog enabled (it should be by default) then a good thing \nto remember is the @{1} notation.  For example, if the fetch updated the \norigin/master branch, then origin/master@{1} is what your origin/master \nwas before being updated.  To see the difference between the previous \nand the current state of origin/master, you can do:\n\n\tgit diff origin/master@{1}..origin/master\n\nOr to see the list of new commits:\n\n\tgit log origin/master@{1}..origin/master\n\n\tgit log -p origin/master@{1}..origin/master\n\nEtc.\n\nThis notation is a bit obnoxious and the re were suggestions about \naddind the equivalent origin/master@{1..} but that didn't materialize \nyet.\n\n> Backing to the documentation, your proposal is:\n>  A merge is always between the current `HEAD` and one or more\n>  branch heads (remote or local), and the index file must exactly match the\n> \n> In case of a git fetch + git merge the merge is between the current\n> `HEAD` and the\n> downloaded objects. Is correct to define it `branch heads`?\n\nA merge doesn't happen between a branch and some objects.  Please don't \nsee it that way.  Objects are at a lower level of abstraction.  What a \nfetch does is to make sure your version of a branch (say origin/master) \nmatches the remote version of the branch \"master\" on server \"origin\".  \nIf you happen to already have all the needed objects already, then no \nobjects will be transferred and only the branch reference will be \nupdated.\n\nThe merge operation really works at the commit graph level in order to \njointwo or more branches together. Objects associated to the involved \nbranches are only checked so to make sure the merging of the specified \nbranches does not create a conflict (and to fix it otherwise).  If a \nmerge conflict is fixed (either manually or automatically) then new \nobjects corresponding to the modified files are locally created but the \npreviously existing objects remain unchanged.  But object handling \nduring a merge is really a low level thing.\n\n> Maybe (read it: for sure) I'm a bit confused by the git terminology\n> but I really feel that\n> other newbies are not easily understanding this process.\n\nI suggest you have a look at the following article:\n\n\thttp://eagain.net/articles/git-for-computer-scientists/ \n\nIt is really well written, with the right level of vulgarization to make \nthe Git concept really obvious very quickly.\n\n\nNicolas\n"},{"id":"70799","messageId":"4d8e3fd30803030851n498953c4u7e7a109b91b9da11@mail.gmail.com","threadId":"12457","inReplyTo":"alpine.LFD.1.00.0803031057140.2899@xanadu.home","subject":"Re: git fetch: where are the downloaded objects stored?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-03-03T16:51:03Z","receivedAt":"2008-03-03T16:51:03Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On Mon, Mar 3, 2008 at 5:29 PM, Nicolas Pitre <nico@cam.org> wrote:\n> On Mon, 3 Mar 2008, Paolo Ciarrocchi wrote:\n>\n> > On Mon, Mar 3, 2008 at 4:21 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:\n> > > \"Paolo Ciarrocchi\" <paolo.ciarrocchi@gmail.com> writes:\n> > >\n> > > > \"A merge is always between the current HEAD and one or more remote\n> > > > branch heads\"\n> > >\n> > > I think this is just wrong. Would this be correct?\n> >\n> > Sounds better than the original document,\n> > however I'm still having some problems in visualizing what happens\n> > when I type \"git fetch\" followed by \"git merge\".\n> >\n> > > diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\n> > > index 0c9ad7f..e46dea1 100644\n> > > --- a/Documentation/git-merge.txt\n> > > +++ b/Documentation/git-merge.txt\n> > > @@ -68,7 +68,7 @@ HOW MERGE WORKS\n> > >  ---------------\n> > >\n> > >  A merge is always between the current `HEAD` and one or more\n> > > -remote branch heads, and the index file must exactly match the\n> > > +branch heads (remote or local), and the index file must exactly match the\n>\n> Yes, this is much better.  A merge may occur with any other branches,\n> local or remote, or even with a tag, or any other random commit\n> reference for that matter.\n\nIt's probably a good idea to mention the tag as well.\nSomething like:\n  A merge is always between the current `HEAD` and one or more\n  branch heads (remote or local) or tags, and the index file must\nexactly match the\n\n> > When I run the command git fetch the objects are downloaded from the remote\n> > branch and locally stored in the objects database.\n> > Both the working tree and index are not touched by this operation.\n> > Is this correct?\n>\n> Yes.  The fetch operation will figure out, with the remote machine, what\n> is the set of objects that you already have and the set that you don't\n> have so the remote machine will create and send you a pack of only the\n> objects you're missing.  And the remote machine will also reduce it to\n> deltas against objects that you already have when possible so the\n> transferred pack is even smaller.  Once that pack has successfully been\n> received, then the branch head for which this pack was requested will be\n> updated to point at the latest commit for that branch.\n\nOK, that's now completely clear and understood.\n\n> > How can I look to what I just downloaded?\n> > Should I simply do a git diff?\n>\n> If you have reflog enabled (it should be by default) then a good thing\n> to remember is the @{1} notation.  For example, if the fetch updated the\n> origin/master branch, then origin/master@{1} is what your origin/master\n> was before being updated.  To see the difference between the previous\n> and the current state of origin/master, you can do:\n>\n>        git diff origin/master@{1}..origin/master\n>\n> Or to see the list of new commits:\n>\n>        git log origin/master@{1}..origin/master\n>\n>        git log -p origin/master@{1}..origin/master\n>\n> Etc.\n\nVery nice, I didn't find in the documentation.\nI'll read again the documents and if needed, I'll propose some new text.\n\n> This notation is a bit obnoxious and the re were suggestions about\n> addind the equivalent origin/master@{1..} but that didn't materialize\n> yet.\n\nMybe it's just me but wouldn't be very nice to have a simple command\nto look at what data have been used for updating the currente branch?\ni.e.\ngit fetch\ngit diff -- fetch (which is an alias of git diff\norigin/master@{1}..origin/master)\n\nAnd how about a repository which have reflogs disabled?\n\n> > Backing to the documentation, your proposal is:\n> >  A merge is always between the current `HEAD` and one or more\n> >  branch heads (remote or local), and the index file must exactly match the\n> >\n> > In case of a git fetch + git merge the merge is between the current\n> > `HEAD` and the\n> > downloaded objects. Is correct to define it `branch heads`?\n>\n> A merge doesn't happen between a branch and some objects.  Please don't\n> see it that way.  Objects are at a lower level of abstraction.  What a\n> fetch does is to make sure your version of a branch (say origin/master)\n> matches the remote version of the branch \"master\" on server \"origin\".\n> If you happen to already have all the needed objects already, then no\n> objects will be transferred and only the branch reference will be\n> updated.\n\nOK.\n\n> The merge operation really works at the commit graph level in order to\n> jointwo or more branches together. Objects associated to the involved\n> branches are only checked so to make sure the merging of the specified\n> branches does not create a conflict (and to fix it otherwise).  If a\n> merge conflict is fixed (either manually or automatically) then new\n> objects corresponding to the modified files are locally created but the\n> previously existing objects remain unchanged.  But object handling\n> during a merge is really a low level thing.\n>\n> > Maybe (read it: for sure) I'm a bit confused by the git terminology\n> > but I really feel that\n> > other newbies are not easily understanding this process.\n>\n> I suggest you have a look at the following article:\n>\n>        http://eagain.net/articles/git-for-computer-scientists/\n>\n> It is really well written, with the right level of vulgarization to make\n> the Git concept really obvious very quickly.\n\nI read it, very intersting.\n\nThank you Nicolas.\n\nCiao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"70800","messageId":"m3tzjnivzp.fsf@localhost.localdomain","threadId":"12457","inReplyTo":"4d8e3fd30803030633nf6266d5qab0df4ba4c539e0b@mail.gmail.com","subject":"Re: git fetch: where are the downloaded objects stored?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-03T16:59:45Z","receivedAt":"2008-03-03T16:59:45Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Paolo Ciarrocchi\" <paolo.ciarrocchi@gmail.com> writes:\n\n> On Mon, Mar 3, 2008 at 2:14 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:\n>> \"Paolo Ciarrocchi\" <paolo.ciarrocchi@gmail.com> writes:\n>>\n>>> What is still not clear to me is where git is storing\n>>> the objects downloaded during a git fetch operation.\n>>\n>>  git fetch downloads the objects to the object database, i.e.\n>>  .git/objects/, usualy as a pack.\n\nDownloading as individual objects (\"exploded\") or as a pack depends on\nfetch.unpackLimit configuration.\n \n>>  Now, just \"having\" the objects locally doesn't change much, an object\n>>  starts being really interesting if you have a reference (typically, a\n>>  branch) pointing to it. \"git fetch\" will update the remote references\n>>  (for example, origin/master), but won't touch the working tree, and\n>>  won't do any merge, fast-forward or not, to a local branch. So, most\n>>  likely, \"git fetch\" will be followed by either a merge or a rebase.\n\nWhat is important git-fetch _always_ stores what it fetched in\n$GIT_DIR/FETCH_HEAD.\n\nThen depending on configuration and command line options it updates\nappropriate remote-tracking branches.  For example if you do one-shot\n\"git pull <remote> <branch>\" git would not store fetched refs (heads)\nin tracking branches: see git-fetch(1).\n \n> Yes, your explanation perfectly match my understanding.\n> \n> I was, and I'm still, confused by the following sentence in the git merge\n> documentation:\n>\n>   \"A merge is always between the current HEAD and one or more\n>    remote branch heads\"\n\nThis \"remote\" is here invalid. Merge can merge in any ref, not only\nremote-tracking branches.  \"git merge <branch>\" would merge given\nbranch into current (HEAD) branch:\n\nBefore:\n\n  1---2---3---4---5---6---7   <-- master <-- HEAD\n               \\\n                \\-A---B       <-- devel (or origin/master)\n\nAfter \"git merge devel\"\n\n  1---2---3---4---5---6---7---M   <-- master <-- HEAD\n               \\             /\n                \\-A---B-----/     <-- devel (or origin/master)\n\nwhere 'M' is merge (multi-parent) commit.\n\n> If I think to the following scenario:\n> \n>  git fetch\n>  git diff (to look at what I downloaded via git fetch)\n\nBecause you download _series_ of commits \"git log\" would be usually\nmore useful than \"git diff\".\n\nYou can use <branch>@{1} for position of branch before fetch, or even\nORIG_HEAD for position of HEAD branch before fetch (or pull).\n\n>  git merge\n\nI'm not sure if \"git merge\" without branch specified would work.\n\"git pull\" should, so perhaps \"git merge\" would too.\n\n\"git pull\" would merge 'first' branch, or branch specified in\nbranch/remote configuration.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"70809","messageId":"87hcfnu3nu.fsf@osv.gnss.ru","threadId":"12457","inReplyTo":"4d8e3fd30803030851n498953c4u7e7a109b91b9da11@mail.gmail.com","subject":"Re: git fetch: where are the downloaded objects stored?","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2008-03-03T17:18:45Z","receivedAt":"2008-03-03T17:18:45Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"\"Paolo Ciarrocchi\" <paolo.ciarrocchi@gmail.com> writes:\n> On Mon, Mar 3, 2008 at 5:29 PM, Nicolas Pitre <nico@cam.org> wrote:\n>> On Mon, 3 Mar 2008, Paolo Ciarrocchi wrote:\n>>\n>> > On Mon, Mar 3, 2008 at 4:21 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:\n\n[...]\n\n>> > How can I look to what I just downloaded?\n>> > Should I simply do a git diff?\n>>\n>> If you have reflog enabled (it should be by default) then a good thing\n>> to remember is the @{1} notation.  For example, if the fetch updated the\n>> origin/master branch, then origin/master@{1} is what your origin/master\n>> was before being updated.  To see the difference between the previous\n>> and the current state of origin/master, you can do:\n>>\n>>        git diff origin/master@{1}..origin/master\n>>\n>> Or to see the list of new commits:\n>>\n>>        git log origin/master@{1}..origin/master\n>>\n>>        git log -p origin/master@{1}..origin/master\n>>\n>> Etc.\n>\n> Very nice, I didn't find in the documentation.\n> I'll read again the documents and if needed, I'll propose some new text.\n>\n>> This notation is a bit obnoxious and the re were suggestions about\n>> addind the equivalent origin/master@{1..} but that didn't materialize\n>> yet.\n>\n> Mybe it's just me but wouldn't be very nice to have a simple command\n> to look at what data have been used for updating the currente branch?\n> i.e.\n> git fetch\n> git diff -- fetch (which is an alias of git diff\n> origin/master@{1}..origin/master)\n>\n> And how about a repository which have reflogs disabled?\n\nI'm also a newbie, and I think you are on a wrong road. Usually it's not\nthat interesting what was downloaded. What is interesting is what is on\n'origin/master' that is still missing from 'master'. For this I think\nyou have:\n\n$ git log master..origin\n\n-- Sergei.\n"},{"id":"70814","messageId":"alpine.LFD.1.00.0803031307110.2899@xanadu.home","threadId":"12457","inReplyTo":"4d8e3fd30803030851n498953c4u7e7a109b91b9da11@mail.gmail.com","subject":"Re: git fetch: where are the downloaded objects stored?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-03-03T18:07:25Z","receivedAt":"2008-03-03T18:07:25Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 3 Mar 2008, Paolo Ciarrocchi wrote:\n\n> On Mon, Mar 3, 2008 at 5:29 PM, Nicolas Pitre <nico@cam.org> wrote:\n> > If you have reflog enabled (it should be by default) then a good thing\n> > to remember is the @{1} notation.  For example, if the fetch updated the\n> > origin/master branch, then origin/master@{1} is what your origin/master\n> > was before being updated.  To see the difference between the previous\n> > and the current state of origin/master, you can do:\n> >\n> >        git diff origin/master@{1}..origin/master\n> >\n> > Or to see the list of new commits:\n> >\n> >        git log origin/master@{1}..origin/master\n> >\n> >        git log -p origin/master@{1}..origin/master\n> >\n> > Etc.\n> \n> Very nice, I didn't find in the documentation.\n> I'll read again the documents and if needed, I'll propose some new text.\n\nI found the reflog notation burried in git-rev-parse.txt.  Maybe some \nexample usage could be added to more frequently used commands.\n\n> > This notation is a bit obnoxious and the re were suggestions about\n> > addind the equivalent origin/master@{1..} but that didn't materialize\n> > yet.\n> \n> Mybe it's just me but wouldn't be very nice to have a simple command\n> to look at what data have been used for updating the currente branch?\n> i.e.\n> git fetch\n> git diff -- fetch (which is an alias of git diff\n> origin/master@{1}..origin/master)\n\nYou still think in terms of \"data used to update a branch\".  There is no \nsuch direct relation between the fetched data (objects) and the updated \nbranch heads.  What you do when listing the commits found between \norigin/master@{1} and origin/master@{0} (or simply origin/master wich \nis equivalent to origin/master@{0}) does not necessarily correspond to \nthe data you received during the fetch.  For example, it is possible \nthat half of those commits were already part of another branch in your \nrepository, hence the fetch operation won't download them again.  Still, \nthe origin/master branch now has acquired them all which wasn't the case \nbefore.  To really _see_ the actually received data during a fetch \nrequires internal Git knowledge and digging in the pack directory -- \nthere is no (need for any) UI for that.\n\n> And how about a repository which have reflogs disabled?\n\nWell, just re-enable them.  ;-)\n\nSince they're on by default, if you turned them off then you surely know \nwhat you're doing and why.\n\n\nNicolas\n"},{"id":"70815","messageId":"alpine.LFD.1.00.0803031307380.2899@xanadu.home","threadId":"12457","inReplyTo":"87hcfnu3nu.fsf@osv.gnss.ru","subject":"Re: git fetch: where are the downloaded objects stored?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-03-03T18:14:57Z","receivedAt":"2008-03-03T18:14:57Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 3 Mar 2008, Sergei Organov wrote:\n> \"Paolo Ciarrocchi\" <paolo.ciarrocchi@gmail.com> writes:\n> > On Mon, Mar 3, 2008 at 5:29 PM, Nicolas Pitre <nico@cam.org> wrote:\n> >> If you have reflog enabled (it should be by default) then a good thing\n> >> to remember is the @{1} notation.  For example, if the fetch updated the\n> >> origin/master branch, then origin/master@{1} is what your origin/master\n> >> was before being updated.  To see the difference between the previous\n> >> and the current state of origin/master, you can do:\n> >>\n> >>        git diff origin/master@{1}..origin/master\n> >>\n> >> Or to see the list of new commits:\n> >>\n> >>        git log origin/master@{1}..origin/master\n> >>\n> >>        git log -p origin/master@{1}..origin/master\n> >>\n> >> Etc.\n> >\n> > Very nice, I didn't find in the documentation.\n> > I'll read again the documents and if needed, I'll propose some new text.\n> >\n> >> This notation is a bit obnoxious and the re were suggestions about\n> >> addind the equivalent origin/master@{1..} but that didn't materialize\n> >> yet.\n> >\n> > Mybe it's just me but wouldn't be very nice to have a simple command\n> > to look at what data have been used for updating the currente branch?\n> > i.e.\n> > git fetch\n> > git diff -- fetch (which is an alias of git diff\n> > origin/master@{1}..origin/master)\n> >\n> > And how about a repository which have reflogs disabled?\n> \n> I'm also a newbie, and I think you are on a wrong road. Usually it's not\n> that interesting what was downloaded. What is interesting is what is on\n> 'origin/master' that is still missing from 'master'. For this I think\n> you have:\n> \n> $ git log master..origin\n\nYes, this is indeed what most people should be doing.  But if you're \ntracking some remote repository with no intention of merging them in \nyour master branch by default, then it is often a nice thing to be able \nto see what has changed in those tracked branches since the last time \nyou fetched them.  This is where the reflog is really handy as it \nrecords all fetch points you did.\n\n\nNicolas\n"},{"id":"70833","messageId":"4d8e3fd30803031143n28371721jbe7eaf2f5e72dcb7@mail.gmail.com","threadId":"12457","inReplyTo":"alpine.LFD.1.00.0803031307110.2899@xanadu.home","subject":"Re: git fetch: where are the downloaded objects stored?","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-03-03T19:43:56Z","receivedAt":"2008-03-03T19:43:56Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On Mon, Mar 3, 2008 at 7:07 PM, Nicolas Pitre <nico@cam.org> wrote:\n[...]\n>  You still think in terms of \"data used to update a branch\".  There is no\n>  such direct relation between the fetched data (objects) and the updated\n>  branch heads.  What you do when listing the commits found between\n>  origin/master@{1} and origin/master@{0} (or simply origin/master wich\n>  is equivalent to origin/master@{0}) does not necessarily correspond to\n>  the data you received during the fetch.  For example, it is possible\n>  that half of those commits were already part of another branch in your\n>  repository, hence the fetch operation won't download them again.  Still,\n>  the origin/master branch now has acquired them all which wasn't the case\n>  before.  To really _see_ the actually received data during a fetch\n>  requires internal Git knowledge and digging in the pack directory --\n>  there is no (need for any) UI for that.\n\nYes, this time it was me using a completely wrong terminology.\nWhat I was looking for is what Sergei suggested.\n\n>  > And how about a repository which have reflogs disabled?\n>\n>  Well, just re-enable them.  ;-)\n>\n>  Since they're on by default, if you turned them off then you surely know\n>  what you're doing and why.\n\nOh well, very true!\n\nMaybe it's again just me which is still not used to git fetch (or my\nmental translation of °fetch° in Italian)\nbut I found easier to \"visualize\" the commang \"git remote update\"\nwhich in my setup alway means\n\"Fetch updates all the remotes in the repository\"\n\nAgain, thank you for your comments and for your time.\n\nCiao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"}]}