[vtk-developers] Best way to contribute to VTK ? - Fwd: [GitHub] nolden sent you a pull request from nolden/VTK

Marcus D. Hanwell marcus.hanwell at kitware.com
Wed Jul 7 11:44:53 EDT 2010


Brad may provide a fuller answer, but in short it preserves more of history
(when the commits were made, where that branched and merged back in), as
well as allowing merges into multiple integration branches using the same
commit objects. So using master and next, the only things that would differ
if all branches were merged in both is the merge commits.

The problems we had in getting a topic branch out of your wrapping commits
go away when topic branches are used, shared and later merged as Git
recognizes them as the same commits. The CMake and Titan wikis contain more
details on the motivations behind using it. We have only been using a small
part of Git when requiring a linear workflow, and it would be nice to take
fuller advantage.

Brad is writing up more details as we speak, and will make a broader
announcement.

Thanks,

Marcus

On Wed, Jul 7, 2010 at 11:25 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> I have what might be a silly question.  When a branch merge is done,
> it shows up simply as "Merge branch" in the logs, and a bit of digging
> is required to find out what has changed and why.
>
> Is there any advantage over doing a merge, as compared to pulling the
> changes from the branch, rebasing them, and pushing them?  For
> small changes, this would seem preferable over doing a merge, as least
> as far as the clarity of the logs is concerned.
>
>   David
>
>
> On Wed, Jul 7, 2010 at 8:54 AM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
> > On Tue, Jul 6, 2010 at 1:13 PM, Marco Nolden <
> m.nolden at dkfz-heidelberg.de>
> > wrote:
> >>
> >> On 07/06/2010 06:11 PM, Marcus D. Hanwell wrote:
> >>>
> >>> Sorry if I missed this one, the change looks reasonable and I can take
> a
> >>> look at it. It would be good to see improved unicode support too. It is
> >>> something that the ARB should probably be discussing, but it would be
> >>> great to involve the community as far as is possible.
> >>>
> >>> Marcus
> >>>
> >> Actually I revised it a bit, so the link is here:
> >>
> >>
> >>
> http://github.com/nolden/VTK/commit/9b76af72e6016fcd4a7b2e1a58edb77eb5549eef
> >>
> >> and the patch is attached.
> >>
> > This is now merged, and was actually the first topic branch merged into
> VTK
> > using the staging repository we have been working on. I actually made a
> > second commit in that topic where I fixed the public API to use unsigned
> > char, and also use static_cast instead of the C style casts.
> > The commit prefix is normally BUG: rather than FIX: too, although this is
> > something else we need to make clear (are we requiring the log message
> > prefixes). Thanks for your patch, I encourage you to keep an eye on the
> > dashboards (although I will be doing that too).
> > 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
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100707/d3cb50c7/attachment.html>


More information about the vtk-developers mailing list