summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2005-08-27Enable git-send-email-script on Debian.Junio C Hamano
You can define WITH_SEND_EMAIL to include the send-email command as part of the installation. Since Debian, unlike RPM/Fedora, has the two necessary Perl modules available as part of the mainline distribution, there is no reason for us to shy away from shipping send-email. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-27Update the main documentation index.Junio C Hamano
Gitzilla updated bunch of undocumented command pages, so move the entries in the main documentation index around to put them in proper category. Ordering within category will be fixed later. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-27[PATCH] Subject: [PATCH] Add some documentation.A Large Angry SCM
Add some documentation. Text taken from the the commit messages and the command sources.
2005-08-26[PATCH] git bugfixes and cleanups, mainly Debian thingsTommi Virtanen
Point Debian doc-base at the right files. Clean up. Signed-off-by: Tommi Virtanen <tv@debian.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26[PATCH] git bugfixes and cleanups, mainly Debian thingsTommi Virtanen
Ignore generated files. Signed-off-by: Tommi Virtanen <tv@debian.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26[PATCH] git bugfixes and cleanups, mainly Debian thingsTommi Virtanen
Generate docs for gitk. Install them in the right deb package. Signed-off-by: Tommi Virtanen <tv@debian.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26[PATCH] git bugfixes and cleanups, mainly Debian thingsTommi Virtanen
Make the git deb conflict with cogito versions prior to 0.13, as those versions used to contain git. Suggest cogito. Signed-off-by: Tommi Virtanen <tv@debian.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26[PATCH] git bugfixes and cleanups, mainly Debian thingsTommi Virtanen
Fix syntax error in debian Build-Depends-Indep, dpkg-checkbuilddeps used to give false ok results. Signed-off-by: Tommi Virtanen <tv@debian.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26Add Abstract: support for howto index generator.Junio C Hamano
Maybe it's time for me to really learn asciidoc. Also I should do Perl ;-). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26[PATCH] More missing terms in glossary.txtJohannes Schindelin
Describe a DAG and octopus, and change wording of tree object. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26[PATCH] update howto/using-topic-branches.txttony.luck@intel.com
Various updates and cleanups for my howto on using branches in GIT as a Linux subsystem maintainer. Three categories of changes: 1) Updates for new features in GIT 0.99.5 2) Changes to use "git fetch" rather than "git pull" to update local linus branch. 3) Cleanups suggested by Len Brown Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-25Don't forget to build the howto-index file.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-25Link howto documents from the main git.txt documentation.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-25Sort branch names snarfed from refs/ hierarchy.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-25Fix fetching of tags.Junio C Hamano
"git fetch tag <tag>" stored a tag after dereferencing. Bad. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-25Merge refs/heads/master from . v0.99.5Junio C Hamano
2005-08-25[PATCH] Fix silly pathspec bug in git-ls-filesLinus Torvalds
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>
2005-08-25[PATCH] Fix git-checkout-script exit statustony.luck@intel.com
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>
2005-08-25Merge refs/heads/master from . Junio C Hamano
2005-08-25Fix markup minimally to get man pages built.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24Merge refs/heads/master from . Junio C Hamano
2005-08-24Update tutorial to describe shared repository style a bit more.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24Documentation: multi-head fetch.Junio C Hamano
Add documentation related to multi-head work, including $GIT_DIR/remotes/ changes. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24Support +<src>:<dst> format in push as well.Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24[PATCH] Allow "+remote:local" refspec to cause --force when fetching.Junio C Hamano
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>
2005-08-24[PATCH] Use git-octopus when pulling more than one heads.Junio C Hamano
With this, you can finally say "git pull jgarzik sil24 pdc2027x". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24[PATCH] "git fetch --force".Junio C Hamano
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>
2005-08-24[PATCH] Use .git/remote/origin, not .git/branches/origin.Junio C Hamano
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>
2005-08-24[PATCH] Make "git pull" and "git fetch" default to originJunio C Hamano
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>
2005-08-24[PATCH] Infamous 'octopus merge'Junio C Hamano
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>
2005-08-24[PATCH] Retire git-parse-remote.Junio C Hamano
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>
2005-08-24[PATCH] Multi-head fetch.Junio C Hamano
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>
2005-08-24[PATCH] Start adding the $GIT_DIR/remotes/ support.Junio C Hamano
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>
2005-08-24[PATCH] Fix "prefix" mixup in git-rev-listPavel Roskin
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>
2005-08-24Audit rev-parse users again.Junio C Hamano
Some callers to rev-parse were using the output selection flags inconsistently. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24Rationalize output selection in rev-parse.Junio C Hamano
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>
2005-08-24Generate pack info file after repack.Junio C Hamano
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>
2005-08-24Merge refs/heads/master from . Junio C Hamano
2005-08-24Link the tutorial from the main document.Junio C Hamano
And lead the reader to it at the beginning of the manual. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-24Try to find the optimum merge base while resolving.Junio C Hamano
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>
2005-08-23Merge refs/heads/master from . Junio C Hamano
2005-08-23Tutorial updates.Junio C Hamano
- 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>
2005-08-23Update git-diff-script.Junio C Hamano
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>
2005-08-23Make "git-rev-list" work within subdirectoriesLinus Torvalds
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>
2005-08-23[PATCH] Fix git-rev-parse --default and --flags handlingLinus Torvalds
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>
2005-08-23Add placeholders for missing documents.Junio C Hamano
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>
2005-08-23Merge refs/heads/master from . Junio C Hamano
2005-08-23Introduce "reset type" flag to "git reset"Junio C Hamano
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>
2005-08-23Clean-up output from "git show-branch" and document it.Junio C Hamano
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>
2005-08-23[PATCH] Add 'git show-branch'.Junio C Hamano
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>