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

On Mon, 3 Mar 2008, Paolo Ciarrocchi wrote:

On Mon, Mar 3, 2008 at 5:29 PM, Nicolas Pitre [off-list ref] wrote:

quoted

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.

Very nice, I didn't find in the documentation.
I'll read again the documents and if needed, I'll propose some new text.

I found the reflog notation burried in git-rev-parse.txt.  Maybe some 
example usage could be added to more frequently used commands.

quoted

This notation is a bit obnoxious and the re were suggestions about
addind the equivalent origin/master@{1..} but that didn't materialize
yet.

Mybe it's just me but wouldn't be very nice to have a simple command
to look at what data have been used for updating the currente branch?
i.e.
git fetch
git diff -- fetch (which is an alias of git diff
origin/master@{1}..origin/master)

You still think in terms of "data used to update a branch".  There is no 
such direct relation between the fetched data (objects) and the updated 
branch heads.  What you do when listing the commits found between 
origin/master@{1} and origin/master@{0} (or simply origin/master wich 
is equivalent to origin/master@{0}) does not necessarily correspond to 
the data you received during the fetch.  For example, it is possible 
that half of those commits were already part of another branch in your 
repository, hence the fetch operation won't download them again.  Still, 
the origin/master branch now has acquired them all which wasn't the case 
before.  To really _see_ the actually received data during a fetch 
requires internal Git knowledge and digging in the pack directory -- 
there is no (need for any) UI for that.

And how about a repository which have reflogs disabled?

Well, just re-enable them.  ;-)

Since they're on by default, if you turned them off then you surely know 
what you're doing and why.


Nicolas