# An idea for the "Leftover Bits": rebase -x to imply -i 6 messages from 2016-03-16 to 2016-03-17. Participants: Stefan Beller, Junio C Hamano. Thread: https://gitlist.dev/t/41718 ## Stefan Beller, 2016-03-16 21:12 Subject: An idea for the "Leftover Bits": rebase -x to imply -i Message-ID: URL: https://gitlist.dev/e/CAGZ79kZg3QkfjB1hwZKRS9Hqg-1H%3DkQwuwByX_rAMzveXtnp7Q%40mail.gmail.com ``` 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 ``` ## Junio C Hamano, 2016-03-16 22:19 Subject: Re: An idea for the "Leftover Bits": rebase -x to imply -i Message-ID: URL: https://gitlist.dev/e/xmqqy49i2hhe.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Stefan Beller 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). ``` ## Junio C Hamano, 2016-03-16 22:33 Subject: Re: An idea for the "Leftover Bits": rebase -x to imply -i Message-ID: URL: https://gitlist.dev/e/xmqqpouu2guc.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Stefan Beller 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 ``` ## Junio C Hamano, 2016-03-16 22:51 Subject: Re: An idea for the "Leftover Bits": rebase -x to imply -i Message-ID: URL: https://gitlist.dev/e/xmqqlh5i2g0y.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Junio C Hamano 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. ``` ## Stefan Beller, 2016-03-16 23:18 Subject: Re: An idea for the "Leftover Bits": rebase -x to imply -i Message-ID: URL: https://gitlist.dev/e/CAGZ79kZC0AAz%3Dcm59ys1L_Axj1_HLvcTqrMrfNrOHoA3Ef7a5A%40mail.gmail.com In-Reply-To: ``` On Wed, Mar 16, 2016 at 3:51 PM, Junio C Hamano wrote: > Junio C Hamano 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 ``` ## Junio C Hamano, 2016-03-17 07:31 Subject: Re: An idea for the "Leftover Bits": rebase -x to imply -i Message-ID: URL: https://gitlist.dev/e/xmqqbn6d36i1.fsf%40gitster.mtv.corp.google.com In-Reply-To: ``` Stefan Beller writes: > On Wed, Mar 16, 2016 at 3:51 PM, Junio C Hamano 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. ```