git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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--

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