Comment by skybrian | Hacker News Reader

Comment by skybrian | Hacker News Reader

Parent Full thread

Coming from Perforce, I'd say that git's model seems overly rigid. In Perforce, workflow looks like this:

- edit files A, B, C, D, E in the default changelist. - put A and B in changelist #1 - put C, D, E in changelist #2 - oops, C is the wrong changelist. Move it to #1. - edit file F (starts out in default changelist) - put F in changelist #1 - send both changelists out for review. - edit file B based on review. Run tests to make sure both CLs work together. - commit one of the CL's

So the basic idea is that I have multiple changelists open simultaneously and the contents of the changelists are fluid. I can keep changing my mind about them until commit.

Of course, since Perforce CL's are file-based, this all breaks down if I want overlapping uncommitted CL's. Git handles that better, which is why I'm using Git now. But I still miss the ease of use of Perforce when working on multiple CL's. Sure, the commits in Git are only local and you can always edit them until you do a push, but it seems like I have to plan ahead more and commit more often, or I end up having to split or merge CL's using commands I'm not very comfortable with.

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).

You may want to check out http://porkrind.org/commit-patch/. It doesn't do changelists like you describe but it lets you check in fine grained stuff easier than "git add -i" (IMO). Especially if you are an Emacs user.

Reply on news.ycombinator.com