summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2007-11-05grep with unmerged indexLibravatar Junio C Hamano1-1/+1
We called flush_grep() every time we saw an unmerged entry in the index. If we happen to find an unmerged entry before we saw more than two paths, we incorrectly declared that the user had too many non-paths options in front. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05Merge branch 'gp/maint-diffdoc' into maintLibravatar Junio C Hamano2-9/+13
* gp/maint-diffdoc: git-diff.txt: add section "output format" describing the diff formats
2007-11-05git-daemon: fix remote port number in log entryLibravatar Gerrit Pape1-2/+2
The port number in struct sockaddr_in needs to be converted from network byte order to host byte order (on some architectures). Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05git-svn: t9114: verify merge commit message in testLibravatar Eric Wong1-0/+5
It's possible that we end up with an incorrect commit message in this test after making changes to fix the clobber bug in dcommit. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05git-svn: fix dcommit clobbering when committing a series of diffsLibravatar Eric Wong2-4/+100
Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-03RelNotes-1.5.3.5: fix typoLibravatar David D Kilzer1-2/+2
Signed-off-by: David D Kilzer <ddkilzer@kilzer.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-03Delay pager setup in git blameLibravatar Mike Hommey1-3/+3
This avoids to launch the pager when git blame fails for any reason. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-03git-cvsimport: really convert underscores in branch names to dots with -uLibravatar Gerrit Pape1-0/+1
The documentation states for the -u option that underscores in tag and branch names are converted to dots, but this was actually implemented for the tag names only. Kurt Roeckx reported this through http://bugs.debian.org/446495 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02Fixing path quoting in git-rebaseLibravatar Jonathan del Strother1-13/+13
git-rebase used to fail when run from a path containing a space. Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-11-02Merge branch 'bk/maint-cvsexportcommit' into maintLibravatar Junio C Hamano1-3/+10
* bk/maint-cvsexportcommit: cvsexportcommit: fix for commits that do not have parents
2007-11-02Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test suites.Libravatar Kristian Høgsberg2-6/+6
They are already set and exoprted by sourcing ./test-lib.sh in all test scripts. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02Documentation: quote commit messages consistently.Libravatar Sergei Organov3-7/+7
Documentation quotes commit messages 14 times with double-quotes, and 7 times with single-quotes. The patch turns everything to double-quotes. A nice side effect is that documentation becomes more Windoze-friendly as AFAIK single quotes won't work there. Signed-off-by: Sergei Organov <osv@javad.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02Remove escaping of '|' in manpage option sectionsLibravatar Jonas Fonseca2-2/+2
The escaped were ending up verbatim in the generated documentation. Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-01git-diff.txt: add section "output format" describing the diff formatsLibravatar Gerrit Pape2-9/+13
git-diff.txt includes diff-options.txt which for the -p option refers to a section "generating patches.." which is missing from the git-diff documentation. This patch adapts diff-format.txt to additionally mention the git-diff program, and includes diff-format.txt into git-diff.txt. Tino Keitel noticed this problem. Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-01git-format-patch.txt: fix explanation of an example.Libravatar Sergei Organov1-1/+1
Signed-off-by: Sergei Organov <osv@javad.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-01git-filter-branch.txt: fix a typo.Libravatar Sergei Organov1-1/+1
Signed-off-by: Sergei Organov <osv@javad.com> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-01git-clone.txt: Improve --depth description.Libravatar Ralf Wildenhues1-3/+3
Avoid abbreviation 'revs', improve the language a bit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-01gitweb: Update config file example for snapshot feature in gitweb/INSTALLLibravatar Jakub Narebski1-1/+1
Commit a3c8ab30a54c30a6a434760bedf04548425416ef by Matt McCutchen "gitweb: snapshot cleanups & support for offering multiple formats" introduced new format of $feature{'snapshot'}{'default'} value. Update "Config file example" in gitweb/INSTALL accordingly. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-31cvsexportcommit: fix for commits that do not have parentsLibravatar Brad King1-3/+10
Previously commits without parents would fail to export with a message indicating that the commits had more than one parent. Instead we should use the --root option for git-diff-tree in place of a parent. Signed-off-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-31GIT 1.5.3.5Libravatar Junio C Hamano2-7/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-30Update GIT 1.5.3.5 Release NotesLibravatar Junio C Hamano1-1/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-30git-rebase--interactive.sh: Make 3-way merge strategies work for -p.Libravatar Björn Steinbrink1-0/+2
git-rebase--interactive.sh used to pass all parents of a merge commit to git-merge, which means that we have at least 3 heads to merge: HEAD, first parent and second parent. So 3-way merge strategies like recursive wouldn't work. Fortunately, we have checked out the first parent right before the merge anyway, so that is HEAD. Therefore we can drop simply it from the list of parents, making 3-way strategies work for merge commits with only two parents. Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-30git-rebase--interactive.sh: Don't pass a strategy to git-cherry-pick.Libravatar Björn Steinbrink1-2/+2
git-cherry-pick doesn't support a strategy paramter, so don't pass one. This means that --strategy for interactive rebases is a no-op for anything but merge commits, but that's still better than being broken. A correct fix would probably need to port the --merge behaviour from plain git-rebase.sh, but I have no clue how to integrate that cleanly. Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-30Fix --strategy parsing in git-rebase--interactive.shLibravatar Björn Steinbrink1-1/+0
For the --strategy/-s option, git-rebase--interactive.sh dropped the parameter which it was trying to parse. Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-30Make merge-recursive honor diff.renamelimitLibravatar Lars Hjemli1-0/+6
It might be a sign of source code management gone bad, but when two branches has diverged almost beyond recognition and time has come for the branches to merge, the user is going to need all the help his tool can give him. Honoring diff.renamelimit has great potential as a painkiller in such situations. The painkiller effect could have been achieved by e.g. 'merge.renamelimit', but the flexibility gained by a separate option is questionable: our user would probably expect git to detect renames equally good when merging as when diffing (I known I did). Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-30cherry-pick/revert: more compact user direction messageLibravatar Nicolas Pitre1-1/+1
A failed cherry-pick (and friend) currently says: |Automatic cherry-pick failed. After resolving the conflicts, |mark the corrected paths with 'git-add <paths>' |and commit the result. This can obviously be displayed on two lines only. While at it, change "git-add" to "git add". Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-30core-tutorial: Use new syntax for git-merge.Libravatar Sergei Organov1-4/+4
"git-merge <msg> HEAD <other branches>" is still supported but we shouldn't encourage its use. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-30git-merge: document but discourage the historical syntaxLibravatar Junio C Hamano1-5/+6
Historically "git merge" took its command line arguments in a rather strange order. Document the historical syntax, and also document clearly that it is not encouraged in new scripts. There is no reason to deprecate the historical syntax, as the current code can sanely tell which syntax the caller is using, and existing scripts by people do use the historical syntax. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-30Prevent send-pack from segfaulting (backport from 'master')Libravatar Junio C Hamano1-1/+4
4491e62ae932d5774f628d1bd3be663c11058a73 (Prevent send-pack from segfaulting when a branch doesn't match) is hereby cherry-picked back to 'maint'. If we can't find a source match, and we have no destination, we need to abort the match function early before we try to match the destination against the remote. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-30Documentation/git-cvsexportcommit.txt: s/mgs/msg/ in exampleLibravatar Michael W. Olson1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-29RelNotes-1.5.3.5: describe recent fixesLibravatar Junio C Hamano1-0/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-29merge-recursive.c: mrtree in merge() is not used before setLibravatar Junio C Hamano1-1/+1
The called function merge_trees() sets its *result, to which the address of the variable mrtree in merge() function is passed, only when index_only is set. But that is Ok as the function uses the value in the variable only under index_only iteration. However, recent gcc does not realize this. Work it around by adding a fake initializer. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-29sha1_file.c: avoid gcc signed overflow warningsLibravatar Junio C Hamano1-7/+9
With the recent gcc, we get: sha1_file.c: In check_packed_git_: sha1_file.c:527: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false sha1_file.c:527: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false for a piece of code that tries to make sure that off_t is large enough to hold more than 2^32 offset. The test tried to make sure these do not wrap-around: /* make sure we can deal with large pack offsets */ off_t x = 0x7fffffffUL, y = 0xffffffffUL; if (x > (x + 1) || y > (y + 1)) { but gcc assumes it can do whatever optimization it wants for a signed overflow (undefined behaviour) and warns about this construct. Follow Linus's suggestion to check sizeof(off_t) instead to work around the problem. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-29Fix a small memory leak in builtin-addLibravatar Benoit Sigoure1-0/+2
prune_directory and fill_directory allocated one byte per pathspec and never freed it. Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-28honor the http.sslVerify option in shell scriptsLibravatar Aurelien Bompard2-4/+6
Signed-off-by: Aurélien Bompard <aurelien@bompard.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-26Fix generation of perl/perl.makLibravatar Alex Riesen1-5/+1
The code generating perl/Makefile from Makefile.PL was causing trouble because it didn't considered NO_PERL_MAKEMAKER and ran makemaker unconditionally, rewriting perl.mak. Makemaker is FUBAR in ActiveState Perl, and perl/Makefile has a replacement for it. Besides, a changed Git.pm is *NOT* a reason to rebuild all the perl scripts, so remove the dependency too. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-24git-remote: fix "Use of uninitialized value in string ne"Libravatar Junio C Hamano1-1/+2
martin f krafft <madduck@madduck.net> writes: > piper:~> git remote show origin > * remote origin > URL: ssh://git.madduck.net/~/git/etc/mailplate.git > Use of uninitialized value in string ne at /usr/local/stow/git/bin/git-remote line 248. This is because there might not be branch.<name>.remote defined but the code unconditionally dereferences $branch->{$name}{'REMOTE'} and compares with another string. Tested-by: Martin F Krafft <madduck@madduck.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-21Describe more 1.5.3.5 fixes in release notesLibravatar Shawn O. Pearce1-0/+15
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-21Fix diffcore-break total breakageLibravatar Linus Torvalds2-4/+8
Ok, so on the kernel list, some people noticed that "git log --follow" doesn't work too well with some files in the x86 merge, because a lot of files got renamed in very special ways. In particular, there was a pattern of doing single commits with renames that looked basically like - rename "filename.h" -> "filename_64.h" - create new "filename.c" that includes "filename_32.h" or "filename_64.h" depending on whether we're 32-bit or 64-bit. which was preparatory for smushing the two trees together. Now, there's two issues here: - "filename.c" *remained*. Yes, it was a rename, but there was a new file created with the old name in the same commit. This was important, because we wanted each commit to compile properly, so that it was bisectable, so splitting the rename into one commit and the "create helper file" into another was *not* an option. So we need to break associations where the contents change too much. Fine. We have the -B flag for that. When we break things up, then the rename detection will be able to figure out whether there are better alternatives. - "git log --follow" didn't with with -B. Now, the second case was really simple: we use a different "diffopt" structure for the rename detection than the basic one (which we use for showing the diffs). So that second case is trivially fixed by a trivial one-liner that just copies the break_opt values from the "real" diffopts to the one used for rename following. So now "git log -B --follow" works fine: diff --git a/tree-diff.c b/tree-diff.c index 26bdbdd..7c261fd 100644 --- a/tree-diff.c +++ b/tree-diff.c @@ -319,6 +319,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co diff_opts.detect_rename = DIFF_DETECT_RENAME; diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT; diff_opts.single_follow = opt->paths[0]; + diff_opts.break_opt = opt->break_opt; paths[0] = NULL; diff_tree_setup_paths(paths, &diff_opts); if (diff_setup_done(&diff_opts) < 0) however, the end result does *not* work. Because our diffcore-break.c logic is totally bogus! In particular: - it used to do if (base_size < MINIMUM_BREAK_SIZE) return 0; /* we do not break too small filepair */ which basically says "don't bother to break small files". But that "base_size" is the *smaller* of the two sizes, which means that if some large file was rewritten into one that just includes another file, we would look at the (small) result, and decide that it's smaller than the break size, so it cannot be worth it to break it up! Even if the other side was ten times bigger and looked *nothing* like the samell file! That's clearly bogus. I replaced "base_size" with "max_size", so that we compare the *bigger* of the filepair with the break size. - It calculated a "merge_score", which was the score needed to merge it back together if nothing else wanted it. But even if it was *so* different that we would never want to merge it back, we wouldn't consider it a break! That makes no sense. So I added if (*merge_score_p > break_score) return 1; to make it clear that if we wouldn't want to merge it at the end, it was *definitely* a break. - It compared the whole "extent of damage", counting all inserts and deletes, but it based this score on the "base_size", and generated the damage score with delta_size = src_removed + literal_added; damage_score = delta_size * MAX_SCORE / base_size; but that makes no sense either, since quite often, this will result in a number that is *bigger* than MAX_SCORE! Why? Because base_size is (again) the smaller of the two files we compare, and when you start out from a small file and add a lot (or start out from a large file and remove a lot), the base_size is going to be much smaller than the damage! Again, the fix was to replace "base_size" with "max_size", at which point the damage actually becomes a sane percentage of the whole. With these changes in place, not only does "git log -B --follow" work for the case that triggered this in the first place, ie now git log -B --follow arch/x86/kernel/vmlinux_64.lds.S actually gives reasonable results. But I also wanted to verify it in general, by doing a full-history git log --stat -B -C on my kernel tree with the old code and the new code. There's some tweaking to be done, but generally, the new code generates much better results wrt breaking up files (and then finding better rename candidates). Here's a few examples of the "--stat" output: - This: include/asm-x86/Kbuild | 2 - include/asm-x86/debugreg.h | 79 +++++++++++++++++++++++++++++++++++------ include/asm-x86/debugreg_32.h | 64 --------------------------------- include/asm-x86/debugreg_64.h | 65 --------------------------------- 4 files changed, 68 insertions(+), 142 deletions(-) Becomes: include/asm-x86/Kbuild | 2 - include/asm-x86/{debugreg_64.h => debugreg.h} | 9 +++- include/asm-x86/debugreg_32.h | 64 ------------------------- 3 files changed, 7 insertions(+), 68 deletions(-) - This: include/asm-x86/bug.h | 41 +++++++++++++++++++++++++++++++++++++++-- include/asm-x86/bug_32.h | 37 ------------------------------------- include/asm-x86/bug_64.h | 34 ---------------------------------- 3 files changed, 39 insertions(+), 73 deletions(-) Becomes include/asm-x86/{bug_64.h => bug.h} | 20 +++++++++++++----- include/asm-x86/bug_32.h | 37 ----------------------------------- 2 files changed, 14 insertions(+), 43 deletions(-) Now, in some other cases, it does actually turn a rename into a real "delete+create" pair, and then the diff is usually bigger, so truth in advertizing: it doesn't always generate a nicer diff. But for what -B was meant for, I think this is a big improvement, and I suspect those cases where it generates a bigger diff are tweakable. So I think this diff fixes a real bug, but we might still want to tweak the default values and perhaps the exact rules for when a break happens. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-21Fix directory scanner to correctly ignore files without d_typeLibravatar Linus Torvalds1-14/+38
On Fri, 19 Oct 2007, Todd T. Fries wrote: > If DT_UNKNOWN exists, then we have to do a stat() of some form to > find out the right type. That happened in the case of a pathname that was ignored, and we did not ask for "dir->show_ignored". That test used to be *together* with the "DTYPE(de) != DT_DIR", but splitting the two tests up means that we can do that (common) test before we even bother to calculate the real dtype. Of course, that optimization only matters for systems that don't have, or don't fill in DTYPE properly. I also clarified the real relationship between "exclude" and "dir->show_ignored". It used to do if (exclude != dir->show_ignored) { .. which wasn't exactly obvious, because it triggers for two different cases: - the path is marked excluded, but we are not interested in ignored files: ignore it - the path is *not* excluded, but we *are* interested in ignored files: ignore it unless it's a directory, in which case we might have ignored files inside the directory and need to recurse into it). so this splits them into those two cases, since the first case doesn't even care about the type. I also made a the DT_UNKNOWN case a separate helper function, and added some commentary to the cases. Linus Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-20Merge branch 'maint' of git://repo.or.cz/git-gui into maintLibravatar Shawn O. Pearce4-11/+73
* 'maint' of git://repo.or.cz/git-gui: git-gui: Don't display CR within console windows git-gui: Handle progress bars from newer gits git-gui: Correctly report failures from git-write-tree git-gui: accept versions containing text annotations, like 1.5.3.mingw.1 git-gui: Don't crash when starting gitk from a browser session git-gui: Allow gitk to be started on Cygwin with native Tcl/Tk git-gui: Ensure .git/info/exclude is honored in Cygwin workdirs git-gui: Handle starting on mapped shares under Cygwin git-gui: Display message box when we cannot find git in $PATH git-gui: Avoid using bold text in entire gui for some fonts
2007-10-20Improve receive-pack error message about funny ref creationLibravatar Joakim Tjernlund1-1/+1
receive-pack is only executed remotely so when reporting errors, say so. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-20fast-import: Fix argument order to die in file_change_mLibravatar Julian Phillips1-1/+1
The arguments to the "Not a blob" die call in file_change_m were transposed, so that the command was printed as the type, and the type as the command. Switch them around so that the error message comes out correctly. Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-20git-gui: Don't display CR within console windowsLibravatar Shawn O. Pearce1-1/+1
Git progress bars from tools like git-push and git-fetch use CR to skip back to the start of the current line and redraw it with an updated progress. We were doing this in our Tk widget but had failed to skip the CR, which Tk doesn't draw well. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-20git-gui: Handle progress bars from newer gitsLibravatar Shawn O. Pearce1-1/+4
Post Git 1.5.3 a new style progress bar has been introduced that uses only one line rather than two. The formatting of the completed and total section is also slightly different so we must adjust our regexp to match. Unfortunately both styles are in active use by different versions of Git so we need to look for both. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-20git-gui: Correctly report failures from git-write-treeLibravatar Shawn O. Pearce1-1/+1
If git-write-tree fails (such as if the index file is currently locked and it wants to write to it) we were not getting the error message as $tree_id was always the empty string so we shortcut through the catch and never got the output from stderr. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-19gitk.txt: Fix markup.Libravatar Ralf Wildenhues1-1/+1
For the manpage, avoid generating an em dash in code. Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-19send-pack: respect '+' on wildcard refspecsLibravatar Jeff King2-0/+50
When matching source and destination refs, we were failing to pull the 'force' parameter from wildcard refspecs (but not explicit ones) and attach it to the ref struct. This adds a test for explicit and wildcard refspecs; the latter fails without this patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-19Paper bag fix diff invocation in 'git stash show'Libravatar Shawn O. Pearce1-1/+1
In 89d750bf6fa025edeb31ad258cdd09a27a5c02fa I got a little too aggressive with changing "git diff" to "git diff-tree". This is shown to the user, who expects to see a full diff on their console, and will want to see the output of their custom diff drivers (if any) as the whole point of this call site is to show the diff to the end-user. Noticed by Johannes Sixt <j.sixt@viscovery.net>. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-19Further 1.5.3.5 fixes described in release notesLibravatar Shawn O. Pearce1-3/+13
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>