From: Jeff King <peff@peff.net>
To: Danielle <dsavir.h@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Advice regarding inherited git repository
Date: Wed, 6 Jan 2016 03:20:22 -0500 [thread overview]
Message-ID: <20160106082022.GA19117@sigill.intra.peff.net> (raw)
In-Reply-To: <loom.20160105T183516-607@post.gmane.org>
On Tue, Jan 05, 2016 at 05:42:15PM +0000, Danielle wrote:
> I inherited a web site and a git repository. the git repository is cloned
> to the website and a sandbox website (two clones). No commits have been
> done in more than 6 months. The main site has been updated a lot of times,
> the sandbox has lots of test and exploratory code. To bring things up to
> date, I thought of staging and committing all the files in the main site
> and pushing to the remote repository, and then fetching into the sandbox
> clone and merging what is needed (which will be sooo not trivial). Does
> this make sense? Or would it be better to create a sandbox branch somehow?
> I'm used to working with SVN, no real git experience, so I would
> appreciate any advice on how to manage this.
You probably should create a sandbox branch, for your own sanity.
Because git is distributed, each separate repository is implicitly a
branch. So if you did something like:
1. Commit all the changes on the main site to "master". Push the
result to some common remote.
2. Commit all the changes in the sandbox to its "master". Do _not_
push to the remote.
3. Pull the changes from the remote into the sandbox. If they're worth
adding to the main site, push them up. If not, leave them there.
That works; "master" in the sandbox has the experimental changes, but
you don't have to push them anywhere. However, you are one accidental
"git push" away from sending all of those experimental features to your
remote "master". So it's easy enough to make step 1.5 "git checkout -b
sandbox-cruft" in the sandbox repository, so git knows not to ever push
it to "master".
In general, I'd also say you may benefit from splitting the changes in
each repository into as many separate logical commits as you can (and
possibly even to separate topic branches that you can merge
independently). Given that you inherited this, that's _probably_ too
much work. But if you do want to try it, I recommend "git add -p" for
picking out individual hunks.
-Peff
next parent reply other threads:[~2016-01-06 8:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <loom.20160105T183516-607@post.gmane.org>
2016-01-06 8:20 ` Jeff King [this message]
2016-01-07 8:40 ` Advice regarding inherited git repository Danielle
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=20160106082022.GA19117@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=dsavir.h@gmail.com \
--cc=git@vger.kernel.org \
/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.
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 NNTP newsgroup(s).