summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* svn-git: Use binmode for reading/writing binary rev mapsMichael Weber2008-04-221-0/+4
| | | | | | | | | | | | | | Otherwise, there is a possible interaction with UTF-8 locales in combination with PERL_UNICODE, resulting in "inconsistent size: 40" or "read:"-type errors. See also: perldoc -f binmode <http://perldoc.perl.org/perl581delta.html#UTF-8-no-longer-default-under-UTF-8-locales> Signed-off-by: Michael Weber <michaelw@foldr.org> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* diff options documentation: refer to --diff-filter in --name-statusMiklos Vajna2008-04-221-1/+2
| | | | | | | | git diff --name-status outputs letters, but the meaning of those letters is documented elsewhere. Add a note to make the manpage more intuitive. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-svn bug with blank commits and author fileThomas Guyot-Sionnest2008-04-221-2/+1
| | | | | | | | | | | | | | When trying to import from svn using an author file, git-svn bails out if it encounters a blank author. The attached patch changes this behavior and allow using the author file with blanks authors. I came across this bug while importing from a cvs2svn repo where the initial revision (1) has a blank author. This doesn't break the behavior of bailing out when an unknown author is encountered. Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* archive.c: format_subst - fixed bogus argument to memchrAriel Badichi2008-04-221-2/+2
| | | | | | | Also removed a superfluous test. Signed-off-by: Ariel Badichi <abadichi@bezeqint.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* copy.c: copy_fd - correctly report write errorsAriel Badichi2008-04-221-4/+4
| | | | | | | | | | Previously, the errno could have been lost due to an intervening close() call. This patch also contains minor cosmetic changes. Signed-off-by: Ariel Badichi <abadichi@bezeqint.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* gitattributes: Fix subdirectory attributes specified from root directoryMatthew Ogilvie2008-04-222-1/+11
| | | | | Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* am: POSIX portability fixJunio C Hamano2008-04-181-1/+1
| | | | | | | | | | | POSIX allows echo without flag to interpret specials such as \n, and we tried to make things portable by using printf instead where it matters. Recently added code to "git am" had unprotected "echo", which was caught by t4014 and Rémi Vanicat. This should fix it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-am: minor cleanupJunio C Hamano2008-04-161-2/+1
| | | | | | | | | This moves the assignment to FIRSTLINE down so that we do not have to have multiple copies. Suggested by Linus. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Clarify and fix English in "git-rm" documentationJon Loeliger2008-04-161-20/+32
| | | | | | | | | Do some verb-noun agreement changes. Clarify some file globbing cases. Fixed a wrong statement in an example. Signed-off-by: Jon Loeliger <jdl@jdl.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-bisect: make "start", "good" and "skip" succeed or fail atomicallyChristian Couder2008-04-162-5/+16
| | | | | | | | | | | | | | | | | | | | Before this patch, when "git bisect start", "git bisect good" or "git bisect skip" were called with many revisions, they could fail after having already marked some revisions as "good", "bad" or "skip". This could be especilally bad for "git bisect start" because as the file ".git/BISECT_NAMES" would not have been written, there would have been no attempt to clear the marked revisions on a "git bisect reset". That's because if there is no ".git/BISECT_NAMES" file, nothing is done to clean things up, as the bisect session is not supposed to have started. While at it, let's also create the ".git/BISECT_START" file, only after ".git/BISECT_NAMES" as been created. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-am: cope better with an empty Subject: lineLinus Torvalds2008-04-161-14/+10
| | | | | | | | | | | | | | | | When the Subject: line is empty for whatever reason, git-am was fooled by it and left an empty line at the beginning of the resulting commit log message. This moves the logic around so that we do not keep $SUBJECT in a separate variable. Instead, $dotest/msg-clean, which used to be the log message body extracted from the message and then trailing whitespaces cleansed out, now contains the subject line followed by a blank line at the beginning for normal messages, and we use the first line from the file as the summary line throughout the program. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Ignore leading empty lines while summarizing mergesLinus Torvalds2008-04-151-1/+9
| | | | | | | | | | | | "git log" and friends normally skip the initial empty lines when showing one-line summary of a commit, but merge summary didn't. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> ---- builtin-fmt-merge-msg.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
* bisect: squelch "fatal: ref HEAD not a symref" misleading messageChristian Couder2008-04-151-1/+1
| | | | | | | | | | | | | | | | | | To get the current HEAD when we start bisecting using for example "git bisect start", we first try "git symbolic-ref HEAD" to get a nice name, and if it fails, we fall back to "git rev-parse --verify HEAD". The problem is that when "git symbolic-ref HEAD" fails, it displays "fatal: ref HEAD not a symref", so it looks like "git bisect start" failed and does not accept detached HEAD, even if in fact it worked fine. This patch adds "-q" option to the "git symbolic-ref" call to get rid of the misleading error message. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin-apply: Show a more descriptive error on failure when opening a patchAlberto Bertogli2008-04-151-1/+1
| | | | | | | | | When a patch can't be opened (it doesn't exist, there are permission problems, etc.) we get the usage text, which is not a proper indication of failure. Signed-off-by: Alberto Bertogli <albertito@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Clarify documentation of git-cvsserver, particularly in relation to git-shellScott Collins2008-04-151-11/+17
| | | | | | | | | | | | | | | | | | | For SSH clients restricted to git-shell, CVS_SERVER does not have to be specified, because git-shell understands the default value of 'cvs' to mean git-cvsserver'. This makes it totally transparent to CVS users, but the instruction to set up CVS access for people with real shell access does not apply. Previous wording mentioning GIT_AUTHOR, GIT_COMMITTER variables was unclear that we really meant GIT_AUTHOR_(NAME|EMAIL), etc. Note that the .ssh/environment file is a good place to set these, and that the .bashrc is shell-specific. Add a bit of text to differentiate cvs -d (setting CVSROOT) from cvs co -d (setting the name of the newly checked out directory). Removed an extra 'Example:' string. Signed-off-by: Scott Collins <scc@ScottCollins.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Docs gitk: Explicitly mention the files that gitk uses (~/.gitk)Clifford Caoile2008-04-121-0/+5
| | | | | | | gitk creates and uses ~/.gitk Signed-off-by: Clifford Caoile <piyo@users.sourceforge.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Document -w option to shortlogJunio C Hamano2008-04-122-3/+9
| | | | | | Noticed by Fredrik Noring. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* bisect: report bad rev betterChristian Couder2008-04-121-2/+2
| | | | | | | | | The previous one overwrote the variable used to report the bad input when the input is actually bad, and we did not give a useful enough information. This corrects it. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* bisect: fix bad rev checking in "git bisect good"Christian Couder2008-04-112-9/+18
| | | | | | | | | | | | | | | | | | | | | | | It seems that "git bisect good" and "git bisect skip" have never properly checked arguments that have been passed to them. As soon as one of them can be parsed as a SHA1, no error or warning would be given. This is because 'git rev-parse --revs-only --no-flags "$@"' always "exit 0" and outputs all the SHA1 it can found from parsing "$@". This patch fix this by using, for each "bisect good" argument, the same logic as for the "bisect bad" argument. While at it, this patch teaches "bisect bad" to give a meaningfull error message when it is passed more than one argument. Note that if "git bisect good" or "git bisect skip" is given some proper revs and then something that is not a proper rev, then the first proper revs will still have been marked as "good" or "skip". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* revision.c: make --date-order overriddableMichele Ballabio2008-04-111-0/+1
| | | | | | | | | Jan Engelhardt noticed that while --topo-order can be overridden by a subsequent --date-order, the reverse was not possible. That's because setup_revisions() failed to set revs->lifo properly. Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix section about backdating tags in the git-tag docsBjörn Steinbrink2008-04-111-2/+2
| | | | | | | | | The tagger is equal to the committer, not the author, so GIT_COMMITTER_DATE is the right environment variable to use, not GIT_AUTHOR_DATE. Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Document option --only of git commitJohannes Sixt2008-04-112-1/+12
| | | | | | | | | | Its documentation was removed by 6c96753 (Documentation/git-commit: rewrite to make it more end-user friendly, 2006-12-08), even though it is referenced from a few places, including builtin-commit.c (as part of the commentary in the commit message template). Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation/git-request-pull: Fixed a typo ("send" -> "end")Dirk Suesserott2008-04-111-1/+1
| | | | | Signed-off-by: Dirk Suesserott <newsletter@dirk.my1.cc> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* core-tutorial.txt: Fix showing the current behaviour.Carlos Rica2008-04-101-6/+6
| | | | | | | | | | | | The --root option from "git diff-tree" won't do nothing when is given to commands like git-whatchanged or git-log, because those always print the initial commit by default. This fixes the tutorial explaining the function of the log.showroot configuration variable. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-archive: ignore prefix when checking file attributeRené Scharfe2008-04-103-5/+22
| | | | | | | | | | | | | | | | Ulrik Sverdrup noticed that git-archive doesn't correctly apply the attribute export-subst when the option --prefix is given, too. When it checked if a file has the attribute turned on, git-archive would try to look up the full path -- including the prefix -- in .gitattributes. That's wrong, as the prefix doesn't need to have any relation to any existing directories, tracked or not. This patch makes git-archive ignore the prefix when looking up if value of the attribute export-subst for a file. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix documentation syntax of optional arguments in short options.Carlos Rica2008-04-103-4/+4
| | | | | | | | | | | When an argument for an option is optional, like in -n from git-tag, puting a space between the option and the argument is interpreted as a missing argument for the option plus an isolated argument. Documentation now reflects the need to write the parameter following the option -n, as in "git tag -nARG", for instance. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix "git apply" to correctly enforce "match at the beginning"Junio C Hamano2008-04-062-13/+29
| | | | | | | | | | | | | | | | | An earlier commit 4be6096 (apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches, 2006-09-17) made match_beginning and match_end computed incorrectly. If a hunk inserts at the beginning, old position recorded at the hunk is line 0, and if a hunk changes at the beginning, it is line 1. The new test added to t4104 exposes that the old code did not insist on matching at the beginning for a patch to add a line to an empty file. An even older 65aadb9 (apply: force matching at the beginning., 2006-05-24) was equally wrong in that it tried to take hints from the number of leading context lines, to decide if the hunk must match at the beginning, but we can just look at the line number in the hunk to decide. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* GIT 1.5.4.5v1.5.4.5Junio C Hamano2008-03-272-7/+1
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Update draft release notes for 1.5.4.5Junio C Hamano2008-03-271-1/+10
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jc/maint-fetch-regression-1.5.4' into maintJunio C Hamano2008-03-2770-55/+1067
|\ | | | | | | | | | | | | * jc/maint-fetch-regression-1.5.4: git-fetch test: test tracking fetch results, not just FETCH_HEAD Fix branches file configuration Tighten refspec processing
| * git-fetch test: test tracking fetch results, not just FETCH_HEADJunio C Hamano2008-03-2665-7/+831
| | | | | | | | | | | | | | | | | | | | We really should have done this long time ago. Existing t5515 test was written for the specific purpose of catching regression to the contents of generated FETCH_HEAD file, but it also is a good place to make sure various fetch configurations do fetch what they intend to fetch (and nothing else). Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Fix branches file configurationDaniel Barkalow2008-03-261-6/+22
| | | | | | | | | | | | | | | | | | Fetched remote branch from .git/branches/foo should fetch into refs/heads/foo. Also when partial URL is given, the fetched head should always be remote HEAD, and the result should not be stored anywhere. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Tighten refspec processingDaniel Barkalow2008-03-265-42/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the pattern matching code to not store the required final / before the *, and then to require each side to be a valid ref (or empty). In particular, any refspec that looks like it should be a pattern but doesn't quite meet the requirements will be found to be invalid as a fallback non-pattern. This was cherry picked from commit ef00d15 (Tighten refspec processing, 2008-03-17), and two fix-up commits 46220ca (remote.c: Fix overtight refspec validation, 2008-03-20) and 7d19da4 (refspec: allow colon-less wildcard "refs/category/*", 2008-03-25) squashed in. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Documentation: clarify use of .git{ignore,attributes} versus .git/info/*Jeff King2008-03-272-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | gitignore patterns can be read from three different files, while gitattributes can come from two files. Let's provide some hints to the user about the differences and how they are typically used. Suggested by Toby Corkindale, but gratuitously reworded by Jeff King. Signed-off-by: Toby Corkindale <toby.corkindale@rea-group.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t/t3800-mktag.sh: use test_must_fail rather than '!'Brandon Casey2008-03-261-2/+2
|/ | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix the wrong output of `git-show v1.3.0~155^2~4` in documentation.Guanqun Lu2008-03-261-1/+1
| | | | | | | | Texts between ~ and ~ will be subscripted during the asciidoc translation. Signed-off-by: Guanqun Lu <Guanqun.Lu@Gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> (cherry picked from commit 0c829391cfcdc57172765322575804a7ad5f3116)
* Start draft ReleaseNotes for 1.5.4.5Junio C Hamano2008-03-162-1/+54
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rebase -m: do not trigger pre-commit verificationJunio C Hamano2008-03-161-1/+1
| | | | | | | | | | | | When rebasing changes that contain issues that the pre-commit hook flags as problematic, the rebase cannot be continued. However, rebase is about transplanting commits that are already made with as little distortion as possible, and pre-commit check should not interfere. Earlier, c5b09fe (Avoid update hook during git-rebase --interactive, 2007-12-19) fixed "rebase -i", but "rebase -m" shared the same issue. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* format-patch: generate MIME header as needed even when there is format.headerJunio C Hamano2008-03-155-16/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Earlier, the callchain from pretty_print_commit() down to pp_title_line() had an unwarranted assumption that the presense of "after_subject" parameter, means the caller has already output MIME headers for attachments. The parameter's primary purpose is to give extra header lines the caller wants to place after pp_title_line() generates the "Subject: " line. This assumption does not hold when the user used the format.header configuration variable to pass extra headers, and caused a message with non-ASCII character to lack proper MIME headers (e.g. 8-bit CTE header). The earlier logic also failed to suppress duplicated MIME headers when "format-patch -s --attach" is asked for and the signer's name demanded 8-bit clean transport. This patch fixes the logic by introducing a separate need_8bit_cte parameter passed down the callchain. This can have one of these values: -1 : we've already done MIME crap and we do not want to add extra header to say this is 8bit in pp_title_line(); 0 : we haven't done MIME and we have not seen anything that is 8bit yet; 1 : we haven't done MIME and we have seen something that is 8bit; pp_title_line() must add MIME header. It adds two tests by Jeff King who independently diagnosed this issue. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Make man page building quiet when DOCBOOK_XSL_172 is definedJonas Fonseca2008-03-151-1/+5
| | | | | | | | | | Tell xmlto to repress printing of the lines: Note: meta date : No date. Using generated date git-xyx Note: Writing git-xyz.1 Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-new-workdir: Share SVN meta data between work dirs and the repositoryBernt Hansen2008-03-151-1/+1
| | | | | | | | | | | | | | | Multiple work dirs with git svn caused each work dir to have its own stale copy of the SVN meta data in .git/svn git svn rebase updates commits with git-svn-id: in the repository and stores the SVN meta data information only in that work dir. Attempting to git svn rebase in other work dirs for the same branch would fail because the last revision fetched according to the git-svn-id is greater than the revision in the SVN meta data for that work directory. Signed-off-by: Bernt Hansen <bernt@norang.ca> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rev-parse: fix meaning of rev~ vs rev~0.Linus Torvalds2008-03-141-13/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I think it would make more sense for rev~ to have the same guarantees that rev^ has, namely to always return a commit. I would also suggest that not giving a number would have the same effect of defaulting to 1, not 0. Right now it's a bit illogical, but at least it's an _undocumented_ illogical behaviour. This patch makes '^' and '~' act the same for the default count (i.e. both default to 1), and also have the same behaviour for a count of zero. Before (no discernible pattern): [torvalds@woody git]$ git rev-parse v1.5.1 v1.5.1^0 v1.5.1~0 v1.5.1^ v1.5.1~ 45354a57ee7e3e42c7137db6c94fa968c6babe8d 89815cab95268e8f0f58142b848ac4cd5e9cbdcb 45354a57ee7e3e42c7137db6c94fa968c6babe8d 045f5759c97746589a067461e50fad16f60711ac 45354a57ee7e3e42c7137db6c94fa968c6babe8d After (fairly logical): [torvalds@woody git]$ git rev-parse v1.5.1 v1.5.1^0 v1.5.1~0 v1.5.1^ v1.5.1~ 45354a57ee7e3e42c7137db6c94fa968c6babe8d 89815cab95268e8f0f58142b848ac4cd5e9cbdcb 89815cab95268e8f0f58142b848ac4cd5e9cbdcb 045f5759c97746589a067461e50fad16f60711ac 045f5759c97746589a067461e50fad16f60711ac Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-svn: don't blindly append '*' to branch/tags configEric Wong2008-03-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, git-svn would blindly append '*' even if it was specified by the user during initialization (for certain SVN setups, it is necessary). Now, the following command will work correctly: git svn init -T trunk/docutils \ -t 'tags/*/docutils' \ -b 'branches/*/docutils' \ svn://svn.berlios.de/docutils Thanks to martin f krafft for the bug report: > My git-svn target configuration is > > [svn-remote "svn"] > url = svn://svn.berlios.de/docutils > fetch = trunk/docutils:refs/remotes/trunk > branches = branches/*/docutils:refs/remotes/* > tags = tags/*/docutils:refs/remotes/tags/* > > Unfortunately, when I run > > git-svn init -T trunk/docutils -t 'tags/*/docutils' > -b 'branches/*/docutils' > > then I get (note the two asterisks on the left hand side): > > branches = branches/*/docutils/*:refs/remotes/* > tags = tags/*/docutils/*:refs/remotes/tags/* > > I took a brief stab at the code but I can't even figure out where > the /* is appended, so I defer to you. > > It should be trivial to keep git-svn from appending /* if the left > side already contains an asterisk. Signed-off-by: Eric Wong <normalperson@yhbt.net> Tested-by: martin f krafft <madduck@madduck.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ph/maint-quiltimport' into maintJunio C Hamano2008-03-141-3/+19
|\ | | | | | | | | | | * ph/maint-quiltimport: quiltimport: fix misquoting of parsed -p<num> parameter git-quiltimport: better parser to grok "enhanced" series files.
| * quiltimport: fix misquoting of parsed -p<num> parameterJunio C Hamano2008-03-121-2/+2
| | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git-quiltimport: better parser to grok "enhanced" series files.Pierre Habouzit2008-03-091-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous parser wasn't able to grok: * empty lines; * annotated patch levels (trailing -pNNN annotations); * trailing comments. Now it understands them and uses the patch level hints as a git apply argument. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | merge-file: handle empty files gracefullyJohannes Schindelin2008-03-132-3/+4
| | | | | | | | | | | | | | | | | | | | Earlier, it would error out while trying to read and/or writing them. Now, calling merge-file with empty files is neither interesting nor useful, but it is a bug that needed fixing. Noticed by Clemens Buchacher. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* | merge-recursive: handle file mode changesClemens Buchacher2008-03-132-2/+62
| | | | | | | | | | | | | | | | | | | | File mode changes should be handled similarly to changes of content. That is, if the file mode changed in only one branch, keep the changed version, and if both branch changed to different mode, mark it as a conflict. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Minor wording changes in the keyboard descriptions in git-add --interactive.Vineet Kumar2008-03-131-10/+8
| | | | | | | | | | | | | | | | The wording of the interactive help text from git-add--interactive.perl is clearer. Just duplicate that text here. Signed-off-by: Vineet Kumar <vineet@doorstop.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git fetch: Take '-n' to mean '--no-tags'Johannes Schindelin2008-03-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to commit 8320199 (Rewrite builtin-fetch option parsing to use parse_options().), we understood '-n' as a short option to mean "don't fetch tags from the remote". This patch reinstates behaviour similar, but not identical to the pre commit 8320199 times. Back then, -n always overrode --tags, so if both --tags and -n was given on command-line, no tags were fetched regardless of argument ordering. Now we use a "last entry wins" strategy, so '-n --tags' means "fetch tags". Since it's patently absurd to say both --tags and --no-tags, this shouldn't matter in practice. Spotted-by: Artem Zolochevskiy <azol@altlinux.org> Reported-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Tested-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
View Lorry Controller Status