On 1 March 2018 at 22:20, Junio C Hamano <gits...@pobox.com> wrote: > Here are the topics that have been cooking. Commits prefixed with > '-' are only in 'pu' (proposed updates) while commits prefixed with > '+' are in 'next'. The ones marked with '.' do not appear in any of > the integration branches, but I am still holding onto them. > > You can find the changes described here in the integration branches > of the repositories listed at > > http://git-blame.blogspot.com/p/git-public-repositories.html > > -------------------------------------------------- > -------------------------------------------------- > [New Topics] > > > * ld/p4-unshelve (2018-02-22) 1 commit > - git-p4: add unshelve command > > "git p4" learned to "unshelve" shelved commit from P4. > > Will merge to 'next'.
The unshelve change should be left off next for now. The problem with it is that it can't easily find a sensible consistent point prior to the shelved changelist to generate the diff from (P4 has no concept of a tree revision). So you can end up "unshelving" and pickup not only the shelved changelist, but also a bunch of intervening changes (or the effect of some missing changelists). That can be quite surprising. This is actually pretty close to the behaviour of P4 unshelve itself, which does somewhat the same thing. From the p4 manual page: https://www.perforce.com/perforce/doc.current/manuals/cmdref/Content/CmdRef/p4_unshelve.html " Unshelving copies the shelved files into the user’s workspace as they existed when they were shelved. (For example, a file open for edit when shelved will also be open for edit in the unshelving user’s workspace.)" There's a better change which I posted which adds a "git p4 format-change" command which uses the diffs from Perforce. I think that has a better chance of working properly. I had some review comments which I need to take, after which it could be a candidate for next. It _might_ though be possible to resurrect the unshelve code by doing something like extracting the previous versions of the files (which is kind of doable) and then constructing a temporary branch in git to do the comparison against. Sounds pretty nasty though. Thanks Luke
