On 13/03/12 20:25, Thomas Bächler wrote: > Am 13.03.2012 09:21, schrieb Allan McRae: >>> Is it at all feasible to just use the build date for package ordering if >>> it's a >>> vcs package? This way the pkgver can be the ref that was checked out: >>> >>> - the short hash >>> - the tag >>> - the branch (_short hash maybe OR only automatically bump the pkgrel) >> >> I would really like to move away from the build date having anything to >> do with package ordering as it is entirely non-deterministic about what >> is in a package. > > I cannot ACK that enough. Please, no build dates! > >>>> source=(git://projects.archlinux.org/users/allan/pacman.git) >>>> _git_branch="working" >>>> _git_commit="8c857343" >>>> >>> >>> Are these looking forward to other VCS's though? What scenario is more than >>> one >>> ref needed? Makepkg would just be doing a checkout right? >> >> This might be me not understanding some of the subtleties of git, but >> this is what I see as options for building from a git repo... >> >> 1) build from master HEAD >> 2) build from a branch HEAD >> 3) build from a given commit/tag >> >> So, assuming that the git repo is checked out from upstream in $vcsdir, >> the command needed for each of these is: >> >> 1) git clone --branch master $vcsdir [*] >> 2) git clone --branch <branch> $vcsdir >> 3) git clone $vcsdir; git checkout <ref> > > You complicate things A LOT here. Specifying the branch and commit > separately is nonsense. The commit id already tells you exactly where > you want to be. This is the right thing to do:
Just to be clear, you do realize these are not three commands to be run one after the other but the way I was thinking about achieving each of the three usages scenarios I gave above? > $ git clone $vcsdir > $ git checkout -b makepkg $ref > > Here, $ref can be a tag name, a branch name, a commit id or an > abbreviated commit id - everything git understands as a refspec. Let's > just give git a single refspec and let it handle the rest. > > (I just realized I might be slightly wrong here, as we refer to branch > and tag names in a remote repository of a remote repository - but I am > sure some magic exists here that will make it just as easy as I > described, Dan probably knows.) > > This is what you don't seem to understand: Once you have the commit id, > the branch name has no relevance anymore. You only need the branch name > when referencing the head of that branch. > I do understand the branch name is useless once you have a tag/commit id. That is why later in the email I said it only really serves as documentation. What I was trying to avoid is the need to specify (e.g.) "origin/maint" as the branch. The "origin/" part just seems redundant and the I was trying to remove as much redundancy across PKGBUILDs as possible here. Of course I also see that having separate methods to specify a branch and a ref/tag is redundant too... In the end there is probably no such thing as perfection here. Allan
