I agree with everyone else that's said it. This comes up often enough but no one ever has a good workflow that works. I have seen nothing proposed in this thread that is good. The ONLY thing gained is "oh neat, it's in git". We lose quite a bit, especially in the branch-ing department. It seems like this is a "solution" that's looking for a problem to happen. As far as I know, working with svn isn't a big deal and isn't a problem. On Sun, Mar 7, 2010 at 9:07 AM, Dieter Plaetinck <dieter@xxxxxxxxxxxx> wrote: > * git branches. 3 branches or so for each package. that's a lot of > branches, but maybe that's not really a problem, depends on how many > times you want to merge branches i guess (i.e. how related packages > are to each other) This wouldn't allow you to safely checkout multiple packages at a time as you can only have one branch checked out at a time. Also could you imagine scripting this to verify the version of say xorg-server that is in extra? Ugh. With svn, it's imply a checkout of $URL/xorg-server/extra-i686 and checking the PKGBUILD. > * we could also get rid of these branch directories. what's the > point of them anyway? the tools who build the packages (tarballs) > must know the latest version for the particular architecture? maybe > we can put tags in the commit messages, or keep a textfile in the > package directory to know which "state" of the directory is usuable > to build packages for. Knowing the version of the files which built a package in the repos is important. Using tags in commit messages is a terrible idea because not only do we need to change the PAINFULLY simple way of checking with something using git, but we also have to parse plain text commit messages. > * just do normal copies and don't care about the histories. This shouldn't ever happen. The history is important
