Possible to extend history back before quick-clone changeset?

[JamesDunne]

Is it possible to pull in earlier TFS changesets to the git repo before the quick-clone changeset? If so, how?

[spraints]

Not, it's not. Or, at least, not easily. Because of git's sha1 thing,
if you add a parent commit "P" to a commit "A", A will get a new sha1
id. So git-tfs can't backfill in front of a quick-clone commit.

What I would do, if I wanted to use quick-clone to get going quickly
and then back-fill the full history later, is:

1. git tfs quick-clone to working dir "A", and start working.
2. git tfs clone into another repository "B" and let it run in the background.
3. Migrate the commits from "A" to "B". This could involve either
   fetch/cherry-pick or format-patch/am to get the commits from "A" into
   "B"; but it could also be a simple copy-paste of the latest state in
   "A" to "B". This part will be a pain to deal with, but git makes it
   possible to do this a lot better than almost anything else.

Honestly, though, if it was just me using git-tfs and the rest of the
team using TFS (i.e. the "official" code is going to stay in TFS), I
would do a quick-clone + fetch, and use TFS to look at older history.

If you're migrating permanently, do a full clone. There are TFS
histories that cause problems for git-tfs (e.g. issue #4), so a clone
might not be feasible. In that case, I'd hack quick-clone to take a
"starting TFS version" and effectively ignore history older than that.

HTH.

On Tue, Mar 15, 2011 at 6:06 PM, JamesDunne
reply@reply.github.com
wrote:

Is it possible to pull in earlier TFS changesets to the git repo before the quick-clone changeset? If so, how?

Reply to this email directly or view it on GitHub:
https://github.com/spraints/git-tfs/issues/28

[JamesDunne]

It is just me using git-tfs and everyone else using TFS so I resorted to a simple view history in TFS. It's just so much nicer to use gitk though.
I have a fork of your git-tfs where I made some DownloadFile "improvements" (not really sure if they improve anything yet), so I'll try adding the "starting changeset" option to quick-clone. Or maybe I won't, since it's not that important. :)
Anyway, thanks for your help!

[spraints]

I agree on gitk (or gitextensions, or gitx).

Did your DownloadFile changes speed things up?

On Wed, Mar 16, 2011 at 11:37 AM, JamesDunne
reply@reply.github.com
wrote:

It is just me using git-tfs and everyone else using TFS so I resorted to a simple view history in TFS. It's just so much nicer to use gitk though.
I have a fork of your git-tfs where I made some DownloadFile "improvements" (not really sure if they improve anything yet), so I'll try adding the "starting changeset" option to quick-clone. Or maybe I won't, since it's not that important. :)
Anyway, thanks for your help!

Reply to this email directly or view it on GitHub:
https://github.com/spraints/git-tfs/issues/28#comment_881009

[JamesDunne]

Only marginally as far as I can tell. It did cut out the CPU utilization from GitSharp.Core's ObjectWriter since I removed the need to download to a TemporaryFile by using the DownloadFile() overload that returns a Stream. I also added the ContentLength property to the IItem in order to pass to the ObjectWriter. Feel free to check it out; it's a small set of changes.

[hazzik]

I wonder if git tfs already does use intensive history rewrite, why just dont allow to do following

1. git tfs quick-clone
2. do some work, commit, commit, commit
3. git tfs <something> -c C1234

Where will do following:

1. get changesets between C1234 and previous first CS of git quick-clone
2. rebase on top of new quick-cloned repository

Of cource this will not work for quick-clones made public, but anyway this should never happen

[hazzik]

Also this can be done using git graft or git replace