Re: Plans for git

Bakul Shah wrote in
 <AACA0895-9C16-4AE1-8790-CC9B1ED51A97_at_iitbombay.org>:
 |On Sep 18, 2020, at 11:21 PM, Warner Losh <imp_at_bsdimp.com> wrote:
 |> 
 |> These are the main ones. The three down sides are lack of $FreeBSD$ \
 |> support
 |> and tags in general.
 |
 |Can a git hook be used for this?

I use a git pre-commit hook to fake-update SCCS IDs for my web
site (

  if git rev-parse --verify HEAD >/dev/null 2>&1
  then
          against=HEAD
  else
          # Initial commit: diff against an empty tree object
          against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
  fi

  DATE=`date -u +%Y-%m-%dT%H:%M:%S`

  git diff-index --name-status --cached $against -- |
  grep -E '^[AM][[:space:]]+.+\.(html|js|css)' |
  cut -f2 |
  while read f; do
          if grep -F '_at_(#)' ${f} > /dev/null 2>&1; then
                  < ${f} perl -e '
                          while (<STDIN>) {
                                  unless ($_ =~ /_at_\(#\)/) {
                                          print;
                                          next;
                                  }
                                  chomp;
                                  $_ =~ /^((?:.*?)_at_\(\#\)(?:.+?) \d+\.)
                                          (\d+)
                                          ( .+\+0000)(.*)$/x;
                                  print $1, int($2) + 1,
                                          " '"${DATE}"'+0000", $4, "\n";
                          }
                  ' > ${f}.new
                  mv ${f}.new ${f}
                  git add ${f}
          fi
  done
  exit 0

and do not look to seriously) but of course this is a crux that
can only work well with a single developer / changeset branch tip,
as soon as you join in other branches you are in trouble unless
you cherry-pick everything onto a main line by policy.

 |> Yes. I've started doing a series of short videos explaining the change, \
 |> why
 |> we are doing it and what to do in the new world order. I'll be doing blog
 |> entries as well as turning that material into handbook entries. I \
 |> have some
 |> of those written.
 |> 
 |> Does this help?
 |
 |It would be useful to describe the development model (e.g. how major/minor
 |features get added etc), how to maintain multiple local branches (e.g.
 |release branch or -current) or working on more than one feature at \
 |a time etc.
 |
 |Do you plan to move to something like the github review process?
 |
 |When is the cutover supposed to occur?
 |
 |The cgit-beta.FreeBSD.org and github trees are not identical the last
 |time I looked (mainly in meta data). Any reason for not keeping them
 |identical? I switched from the github tree to the cgit-beta tree.
 |
 |FWIW, I have used sccs, rcs, cvs, subversion, mercurial, git & a few more.
 |I have used git exclusively for the last few years. I felt more comfortable
 |with git once I understood the on-disk storage model. The Pro Git book is
 |pretty good for that & more.

That gc (--aggressive --prune=all) thing is a tremendous plus for
git in my opinion.  I track all BSDs and the Linux kernel via git
and in bare repositories without checked out work dir, and it is
as compact as can be.  Whereas with Mercurial and Subversion (as
i used to know them a decade(+) ago) you had all that mess lying
around.

--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)