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

From: Nicolas Pitre <nico@fluxnic.net>
Date: Jan 11, 2010, 02:01 UTC
Message-ID: <alpine.LFD.2.00.1001102055070.10143@xanadu.home>
In-Reply-To: <ee2a733e1001101736p2f395de6ka05044fe7cca624d@mail.gmail.com>

On Sun, 10 Jan 2010, Leo Razoumov wrote:

Show 18 quoted lines

> 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.

You still don't answer my question though. Again, _why_ do you need to know about remote commit availability without fetching them?

> 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??

Pushing involves resource usage on your own machine while pulling/fetching involves the remote machine. Your choice to "waste" CPU cycles on your own machine is not the same as having anybody do the same on a central server.

Nicolas