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@gmail
reposurgeon-add-help.patch
Description: Binary data
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
