Flakes are basically a framework for centrally managing dependencies. Instead of using fetchgit, you’d just make the git repo a flake input and use that input wherever you need to.
The other nice thing they do (that I use) is provide a nice way to define entry points (either ones accessed by a specific nix flake command, or just Nix flake run). Nix flake check and nix flake fmt are the ones I use.
But mostly it’s not anything new, just a (eventually, right now needing to be manually turned on is annoying) nicer UX on top of things that were already possible.
With flakes it seems a lot easier to understand where all the parts are coming from. You give it git repo urls and it gives you a workable package. If you want to use a branch, or unstable, or whatever, it’s right there in the flake. Also, input and output are clearly marked.
It’s not doing anything new, really, but as a stand-alone unit it seems easier to wrap my head around.
I've just started using floobits, I work remotely with people all over the place(and they all use sublime) so it's a fantastic product for me. One thing I haven't got my head around is the workflow involving git. Have you guys put any thoughts down about this?
I'm definitely team command-line for git, but I've been happily using lazygit to quickly review repo changes before committing and it's been pretty good for that.
If I am going to make any changes to a config file, I just initialize a repo in that directory and make my changes. This is great to track what was done during outages when normal controls and processes are out the window.
I don't use rsync as much nowadays, as now I copy files around using git. It makes it easy to make sure two systems are in sync with one another.
If I want to compare directories A and B, often I will just create a repo in A and dump the contents of B on top of it.
And local clones and easy branches means it is easy to test crazy code and break source trees.
EDIT: One more thing, jgit is great for systems where you can't install git (like AIX, where it is a pain to get the packages). It's a single java jar that you can deploy to any system that has java http://eclipse.org/jgit/. I take the .sh script that wraps the .jar file and symlink it to a 'git'.
Thanks for mentioning this. Since my workflow and even setting up a new laptop, virtual machine, etc is all git based for me, using gists could be a great addition for me.
Very recently I used libgit2 in an application. It was quite nice. Then I noticed my build was failing because I make static binaries and my setup couldn't handle libgit2 via Haskell for some obscure reason. So I rewrote my Git layer to use the Git porcelain shell tools (git mktree, git hash-object, git commit-tree, etc) as a quick and easy way to get it working again. I find it quite typical that using native libraries via FFI instead of shelling out to programs leads to tedious problems. And that's part of why I cherish the Unix tradition of combining different programs; shell scripting is one manifestation of that.
My point was going to be that these are concepts and protocols rather than programs, and that you would use an actual program (eg TortoiseGit) to actually use it.
But then I read your comment and realised in *nix the program is actually called "git". So I concede :-)
For me, the big missing use case is using it on Windows. It feels like git actively hates the Windows developer. Install mysygit on a windows box and the recommended option is to use a bash shell. A bash shell on a windows machine.
The message seems to be 'git's never going to really try to work your way; why not pretend you're using *nix?'
It works and it's popular and the underlying model is easy to understand.
I think step one to replacing git will be to launch a tool that completely replaces the git CLI but uses the same model below. I've not looked into EasyGit much, but I don't think it goes far enough.
Do the devs already know git, or will it be a new experience for them? No matter what tool(s) you use, learning to use git effectively will be the hardest part.
I use TortoiseGit integrated into Windows Explorer for most stuff, and drop down to the command line in the odd situation where it's needed. I can't give much feedback about the server side, I'm using GitHub.
The best part is that since it's still just a git repository, once it's local you don't have to bother with jgit at all. I'm going to replace a custom git bundle + tarsnap backup thing I have going with this tonight. Gonna be great.
I've built a UI on top of libgit2 and I wish that this blog post expanded on which new features are missing (sparse checkout?).
To quote: "The migration to Git Executable will allow us to resolve long-standing issues with GitKraken Client, such as poor LFS performance, SSH configuration support and many other features/performance improvements."
I don't have the same background as the "person that wrote it," and I consistently find the git command-line tools easier to work with than other tools (SourceTree, magit-mode, vim-fugitive, etc [1]). I think that in this case, it's just the mental model of a DAG[2] of commits that people have trouble wrapping their minds around. The tools are just there to help you slice and dice the DAG.
[1] I haven't used TortoiseGit, but I do imagine that having file browser menu items for files that are maintained by git could be useful from time-to-time, but I would still be using the cli most of the time.
The other nice thing they do (that I use) is provide a nice way to define entry points (either ones accessed by a specific nix flake command, or just Nix flake run). Nix flake check and nix flake fmt are the ones I use.
But mostly it’s not anything new, just a (eventually, right now needing to be manually turned on is annoying) nicer UX on top of things that were already possible.
reply