[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: RFR: GIT Package VCS
From:       Karel Zak <kzak () redhat ! com>
Date:       2007-06-10 23:18:59
Message-ID: 20070610231859.GQ16879 () petra ! dvoda ! cz
[Download RAW message or body]

On Sun, Jun 10, 2007 at 02:20:23PM -0400, Dave Jones wrote:
>  > I'm almost sure that someone other (for example
>  >  Linus) will use GIT instead quilt for same job.
> 
> I tried it during F7 after FUDCon.  I thought it'd work out too.
> It didn't.  As soon as rebasing broke Xen, it became a nightmare,
> as I couldn't easily drop it.  It became easier to just

 What not? You need to 1/ checkout code to a temporary branch, 2/
 remove the patch (reset --hard) and 3/ rebase (--onto tmp) to the
 original branch.

 Well, I agree this is definitely less elegant than comment out
 some %patch.

> regenerate the tree from scratch without xen ever having been
> included.  (This however kills your history).
>
> Compare this to the method we use today, where I just comment
> out some %patch's, and maybe rediff 1-2 of the follow-on patches.

 The problem is that the method we use today doesn't support anything
 like rediffing. The "rediff 1-2" is nightmare with rpmbuild +
 gendiff.

> This approach isn't too unlike quilt.

 Yes, but the quilt is better. It supports rediffing ("quilt refresh").

 When I think about the way how I use CVS for Fedora packages -- I
 have to say: I needn't SCM for *patches management*. I need SCM when
 I work on changes to source code.

 The method we use today is silly -- we use (ugly, centralized)
 *source code* management tool for *patches  management*. The other
 disadvantage is that the method isn't integrated with spec file
 management (you still need to manually edit your spec files).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]