Re: [PATCH 1/2] help: introduce option --command-only

Hi Ralf, Ralf Thielow writes: > [...] > +test_expect_success "works for commands and guides by default" " > +git help status && > +git help revisions > +" > + > +test_expect_success "--command-only does not work for guides" " > +git help

Re: git cherry-pick conflict error message is deceptive when cherry-picking multiple commits

Stephen Morton <stephen.mor...@nokia.com> writes: > [snip] > On 2016-08-16 4:44 AM, Remi Galan Alfonso wrote: >> Hi Stephen, >> >> Stephen Morton <stephen.mor...@nokia.com> writes: >>> +if (multiple_commits) >>> +

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

Junio C Hamano <gits...@pobox.com> writes: > Remi Galan Alfonso <remi.galan-alfo...@ensimag.grenoble-inp.fr> > writes: > >> Johannes Schindelin <johannes.schinde...@gmx.de> writes: >>> Hi Rémi, >>> >>> On Tue, 16 Aug 2016, Remi Galan Al

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

Johannes Schindelin <johannes.schinde...@gmx.de> writes: > Hi Rémi, > > On Tue, 16 Aug 2016, Remi Galan Alfonso wrote: > > > Johannes Schindelin <johannes.schinde...@gmx.de> writes: > > > diff --git a/t/t1350-config-hooks-path.sh b/t/t1350-config-hooks-path

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

Hi Johannes, Johannes Schindelin writes: > diff --git a/t/t1350-config-hooks-path.sh b/t/t1350-config-hooks-path.sh > index 5e3fb3a..f1f9aee 100755 > --- a/t/t1350-config-hooks-path.sh > +++ b/t/t1350-config-hooks-path.sh > @@ -34,4 +34,10 @@ test_expect_success

Re: git cherry-pick conflict error message is deceptive when cherry-picking multiple commits

Hi Stephen, Stephen Morton writes: > +if (multiple_commits) > + advise(_("after resolving the conflicts, > mark the corrected paths with 'git add ' or 'git rm '\n" > +"then

Re: [PATCHv2] checkout: do not mention detach advice for explicit --detach option

Stefan Beller writes: > +test_expect_success 'no advice given for explicit detached head state' ' > +git config advice.detachedHead false && > +git checkout child && > +git checkout --detach HEAD >expect && > +git config advice.detachedHead true

Re: Bug? git rebase -i --autostash fails to restore working files

Hi Phillip, Phillip Wood writes: > When running ‘git rebase -i --autostash’ if the editor fails then the > rebase fails but stash is not applied so the working files are not > restored. Running ‘git rebase --abort’ replies that there’s no rebase > in progress. If you

Re: [PATCH v1 2/3] convert: modernize tests

Hi Lars, Sorry, minor nit that I noticed a couple of days ago but didn't comment on the moment and forgot until now. Lars Schneider wrote: > Use `test_config` to set the config, check that files are empty with > `test_must_be_empty`, compare files with `test_cmp`, and

Re: [PATCH v3 4/4] archive-tar: drop return value

Hi Peff, Jeff King writes: > @@ -413,7 +411,7 @@ static int write_tar_archive(const struct archiver *ar, > { > int err = 0; > > -err = write_global_extended_header(args); > +write_global_extended_header(args); > if (!err) > err

Re: [PATCH v4 1/6] t9001: non order-sensitive file comparison

Hi Samuel, Samuel GROOT writes: > +test_cmp_noorder () { > +sort "$1" >"$1_noorder" > +sort "$2" >"$2_noorder" > +test_cmp $1 $2 You meant `test_cmp "$1_noorder" "$2_noorder"`, I guess. Thanks, Rémi -- To unsubscribe from this list: send

Re: [PATCH] completion: complete --move for git branch

Ville Skyttä <ville.sky...@iki.fi> writes: > On Mon, Jun 6, 2016 at 5:16 PM, Remi Galan Alfonso > <remi.galan-alfo...@ensimag.grenoble-inp.fr> wrote: > > > > Hi, > > > > Ville Skyttä <ville.sky...@iki.fi> writes: > > > while

Re: [PATCH] completion: complete --move for git branch

Hi, Ville Skyttä writes: > while [ $c -lt $cword ]; do > i="${words[c]}" > case "$i" in > --d|-m)only_local_ref="y" ;; > --r)has_r="y" ;; > +-d|-m|--move)

Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

Hi Antoine, Antoine Queru writes: > [...] > +For example, if we set up the configuration variables like this: > + > +--- > +git config --add remote.pushBlacklist repository.com > +git config --add remote.pushWhitelist

Re: [PATCH 0/2] strbuf: improve API

William Duclot writes: > This patch series implements an improvment of the strbuf API, allowing > strbuf to use preallocated memory. This makes strbuf fit to be used > in performance-critical operations. > > The first patch is simply a preparatory work,

Re: [RFC/PATCH 1/2] log: add "log.showsignature" configuration variable

Mehul Jain <mehul.jain2...@gmail.com> writes: > Hi Remi, > > Thanks for your input. > > On Thu, May 26, 2016 at 7:12 PM, Remi Galan Alfonso > <remi.galan-alfo...@ensimag.grenoble-inp.fr> wrote: > > Hi Mehul, > > > > Mehul Jain <mehul.jain2...

Re: [RFC/PATCH 1/2] log: add "log.showsignature" configuration variable

Hi Mehul, Mehul Jain writes: > People may want to always use "--show-signature" while using "git log" > or "git show". > > When log.showsignature set true, "git log" and "git show" will behave 'When log.showsignature is set to true' ? > as "--show-signature" was

Re: [PATCH 2/2] submodule update: learn `--[no-]recommend-shallow` option

You forgot to update from recommend-depth to recommend-shallow Stefan Beller writes: > [...] > 'git submodule' [--quiet] init [--] [...] > 'git submodule' [--quiet] deinit [-f|--force] (--all|[--] ...) > 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]

Re: [PATCH 1/2] submodule-config: keep shallow recommendation around

Hi Stefan, Stefan Beller writes: > [...] > @ -353,6 +354,15 @@ static int parse_config(const char *var, const char > *value, void *data) > else if (parse_submodule_update_strategy(value, > >update_strategy) < 0) >

Re: possible bug of git stash deleting uncommitted files in corner case

Junio C Hamano <gits...@pobox.com> writes: > Remi Galan Alfonso <remi.galan-alfo...@ensimag.grenoble-inp.fr> > writes: > > > Daniele Segato <daniele.seg...@gmail.com> wrote: > > ... > >> git version 1.9.1 > > > > Contrary to what I

Re: possible bug of git stash deleting uncommitted files in corner case

Daniele Segato wrote: > git init > echo 'X' > foo > git add foo > git commit -m 'foo file committed' > > rm foo > mkdir foo > echo 'B' > foo/bar > > # git status > > git stash > > at this point stash deleted the "bar" file, in his case all the work > on the previous

Re: Ambiguous sha-1 during a rebase

Matthieu Moy writes: > Mike Hommey writes: > > > Yeah, that definitely is a weird corner case. Interestingly, it was > > complaining about "error: short SHA1 e34ff55 is ambiguous." when apply > > *other* commits that were in the list prior to it,

Re: [PATCH v3][Outreachy] branch -D: allow - as abbreviation of @{-1}

elena petrashen <elena.petras...@gmail.com> wrote: > On Tue, Apr 5, 2016 at 12:53 AM, Remi Galan Alfonso > <remi.galan-alfo...@ensimag.grenoble-inp.fr> wrote: > > elena petrashen <elena.petras...@gmail.com> wrote: > >> On Thu, Mar 31, 2016 at 6:31 PM, R

Re: [RFC/PATCH] git.spec: fix changelog dates

Michael J Gruber <g...@drmicha.warpmail.net> wrote: > Remi Galan Alfonso venit, vidit, dixit 05.04.2016 14:28: > > Michael J Gruber <g...@drmicha.warpmail.net> wrote: > >> A few changelog entries have inconsistent dates, which rpmlint reports > >&

Re: [RFC/PATCH] git.spec: fix changelog dates

Michael J Gruber wrote: > A few changelog entries have inconsistent dates, which rpmlint reports > as errors. > > Fix them based on these assumptions: > - It's easier to mistype a number than a weekday abbreviation. > - changelog date must be before git commit date > -

Re: [PATCH v3][Outreachy] branch -D: allow - as abbreviation of @{-1}

elena petrashen <elena.petras...@gmail.com> wrote: > On Thu, Mar 31, 2016 at 6:31 PM, Remi Galan Alfonso > <remi.galan-alfo...@ensimag.grenoble-inp.fr> wrote: > > Elena Petrashen <elena.petras...@gmail.com> wrote: > >> +void delete_branch_a

Re: [PATCH v3][Outreachy] branch -D: allow - as abbreviation of @{-1}

Elena Petrashen wrote: > +void delete_branch_advice(const char *name, const char *ref) > +{ > +const char fmt[] = > +"\nNote: to restore the deleted branch:\n\ngit branch %s %s\n"; Shouldn't that be marked for translation, like is done with the other

Re: [RFC/GSOC] Git Beginner | Warnings for potentially destructive commands (v2)

Sidhant Sharma wrote: > $ ggit push --force > > Pushing changes to $REMOTE/$BRANCH > [WARNING] You are about to purge commits from the $REMOTE/$BRANCH branch and > overwrite it's history to match yours. > For instance, assume the following history exists where 'origin' is

Re: Regarding GSoC 2016

Mehul Jain wrote: > On Thu, Mar 24, 2016 at 11:13 PM, Saurabh Jain > wrote: > > The proposal can be accessed here. > > > 5mWF_cqoZS6IUvGr6CVu5SmkbZk/edit?usp=sharing> > > It's broken I

Re: [PATCH] rebase: accept indented comments (fixes regression)

Matthieu Moy writes: > With Git <2.0.6, 'git rebase' used to accept lines starting with > whitespaces followed with '#' as a comment. This was broken by > 804098b (git rebase -i: add static check for commands and SHA-1, > 2015-06-29), which introduced additional checks on

Re: [PATCH v5] git-p4: add config git-p4.pathEncoding

Lars Schneider writes: > > Hi Lars, > > > > Lars Schneider writes: > > > >> +test_expect_success 'Clone repo containing iso8859-1 encoded paths with > >> git-p4.pathEncoding' ' > >> + > >> +test_when_finished cleanup_git && > >> +

Re: [PATCH v5] git-p4: add config git-p4.pathEncoding

Hi Lars, Lars Schneider writes: > +test_expect_success 'Clone repo containing iso8859-1 encoded paths with > git-p4.pathEncoding' ' > + > +test_when_finished cleanup_git && > +( > +cd "$git" && > +git init . && > +

Re: [PATCH v8] git-p4: Obey core.ignorecase when using P4 client specs

Hi, Lars Schneider larsxschnei...@gmail.com writes: Fix this by using the path case that appears first in lexicographical order when core.ignorcase is set to true. This behavior is consistent s/core.ignorcase/core.ignorecase with p4 and p4v. Thanks, Rémi -- To unsubscribe from this list:

Re: [PATCH] http: add support for specifying the SSL version

Hello, Elia Elia Pinto gitter.spi...@gmail.com writes: +if (ssl_version != NULL *ssl_version) { +if (!strcmp(ssl_version,tlsv1)) { +sslversion = CURL_SSLVERSION_TLSv1; +} else if (!strcmp(ssl_version,sslv2)) { +

Re: [PATCH] fetch: add configuration for making --all default

Hi, Øystein Walle oys...@gmail.com writes: +fetch.all:: +If true, fetch will automatically behave as if the `--all` +option was given on the command line uness a remote was given. The +default is false. s/uness/unless +test_expect_success 'git fetch (fetch.all =

Re: [PATCH 1/4] list-object: add get_commit_count function

Lawrence Siebert lawrencesieb...@gmail.com writes: +get_commit_count(revs); There's trailing whitespace here. (See my message in 3/4) Rémi -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info

Re: [PATCH 2/4] log: add --count option to git log

Lawrence Siebert lawrencesieb...@gmail.com writes: +prepare_revision_walk(rev); There's trailing whitespace here. (See my message in 3/4) Rémi -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More

Re: [PATCH 3/4] log --count: added test

Hi Lawrence, Lawrence Siebert lawrencesieb...@gmail.com writes: +test_expect_success 'log --count' ' +git log --count HEAD actual +gitrev-list --count HEAD expect Why the huge space here between 'git' and 'rev-list'? Also no space after the redirection (''), it

Re: [PATCH 0/3] rebase -i: drop, missing commits and static checks

Matthieu Moy matthieu@imag.fr writes: Hi, Here are a few fixes to squash into the commits of the series. Other than that, the series looks good to me. Junio: do you prefer a reroll or do you want to apply locally? Matthieu Moy (3): fixup! git rebase -i: add static check for

Re: [PATCH 0/3] rebase -i: drop, missing commits and static checks

Matthieu Moy matthieu@grenoble-inp.fr writes: Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr writes: Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr writes: Shouldn't all the checking also be called in a 'rebase --continue', considering that it can be called after

Re: [PATCH] commit: add commit.signoff config option

Caio Marcelo de Oliveira Filho cmarc...@gmail.com writes: +test_expect_success 'commit.signoff config option' ' +git config commit.signoff true +echo yet another content *narf* foo +echo zort | git commit -F - foo +git cat-file commit HEAD | sed 1,/^\$/d

Re: [PATCHv6 1/3] git-rebase -i: add command drop to remove a commit

Eric Sunshine sunsh...@sunshineco.com writes: +test_rebase_end () { + test_when_finished git checkout master + git branch -D $1 + test_might_fail git rebase --abort + git checkout -b $1 master +} The way this is indented makes it difficult to see that

Re: [PATCHv6 1/3] git-rebase -i: add command drop to remove a commit

Matthieu Moy matthieu@grenoble-inp.fr writes: Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr writes: Eric Sunshine sunsh...@sunshineco.com writes: +test_rebase_end () { + test_when_finished git checkout master + git branch -D $1

Re: [PATCH v7 4/5] bisect: add the terms old/new

Matthieu Moy matthieu@imag.fr writes: Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr Signed-off-by: Matthieu Moy matthieu@imag.fr Sounds like you went all out with this patch. Rémi -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: [PATCHv6 1/3] git-rebase -i: add command drop to remove a commit

Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr writes: I think that the indentation on its own is enough to avoid confusion test_rebase_end () { test_when_finished git

Re: [PATCHv6 3/3] git rebase -i: add static check for commands and SHA-1

Junio C Hamano gits...@pobox.com writes: Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr writes: I used: read -r command sha1 rest EOF $line EOF because printf '%s' $line | read -r command sha1 rest doesn't work (the 3 variables have no value as a result).

Re: [PATCHv6 1/3] git-rebase -i: add command drop to remove a commit

Junio C Hamano gits...@pobox.com writes: Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr writes: +test_rebase_end () { +test_when_finished git checkout master +git branch -D $1 Is this one guaranteed to succeed? Do we want to consider it a failure to

Re: [PATCH 2/3] Move unsigned long option parsing out of pack-objects.c

Charles Bailey cbaile...@bloomberg.net writes: test_expect_success 'long options' ' - test-parse-options --boolean --integer 1729 --boolean --string2=321 \ - --verbose --verbose --no-dry-run --abbrev=10 --file fi.le\ - --obsolete output 2 output.err + test-parse-options --boolean --integer

Re: What's cooking in git.git (Jun 2015, #04; Tue, 16)

Junio C Hamano gits...@pobox.com writes: * gr/rebase-i-drop-warn (2015-06-01) 2 commits - git rebase -i: warn about removed commits - git-rebase -i: add command drop to remove a commit Add drop commit-object-name subject command as another way to skip replaying of a commit in rebase -i, and

Re: [PATCH/RFCv5 3/3] git rebase -i: add static check for commands and SHA-1

Matthieu Moy matthieu@grenoble-inp.fr writes: Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr writes: It is mainly because here the SHA-1 is a long one (40 chars) OK, but then the minimum would be to add a comment saying that. Now, this makes me wonder why you

Re: [PATCH/RFCv5 2/3] git rebase -i: warn about removed commits

Matthieu Moy matthieu@grenoble-inp.fr writes: Remi Galan Alfonso remi.galan-alfo...@ensimag.grenoble-inp.fr writes: Matthieu Moy matthieu@grenoble-inp.fr writes: +warn_file $todo.miss I would find it more elegant with less intermediate files, like

Re: [PATCH/RFCv5 3/3] git rebase -i: add static check for commands and SHA-1

+git stripspace --strip-comments | +while read -r command sha1 rest +do +case $command in +''|noop|x|exec) +;; +pick|p|drop|d|reword|r|edit|e|squash|s|fixup|f) +

Re: [PATCH/RFCv5 2/3] git rebase -i: warn about removed commits

Matthieu Moy matthieu@grenoble-inp.fr writes: +warn_file $todo.miss I would find it more elegant with less intermediate files, like git rev-list $opt $todo.miss | while read -r line do warn - $line done I am not really sure since I also use

Re: [PATCH/RFCv2 2/2] git rebase -i: warn about removed commits

I'm going to try to change the die_abort in this patch by a die, so that the user can use rebase --edit-todo afterward. This way, adding the checking on the SHA-1 for the 'drop' command (discussed in 1/2) (and also maybe the other commands requiring a correct SHA-1 corresponding to a commit) to

Re: [PATCH/RFCv4 1/2] git-rebase -i: add command drop to remove a commit

Junio C Hamano gits...@pobox.com writes: But what if you got this back after the user edits? drop pick 2c9c1c5 gostak: distim doshes drop e3b601d pull: use git-rev-parse... edit eb2a8d9 pull: handle git-fetch'... [...] Did the user tried to drop something else but the

Re: [PATCH/RFCv2 2/2] git rebase -i: warn about removed commits

Eric Sunshine sunsh...@sunshineco.com writes: +test_expect_success 'rebase -i respects rebase.missingCommitsCheck=ignore' ' + test_config rebase.missingCommitsCheck ignore + test_when_finished git checkout master + git branch -D tmp2 Strange indentation.

Re: [PATCH/RFCv3 2/2] git rebase -i: warn about removed commits

Matthieu Moy matthieu@grenoble-inp.fr writes: Ideally, you would check the list of commits displayed too. If the commits sha1 are stable, this should be easy to do. If it's too hard to test, I'd say its not worth the trouble, but others may disagree. Originally I chose not to

Re: [PATCH/RFCv3 2/2] git rebase -i: warn about removed commits

Matthieu Moy matthieu@grenoble-inp.fr writes: Ideally, you would check the list of commits displayed too. If the commits sha1 are stable, this should be easy to do. If it's too hard to test, I'd say its not worth the trouble, but others may disagree. Originally I chose not to check if the

Re: [PATCH/RFCv2 1/2] git-rebase -i: add command drop to remove a commit

Junio C Hamano gits...@pobox.com writes: As long as what is given to 'drop' is checked when it matters (e.g. when the code in patch 2/2 tries see if some commits in the original list are no longer there in order to warn sees drop foo bar where foo is obviously not an object name in the

Re: [PATCH/RFCv4 2/2] git rebase -i: warn about removed commits

Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr writes: +comm -2 -3 $todo.oldsha1 $todo.newsha1 $todo.miss + +# Make the list user-friendly +opt=--no-walk=sorted --format=oneline --abbrev-commit --stdin +git rev-list $opt

Re: [PATCH/RFCv4 2/2] git rebase -i: warn about removed commits

Matthieu Moy matthieu@grenoble-inp.fr writes: You're using $1 and $2 only to redirect input and output. I would find it more elegant to write todo_list_to_sha_list as a filter, and do the redirection in the call site (to keep the option of using todo_list_to_sha_list in a pipe). If I

Re: [PATCH/RFCv2 2/2] git rebase -i: warn about removed commits

Eric Sunshine sunsh...@sunshineco.com writes: +rebase.checkLevel:: + If set to warn, git rebase -i will print a warning if some + commits are removed (i.e. a line was deleted) or if some + commits appear more than one time (e.g. the same commit is + picked twice),

Re: [PATCH/RFCv2 1/2] git-rebase -i: add command drop to remove a commit

Ideally, I think we should do a sanity check before starting the rebase, and error out if we encounter an invalid command, a command that should be followed by a valid sha1 and does not, ... But currently, we do the verification while applying commands, and I don't think there's anything

Re: [PATCH/RFCv2 2/2] git rebase -i: warn about removed commits

Matthieu Moy matthieu@grenoble-inp.fr writes: Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr writes: Check if commits were removed (i.e. a line was deleted) and print warnings or abort git rebase according to the value of the configuration variable rebase.checkLevel.

Re: [PATCH/RFCv3 1/2] git-rebase -i: add command drop to remove a commit

Matthieu Moy matthieu@grenoble-inp.fr : writes +test_expect_success 'drop' ' Please, be more descriptive in the first argument of test_expect_success. It's usually a good thing to say not only what the test stresses but also what the expected behavior is. test_expect_success 'drop

Re: [PATCH/RFCv2 2/2] git rebase -i: warn about removed commits

Eric Sunshine sunsh...@sunshineco.com writes: Although the underlying behavior of ignore may be the same as the default, you also want to check that higher-level machinery for recognizing the ignore option is working correctly, which is why checking ignore explicitly is a reasonable thing

Re: [PATCH/RFCv3 2/2] git rebase -i: warn about removed commits

Matthieu Moy matthieu@grenoble-inp.fr writes: Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr writes: +# Sort the SHA-1 and compare them +echo $(sort -u $todo.oldsha1) $todo.oldsha1 +echo $(sort -u $todo.newsha1) $todo.newsha1

Re: [PATCH/RFCv2 1/2] git-rebase -i: add command drop to remove a commit

Junio C Hamano gits...@pobox.com writes: Is this sufficient? If you are going to do something in 2/2 that relies on the format of this line being correct (as opposed to noop or # that can have any garbage on the remainder of the line), wouldn't you want to at least check $sha1 is sensible?

Re: [PATCH/RFC 1/2] git-rebase -i: Add key word drop to remove a commit

At first we wanted a clear indication about removing a commit in rebase -i. We didn't know about the noop command. - 'noop' does the same thing as 'drop' but for the user deleting a commit through 'noop' doesn't seem to be the proper way to use this command. Moreover 'noop' is not

Re: [PATCH/RFC 2/2] git rebase -i: Warn removed or dupplicated commits

Junio C Hamano gits...@pobox.com writes: I think there is a difference between (silently) accepting just to be lenient and documenting and advocating mixed case uses. Personally, I'd rather not to see gratuitous flexibility to allow the same thing spelled in 47 different ways for no good

Re: [PATCH/RFC 2/2] git rebase -i: Warn removed or dupplicated commits

Thank you for reviewing the code. Eric Sunshinesunsh...@sunshineco.com writes: + # To uppercase + checkLevel=$(echo $checkLevel | tr '[:lower:]' '[:upper:]') Is there precedence elsewhere for recognizing uppercase and lowercase variants of config values? It seems to be

Re: [PATCH/RFC 2/2] git rebase -i: Warn removed or dupplicated commits

Eric Sunshinesunsh...@sunshineco.com writes: Shouldn't this case also 'die' when rebase.checkLevel is error? And, why doesn't the user get advice about configuring rebase.checkLevel in this case? Stephen Kellysteve...@gmail.com writes: I sometimes duplicate commits deliberately if I want to

Re: [PATCH/RFC 1/2] git-rebase -i: Add key word drop to remove a commit

Thank you for reviewing the code. Johannes Schindelinjohannes.schinde...@gmx.de writes: Please note that you can already just comment-out the line if you need to keep a visual trace. Alternatively, you can replace the `pick` command by `noop`. If you really need the `drop` command (with