On Friday 2009 January 23 14:03:05 Thomas Rast wrote: >Boyd Stephen Smith Jr. wrote: >> 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? >> 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@xxxxxxxxxxxxxxxxx ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ [1] I hear they are even more feral than penguins.
Attachment:
signature.asc
Description: This is a digitally signed message part.
