On Sun, 07 Mar 2010 14:49:01 +0100
Thomas Bächler <thomas@xxxxxxxxxxxxx> wrote:
> 1) We want to be able to see which PKGBUILD matches the package in the
> repository. In SVN, we use copy - which is subversion's equivalent to
> branching: By copying, you create a reference and all history of the
> copied file is still there. In git, copying means that the copy has no
> history, it is entirely unrelated to the original. The only equivalent
> in git would be branching - but you cannot branch a single file or
> path, you can only branch the entire tree.
Note that with "package in repository" Thomas means the
<package>/repos/i686 and such directories in svn.
There are some approaches we could take:
* git diff has a -C flag to detect copies.
--find-copies-harder
For performance reasons, by default, -C option finds copies
only if the original file of the copy was modified in the same
changeset. This flag makes the command inspect unmodified files as
candidates for the source of copy. This is a very expensive operation
for large projects, so use it with caution. Giving more than one -C
option has the same effect.
so, we tell all packagers to do the add/update/test/add-to-repositories
in one commit. (or use the slow -C flag, I don't know how often you
want to do this)
* 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)
* 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.
* just do normal copies and don't care about the histories.
I'm not really a packager so I don't know how feasible all approaches
are, but some of them seem pretty feasible.
> 2) Partial checkouts and commits: We check out single directories and
> most importantly we commit to single directories without updating the
> rest of the repository. These operations come naturally to SVN, but
> they are against the very concept of git.
did you see http://vmiklos.hu/blog/sparse-checkout-example-in-git-1-7 ?
is this not enough? I mean, you can clone the (complete)
repository, checkout the git repo sparsely,
commit in your subdirs, add the clone as remote in your
original and pull in the changes. okay you do have the
complete 57MB repository locally, but at least a clean checkout.
I actually just tried this and it just works!
Dieter
