git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* Aborting git rebase --edit-todo
@ 2020-09-03  9:39 Victor Toni
  2020-09-03 17:43 ` Junio C Hamano
  0 siblings, 1 reply; 14+ messages in thread
From: Victor Toni @ 2020-09-03  9:39 UTC (permalink / raw)
  To: git

When doing a commit or choosing what to do for an interactive rebase
one can just wipe the whole content of the editor, save and close to
abort the action.
While doing a `git rebase --edit-todo` I came to the conclusion that I
would like to abort the edit and did the same. The final `git rebase
--continue` got me rid of the rest of the commits...
(Fortunately the "missing" commits could be rescued by looking into
`.git/logs/HEAD` so thumbs up for that. )
Unfortunately the behaviour of `--edit-todo` was a bit surprising and
somehow doesn't feel consistent with the other actions involving an
editor.

Can this be considered a bug?

Best regards,
Victor

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03  9:39 Aborting git rebase --edit-todo Victor Toni
@ 2020-09-03 17:43 ` Junio C Hamano
  2020-09-03 18:55   ` Carlo Arenas
                     ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Junio C Hamano @ 2020-09-03 17:43 UTC (permalink / raw)
  To: Victor Toni; +Cc: git, Johannes Schindelin

Victor Toni <victor.toni@gmail.com> writes:

> When doing a commit or choosing what to do for an interactive rebase
> one can just wipe the whole content of the editor, save and close to
> abort the action.
> While doing a `git rebase --edit-todo` I came to the conclusion that I
> would like to abort the edit and did the same. The final `git rebase
> --continue` got me rid of the rest of the commits...
> (Fortunately the "missing" commits could be rescued by looking into
> `.git/logs/HEAD` so thumbs up for that. )
> Unfortunately the behaviour of `--edit-todo` was a bit surprising and
> somehow doesn't feel consistent with the other actions involving an
> editor.
>
> Can this be considered a bug?

It is rather unusual (or almost always wrong) to have a totally
empty commit log or initial todo list, so it is understandable for
Git in these situations to stop without doing anything further.

There is no other sensible interpretations of what you are telling
Git to you by returning an empty buffer---it is extremely unlikely
you want to create a commit with no log message (without explicitly
allowing it with --allow-empty-message, the command is likely to
fail anyway), and it is extremely unlikely that you wanted to just
reset the tip of the branch to the --onto commit.

Once an interactive rebase session has started and you are given the
remainder of the steps to edit and you give an empty buffer back,
however, there are two possible interpretations that are equally
sensible, I would think.

 - One is that you are signaling that you are done with the rebase
   session and all the remaining commits are to be discarded.  

 - The other is that you botched editing the todo list, and you wish
   Git to give you another chance to edit it again.

I think the implementor chose the first interpretation.  The "drop"
insn is a relatively recent invention, and back when it was missing
from the vocabulary, I do not think it was possible to say " discard
all the rest" without emptying the todo list, so that design is
understandable.

Now we have the "drop" verb, the latter interpretation becomes
possible without making it impossible for the user to express the
former.  It might be a good idea to

 (1) save away the original before allowing --edit-todo to edit,

 (2) open the editor, and

 (3) when getting an empty buffer back, go back to step (2) using
     the back-up made in step (1).

Either way, the todo list editor buffer can have additional comment
instructing what happens when the buffer is emptied.

I have no strong opinion on this one myself.  Deferring to Dscho,
who may have a lot more to say on the design issue around this
feature than I do.

Thanks.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03 17:43 ` Junio C Hamano
@ 2020-09-03 18:55   ` Carlo Arenas
  2020-09-03 19:22     ` Victor Toni
  2020-09-03 19:32   ` Victor Toni
  2020-09-04  5:32   ` Johannes Schindelin
  2 siblings, 1 reply; 14+ messages in thread
From: Carlo Arenas @ 2020-09-03 18:55 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Victor Toni, git, Johannes Schindelin

On Thu, Sep 3, 2020 at 10:47 AM Junio C Hamano <gitster@pobox.com> wrote:

> Now we have the "drop" verb, the latter interpretation becomes
> possible without making it impossible for the user to express the
> former.

and for people that would like to enforce the use of the drop verb
there is configuration that prevents deleted lines to "silently"
dropping commits since 5a5445d878 (rebase-interactive: warn if commit
is dropped with `rebase --edit-todo', 2020-01-28) :

  rebase.missingCommitsCheck

AFAIK the correct "signal" to abort is to instruct your editor to exit
with non zero (ex: in vi using <esc>:cq), but agree it could be
confusing or "inconsistent" and might be worth adding it a message at
the footer

Carlo

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03 18:55   ` Carlo Arenas
@ 2020-09-03 19:22     ` Victor Toni
  2020-09-03 20:02       ` Junio C Hamano
  0 siblings, 1 reply; 14+ messages in thread
From: Victor Toni @ 2020-09-03 19:22 UTC (permalink / raw)
  To: Carlo Arenas; +Cc: Junio C Hamano, git, Johannes Schindelin

> > Now we have the "drop" verb, the latter interpretation becomes
> > possible without making it impossible for the user to express the
> > former.
>
> and for people that would like to enforce the use of the drop verb
> there is configuration that prevents deleted lines to "silently"
> dropping commits since 5a5445d878 (rebase-interactive: warn if commit
> is dropped with `rebase --edit-todo', 2020-01-28) :
>
>   rebase.missingCommitsCheck
>

Didn't know about that one, will add it right away to my .gitconfig. Thanks.

> AFAIK the correct "signal" to abort is to instruct your editor to exit
> with non zero (ex: in vi using <esc>:cq), but agree it could be
> confusing or "inconsistent" and might be worth adding it a message at
> the footer
>

This sounds easier than it might be. On some machines I have (Git for)
Windows and use a "regular" text editor which I guess I would have to
kill to make it exit in a way to be recognized by git.
Even when using Linux I never needed to make my editor exit with a non
zero code. From a coding perspective this might work, from a usability
perspective I really don't like it.

Victor

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03 17:43 ` Junio C Hamano
  2020-09-03 18:55   ` Carlo Arenas
@ 2020-09-03 19:32   ` Victor Toni
  2020-09-03 19:59     ` Carlo Arenas
                       ` (2 more replies)
  2020-09-04  5:32   ` Johannes Schindelin
  2 siblings, 3 replies; 14+ messages in thread
From: Victor Toni @ 2020-09-03 19:32 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Schindelin

> It is rather unusual (or almost always wrong) to have a totally
> empty commit log or initial todo list, so it is understandable for
> Git in these situations to stop without doing anything further.
>
> There is no other sensible interpretations of what you are telling
> Git to you by returning an empty buffer---it is extremely unlikely
> you want to create a commit with no log message (without explicitly
> allowing it with --allow-empty-message, the command is likely to
> fail anyway), and it is extremely unlikely that you wanted to just
> reset the tip of the branch to the --onto commit.
>
> Once an interactive rebase session has started and you are given the
> remainder of the steps to edit and you give an empty buffer back,
> however, there are two possible interpretations that are equally
> sensible, I would think.
>
>  - One is that you are signaling that you are done with the rebase
>    session and all the remaining commits are to be discarded.
>
>  - The other is that you botched editing the todo list, and you wish
>    Git to give you another chance to edit it again.
>
> I think the implementor chose the first interpretation.  The "drop"
> insn is a relatively recent invention, and back when it was missing
> from the vocabulary, I do not think it was possible to say " discard
> all the rest" without emptying the todo list, so that design is
> understandable.
>
> Now we have the "drop" verb, the latter interpretation becomes
> possible without making it impossible for the user to express the
> former.  It might be a good idea to
>
>  (1) save away the original before allowing --edit-todo to edit,
>
>  (2) open the editor, and
>
>  (3) when getting an empty buffer back, go back to step (2) using
>      the back-up made in step (1).
>
> Either way, the todo list editor buffer can have additional comment
> instructing what happens when the buffer is emptied.
>

Personally I would like to see your approach (1,2,3) implemented
because it is not destructive. If the user wants to achieve something
different he can retry.
Option / interpretation a)

>  - One is that you are signaling that you are done with the rebase
>    session and all the remaining commits are to be discarded.

is more difficult to recover from. (I'm still thankful for `.git/logs/HEAD`)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03 19:32   ` Victor Toni
@ 2020-09-03 19:59     ` Carlo Arenas
  2020-09-03 21:07       ` Victor Toni
  2020-09-03 21:08     ` Junio C Hamano
  2020-09-04  5:42     ` Johannes Schindelin
  2 siblings, 1 reply; 14+ messages in thread
From: Carlo Arenas @ 2020-09-03 19:59 UTC (permalink / raw)
  To: Victor Toni; +Cc: Junio C Hamano, git, Johannes Schindelin

On Thu, Sep 3, 2020 at 12:36 PM Victor Toni <victor.toni@gmail.com> wrote:
>
> is more difficult to recover from. (I'm still thankful for `.git/logs/HEAD`)

another command that might not be that well known and that will always
recover from a botched merge (or a rebase in this case) :

  $ git reset --hard ORIG_HEAD

Carlo

PS. `git reflog` might be also interesting; sorry if going slightly off topic

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03 19:22     ` Victor Toni
@ 2020-09-03 20:02       ` Junio C Hamano
  0 siblings, 0 replies; 14+ messages in thread
From: Junio C Hamano @ 2020-09-03 20:02 UTC (permalink / raw)
  To: Victor Toni; +Cc: Carlo Arenas, git, Johannes Schindelin

Victor Toni <victor.toni@gmail.com> writes:

> Even when using Linux I never needed to make my editor exit with a non
> zero code. From a coding perspective this might work, from a usability
> perspective I really don't like it.

I do not use --edit-todo myself so personally I do not care that
deeply either way, but I have to agree that it is not the most
natural UI to make your editor to exit with non-zero status to
signal something to the program that opened the editor.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03 19:59     ` Carlo Arenas
@ 2020-09-03 21:07       ` Victor Toni
  0 siblings, 0 replies; 14+ messages in thread
From: Victor Toni @ 2020-09-03 21:07 UTC (permalink / raw)
  To: Carlo Arenas; +Cc: Junio C Hamano, git, Johannes Schindelin

On Do., 3. Sept. 2020 um 21:59 Uhr schrieb Carlo Arenas <carenas@gmail.com>:
>
> On Thu, Sep 3, 2020 at 12:36 PM Victor Toni <victor.toni@gmail.com> wrote:
> >
> > is more difficult to recover from. (I'm still thankful for `.git/logs/HEAD`)
>
> another command that might not be that well known and that will always
> recover from a botched merge (or a rebase in this case) :
>
>   $ git reset --hard ORIG_HEAD
>
I tried it on a backup copy of my repository (created directly after
the "incident").
Unfortunately it would have missed two commits.

> PS. `git reflog` might be also interesting; sorry if going slightly off topic

Thanks for that. Never used it before. git reflog would have helped
directly since it shows the last real commit I did before messing
things up.
From there it's a walk in the park.

Victor

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03 19:32   ` Victor Toni
  2020-09-03 19:59     ` Carlo Arenas
@ 2020-09-03 21:08     ` Junio C Hamano
  2020-09-03 21:21       ` Victor Toni
  2020-09-04  5:42     ` Johannes Schindelin
  2 siblings, 1 reply; 14+ messages in thread
From: Junio C Hamano @ 2020-09-03 21:08 UTC (permalink / raw)
  To: Victor Toni; +Cc: git, Johannes Schindelin

Victor Toni <victor.toni@gmail.com> writes:

>> I think the implementor chose the first interpretation.  The "drop"
>> insn is a relatively recent invention, and back when it was missing
>> from the vocabulary, I do not think it was possible to say " discard
>> all the rest" without emptying the todo list, so that design is
>> understandable.
>>
>> Now we have the "drop" verb, the latter interpretation becomes
>> possible without making it impossible for the user to express the
>> former.  It might be a good idea to
>>
>>  (1) save away the original before allowing --edit-todo to edit,
>>
>>  (2) open the editor, and
>>
>>  (3) when getting an empty buffer back, go back to step (2) using
>>      the back-up made in step (1).
>>
>> Either way, the todo list editor buffer can have additional comment
>> instructing what happens when the buffer is emptied.
>>
> Personally I would like to see your approach (1,2,3) implemented
> because it is not destructive. If the user wants to achieve something
> different he can retry.

Obviously I agree that the approach would be nicer than the status
quo.  It would not be as trivial as a microproject, but would be a
good bite-sized starter-task for those aspiring developers who want
to dip their toes in the water to start hacking on the codebase ;-)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03 21:08     ` Junio C Hamano
@ 2020-09-03 21:21       ` Victor Toni
  2020-09-04  5:43         ` Johannes Schindelin
  2020-09-06 21:52         ` Junio C Hamano
  0 siblings, 2 replies; 14+ messages in thread
From: Victor Toni @ 2020-09-03 21:21 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Schindelin

Junio C Hamano <gitster@pobox.com> writes:
>
> Victor Toni <victor.toni@gmail.com> writes:
>
> >> I think the implementor chose the first interpretation.  The "drop"
> >> insn is a relatively recent invention, and back when it was missing
> >> from the vocabulary, I do not think it was possible to say " discard
> >> all the rest" without emptying the todo list, so that design is
> >> understandable.
> >>
> >> Now we have the "drop" verb, the latter interpretation becomes
> >> possible without making it impossible for the user to express the
> >> former.  It might be a good idea to
> >>
> >>  (1) save away the original before allowing --edit-todo to edit,
> >>
> >>  (2) open the editor, and
> >>
> >>  (3) when getting an empty buffer back, go back to step (2) using
> >>      the back-up made in step (1).
> >>
> >> Either way, the todo list editor buffer can have additional comment
> >> instructing what happens when the buffer is emptied.
> >>
> > Personally I would like to see your approach (1,2,3) implemented
> > because it is not destructive. If the user wants to achieve something
> > different he can retry.
>
> Obviously I agree that the approach would be nicer than the status
> quo.  It would not be as trivial as a microproject, but would be a
> good bite-sized starter-task for those aspiring developers who want
> to dip their toes in the water to start hacking on the codebase ;-)
>
Nice try ;) Speaking of toes ... I'm currently involved in another
project from tip to toe.
I would like to come back to your offer sometime next year when I've
completed the other one.
Especially since I'd have to polish up my buried C skills... C didn't
get GC lately, did it? ;)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03 17:43 ` Junio C Hamano
  2020-09-03 18:55   ` Carlo Arenas
  2020-09-03 19:32   ` Victor Toni
@ 2020-09-04  5:32   ` Johannes Schindelin
  2 siblings, 0 replies; 14+ messages in thread
From: Johannes Schindelin @ 2020-09-04  5:32 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Victor Toni, git

Hi Junio & Victor,

On Thu, 3 Sep 2020, Junio C Hamano wrote:

> Victor Toni <victor.toni@gmail.com> writes:
>
> > When doing a commit or choosing what to do for an interactive rebase
> > one can just wipe the whole content of the editor, save and close to
> > abort the action.
> > While doing a `git rebase --edit-todo` I came to the conclusion that I
> > would like to abort the edit and did the same. The final `git rebase
> > --continue` got me rid of the rest of the commits...
> > (Fortunately the "missing" commits could be rescued by looking into
> > `.git/logs/HEAD` so thumbs up for that. )
> > Unfortunately the behaviour of `--edit-todo` was a bit surprising and
> > somehow doesn't feel consistent with the other actions involving an
> > editor.
> >
> > Can this be considered a bug?
>
> It is rather unusual (or almost always wrong) to have a totally
> empty commit log or initial todo list, so it is understandable for
> Git in these situations to stop without doing anything further.
>
> There is no other sensible interpretations of what you are telling
> Git to you by returning an empty buffer---it is extremely unlikely
> you want to create a commit with no log message (without explicitly
> allowing it with --allow-empty-message, the command is likely to
> fail anyway), and it is extremely unlikely that you wanted to just
> reset the tip of the branch to the --onto commit.
>
> Once an interactive rebase session has started and you are given the
> remainder of the steps to edit and you give an empty buffer back,
> however, there are two possible interpretations that are equally
> sensible, I would think.
>
>  - One is that you are signaling that you are done with the rebase
>    session and all the remaining commits are to be discarded.
>
>  - The other is that you botched editing the todo list, and you wish
>    Git to give you another chance to edit it again.
>
> I think the implementor chose the first interpretation.  The "drop"
> insn is a relatively recent invention, and back when it was missing
> from the vocabulary, I do not think it was possible to say " discard
> all the rest" without emptying the todo list, so that design is
> understandable.
>
> Now we have the "drop" verb, the latter interpretation becomes
> possible without making it impossible for the user to express the
> former.  It might be a good idea to
>
>  (1) save away the original before allowing --edit-todo to edit,
>
>  (2) open the editor, and
>
>  (3) when getting an empty buffer back, go back to step (2) using
>      the back-up made in step (1).
>
> Either way, the todo list editor buffer can have additional comment
> instructing what happens when the buffer is emptied.
>
> I have no strong opinion on this one myself.  Deferring to Dscho,
> who may have a lot more to say on the design issue around this
> feature than I do.

First of all, some historical background: the idea that deleting
everything in the todo list aborts the rebase *predates* `git rebase
--edit-todo` by quite a bit, in fact, that idea was implemented in either
the very first version of `git rebase -i` or at least very, very short
thereafter.

This idea came from the fact that deleting the commit message would abort
a `git commit`.

In the meantime, `--edit-todo` is a thing (where this behavior makes a lot
less sense), and `drop` is also a thing.

I agree that it may be a good time to deprecate that behavior, after
introducing a new verb `abort` or something like that.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03 19:32   ` Victor Toni
  2020-09-03 19:59     ` Carlo Arenas
  2020-09-03 21:08     ` Junio C Hamano
@ 2020-09-04  5:42     ` Johannes Schindelin
  2 siblings, 0 replies; 14+ messages in thread
From: Johannes Schindelin @ 2020-09-04  5:42 UTC (permalink / raw)
  To: Victor Toni; +Cc: Junio C Hamano, git

Hi Victor,

On Thu, 3 Sep 2020, Victor Toni wrote:

> > It is rather unusual (or almost always wrong) to have a totally
> > empty commit log or initial todo list, so it is understandable for
> > Git in these situations to stop without doing anything further.
> >
> > There is no other sensible interpretations of what you are telling
> > Git to you by returning an empty buffer---it is extremely unlikely
> > you want to create a commit with no log message (without explicitly
> > allowing it with --allow-empty-message, the command is likely to
> > fail anyway), and it is extremely unlikely that you wanted to just
> > reset the tip of the branch to the --onto commit.
> >
> > Once an interactive rebase session has started and you are given the
> > remainder of the steps to edit and you give an empty buffer back,
> > however, there are two possible interpretations that are equally
> > sensible, I would think.
> >
> >  - One is that you are signaling that you are done with the rebase
> >    session and all the remaining commits are to be discarded.
> >
> >  - The other is that you botched editing the todo list, and you wish
> >    Git to give you another chance to edit it again.
> >
> > I think the implementor chose the first interpretation.  The "drop"
> > insn is a relatively recent invention, and back when it was missing
> > from the vocabulary, I do not think it was possible to say " discard
> > all the rest" without emptying the todo list, so that design is
> > understandable.
> >
> > Now we have the "drop" verb, the latter interpretation becomes
> > possible without making it impossible for the user to express the
> > former.  It might be a good idea to
> >
> >  (1) save away the original before allowing --edit-todo to edit,

We already do that:
https://github.com/git/git/blob/v2.28.0/rebase-interactive.c#L113-L115

> >
> >  (2) open the editor, and
> >
> >  (3) when getting an empty buffer back, go back to step (2) using
> >      the back-up made in step (1).

Yes, and we can claim that this is a bug fix to avoid having to respect a
deprecation phase.

> >
> > Either way, the todo list editor buffer can have additional comment
> > instructing what happens when the buffer is emptied.
> >
>
> Personally I would like to see your approach (1,2,3) implemented
> because it is not destructive. If the user wants to achieve something
> different he

or she, or they,

> can retry.
> Option / interpretation a)
>
> >  - One is that you are signaling that you are done with the rebase
> >    session and all the remaining commits are to be discarded.
>
> is more difficult to recover from. (I'm still thankful for `.git/logs/HEAD`)

Indeed, it is pretty tedious to recover from when you can originally made
edits to the todo list that you then accidentally discarded.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03 21:21       ` Victor Toni
@ 2020-09-04  5:43         ` Johannes Schindelin
  2020-09-06 21:52         ` Junio C Hamano
  1 sibling, 0 replies; 14+ messages in thread
From: Johannes Schindelin @ 2020-09-04  5:43 UTC (permalink / raw)
  To: Victor Toni; +Cc: Junio C Hamano, git

Hi Victor,

On Thu, 3 Sep 2020, Victor Toni wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> >
> > Victor Toni <victor.toni@gmail.com> writes:
> >
> > >> I think the implementor chose the first interpretation.  The "drop"
> > >> insn is a relatively recent invention, and back when it was missing
> > >> from the vocabulary, I do not think it was possible to say " discard
> > >> all the rest" without emptying the todo list, so that design is
> > >> understandable.
> > >>
> > >> Now we have the "drop" verb, the latter interpretation becomes
> > >> possible without making it impossible for the user to express the
> > >> former.  It might be a good idea to
> > >>
> > >>  (1) save away the original before allowing --edit-todo to edit,
> > >>
> > >>  (2) open the editor, and
> > >>
> > >>  (3) when getting an empty buffer back, go back to step (2) using
> > >>      the back-up made in step (1).
> > >>
> > >> Either way, the todo list editor buffer can have additional comment
> > >> instructing what happens when the buffer is emptied.
> > >>
> > > Personally I would like to see your approach (1,2,3) implemented
> > > because it is not destructive. If the user wants to achieve something
> > > different he can retry.
> >
> > Obviously I agree that the approach would be nicer than the status
> > quo.  It would not be as trivial as a microproject, but would be a
> > good bite-sized starter-task for those aspiring developers who want
> > to dip their toes in the water to start hacking on the codebase ;-)
> >
> Nice try ;) Speaking of toes ... I'm currently involved in another
> project from tip to toe.
> I would like to come back to your offer sometime next year when I've
> completed the other one.

Sure. I expect this project to wait quite patiently for you to come back
next year ;-)

Ciao,
Dscho

> Especially since I'd have to polish up my buried C skills... C didn't
> get GC lately, did it? ;)
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Aborting git rebase --edit-todo
  2020-09-03 21:21       ` Victor Toni
  2020-09-04  5:43         ` Johannes Schindelin
@ 2020-09-06 21:52         ` Junio C Hamano
  1 sibling, 0 replies; 14+ messages in thread
From: Junio C Hamano @ 2020-09-06 21:52 UTC (permalink / raw)
  To: Victor Toni; +Cc: git, Johannes Schindelin

Victor Toni <victor.toni@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>>
>> Victor Toni <victor.toni@gmail.com> writes:
>>
>> > Personally I would like to see your approach (1,2,3) implemented
>> > because it is not destructive. If the user wants to achieve something
>> > different he can retry.
>>
>> Obviously I agree that the approach would be nicer than the status
>> quo.  It would not be as trivial as a microproject, but would be a
>> good bite-sized starter-task for those aspiring developers who want
>> to dip their toes in the water to start hacking on the codebase ;-)
>>
> Nice try ;)

For the record I didn't try _you_.

I was writing for general audience, among which there are aspiring
developers seeking a starter-task.  Whether you are part of that
audience was immaterial (even though it would have been nice if you
were) ;-).

Thanks.




^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2020-09-06 21:52 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-03  9:39 Aborting git rebase --edit-todo Victor Toni
2020-09-03 17:43 ` Junio C Hamano
2020-09-03 18:55   ` Carlo Arenas
2020-09-03 19:22     ` Victor Toni
2020-09-03 20:02       ` Junio C Hamano
2020-09-03 19:32   ` Victor Toni
2020-09-03 19:59     ` Carlo Arenas
2020-09-03 21:07       ` Victor Toni
2020-09-03 21:08     ` Junio C Hamano
2020-09-03 21:21       ` Victor Toni
2020-09-04  5:43         ` Johannes Schindelin
2020-09-06 21:52         ` Junio C Hamano
2020-09-04  5:42     ` Johannes Schindelin
2020-09-04  5:32   ` Johannes Schindelin

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git