Re: src: continued use of Subversion for getting updates

[Graham Perrin]

Warner, thanks for the clarification.

Apologies for me taking the (rough draft/work in progress) documentation 
too literally.


On 23/12/2020 07:01, Warner Losh wrote:
… This has been a big job with way more moving parts than I'd ever 
thought possible. We've attended to most of them, and are fixing the 
stragglers as the team becomes aware of them. …


From the outside looking in: for so complex a project, progress seems 
remarkably smooth. Thanks to all involved.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: src: continued use of Subversion for getting updates

[Warner Losh]

On Wed, Dec 23, 2020, 1:48 AM Graham Perrin  wrote:

> Warner, thanks for the clarification.
>
> Apologies for me taking the (rough draft/work in progress) documentation
> too literally.
>

I'm all ears on ways to make the docs better

Warner

On 23/12/2020 07:01, Warner Losh wrote:
> > … This has been a big job with way more moving parts than I'd ever
> > thought possible. We've attended to most of them, and are fixing the
> > stragglers as the team becomes aware of them. …
>
>  From the outside looking in: for so complex a project, progress seems
> remarkably smooth. Thanks to all involved.
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: src: continued use of Subversion for getting updates

[Johan Hendriks]

On 23/12/2020 09:49, Warner Losh wrote:

On Wed, Dec 23, 2020, 1:48 AM Graham Perrin  wrote:


Warner, thanks for the clarification.

Apologies for me taking the (rough draft/work in progress) documentation
too literally.


I'm all ears on ways to make the docs better

Warner

On 23/12/2020 07:01, Warner Losh wrote:

… This has been a big job with way more moving parts than I'd ever
thought possible. We've attended to most of them, and are fixing the
stragglers as the team becomes aware of them. …

  From the outside looking in: for so complex a project, progress seems
remarkably smooth. Thanks to all involved.



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

First of all a big thank you for all your time and effort you and all 
the other people put in this tremendous task.


For me and i think a lot of regular users that do not push just pull, a 
simple page with the exact commands to track stable or head is very 
appreciated.


Like svnlite update /usr/src replace with git pull  and so on and an 
example for head, stable or release will push most people in the right 
direction.


I for one (i did not search that hard) can not find these steps very 
easily.


regards





___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Marek Zarychta]

W dniu 17.12.2020 o 01:46, Warner Losh pisze:
> Greetings,
> 
> The FreeBSD project will be moving it's source repo from subversion to git
> starting this this weekend. The docs repo was moved 2 weeks ago. The ports
> repo will move at the end of March, 2021 due to timing issues.
> 
> The short version is that we're switching the version control we're using.
> This switch will preserve much of the current FreeBSD development workflow.
> After the switch, the subversion repo will become almost read-only. All
> future work will be done in git, however as a transition aide we'll be
> replaying the MFCs to stable/11, stable/12 and the related releng branches
> for the life of those branches.
> 
> For more detailed information, please see
> https://github.com/bsdimp/freebsd-git-docs/ for the current documentation.
> 
> Please see https://wiki.freebsd.org/git for the latest detailed schedule
> (please note that this schedule is subject to change).
> 
> Warner
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

Will the project utilize gitatributes(5) to support ident as $Id:$ in
git repository?

In file header, we have now only $FreeBSD$ since svn tags disappeared
after the transition. Adding ident tags to certain files which are
updated by mergemaster(8) or etcupdated(8) would be appreciated.

Best regards,
-- 
Marek Zarychta
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: src: continued use of Subversion for getting updates

[Thomas Mueller]

> stable/11 as well as the releng branches for as long as the project has
> them under support. I wrote the code to replay commits into subversion for
> the convenience of our users on those branches. The 12.x releases will be
> built out of Subversion to preserve $FreeBSD$ expansion and other obscure
> subversion details that may matter or be disruptive to people using those
> branches.
 
> Current has moved entirely to git. New commits have started up again.
> Stable/11 and stable/12 are there as well, but there are a couple of last
> minute snags that are being sorted out so it will be an additional day,
> maybe two before those start. FreeBSD 13 will be entirely from git and will
> be branching late winter or early spring if all goes well. Other issues
> with git are being sorted our as they arise.
 
> For those using github, migration instructions will be in place once the
> changes there are complete. What I've written up is enough for the seasoned
> traveler, but lacks a few details that were hosted worked out in the past
> days I've not had time to fold in. We hope to have that all sorted out by
> Christmas.
 
> This has been a big job with way more moving parts than I'd ever thought
> possible. We've attended to most of them, and are fixing the stragglers as
> the team becomes aware of them.
 
> Warner

Congratulations on moving doc and current src trees to git.

I made the transition and ran "rm -Rf" on doc svn tree, src svn tree and also 
src12 tree.

I am abandoning releng-12 because of problems with internet connectivity, which 
even appeared in NomadBSD live USB based on FreeBSD 12.1.

Will stable/11 and stable/12 be available by both git and svn?  This is just 
idle curiosity in my case.

Tom

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: src: continued use of Subversion for getting updates

[Jeffrey Bouquet]

On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks  
wrote:

> 
> On 23/12/2020 09:49, Warner Losh wrote:
> > On Wed, Dec 23, 2020, 1:48 AM Graham Perrin  wrote:
> >
> >> Warner, thanks for the clarification.
> >>
> >> Apologies for me taking the (rough draft/work in progress) documentation
> >> too literally.
> >>
> > I'm all ears on ways to make the docs better
> >
> > Warner
> >
> > On 23/12/2020 07:01, Warner Losh wrote:
> >>> … This has been a big job with way more moving parts than I'd ever
> >>> thought possible. We've attended to most of them, and are fixing the
> >>> stragglers as the team becomes aware of them. …
> >>   From the outside looking in: for so complex a project, progress seems
> >> remarkably smooth. Thanks to all involved.
> >>
> >>
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> >
> First of all a big thank you for all your time and effort you and all 
> the other people put in this tremendous task.
> 
> For me and i think a lot of regular users that do not push just pull, a 
> simple page with the exact commands to track stable or head is very 
> appreciated.
> 
> Like svnlite update /usr/src replace with git pull  and so on and an 
> example for head, stable or release will push most people in the right 
> direction.
> 
> I for one (i did not search that hard) can not find these steps very 
> easily.
> 
> regards
> 
> 
> 
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Seconded.
This and the other ongoing today subversion > git threads IMHO need four or 
more 
new paragraphs in /usr/src/UPDATING and eventually /usr/ports/UPDATING so
persons who for lack of time won't ever get upto speed entirely on how to run 
git
can have  a copy-paste template command to run for most use cases, here,
equivalents of

ports
cd /usr/ports/Mk
svn up .
 
and 

src

cd /usr/src/sbin
svn up
[[... denotes by default the branch checked out, addl parameters probably ]
as well as 'swn switch' equivalents
and another-destination equivalents

for example

git clone https://git.FreeBSD.org/src.git -b stable/12 /usr/freebsd-src

appeared to start checking out 12-stable to the latter directory
but I had to halt it for lack of time and being new. 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Kurt Jaeger]

Hi!

> It's also hard to collect ALL the keys of the devs at any point in
> time to decide if that key is authorized to sign a commit in the
> repo...

We do have most of the keys in docs/share/pgpkeys/ plus history.

> Like if a dev starts in 2021, any commits made by that
> dev prior to 2021 should not be "valid"..  Then there's also the
> issue that people's keys change over time, and now you need to know
> what time period each key was valid for, otherwise a compromised key
> could be used to insert malicious changes into your/the tree...

If we manage keys plus their history in the doc repo, this seems
to be solved.

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git tools for building in base?

[Ulrich Spörlein]

On Fri, 2020-12-18 at 14:02:08 +0100, Miroslav Lachman wrote:

On 25/11/2020 06:54, Thomas Mueller wrote:


NetBSD users face a similar problem with their upcoming switch from cvs to hg 
(Mercurial).


Do anybody have a link to some documents stating why FreeBSD chose Git
and why NetBSD chose Mercurial? I am using both tools at $WORK, I am
just curious what leads to these decisions.


No documents, but git was simply more mature back when I started this 
effort a decade ago and it is and was more popular (with all the added 
side effects that has). I was (and am) only an occasional user of hg and 
even git, so familiarity wasn't quite an argument back then, though the 
git storage model is much nicer for the required history re-writing.


In the early days I pushed to googlecode and bitbucket as well, you can 
see that here 
https://svnweb.freebsd.org/base/user/uqs/git_conv/git_conv?r1=251786&r2=251785&pathrev=251786


Not visible are the trials I ran with git-svn and hg, both of which only 
could handle the single head branch, but not all the other branching 
craziness that was and is going on in the repo.


I don't fully recall, but I think that the hg conversion was slow and 
the disk space needed was quite a bit more than git.


So in summary, I guess it can be summed up as:
- there was no svn-all-fast-export for hg back then
- even bitbucket switched from hg to git
- history rewriting is easier in git, see e.g. this file for the stuff 
  that's required to make the cvs2svn things a bit nicer: 
  https://github.com/freebsd/git_conv/blob/master/fix_bogus_tags.sh


Granted, now that the heavy lifting is done, one could probably do a 
git2hg transition, as the history is now pretty sane and should be 
compatible to the hg model.


But lack of anyone (to my knowledge?) providing a hg copy of FreeBSD all 
these years tells me that there's simply no demand for it.


There's https://wiki.freebsd.org/LocalMercurial from 2008 but that skips 
converting from r1. Of interest is also 
https://www.mercurial-scm.org/pipermail/mercurial/2019-May/051240.html 
which looks like the size issues with hg haven't been fixed yet. It also 
seems that http://hg-beta.freebsd.org/base/branches has the 
user-servicable branches only, but not vendor. So it's not usable as a 
source-of-truth for the project.


I would encourage everyone *not* to base their hg work off of SVN but 
take the soon-official git repo instead. If you wanted to do this right 
off of SVN, here's just one of dozens of quirks: 
https://github.com/freebsd/git_conv/blob/master/revisions.md


You've been warned ;]

Cheers
Uli
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Michael Grimm]

Hi,

Warner Losh  wrote:

> The FreeBSD project will be moving it's source repo from subversion to git
> starting this this weekend. 

First of all I'd like to thank all those involved in this for their efforts.

Following https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md 
form your other mail I was able to migrate from svn to git without running into 
any issues.

Right now I am learning how to use git the way I sed svn before. I am just 
following 12-STABLE in order to build world and kernel. I am not developing, 
neither am I committing.

I wonder how one would switch from a currently used branch (OLD) to another 
branch (NEW).

With svn I used:
svn switch svn://svn.freebsd.org/base/stable/NEW /usr/src

For git I found:
git branch -m stable/OLD stable/NEW
or
git branch -M stable/OLD stable/NEW

git-branch(1):
   With a -m or -M option,  will be renamed to . If
had a corresponding reflog, it is renamed to match
   , and a reflog entry is created to remember the branch
   renaming. If  exists, -M must be used to force the rename to
   happen.

I don't understand that text completely, because I don't know what a reflog is, 
yet ;-)

Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to 
stable/13 in the near future?

Thanks and regards,
Michael

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: src: continued use of Subversion for getting updates

[Steffen Nurpmeso]

Jeffrey Bouquet wrote in
 :
 |On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks  wrote:
 |> On 23/12/2020 09:49, Warner Losh wrote:
 |>> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin  \
 |>> wrote:
 ...
 |> First of all a big thank you for all your time and effort you and all 
 |> the other people put in this tremendous task.

Yes, it is great to have FreeBSD as a stable git repository now,
not only due to "gc --aggressive --prune=all" and the possibility
to use (pseudo) bare repositories without checkouts, but also
because of this.  Downloaded it today (from fresh), currently
doing the mentioned command, but it may be it does not reduce that
much :)

I really dislike that vendor imports have been tagged.  Because
there is only one tag namespace you cannot avoid getting all this
cruft.  I mean, it is too late now, but one could have used
per-vendor import branches and step them via "git rm -rf '*' &&
tar -xf newball && git add . && git commit bla" or whatever, and
then join them in.  It does not matter for those who have all the
repository, but you decided to loose one of the strengts of git,
selective tracking.  Also i think it causes updates to require
more network traffic, i see this with the repos i have at
repo.or.cz, the one with few heads/tags is minimal, the other
requires hundreds of kilobytes just for the check that happens
many times a day.  All these references have to be compared each
and every time.  I think.  On the other hand, a few years back
i accidentally "heard" a discussion about improving the network
protocol and that "head" reference matching, iirc, so it may
change in the future.

Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Renato Botelho]

On 23/12/20 11:32, Michael Grimm wrote:

Hi,

Warner Losh  wrote:


The FreeBSD project will be moving it's source repo from subversion to git
starting this this weekend.


First of all I'd like to thank all those involved in this for their efforts.

Following https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md 
form your other mail I was able to migrate from svn to git without running into 
any issues.

Right now I am learning how to use git the way I sed svn before. I am just 
following 12-STABLE in order to build world and kernel. I am not developing, 
neither am I committing.

I wonder how one would switch from a currently used branch (OLD) to another 
branch (NEW).

With svn I used:
svn switch svn://svn.freebsd.org/base/stable/NEW /usr/src

For git I found:
git branch -m stable/OLD stable/NEW
or
git branch -M stable/OLD stable/NEW

git-branch(1):
With a -m or -M option,  will  be renamed to . If
 had a corresponding reflog, it is renamed to  match
, and  a reflog entry is created to remember the branch
renaming. If   exists, -M must be used to force the rename to
happen.

I don't understand that text completely, because I don't know what a reflog is, 
yet ;-)

Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to 
stable/13 in the near future?


git-branch is used to create/delete/rename branches.  If you want to 
switch to a different already existing branch, as svn switch does, you 
should look at git-checkout.


It can be a bit expensive due to the size of src repository so if you do 
work on multiple branches too often you can improve it using git-worktree.


--
Renato Botelho
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Lev Serebryakov]

On 23.12.2020 17:32, Michael Grimm wrote:


git-branch(1):
With a -m or -M option,  will  be renamed to . If

==

 had a corresponding reflog, it is renamed to  match
, and  a reflog entry is created to remember the branch
renaming. If   exists, -M must be used to force the rename to
happen.

I don't understand that text completely, because I don't know what a reflog is, 
yet ;-)

Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to 
stable/13 in the near future?

You should not use any options if you want to switch your working copy to new 
branch. `-m` and `-M` *renames* branch!

--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Lev Serebryakov]

On 23.12.2020 18:04, Lev Serebryakov wrote:

On 23.12.2020 17:32, Michael Grimm wrote:


git-branch(1):
    With a -m or -M option,  will    be renamed to . 
If

==

     had a corresponding reflog, it is renamed to    match
    , and    a reflog entry is created to remember the branch
    renaming. If     exists,    -M must    be used    to force 
the rename to
    happen.

I don't understand that text completely, because I don't know what a reflog is, 
yet ;-)

Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to 
stable/13 in the near future?

You should not use any options if you want to switch your working copy to new 
branch. `-m` and `-M` *renames* branch!

 I'm idiot today, it is `git checkout ` of course.

--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD-CURRENT src: pulling without pushing: example Git commands to clone then update

[Graham Perrin]

On 23/12/2020 10:13, Johan Hendriks wrote:

… For me and i think a lot of regular users that do not push just 
pull, a simple page with the exact commands to track stable or head is 
very appreciated.


Like svnlite update /usr/src replace with git pull  and so on and 
an example for head, stable or release will push most people in the 
right direction. … 



-CURRENT


Guided mostly by the documentation:

1. with /usr/src as an empty working directory
2. the command below, just once

git clone -o freebsd -b main --depth 1 https://git.freebsd.org/src.git 
freebsd-current


(I do not foresee me committing, and I had no immediate interest in 
history.)


Subsequent updates
--

portsnap auto && git -C /usr/src/freebsd-current pull --ff-only && echo 
"FreeBSD-CURRENT Git revision: " && git -C /usr/src/freebsd-current 
rev-list --count HEAD


– take what you like from that. Not intended to be an exact command for 
other users, but it suits me.


Context: 

HTH
Graham

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: src: continued use of Subversion for getting updates

[Chris]

On 2020-12-22 23:01, Warner Losh wrote:

On Tue, Dec 22, 2020, 11:47 PM Graham Perrin  wrote:


On 23/12/2020 00:10, Paul Mather wrote:
> … continue to get src updates via Subversion. …

As far as I can tell:

* for stable/12 alone



stable/11 as well as the releng branches for as long as the project has
them under support. I wrote the code to replay commits into subversion for
the convenience of our users on those branches. The 12.x releases will be
built out of Subversion to preserve $FreeBSD$ expansion and other obscure
subversion details that may matter or be disruptive to people using those
branches.

Current has moved entirely to git. New commits have started up again.
Stable/11 and stable/12 are there as well, but there are a couple of last
minute snags that are being sorted out so it will be an additional day,
maybe two before those start. FreeBSD 13 will be entirely from git and will
be branching late winter or early spring if all goes well. Other issues
with git are being sorted our as they arise.

For those using github, migration instructions will be in place once the
changes there are complete. What I've written up is enough for the seasoned
traveler, but lacks a few details that were hosted worked out in the past
days I've not had time to fold in. We hope to have that all sorted out by
Christmas.

This has been a big job with way more moving parts than I'd ever thought
possible. We've attended to most of them, and are fixing the stragglers as
the team becomes aware of them.

On a slight aside;
Any plans to incorporate GitLab into any of this?

--Chris


Warner

* for a limited period.


<
https://github.com/bsdimp/freebsd-git-docs/blob/4833066feda51cc3a907cf7bff1c4344b3edd5c6/big-picture.md#L103
>

In context:


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD: GitLab

[Graham Perrin]

On 23/12/2020 15:36, Chris wrote:

… Any plans to incorporate GitLab into any of this? 



 ▶ 
big-picture.md is probably the best starting point.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git tools for building in base?

[Miroslav Lachman]

On 23/12/2020 13:54, Ulrich Spörlein wrote:

On Fri, 2020-12-18 at 14:02:08 +0100, Miroslav Lachman wrote:

On 25/11/2020 06:54, Thomas Mueller wrote:

NetBSD users face a similar problem with their upcoming switch from 
cvs to hg (Mercurial).


Do anybody have a link to some documents stating why FreeBSD chose Git
and why NetBSD chose Mercurial? I am using both tools at $WORK, I am
just curious what leads to these decisions.


No documents, but git was simply more mature back when I started this 
effort a decade ago and it is and was more popular (with all the added 
side effects that has). I was (and am) only an occasional user of hg and 
even git, so familiarity wasn't quite an argument back then, though the 
git storage model is much nicer for the required history re-writing.


In the early days I pushed to googlecode and bitbucket as well, you can 
see that here 
https://svnweb.freebsd.org/base/user/uqs/git_conv/git_conv?r1=251786&r2=251785&pathrev=251786 



Not visible are the trials I ran with git-svn and hg, both of which only 
could handle the single head branch, but not all the other branching 
craziness that was and is going on in the repo.


I don't fully recall, but I think that the hg conversion was slow and 
the disk space needed was quite a bit more than git.


So in summary, I guess it can be summed up as:
- there was no svn-all-fast-export for hg back then
- even bitbucket switched from hg to git
- history rewriting is easier in git, see e.g. this file for the stuff   
that's required to make the cvs2svn things a bit nicer:   
https://github.com/freebsd/git_conv/blob/master/fix_bogus_tags.sh


Granted, now that the heavy lifting is done, one could probably do a 
git2hg transition, as the history is now pretty sane and should be 
compatible to the hg model.


But lack of anyone (to my knowledge?) providing a hg copy of FreeBSD all 
these years tells me that there's simply no demand for it.


There's https://wiki.freebsd.org/LocalMercurial from 2008 but that skips 
converting from r1. Of interest is also 
https://www.mercurial-scm.org/pipermail/mercurial/2019-May/051240.html 
which looks like the size issues with hg haven't been fixed yet. It also 
seems that http://hg-beta.freebsd.org/base/branches has the 
user-servicable branches only, but not vendor. So it's not usable as a 
source-of-truth for the project.


I would encourage everyone *not* to base their hg work off of SVN but 
take the soon-official git repo instead. If you wanted to do this right 
off of SVN, here's just one of dozens of quirks: 
https://github.com/freebsd/git_conv/blob/master/revisions.md


You've been warned ;]


Thank you so much. This is very valuable post. I didn't expect such 
detailed information.
As I am using hg for my local projects and git for public / $WORK maybe 
one day I will try to setup hg repo from official git repo - just for 
"the fun".
I am completely fine with svn, or git or anything else was / is / will 
be the official source even if there is no tool in base. Installing 
package is so simple in these days.


Thank you again!

Kind regards
Miroslav Lachman
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Steffen Nurpmeso]

John-Mark Gurney wrote in
 <20201223023242.gg31...@funkthat.com>:
 |Steffen Nurpmeso wrote this message on Fri, Dec 18, 2020 at 19:28 +0100:
 |> Brooks Davis wrote in
 |>  <20201218175241.ga72...@spindle.one-eyed-alien.net>:
 |>|On Thu, Dec 17, 2020 at 05:53:20PM -0800, Thomas Mueller wrote:
 ...
 |>|Signed commits have no practicl effect on users of a repo.
 |> 
 |> Well you can verify integrity of a repository regardless of how it
 |> was distributed, this is why it is done, right.
 ...

 |TL;DR I don't see any reason for devs to sign commits.
 |
 |I could see use for RE (or another entity) to occasionally (weekly?)
 |sign the repo (say COPYRIGHT or UPDATING), and it would be nice for
 |them to sign all the tags used for releases, but having every dev
 |would both make the dev's life difficult...

Sure.  Signing at least releases makes a lot of sense.
Your idea of periodically sealing the tree is interesting, because
it can even be automatized (dependent on the key).
stable/ patch pumpkins could sign at least the last commit they
cherry pick back to stable, aren't ehy in distress already :)

 |It's also hard to collect ALL the keys of the devs at any point in
 |time to decide if that key is authorized to sign a commit in the
 |repo...  Like if a dev starts in 2021, any commits made by that
 |dev prior to 2021 should not be "valid"..  Then there's also the
 |issue that people's keys change over time, and now you need to know
 |what time period each key was valid for, otherwise a compromised key
 |could be used to insert malicious changes into your/the tree...
 |
 |Then there's also the point that the repo is (looks like it) using
 |SHA-1 hashes, which are effectively broken, so depending upon them
 |to validate the tree is questionable anyways.

git uses the hardened SHA-1 for sure, which is, as far as i know,
at least safe against the known attack.
I .. have not tracked this, but i think upgrading to SHA-256 is
possible, once this will become standard.  Just even more
metadata, then.  I have not looked into this, still in progress.

Imho: devs should show "muchos cojones".
I am sure you appreciate a daunting post, i think it is ok to
quote this post from openssl-...@openssl.org ("Re: Attribution of
pull requests in git"):

  Theodore Ts'o wrote in
   <20140426145907.ga1...@thunk.org>:
   |On Sat, Apr 26, 2014 at 11:29:39AM +0100, Ben Laurie wrote:
   |> I just noticed that if I merge a pull request, then both author and
   |> committer are set to whoever made the pull request.
   |
   |Are you using github, or git using its standard pull request workflow?
   |
   |In the standard git workflow, the author and committer is set to the
   |person who merged the pull.  The person who requested the pull request
   |is recorded in the signed git tag.  For example, I recently signed a
   |git tag:
   |
   |% git tag -s ext4_for_linus_stable
   |
   | 

Wonderful.

   |% git push ssh://gitol...@ra.kernel.org/pub/scm/linux/kernel/git/tytso/e\
   |xt4.git tags/ext4_for_linus_stable
   |
   |   

Ah yes.
Correct enough for German public law television at its best!

   |% git request-pull origin git://git.kernel.org/pub/scm/linux/kernel/git/\
   |tytso/ext4.git tags/ext4_for_linus_stable > /tmp/pull
   |
   |(I have aliases and shell scripts for most of this, but I've expanded
   |all of this out for clarity.)
   |
   |Then I e-mailed the following to Linus, and then after he merged the
   |pull request, when I pulled down his tree, tou can see the following:
   |
   |% git show --pretty=fuller --show-signature  origin
   |commit 9ac03675010a69507c0a9d832d6a722e07d35cc6
   |merged tag 'ext4_for_linus_stable'
   |gpg: Signature made Sun 20 Apr 2014 10:23:16 PM EDT using RSA key ID \
   |C11804F0
   |gpg: Good signature from "Theodore Ts'o "
   |gpg: aka "Theodore Ts'o "
   |gpg: aka "Theodore Ts'o "
   |Merge: a798c10 0a04b24
   |Author: Linus Torvalds 
   |AuthorDate: Sun Apr 20 20:43:47 2014 -0700
   |Commit: Linus Torvalds 
   |CommitDate: Sun Apr 20 20:43:47 2014 -0700

   ...

   |The advantage of doing this way is that git will detach the signature
   |from the tag, and save it in the merge conflict, so years later, the
   |cryptographic accountability chain is preserved in the git tree.
   |
   |Cheers,

Hope that helps.
I personally sign releases and (at least the head of a bunch of)
commits to [master] and [stable] (it is a git alias which does
it).  Looser that i am i have a setup-privacy script on an
encrypted partition that loads keys, unfortunately not even root
can kill -SOMESIG to cause all ssh-agents etc to unload and clear
the loaded keys, therefore i hook acpi and do something like

   if command -v ssh-add >/dev/null 2>&1; then
  for a in /tmp/ssh-*/agent.*; do
 [ -e "$a" ] || continue
 act '( SSH_AUTH_SOCK="$a" ssh-add -D ) /dev/null 2>&1 &'
  done
   fi

Luckily i do not yet use per-user private temporary directories.
All in all it is

Re: FreeBSD: GitLab

[Chris]

On 2020-12-23 07:41, Graham Perrin wrote:

On 23/12/2020 15:36, Chris wrote:


… Any plans to incorporate GitLab into any of this?



 ▶ 
big-picture.md is

probably the best starting point.

Brilliant! :)

I mainly asked because GitLab seems to offer a richer toolset IMHO.

Thanks, Graham!

--Chris



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD: GitLab

[Warner Losh]

On Wed, Dec 23, 2020 at 9:44 AM Chris  wrote:

> On 2020-12-23 07:41, Graham Perrin wrote:
> > On 23/12/2020 15:36, Chris wrote:
> >
> >> … Any plans to incorporate GitLab into any of this?
> >
> >
> >  ▶
> > big-picture.md is
> > probably the best starting point.
> Brilliant! :)
>
> I mainly asked because GitLab seems to offer a richer toolset IMHO.
>

The project is publishing many places, and will use features of the places
it publishes as it refines the future workflow. The different
mirroring/hosting services offer different features and it's not yet clear
how we can best utilize them or if even one size fits all.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Warner Losh]

On Wed, Dec 23, 2020 at 3:35 AM Marek Zarychta <
zarych...@plan-b.pwste.edu.pl> wrote:

> W dniu 17.12.2020 o 01:46, Warner Losh pisze:
> > Greetings,
> >
> > The FreeBSD project will be moving it's source repo from subversion to
> git
> > starting this this weekend. The docs repo was moved 2 weeks ago. The
> ports
> > repo will move at the end of March, 2021 due to timing issues.
> >
> > The short version is that we're switching the version control we're
> using.
> > This switch will preserve much of the current FreeBSD development
> workflow.
> > After the switch, the subversion repo will become almost read-only. All
> > future work will be done in git, however as a transition aide we'll be
> > replaying the MFCs to stable/11, stable/12 and the related releng
> branches
> > for the life of those branches.
> >
> > For more detailed information, please see
> > https://github.com/bsdimp/freebsd-git-docs/ for the current
> documentation.
> >
> > Please see https://wiki.freebsd.org/git for the latest detailed schedule
> > (please note that this schedule is subject to change).
> >
> > Warner
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
> >
>
> Will the project utilize gitatributes(5) to support ident as $Id:$ in
> git repository?
>

There are no plans. $Id$, as implemented in git, records the wrong
information. Rather than a commit hash, it's the blob object hash which can
be hard to puzzle out. It would cause way more confusion were we to use it.
Plus, when I did experiments with it, it was slow and difficult to work
with. Given these issues, we've opted to not use it. Plus there's no
documented way to change $Id$ to $FreeBSD$ in an easy way, and the
filtering stuff looked extra fragile.


> In file header, we have now only $FreeBSD$ since svn tags disappeared
> after the transition. Adding ident tags to certain files which are
> updated by mergemaster(8) or etcupdated(8) would be appreciated.
>

mergemaster and etcupdate can cope without them.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD: GitLab

[Chris]

On 2020-12-23 08:52, Warner Losh wrote:

On Wed, Dec 23, 2020 at 9:44 AM Chris  wrote:


On 2020-12-23 07:41, Graham Perrin wrote:
> On 23/12/2020 15:36, Chris wrote:
>
>> … Any plans to incorporate GitLab into any of this?
>
>
>  ▶
> big-picture.md is
> probably the best starting point.
Brilliant! :)

I mainly asked because GitLab seems to offer a richer toolset IMHO.



The project is publishing many places, and will use features of the places
it publishes as it refines the future workflow. The different
mirroring/hosting services offer different features and it's not yet clear
how we can best utilize them or if even one size fits all.

Sure. I got that following the notes from the search listed above.
Just to be clear; I was *not* suggesting anyone was making any *wrong*
choices here. Just a humble inquiry. :-)

Thanks for taking the time to respond, Warner.


Warner


--Chris
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Brooks Davis]

On Tue, Dec 22, 2020 at 06:32:43PM -0800, John-Mark Gurney wrote:
> Steffen Nurpmeso wrote this message on Fri, Dec 18, 2020 at 19:28 +0100:
> > Brooks Davis wrote in
> >  <20201218175241.ga72...@spindle.one-eyed-alien.net>:
> >  |On Thu, Dec 17, 2020 at 05:53:20PM -0800, Thomas Mueller wrote:
> >  |>>> I hope we don't have to start signing all commits.  saltstack/salt has
> >  |>>> that policy, and it's extremely annoying.
> >  |> 
> >  |>> Have to? Not currently. As with all process changes, there will be
> >  |>> community discussion around the different points.
> >  |> 
> >  |>> Warner
> >  |> 
> >  |> I hope not!
> >  |> 
> >  |> Signatures, at least in email messages, are just an annoyance as \
> >  |> I see them.
> >  |> 
> >  |> I don't even know how do sign an email message or make use of a 
> > signatur\
> >  |> e in a message I receive.
> >  |> 
> >  |> I have never made a commit to a repository, so would not be familiar \
> >  |> with signatures there; imagine it would be a barrier.
> >  |
> >  |Signed commits have no practicl effect on users of a repo.
> > 
> > Well you can verify integrity of a repository regardless of how it
> > was distributed, this is why it is done, right.
> > 
> >   #?0$ git log --oneline --show-signature -1 v14.9.20.ar
> >   16a21755 (...)
> >   gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
> >   gpg:using RSA key DF082F6AEEC8C2FF
> >   gpg: Good signature from "Steffen Nurpmeso "
> >   Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12
> > 
> >   #?0$ git tag -v v14.9.20.ar; echo $?
> >   object 16a21755fd1fade2b15fdb78a592f12169c3453f
> >   type commit
> >   tag v14.9.20.ar
> >   tagger Steffen Nurpmeso  1607816624 +0100
> >   
> >   Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12
> >   gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
> >   gpg:using RSA key DF082F6AEEC8C2FF
> >   gpg: Good signature from "Steffen Nurpmeso "
> >   0
> 
> TL;DR I don't see any reason for devs to sign commits.
> 
> I could see use for RE (or another entity) to occasionally (weekly?)
> sign the repo (say COPYRIGHT or UPDATING), and it would be nice for
> them to sign all the tags used for releases, but having every dev
> would both make the dev's life difficult...

I think RE signing releases makes some sense.  Routine signing of commits
eliminates lots of potentially useful workflows if you also want linear
history.  In particular it makes it impractical to implement any form of
commit-automatically-after-CI type workflows because rebase looses the
signature.

-- Brooks


signature.asc
Description: PGP signature

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Warner Losh]

On Wed, Dec 23, 2020 at 7:32 AM Michael Grimm  wrote:

> Hi,
>
> Warner Losh  wrote:
>
> > The FreeBSD project will be moving it's source repo from subversion to
> git
> > starting this this weekend.
>
> First of all I'd like to thank all those involved in this for their
> efforts.
>
> Following
> https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md form
> your other mail I was able to migrate from svn to git without running into
> any issues.
>
> Right now I am learning how to use git the way I sed svn before. I am just
> following 12-STABLE in order to build world and kernel. I am not
> developing, neither am I committing.
>
> I wonder how one would switch from a currently used branch (OLD) to
> another branch (NEW).
>
> With svn I used:
> svn switch svn://svn.freebsd.org/base/stable/NEW /usr/src
>
> For git I found:
> git branch -m stable/OLD stable/NEW
> or
> git branch -M stable/OLD stable/NEW
>
> git-branch(1):
>With a -m or -M option,  will be renamed to .
> If
> had a corresponding reflog, it is renamed to match
>, and a reflog entry is created to remember the branch
>renaming. If  exists, -M must be used to force the
> rename to
>happen.
>
> I don't understand that text completely, because I don't know what a
> reflog is, yet ;-)
>
> Thus: Should I use "-m" or "-M" in my scenario when switching from
> stable/12 to stable/13 in the near future?
>

I think the answer is a simple "git checkout NEW". This will replace the
current tree at branch OLD with the contents of branch NEW.

git branch -m is different and changes what the branch means. If you did
what you suggested then you'd be renaming the OLD brnach to NEW, which
isn't what I think you're asking about.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Michael Grimm]

Warner Losh  wrote:
> On Wed, Dec 23, 2020 at 7:32 AM Michael Grimm  wrote:

>> With svn I used:
>>svn switch svn://svn.freebsd.org/base/stable/NEW /usr/src
>> 
>> For git I found:
>>git branch -m stable/OLD stable/NEW
>>or
>>git branch -M stable/OLD stable/NEW
> 
> I think the answer is a simple "git checkout NEW". This will replace the
> current tree at branch OLD with the contents of branch NEW.


Thanks to all of you pointing me away from renaming a branch instead of simply 
checking out the branch of interest.


> git branch -m is different and changes what the branch means. If you did
> what you suggested then you'd be renaming the OLD brnach to NEW, which
> isn't what I think you're asking about.

No, I will not apply anything before having it understood. In this case I 
looked into git-branch(1) because I believed this the command to be. Haven't 
found git-checkout(1) :-( Sorry for the noise.

Now, stable/13 may come, I am ready to switch ;-)

Thanks again and regards,
Michael
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Michael Grimm]

Renato Botelho  wrote:

> If you want to switch to a different already existing branch, as svn switch 
> does, you should look at git-checkout.
> 
> It can be a bit expensive due to the size of src repository so if you do work 
> on multiple branches too often you can improve it using git-worktree.

If I understand git-worktree(1) correctly I will most probably not need it, 
because I will only follow one single branch stable/12, and soon stable/13. Or 
do I miss something important?

Thanks and regards,
Michael
 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Renato Botelho]

On 23/12/20 15:20, Michael Grimm wrote:

Renato Botelho  wrote:


If you want to switch to a different already existing branch, as svn switch 
does, you should look at git-checkout.

It can be a bit expensive due to the size of src repository so if you do work 
on multiple branches too often you can improve it using git-worktree.


If I understand git-worktree(1) correctly I will most probably not need it, 
because I will only follow one single branch stable/12, and soon stable/13. Or 
do I miss something important?


You are correct.  You can clone stable/12 now and when it's time just do

# git checkout stable/13

--
Renato Botelho
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[John Kennedy]

On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote:
> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
> > The FreeBSD project will be moving it's source repo from subversion to git
> > starting this this weekend. The docs repo was moved 2 weeks ago. The ports
> > repo will move at the end of March, 2021 due to timing issues. ...
> 
>   I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when clean),
> but that's just a trivial issue with my source tree being marked -dirty
> when it isn't, and that would have been part of r368709 anyway.  All my
> other git nits have been my own (refs/notes and origin name).

  Warner/others, up to r368820, we had log entries that looked like this:

commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a
Author: Li-Wen Hsu 
Date:   Sun Dec 20 02:59:44 2020 +

Mark the repository as being converted to Git.

This is the last Subversion commit to src.

Sponsored by:   The FreeBSD Foundation

Notes:
svn path=/head/; revision=368820

  Now, our git logs look like this:

commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc
Author: Ed Maste 
Date:   Tue Dec 22 23:31:15 2020 -0500

newvers.sh: fix sense of git dirty check

Previously we reported -dirty for an unmodified tree, and no -dirty 
if
there were changes.

PR: 252028
Reported by:John Kennedy

  (Specifically, no Notes: with revision= value)

  For the kernel I compiled today, the uname output dumps out:

FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ...

  Last kernel was (-dirty since fixed):

FreeBSD 13.0-CURRENT #244 r368820+3cc0c0d66a06-c255241(main)-dirty: ...

  So, the r368820-value isn't being updated for it to find anymore.  The middle
value corresponds to the git commit and does have value (878d53410f75 is your
"UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the repository
as being converted to Git" r368820 commit).

  How do you plan on referencing distinct patches now?  If the revision number
is going away, we might as well yank it out since it'll be r368820 forever.

  For my git projects, I often use a "git tag -a" (annotated) commit at useful
milestones, but I'm not sure what you're using it for:

[git describe]
vendor/bc/3.2.3-255270-g3f3cc995a35a

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Ulrich Spörlein]

On Wed, 2020-12-23 at 12:19:47 -0800, John Kennedy wrote:

On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote:

On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
> The FreeBSD project will be moving it's source repo from subversion to git
> starting this this weekend. The docs repo was moved 2 weeks ago. The ports
> repo will move at the end of March, 2021 due to timing issues. ...

  I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when clean),
but that's just a trivial issue with my source tree being marked -dirty
when it isn't, and that would have been part of r368709 anyway.  All my
other git nits have been my own (refs/notes and origin name).


 Warner/others, up to r368820, we had log entries that looked like this:

commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a
Author: Li-Wen Hsu 
Date:   Sun Dec 20 02:59:44 2020 +

Mark the repository as being converted to Git.

This is the last Subversion commit to src.

Sponsored by:   The FreeBSD Foundation

Notes:
svn path=/head/; revision=368820

 Now, our git logs look like this:

commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc
Author: Ed Maste 
Date:   Tue Dec 22 23:31:15 2020 -0500

newvers.sh: fix sense of git dirty check

Previously we reported -dirty for an unmodified tree, and no -dirty 
if
there were changes.

PR: 252028
Reported by:John Kennedy

 (Specifically, no Notes: with revision= value)


Yes, these notes are merely pointers to the SVN revisions. Without SVN, 
we will of course not get any new notes.



 For the kernel I compiled today, the uname output dumps out:

FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ...

 Last kernel was (-dirty since fixed):

FreeBSD 13.0-CURRENT #244 r368820+3cc0c0d66a06-c255241(main)-dirty: ...

 So, the r368820-value isn't being updated for it to find anymore.  The middle
value corresponds to the git commit and does have value (878d53410f75 is your
"UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the repository
as being converted to Git" r368820 commit).


Yeah, that's a bug in newvers.sh, thanks for pointing that out. It finds 
"some" note in the last 10k revs and then uses that, instead of properly 
falling back to counting from HEAD, which would result in -c255126 or 
something around that.


We'll fix it ...

Cheers
Uli
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Rainer Hurling]

Am 23.12.20 um 21:55 schrieb Ulrich Spörlein:
> On Wed, 2020-12-23 at 12:19:47 -0800, John Kennedy wrote:
>> On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote:
>>> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
>>> > The FreeBSD project will be moving it's source repo from subversion
>>> to git
>>> > starting this this weekend. The docs repo was moved 2 weeks ago.
>>> The ports
>>> > repo will move at the end of March, 2021 due to timing issues. ...
>>>
>>>   I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when
>>> clean),
>>> but that's just a trivial issue with my source tree being marked -dirty
>>> when it isn't, and that would have been part of r368709 anyway.  All my
>>> other git nits have been my own (refs/notes and origin name).
>>
>>  Warner/others, up to r368820, we had log entries that looked like this:
>>
>> commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a
>> Author: Li-Wen Hsu 
>> Date:   Sun Dec 20 02:59:44 2020 +
>> 
>>     Mark the repository as being converted to Git.
>> 
>>     This is the last Subversion commit to src.
>> 
>>     Sponsored by:   The FreeBSD Foundation
>> 
>> Notes:
>>     svn path=/head/; revision=368820
>>
>>  Now, our git logs look like this:
>>
>> commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc
>> Author: Ed Maste 
>> Date:   Tue Dec 22 23:31:15 2020 -0500
>> 
>>     newvers.sh: fix sense of git dirty check
>> 
>>     Previously we reported -dirty for an unmodified tree, and no
>> -dirty if
>>     there were changes.
>> 
>>     PR: 252028
>>     Reported by:    John Kennedy
>>
>>  (Specifically, no Notes: with revision= value)
> 
> Yes, these notes are merely pointers to the SVN revisions. Without SVN,
> we will of course not get any new notes.
> 
>>  For the kernel I compiled today, the uname output dumps out:
>>
>> FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ...
>>
>>  Last kernel was (-dirty since fixed):
>>
>> FreeBSD 13.0-CURRENT #244
>> r368820+3cc0c0d66a06-c255241(main)-dirty: ...
>>
>>  So, the r368820-value isn't being updated for it to find anymore. 
>> The middle
>> value corresponds to the git commit and does have value (878d53410f75
>> is your
>> "UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the
>> repository
>> as being converted to Git" r368820 commit).
> 
> Yeah, that's a bug in newvers.sh, thanks for pointing that out. It finds
> "some" note in the last 10k revs and then uses that, instead of properly
> falling back to counting from HEAD, which would result in -c255126 or
> something around that.

I built HEAD this afternoon and got 'FreeBSD 13.0-CURRENT #0
92be2847e84-c255272(main): Wed Dec 23 17:39:31 CET 2020'. The counting
seems more correct here?

> We'll fix it ...
> 
> Cheers
> Uli
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

referencing one commit in another for git

[Rick Macklem]

Hi,

So I just did my first git commit. Pretty scary, but it looks ok.

Now, how do I reference one commit in another related
commit's log?

By the long winded hash or ??

I'm not sure if I should ask here or on the git mailing list,
but I figured this isn't a technical git question...

Thanks for any help with this, rick
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: referencing one commit in another for git

[Alan Somers]

On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem  wrote:

> Hi,
>
> So I just did my first git commit. Pretty scary, but it looks ok.
>
> Now, how do I reference one commit in another related
> commit's log?
>
> By the long winded hash or ??
>
> I'm not sure if I should ask here or on the git mailing list,
> but I figured this isn't a technical git question...
>
> Thanks for any help with this, rick
>

Yeah, you should use the full hash.  For temporary references, like during
a code review, you can use the first "several" digits of the hash.   For a
project of FreeBSD's size, "several" is probably 11-13.  But in permanent
contexts, like commit logs, you should use the full hash.  When somebody
views the commit on a platform like Github, Github will automatically turn
it into a hyperlink, and display only the first "several" digits.
-Alan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: referencing one commit in another for git

[Warner Losh]

On Wed, Dec 23, 2020, 3:21 PM Alan Somers  wrote:

> On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem  wrote:
>
> > Hi,
> >
> > So I just did my first git commit. Pretty scary, but it looks ok.
> >
> > Now, how do I reference one commit in another related
> > commit's log?
> >
> > By the long winded hash or ??
> >
> > I'm not sure if I should ask here or on the git mailing list,
> > but I figured this isn't a technical git question...
> >
> > Thanks for any help with this, rick
> >
>
> Yeah, you should use the full hash.  For temporary references, like during
> a code review, you can use the first "several" digits of the hash.   For a
> project of FreeBSD's size, "several" is probably 11-13.  But in permanent
> contexts, like commit logs, you should use the full hash.  When somebody
> views the commit on a platform like Github, Github will automatically turn
> it into a hyperlink, and display only the first "several" digits.
>


For MFCs we are recommending the first 11. I think this will likely suffice
and matches the git client behavior.

Warner

-Alan
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: referencing one commit in another for git

[Jan Beich]

Warner Losh  writes:

> On Wed, Dec 23, 2020, 3:21 PM Alan Somers  wrote:
>
>> On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem  wrote:
>>
>> > Hi,
>> >
>> > So I just did my first git commit. Pretty scary, but it looks ok.
>> >
>> > Now, how do I reference one commit in another related
>> > commit's log?
>> >
>> > By the long winded hash or ??
>> >
>> > I'm not sure if I should ask here or on the git mailing list,
>> > but I figured this isn't a technical git question...
>> >
>> > Thanks for any help with this, rick
>> >
>>
>> Yeah, you should use the full hash.  For temporary references, like during
>> a code review, you can use the first "several" digits of the hash.   For a
>> project of FreeBSD's size, "several" is probably 11-13.  But in permanent
>> contexts, like commit logs, you should use the full hash.  When somebody
>> views the commit on a platform like Github, Github will automatically turn
>> it into a hyperlink, and display only the first "several" digits.
>>
>
>
> For MFCs we are recommending the first 11. I think this will likely suffice
> and matches the git client behavior.

Mercurial defaults to 12 digit abbreviation. Git abbreviates linux,
freebsd-legacy, freebsd-ports repos on GitHub to 12 digit.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git tools for building in base?

[Charlie Li]

Ulrich Spörlein wrote:
> I don't fully recall, but I think that the hg conversion was slow and
> the disk space needed was quite a bit more than git.
> 
One of Mercurial's biggest design principles is immutable history (with
history rewriting disabled by default), so increased disk space compared
to git is reasonable.
> So in summary, I guess it can be summed up as:
> - there was no svn-all-fast-export for hg back then
> - even bitbucket switched from hg to git
Bitbucket dropping Mercurial support was more a business decision,
although more ancillary tooling for git existing and developer appetite
certainly played factors there.
> - history rewriting is easier in git, see e.g. this file for the stuff  
> that's required to make the cvs2svn things a bit nicer:  
> https://github.com/freebsd/git_conv/blob/master/fix_bogus_tags.sh
> 
> Granted, now that the heavy lifting is done, one could probably do a
> git2hg transition, as the history is now pretty sane and should be
> compatible to the hg model.
> 
Mercurial's branches are more similar to subversion than git. The hg
analogue to git's branches are bookmarks, for which even they are
optional since hg has its heads concept.
> But lack of anyone (to my knowledge?) providing a hg copy of FreeBSD all
> these years tells me that there's simply no demand for it.
> 
I use hg-beta for ports. Also used it for src up until git-beta came
online. Not sure what I will do once ports is converted to git, however.

My mercurial use stems from two sources: committers' need to preserve
copy/move history (though this will probably go away with git) and
horrendous performance with the ports tree in git. Horrendous as in, for
example, takes about five minutes just to run git-status(1) on a ports
tree stored on a hard drive with UFS (-uno doesn't help) whilst locking
up the entire system I/O for the duration. The I/O lockups have since
subsided but as of six months ago the slow enumeration has persisted.
For some reason, mercurial is far more efficient in this regard.

-- 
Charlie Li
…nope, still don't have an exit line.

(This email address is for mailing list use; replace local-part with
vishwin for off-list communication if possible)



OpenPGP_signature
Description: OpenPGP digital signature

Re: referencing one commit in another for git

[Warner Losh]

On Wed, Dec 23, 2020 at 6:22 PM Jan Beich  wrote:

> Warner Losh  writes:
>
> > On Wed, Dec 23, 2020, 3:21 PM Alan Somers  wrote:
> >
> >> On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem 
> wrote:
> >>
> >> > Hi,
> >> >
> >> > So I just did my first git commit. Pretty scary, but it looks ok.
> >> >
> >> > Now, how do I reference one commit in another related
> >> > commit's log?
> >> >
> >> > By the long winded hash or ??
> >> >
> >> > I'm not sure if I should ask here or on the git mailing list,
> >> > but I figured this isn't a technical git question...
> >> >
> >> > Thanks for any help with this, rick
> >> >
> >>
> >> Yeah, you should use the full hash.  For temporary references, like
> during
> >> a code review, you can use the first "several" digits of the hash.
>  For a
> >> project of FreeBSD's size, "several" is probably 11-13.  But in
> permanent
> >> contexts, like commit logs, you should use the full hash.  When somebody
> >> views the commit on a platform like Github, Github will automatically
> turn
> >> it into a hyperlink, and display only the first "several" digits.
> >>
> >
> >
> > For MFCs we are recommending the first 11. I think this will likely
> suffice
> > and matches the git client behavior.
>
> Mercurial defaults to 12 digit abbreviation. Git abbreviates linux,
> freebsd-legacy, freebsd-ports repos on GitHub to 12 digit.
>

I've updated to 12. That sounds like a good number of digits...Thanks.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD: GitLab

[grarpamp]

>> I mainly asked because GitLab seems to offer a richer toolset IMHO.
>
> The project is publishing many places, and will use features of the places
> it publishes as it refines the future workflow. The different
> mirroring/hosting services offer different features and it's not yet clear
> how we can best utilize them or if even one size fits all.

As with the move to git, readonly mirrors is fine thing.
Yet more general attempt to open up bug work issue trackers flow
read-write services etc for some things beyond say central freebsd.org,
can massively raise overhead, needlessly partition knowledge
base, raise peoples search and participation time by 2^n,
complexity alienate new dev and user influx, be harder for
donors to big picture, etc...

'A: hey here's my bug report on site H'
'L: H redundant, already filed over on service X'
'Z: but we're working it on J, see the mail list at U'
'W: well J blocks devs using tor with cloudflare so we can't read or
contribute there'
'X: did you see telegram message G you can add it to site R's wiki'
'Q: nope not bothering to set up yet another account for that'
'I: ddg search gave results to U, but V which was not indexed that I
found on F had my answer'
'E: i clicked your link but N already 404 expired sold out or shutdown'
'N: , sorry for your loss'
'M: but the forum C said github clone A was it'
'O: they wanted my phone picture id and utility bill for an account, fuck that'
'B: i tried to integrate sites G and Y in my scripts to do miracle T
but they kept changing API's and it required plugins which were were
broken in pkg all month.'

Also consider before canonizing/depending elements to
third party services, especially ones without good export for
backup, mirror, and local use... people think corp services
will last forever, history shows they don't.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"