Permalink
Commits on Apr 4, 2007
  1. GIT 1.5.1

    Junio C Hamano committed Apr 4, 2007
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. Merge 1.5.0.7 in

    Junio C Hamano committed Apr 4, 2007
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  3. GIT 1.5.0.7

    Junio C Hamano committed Apr 3, 2007
    Not that this release really matters, as we will be doing
    1.5.1 tomorrow.  This commit is to tie the loose ends and
    merge all of "maint" branch into "master" in preparation.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  4. Documentation: A few minor fixes to Git User's Manual

    jnareb committed with Junio C Hamano Apr 3, 2007
    Mainly consistent usage of "git command" and not "git-command" syntax
    
    Signed-off-by: Jakub Narebski <jnareb@gmail.com>
    Acked-by: J. Bruce Fields <bfields@citi.umich.edu>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  5. Plug memory leak in index-pack collision checking codepath.

    Nicolas Pitre committed with Junio C Hamano Apr 3, 2007
  6. rerere should not repeat the earlier hunks in later ones

    Junio C Hamano committed Apr 3, 2007
    When a file has more then one conflicting hunks, it repeated the
    contents of previous hunks in output for later ones.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Apr 2, 2007
  1. Hopefully final update to the draft Release Notes, preparing for 1.5.1

    Junio C Hamano committed Apr 2, 2007
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Mar 31, 2007
  1. cvsserver: Don't lie about binary mode in asciidoc documentation

    flichtenheld committed with Junio C Hamano Mar 31, 2007
    The git-cvsserver documentation claims that the server will set
    -k modes if appropriate which is not really the case. On the other
    hand the available gitcvs.allbinary variable is not documented at
    all. Fix both these issues by rewording the related paragraph.
    
    Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. git-svn: fail on rebase if we are unable to find a ref to rebase against

    Eric Wong committed with Junio C Hamano Mar 31, 2007
    If we're on an invalid HEAD, we should detect this and avoid
    attempting to continue.
    
    Signed-off-by: Eric Wong <normalperson@yhbt.net>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  3. Keep rename/rename conflicts of intermediate merges while doing recur…

    raalkml committed with Junio C Hamano Mar 31, 2007
    …sive merge
    
    This patch leaves the base name in the resulting intermediate tree, to
    propagate the conflict from intermediate merges up to the top-level merge.
    
    Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  4. contrib/workdir: add a simple script to create a working directory

    qur committed with Junio C Hamano Mar 26, 2007
    Add a simple script to create a working directory that uses symlinks
    to point at an exisiting repository.  This allows having different
    branches in different working directories but all from the same
    repository.
    
    Based on a description from Junio of how he creates multiple working
    directories[1].  With the following caveat:
    
    "This risks confusion for an uninitiated if you update a ref that
    is checked out in another working tree, but modulo that caveat
    it works reasonably well."
    
    [1] http://article.gmane.org/gmane.comp.version-control.git/41513/
    
    Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  5. Reimplement emailing part of hooks--update in contrib/hooks/post-rece…

    andyparkins committed with Junio C Hamano Mar 30, 2007
    …ive-email
    
    The update hook is no longer the correct place to generate emails; there
    is now the hooks/post-receive script which is run automatically after a
    ref has been updated.
    
    This patch is to make use of that new location, and to address some
    faults in the old update hook.
    
    The primary problem in the conversion was that in the update hook, the
    ref has not actually been changed, but is about to be.  In the
    post-receive hook the ref has already been updated.  That meant that
    where we previously had lines like:
    
     git rev-list --not --all
    
    would now give the wrong list because "--all" in the post-receive hook
    includes the ref that we are making the email for.  This made it more
    difficult to show only the new revisions added by this update.
    
    The solution is not pretty; however it does work and doesn't need any
    changes to git-rev-list itself.  It also fixes (more accurately: reduces
    the likelihood of) a nasty race when another update occurs while this
    script is running.  The solution, in short, looks like this (see the
    source code for a longer explanation)
    
     git rev-parse --not --all | grep -v $(git rev-parse $refname) |
     git rev-list --pretty --stdin $oldrev..$newrev
    
    This uses git-rev-parse followed by grep to filter out the revision of
    the ref in question before it gets to rev-list and inhibits the output
    of itself.  By using $(git rev-parse $revname) rather than $newrev as the
    filter, it also takes care of the situation where another update to the
    same ref has been made since $refname was $newrev.
    
    The second problem that is addressed is that of tags inhibiting the
    correct output of an update email.  Consider this, with somebranch and
    sometag pointing at the same revision:
    
     git push origin somebranch
     git push origin sometag
    
    That would work fine; the push of the branch would generate an email
    containing all the new commits introduced by the update, then the push
    of the tag would generate the shortlog formatted tag email.  Now
    consider:
    
     git push origin sometag
     git push origin somebranch
    
    When some branch comes to run its "--not --all" line, it will find
    sometag, and filter those commits from the email - leaving nothing.
    That meant that those commits would not show (in full) on any email.
    The fix is to not use "--all", and instead use "--branches" in the
    git-rev-parse command.
    
    Other changes
     * Lose the monstrous one-giant-script layout and put things in easy to
       digest functions.  This makes it much easier to find the place you
       need to change if you wanted to customise the output.  I've also
       tried to write more verbose comments for the same reason.  The hook
       script is big, mainly because of all the different cases that it has
       to handle, so being easy to navigate is important.
     * All uses of "git-command" changed to "git command", to cope better
       if a user decided not to install all the hard links to git;
     * Cleaned up some of the English in the email
     * The fact that the receive hook makes the ref available also allows me
       to use Shawn Pearce's fantastic suggestion that an annotated tag can
       be parsed with git-for-each-ref.  This removes the potentially
       non-portable use of "<<<" heredocs and the nasty messing around with
       "date" to convert numbers of seconds UTC to a real date
     * Deletions are now caught and notified (briefly)
     * To help with debugging, I've retained the command line mode from the
       update hook; but made it so that the output is not emailed, it's just
       printed to the screen.  This could then be redirected if the user
       wanted
     * Removed the "Hello" from the beginning of the email - it's just
       noise, and no one seriously has their day made happier by "friendly"
       programs
     * The fact that it doesn't rely on repository state as an indicator any
       more means that it's far more stable in its output; hopefully the
       same arguments will always generate the same email - even if the
       repository changes in the future.  This means you can easily recreate
       an email should you want to.
     * Included Jim Meyering's envelope sender option for the sendmail call
     * The hook is now so big that it was inappropriate to copy it
       to every repository by keeping it in the templates directory.
       Instead, I've put a comment saying to look in contrib/hooks, and
       given an example of calling the script from that template hook.  The
       advantage of calling the script residing at some fixed location is
       that if a future package of git included a bug fixed version of the
       script, that would be picked up automatically, and the user would not
       have to notice and manually copy the new hook to every repository
       that uses it.
    
    Signed-off-by: Andy Parkins <andyparkins@gmail.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  6. git-svn: avoid respewing similar error messages for missing paths

    Eric Wong committed with Junio C Hamano Mar 31, 2007
    We ignore errors if the path we're tracking did not exist for
    a particular revision range, but we still print out warnings
    telling the user about that.
    
    As pointed out by Seth Falcon, this amounts to a lot of warnings
    that could confuse and worry users.  I'm not entirely comfortable
    completely silencing the warnings, but showing one warning per
    path that we track should be reasonable.
    
    Signed-off-by: Eric Wong <normalperson@yhbt.net>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  7. Rename warn() to warning() to fix symbol conflicts on BSD and Mac OS

    tytso committed with Junio C Hamano Mar 30, 2007
    This fixes a problem reported by Randal Schwartz:
    
    >I finally tracked down all the (albeit inconsequential) errors I was getting
    >on both OpenBSD and OSX.  It's the warn() function in usage.c.  There's
    >warn(3) in BSD-style distros.  It'd take a "great rename" to change it, but if
    >someone with better C skills than I have could do that, my linker and I would
    >appreciate it.
    
    It was annoying to me, too, when I was doing some mergetool testing on
    Mac OS X, so here's a fix.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Cc: "Randal L. Schwartz" <merlyn@stonehenge.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  8. git-mailinfo fixes for patch munging

    dzickusrh committed with Junio C Hamano Mar 30, 2007
    Don't translate the patch to UTF-8, instead preserve the data as
    is.  This also reverts a test case that was included in the
    original patch series.
    
    Also allow overwriting the authorship and title information we
    gather from RFC2822 mail headers with additional in-body
    headers, which was pointed out by Linus.
    
    Signed-off-by: Don Zickus <dzickus@redhat.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  9. gitweb: Support comparing blobs (files) with different names

    jnareb committed with Junio C Hamano Mar 30, 2007
    Fix the bug that caused "blobdiff" view called with new style URI
    for a rename with change diff to be show as new (added) file diff.
    
    New style URI for "blobdiff" for rename means with $hash_base ('hb') and
    $hash_parent_base ('hpb') paramaters denoting tree-ish (usually commit)
    of a blobs being compared, together with both $file_name ('f') and
    $file_parent ('fp') parameters.
    
    It is done by adding $file_parent ('fp') to the path limiter, meaning
    that diff command becomes:
    
    	git diff-tree [options] hpb hb -- fp f
    
    Other option would be finding hash of a blob using git_get_hash_by_path
    subroutine and comparing blobs using git-diff, or using extended SHA-1
    syntax and compare blobs using git-diff:
    
    	git diff [options] hpb:fp hp:f
    
    Signed-off-by: Jakub Narebski <jnareb@gmail.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Mar 30, 2007
  1. Do not bother documenting fetch--tool

    Junio C Hamano committed Mar 30, 2007
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. Update draft release notes for 1.5.1

    Junio C Hamano committed Mar 30, 2007
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  3. Merge branch 'maint'

    Junio C Hamano committed Mar 30, 2007
    * maint:
      git-upload-pack: make sure we close unused pipe ends
      Documentation/git-rev-parse.txt: fix example in SPECIFYING RANGES.
      Documentation/git-svnimport.txt: fix typo.
  4. git-quiltimport /bin/sh-ism fix

    Francis Daly committed with Junio C Hamano Mar 29, 2007
    Bryan Wu reported
    /usr/local/bin/git-quiltimport: 114: Syntax error: Missing '))'
    
    Most bourne-ish shells I have here accept
     x=$((echo x)|cat)
    but all bourne-ish shells I have here accept
     x=$( (echo x)|cat)
    because $(( might mean arithmetic expansion.
    
    Signed-off-by: Francis Daly <francis@daoine.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  5. Bisect: Improve error message in "bisect_next_check".

    chriscool committed with Junio C Hamano Mar 29, 2007
    So we can remove the specific message in "bisect_run".
    
    Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  6. Merge branch 'master' of git://repo.or.cz/git/mergetool.git

    Junio C Hamano committed Mar 30, 2007
    * 'master' of git://repo.or.cz/git/mergetool.git:
      mergetool: Clean up description of files and prompts for merge resolutions
      mergetool: Make git-rm quiet when resolving a deleted file conflict
      mergetool: Add support for Apple Mac OS X's opendiff command
      mergetool: Fix abort command when resolving symlinks and deleted files
      mergetool: Remove spurious error message if merge.tool config option not set
      mergetool: factor out common code
      mergetool: portability fix: don't use reserved word function
      mergetool: portability fix: don't assume true is in /bin
      mergetool: Don't error out in the merge case where the local file is deleted
      mergetool: Replace use of "echo -n" with printf(1) to be more portable
      Fix minor formatting issue in man page for git-mergetool
  7. mergetool: Clean up description of files and prompts for merge resolu…

    tytso committed Mar 29, 2007
    …tions
    
    This fixes complaints from Junio for how messages and prompts are
    printed when resolving symlink and deleted file merges.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Commits on Mar 29, 2007
  1. mergetool: Make git-rm quiet when resolving a deleted file conflict

    tytso committed Mar 29, 2007
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
  2. mergetool: Add support for Apple Mac OS X's opendiff command

    tytso committed Mar 29, 2007
    Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
  3. mergetool: Fix abort command when resolving symlinks and deleted files

    tytso committed Mar 29, 2007
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
  4. mergetool: Remove spurious error message if merge.tool config option …

    tytso committed Mar 29, 2007
    …not set
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
  5. mergetool: factor out common code

    tytso committed Mar 29, 2007
    Create common function check_unchanged(), save_backup() and
    remove_backup().
    
    Also fix some minor whitespace issues while we're at it.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
  6. mergetool: portability fix: don't use reserved word function

    tytso committed Mar 29, 2007
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
  7. mergetool: portability fix: don't assume true is in /bin

    tytso committed Mar 29, 2007
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
  8. mergetool: Don't error out in the merge case where the local file is …

    tytso committed Mar 27, 2007
    …deleted
    
    If the file we are trying to merge resolve is in git-ls-files -u, then
    skip the file existence test.  If the file isn't reported in
    git-ls-files, then check to see if the file exists or not to give an
    appropriate error message.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
  9. mergetool: Replace use of "echo -n" with printf(1) to be more portable

    tytso committed Mar 27, 2007
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
  10. Fix minor formatting issue in man page for git-mergetool

    tytso committed Mar 27, 2007
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
  11. git-upload-pack: make sure we close unused pipe ends

    H. Peter Anvin committed with Junio C Hamano Mar 27, 2007
    Right now, we don't close the read end of the pipe when git-upload-pack
    runs git-pack-object, so we hang forever (why don't we get SIGALRM?)
    instead of dying with SIGPIPE if the latter dies, which seems to be the
    norm if the client disconnects.
    
    Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for
    pointing out where this close() needed to go.
    
    This patch has been tested on kernel.org for several weeks and appear
    to resolve the problem of git-upload-pack processes hanging around
    forever.
    
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    (cherry picked from commit 465b351)
  12. Documentation/git-rev-parse.txt: fix example in SPECIFYING RANGES.

    Gerrit Pape committed with Junio C Hamano Mar 29, 2007
    Please see http://bugs.debian.org/404795:
    
     In git-rev-parse(1), there is an example commit tree, which is used twice.
     The explanation for this tree is very clear: B and C are commit *parents* to
     A.
    
     However, when the tree is reused as an example in the SPECIFYING RANGES, the
     manpage author screws up and uses A as a commit *parent* to B and C!  I.e.,
     he inverts the tree.
    
     And the fact that for this example you need to read the tree backwards is
     not explained anywhere (and it would be confusing even if it was).
    
    Signed-off-by: Gerrit Pape <pape@smarden.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>