Hi,
It looks like your transition to git has been a success. Your very
careful conversion from CVS to git and your exacting scrutiny of the
results are a great check that cvs2git is not doing anything completely
crazy. I will soon release a version 2.4 of cvs2svn that includes the
many improveme
On 09/13/2010 03:14 AM, Tom Lane wrote:
[...]
Now as far as I can tell, the branch was made immediately before those
test commits you can see Marc making in each branch. In particular,
it was definitely made *after* Bryan deleted the src/bin/monitor files,
because neither of them have REL2_0 or
Tom Lane wrote:
> Well, even if the goal is to faithfully represent the bogus history
> shown by CVS, cvs2git isn't doing a good job of it.
Them's fightin' words :-)
> In the case of
> src/bin/pg_dump/po/it.po, the CVS history claims that the version
> added to REL8_4_STABLE on 2010-05-13 is a ch
Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 7, 2010 at 17:07, Tom Lane wrote:
>>> Look for
>>>This commit was manufactured by cvs2svn to create branch ...
>
>> Ok, found a bunch of those (78 to be exact). And the issue with them
>> is we want to change the commit author on t
Tom Lane wrote:
> Michael Haggerty writes:
>> No, it is also possible to use "cvs tag -b REL8_4_STABLE filename". In
>> this case the file as it appears on the current branch is added to the
>> specified branch, but CVS records no commit, author, or timestamp
Tom Lane wrote:
> I wrote:
>> Michael Haggerty writes:
>>> On the contrary, I prefer an obvious indication of "I don't know" to a
>>> value that might appear to be authoritative but is really just a guess.
>>> It could be that one user copied th
Tom Lane wrote:
> Michael Haggerty writes:
>> CVS does not record when a branch was created or by whom. If a git
>> commit has to be created for such events, cvs2git attributes them to a
>> configurable username, which Max has set to be "pgsql". It chooses the
&g
Tom Lane wrote:
> Max Bowsher writes:
>> For both, see http://github.com/maxb
>
> [...] The only real gripe I can find to make is that in the cases where
> a file is added to a back branch, the "manufactured" commit is
> invariably blamed on committer "pgsql". Can't we arrange to blame it
> on t
Max Bowsher wrote:
> On 02/09/10 16:44, Michael Haggerty wrote:
>> My understanding was that the problem is not that the branches are
>> created, but that they are created from a non-optimal starting point,
>> making it necessary for each of them to be doctored using a fixup
Max Bowsher wrote:
> On 02/09/10 14:40, Michael Haggerty wrote:
>> Robert Haas wrote:
>>> On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty
>>> wrote:
>>>> What weirdness, exactly, are you discussing now? I've lost track of
>>>> which p
Robert Haas wrote:
> On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty wrote:
>> What weirdness, exactly, are you discussing now? I've lost track of
>> which problem(s) are still unresolved.
>
> Lots of commits that look like this:
>
> commit c50da22b6050e0bdd
Robert Haas wrote:
> On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander wrote:
>>> That definitely didn't fix it, although I'm not quite sure why. Can
>>> you throw the modified CVS you ran this off of up somewhere I can
>>> rsync it?
>> no rsync server on that box, but I put up a tarball for you at
Robert Haas wrote:
> Well, the history here is pretty weird. In relevant part, here's the
> result of cvs log on src/backend/parser/gram.c:
>
> revision 2.92
> date: 2007/04/17 01:06:27; author: tgl; state: dead; lines: +0 -0
> And remove 'em again ...
>
> revision
Robert Haas wrote:
> This series of commits also seems pretty messed up:
>
> http://archives.postgresql.org/pgsql-committers/2007-04/msg00222.php
> http://archives.postgresql.org/pgsql-committers/2007-04/msg00223.php
>
> The commit messages make it clear that CVS did something funky,
> although i
Max Bowsher wrote:
> On 25/08/10 12:36, Heikki Linnakangas wrote:
>> On 25/08/10 14:03, Max Bowsher wrote:
>>> cvs2git will try to use the timestamps from the commits, but sometimes
>>> the ordering of how revisions and tags relate to each other will
>>> actually disagree with the timestamps. In su
; There is a commit message on the trunk when the file was added there.
>>>> Is there any chance of being able to lift that message off trunk and
>>>> just copy it into the branch, instead of saying "this is a cherry-pick
>>>> of this commit over here"?
>
Magnus Hagander wrote:
> Is there some way to make cvs2git work this way, and just not bother
> even trying to create merge commits, or is that fundamentally
> impossible and we need to look at another tool?
The good news: (I just reminded myself/realized that) Max Bowsher has
already implemented
Alvaro Herrera wrote:
> Excerpts from Michael Haggerty's message of mié ago 18 12:00:44 -0400 2010:
>
>> 3. Run
>>
>> git filter-branch
>>
>> This rewrites the commits using any parentage changes from the grafts
>> file. This changes most commits' SHA1 hashes. After this you can
>> discard t
Tom Lane wrote:
> Michael Haggerty writes:
>> The "exclusive" possibility is to ignore the fact that some of the
>> content of B4 came from trunk and to pretend that FILE1 just appeared
>> out of nowhere in commit B4 independent of the FILE1 in TRUNK:
>
&
Robert Haas wrote:
> Exactly. IMHO, the way this should work is by starting at the
> beginning of time and working forward. [...]
What you are describing is more or less the algorithm that was used by
cvs2svn version 1.x. It mostly works, but has nasty edge cases that are
impossible to fix.
cv
Alvaro Herrera wrote:
> Excerpts from Michael Haggerty's message of mié ago 18 05:01:29 -0400 2010:
>
>> [...] Alternatively, you
>> could write a tool that would rewrite the ancestry information in the
>> repository *after* the cvs2git conversion using .git/info/grafts (see
>> git-filter-branch(
Tom Lane wrote:
> Michael Haggerty writes:
>> So let's take the simplest example: a branch BRANCH1 is created from
>> trunk commit T1, then some time later another FILE1 from trunk commit T3
>> is added to BRANCH1 in commit B4. How should this series of events
Martijn van Oosterhout wrote:
> On Wed, Aug 18, 2010 at 08:25:45AM +0200, Michael Haggerty wrote:
>> So let's take the simplest example: a branch BRANCH1 is created from
>> trunk commit T1, then some time later another FILE1 from trunk commit T3
>> is added to BRANCH1
Tom Lane wrote:
> I lack git-fu pretty completely, but I do have the CVS logs ;-).
> It looks like some of these commits that are being ascribed to the
> REL8_3_STABLE branch were actually only committed on HEAD. For
> instance my commit in contrib/xml2 on 28 Feb 2010 21:31:57 was
> only in HEAD.
Alex Hunsaker wrote:
> On Tue, Aug 17, 2010 at 13:52, Alex Hunsaker wrote:
>> How sure are we that its not the cvs2svn step that is screwing it up?
>
> urp, I jumped to a conclusion while skimming the cvs2git.options file
> Magnus posted. With all the references to svn and things like
> "GitRevi
25 matches
Mail list logo
