[vtk-developers] Strange repo happenings with vtkOpenGLProjectedTetrahedraMapper

Bill Lorensen bill.lorensen at gmail.com
Thu Dec 22 15:25:54 EST 2011


I think we should require all changes to go through gerrit. I'm sure I
would have caught this conflict.


On Thu, Dec 22, 2011 at 3:20 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Thu, Dec 22, 2011 at 3:15 PM, Utkarsh Ayachit
> <utkarsh.ayachit at kitware.com> wrote:
>> On Thu, Dec 22, 2011 at 2:35 PM, David Cole <david.cole at kitware.com> wrote:
>>> 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
>>>>
>>> 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.
>>
>> I totally agree with "sweeping changes" statement. I have been burnt
>> by it far too often. Another problem with sweeping changes is doing
>> them in the same commit. That precludes cherry-picking which can help
>> solve any conflicts.
>
> We still need a mechanism, as these things are required at times. I
> think the vtkstd removal was one such occasion, but perhaps
> distributing the load among developers by asking them to rebase their
> topics would be better. Many projects simply refuse to merge topics
> with conflicts and ask the author to rebase them, having three
> integration branches for VTK doesn't make things easy either...
>
> Marcus
> _______________________________________________
> 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
>



-- 
Unpaid intern in BillsBasement at noware dot com



More information about the vtk-developers mailing list