summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2009-09-02Merge branch 'maint-1.6.2' into maint-1.6.3Libravatar Junio C Hamano2-3/+7
* maint-1.6.2: clone: disconnect transport after fetching
2009-09-02git-cvsserver: no longer use deprecated 'git-subcommand' commandsLibravatar Gerrit Pape1-20/+20
git-cvsserver still references git commands like 'git-config', which is depcrecated. This commit changes git-cvsserver to use the 'git subcommand' form. Sylvain Beucler reported the problem through http://bugs.debian.org/536067 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-02clone: disconnect transport after fetchingLibravatar Jeff King2-3/+7
The current code just leaves the transport in whatever state it was in after performing the fetch. For a non-empty clone over the git protocol, the transport code already disconnects at the end of the fetch. But for an empty clone, we leave the connection hanging, and eventually close the socket when clone exits. This causes the remote upload-pack to complain "the remote end hung up unexpectedly". While this message is harmless to the clone itself, it is unnecessarily scary for a user to see and may pollute git-daemon logs. This patch just explicitly calls disconnect after we are done with the remote end, which sends a flush packet to upload-pack and cleanly disconnects, avoiding the error message. Other transports are unaffected or slightly improved: - for a non-empty repo over the git protocol, the second disconnect is a no-op (since we are no longer connected) - for "walker" transports (like HTTP or FTP), we actually free some used memory (which previously just sat until the clone process exits) - for "rsync", disconnect is always a no-op anyway Signed-off-by: Jeff King <peff@peff.net> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-27Merge branch 'maint-1.6.2' into maint-1.6.3Libravatar Junio C Hamano4-4/+4
* maint-1.6.2: Fix overridable written with an extra 'e' Documentation: git-archive: mark --format as optional in summary Round-down years in "years+months" relative date view Conflicts: Documentation/git-archive.txt
2009-08-27Fix overridable written with an extra 'e'Libravatar Nanako Shiraishi2-2/+2
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-27Merge branch 'maint-1.6.1' into maint-1.6.2Libravatar Junio C Hamano1-1/+1
* maint-1.6.1: Documentation: git-archive: mark --format as optional in summary
2009-08-27Merge branch 'maint-1.6.0' into maint-1.6.1Libravatar Junio C Hamano1-1/+1
* maint-1.6.0: Documentation: git-archive: mark --format as optional in summary
2009-08-27Documentation: git-archive: mark --format as optional in summaryLibravatar Wesley J. Landaker1-1/+1
The --format option was made optional in 8ff21b1 (git-archive: make tar the default format, 2007-04-09), but it was not marked as optional in the summary. This trival patch just changes the summary to match the rest of the documentation. Signed-off-by: Wesley J. Landaker <wjl@icecavern.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-27Merge branch 'maint-1.5.6' into maint-1.6.0Libravatar Junio C Hamano2-2/+43
* maint-1.5.6: revision traversal and pack: notice and die on missing commit
2009-08-27Round-down years in "years+months" relative date viewLibravatar David Reiss1-1/+1
Previously, a commit from 1 year and 7 months ago would display as "2 years, 7 months ago". Signed-off-by: David Reiss <dreiss@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-26Merge branch 'tr/maint-1.6.3-add-p-modeonly-fix' into maint-1.6.3Libravatar Junio C Hamano2-0/+15
* tr/maint-1.6.3-add-p-modeonly-fix: add -p: do not attempt to coalesce mode changes git add -p: demonstrate failure when staging both mode and hunk
2009-08-15add -p: do not attempt to coalesce mode changesLibravatar Thomas Rast2-1/+5
In 0392513 (add-interactive: refactor mode hunk handling, 2009-04-16), we merged the interaction loops for mode changes and hunk staging. This was fine at the time, because 0beee4c (git-add--interactive: remove hunk coalescing, 2008-07-02) removed hunk coalescing. However, in 7a26e65 (Revert "git-add--interactive: remove hunk coalescing", 2009-05-16), we resurrected it. Since then, the code would attempt in vain to merge mode changes with diff hunks, corrupting both in the process. We add a check to the coalescing loop to ensure it only looks at diff hunks, thus skipping mode changes. Noticed-by: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-15git add -p: demonstrate failure when staging both mode and hunkLibravatar Kirill Smelkov1-0/+11
When trying to stage changes to file which has also pending `chmod +x`, `git add -p` produces lots of 'Use of uninitialized value ...' warnings and fails to do the job: $ echo content >> file $ chmod +x file $ git add -p diff --git a/file b/file index e69de29..d95f3ad --- a/file +++ b/file old mode 100644 new mode 100755 Stage mode change [y,n,q,a,d,/,j,J,g,?]? y @@ -0,0 +1 @@ +content Stage this hunk [y,n,q,a,d,/,K,g,e,?]? y Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776. Use of uninitialized value $ofs in numeric le (<=) at .../git-add--interactive line 806. Use of uninitialized value $o0_ofs in concatenation (.) or string at .../git-add--interactive line 830. Use of uninitialized value $n0_ofs in concatenation (.) or string at .../git-add--interactive line 830. Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776. fatal: corrupt patch at line 5 diff --git a/file b/file index e69de29..d95f3ad --- a/file +++ b/file @@ -,0 + @@ +content Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-12Change mentions of "git programs" to "git commands"Libravatar Ori Avtalion8-10/+10
Most of the docs and printouts refer to "commands" when discussing what the end users call via the "git" top-level program. We should refer them as "git programs" when we discuss the fact that the commands are implemented as separate programs, but in other contexts, it is better to use the term "git commands" consistently. Signed-off-by: Ori Avtalion <ori@avtalion.name> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-12Documentation: merge: one <remote> is requiredLibravatar Paul Bolle1-1/+1
merge only requires one <remote>, so "<remote>..." should be used in the synopsis (and not "<remote> <remote>..."). Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-12help.c: give correct structure's size to memset()Libravatar Johan Herland1-1/+1
These two structures are of the same type, but we'd better be consistent. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-10Fix typos in git-remote.txt and git-symbolic-ref.txtLibravatar Štěpán Němec2-4/+4
Signed-off-by: Štěpán Němec <stepnem@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-07Merge branch 'maint-1.6.2' into maint-1.6.3Libravatar Junio C Hamano2-11/+27
* maint-1.6.2: verify-pack -v: do not report "chain length 0" t5510: harden the way verify-pack is used
2009-08-07Merge branch 'maint-1.6.1' into maint-1.6.2Libravatar Junio C Hamano2-11/+27
* maint-1.6.1: verify-pack -v: do not report "chain length 0" t5510: harden the way verify-pack is used
2009-08-07Merge branch 'maint-1.6.0' into maint-1.6.1Libravatar Junio C Hamano2-11/+27
* maint-1.6.0: verify-pack -v: do not report "chain length 0" t5510: harden the way verify-pack is used
2009-08-07verify-pack -v: do not report "chain length 0"Libravatar Junio C Hamano1-8/+19
When making a histogram of delta chain length in the pack, the program collects number of objects whose delta depth exceeds the MAX_CHAIN limit in histogram[0], and showed it as the number of items that exceeds the limit correctly. HOWEVER, it also showed the same number labeled as "chain length = 0". In fact, we are not showing the number of objects whose chain length is zero, i.e. the base objects. Correct this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-07t5510: harden the way verify-pack is usedLibravatar Junio C Hamano1-3/+8
The test ignored the exit status from verify pack command, and also relied on not seeing any delta chain statistics. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-05Better usage string for reflog.Libravatar Matthieu Moy1-1/+1
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-04hg-to-git: don't import the unused popen2 moduleLibravatar Miklos Vajna1-1/+1
Importing the popen2 module in Python-2.6 results in the "DeprecationWarning: The popen2 module is deprecated. Use the subprocess module." message. The module itself isn't used in fact, so just removing it solves the problem. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-04send-email: remove debug traceLibravatar Erik Faye-Lund1-1/+0
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
2009-07-31config: Keep inner whitespace verbatimLibravatar Björn Steinbrink2-6/+9
Configuration values are expected to be quoted when they have leading or trailing whitespace, but inner whitespace should be kept verbatim even if the value is not quoted. This is already documented in git-config(1), but the code caused inner whitespace to be collapsed to a single space, breaking, for example, clones from a path that has two consecutive spaces in it, as future fetches would only see a single space. Reported-by: John te Bokkel <tanj.tanj@gmail.com> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-28GIT 1.6.3.4Libravatar Junio C Hamano3-2/+38
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-28config.txt: document add.ignore-errorsLibravatar Stephen Boyd1-0/+5
Use the description of "--ignore-errors" from git-add.txt as inspiration. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-28request-pull: allow ls-remote to notice remote.$nickname.uploadpackLibravatar Tom Grennan1-1/+1
The location to pull from should be converted from the configured nickname to URL in the message, but ls-remote should be fed the nickname so that the command uses remote.$nickname.* variables, most notably "uploadpack". Signed-off-by: Tom Grennan <tgrennan@redback.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-25t8005: Nobody writes Russian in shift_jisLibravatar Junio C Hamano4-17/+19
The second and third tests of this script expected that Russian strings are converted between ISO-8859-5 and Shift_JIS in the "blame --porcelain" format output correctly. Sure, many platforms may convert between such a combination, but that is only because one of the base character set of Shift_JIS, JIS X 0208, defines codepoints for Russian characters (among others); I do not think anybody uses Shift_JIS when seriously writing Russian, and it is perfectly understandable if iconv() libraries on some platforms fail converting between this combination, as it does not matter in reality. This patch changes the test to verify Japanese strings are converted correctly between EUC-JP and Shift_JIS in the same procedure. The point of the test is not about verifying the platform's iconv() library, but to see if "git blame" makes correct iconv() library calls when it should. We could instead use ISO-8859-5 and KOI8-R as the combination, because they are both meant to represent Russian, in order to make this test meaningful on more platforms, but we already use Shift_JIS vs EUC-JP combinations to test other programs in our test suite, so this combination is safer from the point of view of the portability. Besides, I do not read nor write Russian; sorry ;-) This change allows tests to pass on my (friend's) Solaris 5.11 box. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-25Fix severe breakage in "git-apply --whitespace=fix"Libravatar Junio C Hamano2-5/+9
735c674 (Trailing whitespace and no newline fix, 2009-07-22) completely broke --whitespace=fix, causing it to lose all the empty lines in a patch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24SunOS grep does not understand -C<n> nor -eLibravatar Junio C Hamano1-0/+1
The first "grep -C1" test in t7002 does not pass on my SunOS-5.11-i86pc, and that is not because our way to spawn external grep is broken, but because the native grep does not understand -C<n>. It turns out that Peff was also using this option himself because our Makefile doesn't do that automatically. Brandon Casey uses SUNWspro compiler without having to set this, and it turns out that the compiler does not define preprocessor macro __unix__ which made him always use the built-in grep, never an external one. Let's be more explicit and say that we do not use external grep on Suns. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24Fix export_marks() error handling.Libravatar Matthias Andree1-4/+10
- Don't leak one FILE * on error per export_marks() call. Found with cppcheck and reported by Martin Ettl. - Abort the potentially long for(;idnums.size;) loop on write errors. - Record error if fprintf() fails for reasons not required to set the stream error indicator, such as ENOMEM. - Add a trailing full-stop to error message when fopen() fails. Signed-off-by: Matthias Andree <matthias.andree@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-23git branch: clean up detached branch handlingLibravatar Linus Torvalds1-15/+23
Make the 'show detached branch info' a routine of its own. And in the process, avoid the object lookup that is unnecessary if the current branch isn't detached. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-23git branch: avoid unnecessary object lookupsLibravatar Linus Torvalds1-10/+14
They can be expensive in the cold-cache case, so don't bother looking up the commits for all branches unless we really need them for some reason. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-23git branch: fix performance problemLibravatar Linus Torvalds1-5/+5
'git branch' looks at _all_ the refs, and verifies them. Which means that during cold-cache situations with a slow disk (and lots of tags, for example) it can take several very annoying seconds (7.5s according to a report by Carlos R. Mafra). This avoids most of it by simply doing the filtering before looking up the commits, by using the "raw" version of for_each_ref. Reported-by: Carlos R. Mafra <crmafra2@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-22do_one_ref(): null_sha1 check is not about broken refLibravatar Junio C Hamano1-2/+3
f8948e2 (remote prune: warn dangling symrefs, 2009-02-08) introduced a more dangerous variant of for_each_ref() family that skips the check for dangling refs, but it also made another unrelated check optional by mistake. The check to see if a ref points at 0{40} is not about brokenness, but is about a possible future plan to represent a deleted ref by writing 40 "0" in a loose ref when there is a stale version of the same ref already in .git/packed-refs, so that we can implement deletion of a ref without having to rewrite the packed refs file excluding the ref being deleted. This check has to live outside of the conditional. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-22Trailing whitespace and no newline fixLibravatar SZEDER Gábor2-3/+20
If a patch adds a new line to the end of a file and this line ends with one trailing whitespace character and has no newline, then '--whitespace=fix' currently does not remove that trailing whitespace. This patch fixes this by removing the check for trailing whitespace at the end of the line at a hardcoded offset which does not take the eventual absence of newline into account. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-22diff --cc: a lost line at the beginning of the file is shown incorrectlyLibravatar Junio C Hamano2-7/+93
When combine-diff inspected the diff from one parent to the merge result, it misinterpreted a header in the form @@ -l,k +0,0 @@. This hunk header means that K lines were removed from the beginning of the file, so the lost lines must be queued to the sline that represents the first line of the merge result, but we incremented our pointer incorrectly and ended up queuing it to the second line, which in turn made the lossage appear _after_ the first line. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-22combine-diff.c: fix performance problem when folding common deleted linesLibravatar Junio C Hamano1-8/+5
For a deleted line in a patch with the parent we are looking at, the append_lost() function finds the same line among a run of lines that were deleted from the same location by patches from parents we previously checked. This is so that patches with two parents @@ -1,4 +1,3 @@ @@ -1,4 +1,3 @@ one one -two -two three three -quatro -fyra +four +four can be coalesced into this sequence, reusing one line that describes the removal of "two" for both parents. @@@ -1,4 -1,4 +1,3 @@@ one --two three - quatro -frya ++four While reading the second patch (that removes "two" and then "fyra"), after finding where removal of the "two" matches, we need to find existing removal of "fyra" (if exists) in the removal list, but the match has to happen after all the existing matches (in this case "two"). The code used a naïve O(n^2) algorithm to compute this by scanning the whole removal list over and over again. This patch remembers where the next scan should be started in the existing removal list to avoid this. Noticed by Linus Torvalds. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-18checkout -f: deal with a D/F conflict entry correctlyLibravatar Junio C Hamano1-1/+1
When we switch branches with "checkout -f", unpack_trees() feeds two cache_entries to oneway_merge() function in its src[] array argument. The zeroth entry comes from the current index, and the first entry represents what the merge result should be, taken from the tree recorded in the commit we are switching to. When we have a blob (either regular file or a symlink) in the index and in the work tree at path "foo", and the switched-to tree has "foo/bar", i.e. "foo" becomes a directory, src[0] is obviously that blob currently registered at "foo". Even though we do not have anything at "foo" in the switched-to tree, src[1] is _not_ NULL in this case. The unpack_trees() machinery places a special marker df_conflict_entry to signal that no blob exists at "foo", but it will become a directory that may have somthing underneath it (namely "foo/bar"), so a usual 3-way merge can notice the situation. But oneway_merge() codepath failed to notice this and passed the special marker directly to merged_entry(). This happens to remove the "foo" in the end because the df_conflict_entry does not have any name (hence the "error" message) and its addition in add_index_entry() is rejected, but it is wrong. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-07-16sha1_name.c: avoid unnecessary strbuf_releaseLibravatar Brandon Casey1-2/+0
When we fall back to a standard for_each_reflog_ent() after failing to find the nth branch switch (or if we had a short reflog) with the call to for_each_recent_reflog_ent(), we do not need to free the memory allocated for our strbuf's since a strbuf_reset() will be performed in grab_nth_branch_switch() before assigning to the entry. Plus, the strbuf_release() negates the non-zero hint we initially gave to strbuf_init() just above these lines. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-16refs.c: release file descriptor on error returnLibravatar Brandon Casey1-1/+3
Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-08Merge branch 'cb/maint-fetch-refspec-wo-dst' into maintLibravatar Junio C Hamano1-1/+1
* cb/maint-fetch-refspec-wo-dst: fetch: do not create ref from empty name
2009-07-08Merge branch 'cf/maint-remote-uploadpack-useconfig-fix' into maintLibravatar Junio C Hamano1-1/+1
* cf/maint-remote-uploadpack-useconfig-fix: git-remote: fix missing .uploadpack usage for show command
2009-07-08Documentation: update description of shell aliasesLibravatar Sitaram Chamarty1-1/+3
Aliases that invoke shell commands start from the top-level directory, but this was not documented. Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-01request-pull: really really disable pagerLibravatar Michal Marek1-3/+4
Earlier 476cc72 (request-pull: really disable pager, 2009-06-30) tried to use the correct environment variable to disable paging from multiple calls to "git log" and friends, but there was one extra call to "git log" that was not covered by the trick. Move the setting and exporting of GIT_PAGER much earlier in the script to cover everybody. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-30attr: plug minor memory leakLibravatar René Scharfe1-0/+2
Free the memory allocated for struct strbuf pathbuf when we're done. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-30request-pull: really disable pagerLibravatar Junio C Hamano1-2/+2
ff06c74 (Improve request-pull to handle non-rebased branches, 2007-05-01) attempted to disable pager when running subcommands in this script, but with a wrong variable. If GIT_PAGER is set, it takes precedence over PAGER. Noticed by Michal Marek. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-30Makes some cleanup/review in gittutorialLibravatar Thadeu Lima de Souza Cascardo1-12/+12
There are some different but little cleanup changes to fix some missing quotes, to fix what seemed to be an unended sentence, to reident a little paragraph with too large a sentence and fix a branch name that was referred to twice later by another name. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>