summaryrefslogtreecommitdiff
path: root/t/t1410-reflog.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-01-05reflog-walk: don't segfault on non-commit sha1's in the reflogLibravatar Dennis Kaarsemaker1-0/+13
git reflog (ab)uses the log machinery to display its list of log entries. To do so it must fake commit parent information for the log walker. For refs in refs/heads this is no problem, as they should only ever point to commits. Tags and other refs however can point to anything, thus their reflog may contain non-commit objects. To avoid segfaulting, we check whether reflog entries are commits before feeding them to the log walker and skip any non-commits. This means that git reflog output will be incomplete for such refs, but that's one step up from segfaulting. A more complete solution would be to decouple git reflog from the log walker machinery. Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net> Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-28tests: remove some direct access to .git/logsLibravatar David Turner1-8/+16
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>
2014-12-22Merge branch 'jk/for-each-reflog-ent-reverse'Libravatar Junio C Hamano1-0/+30
The code that reads the reflog from the newer to the older entries did not handle an entry that crosses a boundary of block it uses to read them correctly. * jk/for-each-reflog-ent-reverse: for_each_reflog_ent_reverse: turn leftover check into assertion for_each_reflog_ent_reverse: fix newlines on block boundaries
2014-12-05for_each_reflog_ent_reverse: fix newlines on block boundariesLibravatar Jeff King1-0/+30
When we read a reflog file in reverse, we read whole chunks of BUFSIZ bytes, then loop over the buffer, parsing any lines we find. We find the beginning of each line by looking for the newline from the previous line. If we don't find one, we know that we are either at the beginning of the file, or that we have to read another block. In the latter case, we stuff away what we have into a strbuf, read another block, and continue our parse. But we missed one case here. If we did find a newline, and it is at the beginning of the block, we must also stuff that newline into the strbuf, as it belongs to the block we are about to read. The minimal fix here would be to add this special case to the conditional that checks whether we found a newline. But we can make the flow a little clearer by rearranging a bit: we first handle lines that we are going to show, and then at the end of each loop, stuff away any leftovers if necessary. That lets us fold this special-case in with the more common "we ended in the middle of a line" case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-12Merge branch 'jk/fetch-reflog-df-conflict'Libravatar Junio C Hamano1-18/+18
Fix-up a test for portability. * jk/fetch-reflog-df-conflict: t1410: fix breakage on case-insensitive filesystems
2014-11-10t1410: fix breakage on case-insensitive filesystemsLibravatar Jeff King1-18/+18
Two tests recently added to t1410 create branches "a" and "a/b" to test d/f conflicts on reflogs. Earlier, unrelated tests in that script create the path "A/B" in the working tree. There's no conflict on a case-sensitive filesystem, but on a case-insensitive one, "git log" will complain that "a/b" is both a revision and a working tree path. We could fix this by using a "--" to disambiguate, but we are probably better off using names that are less confusing to make it more clear that they are unrelated to the working tree files. This patch turns "a/b" into "one/two". Reported-by: Michael Blume <blume.mike@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-06Merge branch 'jk/fetch-reflog-df-conflict'Libravatar Junio C Hamano1-0/+34
Corner-case bugfixes for "git fetch" around reflog handling. * jk/fetch-reflog-df-conflict: ignore stale directories when checking reflog existence fetch: load all default config at startup
2014-11-04ignore stale directories when checking reflog existenceLibravatar Jeff King1-0/+34
When we update a ref, we have two rules for whether or not we actually update the reflog: 1. If the reflog already exists, we will always append to it. 2. If log_all_ref_updates is set, we will create a new reflog file if necessary. We do the existence check by trying to open the reflog file, either with or without O_CREAT (depending on log_all_ref_updates). If it fails, then we check errno to see what happened. If we were not using O_CREAT and we got ENOENT, the file doesn't exist, and we return success (there isn't a reflog already, and we were not told to make a new one). If we get EISDIR, then there is likely a stale directory that needs to be removed (e.g., there used to be "foo/bar", it was deleted, and the directory "foo" was left. Now we want to create the ref "foo"). If O_CREAT is set, then we catch this case, try to remove the directory, and retry our open. So far so good. But if we get EISDIR and O_CREAT is not set, then we treat this as any other error, which is not right. Like ENOENT, EISDIR is an indication that we do not have a reflog, and we should silently return success (we were not told to create it). Instead, the current code reports this as an error, and we fail to update the ref at all. Note that this is relatively unlikely to happen, as you would have to have had reflogs turned on, and then later turned them off (it could also happen due to a bug in fetch, but that was fixed in the previous commit). However, it's quite easy to fix: we just need to treat EISDIR like ENOENT for the non-O_CREAT case, and silently return (note that this early return means we can also simplify the O_CREAT case). Our new tests cover both cases (O_CREAT and non-O_CREAT). The first one already worked, of course. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-08checkout.c: use ref_exists instead of file_existLibravatar Ronnie Sahlberg1-0/+8
Change checkout.c to check if a ref exists instead of checking if a loose ref file exists when deciding if to delete an orphaned log file. Otherwise, if a ref only exists as a packed ref without a corresponding loose ref for the currently checked out branch, we risk that the reflog will be deleted when we switch to a different branch. Update the reflog tests to check for this bug. The following reproduces the bug: $ git init-db $ git config core.logallrefupdates true $ git commit -m Initial --allow-empty [master (root-commit) bb11abe] Initial $ git reflog master [8561dcb master@{0}: commit (initial): Initial] $ find .git/{refs,logs} -type f | grep master [.git/refs/heads/master] [.git/logs/refs/heads/master] $ git branch foo $ git pack-refs --all $ find .git/{refs,logs} -type f | grep master [.git/logs/refs/heads/master] $ git checkout foo $ find .git/{refs,logs} -type f | grep master ... reflog file is missing ... $ git reflog master ... nothing ... Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Acked-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-11tests: modernise style: more uses of test_line_countLibravatar Stefano Lattarini1-18/+8
Prefer: test_line_count <OP> COUNT FILE over: test $(wc -l <FILE) <OP> COUNT (or similar usages) in several tests. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-4/+4
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-28reflog: honor gc.reflogexpire=neverLibravatar Adam Simpkins1-0/+41
Previously, if gc.reflogexpire or gc.reflogexpire were set to "never" or "false", the builtin default values were used instead. Signed-off-by: Adam Simpkins <simpkins@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-19test-lib: Introduce test_chmod and use it instead of update-index --chmodLibravatar Johannes Sixt1-3/+1
This function replaces sequences of 'chmod +x' and 'git update-index --chmod=+x' in the test suite, whose purpose is to help filesystems that need core.filemode=false. Two places where only 'chmod +x' was used we also use this new function. The function calls 'git update-index --chmod' without checking core.filemode (unlike some of the call sites did). We do this because the call sites *expect* that the executable bit ends up in the index (ie. it is not the purpose of the call sites to *test* whether git treats 'chmod +x' and 'update-index --chmod=+x' correctly). Therefore, on filesystems with core.filemode=true the 'git update-index --chmod' is a no-op. The function uses --add with update-index to help one call site in t6031-merge-recursive. It makes no difference for the other callers. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2008-08-10Fix deleting reflog entries from HEAD reflogLibravatar Junio C Hamano1-1/+1
dwim_ref() used to resolve HEAD symbolic ref to its target (i.e. current branch). This incorrectly removed the reflog entry from the current branch when 'git reflog delete HEAD@{1}' was asked for. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-10reflog test: add more tests for 'reflog delete'Libravatar Pieter de Bie1-4/+18
This adds more tests for 'reflog delete' and marks it as broken, as currently a call to 'git reflog delete HEAD@{1}' deletes entries in the currently checked out branch's log, not the HEAD log. Noticed by John Wiegley Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-12gc: call "prune --expire 2.weeks.ago" by defaultLibravatar Johannes Schindelin1-18/+0
The only reason we did not call "prune" in git-gc was that it is an inherently dangerous operation: if there is a commit going on, you will prune loose objects that were just created, and are, in fact, needed by the commit object just about to be created. Since it is dangerous, we told users so. That led to many users not even daring to run it when it was actually safe. Besides, they are users, and should not have to remember such details as when to call git-gc with --prune, or to call git-prune directly. Of course, the consequence was that "git gc --auto" gets triggered much more often than we would like, since unreferenced loose objects (such as left-overs from a rebase or a reset --hard) were never pruned. Alas, git-prune recently learnt the option --expire <minimum-age>, which makes it a much safer operation. This allows us to call prune from git-gc, with a grace period of 2 weeks for the unreferenced loose objects (this value was determined in a discussion on the git list as a safe one). If you want to override this grace period, just set the config variable gc.pruneExpire to a different value; an example would be [gc] pruneExpire = 6.months.ago or even "never", if you feel really paranoid. Note that this new behaviour makes "--prune" be a no-op. While adding a test to t5304-prune.sh (since it really tests the implicit call to "prune"), also the original test for "prune --expire" was moved there from t1410-reflog.sh, where it did not belong. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2008-02-22Merge branch 'bc/reflog-fix' into js/reflog-deleteLibravatar Junio C Hamano1-0/+19
* bc/reflog-fix: (1490 commits) builtin-reflog.c: don't install new reflog on write failure hash: fix lookup_hash semantics gitweb: Better chopping in commit search results builtin-tag.c: remove cruft git-merge-index documentation: clarify synopsis send-email: fix In-Reply-To regression git-reset --hard and git-read-tree --reset: fix read_cache_unmerged() Teach git-grep --name-only as synonym for -l diff: fix java funcname pattern for solaris t3404: use configured shell instead of /bin/sh git_config_*: don't assume we are parsing a config file prefix_path: use is_absolute_path() instead of *orig == '/' git-clean: handle errors if removing files fails Clarified the meaning of git-add -u in the documentation git-clone.sh: properly configure remote even if remote's head is dangling git.el: Set process-environment instead of invoking env Documentation/git-stash: document options for git stash list send-email: squelch warning due to comparing undefined $_ to "" cvsexportcommit: be graceful when "cvs status" reorders the arguments Rename git-core rpm to just git and rename the meta-pacakge to git-all. ... Conflicts: Documentation/git-reflog.txt t/t1410-reflog.sh
2007-11-30Add "--expire <time>" option to 'git prune'Libravatar Johannes Schindelin1-0/+18
Earlier, 'git prune' would prune all loose unreachable objects. This could be quite dangerous, as the objects could be used in an ongoing operation. This patch adds a mode to expire only loose, unreachable objects which are older than a certain time. For example, by git prune --expire 14.days you can prune only those objects which are loose, unreachable and older than 14 days (and thus probably outdated). The implementation uses st.st_mtime rather than st.st_ctime, because it can be tested better, using 'touch -d <time>' (and omitting the test when the platform does not support that command line switch). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-17Teach "git reflog" a subcommand to delete single entriesLibravatar Johannes Schindelin1-0/+26
This commit implements the "delete" subcommand: git reflog delete master@{2} will delete the second reflog entry of the "master" branch. With this, it should be easy to implement "git stash pop" everybody seems to want these days. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-01-28git-fsck-objects is now synonym to git-fsckLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince1-1/+1
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-21Revert "prune: --grace=time"Libravatar Junio C Hamano1-3/+3
This reverts commit 9b088c4e394df84232cfd37aea78349a495b09c1. Protecting 'mature' objects does not make it any safer. We should admit that git-prune is inherently unsafe when run in parallel with other operations without involving unwarranted locking overhead, and with the latest git, even rebase and reset would not immediately create crufts anyway.
2007-01-20prune: --grace=timeLibravatar Matthias Lederhofer1-3/+3
This option gives grace period to objects that are unreachable from the refs from getting pruned. The default value is 24 hours and may be changed using gc.prunegrace. Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-10Fix t1410 for core.filemode==falseLibravatar Johannes Schindelin1-0/+2
Since c869753e, core.filemode is hardwired to false on Cygwin. So this test had no chance to succeed, since an early commit (changing just the filemode) failed, and therefore all subsequent tests. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-06reflog expire --fix-staleLibravatar Junio C Hamano1-0/+176
The logic in an earlier round to detect reflog entries that point at a broken commit was not sufficient. Just like we do not trust presense of a commit during pack transfer (we trust only our refs), we should not trust a commit's presense, even if the tree of that commit is complete. A repository that had reflog enabled on some of the refs that was rewound and then run git-repack or git-prune from older versions of git can have reflog entries that point at a commit that still exist but lack commits (or trees and blobs needed for that commit) between it and some commit that is reachable from one of the refs. This revamps the logic -- the definition of "broken commit" becomes: a commit that is not reachable from any of the refs and there is a missing object among the commit, tree, or blob objects reachable from it that is not reachable from any of the refs. Entries in the reflog that refer to such a commit are expired. Since this computation involves traversing all the reachable objects, i.e. it has the same cost as 'git prune', it is enabled only when a new option --fix-stale. Fortunately, once this is run, we should not have to ever worry about missing objects, because the current prune and pack-objects know about reflogs and protect objects referred by them. Unfortunately, this will be absolutely necessary to help people migrate to the newer prune and repack. Signed-off-by: Junio C Hamano <junkio@cox.net>