An idea for the "Leftover Bits": rebase -x to imply -i

An idea for the "Leftover Bits": rebase -x to imply -i

[Stefan Beller]

Hi Junio,

here is an additional ideas for the "Leftover Bits" on git-blame.blogspot.com
(Is there another way of contributing these, such as sending a patch
against some
repository? Or any other way which may bother you less?)

* "rebase -exec" requiries to be an explicit interactive rebase (i.e.
--interactive was given)
  Could --exec just imply --interactive with a no-op editor? If so
write a patch for it;
  if not, document the reason in the man page at the --exec option.

Thanks,
Stefan

Re: An idea for the "Leftover Bits": rebase -x to imply -i

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> here is an additional ideas for the "Leftover Bits" on git-blame.blogspot.com
> (Is there another way of contributing these, such as sending a patch
> against some
> repository? Or any other way which may bother you less?)

A message "Subject: [RFC] ..." that asks "Wouldn't it be wonderful
if command X is extended to work like this way?", without even
mentioning "leftover bits", would be far more useful.  Instead of
going nowhere waiting for the next round of "leftover sweep" picks
it up to add it to my "leftover bits" list, it may even find a
traction here ;-).

The list is my personal collection of "leftover" things, i.e. topics
that were raised on the list, perhaps already discussed or perhaps
nobody thought them interesting, that I found when re-reading the
past list traffic that did not reach a useful conclusion to result
in a patch (or resolution, a shared understanding, that it is not a
good idea).  Getting added to the list should not be a goal.

Your message is perhaps the least effective way to add an item to
the list.  It hasn't been discussed here, nobody seems to have felt
it is a good idea, and I didn't think it is particularly interesting
myself (at least not yet).

Re: An idea for the "Leftover Bits": rebase -x to imply -i

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> The list is my personal collection of "leftover" things, i.e. topics
> that were raised on the list, perhaps already discussed or perhaps
> nobody thought them interesting, that I found when re-reading the
> past list traffic that did not reach a useful conclusion to result
> in a patch (or resolution, a shared understanding, that it is not a
> good idea).  Getting added to the list should not be a goal.
>
> Your message is perhaps the least effective way to add an item to
> the list.  It hasn't been discussed here, nobody seems to have felt
> it is a good idea, and I didn't think it is particularly interesting
> myself (at least not yet).

Having said that, I could use help in maintaining the collection.

A few "characteristics" of that list, that cannot be updated by
anybody but me (because it is just my personal collection after all)
are:

 * I do not have to worry about useless new entries that do not
   align the overall system design getting added by clueless people.

 * Adding new entry after scanning past list traffic and finding a
   still unresolved topic that "died down" is relatively easy.

 * Removing existing entries because the topic was revived on the
   list and completed is _hard_, as that is merely an administrative
   overhead to me.

Moving it to a public wiki would lose the first point, which is a
benefit.

Merely making it public does not guarantee that the third point
(i.e. clean-up) would happen more easily unless we have volunteers.
It is likely that the "leftover bits" list would go stale just like
other people's wikis or bug trackers.

On the other hand, if we do have volunteers who are scanning for
"stale" items in the "leftover bits" list to tell me "that item was
done with commit c0ffee1eaf" and that would help me quite a bit
without being it a public wiki/bug tracker.

Re: An idea for the "Leftover Bits": rebase -x to imply -i

[Stefan Beller]

On Wed, Mar 16, 2016 at 3:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> The list is my personal collection of "leftover" things, i.e. topics
>> that were raised on the list, perhaps already discussed or perhaps
>> nobody thought them interesting, that I found when re-reading the
>> past list traffic that did not reach a useful conclusion to result
>> in a patch (or resolution, a shared understanding, that it is not a
>> good idea).  Getting added to the list should not be a goal.

Well it was my goal partially at least. I tripped over that behavior and found
it strange to error out instead of just implying the interactive mode.

So I thought I had found a small wart in the UI, which can easily be fixed.
But I had no intention to fix it myself as I do not intent to trip over that
behavior again. This may be a good beginner project similar
to the GSoC micro projects which are partially taken from the left
over bits, so my mental shortcut was to get it added such that it
comes up again next year as micro project.

Now that you proposed the code (and me having rewritten
the tests, I only need to find a convincing commit message), I
can take ownership of this issue.

>>
>> Your message is perhaps the least effective way to add an item to
>> the list.  It hasn't been discussed here, nobody seems to have felt
>> it is a good idea, and I didn't think it is particularly interesting
>> myself (at least not yet).

I did not find it interesting for *me* as well (I don't need that problem
solved by tonight nor tomorrow); It is just a nice beginners project,
and your leftover bits are the only collection for general Git that I
know of. Other people may have private notes somewhere, but
I am too messy and chaotic to have these notes in a year when
we'd need this potential idea.

>
> Having said that, I could use help in maintaining the collection.
>
> A few "characteristics" of that list, that cannot be updated by
> anybody but me (because it is just my personal collection after all)
> are:
>
>  * I do not have to worry about useless new entries that do not
>    align the overall system design getting added by clueless people.

As it is your personall collection and you're the maintainer, I thought
of this as a collection with maintainers blessing, i.e. if the code&tests
are not too shoddy a patch will get accepted (read as: On that list there
are no bullet points with fundamental design issues). Why would you
add things to that list if you'd not agree with them?

>
>  * Adding new entry after scanning past list traffic and finding a
>    still unresolved topic that "died down" is relatively easy.

As the notes in Documentation/howto/maintain-git.txt indicate, you're
scanning the list anyway, so offering help in this point may be moot.

>
>  * Removing existing entries because the topic was revived on the
>    list and completed is _hard_, as that is merely an administrative
>    overhead to me.

This may be solved by having this list as part of git.git in an ideas/
directory. The closer the reported issue is to the actual code, the higher
the chances that they are kept in sync, I'd assume. This is similar to
the discussion we had about a year ago, where to document methods.
(Documentation/technical vs in header files). Another example would
be the NEEDSWORK comments which are best kept as close to the
offending code as well.

>
> Moving it to a public wiki would lose the first point, which is a
> benefit.

I would have assumed this is the opposite, i.e. By having a public
wiki, you cannot assume any idea is valid and thoughtful. You would
need a lot more reasoning, why an idea is good and lots of text may
make that wiki unclear. A potential contributor would need to filter through
a lot of (outdated) text.

>
> Merely making it public does not guarantee that the third point
> (i.e. clean-up) would happen more easily unless we have volunteers.
> It is likely that the "leftover bits" list would go stale just like
> other people's wikis or bug trackers.

I see. By having ownership, you offer a certain quality of that list
as your name is attached to it.

>
> On the other hand, if we do have volunteers who are scanning for
> "stale" items in the "leftover bits" list to tell me "that item was
> done with commit c0ffee1eaf" and that would help me quite a bit
> without being it a public wiki/bug tracker.

Ok, that is an actionable item I can follow up on. I'll try to check that list
regularly pointing out stale entrees.

Thanks for the explanation/thoughts,
Stefan

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

Re: An idea for the "Leftover Bits": rebase -x to imply -i

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> On Wed, Mar 16, 2016 at 3:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> A few "characteristics" of that list, that cannot be updated by
>> anybody but me (because it is just my personal collection after all)
>> are:
>>
>>  * I do not have to worry about useless new entries that do not
>>    align the overall system design getting added by clueless people.
>
> As it is your personall collection and you're the maintainer, I thought
> of this as a collection with maintainers blessing, i.e. if the code&tests
> are not too shoddy a patch will get accepted (read as: On that list there
> are no bullet points with fundamental design issues). Why would you
> add things to that list if you'd not agree with them?

If it was not clear, I didn't mean these three are all bad things.
In fact, this first of the three "characteristics" is a good thing.
Random people are not allowed to throw random things into it.

>>  * Adding new entry after scanning past list traffic and finding a
>>    still unresolved topic that "died down" is relatively easy.
>
> As the notes in Documentation/howto/maintain-git.txt indicate, you're
> scanning the list anyway, so offering help in this point may be moot.

The scanning of the list for new topics (to further discuss and pick
patches to queue) and the scanning of the list for "died down"
threads are two completely separate activities.  If somebody with
good taste can do the latter when I am too busy elsewhere by
pointing out "what happened to this thread?  It seems that nobody is
interested enough to pursue it right now, so perhaps it is a good
time to add it to 'leftover bits' list?", that would be helpful.

And as you agreed, pointing out "done" items to remove would also be
helpful.

Thanks.

Re: An idea for the "Leftover Bits": rebase -x to imply -i

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> * "rebase -exec" requiries to be an explicit interactive rebase (i.e.
>   --interactive was given)
>   Could --exec just imply --interactive with a no-op editor?

Perhaps like this?  You have to defend the change with a good
description, have to protect the new behaviour with a new test from
future breakages, and may have to adjust existing tests if they are
expecting the current behaviour (I didn't test).

 git-rebase.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/git-rebase.sh b/git-rebase.sh
index cf60c43..c68baa0 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -248,6 +248,7 @@ do
 		;;
 	--exec=*)
 		cmd="${cmd}exec ${1#--exec=}${LF}"
+		interactive_rebase=explicit
 		;;
 	--interactive)
 		interactive_rebase=explicit