Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Unshelve should create a git branch #138

Open
sc68cal opened this Issue Feb 14, 2012 · 6 comments

Comments

Projects
None yet
4 participants
Contributor

sc68cal commented Feb 14, 2012

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

@ghost ghost assigned sc68cal Feb 14, 2012

Owner

ivan-danilov commented Feb 16, 2012

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 :)

Contributor

sc68cal commented Feb 16, 2012

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.

Owner

spraints commented Feb 24, 2012

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.

Owner

spraints commented Feb 24, 2012

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.

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.

Owner

spraints commented Mar 30, 2012

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