[vtk-developers] Strange repo happenings with vtkOpenGLProjectedTetrahedraMapper

David Cole david.cole at kitware.com
Thu Dec 22 14:35:51 EST 2011


On Thu, Dec 22, 2011 at 1:59 PM, Brad King <brad.king at kitware.com> wrote:
> On 12/22/2011 8:42 AM, Bill Lorensen wrote:
>>
>> If I do a git log on the vtkOpenGLProjectedTetrahedraMappe.cxx file I
>> don't see your commits or mine.
>
>
> The other part of this thread identified the vtkstd changes.
> I'll follow up with why your commit (49c1f9de) is not shown by:
>
>  $ git log 49c1f9de~1..31ec9251 -- \
>   VolumeRendering/vtkOpenGLProjectedTetrahedraMapper.cxx
>
> The command tells Git to start at commit 31ec9251 and walk back looking
> for commits that change the given file.  When Git comes to the incorrect
> merge commit 174c39e8 it sees that the file in the commit is identical
> to one of its parents.  Therefore it assumes that the content in the file
> as of the merge commit can be fully explained by the history of the one
> parent in which it is identical.  It follows only that parent and prunes
> out the history from the other parent.  Your commit only appears in the
> pruned side of history so it gets skipped.
>
> The above behavior is an optimization that does the right thing in the
> case that merges were done correctly.  One can use the "--full-history"
> option to disable the behavior.  The following command shows your commit:
>
>  $ git log 49c1f9de~1..31ec9251 --full-history -- \
>   VolumeRendering/vtkOpenGLProjectedTetrahedraMapper.cxx
>
> -Brad
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>


This whole day, and this whole discussion, points out one shortcoming
of our current workflow. I'm not saying there's a good way to fix it,
but am "just saying":

The shortcoming is the combination of:
- having some commits that are "sweeping changes" that touch lots and
lots of files
- also allowing merge commits surrounding those sweeping changes
- also allowing topic branches that are based on very old (more than a
couple weeks or so?) commits in 'master'
- having developers resolve conflicts (the human error factor)

The problem is mainly that sweeping changes that touch lots of files
are time-consuming to review. And yet, if there are many outstanding
topic branches, it is likely that those sweeping changes will be
merged in over and over again (because others are touching some of the
same files). The more that happens, the more the "I've seen this
already" response the developer has, ... making mistakes during
conflict resolution more likely.

We don't have a good way to detect "mistaken conflict resolutions" --
other than the next day's dashboard -- and, in some cases like this
one, it's very difficult to tell what happened after the fact.
Thankfully, we've at least discovered the --full-history flag to make
future analyses easier.

I wonder if there's a way to add more eyes to the "conflict resolution
by a developer" process such that this becomes less likely. Perhaps a
2nd pair of eyes on a manual conflict resolution in this case would
have caught the mistake before it was merged into master.

One other thing we could do to help make sweeping changes easier is to
make them on an agreed upon day, and then have everybody rebase
outstanding topic branches on 'master' again as soon as the sweeping
changes are in.

Of the two, I think "more eyes" is the more important point.


Just thinking,
David C.



More information about the vtk-developers mailing list