On Sun, 10 Jan 2010, Leo Razoumov wrote: > On 2010-01-10, Nicolas Pitre <nico@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html