nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

[Git] Amend a commit do more than change the message

mprimi

If I amend a commit, the commit message field is populated and I can edit it.

However I cannot edit the actual content of the commit (i.e. unstage a file or a hunk).

GitX has this feature which i find very useful when I realize after committing that I staged some file/hunk by mistake.

Any way to do this with SourceTree (which i find better than GitX for everything else :-))?

Accepted answers

KieranA

Hi Marco,

I can see precisely what you mean by this. As you say, staging/unstaging hunks at the command line can be a pain.

"git commit --amend" actually just makes additions to the previous commit, so you can stage files and make changes to files in the previous commit. What GitX seems to be doing is something like the following:

git reset --soft HEAD^ (this will reset the HEAD to the prior commit, making your prior changes in the state of "changes to be committed")
From this point, you can then unstage the changes from your previous commit if you like if you made a mistake and/or stage other files
git commit -c ORIG_HEAD (to then re-commit)

So it doesn't do one action as technically git's amend flag doesn't support this, it's just issuing multiple commands to make it seem as if git's amend flag can do this.

Currently you can do this in SourceTree by resetting to the most recent commit's parent (HEAD^) as follows:

Then you can select the soft mode as follows:

We've added this in JIRA as a feature request here: https://jira.atlassian.com/browse/SRCTREE-1303

In the mean time, if you could use the above method instead which is essentially the same thing, then we'll look at getting it integrated into the commit dialog for 1.6.

Cheers

All comments

KieranA

Hi Marco,

You can do this, it just involves a small extra step. You can reverse your previous commit entirely if you like, alternatively SourceTree allows you to reverse hunks/selected lines so you can pick which changes you want to revert (in the diff view). Following this you can then commit those changes and amend to the latest commit. It's the same thing essentially and in practice is what you'd usually do.

Cheers

mprimi

Thanks for your reply. Unfortunately what you're suggesting works for just a subset of the scenarios I was thinking about.

You can use it only to revert, what I really want is just to unstage (during an amend).

Consider the following scenario:

I did some work, committed, tested on some other machine, etc.

Now I want to go back and split my large ugly commit into maybe two or three smaller commits that are easier for other people to review.

With GitX I would amend (this brings all my changes in the staging area). I can unstage some hunks and create a first commit, then stage some more and create a second one, and maybe revert some other hunks (i.e. debug printouts), etc.

I still don't see any way to this with SourceTree.

I guess my request/suggestion boils down to:

When amending a commit, it's content is not visible. It would be really nice to see the files in the staged area and allow one to unstage hunks or files, just like one does _before_ the commit.

This covers 90% of the use I make of GUI SCM tools, staging and unstaging hunks is a PITA using the command line. (the other 10% is looking at the tree view).

Please consider this a feature suggestion. I think it would allow user to do even more with SourceTree.

KieranA

Hi Marco,

I can see precisely what you mean by this. As you say, staging/unstaging hunks at the command line can be a pain.

git reset --soft HEAD^ (this will reset the HEAD to the prior commit, making your prior changes in the state of "changes to be committed")
From this point, you can then unstage the changes from your previous commit if you like if you made a mistake and/or stage other files
git commit -c ORIG_HEAD (to then re-commit)

So it doesn't do one action as technically git's amend flag doesn't support this, it's just issuing multiple commands to make it seem as if git's amend flag can do this.

Currently you can do this in SourceTree by resetting to the most recent commit's parent (HEAD^) as follows:

Then you can select the soft mode as follows:

We've added this in JIRA as a feature request here: https://jira.atlassian.com/browse/SRCTREE-1303

In the mean time, if you could use the above method instead which is essentially the same thing, then we'll look at getting it integrated into the commit dialog for 1.6.

Cheers

KieranA

Hi Marco,

I can see precisely what you mean by this. As you say, staging/unstaging hunks at the command line can be a pain.

git reset --soft HEAD^ (this will reset the HEAD to the prior commit, making your prior changes in the state of "changes to be committed")
From this point, you can then unstage the changes from your previous commit if you like if you made a mistake and/or stage other files
git commit -c ORIG_HEAD (to then re-commit)

So it doesn't do one action as technically git's amend flag doesn't support this, it's just issuing multiple commands to make it seem as if git's amend flag can do this.

Currently you can do this in SourceTree by resetting to the most recent commit's parent (HEAD^) as follows:

Then you can select the soft mode as follows:

We've added this in JIRA as a feature request here: https://jira.atlassian.com/browse/SRCTREE-1303

In the mean time, if you could use the above method instead which is essentially the same thing, then we'll look at getting it integrated into the commit dialog for 1.6.

Cheers

mprimi

Ah! That's great, I had missed it!

There is a small downside to this approach which is that the commit message is lost - for good.

Still good enough for me, I'm officially ready to switch to SourceTree with both feet!

Thanks a lot for your help and for this great product.

KieranA

The commit message will be in the "Recent messages" drop-down on the commit sheet just below the text area you input your commit message. Hit the drop-down and you should see the previous commit message.

Cheers!

Sandeep Anand

Hi Kieren,

Can you help me in my quest in sourcetree?

I am trying to produce the problem that one can have if he uses git --amend to amend an already pushed commit. I know the concept of the problem that can occur by this. But I want to produce it to demonstrate to my developers and create a little user guide for them on how to effectively use git --amend command.

I am not able to see what problem can occur if we amend a pushed commit.

What I am trying to do is:

1) Create a master repository,

2) Then clone it at two different places.

3) At one clone I make some changes and then commit them. Push them.

4) At another clone, I pull those changes, create a branch based on them and commit them. But do not push them.

5) Now back at clone one, I make some more changes and commit them with amend option and replace the recent commit that had already been pushed.

6) It does give me those two warning popup messages but I proceed through.

7) After that I go the clone2 and pull the changes, which come through. Now here I should see some problems, right? but I do not. so what issue has git --amend caused here?

Regards

Sandeep Anand

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

sourcetree

git

identity-manager