Re: PostgreSQL Developer meeting minutes up - Mailing list pgsql-hackers

Hi,

Quoting "Marko Kreen" <markokr@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" >
testfilegit 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
filescalled "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