- 03 11月, 2007 2 次提交
-
-
由 Sergei Organov 提交于
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: NSergei Organov <osv@javad.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jonas Fonseca 提交于
The escaped were ending up verbatim in the generated documentation. Signed-off-by: NJonas Fonseca <fonseca@diku.dk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 11月, 2007 4 次提交
-
-
由 Sergei Organov 提交于
Signed-off-by: NSergei Organov <osv@javad.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Sergei Organov 提交于
Signed-off-by: NSergei Organov <osv@javad.com> Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Ralf Wildenhues 提交于
Avoid abbreviation 'revs', improve the language a bit. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jakub Narebski 提交于
Commit a3c8ab30 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: NJakub Narebski <jnareb@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 11月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 31 10月, 2007 10 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Björn Steinbrink 提交于
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: NBjörn Steinbrink <B.Steinbrink@gmx.de> Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Björn Steinbrink 提交于
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: NBjörn Steinbrink <B.Steinbrink@gmx.de> Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Björn Steinbrink 提交于
For the --strategy/-s option, git-rebase--interactive.sh dropped the parameter which it was trying to parse. Signed-off-by: NBjörn Steinbrink <B.Steinbrink@gmx.de> Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Lars Hjemli 提交于
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: NLars Hjemli <hjemli@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Nicolas Pitre 提交于
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: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Sergei Organov 提交于
"git-merge <msg> HEAD <other branches>" is still supported but we shouldn't encourage its use. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
4491e62a (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: NJunio C Hamano <gitster@pobox.com>
-
由 Michael W. Olson 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 10月, 2007 4 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
由 Benoit Sigoure 提交于
prune_directory and fill_directory allocated one byte per pathspec and never freed it. Signed-off-by: NBenoit Sigoure <tsuna@lrde.epita.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 10月, 2007 1 次提交
-
-
由 Aurelien Bompard 提交于
Signed-off-by: NAurélien Bompard <aurelien@bompard.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 10月, 2007 1 次提交
-
-
由 Alex Riesen 提交于
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: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 10月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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: NMartin F Krafft <madduck@madduck.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 10月, 2007 8 次提交
-
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Linus Torvalds 提交于
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: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Linus Torvalds 提交于
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: NShawn O. Pearce <spearce@spearce.org>
-
git://repo.or.cz/git-gui由 Shawn O. Pearce 提交于
* '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
-
由 Joakim Tjernlund 提交于
receive-pack is only executed remotely so when reporting errors, say so. Signed-off-by: NJoakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Julian Phillips 提交于
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: NJulian Phillips <julian@quantumfyre.co.uk> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org>
-
- 20 10月, 2007 3 次提交
-
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org>
-
由 Ralf Wildenhues 提交于
For the manpage, avoid generating an em dash in code. Signed-off-by: NRalf Wildenhues <Ralf.Wildenhues@gmx.de> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 19 10月, 2007 5 次提交
-
-
由 Shawn O. Pearce 提交于
In 89d750bf 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: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Shawn O. Pearce 提交于
git-stash needs to restrict itself to plumbing when running automated diffs as part of its operation as the user may have configured a custom diff driver that opens an interactive UI for certain/all files. Doing that during scripted actions is very unfriendly to the end-user and may cause git-stash to fail to work. Reported by Johannes Sixt Acked-by: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Steffen Prohaska 提交于
git may segfault if gitattributes contains an invalid entry. A test is added to t0020 that triggers the segfault. The parsing code is fixed to avoid the crash. Signed-off-by: NSteffen Prohaska <prohaska@zib.de> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
由 Patrick Welche 提交于
I found I needed NI_MAXSERV as it is defined in netdb.h, which is not included by daemon.c. Rather than including the whole header we can define a reasonable fallback value. Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-