Re: [PATCH 000/141] V4L/DVB updates part 1

[Mauro Carvalho Chehab]

> Hmm. I don't know if it's stgit per se. Maybe the breakage came from a 
> mercurial merge that got exported to git as a patch, rather than as a 
> merge.
We can't discard any cause, but, at mercurial, I just export the
patches, removing all version-dependent code. After doing, I do a diff
between Mercurial and git trees. Only after that, I proceed.
> 
> If that's the case, then I'm afraid that the problem is the mercurial 
> part, or at least the hg->git conversion. I have no idea how hg does 
> merges, and maybe the broken merge was done in the hg tree. 
Patch generation seems to be ok, since I have the habit to check all
patches before commiting. Also, diffstat I sent were generated by
looking at the stg exported patches. I dunno if this is common, but
running git-fsck-objects after working for a while with stgit generates
lots of 
> 
> The really sad part about this is that it means I have to be much more 
> careful with dvb merges, since I can't trust the tree any more, when it 
> apparently has something strange going on.
I'll rebuild the entire tree from the beginning, and I'll also update
both git and stg version to latest ones.
>  If things like this keep on happening, I'll have to ask you guys to change your work habits.
> 
> That said, I _tried_ to check for similar cases in the past history, and I 
> couldn't find any. So hopefully this was a one-off occurrence.
I hope this won't happen again.

What is sad is that I can't determinate the root cause of this breakage,
but it seemed to be associated with merging handling at stg or git.

One possibility is that stg pick doesn't seem to be preserving commit
date, so that patches are compared with the wrong versions.

The first 141 patches were committed in the past, starting from the end
of 2.6.15 window and were already committed at stgit. I just did a git
pull . prev to retrieve they.

The newer 49, however, were not committed yesterday, but also in the
past. Yesterday, I just picked them from work branch. However, stgit
marked commit timestamp as if they were just committed. This might have
generated some troubles at resolution conflict code on git.
> 
> 			Linus
Cheers, 
Mauro.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/