[#6686] changed git to pull last commit info directly from the SCM instead of mongo, and SVN already did the same. Now we just need to change the Mercurial browser to do the same.
In the test, it'd be better if it was clear why the error handling would be invoked.
It'd be better to timing out rather than hanging, when something does goes wrong in the threads and isn't caught.
There's quite a bit of logic overlap between hg & git's last_commit_ids: http://pastie.org/8547562 Could that be refactored and shared?
Git's implementation specifies no_merges=True, we should be consistent with hg. hg log takes a --no-merges param; can we do this with cmdutil.walkchangerevs though? I prefer no merges, but showing merges on both would be ok too. It also seems that merge commits aren't displayed in log view (either via allura or commandline, which I don't really understand). Example: merge commit ada01d on /NEWS.txt in the SF 'coils' repo. Which makes it confusing when you see the merge commit on the tree view but not the history view.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rebased and force-pushed to: allura:cj/6821 forgehg:cj/6821
Removed the merge commit filter from git because: 1) that was easier, and 2) it more closes matches what you would see from git log on the command line (and also on the history / log view on the web).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ugh. The behavior of git log with respect to merge commits appears to contradict the detailed explanation under History Simplication (specifically the bits about the default mode and --dense). Apparently, git will sometimes return a merge commit as having modified a given path, even though it doesn't list it as modified in the output from the --name-only option.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
forgehg:cj/6821
allura:cj/6821
Found an issue where errors in the thread workers could potentially block the request indefinitely. Fixed in both Hg and Git.
In the test, it'd be better if it was clear why the error handling would be invoked.
It'd be better to timing out rather than hanging, when something does goes wrong in the threads and isn't caught.
There's quite a bit of logic overlap between hg & git's
last_commit_ids
: http://pastie.org/8547562 Could that be refactored and shared?Git's implementation specifies no_merges=True, we should be consistent with hg.
hg log
takes a--no-merges
param; can we do this withcmdutil.walkchangerevs
though? I prefer no merges, but showing merges on both would be ok too. It also seems that merge commits aren't displayed in log view (either via allura or commandline, which I don't really understand). Example: merge commit ada01d on /NEWS.txt in the SF 'coils' repo. Which makes it confusing when you see the merge commit on the tree view but not the history view.Rebased and force-pushed to:
allura:cj/6821
forgehg:cj/6821
Removed the merge commit filter from git because: 1) that was easier, and 2) it more closes matches what you would see from
git log
on the command line (and also on the history / log view on the web).RepositoryImplementation now has two
last_commit_ids
methodsThe new method should have a docstring explaining how a specific SCM could implement just the
_get_last_commit
methodforgegit.tests.model.test_repository:TestGitImplementation.test_last_commit_ids
is now failingUpdated:
allura:cj/6821
Ugh. The behavior of
git log
with respect to merge commits appears to contradict the detailed explanation under History Simplication (specifically the bits about the default mode and--dense
). Apparently, git will sometimes return a merge commit as having modified a given path, even though it doesn't list it as modified in the output from the--name-only
option.Updated:
allura:cj/6821
forgehg:cj/6821
A number of allura.tests.model.test_repo:TestLastCommit test failures, mostly due to
get_changes
methodallura:cj/6821