Jeffrey C. Ollie <jeff <at> ocjtech.us> writes: > Once you know more about source code control you'll understand that > having the history that went into a patch (and into the source code that > the patch is for) lets you do amazing things with patches, like rebase > them so that they apply to new versions of released software. Just reading Git crash course for SVN lusers (http://git.or.cz/course/svn.html) and they are taking about conflicts during a merge: "[...] if any changes conflicted, git merge will report them and let you resolve them, updating the rest of the tree already to the result state; you can git commit when you resolve the conflicts." To me, this reads as if each maintainer still needs to understand the new upstream code in order to rework the patches so that they apply. Is that what you mean by "rebase"? Fix them by hand so that they actually work? I get the point about branch history etc. -- Bojan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
