This project is read-only.


git tf checkin [--deep]

Checks in the changes made in the Git repo into TFS. By default, the checkin command will create a single TFS changeset for the aggregate of all changes made on the current branch in Git since the last checkin to TFS. When used with the --deep option, a TFS changeset will be created for each Git commit on the current branch since the last checkin to TFS.

Last edited Aug 9, 2012 at 10:49 PM by mmitrik, version 1


lenthe Sep 23, 2014 at 3:02 PM 
This documentation says that the changes from the current branch in git are what is checked in. That is not true. This always works from master. I tried this with a different git branch and it checked in from master. The code also shows that it is hard coded to use Constants.MASTER when committing.

Jimstein May 22, 2013 at 9:21 PM 
!OBS! even with --deep the checkin will lose the info about who was the original commiter, and reassign all commits with current user executing the checkin.

brianlow May 6, 2013 at 6:03 PM 
I believe the --deep option is enabled by default if you cloned your repository with --deep.

brianlow Jan 16, 2013 at 9:23 PM 
--renamemode=justfiles (this is the default in v2.0.1 release Jan 8, 2013)

Affects folder renames but not sure exactly how.

weisjohn Jan 14, 2013 at 2:45 AM 
can you add some docs here surrounding what happens on a successful checkin?

I stumbled across this on a repo that I'm working on, are these only made if a successful checkin happens?:

$ git tag

sstude Nov 18, 2012 at 8:56 PM 
Looks like --associate works only for last checkin, because all previous checkins are not associated with the TFS item.

pmiossec Oct 1, 2012 at 2:09 PM 
For the information, you could associate and resolve workitems with the command line options :
--resolve=<workitem id>
ID of the TFS work item to resolve during check-in
--associate=<workitem id>
ID of the TFS work item to associate during check-in