summaryrefslogtreecommitdiff
path: root/t/t1400-update-ref.sh
AgeCommit message (Collapse)AuthorFilesLines
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>