* Dominic Hargreaves <d...@earth.li> [130326 23:36]:
> To be clear, the issues is that in the upstream branch, following the
> import, 'git log' shows the expected history, but 'git log etc' doesn't.
> Yes, once I'd merged upstream-third-party-source into upstream, as
> git-dpm seems to expect, I ran git init like this:
> git-dpm init --record-patch-name --component
> ../request-tracker4_4.0.7.orig.tar.gz upstream
The problem seems to be the following: with components reprepro
creates one commit for the .orig.tar file imported and nothing else in
it (so that it can point pristine-tar to that commit as that will
generate a smaller delta than any other commit with more stuff).
This commit is then merged into the upstream branch.
Now if git is asked to look for where that etc directory is from
looks at the merge, sees that everything is available on the right
hand side and decides to use that side instead of the other side,
and thus decides that it suffices to only show that part of the
merge in the history and not the other side. (usually I'd assume
git to prefer the most leftish merge and not go into the other
parent, but perhaps that directory is just too similar to that parent,
so it no longer looks at the first parent).
You get to see the parts of the history git considered uninteresting
that way by adding "--full-history" to git log.
> I'm still looking for ideas about what to do next. git-dpm people,
> hoping this will sound familiar to you...
The situation might be mitigated by having some history for that
part. If a commit would be created with
git-dpm import-tar -p upstream/4.0.7
and the result of that commit is given via -p to
git-dpm import-new-upstream --component ...
then no such commit should be made and the problem should not happen.
Bernhard R. Link
Git-dpm-user mailing list