kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Jeff King	de239446b6	reflog-walk: apply --since/--until to reflog dates When doing a reflog walk, we use the commit's date to do any date limiting. In earlier versions of Git, this could lead to nonsense results, since a skipped commit would truncate the traversal. So a sequence like: git commit ... git checkout week-old-branch git checkout - git log -g --since=1.day.ago would stop at the week-old-branch, even though the "git commit" entry further back is still interesting. As of the prior commit, which uses a parent-less traversal of the reflog, you get the whole reflog minus any commits whose dates do not match the specified options. This is arguably useful, as you could scan the reflogs for commits that originated in a certain range. But more likely a user doing a reflog walk wants to limit based on the reflog entries themselves. You can simulate --until with: git log -g @{1.day.ago} but there's no way to ask Git to traverse only back to a certain date. E.g.: # show me reflog entries from the past day git log -g --since=1.day.ago This patch teaches the revision machinery to prefer the reflog entry dates to the commit dates when doing a reflog walk. Technically this is a change in behavior that affects plumbing, but the previous behavior was so buggy that it's unlikely anyone was relying on it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Jeff King	d08565bf2d	reflog-walk: stop using fake parents The reflog-walk system works by putting a ref's tip into the pending queue, and then "traversing" the reflog by pretending that the parent of each commit is the previous reflog entry. This causes a number of user-visible oddities, as documented in t1414 (and the commit message which introduced it). We can fix all of them in one go by replacing the fake-reflog system with a much simpler one: just keeping a list of reflogs to show, and walking through them entry by entry. The implementation is fairly straight-forward, but there are a few items to note: 1. We obviously must skip calling add_parents_to_list() when we are traversing reflogs, since we do not want to walk the original parents at all. As a result, we must call try_to_simplify_commit() ourselves. There are other parts of add_parents_to_list() we skip, as well, but none of them should matter for a reflog traversal: - We do not allow UNINTERESTING commits, nor symmetric ranges (and we bail when these are used with "-g"). - Using --source makes no sense, since we aren't traversing. The reflog selector shows the same information with more detail. - Using --first-parent is still sensible, since you may want to see the first-parent diff for each entry. But since we're not traversing, we don't need to cull the parent list here. 2. Since we now just walk the reflog entries themselves, rather than starting with the ref tip, we now look at the "new" field of each entry rather than the "old" (i.e., we are showing entries, not faking parents). This removes all of the tricky logic around skipping past root commits. But note that we have no way to show an entry with the null sha1 in its "new" field (because such a commit obviously does not exist). Normally this would not happen, since we delete reflogs along with refs, but there is one special case. When we rename the currently checked out branch, we write two reflog entries into the HEAD log: one where the commit goes away, and another where it comes back. Prior to this commit, we show both entries with identical reflog messages. After this commit, we show only the "comes back" entry. See the update in t3200 which demonstrates this. Arguably either is fine, as the whole double-entry thing is a bit hacky in the first place. And until a recent fix, we truncated the traversal in such a case anyway, which was _definitely_ wrong. 3. We show individual reflogs in order, but choose which reflog to show at each stage based on which has the most recent timestamp. This interleaves the output from multiple reflogs based on date order, which is probably what you'd want with limiting like "-n 30". Note that the implementation aims for simplicity. It does a linear walk over the reflog queue for each commit it pulls, which may perform badly if you interleave an enormous number of reflogs. That seems like an unlikely use case; if we did want to handle it, we could probably keep a priority queue of reflogs, ordered by the timestamp of their current tip entry. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Jeff King	7f97de5ee1	rev-list: check reflog_info before showing usage When git-rev-list sees no pending commits, it shows a usage message. This works even when reflog-walking is requested, because the reflog-walk code currently puts the reflog tips into the pending queue. In preparation for refactoring the reflog-walk code, let's explicitly check whether we have any reflogs to walk. For now this is a noop, but the existing reflog tests will make sure that it kicks in after the refactoring. Likewise, we'll add a test that "rev-list -g" without specifying any reflogs continues to fail (so that we know our check does not kick in too aggressively). Note that the implementation needs to go into its own sub-function, as the walk code does not expose its innards outside of reflog-walk.c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Jeff King	7cf686b9a8	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>	8 years ago