summaryrefslogtreecommitdiff
path: root/git-commit.sh
AgeCommit message (Collapse)AuthorFilesLines
2007-01-11Merge branch 'jc/bare'Libravatar Junio C Hamano1-0/+1
* jc/bare: Disallow working directory commands in a bare repository. git-fetch: allow updating the current branch in a bare repository. Introduce is_bare_repository() and core.bare configuration variable Move initialization of log_all_ref_updates
2007-01-10Disallow working directory commands in a bare repository.Libravatar Shawn O. Pearce1-0/+1
If the user tries to run a porcelainish command which requires a working directory in a bare repository they may get unexpected results which are difficult to predict and may differ from command to command. Instead we should detect that the current repository is a bare repository and refuse to run the command there, as there is no working directory associated with it. [jc: updated Shawn's original somewhat -- bugs are mine.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-08git-commit: do not fail to print the diffstat even if there is a file named HEADLibravatar Michael Loeffler1-1/+1
Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-01Remove unused variable (git-commit.sh)Libravatar Junio C Hamano1-1/+0
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Suggest use of "git add file1 file2" when there is nothing to commit.Libravatar Shawn O. Pearce1-1/+1
If a user modifies files and runs 'git commit' (without the very useful -a option) and they have not yet updated the index they are probably coming from another SCM-like tool which would perform the same as 'git commit -a' in this case. Showing the user their current status and a final line of "nothing to commit" is not very reassuring, as the user might believe that Git did not recognize their files were modified. Instead we can suggest as part of the 'nothing to commit' message that the user invoke 'git add' to add files to their next commit. Suggested by Andy Parkins' Git 'niggles' list (<200612132237.10051.andyparkins@gmail.com>). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15make commit message a little more consistent and confortingLibravatar Nicolas Pitre1-4/+15
It is nicer to let the user know when a commit succeeded all the time, not only the first time. Also the commit sha1 is much more useful than the tree sha1 in this case. This patch also introduces a -q switch to supress this message as well as the summary of created/deleted files. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-13Merge branch 'np/addcommit'Libravatar Junio C Hamano1-11/+1
* np/addcommit: git-commit: allow --only to lose what was staged earlier. Documentation/git-commit: rewrite to make it more end-user friendly. make 'git add' a first class user friendly interface to the index
2006-12-10git-commit: allow --only to lose what was staged earlier.Libravatar Junio C Hamano1-11/+1
The command used to have a safety valve to prevent this sequence: edit foo git update-index foo edit foo git diff foo git commit --only foo The reason for this was because an inexperienced user might mistakenly think what is shown with the last-minute diff contains all the change that is being committed (instead, what the user asked to check was an incremental diff since what has been staged so far). However, this turns out to only annoy people who know what they are doing. Inexperienced people would not be using the first "update-index" anyway, in which case they would see the full changes in the "git diff". Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-25git-commit: show --summary after successful commit.Libravatar Junio C Hamano1-0/+3
Sometimes people accidentally commit files in wrong mode bits. Show --summary output for the HEAD commit after successful commit as a final sanity check. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-01Merge branch 'lj/refs'Libravatar Junio C Hamano1-5/+5
* lj/refs: (63 commits) Fix show-ref usagestring t3200: git-branch testsuite update sha1_name.c: avoid compilation warnings. Make git-branch a builtin ref-log: fix D/F conflict coming from deleted refs. git-revert with conflicts to behave as git-merge with conflicts core.logallrefupdates thinko-fix git-pack-refs --all core.logallrefupdates create new log file only for branch heads. Remove bashism from t3210-pack-refs.sh ref-log: allow ref@{count} syntax. pack-refs: call fflush before fsync. pack-refs: use lockfile as everybody else does. git-fetch: do not look into $GIT_DIR/refs to see if a tag exists. lock_ref_sha1_basic does not remove empty directories on BSD Do not create tag leading directories since git update-ref does it. Check that a tag exists using show-ref instead of looking for the ref file. Use git-update-ref to delete a tag instead of rm()ing the ref file. Fix refs.c;:repack_without_ref() clean-up path Clean up "git-branch.sh" and add remove recursive dir test cases. ...
2006-10-15git-revert with conflicts to behave as git-merge with conflictsLibravatar Luben Tuikov1-2/+2
In a busy project, reverting a commit almost always results in a conflict between one or more files (depending on the commit being reverted). It is useful to record this conflict in the commit-to-be message of the resulting commit (after the resolve). The process now becomes: git-revert <SHA-1> <git complains and prints failed automatic> <user manually resolves> git-update-index <resolved files> git-commit -s And the commit message is now a merge of the revert commit message and the conflict commit message, giving the user a chance to edit it or add more information: Signed-off-by: Luben Tuikov <ltuikov@yahoo.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-07git-commit: fix coding style.Libravatar Martin Waitz1-231/+233
git-commit.sh was using a mixture of spaces and tabs for indentation. This is changed to one tab per indentation level. No code changes. Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-03git-commit: cleanup unused function.Libravatar Martin Waitz1-27/+0
The report() function is not used anymore. Kill it. Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27update a few Porcelain-ish for ref lock safety.Libravatar Junio C Hamano1-3/+3
This updates the use of git-update-ref in git-branch, git-tag and git-commit to make them safer in a few corner cases as demonstration. - git-tag makes sure that the named tag does not exist, allows you to edit tag message and then creates the tag. If a tag with the same name was created by somebody else in the meantime, it used to happily overwrote it. Now it notices the situation. - git-branch -d and git-commit (for the initial commit) had the same issue but with smaller race window, which is plugged with this. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-12Teach runstatus about --untrackedLibravatar Johannes Schindelin1-1/+2
Actually, teach runstatus what to do if it is not passed; it should not list the contents of completely untracked directories, but only the name of that directory (plus a trailing '/'). [jc: with comments by Jeff King to match hide-empty-directories behaviour of the original.] Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-08git-commit.sh: convert run_status to a C builtinLibravatar Jeff King1-99/+7
This creates a new git-runstatus which should do roughly the same thing as the run_status function from git-commit.sh. Except for color support, the main focus has been to keep the output identical, so that it can be verified as correct and then used as a C platform for other improvements to the status printing code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-13Do not use perl in git-commit.shLibravatar Alex Riesen1-19/+13
git-commit.sh has the only one place where perl is used and there it can quite trivially be done in sh. git-ls-files without "-z" produces quoted output, even if is different from that produced by perl code it is good enough. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-10Record the type of commit operation in the reflog.Libravatar Shawn Pearce1-1/+5
If committing a merge (.git/MERGE_HEAD exists), an initial tree (no HEAD) or using --amend to amend the prior commit then denote the subtype of commit in the reflog. This helps to distinguish amended or merge commits from normal commits. In the case of --amend the prior sha1 is probably the commit which is being thrown away in favor of the new commit. Since it is likely that the old commit doesn't have any ref pointing to it anymore it can be interesting to know why that the commit was replaced and orphaned. In the case of a merge the prior sha1 is probably the first parent of the new merge commit. Consequently having its prior sha1 in the reflog is slightly less interesting but its still informative to know the commit was the result of a merge which had to be completed by hand. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-10Fix more typos, primarily in the codeLibravatar Pavel Roskin1-1/+1
The only visible change is that git-blame doesn't understand "--compability" anymore, but it does accept "--compatibility" instead, which is already documented. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-08Using 'perl' in *.shLibravatar Michal Rokos1-1/+1
Some GIT's shell script are using bare 'perl' for perl invocation. Use @@PERL@@ symbol and replace it with PERL_PATH_SQ everywhere. Signed-off-by: Michal Rokos <michal.rokos@nextsoft.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-29Racy GIT (part #3)Libravatar Junio C Hamano1-1/+1
Commit 29e4d3635709778bcc808dbad0477efad82f8d7e fixed the underlying update-index races but git-commit was not careful enough to preserve the index file timestamp when copying the index file. This caused t3402 test to occasionally fail. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27Fix expr usage for FreeBSDLibravatar Dennis Stosberg1-9/+9
Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: Dennis Stosberg <dennis@stosberg.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-26Merge branch 'jc/squash'Libravatar Junio C Hamano1-2/+5
* jc/squash: git-merge --squash
2006-06-25git-commit: filter out log message lines only when editor was run.Libravatar Yann Dirson1-7/+12
The current behaviour strips out lines starting with a # even when fed through stdin or -m. This is particularly bad when importing history from another SCM (tailor 0.9.23 uses git-commit). In the best cases all lines are stripped and the commit fails with a confusing "empty log message" error, but in many cases the commit is done, with loss of information. Note that it is quite peculiar to just have "#" handled as a leading comment char here. One commonly meet CVS: or CG: or STG: as prefixes, and using GIT: would be more robust as well as consistent with other commit tools. However, that would break any tool relying on the # (if any). Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24git-merge --squashLibravatar Junio C Hamano1-2/+5
Some people tend to do many little commits on a topic branch, recording all the trials and errors, and when the topic is reasonably cooked well, would want to record the net effect of the series as one commit on top of the mainline, removing the cruft from the history. The topic is then abandoned or forked off again from that point at the mainline. The barebone porcelainish that comes with core git tools does not officially support such operation, but you can fake it by using "git pull --no-merge" when such a topic branch is not a strict superset of the mainline, like this: git checkout mainline git pull --no-commit . that-topic-branch : fix conflicts if any rm -f .git/MERGE_HEAD git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged This however does not work when the topic branch is a fast forward of the mainline, because normal "git pull" will never create a merge commit in such a case, and there is nothing special --no-commit could do to begin with. This patch introduces a new option, --squash, to support such a workflow officially in both fast-forward case and true merge case. The user-level operation would be the same in both cases: git checkout mainline git pull --squash . that-topic-branch : fix conflicts if any -- naturally, there would be : no conflict if fast forward. git commit -a -m 'consolidated commit log message' git branch -f that-topic-branch ;# now fully merged When the current branch is already up-to-date with respect to the other branch, there truly is nothing to do, so the new option does not have any effect. This was brought up in #git IRC channel recently. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-23git-commit: allow -e option anywhere on command lineLibravatar Jeff King1-1/+3
Previously, the command 'git-commit -e -m foo' would ignore the '-e' option because the '-m' option overwrites the no_edit flag during sequential option parsing. Now we cause -e to reset the no_edit flag after all options are parsed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-31Merge branch 'master' into nextLibravatar Junio C Hamano1-7/+30
* master: send-email: only 'require' instead of 'use' Net::SMTP Allow multiple -m options to git-commit.
2006-05-31Allow multiple -m options to git-commit.Libravatar Shawn Pearce1-7/+30
I find it very convenient to be able to supply multiple paragraphs of text on the command line with a single git-commit call. This change permits multiple -m/--message type options to be supplied to git-commit with each message being added as its own paragraph of text in the commit message. The -m option is still not permitted with -c/-C/-F nor are multiple occurrences of these options permitted. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-26Merge branch 'master' into nextLibravatar Junio C Hamano1-0/+3
* master: Call builtin ls-tree in git-cat-file -p built-in format-patch: various fixups. Add instructions to commit template.
2006-05-26Add instructions to commit template.Libravatar Martin Waitz1-0/+3
New users can be irritated by the git status text in their editor. Let's give them a short help. Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-23Merge branch 'sp/reflog' into nextLibravatar Junio C Hamano1-1/+2
* sp/reflog: Enable ref log creation in git checkout -b. Create/delete branch ref logs. Include ref log detail in commit, reset, etc. Change order of -m option to update-ref. Correct force_write bug in refs.c Change 'master@noon' syntax to 'master@{noon}'. Log ref updates made by fetch. Force writing ref if it doesn't exist. Added logs/ directory to repository layout. General ref log reading improvements. Fix ref log parsing so it works properly. Support 'master@2 hours ago' syntax Log ref updates to logs/refs/<ref> Convert update-ref to use ref_lock API. Improve abstraction of ref lock/write.
2006-05-23git status: skip empty directories, and add -u to show all untracked filesLibravatar Matthias Lederhofer1-3/+14
By default, we use --others --directory to show uninteresting directories (to get user's attention) without their contents (to unclutter output). Showing empty directories do not make sense, so pass --no-empty-directory when we do so. Giving -u (or --untracked) disables this uncluttering to let the user get all untracked files. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-19Include ref log detail in commit, reset, etc.Libravatar Shawn Pearce1-1/+2
When updating a ref at the direction of the user include a reason why head was changed as part of the ref log (assuming it was enabled). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-14Ensure author & committer before asking for commit message.Libravatar Sean1-0/+2
It's better to find out you need to fix your author and committer information before you enter a long commit message. Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-20git-commit --amend: two fixes.Libravatar Junio C Hamano1-7/+14
When running "git commit --amend" only to fix the commit log message without any content change, we mistakenly showed the git-status output that says "nothing to commit" without commenting it out. If you have already run update-index but you want to amend the top commit, "git commit --amend --only" without any paths should have worked, because --only means "starting from the base commit, update-index these paths only to prepare the index to commit, and perform the commit". However, we refused -o without paths. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-13Shell utilities: Guard against expr' magic tokens.Libravatar Mark Wooding1-2/+2
Some words, e.g., `match', are special to expr(1), and cause strange parsing effects. Track down all uses of expr and mangle the arguments so that this isn't a problem. Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-12git-commit: do not muck with commit message when no_edit is set.Libravatar Junio C Hamano1-5/+12
Spotted by Linus and Darrin Thompson. When we took a commit message from -F <file> with an incomplete line, we appended "git status" output, which ended up attaching a lone "#" at the end. We still need the "do we have anything to commit?" check by running "status" (which has to know what to do in different cases with -i/-o/-a), but there is no point appending its output to the proposed commit message given by the user. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-20Be verbose when !initial commitLibravatar Yasushi SHOJI1-1/+1
verbose option in git-commit.sh lead us to run git-diff-index, which needs a commit-ish we are making diff against. When we are commiting the fist set, we obviously don't have any commit-ish in the repo. So we just skip the git-diff-index run. It might be possible to produce diff against empty but do we need that? Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-05git-commit --amend: allow empty commit.Libravatar Junio C Hamano1-1/+1
When amending a commit only to update the commit log message, git-status would rightly say "Nothing to commit." Do not let this prevent commit to be made. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-02git-commit: make sure we protect against races.Libravatar Junio C Hamano1-0/+2
An earlier commit 8098a178b26dc7a158d129a092a5b78da6d12b72 accidentally lost race protection from git-commit command. This commit reinstates it. When something else updates HEAD pointer while you were editing your commit message, the command would notice and abort the commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-02git-commit --amendLibravatar Junio C Hamano1-4/+39
The new flag is used to amend the tip of the current branch. Prepare the tree object you would want to replace the latest commit as usual (this includes the usual -i/-o and explicit paths), and the commit log editor is seeded with the commit message from the tip of the current branch. The commit you create replaces the current tip -- if it was a merge, it will have the parents of the current tip as parents -- so the current top commit is discarded. It is a rough equivalent for: $ git reset --soft HEAD^ $ ... do something else to come up with the right tree ... $ git commit -c ORIG_HEAD but can be used to amend a merge commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-14Merge branch 'jc/commit'Libravatar Junio C Hamano1-7/+9
* jc/commit: commit: detect misspelled pathspec while making a partial commit. combine-diff: diff-files fix (#2) combine-diff: diff-files fix.
2006-02-14commit: detect misspelled pathspec while making a partial commit.Libravatar Junio C Hamano1-10/+9
When you say "git commit Documentaiton" to make partial commit for the files only in that directory, we did not detect that as a misspelled pathname and attempted to commit index without change. If nothing matched, there is no harm done, but if the index gets modified otherwise by having another valid pathspec or after an explicit update-index, a user will not notice without paying attention to the "git status" preview. This introduces --error-unmatch option to ls-files, and uses it to detect this common user error. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-12git-commit: Now --only semantics is the default.Libravatar Junio C Hamano1-6/+3
This changes the "git commit paths..." to default to --only semantics from traditional --include semantics, as agreed on the list. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-11Only call git-rerere if $GIT_DIR/rr-cache exists.Libravatar Junio C Hamano1-1/+4
Johannes noticed that git-rerere depends on Digest.pm, and if one does not use the command, one can live without it. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10git-commit -v: have patch at the end.Libravatar Junio C Hamano1-27/+18
It was pointed out that otherwise more important summary information prefixed with '#' would become prone to be missed. Also instead of chopping at the first '^---$' line, stop at the first 'diff --git a/' line. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10git-status -vLibravatar Junio C Hamano1-60/+250
This revamps the git-status command to take the same set of parameters as git commit. It gives a preview of what is being committed with that command. With -v flag, it shows the diff output between the HEAD commit and the index that would be committed if these flags were given to git-commit command. git-commit also acquires -v flag (it used to mean "verify" but that is the default anyway and there is --no-verify to turn it off, so not much is lost), which uses the updated git-status -v to seed the commit log buffer. This is handy for writing a log message while reviewing the changes one last time. Now, git-commit and git-status are internally share the same implementation. Unlike previous git-commit change, this uses a temporary index to prepare the index file that would become the real index file after a successful commit, and moves it to the real index file once the commit is actually made. This makes it safer than the previous scheme, which stashed away the original index file and restored it after an aborted commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06git-commit: finishing touches.Libravatar Junio C Hamano1-40/+73
Introduce --only flag to allow the new "partial commit" semantics when paths are specified. The default is still the traditional --include semantics. Once peoples' fingers and scripts that want the traditional behaviour are updated to explicitly say --include, we could change it to either default to --only, or refuse to operate without either --only/--include when paths are specified. This also fixes a couple of bugs in the previous round. Namely: - forgot to save/restore index in some cases. - forgot to use the temporary index to show status when '--only paths...' semantics was used. - --author did not take precedence when reusing an existing commit. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06git-commit: revamp the git-commit semantics.Libravatar Junio C Hamano1-112/+291
- "git commit" without _any_ parameter keeps the traditional behaviour. It commits the current index. We commit the whole index even when this form is run from a subdirectory. - "git commit --include paths..." (or "git commit -i paths...") is equivalent to: git update-index --remove paths... git commit - "git commit paths..." acquires a new semantics. This is an incompatible change that needs user training, which I am still a bit reluctant to swallow, but enough people seem to have complained that it is confusing to them. It 1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds trained git users that the traditional semantics now needs -i flag. 2. refuses to run if named paths... are different in HEAD and the index (ditto about reminding). Added paths are OK. 3. reads HEAD commit into a temporary index file. 4. updates named paths... from the working tree in this temporary index. 5. does the same updates of the paths... from the working tree to the real index. 6. makes a commit using the temporary index that has the current HEAD as the parent, and updates the HEAD with this new commit. - "git commit --all" can run from a subdirectory, but it updates the index with all the modified files and does a whole tree commit. - In all cases, when the command decides not to create a new commit, the index is left as it was before the command is run. This means that the two "git diff" in the following sequence: $ git diff $ git commit -a $ git diff would show the same diff if you abort the commit process by making the commit log message empty. This commit also introduces much requested --author option. $ git commit --author 'A U Thor <author@example.com>' Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-06git-rerere: reuse recorded resolve.Libravatar Junio C Hamano1-0/+1
In a workflow that employs relatively long lived topic branches, the developer sometimes needs to resolve the same conflict over and over again until the topic branches are done (either merged to the "release" branch, or sent out and accepted upstream). This commit introduces a new command, "git rerere", to help this process by recording the conflicted automerge results and corresponding hand-resolve results on the initial manual merge, and later by noticing the same conflicted automerge and applying the previously recorded hand resolution using three-way merge. Signed-off-by: Junio C Hamano <junkio@cox.net>