diff options
author | Jeff King <peff@peff.net> | 2017-07-07 05:06:10 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2017-07-07 10:03:48 -0700 |
commit | 7cf686b9a89d3cea269dfcced2d32dff56a5f01d (patch) | |
tree | 15cee02040c51c4c77260382fe60dfc1d76cd6ea /levenshtein.c | |
parent | Merge branch 'jk/reflog-walk-maint' into jk/reflog-walk (diff) | |
download | tgif-7cf686b9a89d3cea269dfcced2d32dff56a5f01d.tar.xz |
t1414: document some reflog-walk oddities
Since its inception, the general strategy of the reflog-walk
code has been to start with the tip commit for the ref, and
as we traverse replace each commit's parent pointers with
fake parents pointing to the previous reflog entry.
This lets us traverse the reflog as if it were a real
history, but it has some user-visible oddities. Namely:
1. The fake parents are used for commit selection and
display. So for example, "--merges" or "--no-merges"
are not useful, because the history appears as a linear
string of commits. Likewise, pathspec limiting is based
on the diff between adjacent entries, not the changes
actually introduced by a commit.
These are often the same (e.g., because the entry was
just running "git commit" and the adjacent entry _is_
the true parent), but it may not be in several common
cases. For instance, using "git reset" to jump around
history, or "git checkout" to move HEAD.
2. We reverse-map each commit back to its reflog. So when
it comes time to show commit X, we say "a-ha, we added
X because it was at the tip of the 'foo' reflog, so
let's show the foo reflog". But this leads to nonsense
results when you ask to traverse multiple reflogs: if
two reflogs have the same tip commit, we only map back
to one of them. Instead, we should show both.
3. If the tip of the reflog and the ref tip disagree on
the current value, we show the ref tip but give no
indication of the value in the reflog. This situation
isn't supposed to happen (since any ref update should
touch the reflog). But if it does, given that the
requested operation is to show the reflog, it makes
sense to prefer that.
This commit adds a new script with several expect_failure
tests to demonstrate the problems. This could be part of
the existing t1411, but it's a bit easier to start from a
fresh state, where we know exactly what will be in the log.
Since the new multiple-reflog tests are checking the actual
output, we can drop the "make sure we don't segfault" tests
from t1411, which are a strict subset of what we're doing
here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'levenshtein.c')
0 files changed, 0 insertions, 0 deletions