Hi Stephen,
Sorry for the long delay. I'm going to roll a v2 with two small
fixes. After that it's all yours ;-)
Boyd Stephen Smith Jr. wrote:
[...]
> 6. Try to resurrect branch from origin/pu, get local version I just deleted.
> 7. delete reflog for that branch
> 8. Try to resurrect branch from origin/pu, get local version I merged into
> master at some point.
> 9. Add new option.
>
> So, I added a couple of options locally: --only-merges, so it would only look
> at the first line of commit logs, ignoring my local reflogs entirely;
> and --revisions, to specify arguments to pass to rev-list so it wouldn't even
> see my local merges (I passed 'origin/pu origin/next').
>
> Yeah, my usage might be abusage, but it worked for me. :)
I'm fine with adding such an option, but I still wonder what was wrong
with the original scheme of asking 'git rev-list -1' for the newest
commit. I thought rev-list always listed by date, so that command
should always pick the newest candidate commit from all candidates
selected. Do you have an example where that breaks? Or did you just
have a use-case in which you wanted something other than the newest
candidate?
> In my local version, which I was going to try and clean up over the weekend, I
> was going to support both, by borrowing refspec syntax from fetch/push.
> Specifically. Resurrecting 'js/notes' as 'pu/js/notes' would look like:
> git-resurrect -H js/notes:pu/js/notes
>
> Would you object to a patch that dropped -b in favor of the refspec syntax?
No, that would be fine by me.
> There seems to be some needless redundancy between USAGE and OPTIONS_SPEC.
>
> Would you object to a patch that used $USAGE inside OPTIONS_SPEC?
Also a good idea.
--
Thomas Rast
trast@{inf,student}.ethz.ch
Attachment:
signature.asc
Description: This is a digitally signed message part.
