Re: A usage question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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*
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]