git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Daniel Barkalow <barkalow@iabervon.org>
To: Jeremy O'Brien <obrien654j@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: A usage question
Date: Mon, 1 Jun 2009 12:32:00 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LNX.2.00.0906011215140.2147@iabervon.org> (raw)
In-Reply-To: <20090531033431.GB25869@darkbox>

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*

      reply	other threads:[~2009-06-01 16:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-31  3:34 A usage question Jeremy O'Brien
2009-06-01 16:32 ` Daniel Barkalow [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.00.0906011215140.2147@iabervon.org \
    --to=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=obrien654j@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).