summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2005-06-19read-cache.c: remove stray debugging printfLinus Torvalds
Pointed out by Junio, part of my debugging of the rewrite of the file/dir conflict handling.
2005-06-19Re-implement "check_file_directory_conflict()"Linus Torvalds
This is (imho) more readable, and is also a lot faster. The expense of looking up sub-directory beginnings was killing us on things like "git-diff-cache", even though that one didn't even care at all about the file vs directory conflicts. We really only care when somebody tries to add a conflicting name to stage 0. We should go through the conflict rules more carefully some day.
2005-06-19Avoid warning about function without return.Linus Torvalds
Strangely, this warning only shows up when not compiling with "-O2", which is why I didn't see it originally.
2005-06-18[PATCH] cvs2git and file permissionsSven Verdoolaege
git-cvs2git: propagate mode information Let cvs checkout in a temporary directory rather than using the pipe option to avoid loss of mode information. Signed-off-by: Sven Verdoolaege <skimo@liacs.nl> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-18Make "pretty" commit logs always show merge informationLinus Torvalds
Otherwise the "git log" information doesn't tell enough to make sense of a merge. I'll need to add some parent information for regular entries too, I think, but the merge is more important.
2005-06-18git-rev-list: add "--bisect" flag to find the "halfway" pointLinus Torvalds
This is useful for doing binary searching for problems. You start with a known good and known bad point, and you then test the "halfway" point in between: git-rev-list --bisect bad ^good and you test that. If that one tests good, you now still have a known bad case, but two known good points, and you can bisect again: git-rev-list --bisect bad ^good1 ^good2 and test that point. If that point is bad, you now use that as your known-bad starting point: git-rev-list --bisect newbad ^good1 ^good2 and basically at every iteration you shrink your list of commits by half: you're binary searching for the point where the troubles started, even though there isn't a nice linear ordering.
2005-06-17Use "-M" instead of "-C" for "git diff" and "git status"Linus Torvalds
The "C" in "-C" may stand for "Cool", but it's also pretty slow, since right now it leaves all unmodified files to be tested even if there are no new files at all. That just ends up being unacceptably slow for big projects, especially if it's not all in the cache.
2005-06-17git-apply: use default name for mode change patchesLinus Torvalds
Pure mode changes won't have the file-name in the extended header lines, so make sure we pick it up from the default name from the "diff --git" line.
2005-06-17Don't use -C in "git diff"Linus Torvalds
Right now it confuses at least git-diff-files, since it leaves all the files (whether changed or not) in the diff queue.
2005-06-17Add some installation notes in INSTALLLinus Torvalds
Jens was the second person who hadn't heard of the "merge" program, and didn't have it installed. So document as many dependency and install issues as I can think of.
2005-06-15git-read-tree: fix "--reset" handlingLinus Torvalds
2005-06-15Update tutorial a bit for scripted helpers.Linus Torvalds
2005-06-15Trivial git script fixupsLinus Torvalds
Fix permissions, and add trivial "reset" and "add" scripts. The "reset" script just resets the index back to head, while the "add" script is just a crutch for people used to do "cvs add".
2005-06-14[PATCH] ssh-push: Don't add '/' to pathnameSven Verdoolaege
Paths in the host:path notation are usually interpreted relative to the login directory rather than relative to the root directory. Signed-off-by: Sven Verdoolaege <skimo@liacs.nl> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-14[PATCH] Unset TZ in t5000Mark Allen
Unset TZ to force GMT in test #4 and add a set of parens around the length function in the awk script. Signed-off-by: Mark Allen <mrallen1@yahoo.com> Acked-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-14Make 'git' script be a bit more helpful on unrecognized commandsLinus Torvalds
2005-06-14Make "git commit" handle initial commits tooLinus Torvalds
No need to confuse ex-CVS users with a complex initial commit sequence.
2005-06-14git-apply: normalize file mode when comparing with expected valueLinus Torvalds
Sine git only saves the 'x' bit, we shouldn't compare the stat contents directly.
2005-06-13Add "git diff" scriptLinus Torvalds
It's a simple helper that depending on the arguments will either use git-diff-files, git-diff-cache or git-diff-tree.
2005-06-13Teach git-rev-parse about revision-specifying argumentsLinus Torvalds
Things like "--max-count=xxx" are "rev-only".
2005-06-13git-whatchanged: use the git-rev-parse helperLinus Torvalds
So now you can say git-whatchanged -p v2.6.12-rc5.. drivers/usb and it will show you what changed (as a patch) in drivers/usb since the v2.6.12-rc5 release.
2005-06-13git-rev-parse: split "revs" and "non-revs"Linus Torvalds
Sometimes we only want to output revisions, and sometimes we want to only see the stuff that wasn't revisions. Teach git-rev-parse to understand the "--revs-only" and "--no-revs" flags.
2005-06-13Make "git log" use the new git-rev-parse helperLinus Torvalds
See the previous commit for explanations.
2005-06-13Add 'git-rev-parse' helper scriptLinus Torvalds
It's an incredibly cheesy helper that changes human-readable revision arguments into the git-rev-list argument format. You can use it to do something like this: git-rev-list --pretty $(git-rev-parse --default HEAD "$@") which is what git-log-script will become. Here git-rev-parse will then allow you to use arguments like "v2.6.12-rc5.." or similar human-readable ranges. It's really quite stupid: "a..b" will be converted into "a" and "^b" if "a" and "b" are valid object pointers. And the "--default" case will be used if nothing but flags have been seen, so that you can default to a certain argument if there are no other ranges.
2005-06-13git-apply: fix error handling for nonexistent filesLinus Torvalds
Missing argument for error() function. We should really use the gcc printf format checking capabilities.
2005-06-13[PATCH] git cvsimport fuzz argumentTommy M. McGuire
Add "-z fuzz" argument, passed to cvsps, and clean up argument processing. Also, use "cvsps --cvs-direct", which is is somewhat faster. Give the user the option of specifying the timestamp fuzz passed to cvsps. Looking at the other arguments to it, I can't see anything else that would be sane to play with. Also, use --cvs-direct, which speeds up cvsps for remote repositories and doesn't seem to do anything bad to local repositories. Signed-off-by: Tommy McGuire <mcguire@crsr.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] cvs-migration.txtTommy M. McGuire
Slightly expand the cvsimport description, and make a couple of syntax edits. The way I figure it, telling someone why cvsimport is taking so long will improve their overall user experience. :-) Signed-off-by: Tommy McGuire <mcguire@crsr.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] git cvsimport sanity checkingTommy M. McGuire
This patch adds some sanity checking to git-cvsimport-script, specifically forcing the use of cvsps -x (to get the latest information from the repository, rather than whatever is in the cache) and aborting early if cvsps does not produce any output. I debated removing the $MODULE directory following an abort, but I eventually decided leaving stuff behind would make debugging easier. On the other hand, this patch should help with the "cvsimport left me with an empty repository" complaints. Call cvsps with the -x flag, to get the current state of the repository, and abort the cvs import early if cvsps does not produce any output. Signed-off-by: Tommy McGuire <mcguire@crsr.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] cvsimport: allow remote CVS reposTommy M. McGuire
Remove unneeded sanity tests. Remote repositories do, indeed, just work. Signed-off-by: Tommy McGuire <mcguire@crsr.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] diff-stages: unuglify the too big main() function.Junio C Hamano
Split the core of the program, diff_stage, from one big "main()" function that does it all and leave only the parameter parsing, setup and finalize part in the main(). Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] read-tree: loosen too strict index requirementsJunio C Hamano
This patch teaches read-tree 3-way merge that, when only "the other tree" changed a path, and if the index file already has the same change, we are not in a situation that would clobber the index and the work tree, and lets the merge succeed; this is case #14ALT in t1000 test. It does not change the result of the merge, but prevents it from failing when it does not have to. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] Finish making --emu23 equivalent to pure 2-way merge.Junio C Hamano
This adds #3ALT rule (and #2ALT rule for symmetry) to the read-tree 3-way merge logic that collapses paths that are added only in one branch and not in the other internally. This makes --emu23 to succeed in the last remaining case where the pure 2-way merge succeeded and earlier one failed. Running diff between t1001 and t1005 test scripts shows that the only difference between the two is that --emu23 can leave the states into separate stages so that the user can use usual 3-way merge resolution techniques to carry forward the local changes when pure 2-way merge would have refused to run. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] read-tree: fix too strong index requirement #5ALTJunio C Hamano
This fixes too strong index requirement 3-way merge enforces in one case: the same file is added in both branches. In this case, the original code insisted that if the index file has that path, it must match our branch and be up-to-date. However in this particular case, it only has to match it, and can be dirty. We just need to make sure that we keep the work-tree copy instead of checking out the merge result. The resolution of such a path, however, cannot be left to outside script, because we will not keep the original stage0 entries for unmerged paths when read-tree finishes, and at that point, the knowledge of "if we resolve it to match the new file added in both branches, the merge succeeds and the work tree would not lose information, but we should _not_ update the work tree from the resulting index file" is lost. For this reason, the now code needs to resolve this case (#5ALT) internally. This affects some existing tests in the test suite, but all in positive ways. In t1000 (3-way test), this #5ALT case now gets one stage0 entry, instead of an identical stage2 and stage3 entry pair, for such a path, and one test that checked for merge failure (because the test assumed the "stricter-than-necessary" behaviour) does not have to fail anymore. In t1005 (emu23 test), two tests that involves a case where the work tree already had a change introduced in the upstream (aka "merged head"), the merge succeeds instead of failing. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] read-tree --emu23.Junio C Hamano
This new flag causes two-way fast forward to internally use the three-way merge mechanism. This behaviour is intended to offer a better fast forward semantics when used in a dirty work tree. The new test t1005 is parallel to the existing t1001 "pure 2-way" tests, but some parts that are commented out would fail. These failures are due to three-way merge enforcing too strict index requirements for cases that could succeed. This problem will be addressed by later patches. Without even changing three-way mechanism, the --emu23 two-way fast forward already gives the user an easier-to-handle merge result when a file that "merged head" updates has local modifications. This is demonstrated as "case 16" test in t1005. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] Clean up read-tree two-way tests.Junio C Hamano
This is in preparation for "2-way fast-forward emulated with 3-way mechanism" series. It does not change what the tests for pure 2-way do. It only changes how it tests things, to make reviewing of differences of the two tests easier in later steps. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] Add --diff-filter= output restriction to diff-* family.Junio C Hamano
This is a halfway between debugging aid and a helper to write an ultra-smart merge scripts. The new option takes a string that consists of a list of "status" letters, and limits the diff output to only those classes of changes, with two exceptions: - A broken pair (aka "complete rewrite"), does not match D (deleted) or N (created). Use B to look for them. - The letter "A" in the diff-filter string does not match anything itself, but causes the entire diff that contains selected patches to be output (this behaviour is similar to that of --pickaxe-all for the -S option). For example, $ git-rev-list HEAD | git-diff-tree --stdin -s -v -B -C --diff-filter=BCR shows a list of commits that have complete rewrite, copy, or rename. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] diff-tree: --find-copies-harderJunio C Hamano
Normally, diff-tree does not feed unchanged filepair to diffcore for performance reasons, so copies are detected only when the source file of the copy happens to be modified in the same changeset. This adds --find-copies-harder flag to tell diff-tree to sacrifice the performance in order to find copies the same way as other commands in diff-* family. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] Tutorial update to adjust for -B fixJunio C Hamano
Now -B does not say silly "complete rewrite" anymore for small files such as the one in the tutorial example. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] Fix rename/copy when dealing with temporarily broken pairs.Junio C Hamano
When rename/copy uses a file that was broken by diffcore-break as the source, and the broken filepair gets merged back later, the output was mislabeled as a rename. In this case, the source file ends up staying in the output, so we should label it as a copy instead. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13git-whatchanged: make default output format be pretty.Linus Torvalds
If you want the raw stuff, just do git-whatchanged --pretty=raw and it wil act like it used to.
2005-06-13git-diff-tree: fix output with just "--pretty".Linus Torvalds
It set verbose, but didn't set the output prefix to "diff-tree".
2005-06-13[PATCH] Support commit_format in diff-treeJunio C Hamano
This steals --pretty command line option from rev-list and teaches diff-tree to do the same. With this change, $ git-whatchanged --pretty would work as expected. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-13[PATCH] Re-Fix SIGSEGV on unmerged files in git-diff-files -pJunio C Hamano
When an unmerged path was fed via diff_unmerged() into diffcore, it eventually called run_diff() with "one" and "two" parameters with NULL, but run_diff() was not written carefully enough to notice this situation. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-12git-apply: ignore empty git headersLinus Torvalds
A meaningful (ie non-empty) git patch always has more information in the header than just the "diff --git" line itself: it needs to have either a patch associated with it (which implies "---" and "+++" lines in the header) or it needs to have rename/copy/delete/create information in it. Just ignore git patches which have no change information. Otherwise we'll end up with a patch that doesn't have filenames etc filled in, and we'll be unhappy.
2005-06-10[PATCH] Bugfix: read-cache.c:write_cache() misrecords number of entries.Junio C Hamano
When we choose to omit deleted entries, we should subtract numbers of such entries from the total number in the header. Signed-off-by: Junio C Hamano <junkio@cox.net> Oops. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-09git-read-tree: remove deleted files in the working directoryLinus Torvalds
Only when "-u" is used of course.
2005-06-09[PATCH] Add git-diff-stages command.Junio C Hamano
The diff-* brothers acquired a sibling, git-diff-stages. With an unmerged index file, you specify two stage numbers and it shows the differences between them. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-09git-read-tree: add "--reset" flagLinus Torvalds
This is the same as "-m", but it will silently ignore any unmerged entries, which makes it useful for efficiently forcing a new position regardless of the state of the current index file. IOW, to reset to a previous HEAD (in case you have had a failed merge, for example), you'd just do git-read-tree -u --reset HEAD which will also update your working tree to the right state. NOTE! The "update" will not remove files that may have been added by the merge. Yet.
2005-06-09One more time.. Clean up git-merge-one-file-scriptLinus Torvalds
This uses git-checkout-file to make sure that the full pathname is created, instead of the script having to verify it by hand. Also, simplify the 3-way merge case by just writing to the right file and setting the initial index contents early.
2005-06-09Fix up git-merge-one-file-scriptLinus Torvalds
Junio points out that we may need to create the path leading up the the file we merge. And we need to be more careful with the "exec"s we've done to exit on success - only do the on the last command in the pipeline, not the first one ;)