Vscode: Commit amend loses multiline format in commit message

[joaomoreno]

[pmiossec]

I think that when this issue will be addressed, some more work must me done to improve "amend" feature ergonomy.

I think we should be able, with vscode, to amend only the commit message. At the moment, we must commit changes in the same time.

I also think that we should not use the command palette to edit the commit message like it's done at the moment...

I propose that:

• we first decide that we will amend the commit
• then, if the commit message field is empty, it is filled with the commit message of the commit that will be amended. (I don't exactly know what to do If there is already something entered. Perhaps we could have an option to do either "nothing", or appened the previous commit message on a new line)
• the user is then able to change the commit message (this solve this issue because you can enter a multiline commit message 😄 )
• when commiting, the commit is amended

PS: we could add an option somewhere to "stop" amending the commit if the user decide not to do it in the end....

[cavehill]

Any idea when this fix will be implemented?

Thanks!

[dantman]

If you need a workaround, this works beautifully in the integrated terminal:

EDITOR="code -w" git commit --amend

I actually put this in my ~/.bash_profile:

if [ ! -z "$VSCODE_IPC_HOOK" ]; then
    # Use vscode as the editor for things like Git when run from within vscode's integrated terminal
    export EDITOR="code -w"
fi

Now every time I do git things like git commit --amend from within the integrated terminal vscode itself is used as the editor for commit messages. I can edit within vscode with all the syntax highlighting and special functionality. Then just save and close the tab to finish the commit.

[segevfiner]

Atom's implementation of this is quite nice. It has an amend checkbox which brings the "commit to be amended" commit message, and files, into the UI. This allows you to remove files from the commit by "unstaging" (Not sure what this does in the underlying Git repository) them in the UI, and you can edit the commit message using the same UI as a normal commit. Avoiding a problem like this.

[danielo515]

Still an issue in 2019. I miss some input from the VSCode team...

[LenzGr]

Just stumbled over this one myself several times now. Any update/feedback on this one? It's cumbersome having to switch to a shell to run git commit --amend to maintain the formatting...

[Wiz1999]

Any update?

[coffenbacher]

This pretty much breaks amend functionality for my team, it would be really great if this gets fixed eventually.

[ADIX7]

Any info on this?

[pmiossec]

I just see that the GitPod service which use the theia editor (which is based on VSCode) is doing it very well!

The PR bringing the fix: https://github.com/eclipse-theia/theia/pull/1726

If that inspired someone to do it...And perhaps even get some code from the project...

[gabeschine]

I am also running into this bug. Would really appreciate un-breaking the amend flow!

[Shaun-Cox]

Another vote that this get fixed. I ammend my commit all the time until merge and I hate losing the newlines in my commit message.

[jorhett]

It appears that @joaomoreno will spend hours identifying reports from all the other people annoyed by this, but nobody will spend an hour to fix it

[jrial]

It appears that @joaomoreno will spend hours identifying reports from all the other people annoyed by this, but nobody will spend an hour to fix it

There's no need for that. While the bug is indeed annoying, there are almost 4000 issues demanding attention, apart from the work that's already on the roadmap. Your particular pet issue does not get priority simply by virtue that it annoys _you_.

Reasons why this might not be a priority:
1) It's not a common operation. Sure, some people use it all the time, but we're a minority.
2) There's a perfectly good workaround: the git CLI, or another graphical git frontend.
3) There is no data loss involved, and reverting the negative effects of this bug is trivial.
4) This part of the code may be scheduled for a redesign/rewrite, so fixing the bug in the current implementation would be a waste of effort.
...?

If it doesn't bother you enough for you to fix it yourself and open a pull request, it probably shouldn't bother you enough to lash out at the hard working developers who bring us a great product that measurably improves month by month, as evidenced by the changelog.

[aureliojargas]

A quick update on @dantman nice workaround. At least on my machine (Windows 10, VS Code using Git Bash as the terminal), the VSCODE_IPC_HOOK env variable is not defined. But I have TERM_PROGRAM=vscode. So that's what's working for me:

if test "$TERM_PROGRAM" = vscode; then
    # Use vscode as the editor for things like Git when run from within vscode's integrated terminal
    export EDITOR="code -w"
fi

[jorhett]

@jrial The only person here "lashing out" is you. I made a simple statement in roughly a dozen words that does nothing more than reflect the facts visible to anyone who reads the issue.

And to answer the core of your point, no really I don't see the "measurable improvement" -- I see months of effort put in colors and icons, while fairly basic Git usage is 1/4 to 1/3 implemented AT BEST. We are trying very hard to make use of VS Code, but nearly every day to day operation forces people back to the CLI. IMHO, why bother?

The fact that critical and common Git usage scenarios are all broken, and years go by without even acknowledgement of the issue further proves my point. It's a pretty toy, but until they care about doing Git operations correctly and easily it's functionally useless.

NOW I've lashed out. Got blamed for it anyway, might as well use up that credit 😆 🤣

[jorhett]

@jrial said it best

1. There's a perfectly good workaround: the git CLI, or another graphical git frontend.

If you've found this issue because this annoys you, you're gonna find a dozen more like it. Everyday common Git functionality is broken or not implemented in VS Code. The developers won't even acknowledge or update the issues, but they'll ream you for daring to speak up about them. As he said, if you use Git you should find something different.

[orgads]

I pushed a fix proposal.

[pmiossec]

@mix3d the notification just before the comment?

[devanshj]

I have a gift for ya'll xD

[mix3d]

I have a gift for ya'll xD

Yussss!

[jorhett]

THANK YOU!!! When does it land?

[devanshj]

THANK YOU!!! When does it land?

YOU'RE WELCOME!!! Idk depends when it gets merged, once that's done probably will be available in nightly. In stable it will probably land in month-end afaik.

Will wait for a day or so, after that if the PR doesn't get attention will mention someone from the team to take it to fast track.

UPDATE: Turns out there's a whole process to make changes to api (which is good, I like it) so it could take long enough

[jrial]

I have a gift for ya'll xD

Yay! And it's not even my birthday!

One question though: the input box for regular commits treats an Enter as a newline, and Ctrl+Enter submits (aka commits). I notice that your solution uses a different scheme: Shift+Enter for newline and Enter commits. I take it there was no way to preserve the original behaviour?

[devanshj]

One question though: the input box for regular commits treats an Enter as a newline, and Ctrl+Enter submits (aka commits). I notice that your solution uses a different scheme: Shift+Enter for newline and Enter commits. I take it there was no way to preserve the original behaviour?

Comparison with regular commit ui won't be fair because it's not a solution to this issue per se but it's an feature for the showInputBox api ie the quick pick ui which treats enter as submit so it would be better to keep it like that for multiline also.

EDIT:

there was no way to preserve the original behaviour?

Missed answering this: we can preserve it, but it's my conscious decision not to for the stated reasons

[jrial]

Comparison with regular commit ui won't be fair because it's not a solution to this issue per se but it's an feature for the showInputBox api ie the quick pick ui which treats enter as submit so it would be better to keep it like that for multiline also.

Ah, so this is an intermediate solution then? Not dissing your work, btw. Obviously I'm happy with the improvement. Just curious about where this particular issue is ultimately headed.

[devanshj]

Ah, so this is an intermediate solution then?

Umm no? I have also stated in the proposal on why what you're suggesting is a bad idea. You can back your suggestion and explain it there. Also I'll make myself more clear: I'm saying it's a bad idea because the api will be used by other extensions in other scenarios too, so designing the behavior thinking how it would be best suited for git extension usecase wouldn't be fair.

Not dissing your work, btw.

Dw you're good

Just curious about where this particular issue is ultimately headed.

According to me I think the proposed user experience is good enough which would solve the current issue, ultimately it would be whatever the vscode team agrees to.

[danielo515]

I think that a good workaround would be to add another amend option to VSCode that uses --no-edit. Most of the time, I don't want to edit the commit message and this will preserve the line breaks.

[heartacker]

Close to 3 years,......
I think that it will be better that user click amend that vscode copy the last-commit message to the commit-input-box. that user can edit again or just click cmomit continue.

[heartacker]

here is another way is that add those code you want -amend and the using cli to execute git commit --amend ,then git-scm.exe will open the last commit-msg with vscode(git config --global core.editor "code --wait"),then edit,save,close.
if using gerrit. remind that do not delete the chang-id before. otherwise they will generate a new id

[orgads]

You should not delete Change-Id. This is how gerrit associates your commit with the change entity.

[heartacker]

You should _not_ delete Change-Id. This is how gerrit associates your commit with the change entity.

seem that every commit will generate a new chang-id. if not there are two changeids in the commit-msg. To seek the answers to authority

[orgads]

If this happens to you, something is wrong with your commit-msg hook...

[heartacker]

If this happens to you, something is wrong with your commit-msg hook...

Do you mean that I don't need to delete the change-ID, It will keep the ID after Amend? thank for you remind

[orgads]

Exactly

[heartacker]

Close to 3 years,......
I think that it will be better that user click amend that vscode copy the last-commit message to the commit-input-box. that user can edit again or just click cmomit continue.

perfect example in Visual Studio ~Code~

[bit7]

Oh my God! This hasn't been fixed yet? The code that must need to change to fix this must be a nightmare!

[Aure77]

Still an issue in 2020 ! This bug has been reported in 2017...

[msftwindowslinux]

I've got a scrappy PR to add a git.amendNoEdit option that enables --no-edit when amending (and also skips the prompt for a commit message).

It would be great to get some direction on if/how something like this could be deemed an acceptable solution, because I think this is much needed for gerrit users as the current behavior clobbers the Change-Ids every time.

[jerivas]

What a horrible comment. Mentioning people just to dump sarcasm and vitriol on them. This is not the way to motivate the maintainers to look into this issue.

[hboshnak]

Hello Ed,
Wrote my feelings but mabe was rude, really.
Thanks for the corrective action.
Best regards!

On Wed, Nov 4, 2020 at 3:01 PM Ed Rivas [e-mail] wrote:

What a horrible comment. Mentioning people just to dump sarcasm and
vitriol on them. This is not the way to motivate the maintainers to look
into this issue.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/40295#issuecomment-721718320,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQMRHOWAY2Q4MG34RIHUP33SOFGD7ANCNFSM4EINZV6Q
.

[joaomoreno]

When running Commit (Amend) there are two cases:

• Commit input box is empty: old message is preserved
• Commit input box has value: that value is used as an amend commit message

If you'd like to edit the old commit message, you can always run Undo Last Commit and do it. For any other use cases, this will help: https://github.com/microsoft/vscode/pull/95266

[alexrussell]

• Commit input box is empty: old message is preserved

Aha, right, so for my use-case (doing a --no-edit style amend), I have to stage the files, run Commit (Amend) and then delete the auto-populated text from the single-line input (thus appearing to commit with an empty message) and then it'll do what I want. (I have just confirmed this, it seems to do it.)

Bit of an odd user experience, but I'm just happy I can do this 👍

[joaomoreno]

@alexrussell With the changes I just pushed, you don't need to delete any auto populated text, since you won't even be prompted for any input at all. Running Commit (Amend) will just complete without asking you anything.

This will be released in the next insiders.

[mix3d]

But what if you WANT to amend the commit message? I do this sometimes to fix typos, add something about the file I forgot to add to the commit, etc.

[mix3d]

Also, of the original request items:

I think we should be able, with vscode, to amend only the commit message. At the moment, we must commit changes in the same time.

[alexrussell]

@alexrussell With the changes I just pushed, you don't need to delete any auto populated text, since you won't even be prompted for any input at all. Running Commit (Amend) will just complete without asking you anything.

This will be released in the next insiders.

Ahh cool. And yeah, I said I confirmed that it worked but actually I think I was mistaken. So that tallies up with you saying it wasn't released yet! I look forward to my next insiders build then. Thanks @joaomoreno!

[joaomoreno]

But what if you WANT to amend the commit message? I do this sometimes to fix typos, add something about the file I forgot to add to the commit, etc.

As I said: run Git: Undo Last Commit. This will put your last message in the commit input box, properly formatted. Then, just commit again.

I think we should be able, with vscode, to amend only the commit message. At the moment, we must commit changes in the same time.

The same applies, simply run Git: Undo Last Commit, edit your message and commit again.

[grigorig]

Cool. This sounds like a good compromise. Thanks for the change. The messed up commit message formatting on amend hit me more than once.