From: David Kastrup <dak@gnu•org>
To: Junio C Hamano <gitster@pobox•com>
Cc: Linus Torvalds <torvalds@linux-foundation•org>, git@vger•kernel.org
Subject: Re: How do I manage this setup with git-svn and/or git remotes?
Date: Sat, 18 Aug 2007 09:07:23 +0200 [thread overview]
Message-ID: <85643dwcb8.fsf@lola.goethe.zz> (raw)
In-Reply-To: <85mywpx2wl.fsf@lola.goethe.zz> (David Kastrup's message of "Fri\, 17 Aug 2007 23\:32\:58 +0200")
David Kastrup <dak@gnu•org> writes:
> Junio C Hamano <gitster@pobox•com> writes:
>>
>> My reading of the project David is talking about is that its dsp
>> project which is a "subproject" part gets non generic commits within
>> the context of the superproject --- which means (1) you would have
>> branches in the subproject not superproject, and (2) once you did
>> that, the subproject is not really a subproject anymore, as you
>> cannot merge that back to the standalone dsp project without
>> dragging the non-generic bits along with it.
>
> Ok, I should perhaps should not make things harder than they are: the
> superprojects, being particular to one customer each, don't really
> branch (except that git-svn makes a git branch from every Subversion
> tag). The subproject is the one that has considerable branching and
> merges. What usually gets pulled into the superproject is a copy of a
> stable subproject branch. Once this copy is in, only fixes (from the
> stable branch) or features (from the development branch) that the
> customer definitely needs are merged into the superproject. While
> there might happen some subproject work in the customer branch, this
> mostly happens during bugfixing for the customer, and the changes are
> typically pulled back into the subproject proper at some point of
> time. Inside of the subproject tree, there is really no superproject
> _development_ going on.
I think I got it. My mistake was focusing all the time what I could
do with the git repository of "great" to facilitate two-way merges.
Instead I need to import great/trunk/dsp into a remote branch in my
_dsp_ git repository. Since for git-svn, every Subversion directory
is as good to import as any other (there is no concept of a worktree
root in the repository) that should be all it takes.
I'll need to use the dsp repository when doing merge work, but apart
from that, I can work in the great repository r/w even while in the
dsp subdirectory.
If one could tell git in a remote section to
fetch/consider/synchronize/push just a subdirectory as the repo root,
then the same setup for bidirectional merges could be made to work
with projects like gitk. Though I am fuzzy about the merge
information... But that is a problem when pushing merges with private
branches, anyway, isn't it?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
next prev parent reply other threads:[~2007-08-18 7:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-17 17:24 How do I manage this setup with git-svn and/or git remotes? David Kastrup
2007-08-17 17:56 ` Linus Torvalds
2007-08-17 18:26 ` David Kastrup
2007-08-17 18:53 ` Linus Torvalds
2007-08-17 21:04 ` David Kastrup
2007-08-17 21:18 ` Junio C Hamano
2007-08-17 21:32 ` David Kastrup
2007-08-18 7:07 ` David Kastrup [this message]
2007-08-18 23:37 ` Jakub Narebski
2007-08-19 16:04 ` David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85643dwcb8.fsf@lola.goethe.zz \
--to=dak@gnu$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=torvalds@linux-foundation$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox