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

From: Stefan Beller <sbeller@google.com>
Date: May 27, 2015, 21:47 UTC
Message-ID: <CAGZ79kansAUWsjBsBznqaxRFeN3uF1u2hUZgO8b+OjOw8SKsUw@mail.gmail.com>
In-Reply-To: <xmqq382hlpwt.fsf@gitster.dls.corp.google.com>

On Wed, May 27, 2015 at 1:35 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 25 quoted lines

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>>>
>>>> I find it weird to write
>>>>
>>>> noop <sha1> <title>
>>>
>>> True, but then it can be spelled
>>>
>>>     # <sha1> <title>
>>
>> I do find it weird too. "#" means "comment", which means "do as if it
>> was not there" to me. And in this case it does change the semantics once
>> you activate the safety feature: error out without the "# <sha1>
>> <title>", rebase dropping the commit if the comment is present.
>
> Well, I do not agree with the premise that "A line was removed, the
> user may have made a mistake, we need to warn about it" is a good
> idea in the first place.  Removing an insn that is not wanted has
> been the way to skip and not replay a change from the beginning of
> the time, and users shouldn't be trained into thinking that somehow
> is a bad practice by having such an option that warns.

Talking about ideas: I sometimes have the wrong branch checked out when doing a small fixup commit. So I want to drop that patch from the current branch and apply it to another branch. Maybe an instruction like cherry-pick-to-branch-(and-do-not-apply-here) would help me there.

On the other hand I do understand the reasoning for having more safety features in rebase as that exposes lots of power and many people find the power a bit daunting.

So maybe you don't want to check the rebase instructions, but rather after the fact, when the rebase is done:

$ git rebase -i origin/master
Successfully rebased and updated refs/heads/mytopic
Rebased the following commits:
    0e33744 Document protocol version 2
    6b6e3a7 t5544: add a test case for the new protocol
    d6aff73 transport: get_refs_via_connect exchanges capabilities before refs.
    cbb6089 transport: connect_setup appends protocol version number
    0b86fa1 fetch-pack: use the configured transport protocol
    23ed0ff remote.h: add get_remote_capabilities, request_capabilities
    e18b6dc transport: add infrastructure to support a protocol version number
    fd8d40d upload-pack-2: Implement the version 2 of upload-pack
    bf781ae upload-pack: move capabilities out of send_ref
    4c9cb59 upload-pack: make client capability parsing code a separate function
Dropped the following commits:
    deadbee upload-pack: only accept capabilities on the first "want" line
New commits: (due to rewording, double picking, etc)
    c0ffee1 More Documentation

I'd guess you would construct the information from the reflog (The line before "rebase -i (start)" in the reflog) delta'd against HEAD, so it's a crude incantation of git log maybe?

Also we need to turn this off for the power users, though I'd welcome if we'd make it default on in git 3. (Being maximally verbose is good for new users I assume, and turning it off is easy for advanced folks, so we can do that for all porcelain commands?)

Show 5 quoted lines

>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html