[Nut-upsdev] Mixed-commit problem solved

[Charles Lepple]

On Jan 6, 2012, at 7:34 PM, Eric S. Raymond wrote:

> # 1. Have yet to find a clean merge point for any branch.

I am trying to leverage reposurgeon to automate the process of finding merge points, and I seem to be spinning my wheels. Can you provide an example of how you are searching for merges?

e.g.

reposurgeon% merge (apcsmart-dev)
reposurgeon: :11392 cannot merge clean at target :11808
reposurgeon: target :11808 is out of date on these files: docs/man/apcsmart.txt drivers/apcsmart.h drivers/apcsmart.c

# This doesn't seem to be the right merge point, but maybe that's because '(apcsmart-dev)' represents the whole branch.

reposurgeon% list /merge updated apcsmart/
 11807 2011-09-12T09:54:55 merge updated apcsmart driver from apcsmart-dev branch                                                  

reposurgeon% list (apcsmart-dev) & =H
...
 11800 2011-09-12T09:04:33 apcsmart: minor Makefile.am change                                                                      

reposurgeon% list /merge updated apcsmart/
 11807 2011-09-12T09:54:55 merge updated apcsmart driver from apcsmart-dev branch                                                  

reposurgeon% merge 11800 11807 
Seeking merge point......(1.48 sec) done.
reposurgeon: :11808 can merge clean at :12200
reposurgeon% list :12200
 12193 2011-11-23T08:46:35 Create Eaton_SDK branch                                                                                  

# I am not sure why this merge is so far down the trunk - it was definitely merged before v2.6.2.

At the very least, I am a little more comfortable with the reposurgeon interactive shell, so that should speed up my process of finding the rest of the merge points.

> # 2. set-eol-style operations get lost; see tags windows-set-eol, reset-eol.

Again, I think we're okay with that. But I don't have a Windows setup to test with.

> # 3. Should the first Eaton_SDK commit after the deleteall have a link
> #    back to trunk?

Yes, and not to the deleteall (which should be tagified).

> # 4. Is the new_UIs-root tag still useful?  It doesn't seem to point 
> #    at an actual branch.
> 
> Also, some remaining zero-fileop commits on the root branch should
> probably be tagified.

I haven't had a chance to look at the last two.

I'd add this to the list: "5. with multiple fossil references in a line, only the first gets lifted." 

Especially where merges are concerned, the results will get unwieldy - one-line descriptions are often well over 80 characters. I think it might be time to revisit the alternate style I proposed a while back (which can probably be handled through editing *.box) where we use a footnote-like syntax. If this were automated (and I wouldn't mind taking a shot at it) we could also add short Git hashes to help with quickly navigating through the tree in gitk (since they turn into clickable links). Long-term it might be nice to patch gitk to understand your commit ID format.

Also attached is a patch to fix the help for several commands (they did not print anything in the interactive mode).

-- 
Charles Lepple
clepple at gmail


-------------- next part --------------
A non-text attachment was scrubbed...
Name: reposurgeon-add-help.patch
Type: application/octet-stream
Size: 2138 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120108/69184d5c/attachment.obj>