Re: git: uh-oh - Mailing list pgsql-hackers
From | Magnus Hagander |
---|---|
Subject | Re: git: uh-oh |
Date | |
Msg-id | AANLkTimN6gWDx4tOqq8ABiVeUeCrrBujVCCdr80Gqh-S@mail.gmail.com Whole thread Raw |
In response to | Re: git: uh-oh (Michael Haggerty <mhagger@alum.mit.edu>) |
Responses |
Re: git: uh-oh
|
List | pgsql-hackers |
On Sat, Aug 21, 2010 at 08:15, Michael Haggerty <mhagger@alum.mit.edu> wrote: > Max Bowsher wrote: >> On 20/08/10 19:07, Magnus Hagander wrote: >>> On Fri, Aug 20, 2010 at 19:56, Max Bowsher <maxb@f2s.com> wrote: >>>> On 20/08/10 18:43, Magnus Hagander wrote: >>>>> On Fri, Aug 20, 2010 at 19:41, Max Bowsher <maxb@f2s.com> wrote: >>>>>> On 20/08/10 18:30, Magnus Hagander wrote: >>>>>>> On Fri, Aug 20, 2010 at 19:28, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>>>>>> Max Bowsher <maxb@f2s.com> writes: >>>>>>>>> The history that cvs2svn is aiming to represent here is this: >>>>>>>>> 1) At the time of creation of the REL8_4_STABLE branch, plperl_opmask.pl >>>>>>>>> did *not* exist. >>>>>>>>> 2) Later, it was added to trunk. >>>>>>>>> 3) Then, someone retroactively added the branch tag to the file, marking >>>>>>>>> it as included in the REL8_4_STABLE branch. [This corresponds to the git >>>>>>>>> changeset that Robert is questioning] >>>>>>>> Uh, no. We have never "retroactively added" anything to any branch. >>>>>>>> I don't know enough about the innards of CVS to know what its internal >>>>>>>> representation of this sort of thing is, but all that actually happened >>>>>>>> here was a "cvs add" and a "cvs commit" in REL8_4_STABLE long after the >>>>>>>> branch occurred. We would like the git history to look like that too. >>>>>>> Yeah. >>>>>>> >>>>>>> In fact, is the only thing that's wrong here the commit message? >>>>>>> Because it's probably trivial to just patch that away.. Hmm, but i >>>>>>> guess we'd like to hav ethe actual commit message and not just another >>>>>>> fixed one.. >>>>>> There is no "actual commit message" - the entire changeset is >>>>>> synthesized by cvs2git to represent the addition of a branch tag to the >>>>>> file - i.e. the logical equivalent of a "cvs tag -b", which has no >>>>>> commit message. >>>>> 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"? >>>> It wouldn't be accurate to do so, because the synthetic commit is not >>>> copying the entire change, only registering the addition of (in this >>>> case) one file which happens to be part of the changeset. Please note >>>> that there is a changeset on the branch immediately following the >>>> synthetic one under discussion which contains the 'real' commit message >>>> used when committing to the branch. >>> Hmm. Good point. >>> >>> I wonder if we should try to locate these places and fix them with git >>> filter-branch or rebase -i after the fact, with history rewriting. >>> >>> There seem to be 57 of them. >> >> It sounds cumbersome. >> >> Michael Haggerty might be better placed than me to assess whether >> eliding them within cvs2git is practically achievable. > > I think this would be nontrivial. <snip> > Moreover, this is a pretty specialized request that would be useless to > people who are not so disciplined about their repository as you seem to be. Yeah, I think we're unusually disciplined with our repository - that's one reason the change won't be that drastic wrt how things are done :-) > It seems like you already have a way to find these events in the git > repository after conversion, so I think it would be more practical to > use git-filter-branch to remove the unwanted commits *after* the conversion. Not sure that we do have an automated way, but I agree that this is probably going to be easier to do with git-filter-branch. If we need to do it at all. Tom's latest lookover indicates that he thinks it may be good the way it is, and we need some more detailed checks. I know Robert has said he wants to dedicate some time to doing such checks this week, and I'll see if I can find some time for that as well. If anybody else would like to help us dig through mainly the backbranches - with focus on branchpoints and taggings - to look for any kind of "weird stuff" (meaning anything that's not a straight commit), then please do so and let us know your results! -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
pgsql-hackers by date: