Max Bowsher <m...@f2s.com> writes:
> On 07/09/10 18:16, Tom Lane wrote:
>> Hmm, I see. This depends on the fact that git commits reference
>> filesystem states and not deltas, correct? So it does actually make
>> sense to just delete that commit from the history. I was concerned
>> that it'd invalidate later commits, but I guess it doesn't.
> It wouldn't - except for the fact that cvs2git batches such manufactured
> commits such that there is no guarantee that a single manufactured
> commit pertains only to files in the commit immediately afterwards.
Hmm ... so the consequence of that would be that (in this example) it.po
would show up as being part of the REL8_4_STABLE file set as of that
commit, rather than as of the later commit where it really got added.
That's kind of annoying, but it is not a showstopper I think. Recall
that the goals we set for this conversion in the first place were
(1) duplicate the file set as of any back release tag and (2) duplicate
the CVS log history as nearly as practical. We know we have met (1),
because Magnus explicitly tested that. IMO we have met (2) adequately
as well, with or without any fix for the manufactured-commit issue.
On reflection it might be better to leave well enough alone, though.
Anybody looking at the "real commit" in future might be confused by
the fact that it added a seemingly unrelated file. It would be less
confusing to have an obviously made-up commit adding some files,
probably.
A compromise might be to excise only those manufactured commits that
added files directly related to the following real commit. I haven't
looked to see how many there are that grouped unrelated files.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
