Permalink
Commits on Jul 27, 2008
  1. GIT 1.6.0-rc1

    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    gitster committed Jul 27, 2008
  2. git-mv: Keep moved index entries inact

    The rewrite of git-mv from a shell script to a builtin was perhaps
    a little too straightforward: the git add and git rm queues were
    emulated directly, which resulted in a rather complicated code and
    caused an inconsistent behaviour when moving dirty index entries;
    git mv would update the entry based on working tree state,
    except in case of overwrites, where the new entry would still have
    sha1 of the old file.
    
    This patch introduces rename_index_entry_at() into the index toolkit,
    which will rename an entry while removing any entries the new entry
    might render duplicate. This is then used in git mv instead
    of all the file queues, resulting in a major simplification
    of the code and an inevitable change in git mv -n output format.
    
    Also the code used to refuse renaming overwriting symlink with a regular
    file and vice versa; there is no need for that.
    
    A few new tests have been added to the testsuite to reflect this change.
    
    Signed-off-by: Petr Baudis <pasky@suse.cz>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Petr Baudis committed with gitster Jul 21, 2008
  3. git-mv: Remove dead code branch

    The path list builder had a branch for the case the source is not in index, but
    this can happen only if the source was a directory. However, in that case we
    have already expanded the list to the directory contents and set mode
    to WORKING_DIRECTORY, which is tested earlier.
    
    The patch removes the superfluous branch and adds an assert() instead. git-mv
    testsuite still passes.
    
    Signed-off-by: Petr Baudis <pasky@suse.cz>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Petr Baudis committed with gitster Jul 16, 2008
  4. fsck: Don't require tmp_obj_ file names are 14 bytes in length

    Not all temporary file creation routines will ensure 14 bytes are
    used to generate the temporary file name.  In C Git this may be
    true, but alternate implementations such as jgit are not always
    able to generate a temporary file name with a specific prefix and
    also ensure the file name length is 14 bytes long.
    
    Since temporary files in a directory we are fsck'ing should be
    uncommon (as they are short lived only long enough for an active
    writer to finish writing the file and rename it) we shouldn't see
    these show up very often.  Always using a prefixcmp() call and
    ignoring the length opens up room for other implementations to use
    different name generation schemes.
    
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    spearce committed with gitster Jul 27, 2008
  5. Avoid chdir() in list_commands_in_dir()

    The function list_commands_in_dir() tried to be lazy and just chdir()
    to the directory which entries it listed, so that the check if the
    file is executable could be done on dir->d_name.
    
    However, there is no good reason to jump around wildly just to find
    all Git commands.
    
    Instead, have a strbuf and construct the full path dynamically.
    
    Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    dscho committed with gitster Jul 27, 2008
  6. builtin-branch: fix -v for --[no-]merged

    After the optimization to --[no-]merged logic, the calculation of the
    width of the longest refname to be shown might become inaccurate (since
    the matching against merge_filter is performed after adding refs to
    ref_list). This patch forces a recalculation of maxwidth when it might
    be needed.
    
    Signed-off-by: Lars Hjemli <hjemli@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    hjemli committed with gitster Jul 26, 2008
  7. builtin-branch: factor out merge_filter matching

    The logic for checking commits against merge_filter will be reused
    when we recalculate the maxwidth of refnames.
    
    Signed-off-by: Lars Hjemli <hjemli@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    hjemli committed with gitster Jul 26, 2008
  8. builtin-branch: remove duplicated code

    The previous optimization to --[no-]merged ended up with some duplicated
    code which this patch removes.
    
    Signed-off-by: Lars Hjemli <hjemli@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    hjemli committed with gitster Jul 26, 2008
  9. rev-parse: Add support for the ^! and ^@ syntax

    Those shorthands are explained in the rev-parse documentation but were not
    actually supported by rev-parse itself.
    
    gitk internally uses rev-parse to interpret its command line arguments, and
    being able to use these "limit with parents" syntax is handy there.
    
    Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    dotdash committed with gitster Jul 26, 2008
  10. make sure parsed wildcard refspec ends with slash

    A wildcard refspec is internally parsed into a refspec structure with src
    and dst strings.  Many parts of the code assumed that these do not include
    the trailing "/*" when matching the wildcard pattern with an actual ref we
    see at the remote.  What this meant was that we needed to make sure not
    just that the prefix matched, and also that a slash followed the part that
    matched.
    
    But a codepath that scans the result from ls-remote and finds matching
    refs forgot to check the "matching part must be followed by a slash" rule.
    This resulted in "refs/heads/b1" from the remote side to mistakenly match
    the source side of "refs/heads/b/*:refs/remotes/b/*" refspec.
    
    Worse, the refspec crafted internally by "git-clone", and a hardcoded
    preparsed refspec that is used to implement "git-fetch --tags", violated
    this "parsed widcard refspec does not end with slash" rule; simply adding
    the "matching part must be followed by a slash" rule then would have
    broken codepaths that use these refspecs.
    
    This commit changes the rule to require a trailing slash to parsed
    wildcard refspecs.  IOW, "refs/heads/b/*:refs/remotes/b/*" is parsed as
    src = "refs/heads/b/" and dst = "refs/remotes/b/".  This allows us to
    simplify the matching logic because we only need to do a prefixcmp() to
    notice "refs/heads/b/one" matches and "refs/heads/b1" does not.
    
    Acked-by: Daniel Barkalow <barkalow@iabervon.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    gitster committed Jul 27, 2008
  11. gitweb: More about how gitweb gets 'owner' of repository

    Signed-off-by: Jakub Narebski <jnareb@gmail.com>
    Acked-by: Petr Baudis <pasky@suse.cz>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    jnareb committed with gitster Jul 26, 2008
  12. t6030 (bisect): work around Mac OS X "ls"

    t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero
    status when asked to list nonexistent files.  Unfortunately,
    /bin/ls on Mac OS X 10.3 exits with exit code 0.  So look at
    its output instead.
    
    Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
    Acked-by: Christian Couder <chriscool@tuxfamily.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Jonathan Nieder committed with gitster Jul 27, 2008
  13. Documentation/git-submodule.txt: fix doubled word

    Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    cesarb committed with gitster Jul 26, 2008
  14. bash completion: Add completion for 'git help'

    Rename cached __git_commandlist to __git_porcelain_commandlist and
    add __git_all_commandlist that only filters out *--* helpers.
    
    Completions for 'git help' will use the __git_all_commandlist, while
    the __git_porcelain_commandlist is used for git command completion.
    
    Users who actually read man pages may want to see help for plumbing
    commands.
    
    Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
    Acked-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    lmarlow committed with gitster Jul 24, 2008
  15. Documentation: fix diff.external example

    The diff.external examples pass a flag to gnu-diff, but GNU diff
    does not follow the GIT_EXTERNAL_DIFF interface.
    
    Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Anders Melchiorsen committed with gitster Jul 27, 2008
  16. bash completion: Add long options for 'git describe'

    Signed-off-by: Thomas Rast <trast@student.ethz.ch>
    Acked-by: Shawn O. Pearce <spearce@spearce.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    trast committed with gitster Jul 26, 2008
  17. Clarify that "git log x.c y.h" lists commits that touch either file

    Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    amenonsen committed with gitster Jul 26, 2008
  18. Merge git://repo.or.cz/git-gui

    * git://repo.or.cz/git-gui:
      git-gui: "Stage Line": Treat independent changes in adjacent lines better
      git-gui: Fix "Stage/Unstage Line" with one line of context.
      git-gui: Correct 'Visualize Branches' on Mac OS X to start gitk
      git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
      Add a menu item to invoke full copy detection in blame.
      Kill the blame back-end on window close.
      Add options to control the search for copies in blame.
      Fix pre-commit hooks under MinGW/MSYS
    gitster committed Jul 27, 2008
Commits on Jul 26, 2008
  1. git-gui: "Stage Line": Treat independent changes in adjacent lines be…

    …tter
    
    Assume that we want to commit these states:
    
      Old state == HEAD    Intermediate state   New state
      --------------------------------------------------------
      context before       context before       context before
      old 1                new 1                new 1
      old 2                old 2                new 2
      context after        context after        context after
    
    that is, want to commit two changes in this order:
    
      1. transform "old 1" into "new 1"
      2. transform "old 2" into "new 2"
    
    [This discussion and this patch is about this very case and one other case
    as outlined below; any other intermediate states that one could imagine are
    not affected by this patch.]
    
    Now assume further, that we have not staged and commited anything, but we
    have already changed the working file to the new state. Then we will see
    this hunk in the "Unstaged Changes":
    
      @@ -1,4 +1,4 @@
       context before
      -old 1
      -old 2
      +new 1
      +new 2
       context after
    
    The obvious way to stage the intermediate state is to apply "Stage This
    Line" to "-old 1" and "+new 1". Unfortunately, this resulted in this
    intermediate state:
    
      context before
      old 2
      new 1
      context after
    
    which is not what we wanted. In fact, it was impossible to stage the
    intermediate state using "Stage Line". The crux was that if a "+" line was
    staged, then the "-" lines were converted to context lines and arranged
    *before* the "+" line in the forged hunk that we fed to 'git apply'.
    
    With this patch we now treat "+" lines that are staged differently. In
    particular, the "-" lines before the "+" block are moved *after* the
    staged "+" line. Now it is possible to get the correct intermediate state
    by staging "-old 1" and "+new 1". Problem solved.
    
    But there is a catch.
    
    Noticing that we didn't get the right intermediate state by staging
    "-old 1" and "+new 1", we could have had the idea to stage the complete
    hunk and to *unstage* "-old 2" and "+new 2". But... the result is the same.
    The reason is that there is the exact symmetric problem with unstaging the
    last "-" and "+" line that are in adjacent blocks of "-" and "+" lines.
    
    This patch does *not* change the way in which "-" lines are *unstaged*.
    
    Why? Because if we did (i.e. move "+" lines before the "-" line after
    converting them to context lines), then it would be impossible to stage
    this intermediate state:
    
      context before
      old 1
      new 2
      context after
    
    that is, it would be impossible to stage the two independet changes in the
    opposite order.
    
    Let's look at this case a bit further: The obvious way to get this
    intermediate state would be to apply "Stage This Line" to "-old 2" and
    "+new 2". Before this patch, this worked as expected. With this patch, it
    does not work as expected, but it can still be achieved by first staging
    the entire hunk, then *unstaging* "-old 1" and "+new 1".
    
    In summary, this patch makes a common case possible, at the expense that
    a less common case is made more complicated for the user.
    
    Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Johannes Sixt committed with spearce Jul 17, 2008
  2. git-gui: Fix "Stage/Unstage Line" with one line of context.

    To "Stage/Unstage Line" we construct a patch that contains exactly one
    change (either addition or removal); the hunk header was forged by counting
    the old side and adjusting the count by +/-1 for the new side. But when we
    counted the context we never counted the changed line itself. If the hunk
    had only one removal line and one line of context, like this:
    
        @@ -1,3 +1,2 @@
         context 1
        -removal
         context 2
    
    We had constructed this patch:
    
        @@ -1,2 +1,1 @@
         context 1
        -removal
         context 2
    
    which does not apply because git apply deduces that it must apply at the
    end of the file. ("context 2" is considered garbage and ignored.) The fix
    is that removal lines must be counted towards the context of the old side.
    
    Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
    Johannes Sixt committed with spearce Jul 15, 2008
  3. git-reset: Let -q hush "locally modified" messages

    "git reset -q" is advertised to "only report errors", but "locally
    modified" messages are still shown.  They are not errors but diagnostics.
    
    Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    sbeyer committed with gitster Jul 25, 2008
  4. git-svn: teach dcommit about svn auto-props

    Subversion repositories often require files to have properties such as
    svn:mime-type and svn:eol-style set when they are added.  Users
    typically set these properties automatically using the SVN auto-props
    feature with 'svn add'.  This commit teaches dcommit to look at the user
    SVN configuration and apply matching auto-props entries for files added
    by a diff as it is applied to the SVN remote.
    
    Signed-off-by: Brad King <brad.king@kitware.com>
    Acked-by: Eric Wong <normalperson@yhbt.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    bradking committed with gitster Jul 25, 2008
  5. Windows: Do not compile git-shell

    Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Johannes Sixt committed with gitster Jul 21, 2008
  6. Windows: Make sure argv[0] has a path

    Since the exec-path on Windows is derived from the program invocation path,
    we must ensure that argv[0] always has a path. Unfortunately, if a program
    is invoked from CMD, argv[0] has no path. But on the other hand, the
    C runtime offers a global variable, _pgmptr, that always has the full path
    to the program. We hook into main() with a preprocessor macro, where we
    replace argv[0].
    
    Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Johannes Sixt committed with gitster Jul 21, 2008
  7. Windows: Make $(gitexecdir) relative

    Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Johannes Sixt committed with gitster Jul 21, 2008
  8. Allow add_path() to add non-existent directories to the path

    This function had used make_absolute_path(); but this function dies if
    the directory that contains the entry whose relative path was supplied in
    the argument does not exist. This is a problem if the argument is, for
    example, "../libexec/git-core", and that "../libexec" does not exist.
    
    Since the resolution of symbolic links is not required for elements in
    PATH, we can fall back to using make_nonrelative_path(), which simply
    prepends $PWD to the path.
    
    We have to move make_nonrelative_path() alongside make_absolute_path() in
    abspath.c so that git-shell can be linked. See 5b8e6f8.
    
    Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Johannes Sixt committed with gitster Jul 21, 2008
  9. Allow the built-in exec path to be relative to the command invocation…

    … path
    
    If GIT_EXEC_PATH (the macro that is defined in the Makefile) is relative,
    it is interpreted relative to the command's invocation path, which usually
    is $(bindir).
    
    The Makefile rules were written with the assumption that $(gitexecdir) is
    an absolute path. We introduce a separate variable that names the
    (absolute) installation directory.
    
    Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Johannes Sixt committed with gitster Jul 23, 2008
  10. Fix relative built-in paths to be relative to the command invocation

    $(gitexecdir) (as defined in the Makefile) has gained another path
    component, but the relative paths in the MINGW section of the Makefile,
    which are interpreted relative to it, do not account for it.
    
    Instead of adding another ../ in front of the path, we change the code that
    constructs the absolute paths to do it relative to the command's directory,
    which is essentially $(bindir). We do it this way because we will also
    allow a relative $(gitexecdir) later.
    
    Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Johannes Sixt committed with gitster Jul 21, 2008
  11. Record the command invocation path early

    We will need the command invocation path in system_path(). This path was
    passed to setup_path(), but  system_path() can be called earlier, for
    example via:
    
        main
          commit_pager_choice
            setup_pager
              git_config
                git_etc_gitconfig
                  system_path
    
    Therefore, we introduce git_set_argv0_path() and call it as soon as
    possible.
    
    Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Johannes Sixt committed with gitster Jul 21, 2008
  12. Makefile: Normalize $(bindir) and $(gitexecdir) before comparing

    The install target needs to check whether the user has opted to make
    $(gitexecdir) equal to $(bindir). It did so by a straight string
    comparison. Since we are going to allow a relative $(gitexecdir), we have
    to normalize paths before comparison, which we do with $(cd there && pwd).
    
    The normalized paths are stored in shell variables. These we can now
    reuse in the subsequent install statements, which conveniently shortens
    the lines a bit.
    
    Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Johannes Sixt committed with gitster Jul 21, 2008
  13. Makefile: Do not install a copy of 'git' in $(gitexecdir)

    There is already a copy in $(bindir). A subsequent patch will enable git
    to derive the exec-path from its invocation path. If git is invoked
    recursively, the first invocation puts the exec-path into PATH, so that
    the recursive invocation would find the instance in the exec-path. This
    second instance would again try to derive an exec-path from its invocation
    path, but would base its result on the wrong "bindir".
    
    We do install the copy of git first, but remove it later, so that we can
    use it as the source of the hardlinks for the builtins.
    
    Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Johannes Sixt committed with gitster Jul 21, 2008
  14. archive: allow --exec and --remote without equal sign

    Allow "--remote repo" and "--exec cmd" in addition to "--remote=repo" and
    "--exec=cmd" to make their usage consistent with parameters handled by
    parse_options().
    
    Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Rene Scharfe committed with gitster Jul 25, 2008
  15. archive: declare struct archiver where it's needed

    Move the declaration of struct archiver to archive.c, as this is the only
    file left where it is used.
    
    Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Rene Scharfe committed with gitster Jul 25, 2008
  16. archive: define MAX_ARGS where it's needed

    MAX_EXTRA_ARGS is not used anymore, so remove it.  MAX_ARGS is used only
    in builtin-upload-archive.c, so define it there.  Also report the actual
    value we're comparing against when the number of args is too big.
    
    Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Rene Scharfe committed with gitster Jul 25, 2008
  17. archive: move parameter parsing code to archive.c

    write_archive() in archive.c is the only callsite for the command line
    parsing functions located in builtin-archive.c.  Move them to the place
    where they are used, un-export them and make them static, as hinted at
    by Stephan.
    
    Cc: Stephan Beyer <s-beyer@gmx.net>
    Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    Rene Scharfe committed with gitster Jul 25, 2008