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.
