Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Using both git and cvs
- X-seq: zsh-workers 31466
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Using both git and cvs
- Date: Sun, 09 Jun 2013 18:33:33 -0700
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
On Apr 7, 11:33am, I wrote:
> Background: I have my own CVS repository with a slightly customized zsh
> module. It has stuff that's it's not really appropriate to push up to
> sourceforge, e.g., Makefile changes to be able to compile the docs under
> obsolete versions of texinfo, and the like. I use it to pull sources
> onto some hosts where git is not installed and it's a hassle to arrange
> for it to be. I have a script that previously sync'd CVS at sourceforge
> into a local sandbox based on my repository, which I'm updating to base
> the remote repository on git. The sync depends on being able to do a
> multi-way diff against a clean tree that has no version control clutter,
> which until the cutover I would generate with "cvs export".
Having become a little more familiar with git, I've learned that this is
not necessary. Since the two revision control systems are distinct and
use different methodology, I can have a single tree that is both a git
clone and a cvs sandbox.
To set it up, I did this:
git clone git://git.code.sf.net/p/zsh/code
cd code
cvs checkout zsh-5.0.0
(append .git to .cvsignore)
cvs import zsh-5.0 zsh-workers zsh-5-0-0
cd ..
cvs co zsh-5.0
rsync -a zsh-5.0/. code/.
rm -r zsh-5.0
cd code
There's probably a more clever way than the rsync+rm steps, but cvs won't
recursively checkout into a tree that's already populated with subdirs.
At this point I could have done an import for each of the zsh-5.0.1 and
zsh-5.0.2 git tags, but I don't really care about maintaining a "vendor
branch", so I just did:
git stash
git checkout zsh-5.0.1
cvs up -C .cvsignore
I guess I could have done "git checkout -m zsh-5.0.1" there instead of
stashing first (?) but something else I tried with a tagname in place of
a branchname refused to work, so I went with what the checkout error
message suggested and stashed before checking out. To continue:
cvs commit
cvs tag zsh-5-0-1
git stash
git checkout zsh-5.0.2
cvs up -C .cvsignore
cvs commit
cvs tag zsh-5-0-2
git stash
git checkout master
git stash clear
cvs up -C .cvsignore
git add .cvsignore
I probably would have skipped all that if there were more than two tags.
I imagine "git stash pop" would have accomplished the same thing as my
"cvs up -C" ...
So now I'm ready to commit .cvsignore to git, and git informs me that
it doesn't know what to do with all those CVS subdirectories. So I
added CVS to .gitgnore and ran "git commit -am".
At this point I realized that I'd forgotten that cvs creates .#* files
on update conflicts. That's not likely ever to happen if changes are
always going from git into cvs, but might as well fix it, so that got
added to .gitignore as well. Now cvs and git each pretend the other
does not exist, and instead of updating my old sync script I can just
"git pull" followed by "cvs commit" in the same sandbox.
Unfortunately I've now done two commits to the same file on the master
branch. I'd rather push those back up to origin/master as a single commit.
I'm sure someone has explained this before, but could one of the more
experienced git users here describe how to do so, again?
Here's the full "git diff origin/master" so that I have an article number
to reference.
diff --git a/.cvsignore b/.cvsignore
index 971a308..95cdc58 100644
--- a/.cvsignore
+++ b/.cvsignore
@@ -13,3 +13,4 @@ stamp-h
stamp-h.in
autom4te.cache
*.swp
+.git
diff --git a/.gitignore b/.gitignore
index 19d5640..d0172e3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -27,6 +27,9 @@ TAGS
Config/defs.mk
+CVS
+.#*
+
Doc/intro.a4.pdf
Doc/intro.a4.ps
Doc/intro.us.pdf
Messages sorted by:
Reverse Date,
Date,
Thread,
Author