Amending commits

Amending commits

[Lars Ingebrigtsen]

I vaguely remembered that commands for amending commits had been added,
but I have no idea how those are supposed to be used.  I searched for
"amend" in maintaining.texi and found nothing.  I found
`vc-git-log-edit-toggle-amend', but...  how is that supposed to be used?

There should be a command in `vc-dir-mode' that allows you to amend the
last commit, I think.

Re: Amending commits

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I vaguely remembered that commands for amending commits had been added,
> but I have no idea how those are supposed to be used.  I searched for
> "amend" in maintaining.texi and found nothing.  I found
> `vc-git-log-edit-toggle-amend', but...  how is that supposed to be used?

I think that command assumed you have changes that you wish to add to
the last commit (so you couldn't just use it to reword a commit).  You
start preparing a new commit using `vc-next-action', then when the
buffer appears you M-x vc-git-log-edit-toggle-amend to indicate that
this commit will be amending the previous one.  So the commit message
gets replaced by that of the previous message.  The rest just involves
finishing up like any other commit.

> There should be a command in `vc-dir-mode' that allows you to amend the
> last commit, I think.

That would be good, because it would also allow easier to reword a
commit that doesn't require any code changes.

Re: Amending commits

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> I think that command assumed you have changes that you wish to add to
> the last commit (so you couldn't just use it to reword a commit).  You
> start preparing a new commit using `vc-next-action', then when the
> buffer appears you M-x vc-git-log-edit-toggle-amend to indicate that
> this commit will be amending the previous one.  So the commit message
> gets replaced by that of the previous message.  The rest just involves
> finishing up like any other commit.

Ah, I see.

>> There should be a command in `vc-dir-mode' that allows you to amend the
>> last commit, I think.
>
> That would be good, because it would also allow easier to reword a
> commit that doesn't require any code changes.

Yes.  My use case is "git am" and then I want to add the bug# to the
commit message -- and in that case, I don't have a log-edit buffer at
all.

Re: Amending commits

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: "Emacs-devel@gnu.org" <Emacs-devel@gnu.org>
> Date: Sun, 25 Sep 2022 13:39:00 +0200
> 
> Yes.  My use case is "git am" and then I want to add the bug# to the
> commit message -- and in that case, I don't have a log-edit buffer at
> all.

Can't you set vc-checkin-switches to "--amend" and then commit?

Re: Amending commits

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Yes.  My use case is "git am" and then I want to add the bug# to the
>> commit message -- and in that case, I don't have a log-edit buffer at
>> all.
>
> Can't you set vc-checkin-switches to "--amend" and then commit?

I'm not sure what you mean.  How would that help with "git am"?

Re: Amending commits

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: philipk@posteo.net,  Emacs-devel@gnu.org
> Date: Mon, 26 Sep 2022 12:42:26 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Yes.  My use case is "git am" and then I want to add the bug# to the
> >> commit message -- and in that case, I don't have a log-edit buffer at
> >> all.
> >
> > Can't you set vc-checkin-switches to "--amend" and then commit?
> 
> I'm not sure what you mean.  How would that help with "git am"?

You do "git am" followed by a vc-checkin with --amend switch.
vc-checkin does let you edit the log message in a log-edit buffer,
doesn't it?

Or was that not your use case?  If so, what was it?

Re: Amending commits

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> You do "git am" followed by a vc-checkin with --amend switch.
> vc-checkin does let you edit the log message in a log-edit buffer,
> doesn't it?

A vc-checkin without anything to check in?  I didn't know that that was
possible, and it doesn't seem like a natural work flow.

Re: Amending commits

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: philipk@posteo.net,  Emacs-devel@gnu.org
> Date: Mon, 26 Sep 2022 14:00:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > You do "git am" followed by a vc-checkin with --amend switch.
> > vc-checkin does let you edit the log message in a log-edit buffer,
> > doesn't it?
> 
> A vc-checkin without anything to check in?  I didn't know that that was
> possible, and it doesn't seem like a natural work flow.

It's no less natural than "git commit --amend" from the command line.

How do you fix log messages today when you apply patches by others?

Re: Amending commits

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> A vc-checkin without anything to check in?  I didn't know that that was
>> possible, and it doesn't seem like a natural work flow.
>
> It's no less natural than "git commit --amend" from the command line.

Which is pretty unnatural.

So I guess the conclusion here is that I should just go ahead and add a
vc command that does the right thing for this use case.

> How do you fix log messages today when you apply patches by others?

I use debbugs-gnu.

Re: Amending commits

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: philipk@posteo.net,  Emacs-devel@gnu.org
> Date: Tue, 27 Sep 2022 13:37:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> A vc-checkin without anything to check in?  I didn't know that that was
> >> possible, and it doesn't seem like a natural work flow.
> >
> > It's no less natural than "git commit --amend" from the command line.
> 
> Which is pretty unnatural.

It's Git ;-)

> > How do you fix log messages today when you apply patches by others?
> 
> I use debbugs-gnu.

You mean, you physically edit the log message _before_ committing?

Re: Amending commits

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> You mean, you physically edit the log message _before_ committing?

That's the debbugs-gnu work flow; yes.  But there's usually no manual
editing involved -- I just hit `M-m' five times, and it fixes the rest
(like adding the bug# and stuff).

Re: Amending commits

[Robert Pluim]

>>>>> On Tue, 27 Sep 2022 13:37:24 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Eli Zaretskii <eliz@gnu.org> writes:
    >>> A vc-checkin without anything to check in?  I didn't know that that was
    >>> possible, and it doesn't seem like a natural work flow.
    >> 
    >> It's no less natural than "git commit --amend" from the command line.

    Lars> Which is pretty unnatural.

    Lars> So I guess the conclusion here is that I should just go ahead and add a
    Lars> vc command that does the right thing for this use case.

Can we call it 'commit-reword' or similar, in line with Magit?

    >> How do you fix log messages today when you apply patches by others?

    Lars> I use debbugs-gnu.

I use magit or 'git commit --amendʼ'

Robert
-- 

Re: Amending commits

[Sean Whitton]

Hello,

On Tue 27 Sep 2022 at 01:37PM +02, Lars Ingebrigtsen wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> A vc-checkin without anything to check in?  I didn't know that that was
>>> possible, and it doesn't seem like a natural work flow.
>>
>> It's no less natural than "git commit --amend" from the command line.
>
> Which is pretty unnatural.
>
> So I guess the conclusion here is that I should just go ahead and add a
> vc command that does the right thing for this use case.

There is already vc-modify-change-comment which I think just needs a Git
backend implementation.  Then it'll work from Log View.

-- 
Sean Whitton

Re: Amending commits

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> There is already vc-modify-change-comment which I think just needs a Git
> backend implementation.  Then it'll work from Log View.

Makes sense.  (The limitation in Git, of course, is that you can only
modify the last commit, but having it signal an error if that's not it's
being asked to amend would be fine.)

Re: Amending commits

[Sean Whitton]

Hello,

On Tue 27 Sep 2022 at 05:40PM +02, Lars Ingebrigtsen wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> There is already vc-modify-change-comment which I think just needs a Git
>> backend implementation.  Then it'll work from Log View.
>
> Makes sense.  (The limitation in Git, of course, is that you can only
> modify the last commit, but having it signal an error if that's not it's
> being asked to amend would be fine.)

Couldn't it do a rebase to reword the old commit?  I often do 'git
rebase -i' only for the purpose of rewording an unpushed, non-tip
commit, and it would be nice for that to be automated (eventually!).

-- 
Sean Whitton

Re: Amending commits

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Couldn't it do a rebase to reword the old commit?  I often do 'git
> rebase -i' only for the purpose of rewording an unpushed, non-tip
> commit, and it would be nice for that to be automated (eventually!).

That should be possible (or un-checkin and then stash commits and
reapply), but sounds like major work.

Re: Amending commits

[Sean Whitton]

Hello,

On Tue 27 Sep 2022 at 06:17PM +02, Lars Ingebrigtsen wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> Couldn't it do a rebase to reword the old commit?  I often do 'git
>> rebase -i' only for the purpose of rewording an unpushed, non-tip
>> commit, and it would be nice for that to be automated (eventually!).
>
> That should be possible (or un-checkin and then stash commits and
> reapply), but sounds like major work.

Right.  If you're planning on working on the 'commit --amend' part,
could you add an error specifically stating that amending the messages
of older commits is not yet {supported|implemented}, please?  Currently
I think you just get a Lisp error or maybe nothing happens at all.
Given that I do this a lot I'll probably look into the rest of it at
some point.

-- 
Sean Whitton

Re: Amending commits

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Right.  If you're planning on working on the 'commit --amend' part,
> could you add an error specifically stating that amending the messages
> of older commits is not yet {supported|implemented}, please?

Sure.

Re: Amending commits

[Gregory Heytings]

>
> The limitation in Git, of course, is that you can only modify the last 
> commit
>

With git commit --amend you can only modify the last commit, indeed, but 
you can change earlier commits with git rebase --interactive:

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_changing_multiple

Re: Amending commits

[Juri Linkov]

> There is already vc-modify-change-comment which I think just needs a Git
> backend implementation.  Then it'll work from Log View.

How this could work?  Typing 'e' on the last commit in the log-view buffer
will pop up a log-edit buffer with the pre-filled header "Amend: yes"
and the empty changeset?

Re: Amending commits

[Sean Whitton]

Hello,

On Wed 28 Sep 2022 at 09:09PM +03, Juri Linkov wrote:

>> There is already vc-modify-change-comment which I think just needs a Git
>> backend implementation.  Then it'll work from Log View.
>
> How this could work?  Typing 'e' on the last commit in the log-view buffer
> will pop up a log-edit buffer with the pre-filled header "Amend: yes"
> and the empty changeset?

Yes, or looking forward to when editing the commit messages of older
commits is implemented, a special Log Edit buffer which does not use
Amend: yes but some other magic header, Rewrite: 809abdf maybe.

-- 
Sean Whitton

Re: Amending commits

[Rudolf Schlatte]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Yes.  My use case is "git am" and then I want to add the bug# to the
>>> commit message -- and in that case, I don't have a log-edit buffer at
>>> all.
>>
>> Can't you set vc-checkin-switches to "--amend" and then commit?
>
> I'm not sure what you mean.  How would that help with "git am"?

FWIW, after you apply a series of patches via `git am', you can use `git
rebase -i' (interactive rebase) to bulk-edit commit messages, among
other things.  (Writing this just in case you or another reader didn't
know this yet.)

Re: Amending commits

[Visuwesh]

[ஞாயிறு செப்டம்பர் 25, 2022] Philip Kaludercic wrote:

>> There should be a command in `vc-dir-mode' that allows you to amend the
>> last commit, I think.
>
> That would be good, because it would also allow easier to reword a
> commit that doesn't require any code changes.

As someone who does not really understand Git, does this mean we are
rewriting the log message without also committing a change?  I thought
that was not allowed by Git.

Re: Amending commits

[Philip Kaludercic]

Visuwesh <visuweshm@gmail.com> writes:

> [ஞாயிறு செப்டம்பர் 25, 2022] Philip Kaludercic wrote:
>
>>> There should be a command in `vc-dir-mode' that allows you to amend the
>>> last commit, I think.
>>
>> That would be good, because it would also allow easier to reword a
>> commit that doesn't require any code changes.
>
> As someone who does not really understand Git, does this mean we are
> rewriting the log message without also committing a change?  I thought
> that was not allowed by Git.

Git allows it if you pass the --allow-empty flag.

Re: Amending commits

[Andreas Schwab]

On Sep 25 2022, Philip Kaludercic wrote:

> Visuwesh <visuweshm@gmail.com> writes:
>
>> [ஞாயிறு செப்டம்பர் 25, 2022] Philip Kaludercic wrote:
>>
>>>> There should be a command in `vc-dir-mode' that allows you to amend the
>>>> last commit, I think.
>>>
>>> That would be good, because it would also allow easier to reword a
>>> commit that doesn't require any code changes.
>>
>> As someone who does not really understand Git, does this mean we are
>> rewriting the log message without also committing a change?  I thought
>> that was not allowed by Git.
>
> Git allows it if you pass the --allow-empty flag.

You don't need --allow-empty if you use --amend.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Amending commits

[Philip Kaludercic]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Sep 25 2022, Philip Kaludercic wrote:
>
>> Visuwesh <visuweshm@gmail.com> writes:
>>
>>> [ஞாயிறு செப்டம்பர் 25, 2022] Philip Kaludercic wrote:
>>>
>>>>> There should be a command in `vc-dir-mode' that allows you to amend the
>>>>> last commit, I think.
>>>>
>>>> That would be good, because it would also allow easier to reword a
>>>> commit that doesn't require any code changes.
>>>
>>> As someone who does not really understand Git, does this mean we are
>>> rewriting the log message without also committing a change?  I thought
>>> that was not allowed by Git.
>>
>> Git allows it if you pass the --allow-empty flag.
>
> You don't need --allow-empty if you use --amend.

You are right, I made a mistake when testing it out locally.

Re: Amending commits

[Manuel Giraud]

Visuwesh <visuweshm@gmail.com> writes:

[...]

> As someone who does not really understand Git, does this mean we are
> rewriting the log message without also committing a change?  I thought
> that was not allowed by Git.

It is allowed… but not a good idea on anything public.
-- 
Manuel Giraud

Re: Amending commits

[Gregory Heytings]

>
> As someone who does not really understand Git, does this mean we are 
> rewriting the log message without also committing a change?  I thought 
> that was not allowed by Git.
>

git commit --amend is mainly used to change a commit before pushing it. 
Rewriting history (i.e. changing an already public commit) is (by default) 
not possible.

Re: Amending commits

[Stefan Monnier]

>> As someone who does not really understand Git, does this mean we are
>> rewriting the log message without also committing a change?  I thought
>> that was not allowed by Git.
> git commit --amend is mainly used to change a commit before pushing
> it.  Rewriting history (i.e. changing an already public commit) is (by
> default) not possible.

When people say that in Git you cannot rewrite history, what it means is
that you can't change anything about a given *commit id* (aka
"revision").
Of course, you can create a new revision (i.e. a different commit id)
with any content you like.  Things like `rebase` and `filter-repo` are
more general version of `commit --amend` and work in the same way, by
writing a whole new history.


        Stefan

Re: Amending commits

[Gregory Heytings]

>>> As someone who does not really understand Git, does this mean we are 
>>> rewriting the log message without also committing a change?  I thought 
>>> that was not allowed by Git.
>>
>> git commit --amend is mainly used to change a commit before pushing it. 
>> Rewriting history (i.e. changing an already public commit) is (by 
>> default) not possible.
>
> When people say that in Git you cannot rewrite history, what it means is 
> that you can't change anything about a given *commit id* (aka 
> "revision").
>

Hmm... no, AFAIU, it means that (by default) you cannot replace the commit 
history of a public repository with commits which do not have the HEAD of 
the public repository as their parent.  E.g. if your public repository is

A - B - C - D
             ^ HEAD

you cannot change it into

     B - C - D
   /
A - E - F - G
             ^ HEAD

Re: Amending commits

[Dmitry Gutov]

On 25.09.2022 23:15, Gregory Heytings wrote:
> 
>>>> As someone who does not really understand Git, does this mean we are 
>>>> rewriting the log message without also committing a change?  I 
>>>> thought that was not allowed by Git.
>>>
>>> git commit --amend is mainly used to change a commit before pushing 
>>> it. Rewriting history (i.e. changing an already public commit) is (by 
>>> default) not possible.
>>
>> When people say that in Git you cannot rewrite history, what it means 
>> is that you can't change anything about a given *commit id* (aka 
>> "revision").
>>
> 
> Hmm... no, AFAIU, it means that (by default) you cannot replace the 
> commit history of a public repository with commits which do not have the 
> HEAD of the public repository as their parent.  E.g. if your public 
> repository is
> 
> A - B - C - D
>              ^ HEAD
> 
> you cannot change it into
> 
>      B - C - D
>    /
> A - E - F - G
>              ^ HEAD

You can even do that (if 'force pushes' are not disabled in the 
repository's settings).

It's just usually a bad idea.

So you can rewrite history, but commits are "immutable".

Re: Amending commits

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]


>> Hmm... no, AFAIU, it means that (by default) you cannot replace the 
>> commit history of a public repository with commits which do not have 
>> the HEAD of the public repository as their parent.  E.g. if your public 
>> repository is
>> 
>> A - B - C - D
>>              ^ HEAD
>> 
>> you cannot change it into
>>
>>      B - C - D
>>    /
>> A - E - F - G
>>              ^ HEAD
>
> You can even do that (if 'force pushes' are not disabled in the 
> repository's settings).
>

Yes, I said "by default": force pushes are disabled in the default 
settings of Git repositories, unless they have been enabled you cannot do 
that.

Re: Amending commits

[Stefan Monnier]

Gregory Heytings [2022-09-25 20:46:40] wrote:
> Yes, I said "by default": force pushes are disabled in the default settings
> of Git repositories, unless they have been enabled you cannot do that.

Not sure if this default has changed, but last time I checked the
default was to allow such force pushes (`emacs.git` and `elpa.git` have
explicitly changed this setting to disallow them).
You just need to specify the `--force` option when you push.

For those repositories like `emacs.git`, `--force` doesn't override the
server's wish, but you can still force push by first deleting the branch
and then pushing the new history.


        Stefan

Re: Amending commits

[Gregory Heytings]

>> Yes, I said "by default": force pushes are disabled in the default 
>> settings of Git repositories, unless they have been enabled you cannot 
>> do that.
>
> Not sure if this default has changed, but last time I checked the 
> default was to allow such force pushes (`emacs.git` and `elpa.git` have 
> explicitly changed this setting to disallow them). You just need to 
> specify the `--force` option when you push.
>

These repositories have been created with git init --shared, which 
automatically sets denyNonFastforwards to true.  This has been the default 
since Git 1.5 in 2007.

>
> For those repositories like `emacs.git`, `--force` doesn't override the 
> server's wish, but you can still force push by first deleting the branch 
> and then pushing the new history.
>

With branches, yes, but not with master, unless denyDeleteCurrent has been 
set to warn or ignore.  And this is not always possible, even with 
branches: all deletions can be disallowed by setting receive.denyDeletes 
to true.

Re: Amending commits

[Andreas Schwab]

On Sep 26 2022, Gregory Heytings wrote:

> With branches, yes, but not with master, unless denyDeleteCurrent has been
> set to warn or ignore.

denyDeleteCurrent is only relevant for non-bare repositories (a bare
repository has no checked out branches).

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Amending commits

[Gregory Heytings]

>> With branches, yes, but not with master, unless denyDeleteCurrent has 
>> been set to warn or ignore.
>
> denyDeleteCurrent is only relevant for non-bare repositories (a bare 
> repository has no checked out branches).
>

Wrong.  A bare repository has a current branch too: it's the branch that 
you get when you clone it.

Re: Amending commits

[Andreas Schwab]

On Sep 26 2022, Gregory Heytings wrote:

>>> With branches, yes, but not with master, unless denyDeleteCurrent has
>>> been set to warn or ignore.
>>
>> denyDeleteCurrent is only relevant for non-bare repositories (a bare
>> repository has no checked out branches).
>>
>
> Wrong.  A bare repository has a current branch too: it's the branch that
> you get when you clone it.

That has nothing to do with the currently checked out branch, which
cannot exist in a bare repository.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Amending commits

[Gregory Heytings]

>>>> With branches, yes, but not with master, unless denyDeleteCurrent has 
>>>> been set to warn or ignore.
>>>
>>> denyDeleteCurrent is only relevant for non-bare repositories (a bare 
>>> repository has no checked out branches).
>>
>> Wrong.  A bare repository has a current branch too: it's the branch 
>> that you get when you clone it.
>
> That has nothing to do with the currently checked out branch, which 
> cannot exist in a bare repository.
>

Just try it yourself.  git push origin --delete master, git config 
receive.denyDeleteCurrent ignore, git push origin --delete master.

Re: Amending commits

[Andreas Schwab]

On Sep 26 2022, Gregory Heytings wrote:

> Just try it yourself.  git push origin --delete master, git config
> receive.denyDeleteCurrent ignore, git push origin --delete master.

So this is a documentation bug.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Amending commits

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]


>> Just try it yourself.  git push origin --delete master, git config 
>> receive.denyDeleteCurrent ignore, git push origin --delete master.
>
> So this is a documentation bug.
>

Or an understanding bug 😉 All Git repositories have a "current" branch, 
unless they are in a "detached HEAD" state.  Again, a bare repository has 
a current branch: it's the branch that you get when you clone it.  And 
"git branch" works in a bare repository, too: you'll see a star in front 
of is "current" branch. The documentation could be more explicit indeed, 
but what would be the meaning of receive.denyDeleteCurrent in a bare 
repository?

Re: Amending commits

[Andreas Schwab]

On Sep 26 2022, Gregory Heytings wrote:

>>> Just try it yourself.  git push origin --delete master, git config
>>> receive.denyDeleteCurrent ignore, git push origin --delete master.
>>
>> So this is a documentation bug.
>>
>
> Or an understanding bug 😉 All Git repositories have a "current" branch,

This is irrelevant, because the documentation explicitly excludes bare
repositories.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Amending commits

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]


>>>> Just try it yourself.  git push origin --delete master, git config 
>>>> receive.denyDeleteCurrent ignore, git push origin --delete master.
>>>
>>> So this is a documentation bug.
>>
>> Or an understanding bug 😉 All Git repositories have a "current" 
>> branch,
>
> This is irrelevant, because the documentation explicitly excludes bare 
> repositories.
>

Does it?  What I see is that it explains the meaning to that option for 
non-bare repositories, but doesn't say anything, and does not explicitly 
exclude anything, for bare repositories.

Re: Amending commits

[Alan Mackenzie]

Hello, Stefan.

On Sun, Sep 25, 2022 at 15:26:39 -0400, Stefan Monnier wrote:
> >> As someone who does not really understand Git, does this mean we are
> >> rewriting the log message without also committing a change?  I thought
> >> that was not allowed by Git.
> > git commit --amend is mainly used to change a commit before pushing
> > it.  Rewriting history (i.e. changing an already public commit) is (by
> > default) not possible.

> When people say that in Git you cannot rewrite history, what it means is
> that you can't change anything about a given *commit id* (aka
> "revision").
> Of course, you can create a new revision (i.e. a different commit id)
> with any content you like.  Things like `rebase` and `filter-repo` are
> more general version of `commit --amend` and work in the same way, by
> writing a whole new history.

At the risk of drifting off topic, this is a misfeature of git (and
other VCSs).  When people commit software changes, and get it wrong,
this can be fixed by another commit.

When people commit software changes and get the commit message wrong,
this cannot be fixed.  Whether it be misspelling somebody's name,
missing out the bug number, or whatever, mistakes can't be corrected.

This seems to have been caused by a misunderstanding by the authors of
git (and other VCSs), who thought that the commit message was a
fundamental part of the commit.  It's not, any more than the label on a
bottle of beer is part of the beer.  You don't drink labels, just as you
don't ship commit messages to the users of (binary) software.

Those authors thought that nobody makes mistakes in their commit
messages.  Or at least, nobody that matters.  They, of course, never
make such mistakes themselves.  ;-)  It would have been a simple enough
matter, in a VCS, for the commit message for a specific commit itself to
have had revisions.  Instead, we have repositories filled with unfixable
errors.

Rant over.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Amending commits

[Lars Ingebrigtsen]

Visuwesh <visuweshm@gmail.com> writes:

> As someone who does not really understand Git, does this mean we are
> rewriting the log message without also committing a change?  I thought
> that was not allowed by Git.

You can rewrite all commits in Git -- before pushing them.  After that,
not so much.