[vtk-developers] Strange repo happenings with vtkOpenGLProjectedTetrahedraMapper

[Utkarsh Ayachit]

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.

Utkarsh

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
>>
>> -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.
> _______________________________________________
> 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
>