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

From: Nicolas Pitre <nico@fluxnic.net>
Date: Jan 11, 2010, 17:04 UTC
Message-ID: <alpine.LFD.2.00.1001111149150.10143@xanadu.home>
In-Reply-To: <ee2a733e1001110822t1b04c1ccg9b6eb5489b69783d@mail.gmail.com>

On Mon, 11 Jan 2010, Leo Razoumov wrote:

Show 14 quoted lines

> 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