Re: Report: removing the inconsistencies in our CVS->git conversion
Tom Lane <tgl@sss.pgh.pa.us>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Applied patch to jdbc from Kim Ho at RedHat, fixing improper handling of empty queries under the V3 protocol
- e8839c2b6c00 7.4.1 cited
-
Applied patch for jdbc from Kim Ho at RedHat to more correctly deal with boolean values
- c020d67bc692 7.4.1 cited
-
Applied patch from Oliver Jowett to improve a buffer sizing.
- d7c609f7c4de 7.4.1 cited
-
Code cleanup inspired by recent resname bug report (doesn't fix the bug
- 88381ade63de 7.4.1 cited
-
Pass shared memory id and socket descriptor number on command line for
- d9fd7d12f6c0 7.4.1 cited
-
Second try at avoiding conflicts with system isblank().
- e3859d1ad982 7.2.5 cited
-
Applied Kris Jurkas patch to fix rollback and SQLException
- 985e551b4866 7.4.1 cited
-
applied patch from Oliver Jowett
- d23fd9572b4c 7.4.1 cited
-
Make the world at least somewhat safe for zero-column tables, and
- 6d0d15c45173 7.3.1 cited
-
Add mention of -F not supported by pg_dumpall. Code already disallows it.
- c43760a7143b 7.3.1 cited
-
Two versions of QueryExecutor, currently only version 2 works 100%
- 78d40a2a2f41 7.3.1 cited
-
modifications to the way the protocol is handled to be consistent with
- 54cc549d8f25 7.3.1 cited
-
Part of Anders Bengtsson's patch to clean up Connection.java
- 00923229c2f0 7.3.1 cited
-
Applied Anders patch to move the startup code out of Connection into StartupPacket
- d96c29ab301a 7.3.1 cited
-
>Added ServerEncoding
- eb1fb8650fb2 7.3.1 cited
-
> I am backing out this patch. Please resubmit with this corrected. Thanks.
- d3337c6e3f9b 7.3.1 cited
-
Fixes bug where query hangs if there is an error in the query, went back to
- 202a19e47bfd 7.3.1 cited
-
Backpatch array I/O code and documentation fixes, also array slice
- bbc1fb07c625 7.2.1 cited
-
fixed QueryExecuter to deal with multiple errors
- 134fe5ec61cb 7.3.1 cited
-
Repair bad calculation in timetz_izone() which gave erroneous results.
- efec53adb3a3 7.2.1 cited
-
backed out changes for cancel, no need to look for two 'Z' responses
- ffe356b5dd39 7.3.1 cited
-
Patch by Nicolas Verger to correctly propogate SQLWarning to the Statement and ResultSet
- 29ea8ff9b13f 7.3.1 cited
-
fixed cancel query bug introduced by patch
- ff2f9b663f73 7.3.1 cited
-
Autoconf for jdbc debug changes.
- b7cc409f7f5e 7.3.1 cited
-
Updated the list of encodings supported to match what the backend now supports
- bf737b859f7e 7.2.1 cited
-
Added some additional comments in the code
- f50793c743c7 7.2.1 cited
-
Update TODO list.
- 311eef41ea01 7.2.1 cited
-
Remove ConnectionHook.java. No longer used, bad code.
- 5621ec0629b1 7.2.1 cited
-
The attached patch removes some old and dead code (and some related
- 0e4d43f4593c 7.2.1 cited
-
First batch of the tools merged in...
- e2e84a1c5e13 7.1.1 cited
-
This patch fixes an arrayindexoutofbounds exception that was just
- 4e45005ffb8f 7.1.1 cited
-
Add ./include/config.h.win32 to RELEASE update list.
- ba6fda5191a1 7.1.1 cited
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Having completed that comparison, I then moved on to trying to get rid of
>> the discrepancies in the git conversion; particularly, trying to get rid
>> of the "manufactured commits". I didn't have much success in that for the
>> cases where the manufactured commit was caused by a back-branch file
>> addition. [...] We still have "manufactured" commits either
>> way, but they are just cosmetic so I guess we should live with them.
> I'm not really following what the history looks like here. What are
> the contents (git show) of the manufactured commit?
A typical example is
commit 4d2ac8075a93c685dbbe920f4bac23288dd7cf11
Author: PostgreSQL Daemon <webmaster@postgresql.org>
Date: Tue Nov 22 18:17:36 2005 +0000
This commit was manufactured by cvs2svn to create branch 'REL7_4_STABLE'.
Cherrypick from master 2005-11-22 18:17:34 UTC Bruce Momjian <bruce@momjian.us> 'Re-run pgindent, fixing a problem where comment lines after a blank':
src/port/unsetenv.c
diff --git a/src/port/unsetenv.c b/src/port/unsetenv.c
new file mode 100644
index 0000000..bdfb3f6
--- /dev/null
+++ b/src/port/unsetenv.c
@@ -0,0 +1,56 @@
+ [ entire contents of unsetenv.c here ]
In the cases where I inserted a dead .0 revision, this is followed by
something like
commit a1bdd263ca8ff657365a97a560f6371f39295efc
Author: Bruce Momjian <bruce@momjian.us>
Date: Tue Nov 22 18:17:37 2005 +0000
Mark branch as deleted.
diff --git a/src/port/unsetenv.c b/src/port/unsetenv.c
deleted file mode 100644
index bdfb3f6..0000000
--- a/src/port/unsetenv.c
+++ /dev/null
@@ -1,56 +0,0 @@
- [ entire contents of unsetenv.c here too ]
I'm a bit disappointed by the fact that we get either of these. I had
gathered from Max's comments that the dead-revision-at-the-base-of-the-
branch trick is considered standard in newer CVS versions, and so I'd
hoped that cvs2git would understand the construct and not generate
either of these commits. Possibly the hacked-up revisions I inserted
are enough different from the regular kind to confuse it.
>> I also found numerous places where we'd been sloppy about placing tags.
> I wonder if we should consider fixing some or all of these things on
> the master CVS repository. I wouldn't be too eager to inject those
> fake .0 commits for fear of breakage, but moving tags to where they
> ought to have been all along seems like it might be a good thing to do
> independent of git.
Yeah, that's something I was wondering too. Applying these fixes to the
master repository would also reduce the number of things we have to
remember to do during the final conversion. OTOH, there's that risk of
breaking something.
regards, tom lane