summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2005-09-04[PATCH] Make git-send-email-script ignore some unnecessary options when ↵Libravatar Ryan Anderson1-5/+81
operating in batch mode. Add a "--compose" option that uses $EDITOR to edit an "introductory" email to the patch series. Signed-off-by: Ryan Anderson <ryan@michonline.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-04Install archimport-script.Libravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-04Add copy/rename check for git-apply.Libravatar Junio C Hamano1-0/+148
The new test pattern is taken from HPA's klibc and klibc-kbuild trees, which has many interesting renames (the commits 001eef5a19219e5b0601068a3d13874b88c0653e and 0037d1bc0deaf7daec3778496656cb04b4e4b9d0). The test pattern exposes problems in the apply.c changes currently in the proposed updates branch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-04Add a link from update-server-info documentation to repository layout.Libravatar Junio C Hamano1-2/+21
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-04[PATCH] Make git-apply understand incomplete lines in non-C localesLibravatar Fredrik Kuivinen1-3/+7
The message "\ No newline at end of file" used by diff(1) to mark an incomplete line is locale dependent. We can't assume more than that it begins with "\ ". For example, given two files, "foo" and "bar", with appropriate contents, 'diff -u foo bar' will produce the following output on my system: --- foo 2005-09-04 18:59:38.000000000 +0200 +++ bar 2005-09-04 18:59:16.000000000 +0200 @@ -1 +1 @@ -foobar +foo \ Ingen nyrad vid filslut [jc: the check for the marker still uses the line length being no less than 12 bytes for a sanity check, but I think it is safe to assume that in other locales. I haven't checked the .po files from diff, tho'.] Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-04git-applymbox: fix '-c'.Libravatar Junio C Hamano1-1/+2
Earlier round b50abe8843006e9856c633b5abeb4eab53b46629 broke it by carelessly rewriting the main loop. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-04[PATCH] archimport: avoid committing on an Arch tagLibravatar Martin Langhoff1-0/+8
Arch tags are full commits (without any changed files) as well. Trust Arch to have put an unchanged tree in place (which seems to do reliably), and just add a tag & new branch. Speeds up Arch imports significantly, and leaves history in a much saner state. Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-04[PATCH] archimport autodetects import status, supports incremental importsLibravatar Martin Langhoff1-17/+20
If there is no GIT directory, archimport will assume it is an initial import. It now also supports incremental imports, skipping "seen" commits. You can now run it repeatedly to pull new commits from the Arch repository. Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-04[PATCH] NUL terminate the object data in patch_delta()Libravatar Sergey Vlasov1-1/+2
At least pretty_print_commit() expects to get NUL-terminated commit data to work properly. unpack_sha1_rest(), which reads objects from separate files, and unpack_non_delta_entry(), which reads non-delta-compressed objects from pack files, already add the NUL byte after the object data, but patch_delta() did not do it, which caused problems with, e.g., git-rev-list --pretty when there are delta-compressed commit objects. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-04[PATCH] Possible cleanups for local-pull.cLibravatar Peter Hagervall3-7/+7
Hi. This patch contains the following possible cleanups: * Make some needlessly global functions in local-pull.c static * Change 'char *' to 'const char *' where appropriate Signed-off-by: Peter Hagervall <hager@cs.umu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-04[PATCH] Doc: replace read-cache with git-read-tree.Libravatar Paolo 'Blaisorblade' Giarrusso1-2/+2
Replace references to "read-cache" with references to git-read-tree in the documentation. I chose that because reference say "see read-cache about stages", and stages are explained in git-read-tree. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-02Document hooks.Libravatar Junio C Hamano6-2/+157
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-02Mention post-update when we first talk about publishing a repository.Libravatar Junio C Hamano1-0/+6
There is more detailed instruction for `project lead` later in the tutorial to talk about the same, but at this point in the flow of tutorial, the first time reader has no way of knowing it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-02scripts: equality test '==' is not portable.Libravatar Junio C Hamano3-9/+15
On NetBSD 3 we trigger an error: [: ==: unexpected operator Double-equal is accepted by bash built-in '[' and bash(1) suggests using '=' for strict POSIX compliance (test(1) from coreutils does not mention '=='). Eradicate their uses everywhere. [jc: Somebody with a pseudonym kindly sent a message to let me know about the problem privately; I do not have access to a NetBSD box.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-02git-checkout-script: Remove unnecessary variable.Libravatar Junio C Hamano1-1/+0
There was unused variable $i that counted the number of arguments being processed. Remove it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-02Fix automerge message.Libravatar Junio C Hamano1-18/+33
The rewrite done while adding the shorthand support made the remote refname recorded in the commit message too long for human consumption, while losing information by using the shorthand not the real URL to name the remote repository there. They were both bad changes done without enough thinking. Pointed out by Linus. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-01[PATCH] Explain what went wrong on update-cache of new fileLibravatar Amos Waterland1-2/+6
If somebody tries to run `git update-cache foo', where foo is a new file, git dies with a rather cryptic error message: fatal: Unable to add foo to database This trivial patch makes git explain what probably went wrong. It is not a perfect diagnosis of all error paths, but for 90% of the cases it should provide the user with the clue they need. [jc: I ended up wording slightly differently, and fixed another confusing error message I noticed while reviewing the code.] Signed-off-by: Amos Waterland <apw@rossby.metr.ou.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-01Add repository-layout document.Libravatar Junio C Hamano4-14/+148
... and link to it from both the main index and the tutorial. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-31Use 'git status' now it can handle initial commit.Libravatar Junio C Hamano1-25/+20
Update 'git commit' to use the updated `git status`. Also earlier the `-s` flag was ignored for the initial commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-31Fix git-status when HEAD is invalid.Libravatar Junio C Hamano1-4/+16
It tried to do git-diff-cache against HEAD, of course. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-31Fix git-log-script when HEAD is invalid.Libravatar Junio C Hamano1-2/+13
It used 'die' without including git-sh-setup-script; since everything it uses are subdirectory-aware, instead of including the script to force it to be run from the top, use echo & exit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-31Add Pine 4.63 help from Daniel.Libravatar Junio C Hamano1-0/+12
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-30Update tutorial.Libravatar Junio C Hamano1-291/+370
Finally I bit the bullet and did a full sweep of this document. The changes are mostly clarifications, adjusting old terminology to the glossary compatible one, and asciidoc formatting. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-30show-branch: make it work in a subdirectory.Libravatar Junio C Hamano1-0/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-30[PATCH] Initial import of git-archimport-scriptLibravatar Martin Langhoff1-0/+593
Imports a project history from one or more Arch repositories, following the branching and tagging across repositories. Note you should import separate projects to separate GIT repositories. Supported - Imports, tags and simple commits. - File renames - Arch tags - Binary files - Large trees - Multiple repositories - Branches TODO: - Allow re-running the import on an already-imported project - Follow merges using Arch data - Audit shell escaping of filenames - Better support for file metadata - Better/safer creation of temp directories Unsupported: - Arch 'configuration' [jc: my arch/tla is very rusty and after Tom announced he is stepping down as the maintainer I have very little motivation to relearn it, so I would appreciate if people discuss any bugs or enhancements directly with Martin. Of course I can help with the git end of the issues.] Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-30cat-file: make it work in a subdirectory.Libravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <junkio@cox.net> (cherry picked from 73244994ee4abd6e436e8a1d597dd917271d77a9 commit)
2005-08-30Documentaion updates.Libravatar Junio C Hamano9-357/+508
Mostly making the formatted html prettier. Signed-off-by: Junio C Hamano <junkio@cox.net> (cherry picked from 7adf1f15ebe074d4767df941817a6cf86d8e2533 commit)
2005-08-30'git bisect visualize'Libravatar Junio C Hamano1-6/+22
Linus says: I'm testing bisection to find a bug that causes my G5 to no longer boot, and during the process have found this command line very nice: gitk bisect/bad --not $(cd .git/refs ; ls bisect/good-*) it basically shows the state of bisection with the known bad commit as the top, and cutting off all the good commits - so what you see are the potential buggy commits. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-30[PATCH] Fix bisection terminating conditionLibravatar Linus Torvalds1-2/+6
When testing bisection and using gitk to visualize the result, it was obvious that the termination condition was broken. We know what the bad entry is only when the bisection ends up telling us to test the known-bad entry again. Also, add a safety net: if somebody marks as good something that includes the known-bad point, we now notice and complain, instead of writing an empty revision to the new bisection branch. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-30parse-remote: trivial fix to allow refs/{heads,tags}/ spelled easier.Libravatar Junio C Hamano1-0/+4
Earlier we always prefixed refs/heads to the token given to "git fetch" (and "git pull") as refspec. This was a mistake. Allow them to be spelled like "master:refs/tags/paulus" to mean "I want to fetch the master there and store it as my local "paulus" tag. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-30Merge refs/heads/master from paulus Libravatar Junio C Hamano1-19/+126
2005-08-29Make sure howto/*.html is built as well.Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29[PATCH] Make "git resolve" less scaryLibravatar Linus Torvalds1-1/+3
When we resolve a merge between two branches, and it removes a file in the current branch, we notify the person doing the resolve with a big nice notice like Removing xyzzy which is all well and good. HOWEVER, we also do this when the file was actually removed in the current branch, and we're merging with another branch that didn't have it removed (or, indeed, if the other branch _did_ have it removed, but the common parent was far enough back that the file still existed in there). And that just doesn't make sense. In that case we're not removing anything: the file didn't exist in the branch we're merging into in the first place. So the message just makes people nervous, and makes no sense. This has been around forever, but I never bothered to do anything about it. Until now. The trivial fix is to only talk about removing files if the file existed in the branch we're merging into, but will not exist in the result. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29Allow asciidoc formatted documentation in howto/Libravatar Junio C Hamano3-4/+18
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29Add [HOWTO] revert/branch/rebase.Libravatar Junio C Hamano1-0/+199
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29git commit: Allow editing on all occasions.Libravatar Junio C Hamano1-0/+3
Sometimes it may be handy to be able to edit messages that come from somewhere other than an existing commit. This makes 'git commit -F <file> -e' to start editor with the initial log message contents taken from <file>. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29Do not verify reverted/cherry-picked/rebased patches.Libravatar Junio C Hamano1-1/+1
The original committer may have used validation criteria that is less stricter than yours. You do not want to lose the changes even if they are done in substandard way from your 'commit -v' verifier's point of view. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29Fix compilation warnings.Libravatar Junio C Hamano2-2/+2
... found by compiling them with gcc 2.95. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29[PATCH] Update Thunderbird specific hints.Libravatar A Large Angry SCM1-6/+2
Setting the wraplength to zero keeps the bird from trimming WS. Signed-off-by: <gitzilla@gmail.com> (cherry picked from 1d535d525d6a0ddddc3755065d721278bc5f0aff commit)
2005-08-29[PATCH] Documentation for git-request-pull-script.Libravatar A Large Angry SCM1-8/+10
Copy & paste source comments into documentation. Signed-off-by: <gitzilla@gmail.com> (cherry picked from 10dce95490cb02f66b3a08984ccdee0a92b48236 commit)
2005-08-29[PATCH] Documentation for git-clone-dumb-http.Libravatar A Large Angry SCM1-10/+8
Copy & paste source comments into documentation. Signed-off-by: <gitzilla@gmail.com> (cherry picked from f79528e5d05a64d68b8e09a18521950775e99ec1 commit)
2005-08-29[PATCH] Documentation for git-daemon.Libravatar A Large Angry SCM1-9/+17
Copy & paste source comments into documentation. Signed-off-by: <gitzilla@gmail.com> (cherry picked from 5d0a4efeff62cfa363437f91308453b5b9fd8cf5 commit)
2005-08-30Draw selected graph line thicker and make arrowheads active.Libravatar Paul Mackerras1-19/+126
2005-08-29Accumulated documentation updates.Libravatar Junio C Hamano8-149/+297
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29git-repack-script: Add option to repack all objects.Libravatar Junio C Hamano1-8/+43
This originally came from Frank Sorenson, but with a bit of rework to allow future enhancements without changing the external interface for pack pruning part. With the '-a' option, all objects in the current repository are packed into a single pack. When the '-d' option is given at the same time, existing packs that were made redundant by this round of repacking are deleted. Since we currently have only two repacking strategies, one with '-a' (everything into one) and the other without '-a' (incrementally pack only the unpacked ones), the '-d' option is meaningful only when used with '-a'; it removes the packs existed before we did the "everything into one" repacking. At least for now. Signed-off-by: Junio C Hamano <junkio@cox.net> Acked-by: Frank Sorenson <frank@tuxrocks.com> (cherry picked from bfed505327e31221d8de796b3af880bad696b149 commit)
2005-08-29Updates: show-branchLibravatar Junio C Hamano1-22/+108
Earlier show-branch gave names only to commits reachable via first parent ancestry chain. Change the naming code to name everybody. The original idea was to stop at the first merge point in the topological order, and --more=<n> to show commits until we show <n> more extra merge points. However depending on the order of how we discover the commits, it additionally showed parents of the <n>th merge points, which was unnecessary. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29mailinfo and applymbox updatesLibravatar Junio C Hamano2-86/+554
This attempts to minimally cope with a subset of MIME "features" often seen in patches sent to our mailing lists. Namely: - People's name spelled in characters outside ASCII (both on From: header and the signed-off-by line). - Content-transfer-encoding using quoted-printable (both in multipart and non-multipart messages). These MIME features are detected and decoded by "git mailinfo". Optionally, with the '-u' flag, the output to .info and .msg is transliterated from its original chaset to utf-8. This is to encourage people to use utf8 in their commit messages for interoperability. Applymbox accepts additional flag '-u' which is passed to mailinfo. Signed-off-by: Junio C Hamano / 濱野 純 <junkio@cox.net>
2005-08-29Document "git cherry-pick" and "git revert"Libravatar Junio C Hamano3-1/+75
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29Remove git-apply-patch-script.Libravatar Junio C Hamano6-194/+5
Now the rebase is rewritten to use git cherry-pick, there is no user for that ancient script. I've checked Cogito and StGIT to make sure they do not use it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-29Redo "revert" using three-way merge machinery.Libravatar Junio C Hamano4-39/+185
The reverse patch application using "git apply" sometimes is too rigid. Since the user would get used to resolving conflicting merges by hand during the normal merge experience, using the same machinery would be more helpful rather than just giving up. Cherry-picking and reverting are essentially the same operation. You pick one commit, and apply the difference that commit introduces to its own commit ancestry chain to the current tree. Revert applies the diff in reverse while cherry-pick applies it forward. They share the same logic, just different messages and merge direction. Rewrite "git rebase" using "git cherry-pick". Signed-off-by: Junio C Hamano <junkio@cox.net>