summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2005-12-27send-pack/receive-pack: allow errors to be reported back to pusher.Libravatar Junio C Hamano3-39/+148
This updates the protocol between git-send-pack/git-receive-pack in a backward compatible way to allow failures at the receiving end to be propagated back to the sender. Most notably, versions of git-push before this could not notice if the update hook on the receiving end refused to update the ref for its own policy reasons. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-27Makefile: use git-describe to mark the git version.Libravatar Junio C Hamano3-5/+34
Note: with this commit, the GIT maintainer workflow must change. GIT-VERSION-GEN is now the file to munge when the default version needs to be changed, not Makefile. The tag needs to be pushed into the repository to build the official tarball and binary package beforehand. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-27git-describe: documentation.Libravatar Junio C Hamano2-0/+82
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-27git-describe: still prefer annotated tag under --all and --tagsLibravatar Junio C Hamano1-9/+25
Even though --all and --tags can be used to include non annotated tags in the reference point candidates, prefer to use annotated tags if there are more than one refs that name the same commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-27git-describe: --tags and --abbrevLibravatar Junio C Hamano1-6/+27
With --tags, not just annontated tags, but also any ref under refs/tags/ are used to name the revision. The number of digits is configurable with the --abbrev=<n> option. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-27git-describe: use find_unique_abbrev()Libravatar Junio C Hamano1-1/+2
Just in case 8 hexadecimal digits are not enough. We could use shorter default if we wanted to. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-27git-describe: really prefer tags only.Libravatar Junio C Hamano1-4/+11
Often there are references other than annotated tags under refs/tags hierarchy that are used to "keep things just in case". default to use annotated tags only, still leaving the option to use any ref with --all flag. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-27Add a "git-describe" commandLibravatar Linus Torvalds2-1/+120
It shows you the most recent tag that is reachable from a particular commit is. Maybe this is something that "git-name-rev" should be taught to do, instead of having a separate command for it. Regardless, I find it useful. What it does is to take any random commit, and "name" it by looking up the most recent commit that is tagged and reachable from that commit. If the match is exact, it will just print out that ref-name directly. Otherwise it will print out the ref-name, followed by the 8-character "short SHA". IOW, with something like Junios current tree, I get: [torvalds@g5 git]$ git-describe parent refs/tags/v1.0.4-g2414721b ie the current head of my "parent" branch (ie Junio) is based on v1.0.4, but since it has a few commits on top of that, it has added the git hash of the thing to the end: "-g" + 8-char shorthand for the commit 2414721b194453f058079d897d13c4e377f92dc6. Doing a "git-describe" on a tag-name will just show the full tag path: [torvalds@g5 git]$ git-describe v1.0.4 refs/tags/v1.0.4 unless there are _other_ tags pointing to that commit, in which case it will just choose one at random. This is useful for two things: - automatic version naming in Makefiles, for example. We could use it in git itself: when doing "git --version", we could use this to give a much more useful description of exactly what version was installed. - for any random commit (say, you use "gitk <pathname>" or "git-whatchanged" to look at what has changed in some file), you can figure out what the last version of the repo was. Ie, say I find a bug in commit 39ca371c45b04cd50d0974030ae051906fc516b6, I just do: [torvalds@g5 linux]$ git-describe 39ca371c45b04cd50d0974030ae051906fc516b6 refs/tags/v2.6.14-rc4-g39ca371c and I now know that it was _not_ in v2.6.14-rc4, but was presumably in v2.6.14-rc5. The latter is useful when you want to see what "version timeframe" a commit happened in. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-26Merge fixes up to GIT 1.0.5Libravatar Junio C Hamano10-22/+136
2005-12-26GIT 1.0.5Libravatar Junio C Hamano11-23/+137
Minor fixes. Starting from this one I won't be touching debian/ directory since the official maintainer seems to be reasonably quick to package up things. The packaging procedure used there seems to be quite different from what I have, so I'd like to avoid potential confusion and reduce work by the official maintainer and myself. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-26Handle symlinks graciouslyLibravatar Johannes Schindelin2-1/+86
This patch converts a stat() to an lstat() call, thereby fixing the case when the date of a symlink was not the same as the one recorded in the index. The included test case demonstrates this. This is for the case that the symlink points to a non-existing file. If the file exists, worse things than just an error message happen. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-26t5300: avoid false failures.Libravatar Junio C Hamano1-1/+7
Johannes found that the test has 1/256 chance of falsely producing an uncorrupted idx file, causing the check to detect corruption fail. Now we have 1/2^160 chance of false failure ;-). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-26avoid asking ?alloc() for zero bytes.Libravatar Junio C Hamano6-19/+39
Avoid asking for zero bytes when that change simplifies overall logic. Later we would change the wrapper to ask for 1 byte on platforms that return NULL for zero byte request. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-26short circuit out of a few places where we would allocate zero bytesLibravatar Eric Wong2-1/+4
dietlibc versions of malloc, calloc and realloc all return NULL if they're told to allocate 0 bytes, causes the x* wrappers to die(). There are several more places where these calls could end up asking for 0 bytes, too... Maybe simply not die()-ing in the x* wrappers if 0/NULL is returned when the requested size is zero is a safer and easier way to go. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-25Merge branch 'jc/checkout'Libravatar Junio C Hamano2-5/+28
2005-12-24Tutorial: mention shared repository management.Libravatar Junio C Hamano1-0/+18
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-24git-init-db: initialize shared repositories with --sharedLibravatar Johannes Schindelin1-10/+22
Now you can say git-init-db --shared if you want other users to be able to push into that repository. [jc: info/ and objects/info/ need to be group writable if the repository is shared --- otherwise packs and refs files cannot be updated.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-24Introduce core.sharedrepositoryLibravatar Johannes Schindelin4-1/+36
If the config variable 'core.sharedrepository' is set, the directories $GIT_DIR/objects/ $GIT_DIR/objects/?? $GIT_DIR/objects/pack $GIT_DIR/refs $GIT_DIR/refs/heads $GIT_DIR/refs/heads/tags are set group writable (and g+s, since the git group may be not the primary group of all users). Since all files are written as lock files first, and then moved to their destination, they do not have to be group writable. Indeed, if this leads to problems you found a bug. Note that -- as in my first attempt -- the config variable is set in the function which checks the repository format. If this were done in git_default_config instead, a lot of programs would need to be modified to call git_config(git_default_config) first. [jc: git variables should be in environment.c unless there is a compelling reason to do otherwise.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-24Merge fixes up to GIT 1.0.4Libravatar Junio C Hamano6-15/+86
2005-12-24GIT 1.0.4Libravatar Junio C Hamano9-17/+109
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-23mailinfo: iconv does not like "latin-1" -- should spell it "latin1"Libravatar Junio C Hamano1-1/+1
This was a stupid typo that did not follow http://www.iana.org/assignments/character-sets Long noticed but neglected by JC, but finally reported by Marco. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-23ls-files --full-name: usage string and documentation.Libravatar Junio C Hamano2-2/+9
Somehow this option was not mentioned anywhere in the documentation nor the usage string. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-23merge --no-commit: tweak messageLibravatar Junio C Hamano1-1/+10
We did not distinguish the case the user asked not to make a commit with --no-commit flag and the automerge failed. Tell these cases apart and phrase dying message differently. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-23git-clone: do not special case dumb http.Libravatar Junio C Hamano1-15/+1
Underlying http-fetch is supposed to be capable of handling packed repositories just fine, so no need to special case it in the wrapper script. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-23show-branch: usability updates.Libravatar Junio C Hamano1-11/+60
This does three things: . It simplifies the logic to handle the case in which no refs are given on the command line, and fixes the bug when only "--heads" is specified. Earlier we showed them twice. . It avoids to add the same ref twice. . It sorts the glob result (e.g. "git show-branch 'tags/v1.0*'") according to a more version friendly sort order. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-23check_packed_git_idx(): check integrity of the idx file itself.Libravatar Junio C Hamano2-1/+22
Although pack-check.c had routine to verify the checksum for the pack index file itself, the core did not check it before using it. This is stolen from the patch to tighten packname requirements. Signed-off-by: Junio C Hamano <junkio@cox.net> (cherry picked from 797bd6f490c91c07986382b9f268e0df712cb246 commit)
2005-12-23Adjust to ls-tree --full-name when run from a subdirectory.Libravatar Junio C Hamano2-5/+19
A proposed change to show cwd relative paths by default from ls-tree when run from a subdirectory means we would need to give --full-name option to it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-23ls-tree: chomp leading directories when run from a subdirectoryLibravatar Junio C Hamano1-4/+18
When run from a subdirectory, even though we filtered the output based on where we were using pathspec, we wrote out the repository relative paths, not subtree relative paths. This changes things so that it shows only the current subdirectory relative paths. For example, in Documentation subdirectory of git itself, this used to be the case: $ git-ls-tree --name-only HEAD | grep how Documentation/git-show-branch.txt Documentation/git-show-index.txt Documentation/howto-index.sh Documentation/howto But now it does this instead: $ git-ls-tree --name-only HEAD | grep how git-show-branch.txt git-show-index.txt howto-index.sh howto There are two things to keep in mind. 1. This shows nothing. $ git-ls-tree --name-only HEAD ../ppc/ This is to make things consistent with ls-files, which refuses relative path that goes uplevel. 2. These show things in full repository relative paths. In this case, paths outside the current subdirectory are also shown. $ git-ls-tree --name-only --full-name HEAD | grep how Documentation/git-show-branch.txt Documentation/git-show-index.txt Documentation/howto-index.sh Documentation/howto $ git-ls-tree --name-only --full-name HEAD ../ppc/ ppc/sha1.c ppc/sha1.h ppc/sha1ppc.S The flag --full-name gives the same behaviour as 1.0, so it ought to be the default if we really care about the backward compatibility, but in practice no Porcelain runs ls-tree from a subdirectory yet, and without --full-name is more human friendly, so hopefully the default being not --full-name would be acceptable. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-22checkout: sometimes work from a subdirectory.Libravatar Junio C Hamano1-0/+9
git-checkout does two very different things, and what they should do when run from subdirectory are quite different. It does not make any sense to run the one that switches the current head from anywhere other than the toplevel: git-checkout [-f] <branch> git-checkout [-b <branch>] <committish> We could of course chdir to top and do the whole-tree checkout in git-checkout, but the point is the operation does not make sense on a partial tree. The whole tree is checked out. The other form is to update the index file and working tree file selectively: git-checkout <treeish> <file>... ;# out of tree to index and file git-checkout -- <file>... ;# out of index to file This form _does_ make sense to run from subdirectory; and I myself often wish we supported this. So here is a patch to do both. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-22check_packed_git_idx(): check integrity of the idx file itself.Libravatar Junio C Hamano2-1/+22
Although pack-check.c had routine to verify the checksum for the pack index file itself, the core did not check it before using it. This is stolen from the patch to tighten packname requirements. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-22rev-parse: --show-cdupLibravatar Junio C Hamano2-1/+18
When --show-prefix is useful, sometimes it is easier to cd up to the toplevel of the tree. This is equivalent to: git rev-parse --show-prefix | sed -e 's|[^/][^/]*|..|g' but we do not have to invoke sed for that. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-22Merge in fixes up to 1.0.3 maintenance branch.Libravatar Junio C Hamano5-20/+50
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-22GIT 1.0.3Libravatar Junio C Hamano9-31/+44
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-22git-clone: Support changing the origin branch with -oLibravatar Johannes Schindelin2-5/+21
Earlier, git-clone stored upstream's master in the branch named 'origin', possibly overwriting an existing such branch. Now you can change it by calling git-clone with '-o <other_name>'. [jc: added ref format check, subdirectory safety, documentation and usage string.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-22sha1_to_hex: properly terminate the SHA1Libravatar Johannes Schindelin1-0/+2
sha1_to_hex() returns a pointer to a static buffer. Some of its users modify that buffer by appending a newline character. Other users rely on the fact that you can call printf("%s", sha1_to_hex(sha1)); Just to be on the safe side, terminate the SHA1 in sha1_to_hex(). Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-22Fix for http-fetch from file:// URLsLibravatar Nick Hengeveld1-4/+8
Recognize missing files when using http-fetch with file:// URLs Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-22git-format-patch should show the correct versionLibravatar Johannes Schindelin1-0/+3
We want to record the version of the tools the patch was generated with. While these tools could be rebuilt, git-format-patch stayed the same and report the wrong version. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-22send-pack: reword non-fast-forward error message.Libravatar Junio C Hamano1-16/+14
Wnen refusing to push a head, we said cryptic "remote 'branch' object X does not exist on local" or "remote ref 'branch' is not a strict subset of local ref 'branch'". That was gittish. Since the most likely reason this happens is because the pushed head was not up-to-date, clarify the error message to say that straight, and suggest pulling first. First noticed by Johannes and seconded by Andreas. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21GIT: Support [address] in URLsLibravatar YOSHIFUJI Hideaki / 吉藤英明1-8/+24
Allow IPv6address/IPvFuture enclosed by [] in URLs, like: git push '[3ffe:ffff:...:1]:GIT/git' or git push 'ssh://[3ffe:ffff:...:1]/GIT/git' Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21whatchanged: customize diff-tree outputLibravatar Junio C Hamano1-2/+8
This allows the configuration item whatchanged.difftree to control the output from git-whatchanged command. For example: [whatchanged] difftree = --pretty=fuller --name-status -M does rename detection, shows the commit header in "fuller" format and lists affected pathnames and the kind of changes to them. When no such configuration item exists, the output format defaults to "--pretty -M --abbrev". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21Merge branch 'fixes'Libravatar Junio C Hamano5-10/+10
2005-12-21\n usage in stderr outputLibravatar Alex Riesen5-9/+9
fprintf and die sometimes have missing/excessive "\n" in their arguments, correct the strings where I think it would be appropriate. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21git-pack-redundant: speed and memory usage improvementsLibravatar Lukas Sandström1-80/+69
Slab allocation of llist entries gives some speed improvements. Not computing the pack_list permutaions all at once reduces memory usage greatly on repositories with many packs. Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21merge-recursive: conflicting rename case.Libravatar Junio C Hamano2-11/+64
This changes the way the case two branches rename the same path to different paths is handled. Earlier, the code removed the original path and added both destinations to the index at stage0. This commit changes it to leave the original path at stage1, and two destination paths at stage2 and stage3, respectively. [jc: I am not really sure if this makes much difference in the real life merge situations. What should happen when our branch renames A to B and M to N, while their branch renames A to M? That is, M remains in our tree as is.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21Versioning scheme changes.Libravatar Junio C Hamano2-1/+7
HPA suggests it is simply silly to imitate Linux versioning scheme where the leading "2" does not mean anything anymore, and I tend to agree. The first feature release after 1.0.0 will be 1.1.0, and the development path leading to 1.1.0 will carry 1.0.GIT as the version number from now on. Similarly, the third maintenance release that follows 1.0.0 will not be 1.0.0c as planned, but will be called 1.0.3. The "maint" branch will merge in fixes and immediately tagged, so there is no need for 1.0.2.GIT that is in between 1.0.2 (aka 1.0.0b) and 1.0.3. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21sanity check in add_packed_git()Libravatar Pavel Roskin1-1/+1
add_packed_git() tries to get the pack SHA1 by parsing its name. It may access uninitialized memory for packs with short names. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21Merge branch 'fixes'Libravatar Junio C Hamano5-7/+13
2005-12-21GIT 1.0.0bLibravatar Junio C Hamano4-4/+15
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21server-info: skip empty lines.Libravatar Junio C Hamano1-1/+4
Now we allow an empty line in objects/info/packs file, recognize that and stop complaining. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21[PATCH] quote.c: Make loop control more readable.Libravatar Pavel Roskin1-2/+4
quote_c_style_counted() in quote.c uses a hard-to-read construct. Convert this to a more traditional form of the for loop. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>