Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Unshelve should create a git branch #138

Open
sc68cal opened this Issue · 6 comments

4 participants

@sc68cal

With name of the shelveset if branch name is not given. Bit of a convenience.

@sc68cal sc68cal was assigned
@ivan-danilov

Unshelve sometimes gives very odd results, mostly because (IIRC) I didn't found the way to determine from which TFS checkin shelveset was made. So it seems it just changes current HEAD's tree so that it becomes identical to shelved one - and this leads to strange history log (commits between original shelve point and HEAD look like they were reverted by unshelve).

Thus said, this issue is valid one, but I'd prefer unshelve works correctly first and convenient then :)

@sc68cal

I didn't found the way to determine from which TFS checkin shelveset was made

I thought that's because shelvesets are unversioned?

http://msdn.microsoft.com/en-us/library/ms181403.aspx

Unlike a changeset, a shelveset is a non-versioned entity.
If you or another user unshelve the items of which a shelveset consists, edit several files, 
and reshelve the shelveset, Team Foundation does not create a new version of the 
items for future comparison and maintains no record of who revised the items, when, 
or in what manner. The original shelveset is completely replaced.

So it seems it just changes current HEAD's tree so that it becomes identical to shelved one - and this leads to strange history log

Yes, I've seen that behavior myself. The shelveset goes into Git, and any changes that would have triggered a merge
conflict are silently resolved in the shelveset's favor.

I'll check it out while I'm working in my libgit2sharp_dev branch, but for now I just want a quick tweak of the command's behavior.

@spraints
Owner

It's been a while since I've looked into this, but we might be able to get the starting version for a change in a shelveset? If we can, we could derive a diff, and try to patch.

@spraints
Owner

If it is possible to get the starting version, the reason that I didn't do anything with it was that the work would need to be done per file, not per shelveset. FileA could have initial version 2, and FileB could have initial version 12345.

@Griffitsj

I have found that unshelving a shelveset twice results in the same SHA-1 value being generated by Git. I found this because I unshelved into a new branch - somehow messed up the branch, deleted it and tried to unshelve again into a new branch only to find the messed up changes were recreated.

I think this problem is caused by the Commit Date being set to the shelveset creation date, which is also the Author Date. Because the commit is originating from a shelveset (not a real commit) then commit date should be set to current date and leave Author Date as the shelveset creation date. This should result in a new SHA-1 for each shelveset AFAIK, and resolve this kind of issue.

@spraints
Owner

The unshelve command is still a bit experimental.

That said, I prefer that git-tfs unshelve to a commit as closely to identical as it can, given the same shelveset and parent ref. If you want to move the commit data after unshelving, git comes with a cherry-pick command that will apply the patch anywhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.