{"thread":{"id":"41718","subject":"An idea for the \"Leftover Bits\": rebase -x to imply -i","startedAt":"2016-03-16T21:12:39Z","lastAt":"2016-03-17T07:31:34Z","messageCount":6,"participants":["Stefan Beller","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"280965","messageId":"CAGZ79kZg3QkfjB1hwZKRS9Hqg-1H=kQwuwByX_rAMzveXtnp7Q@mail.gmail.com","threadId":"41718","inReplyTo":null,"subject":"An idea for the \"Leftover Bits\": rebase -x to imply -i","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-03-16T21:12:39Z","receivedAt":"2016-03-16T21:12:39Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"Hi Junio,\n\nhere is an additional ideas for the \"Leftover Bits\" on git-blame.blogspot.com\n(Is there another way of contributing these, such as sending a patch\nagainst some\nrepository? Or any other way which may bother you less?)\n\n* \"rebase -exec\" requiries to be an explicit interactive rebase (i.e.\n--interactive was given)\n Could --exec just imply --interactive with a no-op editor? If so\nwrite a patch for it;\n if not, document the reason in the man page at the --exec option.\n\nThanks,\nStefan\n"},{"id":"280981","messageId":"xmqqy49i2hhe.fsf@gitster.mtv.corp.google.com","threadId":"41718","inReplyTo":"CAGZ79kZg3QkfjB1hwZKRS9Hqg-1H=kQwuwByX_rAMzveXtnp7Q@mail.gmail.com","subject":"Re: An idea for the \"Leftover Bits\": rebase -x to imply -i","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-16T22:19:41Z","receivedAt":"2016-03-16T22:19:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> here is an additional ideas for the \"Leftover Bits\" on git-blame.blogspot.com\n> (Is there another way of contributing these, such as sending a patch\n> against some\n> repository? Or any other way which may bother you less?)\n\nA message \"Subject: [RFC] ...\" that asks \"Wouldn't it be wonderful\nif command X is extended to work like this way?\", without even\nmentioning \"leftover bits\", would be far more useful. Instead of\ngoing nowhere waiting for the next round of \"leftover sweep\" picks\nit up to add it to my \"leftover bits\" list, it may even find a\ntraction here ;-).\n\nThe list is my personal collection of \"leftover\" things, i.e. topics\nthat were raised on the list, perhaps already discussed or perhaps\nnobody thought them interesting, that I found when re-reading the\npast list traffic that did not reach a useful conclusion to result\nin a patch (or resolution, a shared understanding, that it is not a\ngood idea). Getting added to the list should not be a goal.\n\nYour message is perhaps the least effective way to add an item to\nthe list. It hasn't been discussed here, nobody seems to have felt\nit is a good idea, and I didn't think it is particularly interesting\nmyself (at least not yet).\n"},{"id":"280982","messageId":"xmqqpouu2guc.fsf@gitster.mtv.corp.google.com","threadId":"41718","inReplyTo":"CAGZ79kZg3QkfjB1hwZKRS9Hqg-1H=kQwuwByX_rAMzveXtnp7Q@mail.gmail.com","subject":"Re: An idea for the \"Leftover Bits\": rebase -x to imply -i","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-16T22:33:31Z","receivedAt":"2016-03-16T22:33:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> * \"rebase -exec\" requiries to be an explicit interactive rebase (i.e.\n> --interactive was given)\n> Could --exec just imply --interactive with a no-op editor?\n\nPerhaps like this? You have to defend the change with a good\ndescription, have to protect the new behaviour with a new test from\nfuture breakages, and may have to adjust existing tests if they are\nexpecting the current behaviour (I didn't test).\n\n git-rebase.sh | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex cf60c43..c68baa0 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -248,6 +248,7 @@ do\n \t\t;;\n \t--exec=*)\n \t\tcmd=\"${cmd}exec ${1#--exec=}${LF}\"\n+\t\tinteractive_rebase=explicit\n \t\t;;\n \t--interactive)\n \t\tinteractive_rebase=explicit\n"},{"id":"280984","messageId":"xmqqlh5i2g0y.fsf@gitster.mtv.corp.google.com","threadId":"41718","inReplyTo":"xmqqy49i2hhe.fsf@gitster.mtv.corp.google.com","subject":"Re: An idea for the \"Leftover Bits\": rebase -x to imply -i","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-16T22:51:09Z","receivedAt":"2016-03-16T22:51:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> The list is my personal collection of \"leftover\" things, i.e. topics\n> that were raised on the list, perhaps already discussed or perhaps\n> nobody thought them interesting, that I found when re-reading the\n> past list traffic that did not reach a useful conclusion to result\n> in a patch (or resolution, a shared understanding, that it is not a\n> good idea). Getting added to the list should not be a goal.\n>\n> Your message is perhaps the least effective way to add an item to\n> the list. It hasn't been discussed here, nobody seems to have felt\n> it is a good idea, and I didn't think it is particularly interesting\n> myself (at least not yet).\n\nHaving said that, I could use help in maintaining the collection.\n\nA few \"characteristics\" of that list, that cannot be updated by\nanybody but me (because it is just my personal collection after all)\nare:\n\n * I do not have to worry about useless new entries that do not\n align the overall system design getting added by clueless people.\n\n * Adding new entry after scanning past list traffic and finding a\n still unresolved topic that \"died down\" is relatively easy.\n\n * Removing existing entries because the topic was revived on the\n list and completed is _hard_, as that is merely an administrative\n overhead to me.\n\nMoving it to a public wiki would lose the first point, which is a\nbenefit.\n\nMerely making it public does not guarantee that the third point\n(i.e. clean-up) would happen more easily unless we have volunteers.\nIt is likely that the \"leftover bits\" list would go stale just like\nother people's wikis or bug trackers.\n\nOn the other hand, if we do have volunteers who are scanning for\n\"stale\" items in the \"leftover bits\" list to tell me \"that item was\ndone with commit c0ffee1eaf\" and that would help me quite a bit\nwithout being it a public wiki/bug tracker.\n"},{"id":"280986","messageId":"CAGZ79kZC0AAz=cm59ys1L_Axj1_HLvcTqrMrfNrOHoA3Ef7a5A@mail.gmail.com","threadId":"41718","inReplyTo":"xmqqlh5i2g0y.fsf@gitster.mtv.corp.google.com","subject":"Re: An idea for the \"Leftover Bits\": rebase -x to imply -i","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-03-16T23:18:10Z","receivedAt":"2016-03-16T23:18:10Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Mar 16, 2016 at 3:51 PM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> The list is my personal collection of \"leftover\" things, i.e. topics\n>> that were raised on the list, perhaps already discussed or perhaps\n>> nobody thought them interesting, that I found when re-reading the\n>> past list traffic that did not reach a useful conclusion to result\n>> in a patch (or resolution, a shared understanding, that it is not a\n>> good idea). Getting added to the list should not be a goal.\n\nWell it was my goal partially at least. I tripped over that behavior and found\nit strange to error out instead of just implying the interactive mode.\n\nSo I thought I had found a small wart in the UI, which can easily be fixed.\nBut I had no intention to fix it myself as I do not intent to trip over that\nbehavior again. This may be a good beginner project similar\nto the GSoC micro projects which are partially taken from the left\nover bits, so my mental shortcut was to get it added such that it\ncomes up again next year as micro project.\n\nNow that you proposed the code (and me having rewritten\nthe tests, I only need to find a convincing commit message), I\ncan take ownership of this issue.\n\n>>\n>> Your message is perhaps the least effective way to add an item to\n>> the list. It hasn't been discussed here, nobody seems to have felt\n>> it is a good idea, and I didn't think it is particularly interesting\n>> myself (at least not yet).\n\nI did not find it interesting for *me* as well (I don't need that problem\nsolved by tonight nor tomorrow); It is just a nice beginners project,\nand your leftover bits are the only collection for general Git that I\nknow of. Other people may have private notes somewhere, but\nI am too messy and chaotic to have these notes in a year when\nwe'd need this potential idea.\n\n>\n> Having said that, I could use help in maintaining the collection.\n>\n> A few \"characteristics\" of that list, that cannot be updated by\n> anybody but me (because it is just my personal collection after all)\n> are:\n>\n> * I do not have to worry about useless new entries that do not\n> align the overall system design getting added by clueless people.\n\nAs it is your personall collection and you're the maintainer, I thought\nof this as a collection with maintainers blessing, i.e. if the code&tests\nare not too shoddy a patch will get accepted (read as: On that list there\nare no bullet points with fundamental design issues). Why would you\nadd things to that list if you'd not agree with them?\n\n>\n> * Adding new entry after scanning past list traffic and finding a\n> still unresolved topic that \"died down\" is relatively easy.\n\nAs the notes in Documentation/howto/maintain-git.txt indicate, you're\nscanning the list anyway, so offering help in this point may be moot.\n\n>\n> * Removing existing entries because the topic was revived on the\n> list and completed is _hard_, as that is merely an administrative\n> overhead to me.\n\nThis may be solved by having this list as part of git.git in an ideas/\ndirectory. The closer the reported issue is to the actual code, the higher\nthe chances that they are kept in sync, I'd assume. This is similar to\nthe discussion we had about a year ago, where to document methods.\n(Documentation/technical vs in header files). Another example would\nbe the NEEDSWORK comments which are best kept as close to the\noffending code as well.\n\n>\n> Moving it to a public wiki would lose the first point, which is a\n> benefit.\n\nI would have assumed this is the opposite, i.e. By having a public\nwiki, you cannot assume any idea is valid and thoughtful. You would\nneed a lot more reasoning, why an idea is good and lots of text may\nmake that wiki unclear. A potential contributor would need to filter through\na lot of (outdated) text.\n\n>\n> Merely making it public does not guarantee that the third point\n> (i.e. clean-up) would happen more easily unless we have volunteers.\n> It is likely that the \"leftover bits\" list would go stale just like\n> other people's wikis or bug trackers.\n\nI see. By having ownership, you offer a certain quality of that list\nas your name is attached to it.\n\n>\n> On the other hand, if we do have volunteers who are scanning for\n> \"stale\" items in the \"leftover bits\" list to tell me \"that item was\n> done with commit c0ffee1eaf\" and that would help me quite a bit\n> without being it a public wiki/bug tracker.\n\nOk, that is an actionable item I can follow up on. I'll try to check that list\nregularly pointing out stale entrees.\n\nThanks for the explanation/thoughts,\nStefan\n\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"281008","messageId":"xmqqbn6d36i1.fsf@gitster.mtv.corp.google.com","threadId":"41718","inReplyTo":"CAGZ79kZC0AAz=cm59ys1L_Axj1_HLvcTqrMrfNrOHoA3Ef7a5A@mail.gmail.com","subject":"Re: An idea for the \"Leftover Bits\": rebase -x to imply -i","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-17T07:31:34Z","receivedAt":"2016-03-17T07:31:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> On Wed, Mar 16, 2016 at 3:51 PM, Junio C Hamano wrote:\n>\n>> A few \"characteristics\" of that list, that cannot be updated by\n>> anybody but me (because it is just my personal collection after all)\n>> are:\n>>\n>> * I do not have to worry about useless new entries that do not\n>> align the overall system design getting added by clueless people.\n>\n> As it is your personall collection and you're the maintainer, I thought\n> of this as a collection with maintainers blessing, i.e. if the code&tests\n> are not too shoddy a patch will get accepted (read as: On that list there\n> are no bullet points with fundamental design issues). Why would you\n> add things to that list if you'd not agree with them?\n\nIf it was not clear, I didn't mean these three are all bad things.\nIn fact, this first of the three \"characteristics\" is a good thing.\nRandom people are not allowed to throw random things into it.\n\n>> * Adding new entry after scanning past list traffic and finding a\n>> still unresolved topic that \"died down\" is relatively easy.\n>\n> As the notes in Documentation/howto/maintain-git.txt indicate, you're\n> scanning the list anyway, so offering help in this point may be moot.\n\nThe scanning of the list for new topics (to further discuss and pick\npatches to queue) and the scanning of the list for \"died down\"\nthreads are two completely separate activities. If somebody with\ngood taste can do the latter when I am too busy elsewhere by\npointing out \"what happened to this thread? It seems that nobody is\ninterested enough to pursue it right now, so perhaps it is a good\ntime to add it to 'leftover bits' list?\", that would be helpful.\n\nAnd as you agreed, pointing out \"done\" items to remove would also be\nhelpful.\n\nThanks.\n"}]}