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@plaetinck.be> 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