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

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

Stefan Beller <sbeller@google.com> writes:

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

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

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.

On Wed, Mar 16, 2016 at 3:51 PM, Junio C Hamano <gitster@pobox.com> wrote:

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.

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.

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?

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.

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.

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.

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

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

Stefan Beller <sbeller@google.com> writes:

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.

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.

Stefan Beller <sbeller@google.com> writes:

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(+)