summaryrefslogtreecommitdiff
path: root/t/t1400-update-ref.sh
AgeCommit message (Collapse)AuthorFilesLines
2007-01-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince1-2/+2
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19Extend read_ref_at() to be usable from places other than sha1_name.Libravatar Junio C Hamano1-3/+3
You can pass an extra argument to the function to receive the reflog message information. Also when the log does not go back beyond the point the user asked, the cut-off time and count are given back to the caller for emitting the error messages as appropriately. We could later add configuration for get_sha1_basic() to make it an error instead of it being just a warning. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Enable reflogs by default in any repository with a working directory.Libravatar Shawn O. Pearce1-2/+2
New and experienced Git users alike are finding out too late that they forgot to enable reflogs in the current repository, and cannot use the information stored within it to recover from an incorrectly entered command such as `git reset --hard HEAD^^^` when they really meant HEAD^^ (aka HEAD~2). So enable reflogs by default in all future versions of Git, unless the user specifically disables it with: [core] logAllRefUpdates = false in their .git/config or ~/.gitconfig. We only enable reflogs in repositories that have a working directory associated with them, as shared/bare repositories do not have an easy means to prune away old log entries, or may fail logging entirely if the user's gecos information is not valid during a push. This heuristic was suggested on the mailing list by Junio. Documentation was also updated to indicate the new default behavior. We probably should start to teach usuing the reflog to recover from mistakes in some of the tutorial material, as new users are likely to make a few along the way and will feel better knowing they can recover from them quickly and easily, without fsck-objects' lost+found features. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17Fix t1400-update-ref test minimallyLibravatar Junio C Hamano1-5/+2
It depended on specific error messages to detect failure but the implementation changed and broke the test. This fixes the breakage minimally. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-16t1400: make test debuggable.Libravatar Junio C Hamano1-43/+43
I had a hard time figuring out why this test was failing with the packed-refs update without running it under "sh -x". This makes output from "sh t1400-update-ref.sh -v" more descriptive. Updating other tests would be a good janitorial task. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-28Display an error from update-ref if target ref name is invalid.Libravatar Shawn Pearce1-0/+12
Alex Riesen (raa.lkml@gmail.com) recently observed that git branch would fail with no error message due to unexpected situations with regards to refs. For example, if .git/refs/heads/gu is a file but "git branch -b refs/heads/gu/fixa HEAD" was invoked by the user it would fail silently due to refs/heads/gu being a file and not a directory. This change adds a test for trying to create a ref within a directory that is actually currently a file, and adds error printing within the ref locking routine should the resolve operation fail. The error printing code probably belongs at this level of the library as other failures within the ref locking, writing and logging code are also currently at this level of the code. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-11tests: Set EDITOR=: and VISUAL=: globallyLibravatar Eric Wong1-1/+0
This way we don't have to remember to set it for each test; and if we forget, we won't cause interactive editors to be spawned for non-interactive tests. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-10Record the type of commit operation in the reflog.Libravatar Shawn Pearce1-3/+16
If committing a merge (.git/MERGE_HEAD exists), an initial tree (no HEAD) or using --amend to amend the prior commit then denote the subtype of commit in the reflog. This helps to distinguish amended or merge commits from normal commits. In the case of --amend the prior sha1 is probably the commit which is being thrown away in favor of the new commit. Since it is likely that the old commit doesn't have any ref pointing to it anymore it can be interesting to know why that the commit was replaced and orphaned. In the case of a merge the prior sha1 is probably the first parent of the new merge commit. Consequently having its prior sha1 in the reflog is slightly less interesting but its still informative to know the commit was the result of a merge which had to be completed by hand. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-24Verify git-commit provides a reflog message.Libravatar Shawn Pearce1-12/+26
The reflog message from git-commit should include the first line of the commit message as supplied by the user. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-19Change 'master@noon' syntax to 'master@{noon}'.Libravatar Shawn Pearce1-16/+39
Its ambiguous to parse "master@2006-05-17 18:30:foo" when foo is meant as a file name and ":30" is meant as 30 minutes past 6 pm. Therefore all date specifications in a sha1 expression must now appear within brackets and the ':' splitter used for the path name in a sha1 expression ignores ':' appearing within brackets. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-19General ref log reading improvements.Libravatar Shawn Pearce1-0/+64
Corrected the log starting time displayed in the error message (as it was always showing the epoch due to a bad input to strtoul). Improved the log parser so we only scan backwards towards the '\n' from the end of the prior log; during this scan the last '>' is remembered to improve performance (rather than scanning forward to it). If the log record matched is the last log record in the file only use its new sha1 value if the date matches exactly; otherwise we leave the passed in sha1 alone as it already contains the current value of the ref. This way lookups of dates later than the log end to stick with the current ref value in case the ref was updated without logging. If it looks like someone changed the ref without logging it and we are going to return the sha1 which should have been valid during the missing period then warn the user that there might be log data missing and thus their query result may not be accurate. The check isn't perfect as its just based on comparing the old and new sha1 values between the two log records but its better than not checking at all. Implemented test cases based on git-rev-parse for most of the boundary conditions. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-17Log ref updates to logs/refs/<ref>Libravatar Shawn Pearce1-0/+112
If config parameter core.logAllRefUpdates is true or the log file already exists then append a line to ".git/logs/refs/<ref>" whenever git-update-ref <ref> is executed. Each log line contains the following information: oldsha1 <SP> newsha1 <SP> committer <LF> where committer is the current user, date, time and timezone in the standard GIT ident format. If the caller is unable to append to the log file then git-update-ref will fail without updating <ref>. An optional message may be included in the log line with the -m flag. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>