On Tue, 10 Jul 2007, martin f krafft wrote:
>
> also sprach Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> [2007.07.10.0435 +0200]:
> > I really _think_ that what you want is to just use separate
> > branches, if I understand correctly. That makes it really easy to
> > just have both lines of development (both the "trunk" and your
> > "debian" one) in one git repository.
>
> It does mean, however, that I duplicate the upstream into my repo,
> and thus into the published repo at git.debian.org, because I cannot
> just publish a single branch ('debian') in such a way that people
> could clone it and still be able to build the package against
> upstream (which they'd have to obtain for themselves), right?
Well, I think you have two cases:
- the git users
These would get both branches (including all of the upstream, of
course), but that's ok, since git will share all the common objects
*anyway*, so there is no "duplication". You can have a hundred
branches, and they won't use one whit more memory of bandwidth (apart
from the branch refs themselves being sent over, of course), and only
the actual *differences* between branches will take up space.
- the non-git users
Here, I don't really know how the debian package management is supposed
to work, but since they obviously aren't using git, they must be using
something else. A tar-ball or just a series of patches? Both would be
trivial to implement as just an "export" from your git tree. Or you'd
export the "debian" branch as a separate SVN repo (I've not used the
"export back into a SVN" thing, so I don't know how well that works).
In particular, if all your "debian-specific" stuff is almost all in the
"debian" subdirectory, then you can trivially make a tar-file by just
using
git archive --prefix=upstream- HEAD debian > upstream-debian.tar
and git will literally generate the tar-file of that directory for you.
> The way I tend to think about a pair of branches is that one depends
> on the other, or rather, one stems from the other.
.. and no, that's not really how git works from a technical angle: in the
the git model, all branches are technically 100% equal, and no branch
"depends" on anything else, they are all equally first-class citizens.
But while *technically* all branches are equal in git, at the same time
there's no reason not to _think_ of branches as having a hierarchy if you
want to. In particular:
- it's how people tend to use git anyway (ie the "origin" branch is
what you're tracking, and you have your own changes in your local
branches)
- and git will never duplicate information for branches that have a
common history or contents anyway. So while git branches are totally
"independent" in the technical sense, the data structures are all
designed so that they will share everything that they can possibly
share (in fact, thanks to the "delta-against-anything" model, different
branches will share much more than in something like CVS/SVN)
> So if I made changes to the debian branch, I'd check it out first,
> then return to the upstream branch when done.
It sounds like you would actually be fairly comfy with the git "switch
branches within one repository" model, and you might not even need to make
it look like two different trees.
> Okay, this is beginning to make sense. However, the debian branch
> tracks changes mostly to ./debian/*. To check it out separately,
> I need a directory. If usptream is checked out to ., then if I'd
> check out the debian branch do ./debian, I'd end up with
> ./debian/debian. Do you suggest the use of a symlink then?
No, I'm suggesting that you have the upstream thing checked out in ".",
and you have the "debian" branch IN THE SAME PLACE. So when you do
git checkout debian
it will just check out all the debian stuff in the same directory, so now
you'll get a ./debian/ directory with all your debian stuff.
When you do
git checkout upstream
the files in that directory just go away, because it doesn't exist in
the "upstream" branch
But I don't want to fool you - I do think you'll have to change *some* of
how you work. But it sounds like your workflow is *fairly* close to a very
natural git flow.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
