Re: How to check new commit availability without full fetch?

[Tay Ray Chuan <rctay89@gmail.com>]

Hi,

On Mon, Jan 11, 2010 at 9:36 AM, Leo Razoumov <slonik.az@gmail.com> wrote:
> On 2010-01-10, Nicolas Pitre <nico@fluxnic.net> wrote:
>> On Sun, 10 Jan 2010, Junio C Hamano wrote:
>>  >
>>  > A feel good factor is in play?  IOW, "I am short of time, so I won't be
>>  > able to really afford to 'git pull' and test the result of re-integrating
>>  > my changes to what happened on the other end.  If I can learn that there
>>  > is nothing happening over there, then I won't have to do anything and know
>>  > that I am up to date."
>>
>>
>> Just do a fetch then.  If the fetch progress display looks like if it is
>>  going to take a while then just interrupt it and go home.  If the fetch
>>  looks trivial then just merge it.  In any case, the "feel good" factor
>>  can't be that great by only knowing if the remote has changed or not.
>>
>
> Forced interruption is not such a good idea. I would favor a
> non-destructive way to monitor availability of remote commits.

By default, when you add a remote (with git remote add), git sets up
the fetch refspec in your config that looks like

  [remote "foo"]
    url = git://foo.com/git/foo.git
    fetch = refs/heads/*:refs/remotes/foo/*

That is to say, branches on the remote repo will be fetched into a
"safe" area, refs/remotes/foo/, away from the branches that you
normally work with in refs/heads/.

However, if you have a different config and you're fetching directly
into refs/heads/, then I can see why you would want to "peek" first
with --dry-run before fetching. Are you doing this?

> BTW, pull and push are in a way symmetric operations. Is there any
> deep reason why push supports --dry-run but pull/fetch does not??

It's more accurate to say that push and fetch are symmetric, because
pull is fetch with merge or rebase tacked on.

Even then, push and fetch are not _that_ symmetric...

-- 
Cheers,
Ray Chuan