Re: git fetch: where are the downloaded objects stored?

> On Mon, 3 Mar 2008, Paolo Ciarrocchi wrote:
>
> > On Mon, Mar 3, 2008 at 4:21 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> > > "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
> > >
> > > > "A merge is always between the current HEAD and one or more remote
> > > > branch heads"
> > >
> > > I think this is just wrong. Would this be correct?
> >
> > Sounds better than the original document,
> > however I'm still having some problems in visualizing what happens
> > when I type "git fetch" followed by "git merge".
> >
> > > diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
> > > index 0c9ad7f..e46dea1 100644
> > > --- a/Documentation/git-merge.txt
> > > +++ b/Documentation/git-merge.txt
> > > @@ -68,7 +68,7 @@ HOW MERGE WORKS
> > >  ---------------
> > >
> > >  A merge is always between the current `HEAD` and one or more
> > > -remote branch heads, and the index file must exactly match the
> > > +branch heads (remote or local), and the index file must exactly match the
>
> Yes, this is much better.  A merge may occur with any other branches,
> local or remote, or even with a tag, or any other random commit
> reference for that matter.

> > When I run the command git fetch the objects are downloaded from the remote
> > branch and locally stored in the objects database.
> > Both the working tree and index are not touched by this operation.
> > Is this correct?
>
> Yes.  The fetch operation will figure out, with the remote machine, what
> is the set of objects that you already have and the set that you don't
> have so the remote machine will create and send you a pack of only the
> objects you're missing.  And the remote machine will also reduce it to
> deltas against objects that you already have when possible so the
> transferred pack is even smaller.  Once that pack has successfully been
> received, then the branch head for which this pack was requested will be
> updated to point at the latest commit for that branch.

> > How can I look to what I just downloaded?
> > Should I simply do a git diff?
>
> If you have reflog enabled (it should be by default) then a good thing
> to remember is the @{1} notation.  For example, if the fetch updated the
> origin/master branch, then origin/master@{1} is what your origin/master
> was before being updated.  To see the difference between the previous
> and the current state of origin/master, you can do:
>
>        git diff origin/master@{1}..origin/master
>
> Or to see the list of new commits:
>
>        git log origin/master@{1}..origin/master
>
>        git log -p origin/master@{1}..origin/master
>
> Etc.

> > Backing to the documentation, your proposal is:
> >  A merge is always between the current `HEAD` and one or more
> >  branch heads (remote or local), and the index file must exactly match the
> >
> > In case of a git fetch + git merge the merge is between the current
> > `HEAD` and the
> > downloaded objects. Is correct to define it `branch heads`?
>
> A merge doesn't happen between a branch and some objects.  Please don't
> see it that way.  Objects are at a lower level of abstraction.  What a
> fetch does is to make sure your version of a branch (say origin/master)
> matches the remote version of the branch "master" on server "origin".
> If you happen to already have all the needed objects already, then no
> objects will be transferred and only the branch reference will be
> updated.

> The merge operation really works at the commit graph level in order to
> jointwo or more branches together. Objects associated to the involved
> branches are only checked so to make sure the merging of the specified
> branches does not create a conflict (and to fix it otherwise).  If a
> merge conflict is fixed (either manually or automatically) then new
> objects corresponding to the modified files are locally created but the
> previously existing objects remain unchanged.  But object handling
> during a merge is really a low level thing.
>
> > Maybe (read it: for sure) I'm a bit confused by the git terminology
> > but I really feel that
> > other newbies are not easily understanding this process.
>
> I suggest you have a look at the following article:
>
>        http://eagain.net/articles/git-for-computer-scientists/
>
> It is really well written, with the right level of vulgarization to make
> the Git concept really obvious very quickly.