summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2005-11-19git-config-set: add more optionsLibravatar Johannes Schindelin5-61/+258
... namely --replace-all, to replace any amount of matching lines, not just 0 or 1, --get, to get the value of one key, --get-all, the multivar version of --get, and --unset-all, which deletes all matching lines from .git/config Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Documentation update for user-relative paths.Libravatar Andreas Ericsson1-5/+24
Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Client side support for user-relative paths.Libravatar Andreas Ericsson1-22/+33
With this patch, the client side passes identical paths for these two: ssh://host.xz/~junio/repo host.xz:~junio/repo Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Server-side support for user-relative paths.Libravatar Andreas Ericsson2-25/+7
This patch basically just removes the redundant code from {receive,upload}-pack.c in favour of the library code in path.c. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Do not DWIM in userpath library under strict mode.Libravatar Junio C Hamano2-57/+60
This should force git-daemon administrator's job a bit harder because the exact paths need to be given in the whitelist, but at the same time makes the auditing easier. This moves validate_symref() from refs.c to path.c, because we need to link path.c with git-daemon for its "enter_repo()", but we do not want to link the daemon with the rest of git libraries and its requirements. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Library code for user-relative paths, take three.Libravatar Andreas Ericsson2-0/+73
This patch provides the work-horse of the user-relative paths feature, using Linus' idea of a blind chdir() and getcwd() which makes it remarkably simple. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Add test case for git-config-setLibravatar Johannes Schindelin1-0/+180
... includes the mean tests I mentioned on the list. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Add documentation for git-config-setLibravatar Johannes Schindelin2-0/+111
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Add git-config-set, a simple helper for scripts to set config variablesLibravatar Johannes Schindelin3-1/+29
This is meant for the end user, who cannot be expected to edit .git/config by hand. Example: git-config-set core.filemode true will set filemode in the section [core] to true, git-config-set --unset core.filemode will remove the entry (failing if it is not there), and git-config-set --unset diff.twohead ^recar will remove the unique entry whose value matches the regex "^recar" (failing if there is no unique such entry). It is just a light wrapper around git_config_set() and git_config_set_multivar(). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Add functions git_config_set() and git_config_set_multivar()Libravatar Johannes Schindelin2-1/+295
The function git_config_set() does exactly what you think it does. Given a key (in the form "core.filemode") and a value, it sets the key to the value. Example: git_config_set("core.filemode", "true"); The function git_config_set_multivar() is meant for setting variables which can have several values for the same key. Example: [diff] twohead = resolve twohead = recarsive the typo in the second line can be replaced by git_config_set_multivar("diff.twohead", "recursive", "^recar"); The third argument of the function is a POSIX extended regex which has to match the value. If there is no key/value pair with a matching value, a new key/value pair is added. These commands are also capable of unsetting (deleting) entries: git_config_set_multivar("diff.twohead", NULL, "sol"); will delete the entry twohead = resolve Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Decide whether to build http-push in the MakefileLibravatar Nick Hengeveld2-12/+6
The decision about whether to build http-push or not belongs in the Makefile. This follows Junio's suggestion to determine whether curl is new enough to support http-push. Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19http.c: reorder to avoid compilation failure.Libravatar Junio C Hamano1-36/+35
Move the static function get_curl_handle() around to make sure its definition and declarations are seen by the compiler before its first use. Also remove an unused variable. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19http-push memory/fd cleanupLibravatar Nick Hengeveld1-3/+14
Clean up memory and file descriptor usage Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Improve XML parsing in http-pushLibravatar Nick Hengeveld1-156/+163
Improved XML parsing - replace specialized doc parser callbacks with generic functions that track the parser context and use document-specific callbacks to process that data. Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Improve pack list response handlingLibravatar Nick Hengeveld1-2/+10
Better response handling for pack list requests - a 404 means we do have the list but it happens to be empty. Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Make http-fetch request types more clearLibravatar Nick Hengeveld1-136/+139
Rename object request functions and data to make it more clear which type of request is being processed - this is a response to the introduction of slot callbacks and the definition of different types of requests such as alternates_request. Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Isolate shared HTTP request functionalityLibravatar Nick Hengeveld5-976/+635
Move shared HTTP request functionality out of http-fetch and http-push, and replace the two fwrite_buffer/fwrite_buffer_dynamic functions with one fwrite_buffer function that does dynamic buffering. Use slot callbacks to process responses to fetch object transfer requests and push transfer requests, and put all of http-push into an #ifdef check for curl multi support. Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19merge-recursive::removeFile: remove empty directoriesLibravatar Junio C Hamano1-0/+4
When the last file in a directory is removed as the result of a merge, try to rmdir the now-empty directory. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19merge-one-file: remove empty directoriesLibravatar Junio C Hamano1-1/+6
When the last file in a directory is removed as the result of a merge, try to rmdir the now-empty directory. [jc: We probably could use "rmdir -p", but for now we do that by hand for portability.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19Documentation: rebase-from-internal minor updates.Libravatar Junio C Hamano1-5/+2
git-commit -v flag has been the default for quite some time, so do not mention it. Also a typofix. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19git-repack: do not do complex redundancy check.Libravatar Junio C Hamano1-21/+14
With "-a", redundant pack removal is trivial, and otherwise redundant pack removal is pointless; do not call git-redundant-pack from this script. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19git-count-objects: dc replacementLibravatar Junio C Hamano1-1/+19
Johannes suggested this earlier but I did not take it so seriously because this command is not that important. But this probably matters on Cygwin which does not seem to come with precompiled dc. It is a mystery for me that anything that mimics UNIX does not offer a dc, though. I did the detection for the lack of dc command a bit differently from the verison Johannes did. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Merge http://www.kernel.org/pub/scm/gitk/gitkLibravatar Junio C Hamano1-68/+102
2005-11-18Merge branches 'jc/branch' and 'jc/rebase'Libravatar Junio C Hamano2-63/+34
2005-11-18Rewrite rebase to use git-format-patch piped to git-am.Libravatar Junio C Hamano1-56/+16
The current rebase implementation finds commits in our tree but not in the upstream tree using git-cherry, and tries to apply them using git-cherry-pick (i.e. always use 3-way) one by one. Which is fine, but when some of the changes do not apply cleanly, it punts, and punts badly. Suppose you have commits A-B-C-D-E since you forked from the upstream and submitted the changes for inclusion. You fetch from upstream head U and find that B has been picked up. You run git-rebase to update your branch, which tries to apply changes contained in A-C-D-E, in this order, but replaying of C fails, because the upstream got changes that touch the same area from elsewhere. Now what? It notes that fact, and goes ahead to apply D and E, and at the very end tells you to deal with C by hand. Even if you somehow managed to replay C on top of the result, you would now end up with ...-B-...-U-A-D-E-C. Breaking the order between B and others was the conscious decision made by the upstream, so we would not worry about it, and even if it were worrisome, it is too late for us to fix now. What D and E do may well depend on having C applied before them, which is a problem for us. This rewrites rebase to use git-format-patch piped to git-am, and when the patch does not apply, have git-am fall back on 3-way merge. The updated diff/patch pair knows how to apply trivial binary patches as long as the pre- and post-images are locally available, so this should work on a repository with binary files as well. The primary benefit of this change is that it makes rebase easier to use when some of the changes do not replay cleanly. In the "unapplicable patch in the middle" case, this "rebase" works like this: - A series of patches in e-mail form is created that records what A-C-D-E do, and is fed to git-am. This is stored in .dotest/ directory, just like the case you tried to apply them from your mailbox. Your branch is rewound to the tip of upstream U, and the original head is kept in .git/ORIG_HEAD, so you could "git reset --hard ORIG_HEAD" in case the end result is really messy. - Patch A applies cleanly. This could either be a clean patch application on top of rewound head (i.e. same as upstream head), or git-am might have internally fell back on 3-way (i.e. it would have done the same thing as git-cherry-pick). In either case, a rebased commit A is made on top of U. - Patch C does not apply. git-am stops here, with conflicts to be resolved in the working tree. Yet-to-be-applied D and E are still kept in .dotest/ directory at this point. What the user does is exactly the same as fixing up unapplicable patch when running git-am: - Resolve conflict just like any merge conflicts. - "git am --resolved --3way" to continue applying the patches. - This applies the fixed-up patch so by definition it had better apply. "git am" knows the patch after the fixed-up one is D and then E; it applies them, and you will get the changes from A-C-D-E commits on top of U, in this order. I've been using this without noticing any problem, and as people may know I do a lot of rebases. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18git-branch: -f to forcibly reset branch head.Libravatar Junio C Hamano1-7/+18
A new usage, 'git-branch -f branch [start]', resets the branch head at start (or current head). Should be considered a dangerous operation, but if you are like me to keep rewinding branches it is handy. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Do not show .exe in git command list.Libravatar Junio C Hamano1-1/+4
Truncate the result from readdir() in the exec-path if they end with .exe, to make it a bit more readable on Cygwin. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Document the "ignore objects" feature of git-pack-redundantLibravatar Lukas Sandström1-0/+8
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Improve the readability of git-pack-redundantLibravatar Lukas Sandström1-13/+24
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Remove all old packfiles when doing "git repack -a -d"Libravatar Lukas Sandström1-3/+16
No point in running git-pack-redundant if we already know which packs are redundant. Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Update pull/fetch --tags documentationLibravatar Luck, Tony1-1/+3
When fetching/pulling from a remote repository the "--tags" option can be used to pull tags too. Document that it will limit the pull to only commits reachable from the tags. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Fix a bug in get_all_permutations.Libravatar Lukas Sandström1-0/+1
This line was missing in the previous patch for some reason. Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Cygwin *might* be helped with NO_MMAPLibravatar Junio C Hamano1-0/+4
When HPA added Cygwin target, it ran just fine without NO_MMAP for him, but recently we are getting reports that for some people things break without it. For now, just suggest it in the Makefile without actually updating the default. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Teach "approxidate" about weekday syntaxLibravatar Linus Torvalds1-5/+49
On Fri, 18 Nov 2005, David Roundy wrote: > > Don't forget "high noon"! (and perhaps "tea time"?) :) Done. [torvalds@g5 git]$ ./test-date "now" "midnight" "high noon" "tea-time" now -> bad -> Wed Dec 31 16:00:00 1969 now -> Fri Nov 18 08:50:54 2005 midnight -> bad -> Wed Dec 31 16:00:00 1969 midnight -> Fri Nov 18 00:00:00 2005 high noon -> bad -> Wed Dec 31 16:00:00 1969 high noon -> Thu Nov 17 12:00:00 2005 tea-time -> bad -> Wed Dec 31 16:00:00 1969 tea-time -> Thu Nov 17 17:00:00 2005 Thanks for pointing out tea-time. This is also written to easily extended to allow people to add their own important dates like Christmas and their own birthdays. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Make "git fetch" less verbose by defaultLibravatar Linus Torvalds1-5/+9
When doing something like git fetch --tags origin the excessively verbose output of git fetch makes the result totally unreadable. It's impossible to tell if it actually fetched anything new or not, since the screen will fill up with an endless supply of ... * committish: 9165ec17fde255a1770886189359897dbb541012 tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git * refs/tags/v0.99.7c: same as tag 'v0.99.7c' of master.kernel.org:/pub/scm/git/git ... and any new tags that got fetched will be totally hidden. So add a new "--verbose" flag to "git fetch" to enable this verbose mode, but make the default be quiet. NOTE! The quiet mode will still report about new or changed heads, so if you are really fetching a new head, you'll see something like this: [torvalds@g5 git]$ git fetch --tags parent Packing 6 objects Unpacking 6 objects 100% (6/6) done * refs/tags/v1.0rc2: storing tag 'v1.0rc2' of master.kernel.org:/pub/scm/git/git * refs/tags/v1.0rc3: storing tag 'v1.0rc3' of master.kernel.org:/pub/scm/git/git * refs/tags/v1.0rc1: storing tag 'v1.0rc1' of master.kernel.org:/pub/scm/git/git which actually tells you something useful that isn't hidden by all the useless crud that you already had. Extensively tested (hey, for me, this _is_ extensive) by doing a rm .git/refs/tags/v1.0rc* and re-fetching with both --verbose and without. NOTE! This means that if the fetch didn't actually fetch anything at all, git fetch will be totally quiet. I think that's much better than being so verbose that you can't even tell whether something was fetched or not, but some people might prefer to get a "nothing to fetch" message in that case. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18Fix bug introduced by the latest changes to git-pack-redundantLibravatar Lukas Sandström1-1/+1
I forgot to initialize part of the pll struct when copying it. Found by valgrind. Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-18git-prune: quote possibly empty $dryrun as parameter to testLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-17git-am: --binary; document --resume and --binary.Libravatar Junio C Hamano2-14/+30
Now git-apply can grok binary replacement patches, give --binary flag to git-am. As a safety measure, this is not by default enabled, so that you do not let malicious e-mailed patch to replace an arbitrary path with just a couple of lines (diff index lines, the filename and string "Binary files "...) by accident. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-17Teach "approxidate" about weekday syntaxLibravatar Linus Torvalds1-1/+17
This allows people to use syntax like "last thursday" for the approxidate. (Or, indeed, more complex "three thursdays ago", but I suspect that would be pretty unusual). NOTE! The parsing is strictly sequential, so if you do "one day before last thursday" it will _not_ do what you think it does. It will take the current time, subtract one day, and then go back to the thursday before that. So to get what you want, you'd have to write it the other way around: "last thursday and one day before" which is insane (it's usually the same as "last wednesday" _except_ if today is Thursday, in which case "last wednesday" is yesterday, and "last thursday and one day before" is eight days ago). Similarly, "last thursday one month ago" will first go back to last thursday, and then go back one month from there, not the other way around. I doubt anybody would ever use insane dates like that, but I thought I'd point out that the approxidate parsing is not exactly "standard English". Side note 2: if you want to avoid spaces (because of quoting issues), you can use any non-alphanumberic character instead. So git log --since=2.days.ago works without any quotes. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-17Make git-pack-redundant non-horribly slow on large sets of packsLibravatar Lukas Sandström1-12/+48
Change the smallest-set detection algortithm so that when we have found a good set, we don't check any larger sets. Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-17git-repack: Fix variable nameLibravatar Ralf Baechle1-3/+3
Three times remove_redandant -> remove_redundant. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-17'make clean' forgot about some filesLibravatar Nicolas Pitre1-1/+1
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-17Deal with binary diff output from GNU diff 2.8.7Libravatar Junio C Hamano1-6/+18
Some vintage of diff says just "Files X and Y differ\n", instead of "Binary files X and Y differ\n", so catch both patterns. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-17Merge branch 'tojunio' of http://locke.catalyst.net.nz/git/git-martinlanghoffLibravatar Junio C Hamano1-42/+103
2005-11-17archimport: allow for old style branch and public tag namesLibravatar Martin Langhoff1-6/+17
This patch adds the -o switch, which lets old trees tracked by git-archmirror continue working with their old branch and tag names to make life easier for people tracking your tree. Private tags that are only used internally by git-archimport continue to be new-style, and automatically converted upon first run. [ ml: rebased to skip import overhaul ] Signed-off-by:: Eric Wong <normalperson@yhbt.net> Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
2005-11-16Add approxidate test calls.Libravatar Junio C Hamano1-0/+3
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-16git's rev-parse.c function show_datestring presumes gnu dateLibravatar Linus Torvalds3-14/+126
Ok. This is the insane patch to do this. It really isn't very careful, and the reason I call it "approxidate()" will become obvious when you look at the code. It is very liberal in what it accepts, to the point where sometimes the results may not make a whole lot of sense. It accepts "last week" as a date string, by virtue of "last" parsing as the number 1, and it totally ignoring superfluous fluff like "ago", so "last week" ends up being exactly the same thing as "1 week ago". Fine so far. It has strange side effects: "last december" will actually parse as "Dec 1", which actually _does_ turn out right, because it will then notice that it's not December yet, so it will decide that you must be talking about a date last year. So it actually gets it right, but it's kind of for the "wrong" reasons. It also accepts the numbers 1..10 in string format ("one" .. "ten"), so you can do "ten weeks ago" or "ten hours ago" and it will do the right thing. But it will do some really strange thigns too: the string "this will last forever", will not recognize anyting but "last", which is recognized as "1", which since it doesn't understand anything else it will think is the day of the month. So if you do gitk --since="this will last forever" the date will actually parse as the first day of the current month. And it will parse the string "now" as "now", but only because it doesn't understand it at all, and it makes everything relative to "now". Similarly, it doesn't actually parse the "ago" or "from now", so "2 weeks ago" is exactly the same as "2 weeks from now". It's the current date minus 14 days. But hey, it's probably better (and certainly faster) than depending on GNU date. So now you can portably do things like gitk --since="two weeks and three days ago" git log --since="July 5" git-whatchanged --since="10 hours ago" git log --since="last october" and it will actually do exactly what you thought it would do (I think). It will count 17 days backwards, and it will do so even if you don't have GNU date installed. (I don't do "last monday" or similar yet, but I can extend it to that too if people want). It was kind of fun trying to write code that uses such totally relaxed "understanding" of dates yet tries to get it right for the trivial cases. The result should be mixed with a few strange preprocessor tricks, and be submitted for the IOCCC ;) Feel free to try it out, and see how many strange dates it gets right. Or wrong. And if you find some interesting (and valid - not "interesting" as in "strange", but "interesting" as in "I'd be interested in actually doing this) thing it gets wrong - usually by not understanding it and silently just doing some strange things - please holler. Now, as usual this certainly hasn't been getting a lot of testing. But my code always works, no? Linus Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-17Disambiguate the term 'branch' in Arch vs gitLibravatar Eric Wong1-11/+54
Disambiguate the term 'branch' in Arch vs git, and start using fully-qualified names. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
2005-11-17archimport: don't die on merge-base failureLibravatar Eric Wong1-1/+7
Don't die if we can't find a merge base, Arch allows arbitrary cherry-picks between unrelated branches and we should not die when that happens Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
2005-11-17remove shellquote usage for tagsLibravatar Eric Wong1-27/+28
use ',' to encode '/' in "archivename/foo--bar--0.0" so we can allow "--branch"-less trees which are valid in Arch ("archivename/foo--0.0") Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>