I use the same directory structure to separate my repositories and wrote a little wrapper for git-clone to automate it: https://gitlab.com/3point2/git-cu.
The includeIf is new to me and very useful, thanks!
I’m a fan of the merge approach, with the requirement the commit messages are useful.
… with this kind of an entangled graph, it’s practically impossible to find anything in it.
git log --first-parent is great for this. If you are on main, it will show you only merge commits and any commits made directly to main without including all the commits on the branches. Although the author is correct that branches are just pointers and you can’t know which branch a commit was created on, the first parent of a merge commit will always be the “main” branch. This is enough information for –first-parent to filter the history of a branch when needed without actually throwing it away when merging. More info here: https://www.davidchudzicki.com/posts/first-parent/
Pretty cool feature, I didn’t know about its existence before you pointed it out.
I guess my old habit of using and scripting around archive will ultimately take over worktree, but at least I’ll be able to recommend it right away to newcomers!
It also has a URL to folder heuristic, but more importantly, it also hooks into Bash so it automatically changes directory into the cloned repo. So technically, h <owner>/<repo> or h <URL> is idempotent and takes you to that project.
Nice! I like the shell hook for changing directory. I had done a bit of research on how to achieve a directory change without launching a new shell, and it seemed a shell function was the only sane way.
Using “git cu” instead of “git clone” will create a gitlab.com/3point2/git-cu directory structure inside your current working directory.
I really like using git worktree and using it alongside this tool would feel weird. You’d have to put your worktrees somewhere else or come up with some naming convention like gitlab.com/3point2/git-cu_my-branch-name.
I agree, it’s not a neat fit for worktrees in its current state. A friend of mine who uses worktrees a lot said the same! I’d be interested in doing something to include support for worktrees somehow, so I’ve created https://gitlab.com/3point2/git-cu/-/issues/1 - if you have any thoughts / ideas on what would feel ergonomic to you please leave a comment.
I also like organizing my repositories in a way as well. I think this is very helpful for organizing source code for open source, whether it’s contributing or just to pull the code to read.
I wrote a similar tool for myself many years ago, I do recommend having something like this. Every time I want to play with source locally, it’s nice to remove the need to decide where it should live.
It’s very similar indeed, and I had not discovered it prior to writing git-cu! I went with a slightly different design in that it’s “dumber” and passes options directly through to git, and doesn’t offer any management beyond cloning.
I oftentimes found myself very confused of my $HOME/git structure. At $WORK we use three version control systems so it was hard to consistently clone repositories with proper names. Later on it turned out to be a mixture of guessing and ripgrep.
What are use-cases for something like this? I clone most software into a directory called ~/code/src and keep it there, easy to find. If I used subdirectories like this, I’d have to memorize what site I cloned the source code from, and possibly even authors username. The only place I can recognize this from is Go’s package system, but I don’t know if this was created with the same idea in mind.
I find it useful because I often clone both work and non-work git repositories under the same directory. With git-cu all of my work repos end up in a subdirectory named after the work server, and inside that are further grouped by project. Everything else is pretty much either GitHub or GitLab so I haven’t had issues finding stuff, although that is a valid point.
It wasn’t consciously based off Go’s package system but does resemble it now that you mention it!
My main motivator was actually to separate my work repos by project and hence know at a glance which team a repo belongs to. The URLs look something like ‘git@internal.lan:/team/repo’, and I found myself manually recreating the structure by hand. The separation by hostname wasn’t something I was sure about but came to like when I realized it separated work repos from others.
Definitely not a fit for everyone’s workflow but seeing as I use it daily I figured I would put in out there in hope others find it useful too!
I’m with @zge on this. I have ~/projects. I have (on my personal machines) a ~/<day_job_company>/ Or ~/toptal/<client-name> (where I get my sidejobs). To me this is much more meaningful way of separating things.
On my current work machine, my (rarely accessed) personal stuff is in ~/projects as well (as there I have to use the stupid windows c:\<whatever>\<somethingelse>\<stupidexplicitjavastuffwithhardcodedpathswhoevenbuiltthis>.
Any code that I just wanna see what it looks like, it’s ~/projects/tmp (because if it gets accessed frequently enough, it’ll get promoted up a dir easily).
What is more important to me is to clean up things often. The mentioned ~/projects/tmp, every now and then when I remember. The actual projects dir as well - I don’t think I’‘m working on 10 things at the same time. So whatever I haven’t worked on for a while, git push and delete it. The solution for the author would be an overkill for me.
And at work it’s actually a mess because I am frequently involved in like 5 diff projects with multiple repositories each (for reviews, trainings etc). But as long as I clean up from time to time, I rarely end up looking for something.
I do the same as this only $HOME/src is my dumping ground, only just in shell with a function and a couple of function aliases to make things simpler. No need for python3/etc… Finding things is pretty easy, I just do a quick ls -d ~/src///* and can find the thing. I don’t generally know the site or author.
But say I want to clone the NixOS/nixpkgs repo on github all I do is type:
gh NixOS/nixpkgs
And I get dumped into that dir, if I also need to cd to it its also basically like a cd /pushd/popd equivalent.
If anyone’s curious (I also use git worktrees so you’ll see references to that) my setup is:
The worktree setup is normally done via git aliases. What I do is git bwt (branch with worktree, its a bad alias but whatever) so I can do git bwt origin/somebranch branchname then depending where I’m at with the aliases (i have a non public alias for work) but imagine it was a that nixos spiel then I just do:
gh NixOS/nixpkgs branchname or !$ (last commands arg)
Its pretty battle hardened and is portable shell (not bash). Being a function means it can change PWD unlike most of the tooling I’ve seen so far in this thread. I’ve been tempted to put the git alias stuff into shell but find this setup to work the best.
Nice! The @worktree notation is intriguing. @zimbatm uses shell functions in their tool too! I like the ergonomics of git-cu being a git subcommand, so not sure if there’s any way to combine running “git cu” with an alias. Definitely something I will look into though.
I just use worktrees as a way to have multiple branches checked out at the same time. I use the default checkout to be “master” or whatever word of the week is the default branch. The worktrees are there for other branches.
You could use whatever character you want. Actually I’ve been thinking of changing it from @ as as an example the nix tooling doesn’t like @‘s in paths :/ But other than that I’ve not had issues.
I just like this being a function so it can cd like push/popd and cd. I’m lazy and if i just cloned a url I generally would like to be cd’d to the checkout is all. And its a handy function to flip back into the directory as well.
I use the same directory structure to separate my repositories and wrote a little wrapper for git-clone to automate it: https://gitlab.com/3point2/git-cu.
The includeIf is new to me and very useful, thanks!
I’m a fan of the merge approach, with the requirement the commit messages are useful.
git log --first-parentis great for this. If you are on main, it will show you only merge commits and any commits made directly to main without including all the commits on the branches. Although the author is correct that branches are just pointers and you can’t know which branch a commit was created on, the first parent of a merge commit will always be the “main” branch. This is enough information for –first-parent to filter the history of a branch when needed without actually throwing it away when merging. More info here: https://www.davidchudzicki.com/posts/first-parent/git worktreeis what I use for this, which has a few advantages over usinggit archive:git statuswithin worktreesPretty cool feature, I didn’t know about its existence before you pointed it out.
I guess my old habit of using and scripting around
archivewill ultimately take overworktree, but at least I’ll be able to recommend it right away to newcomers!Note, you might also be interested in this tool:
https://myrepos.branchable.com/
Not git specific.
Thanks! Bookmarked 🙂
I wrote something similar a while back: https://github.com/zimbatm/h
It also has a URL to folder heuristic, but more importantly, it also hooks into Bash so it automatically changes directory into the cloned repo. So technically,
h <owner>/<repo>orh <URL>is idempotent and takes you to that project.Nice! I like the shell hook for changing directory. I had done a bit of research on how to achieve a directory change without launching a new shell, and it seemed a shell function was the only sane way.
I really like using
git worktreeand using it alongside this tool would feel weird. You’d have to put your worktrees somewhere else or come up with some naming convention likegitlab.com/3point2/git-cu_my-branch-name.I agree, it’s not a neat fit for worktrees in its current state. A friend of mine who uses worktrees a lot said the same! I’d be interested in doing something to include support for worktrees somehow, so I’ve created https://gitlab.com/3point2/git-cu/-/issues/1 - if you have any thoughts / ideas on what would feel ergonomic to you please leave a comment.
I also like organizing my repositories in a way as well. I think this is very helpful for organizing source code for open source, whether it’s contributing or just to pull the code to read.
I have a similar script I use via bash: https://gist.github.com/rymndhng/cf96f16dd8510d9b417702a00a8c3349
Nice, similar to what @shazow mentioned! Again, really nice to see other people thinking on the same lines 😊
Brazilian developers will have a hard time using this tool.
Why?
I’m not sure this is the reason @tonnydourado made that remark, but “cu” apparently means “ass” in Portuguese.
Oh, and of course, “git” is slang for an unpleasant individual…
Yeah, pretty much, it’s the “cu” part.
Oh dear 😅
Maybe they can apply this just for some clients :)
I wrote a similar tool for myself many years ago, I do recommend having something like this. Every time I want to play with source locally, it’s nice to remove the need to decide where it should live.
My version is here, just a short shell script: https://github.com/shazow/dotfiles/blob/master/local/bin/hub-clone
Nice! It’s really nice to see that others have been thinking along similar lines!
This appears to be the same idea as https://github.com/x-motemen/ghq, which is written in go. I believe it also supports svn and darcs.
It’s very similar indeed, and I had not discovered it prior to writing git-cu! I went with a slightly different design in that it’s “dumber” and passes options directly through to git, and doesn’t offer any management beyond cloning.
This tool looks very promising.
I oftentimes found myself very confused of my
$HOME/gitstructure. At$WORKwe use three version control systems so it was hard to consistently clone repositories with proper names. Later on it turned out to be a mixture of guessing andripgrep.What are use-cases for something like this? I clone most software into a directory called
~/code/srcand keep it there, easy to find. If I used subdirectories like this, I’d have to memorize what site I cloned the source code from, and possibly even authors username. The only place I can recognize this from is Go’s package system, but I don’t know if this was created with the same idea in mind.I find it useful because I often clone both work and non-work git repositories under the same directory. With git-cu all of my work repos end up in a subdirectory named after the work server, and inside that are further grouped by project. Everything else is pretty much either GitHub or GitLab so I haven’t had issues finding stuff, although that is a valid point.
It wasn’t consciously based off Go’s package system but does resemble it now that you mention it!
My main motivator was actually to separate my work repos by project and hence know at a glance which team a repo belongs to. The URLs look something like ‘git@internal.lan:/team/repo’, and I found myself manually recreating the structure by hand. The separation by hostname wasn’t something I was sure about but came to like when I realized it separated work repos from others.
Definitely not a fit for everyone’s workflow but seeing as I use it daily I figured I would put in out there in hope others find it useful too!
I’m with @zge on this. I have
~/projects. I have (on my personal machines) a~/<day_job_company>/Or~/toptal/<client-name>(where I get my sidejobs). To me this is much more meaningful way of separating things.On my current work machine, my (rarely accessed) personal stuff is in
~/projectsas well (as there I have to use the stupid windowsc:\<whatever>\<somethingelse>\<stupidexplicitjavastuffwithhardcodedpathswhoevenbuiltthis>.Any code that I just wanna see what it looks like, it’s
~/projects/tmp(because if it gets accessed frequently enough, it’ll get promoted up a dir easily).What is more important to me is to clean up things often. The mentioned
~/projects/tmp, every now and then when I remember. The actual projects dir as well - I don’t think I’‘m working on 10 things at the same time. So whatever I haven’t worked on for a while,git pushand delete it. The solution for the author would be an overkill for me.And at work it’s actually a mess because I am frequently involved in like 5 diff projects with multiple repositories each (for reviews, trainings etc). But as long as I clean up from time to time, I rarely end up looking for something.
I do the same as this only $HOME/src is my dumping ground, only just in shell with a function and a couple of function aliases to make things simpler. No need for python3/etc… Finding things is pretty easy, I just do a quick ls -d ~/src///* and can find the thing. I don’t generally know the site or author.
But say I want to clone the NixOS/nixpkgs repo on github all I do is type:
And I get dumped into that dir, if I also need to cd to it its also basically like a cd /pushd/popd equivalent.
If anyone’s curious (I also use git worktrees so you’ll see references to that) my setup is:
~/src/domain.tld/uri_prefix ~/src/domain.tld/uri_prefix@worktree
The worktree setup is normally done via git aliases. What I do is git bwt (branch with worktree, its a bad alias but whatever) so I can do git bwt origin/somebranch branchname then depending where I’m at with the aliases (i have a non public alias for work) but imagine it was a that nixos spiel then I just do:
gh NixOS/nixpkgs branchname or !$ (last commands arg)
Have a look see here: https://gist.github.com/mitchty/b37e152ab4dbbc7c320198b61af7e2ac
Its pretty battle hardened and is portable shell (not bash). Being a function means it can change PWD unlike most of the tooling I’ve seen so far in this thread. I’ve been tempted to put the git alias stuff into shell but find this setup to work the best.
Nice! The
@worktreenotation is intriguing. @zimbatm uses shell functions in their tool too! I like the ergonomics of git-cu being a git subcommand, so not sure if there’s any way to combine running “git cu” with an alias. Definitely something I will look into though.I just use worktrees as a way to have multiple branches checked out at the same time. I use the default checkout to be “master” or whatever word of the week is the default branch. The worktrees are there for other branches.
You could use whatever character you want. Actually I’ve been thinking of changing it from @ as as an example the nix tooling doesn’t like @‘s in paths :/ But other than that I’ve not had issues.
I just like this being a function so it can cd like push/popd and cd. I’m lazy and if i just cloned a url I generally would like to be cd’d to the checkout is all. And its a handy function to flip back into the directory as well.
Too many ways to skin this cat.
Shameless plug: if you only remember the project name, and would like to keep this hierarchy, this might help: https://github.com/knl/rh
I wrote it to declutter personal projects from work projects (both company and open-source we contribute to).