Thanks, Linus, for your time in answering my questions. I have some
more comments and questions in reply. I hope I am coherent enough,
this subject matter doesn't exactly flow off my tongue with ease
yet...
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?
> Of course, especially if you want to continue to work the way you
> probably worked with SVN (ie you are used to seeing those two
> branches as two separate directories), that means that while you
> can (and should) see it as a single git project, you'd normally
> end up just having two copies of that project: they'd _both_ have
> two branches, but they'd just en dup having different branches
> checked out.
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. Thus, I'd
probably branch the 'debian' branch off 'upstream', and add the
./debian directory, and then either rebase the debian branch onto
new upstream heads, or merge upstream into the debian branch on new
versions.
This makes perfect sense and I have been experimenting with such
a workflow before:
http://albatross.madduck.net/pipermail/vcs-pkg/2007-June/000001.html
So if I made changes to the debian branch, I'd check it out first,
then return to the upstream branch when done.
Your suggestion to checkout the same repo twice with different
branches does sound a lot like the way I used to do things in SVN.
However, I guess what I am trying to prevent is having to manually
set up this hierarchy on each machine I choose to work on. Instead,
I'd rather be able to clone a repository and be ready to work.
In your scenario, would I make two branches and then import upstream
into one, the ./debian directory into the other, and never ever
merge back and forth again, thus treating them as separate
directories?
> Of course, after you get comfy enough with the setup, you might
> end up just deciding that you might as well just switch branches
> around in a single repository (which is what a lot of git users
> end up doing), but at least initially, it's probably easier from
> a conceptual standpoint to just have the two branches checked out
> in separate copies of the repos.
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?
> > How can I do this with git? I am aware that maybe the best way
> > would be to use git-svn to track the upstream branch remotely
> > and to add ./debian in a separate git branch (and to stop using
> > SVN and switch to git for ./debian)
>
> I don't think you'd have to stop using SVN.
I think I would want to. :)
> (And no, I don't know what the standard debian package management
> setup looks like, but I would hope that your extra stuff would be
> just a few files and package descriptions, and obviously any of
> the local debian changes to the project).
Your hopes seem to be quite close to reality. :)
Thanks,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
spamtraps: madduck.bogus@xxxxxxxxxxx
http://www.vcnet.com/bms/
Attachment:
signature.asc
Description: Digital signature (GPG/PGP)
