2009/6/7 Tom Lane t...@sss.pgh.pa.us:
So there are a lot of good reasons to work backwards in patching.
I don't believe that these would be outweighed by some advantage
in the mechanics of applying an unchanging patch to multiple
branches (especially since AFAICT the mechanical advantage would
Hi,
Quoting Mark Mielke m...@mark.mielke.cc:
I am a theory person - I run things in my head. To me, the concept
of having more context to make the right decision, and an algorithm
that takes advantage of this context to make the right decision, is
simple and compelling on its own. Knowing
Robert Haas wrote:
On Fri, Jun 5, 2009 at 12:15 PM, Tom Lanet...@sss.pgh.pa.us wrote:
... but I'm not at all excited about cluttering the
long-term project history with a zillion micro-commits. One of the
things I find most annoying about reviewing the current commit history
is that Bruce
Hi,
Quoting Nicolas Barbier nicolas.barb...@gmail.com:
If I understand correctly, nearby variable renaming refers to
changes to the few lines surrounding the changes-to-be-merged.
Hm.. I took that to mean changes on the same line. I now realize
this interpretation has been an overly strict
Markus Wanner wrote:
Quoting Mark Mielke m...@mark.mielke.cc:
I am a theory person - I run things in my head. To me, the concept of
having more context to make the right decision, and an algorithm that
takes advantage of this context to make the right decision, is simple
and compelling on its
Hi,
Quoting Nicolas Barbier nicolas.barb...@gmail.com:
ISTM that back-patching
I take this to mean back-patching by cherry picking.
a change to a file that wasn't modified on the
back-branch leads exactly to merging a change to a (file-wise)
ancestor?
Regarding the file's contents - and
2009/6/7 Markus Wanner mar...@bluegap.ch:
However, there's no special whitespace treatment. Nor anything remotely
as clever as nearby variable renaming. There's no such magic, the
developer still needs to tell the tool what he wants.
If I understand correctly, nearby variable renaming refers
Hi,
Tom Lane wrote:
I think it's already been made crystal clear that the people who
actually do this work don't do it that way, and are uninterested in
allowing their tools to force them to do it that way.
That's well understood.
Patching from
HEAD back works better for us for a number of
Hi,
Andrew Dunstan wrote:
Yeah, a requirement to work from the back branch forward is quite
unacceptable IMNSHO. It's also quite unreasonable.
The monotone page about daggy fixes does quite a good job in explaining
why it is helpful. I think it's how to make best use of these tools. And
it's
Markus Wanner mar...@bluegap.ch writes:
Out of interest, and not necessarily related to Postgres: why do you
think it's unreasonable? Fixing the problem where it was introduced
sounds like the most reasonable place to fix it, IMO.
There are a number of possible reasons, but here are a few that
Markus Wanner wrote:
Hi,
Andrew Dunstan wrote:
Yeah, a requirement to work from the back branch forward is quite
unacceptable IMNSHO. It's also quite unreasonable.
The monotone page about daggy fixes does quite a good job in explaining
why it is helpful. I think it's how to make
Andrew Dunstan and...@dunslane.net writes:
[ most of a good summary omitted ]
... Even fairly trivial patches can suffer
from this: the pretty small plperl fixes I applied yesterday and the day
before, required adjustment going from one branch to the previous one in
about three out of five
Tom Lane wrote:
I have heard it claimed that git is more intelligent than plain
diff/patch and could successfully merge patches in cases that currently
require manual adjustment of the sort Andrew describes. If that's
really true to any significant extent, then it could represent a benefit
Mark Mielke m...@mark.mielke.cc writes:
Tom Lane wrote:
I have heard it claimed that git is more intelligent than plain
diff/patch and could successfully merge patches in cases that currently
require manual adjustment of the sort Andrew describes.
...
However, I have yet to see any actual
On Fri, Jun 5, 2009 at 4:37 PM, Tom Lanet...@sss.pgh.pa.us wrote:
However, given that we don't do any real development on the back
branches, it might be that trying to be smart about this is a waste of
time anyway. Surely only the HEAD version of the patch is going to be
something that other
Tom Lane wrote:
Any revision control system should be able to do better than diff/patch
as these systems have more information available to them. Normal GIT
uses the relatively common 3-way merge based upon the most recent common
ancestor algorithm. Assuming there is a most recent common
Hi,
Tom Lane wrote:
There are a number of possible reasons, but here are a few that hold for me:
Thank you for this very good collection. I'm still wondering about
what's the best way to represent this in git (or others). Cherry-picking
is arguably the simplest variant. Maybe that can be
Hi,
Andrew Dunstan wrote:
One fact to keep in mind is that, unlike most other FOSS projects, we
keep quite a large number of branches live.
So far I thought exactly that would be a good reason for migrating to
something like git. Those claim to ease working on multiple branches in
parallel,
Hi,
Tom Lane wrote:
How robust is git about dealing with whitespace changes,
nearby variable renamings, and such?
Monotone tracks changes line by line. I'm not sure about git. Kdiff3,
which is used to do the manual merge, if necessary, uses some finer
grained method, AFAIK.
However, there's
Tom Lane wrote:
Any revision control system should be able to do better than diff/patch
as these systems have more information available to them. Normal GIT
uses the relatively common 3-way merge based upon the most recent common
ancestor algorithm. Assuming there is a most recent common
Hi,
Quoting Ron Mayer rm...@cheapcomplexdevices.com:
Seems you'd want to do is create a new branch as close to the point
where the bug was introduced - and then merge that forward into each
of the branches.
Thank you for pointing this out. As a fan of monotone I certainly know
and like that
Markus Wanner mar...@bluegap.ch writes:
Note that a requirement for daggy fixes is that the bug is fixed
close to the point where it was introduced. So fixing it on the
oldest stable branch that introduced a bug instead of fixing it on
HEAD and then back-porting would certainly be a step
Tom Lane wrote:
Markus Wanner mar...@bluegap.ch writes:
Note that a requirement for daggy fixes is that the bug is fixed
close to the point where it was introduced. So fixing it on the
oldest stable branch that introduced a bug instead of fixing it on
HEAD and then back-porting would
On Fri, Jun 5, 2009 at 9:38 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Markus Wanner mar...@bluegap.ch writes:
Note that a requirement for daggy fixes is that the bug is fixed
close to the point where it was introduced. So fixing it on the
oldest stable branch that introduced a bug instead of
Robert Haas robertmh...@gmail.com writes:
I'm sure someone is going to come in here and again recommend merging,
but I'm going to again recommend not merging. Cherry-picking is the
way to go here. Or just commit to each branch completely separately
with the same commit message; cherry-pick
On Fri, Jun 5, 2009 at 11:37 AM, Tom Lanet...@sss.pgh.pa.us wrote:
However, given that we don't do any real development on the back
branches, it might be that trying to be smart about this is a waste of
time anyway. Surely only the HEAD version of the patch is going to be
something that other
Robert Haas robertmh...@gmail.com writes:
[ about micro commits ]
(As a side benefit, if one of my little micro-commits turns out to
have a bug, you can easily revert *just that commit*, without having
to manually sort out exactly which pieces related to that change.)
I don't actually have a
On Fri, Jun 5, 2009 at 12:15 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
[ about micro commits ]
(As a side benefit, if one of my little micro-commits turns out to
have a bug, you can easily revert *just that commit*, without having
to manually sort out
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
[ about micro commits ]
(As a side benefit, if one of my little micro-commits turns out to
have a bug, you can easily revert *just that commit*, without having
to manually sort out exactly which pieces related to that change.)
I
* Andrew Dunstan and...@dunslane.net [090605 13:55]:
Yeah, a requirement to work from the back branch forward is quite
unacceptable IMNSHO. It's also quite unreasonable. The tool is there to
help, not to force an unnatural work pattern on us.
Again, just to make it clear, git isn't going
Aidan Van Dyk wrote:
* Andrew Dunstan and...@dunslane.net [090605 13:55]:
Yeah, a requirement to work from the back branch forward is quite
unacceptable IMNSHO. It's also quite unreasonable. The tool is there to
help, not to force an unnatural work pattern on us.
Again, just to
* Andrew Dunstan and...@dunslane.net [090605 14:41]:
The whole point is that we want something better *that suits our work
patterns*. Almost all the backpatching that gets done is by the
committers. So we have a bunch of concerns that are not relevant to that
vast majority of
Hi,
Quoting Greg Stark st...@enterprisedb.com:
This is all completely irrelevant to the CVS import.
To the CVS import it is, yes. After all, CVS has no notion of renaming
files. But my example is about renaming with git *after* the
conversion. Git *does* support renaming (to some extent).
On 4 Jun 2009, at 09:11, Markus Wanner mar...@bluegap.ch wrote:
Hi,
Quoting Greg Stark st...@enterprisedb.com:
This is all completely irrelevant to the CVS import.
To the CVS import it is, yes. After all, CVS has no notion of
renaming files. But my example is about renaming with git
Hi,
Quoting Greg Stark greg.st...@enterprisedb.com:
Hmm. I see. I'm not sure we've ever added files to back branches
either. I'm less sure of that though.
We did from time to time. Every merge commit in my current conversion
contains at least one such file that got added as part of a back
Hi,
Quoting Tom Lane t...@sss.pgh.pa.us:
BTW, Markus: you do realize thomas is not me but Tom Lockhart?
Uh.. thanks, that name has fallen through the cracks, before. I've
added it now, it will be included in the next sample conversion.
Regards
Markus Wanner
--
Sent via pgsql-hackers
Hi,
Quoting Marko Kreen mark...@gmail.com:
I'm not sure whether we should mark the old branches getting merges
down or the new branches getting merged up. I suspect I'm missing
something but I don't see any reason one is better than the other.
As pointed out by others, it doesn't make
Markus Wanner wrote:
The new branches getting merged up could work. That is, applying the
fix to the oldest back-branch which requires the fix first and then
merge it to all newer ones, including HEAD. However, that would require
some rethinking: instead of creating bugfix-patches for HEAD,
Hi,
Quoting Marko Kreen mark...@gmail.com:
The example was not actual case from Postgres CVS history,
but hypotetical situation without checking if it already works
with GIT.
Of course it is a simplified example, but it resembles what could
happen i.e. to the file
On Wed, Jun 3, 2009 at 12:10 PM, Markus Wanner mar...@bluegap.ch wrote:
If you create separate commits during the conversion, rename that file on
the master branch
This is all completely irrelevant to the CVS import. I don't think
we've ever renamed files because CVS can't handle it cleanly.
Hi,
On 06/03/2009 02:08 PM, Greg Stark wrote:
On Wed, Jun 3, 2009 at 12:10 PM, Markus Wannermar...@bluegap.ch wrote:
That would make the git history match Tom's same commit message
implicit CVS history that cvs2pcl was giving him. I find git-log's
output including merge commits kind of strange
On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund and...@anarazel.de wrote:
git log --no-merges hides the actual merge commits if that is what you
want.
Ooh! Life seems so much sweeter now!
Given that we don't have to see them then I'm all for marking bug fix
patches which were applied to multiple
Greg Stark wrote:
On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund and...@anarazel.de wrote:
git log --no-merges hides the actual merge commits if that is what you
want.
Ooh! Life seems so much sweeter now!
Given that we don't have to see them then I'm all for marking bug fix
patches which
On 6/3/09, Greg Stark st...@enterprisedb.com wrote:
On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund and...@anarazel.de wrote:
git log --no-merges hides the actual merge commits if that is what you
want.
Ooh! Life seems so much sweeter now!
Given that we don't have to see them then I'm
On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander mag...@hagander.net wrote:
Greg Stark wrote:
On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund and...@anarazel.de wrote:
git log --no-merges hides the actual merge commits if that is what you
want.
Ooh! Life seems so much sweeter now!
Given that
On 6/3/09, Magnus Hagander mag...@hagander.net wrote:
Robert Haas wrote:
On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander mag...@hagander.net
wrote:
I'm not sure whether we should mark the old branches getting merges
down or the new branches getting merged up. I suspect I'm missing
* Magnus Hagander mag...@hagander.net [090603 10:13]:
Right, if it adds additional metadata that lets the tools do their magic
better, and it's still easy to filter out, I don't see a downside.
Note, that it could (and likely will) have a downside when you get to
doing real merge-based
* Marko Kreen mark...@gmail.com [090603 10:26]:
Thats true, but it's not representable in VCS, unless you use cherry-pick,
which is just UI around patch transport. But considering separate
local trees (with can optionally contain local per-fix branches),
it is possible to separate the
Robert Haas wrote:
On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander mag...@hagander.net wrote:
I'm not sure whether we should mark the old branches getting merges
down or the new branches getting merged up. I suspect I'm missing
something but I don't see any reason one is better than the
On Wed, Jun 3, 2009 at 10:20 AM, Marko Kreen mark...@gmail.com wrote:
Various scenarios with git cherry-pick and similar tools would still
result in duplicate commits, so we would need a git log post-processor
anyway if we want to somehow group them together for eg. weekly commit
summary. And
On 6/3/09, Aidan Van Dyk ai...@highrise.ca wrote:
* Marko Kreen mark...@gmail.com [090603 10:26]:
Thats true, but it's not representable in VCS, unless you use cherry-pick,
which is just UI around patch transport. But considering separate
local trees (with can optionally contain local
* Marko Kreen mark...@gmail.com [090603 11:12]:
Well, thats good to know, but this also seems to mean it's rather bad
tool for back-patching, as you risk including random unwanted commits
too that happened in the HEAD meantime. But also, it's very good
tool for forward-patching.
It doesn't
On 6/3/09, Aidan Van Dyk ai...@highrise.ca wrote:
* Marko Kreen mark...@gmail.com [090603 11:12]:
Well, thats good to know, but this also seems to mean it's rather bad
tool for back-patching, as you risk including random unwanted commits
too that happened in the HEAD meantime. But also,
* Marko Kreen mark...@gmail.com [090603 11:28]:
I'm not certain, but I remember using cherry pick and seeing
several commits in result. This seems to be a point that needs
to be checked.
I'm not sure what you're recalling, but git cherry-pick takes a single
commit, and applies it as a
Robert Haas wrote:
But I
wonder if it would make more sense to include some kind of metadata in
the commit message (or some other property of the commit? does git
support that?) to make it not depend on that.
From elsewhere in this thread[1], 'The git cherry-pick ... -x flag adds
a note to
On 6/1/09, Markus Wanner mar...@bluegap.ch wrote:
a newish conversion with cvs2git is available to check here:
git://www.bluegap.ch/
(it's not incremental and will only stay for a few days)
+1 for the idea of replacing CVS usernames with full names.
The knowledge about CVS usernames
On 6/2/09, Marko Kreen mark...@gmail.com wrote:
On 6/1/09, Markus Wanner mar...@bluegap.ch wrote:
a newish conversion with cvs2git is available to check here:
git://www.bluegap.ch/
(it's not incremental and will only stay for a few days)
Btw this conversion seems broken as it
Hi,
Quoting Marko Kreen mark...@gmail.com:
I don't care half as much about the keyword expansion stuff - that's
doomed to disappear anyway.
But this is one aspect we need to get right for the conversion.
What's your definition of right? I personally prefer the keyword
expansion to match
On 6/2/09, Markus Wanner mar...@bluegap.ch wrote:
Quoting Marko Kreen mark...@gmail.com:
I don't care half as much about the keyword expansion stuff - that's
doomed to disappear anyway.
But this is one aspect we need to get right for the conversion.
What's your definition of
Hi,
Quoting Marko Kreen mark...@gmail.com:
Btw this conversion seems broken as it contains random merge commits.
Well, that's a feature, not a bug ;-)
When a commit adds a file to the master *and* then to the branch as
well, cvs2git prefers to represent this as a merge from the master
Hi,
Quoting Marko Kreen mark...@gmail.com:
This is Definitely Wrong (tm). You seem to be thinking that comparing
GIT checkout to random parallel CVS checkout (eg. from .tgz.) is the
main use-case. It is not. Browsing history and looking and diffs
between versions is. And expanded CVS
On 6/2/09, Markus Wanner mar...@bluegap.ch wrote:
Quoting Marko Kreen mark...@gmail.com:
Btw this conversion seems broken as it contains random merge commits.
Well, that's a feature, not a bug ;-)
When a commit adds a file to the master *and* then to the branch as well,
cvs2git
* Markus Wanner mar...@bluegap.ch [090602 07:08]:
Hi,
Quoting Marko Kreen mark...@gmail.com:
I don't care half as much about the keyword expansion stuff - that's
doomed to disappear anyway.
But this is one aspect we need to get right for the conversion.
What's your definition of right? I
Hi,
Quoting Aidan Van Dyk ai...@highrise.ca:
Pick your poison (after all, it's CVS), either way, I think the 2 of
*us* are going to disagree which is best here ;-)
Marko already convinced me of -kk, I'm trying that with cvs2git.
But, which ever way (exact to -kk or exact to -kv), the
* Markus Wanner mar...@bluegap.ch [090602 09:37]:
Marko already convinced me of -kk, I'm trying that with cvs2git.
Good ;-)
I just really didn't want to care about keyword expansion. Besides
lacking consistency, it's one of the worst misfeatures of CVS, IMNSHO.
;-)
Absolutely... And
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
* Markus Wanner mar...@bluegap.ch [090602 10:23]:
# 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.
Sure, and we can all construct example
Aidan Van Dyk escribió:
* Markus Wanner mar...@bluegap.ch [090602 10:23]:
# 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.
Sure, and
Aidan Van Dyk ai...@highrise.ca writes:
* Markus Wanner mar...@bluegap.ch [090602 10:23]:
You consider it a mess, I consider it a better and more valid
representation of the mess that CVS is.
So much better that it makes the history as useless as CVS... I think
one of the reasons people
Hi,
Quoting Aidan Van Dyk ai...@highrise.ca:
Sure, and we can all construct example where that move is both right and
wrong...
Huh? The problem is the file duplication. The move is an action of a
committer - it's neither right nor wrong in this example.
I cannot see any use case for
On Tue, Jun 2, 2009 at 4:02 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
The Monotone folk call this daggy fixes and it seems a clean way to
handle things.
http://www.monotone.ca/wiki/DaggyFixes/
Is this like what git calls an octopus? I've been wondering what the
point of such
On 6/2/09, Tom Lane t...@sss.pgh.pa.us wrote:
Aidan Van Dyk ai...@highrise.ca writes:
* Markus Wanner mar...@bluegap.ch [090602 10:23]:
You consider it a mess, I consider it a better and more valid
representation of the mess that CVS is.
So much better that it makes the history as
On 6/2/09, Markus Wanner mar...@bluegap.ch wrote:
[academic nitpicking]
Sorry, not going there. Just look at the state of VCS systems
that have prioritized academic issues insead of practicality...
(arch/darcs/monotone/etc..)
So please turn the merge logic off. If this cannot be turned off,
On Tue, Jun 2, 2009 at 11:08 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Aidan Van Dyk ai...@highrise.ca writes:
* Markus Wanner mar...@bluegap.ch [090602 10:23]:
You consider it a mess, I consider it a better and more valid
representation of the mess that CVS is.
So much better that it makes the
Hi,
Quoting Tom Lane t...@sss.pgh.pa.us:
FWIW, the tool that I customarily use (cvs2cl) considers commits on
different branches to be the same if they have the same commit message
and occur sufficiently close together (within a few minutes). My
committing habits have been designed around that
Hi,
Quoting Marko Kreen mark...@gmail.com:
Sorry, not going there. Just look at the state of VCS systems
that have prioritized academic issues insead of practicality...
(arch/darcs/monotone/etc..)
I already am there. And I don't want to go back, thanks. But my bias
for monotone certainly
On 6/2/09, Markus Wanner mar...@bluegap.ch wrote:
Quoting Marko Kreen mark...@gmail.com:
And what silly side effects are you talking about?
I'm talking about spurious file duplicates popping up after a rename and a
merge, see my example in this thread.
The example was not actual case
Aidan Van Dyk wrote:
* Markus Wanner mar...@bluegap.ch [090602 10:23]:
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
Hi,
a newish conversion with cvs2git is available to check here:
git://www.bluegap.ch/
(it's not incremental and will only stay for a few days)
For everybody interested, please check the committer names and emails.
I'm missing the names and email addresses for these committers:
'barry'
Markus Wanner mar...@bluegap.ch writes:
I'm missing the names and email addresses for these committers:
'barry' : ('barry??', ''),
Barry Lind, formerly one of the JDBC bunch, been inactive for awhile
'dennis' : ('Dennis??', ''),
I suppose this must be Dennis Björklund, but I didn't
Tom Lane wrote:
Markus Wanner mar...@bluegap.ch writes:
'dennis' : ('Dennis??', ''),
I suppose this must be Dennis Bj�rklund, but I didn't realize he
used to be a committer.
IIRC he was given commit privs for translation files.
--
Alvaro Herrera
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
I suppose this must be Dennis Björklund, but I didn't realize he
used to be a committer.
IIRC he was given commit privs for translation files.
Ah, right, that does ring a bell now.
BTW, Markus: you do realize thomas is not me
Hi,
Quoting Robert Haas robertmh...@gmail.com:
That's not the best news I've had today...
Sorry :-(
To me they sound complex and inconvenient. I guess I'm kind of
mystified by why we can't make this work reliably. Other than the
broken tags issue we've discussed, it seems like the only
On Thursday 28 May 2009 20:03:38 Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Right. Shall we try to spec out exactly what our conversion
requirements are? Here's a shot:
[...]
Comments? Other considerations?
Certainly sounds reasonable to me. I'd be really suprised
On Fri, May 29, 2009 at 2:41 AM, Markus Wanner mar...@bluegap.ch wrot Hi,
Quoting Robert Haas robertmh...@gmail.com:
Why is this harder than I think it is?
One of the simplest possible example is something like:
Thanks for the explanation, I understand it better now. I'm still
dismayed, but
Hi,
Quoting Aidan Van Dyk ai...@highrise.ca:
Ok, so seeing the interest in having a good conversion, I took a stab at
parsecvs this afternoon, probably what I consider the leading static
conversion tool.
Here are some results from a conversion with cvs2git.
It takes about 10 minutes to run
* Markus Wanner mar...@bluegap.ch [090529 11:06]:
Hi,
Comparison of the head of each branch between git and CVS (modulo CVS
keyword expansion, which I've filtered out):
How did you filter it out, and without the filtering out, how does it
do?
I plan to compare the tags as well and test
Hi,
Quoting Aidan Van Dyk ai...@highrise.ca:
* Markus Wanner mar...@bluegap.ch [090529 11:06]:
Comparison of the head of each branch between git and CVS (modulo CVS
keyword expansion, which I've filtered out):
How did you filter it out
With perl some regexes.
and without the filtering
* Markus Wanner mar...@bluegap.ch [090529 11:18]:
Hi,
Quoting Aidan Van Dyk ai...@highrise.ca:
* Markus Wanner mar...@bluegap.ch [090529 11:06]:
Comparison of the head of each branch between git and CVS (modulo CVS
keyword expansion, which I've filtered out):
How did you filter it out
Aidan Van Dyk wrote:
Yes, but the point is you want an exact replica of CVS right? You're
git repo should have $PostgreSQL$ and the cvs export/checkout (you do
use -kk right) should also have $PostgreSQL$.
The 3 parsecvs errors were that it *didn't* recognoze the strange
$PostgreSQL ...
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribi�:
What was in the back of my mind was that we'd go around and mass-remove
$PostgreSQL$ (and any other lurking tags), but only from HEAD and only
after the repo conversion. Although just before it would
* Alvaro Herrera alvhe...@commandprompt.com [090529 11:45]:
Aidan Van Dyk wrote:
Yes, but the point is you want an exact replica of CVS right? You're
git repo should have $PostgreSQL$ and the cvs export/checkout (you do
use -kk right) should also have $PostgreSQL$.
The 3 parsecvs
Hi,
Quoting Marc G. Fournier scra...@hub.org:
Please repost ...
Peter referred to this message here:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg01879.php
However, please be cautious before applying such a patch.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list
Hi,
Quoting Marc G. Fournier scra...@hub.org:
Actually, I have done that on at least one of the 8.x tags too, so
if that is it, more then those two tags should be causing issues ...
Not *every* such issue causes problems. An example that's perfectly fine:
cvs commit -m first commit fileA
Hi,
Quoting Robert Haas robertmh...@gmail.com:
I think this is a semantic argument. The problem isn't that we don't
understand how CVS behaves; it's that we find that behavior
undesirable
I fully agree to that and find it undesirable as well.
aka broken.
Well, for some it's a feature,
* Robert Haas robertmh...@gmail.com [090527 22:43]:
On Wed, May 27, 2009 at 10:09 PM, Aidan Van Dyk ai...@highrise.ca wrote:
* Robert Haas robertmh...@gmail.com [090527 21:30]:
And actually looking at the history of the gpo repo, the branches are all
messed up with merges and stuff that
On Thu, May 28, 2009 at 8:59 AM, Aidan Van Dyk ai...@highrise.ca wrote:
All that based on the assumption that when the project switches to git,
they actually want all the CVS history in their official tree. Its
certainly not necessary, and possibly not even desirable... PostgreSQL
could just
* Robert Haas robertmh...@gmail.com [090528 09:49]:
On Thu, May 28, 2009 at 8:59 AM, Aidan Van Dyk ai...@highrise.ca wrote:
All that based on the assumption that when the project switches to git,
they actually want all the CVS history in their official tree. Its
certainly not necessary,
Robert Haas wrote:
On Thu, May 28, 2009 at 8:59 AM, Aidan Van Dyk ai...@highrise.ca wrote:
All that based on the assumption that when the project switches to git,
they actually want all the CVS history in their official tree. Its
certainly not necessary, and possibly not even desirable...
Andrew Dunstan and...@dunslane.net writes:
Robert Haas wrote:
That would suck for me. I use git log a lot to see how things have
changed over time.
Indeed. Losing the history is not an acceptable option.
I think the same. If git is not able to maintain our project history
then it is not
1 - 100 of 156 matches
Mail list logo
