![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/8140dda6-9512-4297-ac17-d303638c90a6.png)
True, git
itself can’t prevent people from creating a mess of a commit graph.
TBH, lots of build systems mentioned here I’ve never encountered so far.
But this makes it clearer that one can’t reason about how viable a “one big monorepo only” approach mighy be by just considering the capabilities of current git
, coming from a “manyrepo” mindset. Likely that was the pitfall I fell into coming into this discussion.
Have you ever learned about the following in VIM:
H
,M
,L
,22H
, …,: vertical cursor placementzt
,z0
,zb
: vertical scroll positioning0
,$
,gm
,gM
: horizontal cursor placementw
,e
,b
: word based cursor movementSimply holding
j
ork
at times also works, even more so with a decently high key repeat rate.Of course there’s a lot more: https://vimhelp.org/motion.txt.html
The trick is to only learn a couple new movement mappings at a time and use them during one’s workflow for a while, up until they feel ingrained. Then repeat, iteratively building up one’s movement skills in VIM.
One can say many things about VIM, but not that learning it’s movement mappings will make your required APM (let alone mouse clicks) go up to “get stuff done”. Honestly, once a basic set of these movements has been learned, any other editor without them will feel like a drag.