Date: Wed, 7 Oct 2020 06:30:15 -0700 From: David Wolfskill <david@catwhisker.org> To: git@freebsd.org Subject: [resolved] Re: Question on (my) workflow migration svn -> git Message-ID: <20201007133015.GA37695@albert.catwhisker.org>
next in thread | raw e-mail | index | archive | help
--82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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 =46rom 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 (f= orced 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 note.) * 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, though: 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 attractive. 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. Peace, david --=20 David H. Wolfskill david@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. --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl99wuZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 Pckqagf/Q4ia2pJO1puPER4mwklP8SEfHcWPe7/852l8YhqAwxuhD1NG1eA1NBU/ V1aEkElnU1L+vuOr/ckkRoBGNTmpZlQ3XutHobQprTDJd0I6qqb8y2YW76gYfUfz Xxn9oEYrfuPNzaKnzKqx8pYugPMa/cNO+aMEyzr2uakmd909sGhfgBEyI+Ua9fT5 XORKeZAHJLhpwThC9eE4JpjLOS4KwcXH1xkygas1LOwZ11s5yIryUfkkWlcNlQTU oQzzRBbqmaxbGXAk4IEe3THRGczW1Nwx0Q8WxMy8elayEUt2DglNecBD7qVig1Qs FuCAxPN70B1KPeOD7pBOXu9oAoBvOg== =EoXN -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201007133015.GA37695>