From: Junio C Hamano <gitster@pobox.com>
To: Johannes Sixt <j.sixt@viscovery.net>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
Mike Hommey <mh@glandium.org>,
git@vger.kernel.org
Subject: Re: grafts not appearing in manual pages
Date: Thu, 27 Sep 2007 00:25:39 -0700 [thread overview]
Message-ID: <7vmyv8wowc.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <46FB4C23.8010400@viscovery.net> (Johannes Sixt's message of "Thu, 27 Sep 2007 08:22:27 +0200")
Johannes Sixt <j.sixt@viscovery.net> writes:
> J. Bruce Fields schrieb:
> ...
>> It could go in Documentation/user-manual.txt, but I don't know where.
>
> IMHO grafts should not be made known to a wide audience until
> send-pack, pack-objects, and prune are fixed so that you cannot
> corrupt your repository when there are grafts.
I mildly have to disagree.
Documenting the current semantics (in short, "grafts are
strictly local matter") and the implications is important.
Here are some of the points you would want to mention:
- if you graft, prune and fsck will honor that fake ancestry,
- if you _add_ parent by grafting you will not lose the history
that is otherwise disconnected, but on the other hand, once
having pruned that way and you remove that graft, prune will
discard that discontiguous history away.
- if you _hide_ parent by grafting, you will be able to lose
the hidden subbranch away, but you will get complaints from
fsck if you remove that graft after pruning your history.
- if you try to fetch/push across repositories with different
notion of ancestry (because of different grafts), things can
break in expected ways (and you can keep both halves ;-).
For example, if the sending side has extra parents to a
commit compared to the receiving side, and if the receiving
side claims to have that commit, objects reachable from the
extra parents might be missing from the reciving end but the
sender will not be able to notice.
> See http://thread.gmane.org/gmane.comp.version-control.git/37744
> in particular http://article.gmane.org/gmane.comp.version-control.git/37866
> on a sketch how to fix the issues.
IIRC, there discussions were more about what the issues are and
what the potential semantics could be. First the desired
semantics need to be defined.
prev parent reply other threads:[~2007-09-27 7:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-26 20:24 grafts not appearing in manual pages Mike Hommey
2007-09-26 21:01 ` J. Bruce Fields
2007-09-27 6:22 ` Johannes Sixt
2007-09-27 7:25 ` Junio C Hamano [this message]
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=7vmyv8wowc.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=bfields@fieldses.org \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.net \
--cc=mh@glandium.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).