Permalink
Commits on Oct 31, 2007
  1. GIT 1.5.3.5

    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    gitster committed Oct 31, 2007
  2. Update GIT 1.5.3.5 Release Notes

    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    gitster committed Oct 31, 2007
  3. git-rebase--interactive.sh: Make 3-way merge strategies work for -p.

    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>
    dotdash committed with gitster Oct 31, 2007
  4. git-rebase--interactive.sh: Don't pass a strategy to git-cherry-pick.

    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>
    dotdash committed with gitster Oct 31, 2007
  5. Fix --strategy parsing in git-rebase--interactive.sh

    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>
    dotdash committed with gitster Oct 31, 2007
  6. Make merge-recursive honor diff.renamelimit

    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>
    hjemli committed with gitster Sep 25, 2007
Commits on Oct 30, 2007
  1. cherry-pick/revert: more compact user direction message

    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>
    Nicolas Pitre committed with gitster Oct 30, 2007
  2. core-tutorial: Use new syntax for git-merge.

    "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>
    Sergei Organov committed with gitster Oct 30, 2007
  3. git-merge: document but discourage the historical syntax

    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>
    gitster committed Oct 30, 2007
  4. Prevent send-pack from segfaulting (backport from 'master')

    4491e62 (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>
    gitster committed Oct 30, 2007
  5. Documentation/git-cvsexportcommit.txt: s/mgs/msg/ in example

    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    mwolson committed with gitster Oct 30, 2007
Commits on Oct 29, 2007
  1. RelNotes-1.5.3.5: describe recent fixes

    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    gitster committed Oct 29, 2007
  2. merge-recursive.c: mrtree in merge() is not used before set

    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>
    gitster committed Oct 29, 2007
  3. sha1_file.c: avoid gcc signed overflow warnings

    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>
    gitster committed Oct 29, 2007
  4. Fix a small memory leak in builtin-add

    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>
    tsuna committed with gitster Oct 29, 2007
Commits on Oct 28, 2007
  1. honor the http.sslVerify option in shell scripts

    Signed-off-by: Aurélien Bompard <aurelien@bompard.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    abompard committed with gitster Oct 28, 2007
Commits on Oct 26, 2007
  1. Fix generation of perl/perl.mak

    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>
    raalkml committed with gitster Oct 25, 2007
Commits on Oct 25, 2007
  1. git-remote: fix "Use of uninitialized value in string ne"

    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>
    gitster committed Oct 24, 2007
Commits on Oct 21, 2007
  1. Describe more 1.5.3.5 fixes in release notes

    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Oct 21, 2007
  2. Fix diffcore-break total breakage

    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>
    torvalds committed with spearce Oct 20, 2007
  3. Fix directory scanner to correctly ignore files without d_type

    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>
    torvalds committed with spearce Oct 19, 2007
  4. Merge branch 'maint' of git://repo.or.cz/git-gui into maint

    * '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
    spearce committed Oct 21, 2007
  5. Improve receive-pack error message about funny ref creation

    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>
    joakim-tjernlund committed with spearce Oct 20, 2007
  6. fast-import: Fix argument order to die in file_change_m

    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>
    qur committed with spearce Oct 20, 2007
  7. git-gui: Don't display CR within console windows

    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>
    spearce committed Oct 21, 2007
  8. git-gui: Handle progress bars from newer gits

    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>
    spearce committed Oct 20, 2007
Commits on Oct 20, 2007
  1. git-gui: Correctly report failures from git-write-tree

    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>
    spearce committed Oct 20, 2007
  2. gitk.txt: Fix markup.

    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>
    Ralf Wildenhues committed with spearce Oct 19, 2007
  3. send-pack: respect '+' on wildcard refspecs

    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>
    peff committed with spearce Oct 19, 2007
Commits on Oct 19, 2007
  1. Paper bag fix diff invocation in 'git stash show'

    In 89d750b 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>
    spearce committed Oct 19, 2007
  2. Further 1.5.3.5 fixes described in release notes

    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Oct 19, 2007
  3. Avoid invoking diff drivers during git-stash

    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: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    spearce committed Oct 19, 2007
  4. attr: fix segfault in gitattributes parsing code

    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: Steffen Prohaska <prohaska@zib.de>
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    sprohaska committed with spearce Oct 18, 2007
  5. Define NI_MAXSERV if not defined by operating system

    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: Shawn O. Pearce <spearce@spearce.org>
    Patrick Welche committed with spearce Oct 18, 2007
  6. Ensure we add directories in the correct order

    CVS gets understandably upset if you try and add a subdirectory
    before it's parent directory. This patch fixes that.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Alex Bennee committed with spearce Oct 18, 2007