summaryrefslogtreecommitdiff
path: root/t/t1411-reflog-show.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-08-27Merge branch 'sg/test-must-be-empty'Libravatar Junio C Hamano1-2/+1
Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s'
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'Libravatar SZEDER Gábor1-2/+1
Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-16t1000-t1999: fix broken &&-chainsLibravatar Eric Sunshine1-3/+3
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-26t1411: abstract away SHA-1-specific constantsLibravatar brian m. carlson1-10/+11
Adjust the test so that it uses a variable consisting of the current HEAD instead of a hard-coded hash. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-07t1414: document some reflog-walk odditiesLibravatar Jeff King1-10/+0
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>
2017-07-07reflog-walk: don't free reflogs added to cacheLibravatar Jeff King1-0/+4
The add_reflog_for_walk() function keeps a cache mapping refnames to their reflog contents. We use a cached reflog entry if available, and otherwise allocate and store a new one. Since 5026b47175 (add_reflog_for_walk: avoid memory leak, 2017-05-04), when we hit an error parsing a date-based reflog spec, we free the reflog memory but leave the cache entry pointing to the now-freed memory. We can fix this by just leaving the memory intact once it has made it into the cache. This may leave an unused entry in the cache, but that's OK. And it means we also catch a similar situation: we may not have allocated at all in this invocation, but simply be pointing to a cached entry from a previous invocation (which is relying on that entry being present). The new test in t1411 exercises this case and fails when run with --valgrind or ASan. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-07reflog-walk: duplicate strings in complete_reflogs listLibravatar Jeff King1-0/+6
As part of the add_reflog_to_walk() function, we keep a string_list mapping refnames to their reflog contents. This serves as a cache so that accessing the same reflog twice requires only a single copy of the log in memory. The string_list is initialized via xcalloc, meaning its strdup_strings field is set to 0. But after inserting a string into the list, we unconditionally call free() on the string, leaving the list pointing to freed memory. If another reflog is added (e.g., "git log -g HEAD HEAD"), then the second one may have unpredictable results. The extra free was added by 5026b47175 (add_reflog_for_walk: avoid memory leak, 2017-05-04). Though if you look carefully, you can see that the code was buggy even before then. If we tried to read the reflogs by time but came up with no entries, we exited with an error, freeing the string in that code path. So the bug was harder to trigger, but still there. We can fix it by just asking the string list to make a copy of the string. Technically we could fix the problem by not calling free() on our string (and just handing over ownership to the string list), but there are enough conditionals that it's quite hard to figure out which code paths need the free and which do not. Simpler is better here. The new test reliably shows the problem when run with --valgrind or ASAN. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-12Merge branch 'dt/reflog-tests'Libravatar Junio C Hamano1-1/+1
Tests that assume how reflogs are represented on the filesystem too much have been corrected. * dt/reflog-tests: tests: remove some direct access to .git/logs t/t7509: remove unnecessary manipulation of reflog
2015-07-28tests: remove some direct access to .git/logsLibravatar David Turner1-1/+1
Alternate refs backends might store reflogs somewhere other than .git/logs. Change most test code that directly accesses .git/logs to instead use git reflog commands. There are still a few tests which need direct access to reflogs: to check reflog permissions, to manually create reflogs from scratch, to save/restore reflogs, to check the format of raw reflog data, and to remove not just reflog contents, but the reflogs themselves. All cases which don't need direct access have been modified. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-21git-reflog: add exists commandLibravatar David Turner1-0/+5
This is necessary because alternate ref backends might store reflogs somewhere other than .git/logs. Code that now directly manipulates .git/logs should instead go through git-reflog. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05log: use true parents for diff when walking reflogsLibravatar Thomas Rast1-0/+22
The reflog walking logic (git log -g) replaces the true parent list with the preceding commit in the reflog. This results in bogus commit diffs when combined with options such as -p; the diff is against the reflog predecessor, not the parent of the commit. Save the true parents on the side, extending the functions from the previous commit. The diff logic picks them up and uses them to show the correct diffs. We do have to be somewhat careful about repeated calling of save_parents(), since the reflog may list a commit more than once. We now store (commit_list*)-1 to distinguish the "not saved yet" and "root commit" cases. This lets us preserve an empty parent list even if save_parents() is repeatedly called. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-07reflog-walk: tell explicit --date=default from not having --date at allLibravatar Junio C Hamano1-4/+4
Introduction of opt->date_mode_explicit was a step in the right direction, but lost that crucial bit at the very end of the callchain, and the callee could not tell an explicitly specified "I want *date* but in default format" from the built-in default value passed when there was no --date specified. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-04reflog-walk: always make HEAD@{0} show indexed selectorsLibravatar Jeff King1-0/+8
When we are showing reflog selectors during a walk, we infer from context whether the user wanted to see the index in each selector, or the reflog date. The current rules are: 1. if the user asked for an explicit date format in the output, show the date 2. if the user asked for ref@{now}, show the date 3. if neither is true, show the index However, if we see "ref@{0}", that should be a strong clue that the user wants to see the counted version. In fact, it should be much stronger than the date format in (1). The user may have been setting the date format to use in another part of the output (e.g., in --format="%gd (%ad)", they may have wanted to influence the author date). This patch flips the rules to: 1. if the user asked for ref@{0}, always show the index 2. if the user asked for ref@{now}, always show the date 3. otherwise, we have just "ref"; show them counted by default, but respect the presence of "--date" as a clue that the user wanted them date-based Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-04log: respect date_mode_explicit with --format:%gdLibravatar Jeff King1-1/+1
When we show a reflog selector (e.g., via "git log -g"), we perform some DWIM magic: while we normally show the entry's index (e.g., HEAD@{1}), if the user has given us a date with "--date", then we show a date-based select (e.g., HEAD@{yesterday}). However, we don't want to trigger this magic if the alternate date format we got was from the "log.date" configuration; that is not sufficiently strong context for us to invoke this particular magic. To fix this, commit f4ea32f (improve reflog date/number heuristic, 2009-09-24) introduced a "date_mode_explicit" flag in rev_info. This flag is set only when we see a "--date" option on the command line, and we a vanilla date to the reflog code if the date was not explicit. Later, commit 8f8f547 (Introduce new pretty formats %g[sdD] for reflog information, 2009-10-19) added another way to show selectors, and it did not respect the date_mode_explicit flag from f4ea32f. This patch propagates the date_mode_explicit flag to the pretty-print code, which can then use it to pass the appropriate date field to the reflog code. This brings the behavior of "%gd" in line with the other formats, and means that its output is independent of any user configuration. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-04t1411: add more selector index/date testsLibravatar Jeff King1-0/+45
We already check that @{now} and "--date" cause the displayed selector to use the date for both the multiline and oneline formats. However, we miss several cases: 1. The --format=%gd selector is not tested at all. 2. We do not check how the log.date config interacts with the "--date" magic (according to f4ea32f, it should not impact the output). Doing so reveals that the combination of both (log.date combined with the %gd format) does not behave as expected. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-01reflog: fix overriding of command line optionsLibravatar Michael J Gruber1-1/+1
Currently, "git reflog" overrides some command line options such as "--format". Fix this by using the new 2-phase version of cmd_log_init(). Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-01t/t1411: test reflog with formatsLibravatar Michael J Gruber1-0/+18
"git reflog --format=short" does not work because "reflog" overrides the format option. This is documented in code. Document this by a test (known failure) also. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-13don't use default revision if a rev was specifiedLibravatar Dave Olszewski1-0/+9
If a revision is specified, it happens not to have any commits, don't use the default revision. By doing so, surprising and undesired behavior can happen, such as showing the reflog for HEAD when a branch was specified. [jc: squashed a test from René] Signed-off-by: Dave Olszewski <cxreg@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-20make oneline reflog dates more consistent with multiline formatLibravatar Jeff King1-0/+67
The multiline reflog format (e.g., as shown by "git log -g") will show HEAD@{<date>} rather than HEAD@{<count>} in two situations: 1. If the user gave branch@{<date>} syntax to specify the reflog 2. If the user gave a --date=<format> specifier It uses the "normal" date format in case 1, and the user-specified format in case 2. The oneline reflog format (e.g., "git reflog show" or "git log -g --oneline") will show the date in the same two circumstances. However, it _always_ shows the date as a relative date, and it always ignores the timezone. In case 2, it seems ridiculous to trigger the date but use a format totally different from what the user requested. For case 1, it is arguable that the user might want to see the relative date by default; however, the multiline version shows the normal format. This patch does three things: - refactors the "relative_date" parameter to show_reflog_message to be an actual date_mode enum, since this is how it is used (it is passed to show_date) - uses the passed date_mode parameter in the oneline format (making it consistent with the multiline format) - does not ignore the timezone parameter in oneline mode Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>