* A usage question
@ 2009-05-31 3:34 Jeremy O'Brien
2009-06-01 16:32 ` Daniel Barkalow
0 siblings, 1 reply; 2+ messages in thread
From: Jeremy O'Brien @ 2009-05-31 3:34 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]
Hello,
I have a git usage question. I'm working on three separate branches in a
foreign SCM called Surround. One branch is the mainline, and two others
are a v1 branch based off the mainline and the other is a v2 branch
based off the mainline with many new features that we hope to release
soon. Some components of the v1 branch are similar, but not identical to
the v2 branch, and other parts are completely different. I am primarily
working on the v2 branch, but some things that I change can/should be
backported to the v1 and mainline branches.
The foreign SCM requires one working directory for each branch, so I
currently have three separate git repos with the contents of what is on
Surround for each, and then I have one "local" git repo that I'm using
to do my development. I have three branches on this local repo: one to
track each git repo set up for Surround. I've been using topic branches
in my local dev repo to do my work, and then merging my changes into the
branch I branched my topic branch from, and cherry-picking ones into the
other two branches that could be used there. I then push these branches
to the repos and check then into Surround when I am ready to. This
doesn't seem efficient to me at all, and I was wondering if there is a
better setup someone could suggest that would make development easier.
Sorry for the huge message.
Thanks for any suggestions.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: A usage question
2009-05-31 3:34 A usage question Jeremy O'Brien
@ 2009-06-01 16:32 ` Daniel Barkalow
0 siblings, 0 replies; 2+ messages in thread
From: Daniel Barkalow @ 2009-06-01 16:32 UTC (permalink / raw)
To: Jeremy O'Brien; +Cc: git
On Sat, 30 May 2009, Jeremy O'Brien wrote:
> Hello,
>
> I have a git usage question. I'm working on three separate branches in a
> foreign SCM called Surround. One branch is the mainline, and two others
> are a v1 branch based off the mainline and the other is a v2 branch
> based off the mainline with many new features that we hope to release
> soon. Some components of the v1 branch are similar, but not identical to
> the v2 branch, and other parts are completely different. I am primarily
> working on the v2 branch, but some things that I change can/should be
> backported to the v1 and mainline branches.
>
> The foreign SCM requires one working directory for each branch, so I
> currently have three separate git repos with the contents of what is on
> Surround for each, and then I have one "local" git repo that I'm using
> to do my development. I have three branches on this local repo: one to
> track each git repo set up for Surround. I've been using topic branches
> in my local dev repo to do my work, and then merging my changes into the
> branch I branched my topic branch from, and cherry-picking ones into the
> other two branches that could be used there. I then push these branches
> to the repos and check then into Surround when I am ready to. This
> doesn't seem efficient to me at all, and I was wondering if there is a
> better setup someone could suggest that would make development easier.
It sounds to me like all of the steps are required, since Surround want
those directories to exist and contain your work. You may be able to
automate them, though, depending on how amenable Surround is to being part
of scripts (and how comfortable you are writing scripts). Of course, in
the limit, a script could be called from "git fetch" and "git push", and
it would essentially act like native git interaction with an upstream
maintainer who rewrites commits.
If Surround has an API like Perforce does, and it extends to allowing the
developer to implement a different view of the filesystem, you might not
even need to have those directories on disk, unless you want to be able to
show your coworkers something in an environment they recognize.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-06-01 16:32 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-31 3:34 A usage question Jeremy O'Brien
2009-06-01 16:32 ` Daniel Barkalow
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).