git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* 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).