[Outreachy]: Help for Outreachy Application

[Outreachy]: Help for Outreachy Application

[Charvi Mendiratta]

Hi Everyone!

It has been about more than two weeks, since I joined the mailing
list. Till now I have contributed to the microproject - "Modernize the
test script" [1] that is accepted by Junio. Also I would like to Thank
you all for the help and feedback on my first patch series. I learned a
lot about the git command itself, how to work in a community with the
mailing list and will try my best to get involved in the review
discussions.

I have read the Outreachy projects and am interested in the project
"Improve droping and rewording commits in Git interactive rebase". I
spent some time understanding the project and have gone through its
detailed explanation in the issue[2].

As mentioned that the first task is to implement --reword option in
'git commit'. Regarding this, I am unable to understand how it will
work upon rebase --autosquash?

and regarding the task to include --drop option. In issue[2] it's
clear to add this as an option in git revert but at the Outreachy page
in the Internship task section, it's mentioned to implement --drop
option in git reset. So, there is a bit of confusion regarding the
correct way to implement.

I also looked into archives of the mailing list and found the
patches[3] submitted by Philip for --reword option in git commit and
need some more pointers about its status and how to start with its
code ?
Also, in the issue[2] as commented by Phillip regarding the patches[4]
that implements reword. I would like to know if I can start with that
mentioned work, if available.

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

Re: [Outreachy]: Help for Outreachy Application

[Phillip Wood]

Hi Charvi

On 25/10/2020 07:43, Charvi Mendiratta wrote:
> Hi Everyone!
> 
> It has been about more than two weeks, since I joined the mailing
> list. Till now I have contributed to the microproject - "Modernize the
> test script" [1] that is accepted by Junio. Also I would like to Thank
> you all for the help and feedback on my first patch series. I learned a
> lot about the git command itself, how to work in a community with the
> mailing list and will try my best to get involved in the review
> discussions.
> 
> I have read the Outreachy projects and am interested in the project
> "Improve droping and rewording commits in Git interactive rebase". I
> spent some time understanding the project and have gone through its
> detailed explanation in the issue[2].

Thanks for your interest in the project

> As mentioned that the first task is to implement --reword option in
> 'git commit'. Regarding this, I am unable to understand how it will
> work upon rebase --autosquash?

The idea is that --autosquash will rearrange the todo list so that the 
reword! commits get squashed into the commits they reword (by changing 
'pick' to 'fixup' or maybe a new command) and the message from the 
reword! commit is used for the new commit rather than the message from 
the original commit that we squash the reword! commit into.

> and regarding the task to include --drop option. In issue[2] it's
> clear to add this as an option in git revert but at the Outreachy page
> in the Internship task section, it's mentioned to implement --drop
> option in git reset. So, there is a bit of confusion regarding the
> correct way to implement.

Yes getting the user interface right for creating the drop commits will 
be part of the project I think.

> I also looked into archives of the mailing list and found the
> patches[3] submitted by Philip for --reword option in git commit and
> need some more pointers about its status and how to start with its
> code ?
> Also, in the issue[2] as commented by Phillip regarding the patches[4]
> that implements reword. I would like to know if I can start with that
> mentioned work, if available.

Whoever takes on this project is very welcome to use my patches as a 
starting point. The code in the patches is sound as far as I know and 
the I believe the test coverage is reasonable (though that would need to 
be checked). They are lacking any documentation and there has been a 
change to the way empty commits are handled by rebase since they were 
written so "rebase -i: always keep empty amend! commits" will need 
looking at and could probably be dropped.

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]

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
> 

Re: [Outreachy]: Help for Outreachy Application

[Charvi Mendiratta]

On Mon, 26 Oct 2020 at 16:06, Phillip Wood <phillip.wood123@gmail.com> wrote:
>
Hi Phillip,

> Hi Charvi
>
> On 25/10/2020 07:43, Charvi Mendiratta wrote:
> > Hi Everyone!
> >
> > It has been about more than two weeks, since I joined the mailing
> > list. Till now I have contributed to the microproject - "Modernize the
> > test script" [1] that is accepted by Junio. Also I would like to Thank
> > you all for the help and feedback on my first patch series. I learned a
> > lot about the git command itself, how to work in a community with the
> > mailing list and will try my best to get involved in the review
> > discussions.
> >
> > I have read the Outreachy projects and am interested in the project
> > "Improve droping and rewording commits in Git interactive rebase". I
> > spent some time understanding the project and have gone through its
> > detailed explanation in the issue[2].
>
> Thanks for your interest in the project
>

I apologize for late replies, as I thought to spend some more time in
understanding the project.

> > As mentioned that the first task is to implement --reword option in
> > 'git commit'. Regarding this, I am unable to understand how it will
> > work upon rebase --autosquash?
>
> The idea is that --autosquash will rearrange the todo list so that the
> reword! commits get squashed into the commits they reword (by changing
> 'pick' to 'fixup' or maybe a new command) and the message from the
> reword! commit is used for the new commit rather than the message from
> the original commit that we squash the reword! commit into.
>

Thanks for the detailed explanation, now I can easily co relate this with
--fixup / --squash.

> > and regarding the task to include --drop option. In issue[2] it's
> > clear to add this as an option in git revert but at the Outreachy page
> > in the Internship task section, it's mentioned to implement --drop
> > option in git reset. So, there is a bit of confusion regarding the
> > correct way to implement.
>
> Yes getting the user interface right for creating the drop commits will
> be part of the project I think.
>
> > I also looked into archives of the mailing list and found the
> > patches[3] submitted by Philip for --reword option in git commit and
> > need some more pointers about its status and how to start with its
> > code ?
> > Also, in the issue[2] as commented by Phillip regarding the patches[4]
> > that implements reword. I would like to know if I can start with that
> > mentioned work, if available.
>
> Whoever takes on this project is very welcome to use my patches as a
> starting point. The code in the patches is sound as far as I know and
> the I believe the test coverage is reasonable (though that would need to
> be checked). They are lacking any documentation and there has been a
> change to the way empty commits are handled by rebase since they were
> written so "rebase -i: always keep empty amend! commits" will need
> looking at and could probably be dropped.
>

Okay, I will note these points .

> 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 . or as you have mentioned to change the semantics of
'git commit --fixup/squash".
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.

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

Re: [Outreachy]: Help for Outreachy Application

[Phillip Wood]

Hi Charvi

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:
>>> I have read the Outreachy projects and am interested in the project
>>> "Improve droping and rewording commits in Git interactive rebase". I
>>> spent some time understanding the project and have gone through its
>>> detailed explanation in the issue[2].
>>
>> Thanks for your interest in the project
>>
> I apologize for late replies, as I thought to spend some more time in
> understanding the project.

That's fine, no need to apologize - taking time to understand the 
project is good

 >[...]
>>> I also looked into archives of the mailing list and found the
>>> patches[3] submitted by Philip for --reword option in git commit and
>>> need some more pointers about its status and how to start with its
>>> code ?
>>> Also, in the issue[2] as commented by Phillip regarding the patches[4]
>>> that implements reword. I would like to know if I can start with that
>>> mentioned work, if available.
>>
>> Whoever takes on this project is very welcome to use my patches as a
>> starting point. The code in the patches is sound as far as I know and
>> the I believe the test coverage is reasonable (though that would need to
>> be checked). They are lacking any documentation and there has been a
>> change to the way empty commits are handled by rebase since they were
>> written so "rebase -i: always keep empty amend! commits" will need
>> looking at and could probably be dropped.
> 
> Okay, I will note these points .
> 
>> 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.

> 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>`

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`

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.

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

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

Re: [Outreachy]: Help for Outreachy Application

[Charvi Mendiratta]

On Tue, 27 Oct 2020 at 23:18, Phillip Wood <phillip.wood123@gmail.com> wrote:
Hi Phillip
>
> Hi Charvi
>
> 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:
> >>> I have read the Outreachy projects and am interested in the project
> >>> "Improve droping and rewording commits in Git interactive rebase". I
> >>> spent some time understanding the project and have gone through its
> >>> detailed explanation in the issue[2].
> >>
> >> Thanks for your interest in the project
> >>
> > I apologize for late replies, as I thought to spend some more time in
> > understanding the project.
>
> That's fine, no need to apologize - taking time to understand the
> project is good
>
>  >[...]
> >>> I also looked into archives of the mailing list and found the
> >>> patches[3] submitted by Philip for --reword option in git commit and
> >>> need some more pointers about its status and how to start with its
> >>> code ?
> >>> Also, in the issue[2] as commented by Phillip regarding the patches[4]
> >>> that implements reword. I would like to know if I can start with that
> >>> mentioned work, if available.
> >>
> >> Whoever takes on this project is very welcome to use my patches as a
> >> starting point. The code in the patches is sound as far as I know and
> >> the I believe the test coverage is reasonable (though that would need to
> >> be checked). They are lacking any documentation and there has been a
> >> change to the way empty commits are handled by rebase since they were
> >> written so "rebase -i: always keep empty amend! commits" will need
> >> looking at and could probably be dropped.
> >
> > Okay, I will note these points .
> >
> >> 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 . 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`
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 .

> > 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 . I am still
looking for some pointers for how merge command works(its use) in rebase -i.

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

Re: [Outreachy]: Help for Outreachy Application

[Phillip Wood]

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