[resolved] Re: Question on (my) workflow migration svn -> git

David Wolfskill david at catwhisker.org
Wed Oct 7 13:30:24 UTC 2020

On Thu, Sep 24, 2020 at 01:17:15PM -0700, David Wolfskill wrote:
> The migration (of my workflow) from cvs to svn was more "cosmetic"
> than anything else -- the data store changed and the commands
> changed, but the underlying thought processes behind what I was
> doing stayed pretty much the same.
> I have no idea if that will be the case for svn -> git, so I'm
> putting this out for comments and, perhaps, some useful advice from
> folks who are more familiar with git than I am.
> ...

After a fair bit of advice, opinions, and experimentation, I believe I
may have arrived at a working approach -- and if I haven't got quite
that far, I believe I am close enough to stop spamming the list after
this note. :-}

Caveat: The approaches discussed here are almost certainly NOT what you
want if you are trying to set things up to commit back to the FreeBSD
repo.  This is for facilitating tracking FreeBSD.

So, in case anyone else is (somewhat) similarly situated:

* The fundamental concept I needed was the notion of a git "mirror"
  repo.  I created the one I am using via:
	 git clone --mirror https://cgit-beta.freebsd.org/src.git

* A "mirror" git repo is also a "bare" git repo, in case that term may
  be more familiar.  (A mirror has at least one addiitonal attribute --
  I'm not claiming that "mirror" and "bare" are equivalent terms;
  rather, "mirror" implies "bare".)  See the "--mirror" and "--bare"
  discussions from "git help clone" for details.

* The above "mirror" repo is separate from any "working tree" -- which,
  for my use case, is desired (a requirement, really).  This may be
  confusing to some folks (e.g., who may be accustomed to the notion of
  cloning a "normal" git repo, checking out a branch, hacking on code,
  committing, & pushing).  That type of activity is not what the mirror
  repo is for.

* The mirror repo is updated periodically (e.g., nightly) via
  "git fetch --all"
  (run on the machine where the repo resides).  Sample output from such
  an update:

Fetching origin
From https://cgit-beta.freebsd.org/src
   05fcd86b60c0..59d5ed3afc99  main               -> main
   f794cc249acc..13d175068ee9  releng/12.2        -> releng/12.2
   3a305f9fbe30..37087976b6c2  stable/12          -> stable/12
 + 4f5d6f8229a9...0af8f7422420 refs/notes/commits -> refs/notes/commits  (forced update)

* To then get a "working tree" (based on the mirror repo), there are a
  couple of options that I have found.  (There may well be more.
  Two is sufficient for this discussion.)  One may create a "worktree"
  for each branch to be tracked or one may create (what I will call)
  a "normal" git repo/working tree.  Each has tradeoffs:

  * The "worktree" approach.

     This must be done by one who is able to update the mirror repo.
     It is created via (e.g.):
     cd ${mirror_repo} && git worktree add /usr/src ${branch}

     That done, output of "git status" should look fairly normal --
     until the mirror gets updated.  Once that happens, "git status"
     will generally show that any worktree now has some number of
     "Changes to be committed".  To actually get the worktree to reflect
     the state of the mirror repo at that point:
     cd /usr/src && git reset --hard

     which ... may be a little counter-intuitive, but works (for reasons
     that begin to make sense once one delves into the current
     implementation -- so I make no promises as to how well-supported
     this model is).

     On advantage of the worktree is that is uses less disk space than a
     "normal" git repo/working tree (as in place of the latter's .git/
     hierarchy, it merely has a file that references a subdirectory of
     ${mirror_repo}/worktrees).  (Actual numbers near the end of this

  * The '"normal" git repo/working tree' approach.

    This is done via a "normal" "git clone" operation, e.g.:
    git clone  -b ${branch} file:///${mirror_repo} /usr/src

    As with the worktree, /usr/src does not get updated directly as a
    result of updating the mirror.  To update /usr/src in this case,
    cd /usr/src && git pull

    works (as expected).  And before the "git pull" is done (but after
    the mirror is updated), "git status" will show (e.g.):

    On branch main
    Your branch is up to date with 'origin/main'.
    (and should mention any local changes -- in my case, the "untracked"
    kernel config file).

    I believe, but have not actually got to the point of testing this
    empirically, that by using this approach, I can have the mirror
    owned and updated by a user that is not me, and have /usr/src owned
    by me (as I have been doing since the CVS days), and which I find

I mentioned disk space up there.  Actual numbers for my current
experiment at the moment (with head ("main") at 59d5ed3afc99 and
stable/12 at 37087976b6c2):

* mirror: 1.8G
  * head worktree within mirror: 9.3M
  * stable/12 worktree within mirror: 9.1M

* worktrees
  * head: 1.3G
  * stable/12: 1.4G

* "normal" git repo/working trees:
  * head: 2.5G
  * stable/12: 2.2G

For comparison, svn mirror at r366512:

* mirror: 6.5G
* /usr/src:
  * head: 5.0G
  * stable/12: 4.0G

I hope this might be useful to someone.

David H. Wolfskill				david at catwhisker.org
"The economic outlook is strongest under the scenario in which Biden and
the Democrats sweep Congress and fully adopt their economic agenda." --
Moody's Analytics

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-git/attachments/20201007/3143a8f7/attachment.sig>

More information about the freebsd-git mailing list