thanks! and a tiny comment

Yaroslav Halchenko lists at onerussian.com
Mon Oct 22 15:10:43 UTC 2007


On Fri, 19 Oct 2007, martin f krafft wrote:
> also sprach Yaroslav Halchenko <lists at onerussian.com> [2007.10.15.2111 +0200]:
> > not conflict with the original patch). So, the patch must not be
> > applied any longer. If the branch "build"  is a long lasting branch,
> > where merges from feature branches are committed -- it would be the
> > place where the patch needs to be "retracted".
> git-revert cannot revert multi-parent commits, so you cannot just
> undo the merge. However, you can revert all the changes the branch
> merged, but you have to do that manually.
> This is a very good point and I don't have a real solution to it.
obvious possible solution imho is to simply
1. reset long lasting branch to debian branch's HEAD
2. apply all needed patches in the same order as before excluding the
   ones which are not needed any longer.
   The problem comes when there are merge conflicts and the last
   paragraph in my email (look below) was aimed to preserve
   history of their resolution (which was done by hands when they were
   detected)

> The way I would do this is by developing the patch in a branch, but
> then squash-commit all your work into a single commit, which you can
> then easily cherry-pick.
yeap -- all work for a patch/fix should be squashed at the end. it would
be cumbersome if the branch keeps multiple patches/fixes within in ;-)
that is why imho having separate up/... branches instead of a single
upstream-patch

> > well... I am just trying to expand your guidelines ;-) such
> > approach would allow easy and consistent handling of conflicts
> > among the patches (if such occur). If there is a superior way to
> > resolve it -- I would go for it!
> The superior way to resolve conflicts is you, the human being. :)
indeed! we should be smarted than those silicon drops! ;-) the my
suggestion was aimed at how to "record" such conflict resolution in a
way that it could be used later on if it becomes necessary to reapply
sequence of patches (ie merges) and resolve the conflicts based on
previous manual resolution of them during some original merge attempt.

-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW:     http://www.linkedin.com/in/yarik        



More information about the vcs-pkg-discuss mailing list