This is good news indeed, thanks for your feedback.
I guess some "git history squash" command would be useful too.
This is what frequently happens to me:
- I commit some code changes because the current project builds and tests fine.
- I start the "compile all projects" process, which takes about 1 hour.
- In the meantime, I commit other unrelated changes.
- After an hour, I realise that a silly mistake in the first commit makes compilation fail for some project.
I fix that and I trigger a "compile all projects" again, which takes 1 hour again.
- In the meantime, I commit yet another unrelated change.
- After yet another hour, the build process notifies me that I made yet another little mistake, and yet another project fails now.
The commit history looks like this:
- A - B - fixA1 - C - fixA2 - D - E
I only do a "git push" when the 1-hour compilation process succeeds. Before the "git push", I want to reorganise that into:
- A+fixA1+fixA2 - B - C - D - E
I know I can work with branches, but branches make everything more complicated. A linear history is easier, especially when you are working alone. Besides, it is not often that I make such silly mistakes. ;-)
Sometimes, fixing something in the Git repository is so complicated that it is not worth the trouble, so I leave an "unclean" history behind. For example, sometimes I have fixed merge problems by manually overwriting the code with the final new version, losing commit history in the process, in order to avoid having to deal with Git's idiosyncrasies.
Would it be possible to provide a "safe" way to do this "git history" operations? This is what I am thinking about:
1) Start with the messed up history:
- A - B - fixA1 - C - fixA2 - D - E [head]
2) Duplicate it:
- A - B - fixA1 - C - fixA2 - D - E [head]
| A - B - fixA1 - C - fixA2 - D - E [attempt]
3) Try to clean the history of [attempt] with the new "git history reorder" etc.
4) If successful, move [head] to [attempt], and we are done.
5) If not successful, drop [attempt] and possibly leave the messed up history in [head], because the cost of fixing it would be too high.
The first duplication step is what gives me the peace of mind that, if I screw something badly, I can always drop [attempt] and go back to my original state.
I know it would be better to learn Git "properly" and do things "right", but Git is often not very user friendly, and there are other priorities in life.
Regards,
rdiez