From: Petr Baudis <pasky@suse.cz>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Make git-send-pack exit with error when some refs couldn't be pushed out
Date: Wed, 14 Dec 2005 03:30:05 +0100 [thread overview]
Message-ID: <20051214023005.GS10680@pasky.or.cz> (raw)
In-Reply-To: <7vbqzk5tx1.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Dec 14, 2005 at 02:50:02AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> However, I am not quite sure if the recent change to Cogito to
> update the mirror of remote branch is a good one. Since I am
> not a Cogito user, I did not question it when I saw the change,
> but I wondered what you are using the cached "remote ref is
> supposed to be pointing at this commit" knowledge for. If it is
> only "pretending to have fetched the remote branch immediately
> after we pushed into it before anybody else touched the same
> remote branch", then it probably is benign.
Exactly, we're just pretending that. It's useful since cg-fetch's
diff-tree output is less confusing then, cg-log -r <remotebranch> and
cg-diff -r ... gives expected results, etc.
> But this bit puzzles and worries me:
>
> > ... otherwise
> > it gets out of sync, which can lead even to loss of commits on the local
> > side (this happenned to Jonas Fonseca - thanks for the report, BTW).
>
> I do not remember seeing that report so I do not know how that
> lossage happens with unreleased Cogito, but I suspect there is
> something very fishy going on here. I presume it happens when
> the next fetch/pull from the remote is run, but if the locally
> cached information can affect the next fetch/pull in such a way,
> wouldn't updates by other people to the shared remote repository
> branch also cause things to go out-of-sync and cause the same
> breakage?
Jonas only reported it on IRC as weird cg-commit behaviour (which it
appeared to be, but the cause turned out to be this and the nice
side-effect that this kind of breakage cannot lose you actual data at
least, just metadata).
If the push really happened, this shouldn't be a problem, since then we
get into a "fast-forward relation" to the remote branch, and commits by
other people don't affect it either, since they don't break this
relation. The "interesting behaviour" Cogito implements happens only if
your current HEAD == <the_old_remote_head>, which can't happen when
other people commit, only when you push it out to the remote head.
What kicks in is the fast-forward behaviour change I proposed quite some
time ago on the mailing list and got zero feedback about --- when
updating from a remote branch, the Cogito 0.17pre's fast-forward test
is extended from
if (head ancestor_of remote_new)
to
if (head ancestor_of remote_new OR head == remote_old)
which will make fast-forward able to follow even remote rebases
and should have no negative side-effects as long as remote_old
was correct (which it is except when our bug comes out). So in
the reported case, remote_old was set to head, while remote_new
stayed as before, and Cogito therefore thought that the remote
branch just got rebased from head to remote_new, and adjusted
the head appropriately.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
next prev parent reply other threads:[~2005-12-14 2:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-14 0:45 [PATCH] Make git-send-pack exit with error when some refs couldn't be pushed out Petr Baudis
2005-12-14 1:50 ` Junio C Hamano
2005-12-14 2:30 ` Petr Baudis [this message]
2005-12-14 16:15 ` [PATCH] Make git-send-pack exit with error when some refs cou ldn't " Jon Loeliger
2005-12-14 19:01 ` Petr Baudis
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=20051214023005.GS10680@pasky.or.cz \
--to=pasky@suse.cz \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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).