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

[Nicolas Pitre <nico@fluxnic.net>]

On Mon, 11 Jan 2010, Leo Razoumov wrote:

> On 2010-01-10, Nicolas Pitre <nico@fluxnic.net> wrote:
> >
> > You still don't answer my question though.  Again, _why_ do you need to
> >  know about remote commit availability without fetching them?
> >
> 
> I use git to track almost all my data (code and otherwise) and spread
> it between several computers. I end up with several local repos having
> the same local branches. It happens once in a while that I fetch into
> a given remote/foo from several local foo branches from different
> machines and the operation fails. It happens because the commits have
> not been yet consistently distributed among the repos. To do the
> forensics and figure out who should update whom first I need a quick
> and non-destructive way to fetch dry-run.

There is probably something awkward about your setup then.

Normally you should have a remote description for any of the remote 
repositories you fetch from.  So if you have, say, remote machine_a with 
repo foo, machine_b with repo bar, and machine_c with repo baz, then 
fetching any of those will _only_ mirror locally the state of those 
remote repositories.  There is no ordering required as there can't be 
any conflicts in the mere fact of mirroring what the other guys have.  
That's what remote tracking branches are for: they follow the state of a 
remote repository and are never altered by local changes.  And you can 
have as many of those as you wish and they will never conflict with each 
other as each remote description is independent. And this is true 
whether or not the remote repository lives on the same machine (that 
would be a remote directory in that case).

And even if most if not all those remotes are actually copies of each 
others, then the first fetch to occur will transfer the new objects 
while fetching the other ones will simply notice that the required 
objects are already available locally and only the ref will be updated.

The ordering comes into play when it is time to _merge_ those remote 
branches into, say, the local master branch.  That's why it is probably 
a good thing to use fetch+merge instead of pull in this case.  But this 
is then a local matter and nothing that depends on the fetch ordering.


Nicolas