git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Potapov <dpotapov@gmail.com>
To: Kacper <kacper.gazda@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Two versions of a project in one GIT repository
Date: Fri, 8 Jan 2010 06:57:29 +0300	[thread overview]
Message-ID: <20100108035729.GB28263@dpotapov.dyndns.org> (raw)
In-Reply-To: <1262912794001-4269785.post@n2.nabble.com>

On Thu, Jan 07, 2010 at 05:06:34PM -0800, Kacper wrote:
>
> I have two versions of one project in one local git repository. I have to
> commit this repository into 2 remote repositories, one for each version;
>
> LOCAL GIT(V1/V2) -> REMOTE GIT(V1), REMOTE GIT(V2)
>
> I have some files in the LOCAL GIT repository which should only go to REMOTE
> GIT(V1) and other should only go to REMOTE GIT(V2). Now I commit full local
> repository to both remotes. Can I only commit some files to REMOTE1?

You do not commit to any remote. You _always_ commit to the local repository.
Then using 'git push', you propagate your changes, and you can propagate any
commit to any remote repository of your choice, but you can only to push the
_whole_ commit, which implies the whole tree and all parents commits as well.

> I need to have both version of the project in one repository, but would like
> to have an options to divide history a bit.

You can add as many remote repository as you like using 'git remote add'.

> I do not think that any
> branching can help as then I would have to make the same changes to both
> branches mostly. Most of the code, 90% of the code is the same for VER 1 and
> VER 2. New code is usually the same for both versions.

You can commit only to one branch and then merge your changes to another. In
general case, you may want to have a special branch to commit common changes
and then to merge it to V1 and V2. Though, I guess it is a bit inconvinient.

However, if the difference between V1 and V2 is not large, and you do mind
having V1 history visible as part of V2 history then you may have just two
branches. You create V2 based on V1, by adding V2 specific files and removing
V1 specific files. After that you made all your work on V1 and periodically
merge V1 to V2. Changes made to V1 specific files will cause conflict during
merge to V2, but you can easily resolve by doing 'git rm' on V1 specific
files.

To better understand Git model, I suggest you read "Git for Computer
Scientists" http://eagain.net/articles/git-for-computer-scientists/


Dmitry

      reply	other threads:[~2010-01-08  3:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-08  1:06 Two versions of a project in one GIT repository Kacper
2010-01-08  3:57 ` Dmitry Potapov [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

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

  git send-email \
    --in-reply-to=20100108035729.GB28263@dpotapov.dyndns.org \
    --to=dpotapov@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kacper.gazda@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.
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).