Darcs Support: Parses logs of newer version of darcs. Use hashes as tokens instead of patch names.

[lowfatcomputing]

I have modernized the darcs_support a bit and now it parses log files of current versions of darcs (tested with darcs-screened). I have also switched to hashes because they are more precise.

All darcs tests pass now except for one:

  5) Failure:
test_cat_file(OhlohScm::Adapters::DarcsCatFileTest) [/home/andreas/repo/ohloh_scm/test/unit/darcs_cat_file_test.rb:25]:
<"/* Hello, World! */\n\n/*\n * This file is not covered by any license, especially not\n * the GNU General Public License (GPL). Have fun!\n */\n\n#include <stdio.h>\nmain()\n{\n\tprintf(\"Hello, World!\\\\n\");\n}\n"> expected but was
<nil>.

I think the problem is here:

lib/ohloh_scm/adapters/darcs/cat_file.rb:           out, err = run_with_err("cd '#{url}' && darcs show contents -h '#{revision}' #{escape(path)}")

When I remove a file from a darcs repo and then run darcs show contents -h <hash> <file> on a revision that did have the <file> I get nothing. This may be a problem with darcs (?)

#10

[neilmayhew]

@lowfatcomputing: Has this superseded #10? Can the failing test be ignored? It would be good to get this merged before conflicts arise again.

[lowfatcomputing]

Can someone tell me how to hide all these unrelated commits from this pull request? I've forgotten some of this git stuff.

Also, I believe the darcs show contents -h <hash> <file> bug has since been fixed.

[neilmayhew]

@lowfatcomputing, I assume the extra commits are because you did a merge with upstream via git pull. If you rebased instead of merging (eg with git pull --rebase) it would clean up the PR and show only your commits. You'll need to push -f to overwrite the current state of the branch in your fork.

[lowfatcomputing]

Well that didn't work. (Tried git pull --rebase and git push -f)

[neilmayhew]

Well, it depends how you measure "worked". I looked at the graph in gitk and it looks fine to me. However, I'd missed the fact that there's already a darcs_support branch in the upstream repo, and that your rebased branch would break the connection with that. OTOH, there's now a clean series of commits that reflects what's being contributed in a clear way. The original authorship metadata is preserved by the rebase, so there shouldn't be a problem with attribution.

Rebasing is ultimately a matter of taste. Many prefer it, some don't, especially those from a traditional (non-distributed) VCS background where history is immutable because it's shared from the outset.

If you want to get back to the branch as you had it before, git reflog is your friend. Use git reflog darcs_support to see the various states the branch tip has been in. Select one, and use git reset --keep HASH to get back to it.

[neilmayhew]

If you change the target branch to master the conflicts will go away. However, that may not reflect how upstream wants to manage the PR.

[lowfatcomputing]

Also, it looks like travis-ci was installing darcs-2.7.

darcs-2.12.0 would need to be installed for all the darcs bug fixes.