From: "Strain, Roger L." <roger.strain@swri.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Marc Balmer <marc@msys.ch>, Duy Nguyen <pclouds@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>
Subject: RE: Regression in git-subtree.sh, introduced in 2.20.1, after 315a84f9aa0e2e629b0680068646b0032518ebed
Date: Thu, 3 Jan 2019 15:30:13 +0000 [thread overview]
Message-ID: <02964c7abb7544259ba9f0d29ff32a45@MBX260.adm.swri.edu> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1901031448260.45@tvgsbejvaqbjf.bet>
> -----Original Message-----
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> Hi Roger,
>
>
> On Wed, 2 Jan 2019, Strain, Roger L. wrote:
>
> > TL;DR: Current script uses git rev-list to retrieve all commits which
> > are reachable from HEAD but not from <abc123>. Is there a syntax that
> > will instead return all commits reachable from HEAD, but stop
> traversing
> > when <abc123> is encountered? It's a subtle distinction, but
> important.
>
> Maybe you are looking for the --ancestry-path option? Essentially, `git
> rev-list --ancestry-path A..B` will list only commits that are reachable
> from B, not reachable from A, but that *can* reach A (i.e. that are
> descendants of A).
>
> Ciao,
> Johannes
Thanks for the suggestion, but I don't think that one does quite what is needed here. It did provide a good sample graph to consider, though. Subtree needs to rebuild history and tie things in to previously reconstructed commits. Here's the sample graph from the --ancestry-path portion of the git-rev-list manpage:
D---E-------F
/ \ \
B---C---G---H---I---J
/ \
A-------K---------------L--M
Subtree maps mainline commits to known subtree commits, so let's assume we have a mapping of D to D'. As documented, if we were to rev-list D..M normally, we'd get all commits except D itself, and D's ancestors B and A. So the "normal" result would be:
E-------F
\ \
C---G---H---I---J
\
K---------------L--M
This is bad for subtree, because commit C's parent is B, which is not a known commit to subtree, and which wasn't included in the list of commits to convert. It therefore assumes C is an initial commit, which is wrong. Likewise K's parent A isn't in the list to convert, so K is assumed to be an initial commit, which also is wrong. (E is okay here, because E's parent is D, and D maps to D', so we can stitch that history together properly.)
By using --ancestry-path, we would instead get only the things directly between D and M, as documented:
E-------F
\ \
G---H---I---J
\
L--M
This actually moves us in the wrong direction, as now both G and L have one known parent and one unknown parent; I'm not sure how the script would handle this, but we actually end up with less information.
In this case, what I need is a way to trace back history along all merge parents, stopping only when I hit one of multiple known commits that I can directly tie back to. In this instance, subtree *knows* what D maps to, so any time D is encountered, we can stop tracing back. But if I can get to one of D's ancestors through another path, I need to keep following that path. Here's what I need for this to work properly:
E-------F
\ \
B---C---G---H---I---J
/ \
A-------K---------------L--M
To give one more example (since removing a single commit frankly isn't very interesting) let's say that I have known subtree mappings for both D = D' and G = G'. I would therefore need to find all commits which are ancestors of M, but stop tracing history when I reach *either* D or G. Note that if I can reach a commit from any other path, I still need to know about it. Here's what we ultimately would want to find:
E-------F
\
H---I---J
\
A-------K---------------L--M
In this case, commit E will reference known commit D as a parent and maps to D', and is good. Commit H references known commit G as a parent and maps to G', and is good. Commit K references A, which itself is an initial commit so is converted to A' (just as it has been previous times subtree has run), and is good.
I'll keep digging around a little bit, but I'm starting to think the necessary plumbing for this operation might not exist. If I can't find it, I'll see if there's some way to unroll that recursive call.
--
Roger
next prev parent reply other threads:[~2019-01-03 15:43 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-31 10:28 Regression in git-subtree.sh, introduced in 2.20.1, after 315a84f9aa0e2e629b0680068646b0032518ebed Marc Balmer
2018-12-31 10:51 ` Duy Nguyen
2018-12-31 11:12 ` Marc Balmer
2018-12-31 11:20 ` Duy Nguyen
2018-12-31 11:24 ` Marc Balmer
2018-12-31 11:36 ` Duy Nguyen
2018-12-31 12:31 ` Marc Balmer
2019-01-01 13:19 ` Duy Nguyen
2019-01-02 9:13 ` Marc Balmer
2019-01-02 20:20 ` Strain, Roger L.
2019-01-03 13:50 ` Johannes Schindelin
2019-01-03 15:30 ` Strain, Roger L. [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-12-08 10:30 Nadav SInai
2019-12-09 14:11 ` Strain, Roger L.
2019-12-09 11:45 ` Ed Maste
2019-12-09 16:19 ` Strain, Roger L.
2019-12-09 14:13 ` Marc Balmer
2019-12-09 14:18 ` Strain, Roger L.
2019-12-09 14:30 ` Marc Balmer
2019-12-09 15:26 ` Johannes Schindelin
2019-12-09 15:31 ` Marc Balmer
2019-12-09 19:38 ` Johannes Schindelin
2019-12-11 5:43 ` Tom Clarkson
2019-12-11 14:39 ` Strain, Roger L.
2019-12-12 5:02 ` Tom Clarkson
2019-12-13 13:41 ` Johannes Schindelin
2019-12-14 8:29 ` Marc Balmer
[not found] ` <BAB4CF6D-6904-4698-ACE1-EBEEC745E569@msys.ch>
2019-12-14 14:27 ` Tom Clarkson
2019-12-16 11:30 ` Ed Maste
2019-12-18 0:15 ` Tom Clarkson
2020-03-12 10:40 ` Marc Balmer
2019-12-16 3:50 ` Tom Clarkson
[not found] <3E84DE22-9614-4E1B-9717-69F6777DD219@msys.ch>
2020-03-12 10:43 ` Tom Clarkson
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=02964c7abb7544259ba9f0d29ff32a45@MBX260.adm.swri.edu \
--to=roger.strain@swri.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=marc@msys.ch \
--cc=pclouds@gmail.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).