Staging
v0.5.1
swh:1:snp:c5feb7ee9221a3820c8879e85e8a18470c0b3afa

sort by:
Revision Author Date Message Commit Date
3857284 Merge refs/heads/master from . 25 August 2005, 01:54:24 UTC
5690614 [PATCH] Fix silly pathspec bug in git-ls-files The "verify_pathspec()" function doesn't test for ending NUL character in the pathspec, causing some really funky and unexpected behaviour. It just happened to work in the cases I had tested. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 August 2005, 01:53:29 UTC
ab22707 [PATCH] Fix git-checkout-script exit status Sometimes the git-read-tree in git-checkout-script fails for me. Make sure that the failed status is passed up to caller. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 25 August 2005, 01:53:15 UTC
96fdc21 Merge refs/heads/master from . 25 August 2005, 00:50:26 UTC
9e3e2a5 Fix markup minimally to get man pages built. Signed-off-by: Junio C Hamano <junkio@cox.net> 25 August 2005, 00:50:05 UTC
434d6ba Merge refs/heads/master from . 24 August 2005, 23:56:48 UTC
c951734 Update tutorial to describe shared repository style a bit more. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:55 UTC
ab9b313 Documentation: multi-head fetch. Add documentation related to multi-head work, including $GIT_DIR/remotes/ changes. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:54 UTC
ff27adf Support +<src>:<dst> format in push as well. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:53 UTC
efe9bf0 [PATCH] Allow "+remote:local" refspec to cause --force when fetching. With this we could say: Pull: master:ko-master +pu:ko-pu to mean "fast forward ko-master with master, overwrite ko-pu with pu", and the latter one does not require the remote "pu" to be descendant of local "ko-pu". Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:53 UTC
521003f [PATCH] Use git-octopus when pulling more than one heads. With this, you can finally say "git pull jgarzik sil24 pdc2027x". Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:52 UTC
ae2da40 [PATCH] "git fetch --force". Just like "git push" can forcibly update a ref to a value that is not a fast-forward, teach "git fetch" to do so as well. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:52 UTC
6687f8f [PATCH] Use .git/remote/origin, not .git/branches/origin. Now multi-head fetch is complete, let's migrate the default configuration for new repositories created with the "git clone" command. The original $GIT_DIR/branches is not deprecated yet, but create remotes directory by default from the templates as well. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:52 UTC
92c533e [PATCH] Make "git pull" and "git fetch" default to origin Amos Waterland sent in a patch for the pre-multi-head aware version of "git pull" to do this, but the code changed quite a bit since then. If there is no argument given to pull from, and if "origin" makes sense, default to fetch/pull from "origin" instead of barfing. [jc: besides, the patch by Amos broke the non-default case where explicit refspecs are specified, and did not make sure we know what "origin" means before defaulting to it.] Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:51 UTC
d9f3be7 [PATCH] Infamous 'octopus merge' This script uses the list of heads and their origin multi-head "git fetch" left in the $GIT_DIR/FETCH_HEAD file, and makes an octopus merge on top of the current HEAD using them. The implementation tries to be strict for the sake of safety. It insists that your working tree is clean (no local changes) and matches the HEAD, and when any of the merged heads does not automerge, the whole process is aborted and tries to rewind your working tree is to the original state. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:51 UTC
e0bfc81 [PATCH] Retire git-parse-remote. Update git-pull to match updated git-fetch and allow pull to fetch from multiple remote references. There is no support for resolving more than two heads, which will be done with "git octopus". Update "git ls-remote" to use git-parse-remote-script. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:50 UTC
853a369 [PATCH] Multi-head fetch. Traditionally, fetch takes these forms: $ git fetch <remote> $ git fetch <remote> <head> $ git fetch <remote> tag <tag> This patch updates it to take $ git fetch <remote> <refspec>... where: - A <refspec> of form "<src>:<dst>" is to fetch the objects needed for the remote ref that matches <src>, and if <dst> is not empty, store it as a local <dst>. - "tag" followed by <next> is just an old way of saying "refs/tags/<next>:refs/tags/<next>"; this mimics the current behaviour of the third form above and means "fetch that tag and store it under the same name". - A single token <refspec> without colon is a shorthand for "<refspec>:" That is, "fetch that ref but do not store anywhere". - when there is no <refspec> specified - if <remote> is the name of a file under $GIT_DIR/remotes/ (i.e. a new-style shorthand), then it is the same as giving the <refspec>s listed on Pull: line in that file. - if <remote> is the name of a file under $GIT_DIR/branches/ (i.e. an old-style shorthand, without trailing path), then it is the same as giving a single <refspec> "<remote-name>:refs/heads/<remote>" on the command line, where <remote-name> is the remote branch name (defaults to HEAD, but can be overridden by .git/branches/<remote> file having the URL fragment notation). That is, "fetch that branch head and store it in refs/heads/<remote>". - otherwise, it is the same as giving a single <refspec> that is "HEAD:". The SHA1 object names of fetched refs are stored in FETCH_HEAD, one name per line, with a comment to describe where it came from. This is later used by "git resolve" and "git octopus". Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:50 UTC
ac4b0cf [PATCH] Start adding the $GIT_DIR/remotes/ support. All the necessary parsing code is in git-parse-remote-script; update git-push-script to use it. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:49 UTC
d998a08 [PATCH] Fix "prefix" mixup in git-rev-list Recent changes in git have broken cg-log. git-rev-list no longer prints "commit" in front of commit hashes. It turn out a local "prefix" variable in main() shadows a file-scoped "prefix" variable. The patch removed the local "prefix" variable since its value is never used (in the intended way, that is). The call to setup_git_directory() is kept since it has useful side effects. The file-scoped "prefix" variable is renamed to "commit_prefix" just in case someone reintroduces "prefix" to hold the return value of setup_git_directory(). Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 23:50:16 UTC
ff84d32 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> 24 August 2005, 21:31:36 UTC
4866ccf Rationalize output selection in rev-parse. Earlier rounds broke 'whatchanged -p'. In attempting to fix this, make two axis of output selection in rev-parse orthogonal: --revs-only tells it not to output things that are not revisions nor flags that rev-list would take. --no-revs tells it not to output things that are revisions or flags that rev-list would take. --flags tells it not to output parameters that do not start with a '-'. --no-flags tells it not to output parameters that starts with a '-'. So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386', while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'. Also the meaning of --verify has been made stronger. It now rejects anything but a single valid rev argument. Earlier it passed some flags through without complaining. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 21:30:04 UTC
ccf1ee3 Generate pack info file after repack. Pulling from a packed repository over dumb transport without the server info file fails, so run update-server-info automatically after a repack by default. This can be disabled with the '-n' flag. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 17:40:58 UTC
168cc63 Merge refs/heads/master from . 24 August 2005, 04:30:42 UTC
0d6a873 Link the tutorial from the main document. And lead the reader to it at the beginning of the manual. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 04:18:49 UTC
9585e40 Try to find the optimum merge base while resolving. The merge-base command acquires a new option, '--all', that causes it to output all the common ancestor candidates. The "git resolve" command then uses it to pick the optimum merge base by picking the one that results in the smallest number of nontrivial merges. Signed-off-by: Junio C Hamano <junkio@cox.net> 24 August 2005, 04:08:59 UTC
58eaf28 Merge refs/heads/master from . 23 August 2005, 22:32:17 UTC
2a29da7 Tutorial updates. - Use "working tree", "object name", "repository" as the canonical term consistenly. - Start formatting tutorial with asciidoc. - Mention shared repository style of cooperation. - Update with some usability enhancements recently made, such as the "-m" flag to the "git commit" command. Signed-off-by: Junio C Hamano <junkio@cox.net> 23 August 2005, 22:28:34 UTC
0a5a9ea Update git-diff-script. This uses the fixed rev-parse to allow passing diff options to the underlying diff command. For example: $ git diff -r HEAD shows the output in raw-diff format, and $ git diff -p -R HEAD | git apply generates a patch to go back from your working tree to HEAD commit (i.e. an expensive way to say "git checkout -f HEAD"). At the same time, it accidentally removes the use of shell arrays. Signed-off-by: Junio C Hamano <junkio@cox.net> 23 August 2005, 20:18:00 UTC
90e1848 Make "git-rev-list" work within subdirectories This trivial patch makes "git-rev-list" able to handle not being in the top-level directory. This magically also makes "git-whatchanged" do the right thing. Trivial scripting fix to make sure that "git log" also works. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 August 2005, 19:43:57 UTC
0360e99 [PATCH] Fix git-rev-parse --default and --flags handling This makes the argument to --default and any --flags arguments should up correctly, and makes "--" together with --flags act sanely. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 23 August 2005, 19:42:58 UTC
7fc9d69 Add placeholders for missing documents. The text does not say anything interesting, but at least the author list should reflect something close to reality. Signed-off-by: Junio C Hamano <junkio@cox.net> 23 August 2005, 08:49:47 UTC
89305da Merge refs/heads/master from . 23 August 2005, 07:07:17 UTC
45d197a Introduce "reset type" flag to "git reset" I have been feeling that the current behaviour of "git reset" is not quite optimal, but so far could not express exactly what I felt was wrong with it. This patch clarifies it. There are at least two situations you may want to "reset" your working tree. 1. You made a mess in your working tree. You want to switch back to a known good state and start over. This mess may be a result of your own editing, a merge that had too many conflicting changes that you do not feel like to resolve by hand at this moment, or a botched application of a patch you received from somewhere. In this case, you would want to have "git reset HEAD" reset the index file to the tree read from the HEAD commit and the files in the working tree to match index (i.e. "git status" should say "Nothing to commit", without any "unrecorded changes"). The current behaviour leaves the files in the working tree intact, which requires you to run "git checkout -f". Also you need to remember "rm -f" any files that the botched patch may have left in the working tree if the purpose of this "reset" is to attempt to apply it again; most likely the patch would fail if such a file is left behind. 2. You have discovered that commits you made earlier need to be reorganized. The simplest example is to undo the last commit, re-edit some files, and redo the commit. Another simple eample is to undo the last two commits, and commit the changes in those two commits as a single commit. In this case, you would want to have "git reset HEAD^" reset the $GIT_DIR/HEAD to the commit object name of the parent commit of the current commit (i.e. rewinding one commit), leave the index file and the files in the working tree in a state where you can easily make a commit that records a tree that resembles what you have in the current index file and the working tree. The current behaviour is almost OK for this purpose, except that you need to find which files you need to manually run "git add" yourself. They are files that are in the original HEAD commit and not in the commit you are resetting to. The default without the type flag is to do "--mixed", which is the current behaviour. $ git reset [ --hard | --soft | --mixed ] [ <commit-ish> ] A hard reset would be used for 1 and works in this way: (1) remember the set of paths that appear in the current index file (which may even have unmerged entries) and the current $GIT_DIR/HEAD commit. (2) "read-tree --reset" the specified <commit-ish> (default to HEAD), followed by "checkout-cache -f -u -a". (3) remove any files that appear in (1) but not in <commit-ish> from the working tree. (4) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update $GIT_DIR/HEAD with the specified <commit-ish>. (5) remove leftover $GIT_DIR/MERGE_HEAD A soft reset would be used for 2 and works in this way: (1) Make sure that the index file is merged and we do not have MERGE_HEAD; otherwise it does not make sense to do soft reset. (2) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update $GIT_DIR/HEAD with the specified <commit-ish>. Note that with the current behaviour, "git diff" is the way to see what could be committed immediately after "git reset". With the "soft reset" described here you would need to say "git diff HEAD" to find that out. I am not sure what mixed reset (the current behaviour) is good for. If nobody comes up with a good use case it may not be a bad idea to remove it. Signed-off-by: Junio C Hamano <junkio@cox.net> 23 August 2005, 06:19:18 UTC
f5e375c Clean-up output from "git show-branch" and document it. When showing only one branch a lot of default output becomes redundant, so clean it up a bit, and document what is shown. Retire the earlier implementation "git-show-branches-script". Signed-off-by: Junio C Hamano <junkio@cox.net> 23 August 2005, 06:18:17 UTC
f76412e [PATCH] Add 'git show-branch'. The 'git show-branches' command turns out to be reasonably useful, but painfully slow. So rewrite it in C, using ideas from merge-base while enhancing it a bit more. - Unlike show-branches, it can take --heads (show me all my heads), --tags (show me all my tags), or --all (both). - It can take --more=<number> to show beyond the merge-base. - It shows the short name for each commit in the extended SHA1 syntax. - It can find merge-base for more than two heads. Examples: $ git show-branch --more=6 HEAD is almost the same as "git log --pretty=oneline --max-count=6". $ git show-branch --merge-base master mhf misc finds the merge base of the three given heads. $ git show-branch master mhf misc shows logs from the top of these three branch heads, up to their common ancestor commit is shown. $ git show-branch --all --more=10 is poor-man's gitk, showing all the tags and heads, and going back 10 commits beyond the merge base of those refs. Signed-off-by: Junio C Hamano <junkio@cox.net> 23 August 2005, 01:34:10 UTC
4f7599a [PATCH] Add a new extended SHA1 syntax <name>~<num> The new notation is a short-hand for <name> followed by <num> caret ('^') characters. E.g. "master~4" is the fourth generation ancestor of the current "master" branch head, following the first parents; same as "master^^^^" but a bit more readable. This will be used in the updated "git show-branch" command. Signed-off-by: Junio C Hamano <junkio@cox.net> 23 August 2005, 01:34:09 UTC
792fe55 Fix "git-diff-script A B" When "git-diff-script A..B" notation was introduced, it ended up breaking the traditional two revisions notation. [jc: there are other issues with the current "git diff" I would like to address, but they would be left to later rounds. For example, -M and -p flags should not be hardcoded default, and it shouldn't be too hard to rewrite the script without using shell arrays.] Signed-off-by: Junio C Hamano <junkio@cox.net> 23 August 2005, 01:32:38 UTC
56fc510 [PATCH] git-ls-files: generalized pathspecs This generalizes the git "glob" string to be a lot more like the git-diff-* pathspecs (but there are still differences: the diff family doesn't do any globbing, and because the diff family always generates the full native pathname, it doesn't have the issue with ".."). It does three things: - it allows multiple matching strings, ie you can do things like git-ls-files arch/i386/ include/asm-i386/ | xargs grep pattern - the "matching" criteria is a combination of "exact path component match" (the same as the git-diff-* family), and "fnmatch()". However, you should be careful with the confusion between the git-ls-files internal globbing and the standard shell globbing, ie git-ls-files fs/*.c does globbing in the shell, and does something totally different from git-ls-files 'fs/*.c' which does the globbing inside git-ls-files. The latter has _one_ pathspec with a wildcard, and will match any .c file anywhere under the fs/ directory, while the former has been expanded by the shell into having _lots_ of pathspec entries, all of which are just in the top-level fs/ subdirectory. They will happily be matched exactly, but we will thus miss all the subdirectories under fs/. As a result, the first one will (on the current kernel) match 55 files, while the second one will match 664 files! - it uses the generic path prefixing, so that ".." and friends at the beginning of the path spec work automatically NOTE! When generating relative pathname output (the default), a pathspec that causes the base to be outside the current working directory will be rejected with an error message like: fatal: git-ls-files: cannot generate relative filenames containing '..' because we do not actually generate ".." in the output. However, the ".." format works fine for the --full-name case: cd arch/i386/kernel git-ls-files --full-name ../mm/ results in arch/i386/mm/Makefile arch/i386/mm/boot_ioremap.c arch/i386/mm/discontig.c arch/i386/mm/extable.c arch/i386/mm/fault.c arch/i386/mm/highmem.c arch/i386/mm/hugetlbpage.c arch/i386/mm/init.c arch/i386/mm/ioremap.c arch/i386/mm/mmap.c arch/i386/mm/pageattr.c arch/i386/mm/pgtable.c Perhaps more commonly, the generic path prefixing means that "." and "./" automatically get simplified and work properly. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 22 August 2005, 19:58:03 UTC
15ac516 Merge refs/heads/master from . 21 August 2005, 20:59:38 UTC
5be4efb [PATCH] Make "git-ls-files" work in subdirectories This makes git-ls-files work inside a relative directory, and also adds some rudimentary filename globbing support. For example, in the kernel you can now do cd arch/i386 git-ls-files and it will show all files under that subdirectory (and it will have removed the "arch/i386/" prefix unless you give it the "--full-name" option, so that you can feed the result to "xargs grep" or similar). The filename globbing is kind of strange: it does _not_ follow normal globbing rules, although it does look "almost" like a normal file glob (and it uses the POSIX.2 "fnmatch()" function). The glob pattern (there can be only one) is always split into a "directory part" and a "glob part", where the directory part is defined as any full directory path without any '*' or '?' characters. The "glob" part is whatever is left over. For example, when doing git-ls-files 'arch/i386/p*/*.c' the "directory part" is is "arch/i386/", and the "glob part" is "p*/*.c". The directory part will be added to the prefix, and handled efficiently (ie we will not be searching outside of that subdirectory), while the glob part (if anything is left over) will be used to trigger "fnmatch()" matches. This is efficient and very useful, but can result in somewhat non-intuitive behaviour. For example: git-ls-files 'arch/i386/*.[ch]' will find all .c and .h files under arch/i386/, _including_ things in lower subdirectories (ie it will match "arch/i386/kernel/process.c", because "kernel/process.c" will match the "*.c" specifier). Also, while git-ls-files arch/i386/ will show all files under that subdirectory, doing the same without the final slash would try to show the file "i386" under the "arch/" subdirectory, and since there is no such file (even if there is such a _directory_) it will not match anything at all. These semantics may not seem intuitive, but they are actually very practical. In particular, it makes it very simple to do git-ls-files fs/*.c | xargs grep some_pattern and it does what you want. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 21 August 2005, 20:41:28 UTC
e65be0b Merge refs/heads/master from . 21 August 2005, 11:38:33 UTC
1dfcfbc [PATCH] sha1_name: do not accept .git/refs/snap/. I think Linus did a cut & paste from an early JIT code while developing the current extended SHA1 notation, and left it there as a courtesy, but the directory does not deserve to be treated any more specially than, say, .git/refs/bisect. If the subdirectories under .git/refs proliferate, we may want to switch to scanning that hierarchy at runtime, instead of the current hard-coded set, although I think that would be overkill. Signed-off-by: Junio C Hamano <junkio@cox.net> From nobody Mon Sep 17 00:00:00 2001 Subject: [PATCH] Add a new extended SHA1 syntax <name>:<num> From: Junio C Hamano <junkio@cox.net> Date: 1124617434 -0700 The new notation is a short-hand for <name> followed by <num> caret ('^') characters. E.g. "master:4" is the fourth generation ancestor of the current "master" branch head, following the first parents; same as "master^^^^" but a bit more readable. This will be used in the updated "git show-branch" command. Signed-off-by: Junio C Hamano <junkio@cox.net> --- sha1_name.c | 41 +++++++++++++++++++++++++++++++++++++++++ 1 files changed, 41 insertions(+), 0 deletions(-) d5098ce769da46df6d45dc8f41b06dd758fdaea7 diff --git a/sha1_name.c b/sha1_name.c --- a/sha1_name.c +++ b/sha1_name.c @@ -191,9 +191,29 @@ static int get_parent(const char *name, return -1; } +static int get_nth_ancestor(const char *name, int len, + unsigned char *result, int generation) +{ + unsigned char sha1[20]; + int ret = get_sha1_1(name, len, sha1); + if (ret) + return ret; + + while (generation--) { + struct commit *commit = lookup_commit_reference(sha1); + + if (!commit || parse_commit(commit) || !commit->parents) + return -1; + memcpy(sha1, commit->parents->item->object.sha1, 20); + } + memcpy(result, sha1, 20); + return 0; +} + static int get_sha1_1(const char *name, int len, unsigned char *sha1) { int parent, ret; + const char *cp; /* foo^[0-9] or foo^ (== foo^1); we do not do more than 9 parents. */ if (len > 2 && name[len-2] == '^' && @@ -210,6 +230,27 @@ static int get_sha1_1(const char *name, if (parent >= 0) return get_parent(name, len, sha1, parent); + /* name:3 is name^^^, + * name:12 is name^^^^^^^^^^^^, and + * name: is name + */ + parent = 0; + for (cp = name + len - 1; name <= cp; cp--) { + int ch = *cp; + if ('0' <= ch && ch <= '9') + continue; + if (ch != ':') + parent = -1; + break; + } + if (!parent && *cp == ':') { + int len1 = cp - name; + cp++; + while (cp < name + len) + parent = parent * 10 + *cp++ - '0'; + return get_nth_ancestor(name, len1, sha1, parent); + } + ret = get_sha1_basic(name, len, sha1); if (!ret) return 0; 21 August 2005, 10:52:55 UTC
90a734d [PATCH] possible memory leak in diff.c::diff_free_filepair() Here is a patch to fix the problem in the simplest way. 21 August 2005, 10:48:33 UTC
d57306c Create objects/info/ directory in init-db. Signed-off-by: Junio C Hamano <junkio@cox.net> 20 August 2005, 17:59:28 UTC
b909a15 [PATCH] Fix git-commit-script to output on stderr when -v fails When git-commit-script is called with -v option and verify test fails result is print on stdout instead of stderr. [jc: The original patch from Marco updated git-commit-script that still had the piece of code in question, which has been moved to an example hook script on its own, so I transplanted the patch to that new file instead.] Signed-off-by: Marco Costalba <mcostalba@yahoo.it> Signed-off-by: Junio C Hamano <junkio@cox.net> 20 August 2005, 17:54:27 UTC
b0e985d Merge with master to pick up commit hook works. 20 August 2005, 08:47:08 UTC
165e160 git-resolve: dying is good, not showing help is bad. Recent change to make sure we get commit, not tag, accidentally removed its feature of giving a usage help message when it died. Signed-off-by: Junio C Hamano <junkio@cox.net> 20 August 2005, 08:21:21 UTC
b779dd5 Make sample pre-commit hook output Emacs friendly. Use the common error message format, "filename:lineno: body"; this way, problematic lines can be jumped to from the Emacs compilation buffer by C-x `. Signed-off-by: Junio C Hamano <junkio@cox.net> 20 August 2005, 08:05:12 UTC
51890a6 Call prune-packed from "git prune" as well. Add -n (dryrun) flag to git-prune-packed, and call it from "git prune". Signed-off-by: Junio C Hamano <junkio@cox.net> 20 August 2005, 04:38:36 UTC
99b25f0 Merge with master to pick up gitk updates. 19 August 2005, 23:24:29 UTC
4426ac7 Add hooks to tools/git-applypatch. This teachs git-applypatch, which is used from git-applymbox, three hooks, similar to what git-commit-script uses. Signed-off-by: Junio C Hamano <junkio@cox.net> 19 August 2005, 23:23:31 UTC
89e2c5f Add commit hook and make the verification customizable. There are three hooks: - 'pre-commit' is given an opportunity to inspect what is being committed, before we invoke the EDITOR for the commit message; - 'commit-msg' is invoked on the commit log message after the user prepares it; - 'post-commit' is run after a successful commit is made. The first two can interfere to stop the commit. The last one is for after-the-fact notification. The earlier built-in commit checker is now moved to pre-commit. Signed-off-by: Junio C Hamano <junkio@cox.net> 19 August 2005, 23:23:31 UTC
e20ce6a [PATCH] Allow file removal when "git commit --all" is used. After you deleted files from your working tree, automatic git-update-cache used when the "--all" flag is given to "git commit" barfs because it lacks the --remove flag. It can be argued that this is a feature; people should be careful and something with a grave consequence like removing files should be done manually, in which case the current behaviour may be OK. The patch is for people who thinks the user who uses the "--all" flag deserves the danger that comes with the convenience. Comments? Signed-off-by: Junio C Hamano <junkio@cox.net> 19 August 2005, 23:19:16 UTC
b30245c Merge from gitk 19 August 2005, 23:15:59 UTC
0026d54 Merge with master for a couple more fixes. 19 August 2005, 20:55:59 UTC
7f1335c [PATCH] git-rev-list: avoid crash on broken repository When following tags, check for parse_object() success and error out properly instead of segfaulting. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 August 2005, 20:07:43 UTC
cc5625a [PATCH] Fix git-format-patch-script to handle empty messages In case of a commit with an empty message there is no mandatory empty line between headers and body [jc: This makes --mbox output valid even when the commit message does not have anything but its first line, which the one I wrote botched. One side-effect is that it adds an extra blank line at the end even if it has more than one lines, which will be eaten by the receiving end. As Marco says, this is a stop-gap measure. This script needs to be split into two, one that gets the format specifier and a commit ID to write to its standard output, and another that drives that one reading from rev-list. I'll fix things properly when that happens by rewriting the former part in Perl or something more reasonable than the current shell, sed and grep mishmash.] Signed-off-by: Marco Costalba <mcostalba@yahoo.it> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 August 2005, 18:32:54 UTC
106288c Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID. 19 August 2005, 13:11:39 UTC
f1d83ba Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed. 19 August 2005, 12:14:28 UTC
f1d090e Fix __attribute__ changes. It cannot be checked with #ifndef, if you really think about what it does which cannot be done only with the preprocessor. My thinko. Signed-off-by: Junio C Hamano <junkio@cox.net> 19 August 2005, 09:06:52 UTC
14022f5 Merge with master to pick up safety patches. 19 August 2005, 05:10:50 UTC
75ea691 [PATCH] Spell __attribute__ correctly in cache.h. Sun's cc doesn't know __attribute__. Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net> 19 August 2005, 04:55:46 UTC
04c13d3 Save the maxwidth setting in the ~/.gitk file. 19 August 2005, 00:22:24 UTC
022bc2a Fix a bug where commits with no children weren't marked as on-screen. This problem was revealed by running gitk --all on Wolfgang Denk's u-boot repository. 19 August 2005, 00:22:04 UTC
a8055f8 Also make git-rebase-script stricter about dirty working tree. Otherwise the first commit rebase makes could include whatever dirty state the original working tree had. Signed-off-by: Junio C Hamano <junkio@cox.net> 18 August 2005, 23:30:36 UTC
d571c2b [PATCH] git-applymbox: verify that index is clean This makes git-applymbox verify that the index matches the current HEAD before it starts applying patches. Otherwise, you might have updated the index with unrelated changes, and the first patch will commit not just the patch from the mbox, but also any changes you had in your index. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 August 2005, 23:26:50 UTC
1bff649 Link the glossary document from the main manual. Signed-off-by: Junio C Hamano <junkio@cox.net> 18 August 2005, 22:52:58 UTC
d430042 Merge with master. 18 August 2005, 22:46:07 UTC
66e06b6 Stupid typo fix for git rebase. Signed-off-by: Junio C Hamano <junkio@cox.net> 18 August 2005, 20:00:53 UTC
2f5703c [PATCH] Updates to glossary Changes to the descriptions of tree and tag objects, a link for ent, and descriptions for rewind, rebase and core git were added. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 August 2005, 19:53:30 UTC
920b9d9 Merge with master to pick up gitk --parents changes. 18 August 2005, 19:25:18 UTC
9d34c29 Merge with gitk --parents change. 18 August 2005, 19:18:27 UTC
0776f4c Merge with master for gitk and doc updates. 18 August 2005, 18:48:22 UTC
accd952 [PATCH] updates for Documentation/howto/using-topic-branches.txt Small fix (use "git branch" to make branches, rather than "git checkout -b"). Optimization for trivial patches (apply to release and merge to test). Three sample scripts appended. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 August 2005, 17:26:06 UTC
23bb8df [PATCH] Add Makefile target glossary.html This also includes a script which does the sorting, and introduces hyperlinks for every described term. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 August 2005, 17:25:52 UTC
e5ea701 Use the --parents flag to git-rev-list. With --parents, git-rev-list gives us the list of parents on the first line of each commit. We use that rather than looking for the parent: lines in the commit body, since this way we get to know about the grafts for free. 18 August 2005, 10:40:39 UTC
379955c Merge with gitk 18 August 2005, 04:09:15 UTC
f1671ec [PATCH] Assorted changes to glossary Based on the discussion on the git list, here are some important changes to the glossary. (There is no cache, but an index. Use "object name" rather than "SHA1". Reorder. Clarify.) Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 18 August 2005, 02:37:24 UTC
f6075eb Allow graph lines to jump through hyperspace. When the graph gets too wide (as defined by the maxwidth variable, which can be set in ~/.gitk), we can now terminate graph lines with an arrow pointing downwards, and reintroduce them later with an arrow pointing upwards when we need them. This makes the graph much less cluttered on large repositories such as the linux kernel. Unfortunately this has made it slower; it takes about 10 seconds user time on the linux-2.6 repository on my machine now, compared to 6 seconds before. I'll have to work on optimizing that. Also on the todo list are making the arrow heads active (so if you click on them you jump to the other end) and improving the placement of the null entry. 17 August 2005, 23:30:10 UTC
942bc9c Merge from master for misc fixes. 17 August 2005, 22:38:47 UTC
99a92f9 Make rebase script saner. It did not check to see if the working tree was clean and matched the commit we were starting out as, resulting in the initial rebased commit including whatever dirty state the working tree has had. Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 22:19:57 UTC
0f87f89 Make sure alternates are carried over from the original repository. When we create a cheap local clone by pointing at the object databse of the original repository, we forgot to take the alternates the original repository might have had into account. Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 22:18:41 UTC
6a0049c Fix git-commit without paths. The earlier one to grab output from diff-files --name-only has a grave bug that when no paths are given it ended up doing the equivalent of "git-commit --all", which was not what I intended. Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 22:17:03 UTC
cfb0af1 [PATCH] Make git-update-cache take relative pathnames This also makes "./filename" acceptable as a side effect, since the pathname normalization handles that too. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 21:53:40 UTC
828cc61 [PATCH] Export relative path handling "prefix_path()" function Not all programs necessarily have a pathspec array of pathnames, some of them (like git-update-cache) want to do things one file at a time. So export the single-path interface too. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 21:53:39 UTC
049f28c [PATCH] git-cvsimport - remove hardcoded reference to origin ... in the newly introduced merge detection code. Signed-off-by: Martin Langhoff <martin.langhoff@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 21:53:39 UTC
db4b658 [PATCH] Add merge detection to git-cvsimport Added -m and -M flags for git-cvsimport to detect merge commits in cvs. While this trusts the commit message, in repositories where merge commits indicate 'merged from FOOBRANCH' the import works surprisingly well. Even if some merges from CVS are bogus or incomplete, the resulting branches are in better state to go forward (and merge) than without any merge detection. Signed-off-by: Martin Langhoff <martin.langhoff@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 21:53:39 UTC
ca08acc Merge changes from master. 17 August 2005, 21:25:08 UTC
da13981 [PATCH] Add GIT glossary [jc: This is the version without asciidoc cross references; Johannes says that the cross referenced one is generated from this file using a Perl script, so I am placing this as the source, and expecting to later receive the script and a Makefile entry or two to massage this file into the final HTML or whatever form.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 20:50:40 UTC
f01c0fc [PATCH] Let git-format-patch-script write on stdout Avoid that git-format-patch writes out patch series information on stderr when there are no errors Signed-off-by: Marco Costalba <mcostalba@yahoo.it> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 19:13:12 UTC
d5a8664 [PATCH] Be consistent in naming of remote heads The _remote_name variable used for messages does not need the refs/heads/ prefix included. Signed-off-by: Kris Shannon <kris.shannon@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 19:13:12 UTC
cdacb62 [PATCH] use it's and its correctly in documentation At one place in Documentation/tutorial.txt and several in the base README, its was wrongly used in place of it's or vice versa. One instance remains somewhere in Documentation/howto/, which I didn't correct because it's in a quotation. Signed-off-by: Greg Louis <glouis@dynamicro.ca> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 19:13:12 UTC
fbfd60d [PATCH] Also handle CVS branches with a '/' in their name I track a CVS project which has a branch with a '/' in the branch name. Since git wants the branch name to be a file name at the same time, substitute that character to a '-' by default (override with "-s <subst>"). This should work well, despite the fact that a division and a difference are completely different :-) Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 19:13:12 UTC
35cc4bc [PATCH] When copying or renaming, keep the mode, please Without this patch, git-apply does not retain the mode when renaming or copying files. [jc: Good catch, Johannes. I added a test case to demonstrate the breackage in the original.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 19:13:12 UTC
e4aec26 [PATCH] Change git-branch to list branches If no argument provided to `git branch`, show available branches and mark current branch with star. This is based on patch written by Amos Waterland <apw@rossby.metr.ou.edu>. [jc: and I changed it to handle subdirectories under refs/heads/ as well.] Signed-off-by: Kalle Valo <Kalle.Valo@iki.fi> Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 19:11:36 UTC
22cff6a git-commit: pass explicit path to git-diff-files. When running "git commit" with explicit path arguments, allow it to take directory name. This makes "git commit Documentation/" to commit everything that is changed under Documentation/ directory. Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 19:11:36 UTC
86947d7 Pass options to underlying git-rev-list from show-branches. This lets you say "git show-branches --max-count=30". Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 19:11:36 UTC
30b96fc Add --symbolic flag to git-rev-parse. This is most useful with --all, --revs-only, --no-flags and --verify. Signed-off-by: Junio C Hamano <junkio@cox.net> 17 August 2005, 19:11:36 UTC
244edd1 Add graft support. We read .git/info/grafts and use the information in there to override the list of parents we get from git-rev-list or git-cat-file. 17 August 2005, 11:27:55 UTC
6680153 Merge with master to get diff fixes. 17 August 2005, 05:30:46 UTC
back to top