Re: [Outreachy]: Help for Outreachy Application

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Charvi

On 28/10/2020 13:14, Charvi Mendiratta wrote:
> On Tue, 27 Oct 2020 at 23:18, Phillip Wood <phillip.wood123@gmail.com> wrote:
>> On 27/10/2020 14:24, Charvi Mendiratta wrote:
>>> On Mon, 26 Oct 2020 at 16:06, Phillip Wood <phillip.wood123@gmail.com> 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 <commit>'/
>>> '--squash <commit>', to implement reword! commit as mentioned in the issue[2]
>>> by Dscho .
>>
>> My concern with the idea of using `--fixup=<commit> --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=<commit> --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=<commit> --edit` can
> be used and will be presented same as `git commit --amend` . Secondly, if
> we want to change only message then `--fixup=<commit> --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=<commit> --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:<commit>` to create an empty reword! commit that changes
>> the message of <commit> when it is rebased and `--fixup=amend:<commit>`
>> to create a reword! commit that changes the content and message of
>> <commit> 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:<commit>` to be abbreviated as
>> `r/a:<commit>`
>>
> 
> 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! <subject of commit to 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
>>>>>
>>>>