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

Matthieu Moy [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

Matthieu Moy [off-list ref] writes:

quoted

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.

On Wed, May 27, 2015 at 1:35 PM, Junio C Hamano [off-list ref] wrote:

Matthieu Moy [off-list ref] writes:

quoted

Junio C Hamano [off-list ref] writes:

quoted

Matthieu Moy [off-list ref] writes:

quoted

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?)

--
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

Hi Stefan,

On 2015-05-27 23:47, Stefan Beller wrote:

On Wed, May 27, 2015 at 1:35 PM, Junio C Hamano [off-list ref] wrote:
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.

Oh, is it wish-anything time? *claps-his-hands*

I would wish for a graphical tool which visualizes the commit graph in a visually pleasing manner, where I can select one or more commits and drop them onto a commit in the graph, and then it goes and magically cherry-picks-and-drops them.

:-)

Ciao,
Dscho

On Thu, May 28, 2015 at 10:06 AM, Johannes Schindelin
[off-list ref] wrote:

Hi Stefan,

On 2015-05-27 23:47, Stefan Beller wrote:

quoted

On Wed, May 27, 2015 at 1:35 PM, Junio C Hamano [off-list ref] wrote:
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.

Oh, is it wish-anything time? *claps-his-hands*

Maybe my wording was bad, sorry about that.
I think throwing around ideas (which are closely related to what
is trying to be accomplished here IMHO) is not necessarily bad,
but the exchange of ideas helps in understanding the issue better
("I like your idea as I have not thought about it that way.", "What about
use case X", Your idea is nuts because Y")

I would wish for a graphical tool which visualizes the commit graph in a
visually pleasing manner, where I can select one or more commits and drop
them onto a commit in the graph, and then it goes and magically cherry-picks-and-drops them.

Drag and Drop, I get it. ;)

Additionally, if dropped on an unnamed branch, it should come up with
a reasonable
new branch name.

:-)

Ciao,
Dscho