Hello,
Our team works on an existing project that's in CVS, but we don't have
the permissions to commit directly to it. We still need to make
changes and want to stay as up to date as possible, so we are trying
to use git to track the CVS repository and to collaborate inside the
team.
Now, I'm quite new to git, so I'm not sure if the solution I created
is "correct", not way too complicated, or if there are problems waiting
for us.
git-cvsimport seems to be the solution, so I've established the
following structure:
+-----------------+
| dev.eclipse.org |
+-----------------+
^
| (1)
| (2) (3)
+---------------+ +---------------+ +------------+
| ifs:/from-cvs | ---> | ifs:/git-proj | <----- | Merge-Dude |
+---------------+ +---------------+ +------------+
/ \
/ \
/ \
+------+ +------+
| User | (4) | User |
+------+ +------+
1) I use git-cvsimport to update the repository every night. /git-proj
is a "clone --bare" of the /from-cvs repository.
2) After the import, I push the changes from CVS to /git-proj using
'git push /git-proj origin'.
This first two steps can be done with a cronjob, there shouldn't be
any conflicts.
3) Then we have the role of a "Merge-Dude" who pulls the changes from
/git-proj and uses 'git merge origin/origin' to update his master.
If there are any conflicts, he resolves them and pushes everything
back to the master at /git-proj.
4) The users can just push and pull from /git-proj.
From time to time, we can use 'git diff origin/origin' to get a patch
with all the changes we made and have to send upstream.
What do you guys think, is this approach feasible?
What I don't like is how we have to make the upstream patch(es). Is
there an easy way we can get multiple patches, lets say for each
commit we made? Or is it easier to make a lots of branches and to
then create a patch from the diff between the branch and origin/origin?
Wow, this got longer than I expected. Thanks in advance!
Mirko Stocker
On Fri, Jun 13, 2008 at 04:33:34PM +0200, Mirko Stocker [off-list ref] wrote:
3) Then we have the role of a "Merge-Dude" who pulls the changes from
/git-proj and uses 'git merge origin/origin' to update his master.
If there are any conflicts, he resolves them and pushes everything
back to the master at /git-proj.
4) The users can just push and pull from /git-proj.
From time to time, we can use 'git diff origin/origin' to get a patch
with all the changes we made and have to send upstream.
What do you guys think, is this approach feasible?
What I don't like is how we have to make the upstream patch(es). Is
there an easy way we can get multiple patches, lets say for each
commit we made? Or is it easier to make a lots of branches and to
then create a patch from the diff between the branch and origin/origin?
Don't you mean origin/master?
In general, if you don't merge your changes but you rebase on top of the
new upstream head, then you can use 'git format-patch origin/master..'
to create patches for each commit.
It'll include the commit message and each commit will be written out as
a separate file.
From: Jeff King <hidden> Date: 2016-06-15 22:44:44
On Fri, Jun 13, 2008 at 04:33:34PM +0200, Mirko Stocker wrote:
1) I use git-cvsimport to update the repository every night. /git-proj
is a "clone --bare" of the /from-cvs repository.
2) After the import, I push the changes from CVS to /git-proj using
'git push /git-proj origin'.
You could simplify this by just cvsimporting to an 'upstream' branch in
git-proj.
3) Then we have the role of a "Merge-Dude" who pulls the changes from
/git-proj and uses 'git merge origin/origin' to update his master.
If there are any conflicts, he resolves them and pushes everything
back to the master at /git-proj.
And then it works the same: he just pulls 'upstream' occasionally,
merges it into your work, and then pushes the result.
-Peff
On Fri, Jun 13, 2008 at 10:43:36PM +0200, Mirko Stocker [off-list ref] wrote:
quoted
Don't you mean origin/master?
Hm, I'm not sure.. if I work on an a feature in a branch, and now I want to
create a patch that applies to the CVS head, then I have to make the diff to
origin/origin, right?
'origin/origin' means the 'origin' branch of the 'origin' remote. Given
that you said you created the 'origin' remote's repo using
git-cvsimport, I assumed that the 'origin' remote has only one branch
(named 'master').
On Friday 13 June 2008 16:50:10 Miklos Vajna wrote:
On Fri, Jun 13, 2008 at 04:33:34PM +0200, Mirko Stocker
[off-list ref] wrote:
quoted
What I don't like is how we have to make the upstream patch(es). Is
there an easy way we can get multiple patches, lets say for each
commit we made? Or is it easier to make a lots of branches and to
then create a patch from the diff between the branch and origin/origin?
Don't you mean origin/master?
Hm, I'm not sure.. if I work on an a feature in a branch, and now I want to
create a patch that applies to the CVS head, then I have to make the diff to
origin/origin, right?
In general, if you don't merge your changes but you rebase on top of the
new upstream head, then you can use 'git format-patch origin/master..'
to create patches for each commit.
Ah, I didn't know about git-rebase, thanks! That's exactly what I wanted :) I
think I've already fallen in love with git.
On Fri, Jun 13, 2008 at 04:33:34PM +0200, Mirko Stocker wrote:
quoted
1) I use git-cvsimport to update the repository every night. /git-proj
is a "clone --bare" of the /from-cvs repository.
2) After the import, I push the changes from CVS to /git-proj using
'git push /git-proj origin'.
You could simplify this by just cvsimporting to an 'upstream' branch in
git-proj.
Hm, I've tried that, but it doesnt seem to work.. git-proj is a bare
repository, and git-cvsimport always creates a new .git in it. I'm using
the -C option to specify the target. Is anything else needed?
Regards
Mirko
From: Jeff King <hidden> Date: 2016-06-15 22:44:44
On Fri, Jun 13, 2008 at 10:47:03PM +0200, Mirko Stocker wrote:
Hm, I've tried that, but it doesnt seem to work.. git-proj is a bare
repository, and git-cvsimport always creates a new .git in it. I'm using
the -C option to specify the target. Is anything else needed?
Ah, I hadn't thought of that. Apparently git-cvsimport doesn't
understand bare repos. There is even a Debian bug reported:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472873
You might be able to hack around it with:
mkdir bare.git && (cd bare.git && git init)
mkdir cvsimport-hack && ln -s ../bare.git cvsimport-hack/.git
git cvsimport -C cvsimport-hack
-Peff
On Friday 13 June 2008 22:47:40 Miklos Vajna wrote:
'origin/origin' means the 'origin' branch of the 'origin' remote. Given
that you said you created the 'origin' remote's repo using
git-cvsimport, I assumed that the 'origin' remote has only one branch
(named 'master').
Hm, git-cvsimport created a master and an origin branch. And then I push the
origin branch to the bare repository to share it with my colleagues. So for
the users, origin/origin contains the original CVS content, so we need to
make the diff against that, don't we? That's how I think this whole thing
works, I might be wrong :-)
Ah, I hadn't thought of that. Apparently git-cvsimport doesn't
understand bare repos. There is even a Debian bug reported:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472873
You might be able to hack around it with:
mkdir bare.git && (cd bare.git && git init)
mkdir cvsimport-hack && ln -s ../bare.git cvsimport-hack/.git
git cvsimport -C cvsimport-hack
Uh, ok.. :) Thanks.
I just wondered, do I even need the additional bare repository? If I use
git-cvsimport with -i, then it creates only the .git without doing a
checkout, then we could just clone this one from the clients and pull/push to
it?
Thanks
Mirko
On Sun, Jun 15, 2008 at 10:20:05PM +0200, Mirko Stocker [off-list ref] wrote:
Hm, git-cvsimport created a master and an origin branch. And then I push the
origin branch to the bare repository to share it with my colleagues. So for
the users, origin/origin contains the original CVS content, so we need to
make the diff against that, don't we? That's how I think this whole thing
works, I might be wrong :-)
Oh, you are right. Sorry for the noise. I forgot that git-cvsimport
creates an origin branch without -o master.
Uh, ok.. :) Thanks.
I just wondered, do I even need the additional bare repository? If I use
git-cvsimport with -i, then it creates only the .git without doing a
checkout, then we could just clone this one from the clients and pull/push to
it?
Sure. From the client perspective, there's not really a difference
between a bare repo and one with a working directory. Using just one
repo with a working directory will mean you just have one extra checkout
on the server, which wastes a little space.
-Peff
Sure. From the client perspective, there's not really a difference
between a bare repo and one with a working directory. Using just one
repo with a working directory will mean you just have one extra checkout
on the server, which wastes a little space.
Ok, but in my case I have the checkout on the server in any case, whether I
push it to the bare repository or use it directly.
Thanks again
Mirko
From: John J. Franey <hidden> Date: 2016-06-15 22:44:46
On Fri, 2008-06-13 at 14:33 +0200, Mirko Stocker wrote:
Our team works on an existing project that's in CVS, but we don't have
the permissions to commit directly to it. We still need to make
changes and want to stay as up to date as possible, so we are trying
to use git to track the CVS repository and to collaborate inside the
team.
I'm in a team that is all CVS. I'm the only one using git.
I can commit to CVS, unlike your situation.
Now, I'm quite new to git, so I'm not sure if the solution I created
is "correct", not way too complicated, or if there are problems waiting
for us.
I don't think there is a 'wrong' way. 'Whatever works' is the motto.
The configuration should match the workflow. So, I don't have any
comment on yours. I thought I'd share mine, in case there is value. I
think I will learn something
My setup is:
+----------+
| cvs repo |
+----------+
|
| (1)
|
+----------+
| /cvs_git |
+----------+
|
| (2)
\|/
+---------------------+ (5) +--------------------+
| john's private repo |-------->| john's public repo |
+---------------------+ +--------------------+
|
| (3)
\|/
+--------------------+
| john's cvs sandbox |
+--------------------+
|
\|/ (4)
+----------+
| cvs repo |
+----------+
(1) git-cvsimport -i ...
Runs in cron every 30 minutes.
The output git repo is on a shared server. git users (me) can clone/fetch/pull.
The git repo for cvs is purely one way: no commits are to be pushed to
this repo. All content comes from the cvs repo.
This is importing ALL branches from CVS because it git users (me)
require access to all cvs branches.
(2) git clone -o cvs
Using -o, my private repo uses 'cvs' as the name of the git remote that
tracks cvs. This lets me do 'git fetch cvs', which feels right.
And, to create a branch from the cvs head branch:
'git checkout -b br cvs/origin'
(3) git cvsexportcommit
(4) cvs commit
These close the loop: my changes are committed to cvs repo.
Alternatively, the loop can be closed by emailing patch files to a cvs
committer.
(5) git push public
'public' is the name of my public repo. The commits I push to public
are for developers that are using git (currently zero) who want to see
my work before it gets to cvs' head (which is under high contention).
I expect my team members to push to their one public repo. Then I can
do: 'git fetch alice' to get Alice's work.
At the end of all this, when I do a 'git branch -r' I will see something like:
cvs/br1
cvs/br2
alice/br4
alice/br5
bob/br6
bob/br7
Thus making obvious which branch originates from which developer or from cvs.
In this configuration, the 'merge-dude' is simply another user with a
private and public repo.
Issue with being the git user in a team of cvs users:
git makes merges easier and more robust. I don't want to use cvs anymore.
My main problem is sharing my changes to cvs users. cvs head is under
contention and protection, so I can't simply commit all my changes to
cvs head. Our cvs strategy is to create a branch for each developer or
topic. If I create a branch in cvs repo for my git commits, I'd also
want to keep that cvs branch upto date wrt cvs head. I haven't sorted
out how to do that easily with the git tools.
What I don't like is how we have to make the upstream patch(es). Is
there an easy way we can get multiple patches, lets say for each
commit we made? Or is it easier to make a lots of branches and to
then create a patch from the diff between the branch and origin/origin?
I don't know enough. I'd try it both ways to see which works for you.
Doesn't git easily create a patch file in either case? (This is the
part I'm not sure of.)
Regards,
John