On Sat, Dec 21, 2019 at 11:11 AM Allan Sandfeld Jensen
wrote:
> On Monday, 16 December 2019 14:51:38 CET J Decker wrote:
> > Here's the gist of what I would propose...
> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> >
> > In C, there are two operators . and -> used to access
On Thu, 26 Dec 2019, Joseph Myers wrote:
> > It appears that .gitignore has been added in r1 by reposurgeon and then
> > deleted at r130805. In SVN repository .gitignore was added in r195087.
> > I speculate that addition of .gitignore at r1 is expected, but it's
> > deletion at r130805 is hi
Vincent Lefevre :
> What matters is that the date is correct. I don't think the timezone
> matters (that's why SVN doesn't store timezone information, I assume),
> possibly except for the committer himself (?). For instance,
Subversion doesn't store timezone because all commits are consifered
to h
On 2019-12-26 16:30:15 -0500, Eric S. Raymond wrote:
> Vincent Lefevre :
> > > Here's why you want to get timezones right: there are going to be times
> > > when the order of commits is significant information for a developer's
> > > understanding of what happened. But without a timezone you only
On Thu, 26 Dec 2019, Jakub Jelinek wrote:
> Is there some easy way (e.g. file in the conversion scripts) to correct
> spelling and other mistakes in the commit authors?
I've added author fixups to bugdb.py, so you can add any number of fixes
(e.g. based on authors that look suspicious in "git sh
Toon Moene :
> On 12/26/19 10:30 PM, Eric S. Raymond wrote:
>
> > Me, I don't undertstand why version-control systems designed for distributed
> > use don't ignore timezones entirely and display all times in UTC - relative
> > time is surely more imoortant than the commit time's relationship to so
On 12/26/19 10:30 PM, Eric S. Raymond wrote:
Me, I don't undertstand why version-control systems designed for distributed
use don't ignore timezones entirely and display all times in UTC - relative
time is surely more imoortant than the commit time's relationship to solar
noon wherever the keybo
Vincent Lefevre :
> > Here's why you want to get timezones right: there are going to be times
> > when the order of commits is significant information for a developer's
> > understanding of what happened. But without a timezone you only know
> > the actual time of a commit to 24-hour resoltion.
>
Alexandre Oliva :
> I don't see that it does (help). Incremental conversion of a missed
> branch should include the very same parent links that the conversion of
> the entire repo would, just linking to the proper commits in the adopted
> conversion. git-svn can do that incrementally, after the f
On 2019-12-25 14:33:45 -0500, Eric S. Raymond wrote:
> 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 usef
On December 26, 2019 5:58:22 PM GMT+01:00, Joseph Myers
wrote:
>On Thu, 26 Dec 2019, Maxim Kuvyrkov wrote:
>
>> Reposurgeon creates merge entries on trunk when changes from a branch
>
>> are merged into trunk. This brings entire development history from
>the
>> branch to trunk, which is both go
On Thu, 26 Dec 2019, Alexandre Oliva wrote:
> I don't see that it does (help). Incremental conversion of a missed
> branch should include the very same parent links that the conversion of
> the entire repo would, just linking to the proper commits in the adopted
> conversion. git-svn can do that
On Dec 26, 2019, "Eric S. Raymond" wrote:
> Alexandre Oliva :
>> 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
Alexandre Oliva :
> 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
On Thu, 26 Dec 2019, Jakub Jelinek wrote:
> On Thu, Dec 26, 2019 at 04:58:22PM +, Joseph Myers wrote:
> > If we don't want merge commits on git master for the cases where people
> > put merge properties on trunk in the past, we can use a reposurgeon
> > "unmerge" command in gcc.lift to stop
On Thu, Dec 26, 2019 at 04:58:22PM +, Joseph Myers wrote:
> If we don't want merge commits on git master for the cases where people
> put merge properties on trunk in the past, we can use a reposurgeon
> "unmerge" command in gcc.lift to stop the few commits in question from
> being merge com
On Thu, 26 Dec 2019, Maxim Kuvyrkov wrote:
> Reposurgeon creates merge entries on trunk when changes from a branch
> are merged into trunk. This brings entire development history from the
> branch to trunk, which is both good and bad. The good part is that we
> get more visibility into how th
> On Dec 26, 2019, at 2:16 PM, Jakub Jelinek wrote:
>
> On Thu, Dec 26, 2019 at 11:04:29AM +, Joseph Myers wrote:
> Is there some easy way (e.g. file in the conversion scripts) to correct
> spelling and other mistakes in the commit authors?
> E.g. there are misspelled surnames, etc. (e.g. l
On Thu, 26 Dec 2019, Jakub Jelinek wrote:
> Is there some easy way (e.g. file in the conversion scripts) to correct
> spelling and other mistakes in the commit authors?
These can be corrected via reposurgeon commands in gcc.lift (see the
existing "// attribution =A set
jwakely@gmail.com" co
On Thu, Dec 26, 2019 at 11:04:29AM +, Joseph Myers wrote:
Is there some easy way (e.g. file in the conversion scripts) to correct
spelling and other mistakes in the commit authors?
E.g. there are misspelled surnames, etc. (e.g. looking at my name, I see
Jakub Jakub Jelinek (1):
Jakub Jeilnek (1
On Thu, 26 Dec 2019, Alexandre Oliva wrote:
> Could make it a requirement that at least the commits associated with
> head branches and published tags compare equal in both conversions, or
> that differences are known, understood and accepted, before we switch
> over to either one? Going over all
21 matches
Mail list logo
