From: Leo Razoumov <slonik.az@gmail.com>
To: git@vger.kernel.org
Subject: Re: How to check new commit availability without full fetch?
Date: Mon, 11 Jan 2010 12:35:35 -0500 [thread overview]
Message-ID: <ee2a733e1001110935h101e7ec9l1b4fcf2bf210f53f@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1001111149150.10143@xanadu.home>
On 2010-01-11, Nicolas Pitre <nico@fluxnic.net> wrote:
> 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).
>
Setup might be, indeed, awkward but it handles very diverse tasks.
As I said in my earlier emails different repos fetch into the *same* remote/foo.
So there could be conflicts and using fetch -f could cause loss of data.
Before switching to git I used mercurial for the same purpose and it
has command that are equivalent to fetch --dry-run.
--Leo--
next prev parent reply other threads:[~2010-01-11 17:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-10 11:12 How to check new commit availability without full fetch? Leo Razoumov
2010-01-10 20:13 ` Nicolas Pitre
2010-01-10 20:38 ` Junio C Hamano
2010-01-10 21:05 ` Nicolas Pitre
2010-01-11 1:36 ` Leo Razoumov
2010-01-11 1:57 ` Tay Ray Chuan
2010-01-11 2:08 ` Junio C Hamano
2010-01-11 5:29 ` Michael Witten
2010-01-11 7:12 ` Junio C Hamano
2010-01-11 2:01 ` Nicolas Pitre
2010-01-11 16:22 ` Leo Razoumov
2010-01-11 17:04 ` Nicolas Pitre
2010-01-11 17:35 ` Leo Razoumov [this message]
2010-01-11 5:38 ` Dmitry Potapov
2010-01-11 7:31 ` Robin Rosenberg
2010-01-11 8:09 ` Junio C Hamano
2010-01-11 17:59 ` Nicolas Pitre
2010-01-11 19:20 ` Junio C Hamano
2010-01-11 20:52 ` Nicolas Pitre
2010-01-11 20:06 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ee2a733e1001110935h101e7ec9l1b4fcf2bf210f53f@mail.gmail.com \
--to=slonik.az@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).