On Dec 25, 2019, "Eric S. Raymond" wrote:
> Reposurgeon has a reparent command. If you have determined that a
> branch is detached or has an incorrect attachment point, patching the
> metadata of the root node to fix that is very easy.
Thanks, I see how that can enable a missed branch to be con
Joseph Myers :
> On Wed, 25 Dec 2019, Andreas Schwab wrote:
>
> > On Dez 25 2019, Joseph Myers wrote:
> >
> > > Timezones for any email address can be specified in gcc.map for any
> > > authors wishing to have an appropriate timezone used for their commits.
> >
> > But that should not be used f
Segher Boessenkool :
> The goal is not to pretend we never used SVN.
One of *my* goals is that the illusion of git back to the beginning of
time should be as consistent as possible.
> The goal is to have a Git repo that is as useful as possible for us.
Exactly. I've already written about minimi
Andreas Schwab :
> Definitely not. I have never authored or committed any revision in the
> -0800 time zone.
That's easily fixed by adding a timezone entry to your author-map
entry - CET, is it? That will prevent reposurgeon from making any
attempt to deduce your timezone.
It would be interesti
On Wed, Dec 25, 2019 at 01:50:14PM -0500, Eric S. Raymond wrote:
> Segher Boessenkool :
> > Or doing what everyone else does: put an empty .gitignore file in
> > otherwise empty directories.
>
> That is an ugly kludge that I will have no part of whatsoever.
>
> Conversion artifacts like this
It'
Segher Boessenkool :
> Or doing what everyone else does: put an empty .gitignore file in
> otherwise empty directories.
That is an ugly kludge that I will have no part of whatsoever.
Conversion artifacts like this are sources of cognitive friction and
confusion that take developers' attention awa
On Wed, Dec 25, 2019 at 03:36:38PM +, Joseph Myers wrote:
> On Wed, 25 Dec 2019, Andreas Schwab wrote:
>
> > On Dez 25 2019, Joseph Myers wrote:
> >
> > > Timezones for any email address can be specified in gcc.map for any
> > > authors wishing to have an appropriate timezone used for their
On Wed, 25 Dec 2019, Andreas Schwab wrote:
> On Dez 25 2019, Joseph Myers wrote:
>
> > Timezones for any email address can be specified in gcc.map for any
> > authors wishing to have an appropriate timezone used for their commits.
>
> But that should not be used for unrelated authors.
It's not
On Dez 25 2019, Joseph Myers wrote:
> Timezones for any email address can be specified in gcc.map for any
> authors wishing to have an appropriate timezone used for their commits.
But that should not be used for unrelated authors.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fing
On Wed, 25 Dec 2019, Andreas Schwab wrote:
> > Not sure we need that info, but reposurgeon is more correct here.
>
> Definitely not. I have never authored or committed any revision in the
> -0800 time zone.
If reposurgeon is defaulting to the local time where the conversion is
run, there's a s
On Dez 25 2019, Roman Zhuykov wrote:
> 1) In gcc-pretty timezone info is lost in both author/commiter date
> (keeping UTC time correct, certainly).
Since svn doesn't record time zones you cannot lose them, only fabricate
them.
> Not sure we need that info, but reposurgeon is more correct here.
On Wed, 25 Dec 2019, Segher Boessenkool wrote:
> On Wed, Dec 25, 2019 at 07:07:47AM -0500, Eric S. Raymond wrote:
> > For each of these exceptional commits a converter to Git has a choice
> > of dropping the commit, turning it into some sort of annotated tag, or
> > leaving it in place as a zero-o
On Wed, 25 Dec 2019, Segher Boessenkool wrote:
> git-svn did not miss any branches. Finding branches is not done by
> git-svn at all, for this. These branches were skipped because they
> have nothing to do with GCC, have no history in common (they are not
> descendants of revision 1). They can
On Wed, Dec 25, 2019 at 07:07:47AM -0500, Eric S. Raymond wrote:
> For each of these exceptional commits a converter to Git has a choice
> of dropping the commit, turning it into some sort of annotated tag, or
> leaving it in place as a zero-op commit (anomalous but not forbidden
> in the git model
Joseph Myers :
> These are all cases covered by the request-for-enhancement issue for
> adding Co-Authored-by: when the ChangeLog header names multiple authors,
> as the corresponding de facto git idiom for that case.
I apologize, but I am growing doubtful I can deliver that. Even if I
can, it
Hi!
On Wed, Dec 25, 2019 at 05:11:31AM -0300, Alexandre Oliva wrote:
> On Dec 16, 2019, Jeff Law wrote:
> > Yet Joseph just indicated today Maxim's conversion is missing some
> > branches. While I don't consider any of the missed branches important,
> > others might. More importantly, it raise
Alexandre Oliva :
> I know very little about reposurgeon, but I'm concerned that, should we
> make the conversion with it, and later identify e.g. missed branches, we
> might be unable to make such an incremental recovery. Can anyone
> alleviate my concerns and let me know we could indeed make suc
On Wed, 25 Dec 2019, Roman Zhuykov wrote:
> 2) Some thoughts about script for summarizing commit log messages:
> 2a) Why r143753 and r150680 not have "re PR..." summary instead of "[multiple
> changes]" ?
> 2b) On the contrary r155892 have to mention two PRs, even "[multiple changes]"
> is better
First of all thanks to everyone who spent time making the conversion
better and better. Here is my 2c, I have studied a little my colleagues
trunk history in Maxim's gcc-pretty vs gcc-reposurgeon-5b.
1) In gcc-pretty timezone info is lost in both author/commiter date
(keeping UTC time correct,
On Dec 16, 2019, Jeff Law wrote:
> Yet Joseph just indicated today Maxim's conversion is missing some
> branches. While I don't consider any of the missed branches important,
> others might. More importantly, it raises the issue of what other
> branches might be missing and what validation wor
20 matches
Mail list logo
