From: Phillip Wood <phillip.wood123@gmail.com>
To: Charvi Mendiratta <charvi077@gmail.com>
Cc: git <git@vger.kernel.org>, Christian Couder <christian.couder@gmail.com>
Subject: Re: [Outreachy]: Help for Outreachy Application
Date: Tue, 27 Oct 2020 17:48:02 +0000 [thread overview]
Message-ID: <966470c3-8883-faf1-629f-89fc8d18b339@gmail.com> (raw)
In-Reply-To: <CAPSFM5fbZN0uv9SgB-d4SR53ZFw8cOkgFmUK-Gns+c=yAmcP1w@mail.gmail.com>
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
>>>
>>
next prev parent reply other threads:[~2020-10-27 17:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-25 7:43 [Outreachy]: Help for Outreachy Application Charvi Mendiratta
2020-10-26 10:36 ` Phillip Wood
2020-10-27 14:24 ` Charvi Mendiratta
2020-10-27 17:48 ` Phillip Wood [this message]
2020-10-28 13:14 ` Charvi Mendiratta
2020-10-28 15:46 ` Phillip Wood
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=966470c3-8883-faf1-629f-89fc8d18b339@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=charvi077@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=phillip.wood@dunelm.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).