[BUG] bugs in clean, status, bisect, and send-email

[BUG] bugs in clean, status, bisect, and send-email

[Mark Lodato]

I noticed the following four bugs but don't have time to investigate
further, let alone make test cases or fix them.  If someone else wants
to tackle these, great.  If not, I'll try to research them more when I
get free time, which won't be for a while.

All of the following have been tested with git 1.7.0, and the first
three examples use a new, empty repository.

$ mkdir test_dir
$ cd test_dir
$ git init


1. git-clean removes directories when a glob partially matches

If the pathspec given to 'git clean' has the potential to match a file
in a subdirectory (even if no matching file exists in that directory),
the entire directory is removed.  In the following example, none of
the commands should try to remove dir/.

$ mkdir dir
$ touch dir/file
$ git clean -nd 'x*'
$ git clean -nd '*.c'
Would remove dir/
$ git clean -nd 'd*j'
Would remove dir/


2. git-status globs only match untracked files, not staged or unmodified

The last command should show that b.c is staged and modified, but
instead it shows absolutely nothing.  If this is intended behavior,
it's certainly not what I would expect.

$ touch a.txt b.c
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       a.txt
#       b.c
nothing added to commit but untracked files present (use "git add" to track)
$ git status -- '*.c'
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       b.c
nothing added to commit but untracked files present (use "git add" to track)
$ git add b.c
$ echo foo >> b.c
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   b.c
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   b.c
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       a.txt
$ git status -- '*.c'
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)


3. git-send-email does not accept -h option

All other git sub-commands accept -h, so it would probably be a good
idea to implement it for 'git send-email' as well.

$ git send-email -h
usage: git format-patch [options] [<since> | <revision range>]

    -n, --numbered        use [PATCH n/m] even with a single patch
    -N, --no-numbered     use [PATCH] even with multiple patches
    -s, --signoff         add Signed-off-by:
    --stdout              print patches to standard out
    --cover-letter        generate a cover letter
    --numbered-files      use simple number sequence for output file names
    --suffix <sfx>        use <sfx> instead of '.patch'
    --start-number <n>    start numbering patches at <n> instead of 1
    --subject-prefix <prefix>
                          Use [<prefix>] instead of [PATCH]
    -o, --output-directory <dir>
                          store resulting files in <dir>
    -k, --keep-subject    don't strip/add [PATCH]
    --no-binary           don't output binary diffs
    --ignore-if-in-upstream
                          don't include a patch matching a commit upstream
    -p, --no-stat         show patch format instead of default (patch + stat)

Messaging
    --add-header <header>
                          add email header
    --cc <email>          add Cc: header
    --in-reply-to <message-id>
                          make first mail a reply to <message-id>
    --attach[=<boundary>]
                          attach the patch
    --inline[=<boundary>]
                          inline the patch
    --thread[=<style>]    enable message threading, styles: shallow, deep

format-patch -o /tmp/ipOBB8AaCU -h: command returned error: 129


4. git-bisect fails if a pathspec is given that matches no commits

It says there are -1 revisions left.  I have no idea what it does
after that.  The following example uses git.git.

$ git bisect start v1.7.0 v1.6.6 -- 'foobar'
Bisecting: -1 revisions left to test after this (roughly 0 steps)
[f2a37151d4624906e34a9bcafb2ad79d0e8cb7ec] Fix memory leak in helper
method for disconnect

Re: [BUG] bugs in clean, status, bisect, and send-email

[Junio C Hamano]

Mark Lodato <lodatom@gmail.com> writes:

> 2. git-status globs only match untracked files, not staged or unmodified

I am reasonably sure that this is related to a n issue we discussed on
"git add" vs "git add -u" recently.

In short, you cannot expect glob style pathspecs to work for an operation
that involves running diff internally.  You can guess that "To be
committed" is computed by internally running "diff --cached".

Currently globbing style pathspec are supported as an added bonus to only
some commands (e.g. "grep", "ls-files", "add" but not "add -u").  You can
also guess that "Untracked" is computed by internally running "ls-files".

In the meantime, limit yourself to leading path style pathspecs.

Re: [BUG] bugs in clean, status, bisect, and send-email

[Christian Couder]

On Thursday 25 February 2010 04:28:41 Mark Lodato wrote:
> I noticed the following four bugs but don't have time to investigate
> further, let alone make test cases or fix them.  If someone else wants
> to tackle these, great.  If not, I'll try to research them more when I
> get free time, which won't be for a while.

Thanks for the report!

> 4. git-bisect fails if a pathspec is given that matches no commits
> 
> It says there are -1 revisions left.  I have no idea what it does
> after that.  The following example uses git.git.
> 
> $ git bisect start v1.7.0 v1.6.6 -- 'foobar'
> Bisecting: -1 revisions left to test after this (roughly 0 steps)
> [f2a37151d4624906e34a9bcafb2ad79d0e8cb7ec] Fix memory leak in helper
> method for disconnect

I will have a look at this one, but I will be away until Monday, so don't 
expect anything from me before.

Thanks,
Christian.