kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Uwe Kleine-König	4ef40cdbe8	add replay and log to the usage string of git-bisect Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	4c55068683	bisect: it needs to be done in a working tree. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Junio C Hamano	08f1675059	Use "git checkout -q" in git-bisect Converts one use of git-checkout in git-bisect not to say "switching to branch". It looks like all the other cases it is friendlier to give notice to the end user. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Petr Baudis	9b709e47ae	bisect reset: Leave the tree in usable state if git-checkout failed I had local modifications in the tree and doing bisect reset required me to manually edit .git/HEAD. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
Michal Rokos	d9bffc08fd	Using 'perl' in *.sh Some GIT's shell script are using bare 'perl' for perl invocation. Use @@PERL@@ symbol and replace it with PERL_PATH_SQ everywhere. Signed-off-by: Michal Rokos <michal.rokos@nextsoft.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	4631c0035d	bisect: remove BISECT_NAMES after done. I noticed that we forgot to clean this file and kept it that way, while trying to help with Andrew's bisect problem. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Petr Baudis	810255fd12	Properly git-bisect reset after bisecting from non-master head git-bisect reset without an argument would return to master even if the bisecting started at a non-master branch. This patch makes it save the original branch name to .git/head-name and restore it afterwards. This is also compatible with Cogito and cg-seek, so cg-status will show that we are seeked on the bisect branch and cg-reset will properly restore the original branch. git-bisect start will refuse to work if it is not on a bisect but .git/head-name exists; this is to protect against conflicts with other seeking tools. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Fredrik Kuivinen	d025524d9d	Usage message clean-up, take #2 There were some problems with the usage message clean-up patch series. I hadn't realised that subdirectory aware scripts can't source git-sh-setup. I propose that we change this and let the scripts which are subdirectory aware set a variable, SUBDIRECTORY_OK, before they source git-sh-setup. The scripts will also set USAGE and possibly LONG_USAGE before they source git-sh-setup. If LONG_USAGE isn't set it defaults to USAGE. If we go this way it's easy to catch --help in git-sh-setup, print the (long) usage message to stdout and exit cleanly. git-sh-setup can define a 'usage' shell function which can be called by the scripts to print the short usage string to stderr and exit non-cleanly. It will also be easy to change $0 to basename $0 or something else, if would like to do that sometime in the future. What follows is a patch to convert a couple of the commands to this style. If it's ok with everyone to do it this way I will convert the rest of the scripts too. [jc: thrown in to proposed updates queue for comments.] Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Jason Riedy	9754563ca9	Use printf rather than echo -n. On AIX, there is no -n option to the system's echo. Instead, it needs the '\c' control character. We could replace echo -n "foo" with echo -e "foo\c" but printf is recommended by most man pages. Tested on AIX 5.3, Solaris 8, and Debian. [jc: futureproofed two instances that uses variable with '%s' so later feeding different messages would not break things too easily; others are emitting literal so whoever changes the literal ought to notice more easily so they are safe.] Signed-off-by: E. Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	e9a45d75b5	bisect: quote pathnames for eval safety. ... and make sure they are on the same line. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	b3cfd939c3	bisect: limit the searchspace by pathspecs It was surprisingly easy to do. git bisect start <pathspec> followed by all the normal "git bisect good/bad" stuff. Almost totally untested, and I guarantee that if your pathnames have spaces in them (or your GIT_DIR has spaces in it) this won't work. I don't know how to fix that, my shell programming isn't good enough. This involves small changes to make "git-rev-list --bisect" work in the presense of a pathspec limiter, and then truly trivial (and that's the broken part) changes to make "git bisect" save away and use the pathspec. I tried one bisection, and a "git bisect visualize", and it all looked correct. But hey, don't be surprised if it has problems. Linus Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	ae2b0f1518	git-sh-setup: die if outside git repository. Now all the users of this script detect its exit status and die, complaining that it is outside git repository. So move the code that dies from all callers to git-sh-setup script. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	8098a178b2	Add git-symbolic-ref This adds the counterpart of git-update-ref that lets you read and create "symbolic refs". By default it uses a symbolic link to represent ".git/HEAD -> refs/heads/master", but it can be compiled to use the textfile symbolic ref. The places that did 'readlink .git/HEAD' and 'ln -s refs/heads/blah .git/HEAD' have been converted to use new git-symbolic-ref command, so that they can deal with either implementation. Signed-off-by: Junio C Hamano <junio@twinsun.com>	20 years ago
Junio C Hamano	434d036fe4	Do not fail after calling bisect_auto_next() As a convenience measure, 'bisect bad' or 'bisect good' automatically does 'bisect next' when it knows it can, but the result of that test to see if it can was leaking through as the exit code from the whole thing, which was bad. Noticed by Anton Blanchard. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	e204de28e6	Keep bisection log so that it can be replayed later. The 'git bisect' command was very unforgiving in that once you made a mistake telling it good/bad it was very hard to take it back. Keep a log of what you told it in an earlier session, so that it can be replayed after removing everything after what you botched last time. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	215a7ad1ef	Big tool rename. As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	cc9f24d024	'git bisect visualize' Linus says: I'm testing bisection to find a bug that causes my G5 to no longer boot, and during the process have found this command line very nice: gitk bisect/bad --not $(cd .git/refs ; ls bisect/good-*) it basically shows the state of bisection with the known bad commit as the top, and cutting off all the good commits - so what you see are the potential buggy commits. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Linus Torvalds	670f5fe34f	[PATCH] Fix bisection terminating condition When testing bisection and using gitk to visualize the result, it was obvious that the termination condition was broken. We know what the bad entry is only when the bisection ends up telling us to test the known-bad entry again. Also, add a safety net: if somebody marks as good something that includes the known-bad point, we now notice and complain, instead of writing an empty revision to the new bisection branch. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	ff84d327df	Audit rev-parse users again. Some callers to rev-parse were using the output selection flags inconsistently. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Junio C Hamano	7f47e72fb3	git-bisect termination condition fix. When I munged the original from Linus, which did not terminate when the last bisect to check happened to be a bad one, to terminate, I seem to have botched the end result to pick. Thanks for Sanjoy Mahajan for a good reproduction recipe to diagnose this. Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Linus Torvalds	8cc6a08319	[PATCH] Making it easier to find which change introduced a bug This adds a new "git bisect" command. - "git bisect start" start bisection search. - "git bisect bad <rev>" mark some version known-bad (if no arguments, then current HEAD) - "git bisect good <revs>..." mark some versions known-good (if no arguments, then current HEAD) - "git bisect reset <branch>" done with bisection search and go back to your work (if no arguments, then "master"). The way you use it is: git bisect start git bisect bad # Current version is bad git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version # tested that was good When you give at least one bad and one good versions, it will bisect the revision tree and say something like: Bisecting: 675 revisions left to test after this and check out the state in the middle. Now, compile that kernel, and boot it. Now, let's say that this booted kernel works fine, then just do git bisect good # this one is good which will now say Bisecting: 337 revisions left to test after this and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection. Until you have no more left, and you'll have been left with the first bad kernel rev in "refs/bisect/bad". Oh, and then after you want to reset to the original head, do a git bisect reset to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch). Not really any harder than doing series of "quilt push" and "quilt pop", now is it? [jc: This patch is a rework based on what Linus posted to the list. The changes are: - The original introduced four separate commands, which was three too many, so I merged them into one with subcommands. - Since the next thing you would want to do after telling it "bad" and "good" is always to bisect, this version does it automatically for you. - I think the termination condition was wrong. The original version checked if the set of revisions reachable from next bisection but not rechable from any of the known good ones is empty, but if the current bisection was a bad one, this would not terminate, so I changed it to terminate it when the set becomes a singleton or empty. - Removed the use of shell array variable. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago

17 Commits (f8f2aaa17297d6b21c84641edc2f6135575a003c)