One-to-one mapping between git commits and TFS checkins about git-tfs

[spraints]

There isn't an easy way to do it. You could manually walk the revision tree and do git tfs checkin xxxxx for each commit in your tree. But that would be a pain.

git-svn has a dcommit command that I had
thought about replicating, but didn't. The basic mechanics aren't that
hard, I'm just not sure how to do the error handling right (e.g. what
if I cancel part-way through? does a rebase happen at each step?)

I'd be happy with a port of git-svn's
dcommit command.

[ivan-danilov]

Please take a look at this branch: https://github.com/ivan-danilov/git-tfs/tree/rebase-workflow

See details in my blog post: http://sparethought.wordpress.com/2011/06/21/gittfs-rebasing-workflow-is-it-possible/
It seems that it makes fine-grained workflow more or less painless. But I'm not sure if I did things correctly. Could you review my changes please?

[spraints]

I like.

I had a comment about the error message if the commit comes from the wrong branch that I made inline on one of the commits.

Also, what do you think about reworking it to be an rcommit command? e.g. git tfs checkin -r SOMEREF would become git tfs rcheckin SOMEREF?

[ivan-danilov]

My suggestion is to reserve rcommit to entire series of such checkins. So if we have tfs/default referencing HEAD^^ 'rcommit HEAD' would be equivalent to
$ git tfs checkin -r -m 'comment from git for HEAD^' HEAD^

now we have HEAD rebased and tfs/default = HEAD^ = changeset just checked in

$ git tfs checkin -r -m 'comment from git for HEAD' HEAD

If some conflict is happened - we just haven't other option then to leave last rebased state as it is and tell user the details.

I have been working with -r for about a week now and need to do this manually and enter comments twice was the only usability complaint so far.

As for your review - I'll make changes in 2-3 hours as soon as I'll be at home (there's just http read-only access to github from office unfortunately).

[ivan-danilov]

After some thinking... maybe it would be the simplest to have
a) '--no-merge' option for 'checkin' command that marks only previous TFS commit as parent but doesn't rebase
b) 'rcommit' command as described above

Thus, '--no-merge' is like plumbing option and 'rcommit' is porcelain one. I think such discretion will be easy to grasp for most git users.
What do you think about this?

[ivan-danilov]

ivan-danilov/git-tfs@de6c21c - exception and defensive check as you suggested.

[spraints]

The commit looks good.

As for the rcommit / no-merge idea, I like it. I think it will work well. (I would make it rcheckin instead of rcommit, though, in order to match the tfs language.)

[ivan-danilov]

Oh, yeah, you're right, rcheckin.

[ivan-danilov]

See branch. I've implemented rcheckin and --no-merge as we discussed earlier. It is even able to handle simple merges from other git branches. For example:
master: A [tfs/default;C1] <- B <- C <- D [merge commit, master ref]
branch: A <- E <- G [branch ref] <- D
Assuming merge commit has C as first parent and we are currently at refs/heads/master executing git tfs rcheckin preserves the structure and makes B' = tfs/default/C2, C' = tfs/default/C3, D' = tfs/default/C4 and D' has two parents correctly (I marked with ' new commits that were fetched from TFS as they're different from original ones because of rebasing). Comments of B' and C' are taken from B and C, comment of D' is comment of D concatenated with comments of E and G (i.e. some form of summary of the branch merging).

The thing I don't like is that I reused CheckinOptions because it is the only way I found to specify comment in the TFS checkin. And it leads to having in help some options that doesn't make any sense for rcheckin. For example --no-merge or --comment. I'll see for your review and suggestion on that.

[ivan-danilov]

Are there some ideas to think/implement?

As far as I understand, we just physically can't make git commit and corresponding TFS-commit (result of git tfs fetch) equivalent as long as we have additional info in form of git-tfs-id: [url];proj;changeset_number

Current implementation with rcheckin for series of commits and checkin for single merge commit is the best I could see at the moment. So the question is: should we close this issue or there's still something we could do to improve the situation?

[spraints]

I think this is resolved.