2

When using a versioning system, one is often tempted producing 'clean' commits, ie commits that actually make sense, and are compilable (and nice to read for other developers).

As a natural effect of this, commits are usually done pretty late ('when it works').

It mitigates one of the benefits of version control : being able to revert to a state where 'it used to work' and where you wouldn't have rage-deleted a huge chunk of code which wasn't yet committed.

Eclipse has a built-in function for this (local history), but it is IDE dependent.

Is there any similar mechanism with one of the popular VCS (git, mercurial..), potentially as an extension/plugin?

Ideally, it wouldn't interfere with the main commit history, but maintain a parallel 'history of uncommitted changes'.

If such a thing doesn't exist, I might be tempted to write one.

Clarification : I'm well aware of the local branch + rebase or histedit, but I'm asking for an automated and easy to setup solution. If I have to commit frequently I may has well forget/get lazy about doing it, especially if it implies manual clean up (the rebase part) later, for each real commit. The main goal is to provide a safety net for the developer, and people usually realise they need that net just when they are already falling...

Cœur
  • 37,241
  • 25
  • 195
  • 267
Mikarnage
  • 893
  • 1
  • 9
  • 24
  • Have you looked at any of the distributed VC systems? I'm pretty sure that the local branches of git (etc.) are very close to what you are looking for. Maybe sprinkle some automation help (cron, etc.) on top of that. – reto Dec 03 '14 at 10:39
  • Why don't you create a junky branch where you can do some tests and commit even bad non compilable code? you work in this branch and if it gets somewhere, you can merge it into the main one, and else it goes to trash. You'll still have to commit but as you don't care about commiting something bad, you can do it very often. – grorel Dec 03 '14 at 11:00
  • "late and nice commits" is bad style and anti-pattern today – Lazy Badger Dec 04 '14 at 09:02

3 Answers3

3

I am not aware of any tool that does this, but you can do it using Git.

Create a local branch and work on that (commit often, revert, etc). Once you are happy with the work, you can use git rebase -i to squash all the small commits into one (or more) large commits into your development branch.

AesSedai101
  • 1,502
  • 2
  • 23
  • 37
0

You can have (in Mercurial, f.e ):

  • branch for WIP-commits, in which you commit dirty work and merge this branch into mainline only after some "point of stabilization" and only these mergesets should be of interest to others (with push -b $MAINLINE instead of default "push-all" you'll not publish any unfinished work)
  • MQ extension (or Shelve extension), in which set of patches|patch in queue(s) is your current work (and they aren't shared|published), polished patches converted into permanent changesets and become a part of (pushable) history
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
0

In mercurial, the way I do exactly this is to use "hg commit --amend" in conjunction with the evolve extension.

Normally, (assuming your current revision is a head changeset) "commit --amend" will modify your current parent changeset. So you would do this at each point you decide you have something worth saving. This keeps the history clean as you desire.

When used in conjunction with the evolve extension, "commit --amend" preserves the previous commit as a hidden changeset. These hidden changes are visible using "hg log -hidden" (and also in tortoise when the right button is pressed). So you can go back and view all your partial work, but the hidden changesets will not be pushed.

PS. Don't worry too much about the "experimental" status of the evolve extension. It's well tested.

John Jefferies
  • 1,176
  • 7
  • 13