From: Phillip Wood Date: Wed, 28 Oct 2020 15:46:03 GMT Subject: Re: [Outreachy]: Help for Outreachy Application Message-ID: <29fc2f59-1cca-a3db-5586-bbd7b2e4806d@gmail.com> In-Reply-To: Hi Charvi On 28/10/2020 13:14, Charvi Mendiratta wrote: > On Tue, 27 Oct 2020 at 23:18, Phillip Wood wrote: >> On 27/10/2020 14:24, Charvi Mendiratta wrote: >>> On Mon, 26 Oct 2020 at 16:06, Phillip Wood wrote: >>>> On 25/10/2020 07:43, Charvi Mendiratta wrote: > [...] >>>> We will also need to decide on the best UI for the --reword idea. My >>>> patches were developed a couple of years ago before I was aware of >>>> dscho's idea and so implement a slightly different UI to the one >>>> outlined in the github issue (they call 'reword!' 'amend!' instead). I'm >>>> not that keen on adding another option to `git commit` to create yet >>>> another flavor of fixup commit, we'll need to agree a way forward on that[1] >>>> >>> >>> I agree that we need to look into options for creating reword! commit >>> and drop! commit and its integration with interactive rebase . >>> >>> Also, considering this I think there can be two possibilities : >>> >>> As mentioned by Junio [1] that we can extend the existing '--fixed '/ >>> '--squash ', to implement reword! commit as mentioned in the issue[2] >>> by Dscho . >> >> My concern with the idea of using `--fixup= --edit` to create a >> reword! commit is that it is changing existing behavior. I (very) >> occasionally add some temporary notes to a fixup commit if I know I'm >> not going to be rebasing for a while, that would still be possible under >> the new scheme but would require manually editing the subject line. >> > > I am still unable to get the case as you mentioned. At the moment `--fixup= --edit` opens an editor with a commit message that has a single line "fixup! ..." and the user is free to add any notes which will be discarded when they rebase. If we use that combination of options to create a reword! commit then the message will be pre-populated with the old message and that message will be used when the user rebases. > Otherwise, I thought > earlier about this idea as that for creating reword! commit if we want to > change both the content and message then `--fixup= --edit` can > be used and will be presented same as `git commit --amend` . Secondly, if > we want to change only message then `--fixup= --edit --allow-empty` You need to add `--only` as well to ensure that any staged changes are not added to the commit which makes a lot of typing (though users could set up an alias). > can be used and will present same as `git commit --amend --only` for the > mentioned commit . Please correct me if I am wrong or missing something . It may be that using the combination of `--fixup= --edit` is the least worst option and the change in behavior does not impact existing users, but we should consider the other options to be sure. >>> or as you have mentioned to change the semantics of >>> 'git commit --fixup/squash". >> >> I think that would require a config variable to opt in which is not ideal. >> >> Since that discussion I've wondered if changing commit to allow >> `--fixup=reword:` to create an empty reword! commit that changes >> the message of when it is rebased and `--fixup=amend:` >> to create a reword! commit that changes the content and message of >> when it is rebased. The advantage is that they are backwards >> compatible and mirror --amend and --reword as suggested in the other >> thread. We could allow `reword/amend:` to be abbreviated as >> `r/a:` >> > > Okay, I note this as one of the possibility and I agree completely with this. > >> We also need to decide how to apply a reword! commit when rebasing. My >> patch series adds a new command 'amend' but I wonder if we should think >> about using `fixup -C` to reuse the message without editing and `fixup >> -c` to reuse the message and have the user edit it as we do for `merge` > > Yes I also think, like we are not using extra commit command, then we > can also avoid to use new command in rebase also and can go with `fixup -C`. > But, I am still doubtful that how it will work upon rebase > --autosquash . At the moment if `--autosquash` sees a commit with a message that starts "fixup! " then it moves that fixup commit in the todo list to follow the commit it is fixing up and changes the command from `pick` to `fixup`. We want it do do the same with commits that have a message "reword! ..." but changing the command to `fixup -C` instead. If you look at my patch "rebase -i: update --autosquash to work with amend!" that might help make it clearer. > I am still > looking for some pointers for how merge command works(its use) in rebase -i. There's a section "Rebasing Merges" in the man page which might help, I'm not sure you need to know much about rebasing merges for this project. Best Wishes Phillip >> One other point - as the reword! mechanism changes the contents and >> message of the commit I wonder if we could improve the name - maybe >> amend! or revise! I'm not sure. >> > > As I understood, that reword! mechanism includes two cases, first if we want > to change the content and commit message both and second if only need to > change the commit message (as mentioned in issue to --allow-empty). As the > word "reword" implies the second case only . So, considering this I also agree > to improve its name to the one as you suggested or may be other. > >>> And, if we consider the above then for drop! commit, I wonder if we >>> can implement >>> it in the same way as mentioned in issue [2] by adding the --drop >>> option to 'git revert'. >>> >>> Secondly, as you have mentioned here [3], there could be a `rewrite` command >>> as a wrap of `rebase -i` . But regarding this, I want to once confirm >>> if this can be a >>> solution of this project or is it need to be done later on. >> >> The 'rewrite' idea is definitely not part of this project, it's an idea >> for better history editing in the future. >> > > Okay,Thanks for confirming this . > > Thanks and Regards, > Charvi > >> Best Wishes >> >> Phillip >> >>> Please correct me if I am wrong. >>> >>> Thanks and Regards, >>> Charvi >>> >>> [1] https://lore.kernel.org/git/xmqqft77glhn.fsf@gitster.c.googlers.com/ >>> [2] https://github.com/gitgitgadget/git/issues/259 >>> [3] https://lore.kernel.org/git/95cc6fb2-d1bc-11de-febe-c2b5c78a6850@gmail.com/ >>> >>>> Best Wishes >>>> >>>> Phillip >>>> >>>> [1] >>>> https://lore.kernel.org/git/95cc6fb2-d1bc-11de-febe-c2b5c78a6850@gmail.com >>>> >>>>> >>>>> Thanks and Regards, >>>>> Charvi >>>>> >>>>> [1] https://public-inbox.org/git/20201021124823.2217-1-charvi077@gmail.com/ >>>>> [2] https://github.com/gitgitgadget/git/issues/259 >>>>> [3] >>>>> https://public-inbox.org/git/pull.736.git.1600695050.gitgitgadget@gmail.com/ >>>>> [4] https://github.com/phillipwood/git/commits/wip/rebase-amend >>>>> >>>>