This project is read-only.

"git tf checkin --deep" with gated checkin

Nov 4, 2012 at 5:53 PM

I'm brand new to using git tf. The first thing I tried was to create two git commits and then push them up to TFS. I used the command:

git tf checkin --deep

Since this is a repository that is configured with gated checkin, I got this output:

Checking in to $/[my server]: 50%, checking in
git-tf: check-in aborted, pass --bypass to bypass gated check-in
Your check-in could not be completed because it affects the following gated build definitions.
  \[my project]\Immutable Build (Main, Gated)
  \[my project]\Full Build (Main, Gated)
To complete your check-in you will need to queue a build of the shelveset Gated_2012-11-04_09.41.06.6085;[my-tfs-account].

Looking at this shelveset in TFS, I see it has only one git commit in it (which I sort of expected). But this looks like it's going to be extremely tedious. I plan to make a dozen commits at a time and push them when I'm on my work network. Ideally, just like in a native git environment, I'd expect to push a merge of my work into the shared repo so that all my commits are preserved and seen as an isolated set of changes that were merged (truly showing the progression of work).

Ideally I'd like to see TFS support this flow by handling checkin of this type of operation all automatically this way:

  1. Create a branch in TFS. This branch is not subject to gated checkin.
  2. Check in all my commits (--deep) to that branch in a row (preserving commit author and timestamp).
  3. Merge the temporary TFS branch into the public branch that I was originally pushing to, and check that in.
  4. When gated checkin applies on step #3, create a shelveset as you already do. Either ask me which gated checkin queue to use, or as you do now, have me submit the shelveset manually. The shelveset would reflect that this is a merge, and upon checkin, someone reviewing TFS history would see the branching described in the earlier steps.

Is this achievable?


Nov 12, 2012 at 10:40 PM


Thank you for your suggestion. I understand why this scenario can be painful, because you are trying to checkin "--deep" using a gated build which will result in the experience you are seeing above. there are a couple of workarounds for this (each with some trade offs):

1) checkin --shallow : this off course will checkin all commits as one change so history is lost here

2) checkin --deep --bypass : this will bypass gated checkin for all your changes, but will commit all your changes in "deep" mode. After the deep checkin operation is complete. You can queue a new build in the gated build definition from Visual Studio or Eclipse to ensure that your build was not broken.

Thanks for the suggestion above, need to think about it for a little bit to see how this can fit in the git tf design.

Thanks for your suggestions again. Please let us know if you have any other suggestion, issues or feedback regarding git-tf.