All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Gutierrez <luis.gutierrez@xmos.com>
To: git@vger.kernel.org
Subject: complex cvs import
Date: Fri, 22 Aug 2008 14:13:22 +0100	[thread overview]
Message-ID: <48AEBB72.6060209@xmos.com> (raw)

Hi All,

During the past year or so we have been using a bastardized version of 
CVS in which branches were not 'true' cvs branches, but just a copy of 
the original data in a different folder. For instance, we would have 
something like this:

ProjectX
   \---- dev01
   |       \... normal cvs data
   \---- dev02
   |       \... normal cvs data
   \---- release01
   |       \... normal cvs data
   \---- release02
           \... normal cvs data

While a timeline of the branches looks like this:

                /---release01
----dev01------+                /---release02
                \---dev02------+--

Now that we are trying to move to git, and I'm having problems importing 
the projects with their full history.

What I have done is use git-cvsimport on each of those branches to 
create separate git repositories: dev01, dev02, release01, and release02.

What I was planing on doing next was:
(all from the dev01 branch)
1) git branch dev01
2) git checkout -b release01
3) git pull ssh:/..../release01
4) git checkout -b dev02
5) git pull ssh:/..../dev02
6) git checkout -b release02
7) git pull ssh:/..../release02

Now, the problem I'm seeing is that I get hundreds of conflicts when 
pulling.

Short from doing a git-mergetool 100's of times, is there a better way 
of doing this? One that guarantees I keep the latests version (ie, the 
one I'm pulling from).
Put in another way, is there a way to let git know that it will not 
merge the last version of the files, just the history?

Cheers.

Luis Gutierrez

             reply	other threads:[~2008-08-22 13:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-22 13:13 Luis Gutierrez [this message]
2008-08-22 15:14 ` complex cvs import Michael J Gruber
2008-08-23  9:12 ` Robert Schiele

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=48AEBB72.6060209@xmos.com \
    --to=luis.gutierrez@xmos.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.