Deep checkin needs to preserve author

Feb 7, 2013 at 4:09 PM
A deep checkin should at least have a switch to preserve the author of the commit. The relevant code appears to be in the source ready to be used. I have modified the source and tried it out, and it seems to work without issue. Can we please have this as part of the next release?
Developer
Feb 7, 2013 at 4:21 PM
Hi,

I believe, if you use the --metadata option in the checkin command, comments will include auther's name. The default value has been changed to --no-metadata in the lat release according to customers' request. Or did you mean something different?
E.g. an ability to control the meta-data content in case the --metadata parameter is specified?

Alex
Feb 7, 2013 at 4:30 PM
Edited Feb 7, 2013 at 5:23 PM
I mean that I want the Author in TFS to match the Author in Git. E.g. in CheckinPendingChangesTask.java, public TaskStatus run(...)

changesetID =
                workspace.checkIn(
                    changes,
                    null,
                    null,
                    comment == null ? commit.getFullMessage() : comment,
                    null,
                    workItems,
                    null,
                    checkinFlags);
becomes

changesetID =
                workspace.checkIn(
                    changes,
                    commit.getAuthorIdent().getName(),
                    null,
                    comment == null ? commit.getFullMessage() : comment,
                    null,
                    workItems,
                    null,
                    checkinFlags);
Now obviously it would need a lot more than this one change to be "production ready", but this at least proved that there is no great impediment. I assume it is akin to using "tf checkin [/author:author name]". This feature is absolutely crucial to using Git-TF for a team rather than an individual.

Just to add: The problem with the metadata approach is that the metadata does not play well with TFS and is not bi-directional. For example, the metadata is useless when performing an annotate inside TFS. In addition, if I were to create a new Git repository from the changesets generated with this metadata; the metadata is not interpreted by Git TF and hence is a lossy operation. The author is the most important piece here, and also the easiest bit of metadata to properly add (as it is already part of the Git commit).

Ideally there would also be a way to associate work items to each commit, as well as the code reviewer. I am still ignorant in the ways of Git, but perhaps Git Notes can be used to add the required metadata at commit time, so that Git-TF could then use it when committing into the TFS database? You would need to define the template for this of course. Git-TF should also add these notes when pulling the data out of the TFS database.
Developer
Feb 7, 2013 at 5:25 PM
Hi,

I'm afraid we cannot rely on that the commit's author name matches to the TFS User Name, but probably we could at least use the commiter's name as an author's display name (the next parameter in the same call)?

Could you please copy your request to work item so people could vote?

Alex
Feb 7, 2013 at 6:04 PM
This is why it needs to be a switch or a config option. You cannot rely on the author of the commit matching a TFS User Name, but in my team, I can . Although I should point out that TFS does not care if the author name matches a valid TFS User Name. It will happily checkin the changeset with any old name. (To be honest, I do not understand the difference between the display name and the author name).

To me, this kind of functionality is fundamental to your strategy of having an integrated Git server in TFS and a Git client in Visual Studio. You are going to have to sync all this TFS metadata into Git to have a workable solution. I want to be able to have third party teams interact via Git, into a central TFS repository, with no loss of information or functionality. Right now I can live without the Code Review notes, or the Work Item ID. But I can't live without knowing who made the commit.
Developer
Feb 7, 2013 at 6:17 PM
Hello l_o_l,

I agree that maintaining the check-in user and commit author parity between git and tfs is essential. In fact we do have a backlog item on our team to fix this in git-tf and make sure that the check-in in user in tfs is equivalent to the commit author. Unfortunately, this is not as simple as updating the check-in user name the workspace.checkin call due to the difference between the way tfs and git handle identities.

In tfs identities are not just the user display name or email, identities are more complex due to the rich security options in tfs. For example we allow duplicate display names in the tfs system for companies that have users with similar names in their org etc. To fix this correctly essentially what we need to do in git-tf is rely on the tfs identity service to match the git commit author first, if there is ambiguity or multiple users that match we need to figure out a way to resolve this ambiguity so that the check-in user value is handled correctly.

That said, we do have a backlog item to take dependency in git-tf on the tfs identity service to enhance this scenario and make it better.

Thanks for your feedback, please let us know if you have any other suggestions or feedback regarding git-tf :)

Thanks,
Youhana
Developer
Feb 7, 2013 at 6:28 PM
Hi,

IMO, these two things do not contradict: the sophisticated solution based on the TFS Identity Service and the simple one, suggested by l_o_l, i.e. to provide an option that allows the user (on his own risk) postulate that user names in his Git repository and in TFS server are identical. In the worst case the checkin will fail (with a clear error message I hope), and the user may decide what to do: ommit the parameter and ignore user names, correct user names to match between Git and TFS, or ... wait for the sophisticated solution. :-)

Alex