Re: [PATCH] contrib git-resurrect: find traces of a branch name and resurrect it

On Friday 2009 January 23 14:03:05 Thomas Rast wrote:

Boyd Stephen Smith Jr. wrote:

quoted

I think it could be quite nice; "undelete"-type commands are generally
well-received by users and when run against reflogs alone, that's what the
command is.

It's useful enough to me that I'd love to see it mainlined.

So here's a version for contrib with more options and some other
tweaks.

I wanted/needed the ability to ignore reflogs entirely.  Use went something 
like this:
1. resurrect branch from origin/pu
2. add patches, mail to list
3. # wait 24 hours
4. pull, see from logs that branch was modified, but not just my changes (or 
without all of my changes).
5. delete local branch
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. :)

Would you object to a patch adding a --reflog option and allowing each of the 
scan options to be negated?

I removed the ability to "batch resurrect" with several <name>
arguments since that would have conflicted with -b <newname>, but
otherwise the features are the same.

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?

quoted

In my particular case, it wasn't useful without the -m option, but I
understand why it is not the default.

Aside from the obvious speed reasons, I don't really want to teach
people that commits "know" the branch they were on.  It is a pure
coincidence if you can resurrect a topic branch from merge messages;
an equivalent merge could have gone through as a fast-forward, and
you'd never know.

Yeah, agreed.  I made this more clear in my local version by changing the 
documentation from "scan for merges" to "scan first line of commit messages 
for possible merges".  It's more wordy, but it make it clear that it is 
dependent on the message, and it's not tracked outside of that.

I also tend to merge topic branches with --no-ff so that I do get the merge 
message, so it has a better chance of working against my repository.  (I also 
enjoy octopus merging when possible so the history indicates the patch sets 
are separable, but maybe I'm just a little "touched" and haven't been bitten 
by by an octopus yet.[1])

Not directly related to any issue you bring up:

There seems to be some needless redundancy between USAGE and OPTIONS_SPEC.

Would you object to a patch that used $USAGE inside OPTIONS_SPEC?
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[1] I hear they are even more feral than penguins.