Hi,
Quoting "Marko Kreen" <mark...@gmail.com>:
Not a problem for git I think
Knowing that git doesn't track files as "hard" as monotone, I
certainly doubt that.
- it assumes they are same if they have
same contents...
Why do you assume they have the same contents? Obviously these are
different branches, where files can (and will!) have different contents.
Well, such behaviour may be a feature for some repo with complex CVS
usage, but currently we should aim for simple and clear conversion.
First of all, we should aim for a correct one.
The question is - do such merges make any sense to human looking at
history - and the answer is no, as no VCS level merge was happening,
just some copying around (if your description is correct). And
we don't need to add noise for the benefit of GIT as it works fine
without any fake merges.
For low expectations of "it works", maybe yes. However if you don't
tell git, it has no chance of knowing that two (different) files
should actually be the same.
Try the following:
git init
echo "base" > basefile
git add basefile
git commit -m "base commit"
git checkout -b branch
echo "hello, world" > testfile
git add testfile
git commit testfile -m "addition on branch"
git checkout master
echo "hello world" > testfile
git add testfile
git commit testfile -m "addition on master"
# here we are a similar point like after a lacking conversion, having two
# distinct, i.e. historically independent files called "testfile"
git mv testfile movedfile
git commit -m "file moved"
git checkout branch
git merge master
ls
# Bang, you suddenly have 'testfile' and 'movedfile', go figure!
I leave it as an exercise for the reader to try the same with a single
historic origin of the file, as cvs2git does the conversion.
Our target should be each branch having simple linear history,
without any fake merges. This will result in minimal confusion
to both humans looking history and also GIT itself.
I don't consider the above a "minimal confusion". And concerning
humans... you get used to merge commits pretty quickly. I for one am
more confused by a linear history which in fact is not.
As mentioned before, I'd personally favor *all* of the back-ports to
actually be merges of some sort, because that's what they effectively
are. However, that also bring up the question of how we are going to
do back-patches in the future with git.
So please turn the merge logic off. If this cannot be turned off,
cvs2git is not usable for conversion.
As far as I know, it cannot be turned off. Use parsecvs if you want to
get silly side effects later on in history. ;-)
Seems it contains more complex logic to handle more complex CVS usage
cases, but seems like overkill for us if it creates a mess of history.
You consider it a mess, I consider it a better and more valid
representation of the mess that CVS is.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
