kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Tom Prince	e0d10e1c63	[PATCH] Rename git-repo-config to git-config. Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	16d7cc90dd	Extend read_ref_at() to be usable from places other than sha1_name. 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>	18 years ago
Shawn O. Pearce	0bee591869	Enable reflogs by default in any repository with a working directory. 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>	18 years ago
Junio C Hamano	ef176ad06a	Fix t1400-update-ref test minimally 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>	19 years ago
Junio C Hamano	8aac4b45f3	t1400: make test debuggable. 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>	19 years ago
Shawn Pearce	818f477c40	Display an error from update-ref if target ref name is invalid. 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>	19 years ago
Eric Wong	8ff99e7417	tests: Set EDITOR=: and VISUAL=: globally 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>	19 years ago
Shawn Pearce	a3a733e63b	Record the type of commit operation in the reflog. 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>	19 years ago
Shawn Pearce	9c7466fa24	Verify git-commit provides a reflog message. 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>	19 years ago
Shawn Pearce	cce91a2cae	Change 'master@noon' syntax to 'master@{noon}'. 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>	19 years ago
Shawn Pearce	e52290428b	General ref log reading improvements. 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>	19 years ago
Shawn Pearce	6de08ae688	Log ref updates to logs/refs/<ref> 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>	19 years ago

12 Commits (c075aea5da6c35edfe86da7d3edced67cdb009c8)