Not sure if you know about Perforce's shelving feature, but it might be useful for you. Here's how it looks:
1. Hack on files 'foo' and 'bar', but instead of saying `p4 change`, say `p4 shelve`. Write down the changelist number for later; this changelist is stored on the server now.
2. `p4 revert foo bar`. You don't lose any changes; they're all on the server.
3. Hack on files 'bar' and 'baz'. Submit or shelve those changes.
4. `p4 unshelve -c (changelist number from step 1)`. (You'll probably need to resolve here.) Your original changes are back!
Git certainly breaks down if you're working on one massive branch, but it's designed for lots of branching. Go ahead; we're encouraging you to branch for every new feature, every bug fix, everything. Here's the above workflow in git:
1. `git checkout -b first-change`. Hack on files 'foo' and 'bar' and commit.
2. `git checkout old-branch`, where 'old-branch' is the branch that you were on before step 1, probably 'master'. Now `git checkout -b second-change` and edit files 'bar' and 'baz'. Commit again.
3. Checkout the old branch (master, likely) again. `git merge first-change`. `git merge second-change`. Resolve if required. Test. Push changes to the remote server.
Best of all, you don't need to branch before making your changes. You could actually move the `git checkout -b first-change` to after the edits on that branch, and it would still do what you want.
I find local branch really nice, but do you really work on all thoses change at the same time ? I tend to code quite linearly, one functionnality at a time. May be I'm working on too small projects ?
In that case, it doesn't really seem that you would notice much of a difference between Perforce, git, or what have you. Well, maybe between CVS and earlier (which tracked changes per-file) and SVN and later (which track them per repository).
1. Hack on files 'foo' and 'bar', but instead of saying `p4 change`, say `p4 shelve`. Write down the changelist number for later; this changelist is stored on the server now. 2. `p4 revert foo bar`. You don't lose any changes; they're all on the server. 3. Hack on files 'bar' and 'baz'. Submit or shelve those changes. 4. `p4 unshelve -c (changelist number from step 1)`. (You'll probably need to resolve here.) Your original changes are back!
Git certainly breaks down if you're working on one massive branch, but it's designed for lots of branching. Go ahead; we're encouraging you to branch for every new feature, every bug fix, everything. Here's the above workflow in git:
1. `git checkout -b first-change`. Hack on files 'foo' and 'bar' and commit. 2. `git checkout old-branch`, where 'old-branch' is the branch that you were on before step 1, probably 'master'. Now `git checkout -b second-change` and edit files 'bar' and 'baz'. Commit again. 3. Checkout the old branch (master, likely) again. `git merge first-change`. `git merge second-change`. Resolve if required. Test. Push changes to the remote server.
Best of all, you don't need to branch before making your changes. You could actually move the `git checkout -b first-change` to after the edits on that branch, and it would still do what you want.