archive mirror
 help / color / mirror / Atom feed
From: Phillip Wood <>
To: Charvi Mendiratta <>,
Cc: git <>, Christian Couder <>
Subject: Re: [Outreachy]: Help for Outreachy Application
Date: Wed, 28 Oct 2020 15:46:03 +0000	[thread overview]
Message-ID: <> (raw)
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 <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


>> 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]
>>> [2]
>>> [3]
>>>> Best Wishes
>>>> Phillip
>>>> [1]
>>>>> Thanks and Regards,
>>>>> Charvi
>>>>> [1]
>>>>> [2]
>>>>> [3]
>>>>> [4]

      reply	other threads:[~2020-10-28 22:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-25  7:43 Charvi Mendiratta
2020-10-26 10:36 ` Phillip Wood
2020-10-27 14:24   ` Charvi Mendiratta
2020-10-27 17:48     ` Phillip Wood
2020-10-28 13:14       ` Charvi Mendiratta
2020-10-28 15:46         ` Phillip Wood [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [Outreachy]: Help for Outreachy Application' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox