Honestly, about the only reason I want this is because I have found I rather often forget to add new files to a changeset, and then have to promptly make a second changeset of "add new files missed in previous changeset".

But honestly, being able to group multiple _actual_ changesets into a single _virtual_ one would be even better; no need to rewrite history, but a nice way to keep the overall branch explorer clean.

"Now, let’s follow the rule we all use: checkin with the reviewer in mind. Every checkin has to help the reviewer follow your train of thought, follow your steps to understand how you tackled the task.

First, you see 21 files modified, but the comment says it was just about cleaning up some C# usings. The list of 21 files is not terrifying anymore; it is just about removing some easy stuff. You can quickly glance through the files or even skip some of them.

Then, the next 12 files are just about a method extracted to a new class, and the affected callers having to adapt to the new call format. Not an issue either.

Next comes 51 files, but the comment clearly says it is just because a method was renamed. Your colleague is telling you it is a trivial change, probably done thanks to the IDE refactoring capabilities in just a few seconds."

This absolutely great idea from the Plastic Book is less attainable without amendments, and extra difficult without the ability to stage individual lines (index vs head). You can tell a better story with a single "removed unnecessary usings" commits than with three that are spread out over your working session. Professional writers don't go top to bottom in a single pass - articles are revised. "Telling a story with my commits" is the #1 thing that I use Rebase for in Git. Plastic forces you to tell that story the same way you would if you were thrust in front of an audience - "actually, wait, I forgot something, let me go back a step..." is not as easy to follow.

Sometimes I'll change my mind multiple times throughout developing a feature as to how a certain class should be named. History amendment helps clear that up. The arguments against history amendment are sufficiently addressed as long as amendment is only possible for changesets that haven't been pushed yet.

I think it would be great to be able to amend changesets, however not at the cost of rewriting history. I'd prefer an approach like Fossil's where modifications to existing records are performed by adding new records.

I agree with Rupert. Just ran into that exact use case. I just checked in some changes and realized I missed a few other changes which I'll have to add to as a separate commit. It would be great to be able to amend commits that haven't been pushed to the server.

Is there even any difference between local and pushed changes if there is no amend / reset function? I'm really hoping that something like that will be added.

I'd like to be able to amend the latest changeset, at least when in distributed mode when it's not been pushed to a central server yet. I can see the value of immutable history but doesn't feel so critical when the history hasn't been shared yet.

It might be nice if amend commits were treated as a purely visual thing, while internally still treating each amend as an individual commit.
So essentially what it does is hide a bunch of nodes inside a single node, with a different description. This way, if someone works on or branches from one of those nodes, nothing breaks.

This could even add another useful feature: Select a couple of nodes and (visually) squash them into one. I'd love to be able to logically clean up our timeline at the end of the week.
And the opposite: Opening up such a node and looking at the individual commits that went into it.

There are some situations where I like to use branches to save pending work (as shelve or git stash). I prefer this workflow from shelve or git stash because it keeps track of the parent so I can revert to the exact same state I was. Also I like being able to see all my pending work in the branch explorer.

Unfortunately, save current work in a branch give a WIP changeset which often does not contains meaningful description and valid content. I wish it does not appear in the history.

I would like to be able to amend and rewrite history for at least "my private changeset": changeset only on my local computer or pushed on the server but nobody can see except me or my approval (similar to mercurial 'phase' feature).

I like history immutability but sometimes I just check-in something wrong (forgot to add a couple of files) so I would like to change latest changeset of my branch.

It works okay in Git because you can amend before pushing to the server. But in Plastic SCM it should rewrite the history :(

Personally, I value immutable history highly. I would appreciate an amend feature as long as it does not complicate questions like 'does my colleague have the latest changes from branch X in their current workspace' and 'what was the exact set of input files when build Y was produced'.

We find that working with per-task branches, it is not a problem to have extra commits for amends. It is when working on a single branch (usually directly on main) that amend operations would be valuable to us. Therefore, we try to use task branches as much as possible.

Hi Rober! :P

Rewriting history is one of the cool features in Git, but it is somehow counter intuitive in the commercial software development world where you would like version control history to be immutable.

That being said, sounds like a cool thing to do.

Now, is your graph correct? I mean, what D-E-F have to do here? Not sure if I'm missing something.