Commit messages and the move to git

[Richard Earnshaw (lists)]

On 18/11/2019 17:55, Nicholas Krause wrote:
> 
> On 11/18/19 12:46 PM, Richard Earnshaw (lists) wrote:
>> On 18/11/2019 17:25, Nicholas Krause wrote:
>>>
>>> On 11/18/19 12:23 PM, Nicholas Krause wrote:
>>>>
>>>> On 11/18/19 12:20 PM, Nicholas Krause wrote:
>>>>>
>>>>> On 11/18/19 12:11 PM, Segher Boessenkool wrote:
>>>>>> Hi Richard,
>>>>>>
>>>>>> On Mon, Nov 18, 2019 at 04:48:03PM +0000, Richard Earnshaw (lists) 
>>>>>> wrote:
>>>>>>> On 18/11/2019 15:55, Segher Boessenkool wrote:
>>>>>>>> That immediately shows some of the shortcomings of this 
>>>>>>>> approach: the
>>>>>>>> subject line is much too long, but more importantly, it doesn't 
>>>>>>>> make
>>>>>>>> much sense: it is not what the patch does, it is the description 
>>>>>>>> of a
>>>>>>>> bug that is related in some way to this patch.  It is not 
>>>>>>>> uncommon for
>>>>>>>> a commit to not fix the problem mentioned in the bug report (if 
>>>>>>>> it *is*
>>>>>>>> a problem!), or not fix it completely.
>>>>>>>>
>>>>>>>> Then again, changing all such subject lines to read "patch" 
>>>>>>>> could also
>>>>>>>> already be considered an improvement.
>>>>>>> Well the real question is whether such a summary is worse than the
>>>>>>> current situation of just printing the author in the wrong field.  I
>>>>>>> personally don't think it is.
>>>>>> I think that non-obviously-wrong-but-still-wrong info is not 
>>>>>> something
>>>>>> we should introduce.  And, I think this will happen a *lot*.
>>>>>>
>>>>>> Maybe you can just put in artificial subjects like "Patch related to
>>>>>> PR12345" or the like?  That is correct, displays a lot better, and is
>>>>>> at least as useful (imo).
>>>>>
>>>>> I don't see but other projects  mention PRS or Bugzilla ids but
>>>>>
>>>>> more common in my experience is just mentioned the commit
>>>>>
>>>>> ids. For example this fixes commit id x introducing PR x. Commit
>>>>>
>>>>> ids are know good so having them linked in commit messages
>>>>>
>>>>> is much easier to track then PRs, I can just use git log -p commit id.
>>>>>
>>>>>>
>>>>>>> There are about 560 commits where the code highlights that the data
>>>>>>> might be suspect (usually a category mismatch).
>>>>>> What about commits that mention multiple PRs?  What do you do for 
>>>>>> those?
>>>>>> (Are there as many of those as I think, anyway?)Â  With normally 
>>>>>> very short
>>>>>> subjects you could put all of them in there :-)
>>>>>
>>>>> See my above but for this you would just state the main issue(s) in 
>>>>> the commit
>>>>>
>>>>> message and in the body what commits/PRs are being handled.
>>>>>
>>>>> Not sure if that works for everyone but that's normally the best 
>>>>> way in my
>>>>>
>>>>> experience,
>>>>>
>>>>> Nick
>>>>>
>>>>> Sorry but cced the others as this was a misclick.
>>>
>>> One of the emails CCed was boucing so I just fixed that as well.
>>>
>>
>> [strange, I'm not seeing bounces].
>>
>>> Nick
>>>
>>>>>
>>>>>>
>>>>>> Segher
>>
>> SVN commit Ids can't be fixed here.  Not least because we don't know 
>> the SHA code for the git commit at this point.  For legacy commit id's 
>> we'll just need to keep the existing SVN repo available, so that folks 
>> can look at it with, say, viewcvs.
>>
>> R.
> 
> Richard,
> 
> That's a problem but for legacy commits keeping the old cvs around would 
> be good. Other projects had the problem of moving to git but not keeping 
> that data around and causing issues.  The other thing I would point out 
> in this discussion is to start figuring out history policies on branches 
> e.t.c for merges,
> 
> cherry picking and bisect. Merges are the obvious one but bisect and 
> cherry picking will depend on
> 
> the history choices over time as how useful they may become.
> 
> I've yet to see history choices discussed whether it be straight linear, 
> branches and merge e.t.c.
> 
> but thought I will mention it again as I did at Cauldron briefly as 
> this  will not be part of the merge
> 
> but important for future planning git migration or project strategies 
> and should be discussed
> 

Well a lot of that is a property of the conversion tool.  git svn does a 
relatively poor job of anything other than straight history (I believe 
it just ignores the non-linear information.  I don't believe any tool 
can recreate information for cherry-picking unless it's recorded in the 
SVN meta-data.  Eric would be better placed to comment here.

My own observation is that when the SVN commits have merge meta-data, 
reposurgeon will pick this up and create links across to the relevant 
branches.  It does, however seem to create far more links than a 
traditional git merge would do, especially when a sequence of commits 
are referenced.  I don't know if that's essentially unfixable, or if 
it's something Eric intends to work on; but I've seen some cases where 
there are dozens of links back to a simple sequence of svn commits and 
where, I suspect, a single link back to the most recent of that sequence 
would be all that's really wanted.

> or added to the wiki for git migration.
> 
> Cheers,
> 
> Nick
> 

R.