I don't know if this is a good idea. People say "programming's too hard" so we got Ruby and set the world back 10 years.
Gitless: a version control system
321–330 of 390 posts
Re: Gitless: a version control system
#322Git is powerful. While the underlying architecture has beautifully simple aspects arguing that the complexity of the git tool-chain is simple is similar to arguing that TeX is simple as it is written in a simple language. Git is managing trees of file-sets in a distributed manner. It took many generations of configuration management systems to get there. Git is bottom up. Understand the inner workings and you know wh…
Exactly. Git does things I used to need Perforce and a full-time Perforce admin to do.
Re: Gitless: a version control system
#323Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are change…
The problem is the world isn't just git. There are thousands of other things to master at any given moment. Putting a veneer over something you aren't interested in mastering and using that seems like a valid strategy.
Re: Gitless: a version control system
#324Earlier quoted context omitted.
Version control is arguably confusing for beginners, but building a shim instead of learning the tool isn't the answer in my head. I always struggle with "lowering the barrier of entry" and it's not a "I did it they need too do it" it's more of a "Usually high barriers mean it's complex, and learning how to understand complex things is important." If this was some new novel way to version that wasn't just pretty git,…
In my previous job, I taught darcs to a designer/graphics artist. It took about half an hour to go through the CLI, and after that he used it successfully and asked me maybe a pair of questions ever. Now the guy was pretty technical (part of his job was AS development), but he was not a developer. Darcs's and Git's fundamentals are not that different[0], but Darcs's CLI actually makes sense in and of itself independe…
That's why we picked fossil over git. The interface is really sane and you can also do stuff from the browser. It gets out of your way. You do not need Python, it can be statically linked easily. It also works on Windows. The usability experience is akin to Mercurial, but even easier to use. Unfortunately it doesn't quie work for bigger projoects (think the Linux kernel or the FreeBSD ports tree) and it can also get slower once you have a lot of history. The repo is esentially a SQLite db.
Re: Gitless: a version control system
#325Earlier quoted context omitted.
How so? You're the one proposing they do the same thing when they fundamentally do not. To posit so is less of git's "ux problem" and more of just needing to grok git. I share your concerns for consistent tooling, but the idea of becoming proficient in something without putting in the effort is not reality.
> How so? Because he's the one who said that they do the same thing.
I don't follow--where does he say that?
Re: Gitless: a version control system
#326Why would I use this over Mercurial, other than being able to collaborate with others using git? You still need a Python interpreter to use it.
Re: Gitless: a version control system
#327Earlier quoted context omitted.
> If all you have is a single commit with no parent, you cannot rebase it. Well, of course what you want to do here depends. You can squash onto it, edit it, or reorder it. You're commonly going to have conflicts if your first commit created a file and the rest edit it. If you reorder you can't edit a file that doesn't exist yet. Here are a couple of videos to illustrate: https://gfycat.com/GrizzledPartialAntelopegro…
The use case is that when I'm making a new repo, I want to be able to do: git rebase -i ^ git reset --patch ^ git checkout --patch ^ I can do all this if the first commit is actually the second and the first is a dummy empty one.
I meant, "what are you setting out to do?" as in "I'm trying to reorder commits" not "I'm trying to `git rebase -i commit`" (the ultimate aim, rather than the path you choose). My instinct is that you can get where you want to go fairly easily with the `git rebase -i --root` I mentioned earlier.
Re: Gitless: a version control system
#328Earlier quoted context omitted.
Professional means it doesn't sacrifice functionality in favour of making things easy for newbies. This is a philosophy I approve of for all software. Vim is great because it offers power at the expense of having a little bit of a learning curve. A shell gives you unlimited power compare to a stripped down and locked down GUI. GUIs and "UX" are generally antithetical to making a computer do what it does best (automat…
"GUIs and "UX" are generally antithetical to making a computer do what it does best (automate things instead of creating more busywork)." Except for helping the 6 or so billion people in their daily lives, but hey, the iPhone would be 'better' if it just had 'bash'? Read your email lately from bash? Didn't think so!
Bash is what I miss in iOS, I used to jailbreak just for getting a shell.
Now, I use pythonista as a python-shell. Being able to chain a couple of commands and fix a good-enough solution saves a lot of time in many cases such as web scraping on-the-go.
I know this may be an extreme use case, but if iPad is going to be a laptop replacement we need to be able to get a way to speak with it without immidiate access to a laptop.
Re: Gitless: a version control system
#329Earlier quoted context omitted.
I think git's concepts are simple and worth learning (unlike what the gitless people said). That being said, the command line interface is "meh" at best and full of byzantine options.
> I think git's concepts are simple and worth learning For what purpose? The reason for using a VCS is to get your job done. If gitless does that, why should I need to learn the concepts of a content-addressable graph storage and traversal format?
For instance, git has a notion of staging area (the index) where you collect the changes that go into a commit. In gitless, all changes to tracked files are committed. The index goes a long way towards making nice commits that can be understood by other team members, pass tests, etc.
Similarly, the stash that allows you to save your uncommitted changes before switching branches is also quite worthwhile.
Re: Gitless: a version control system
#330Earlier quoted context omitted.
Hg did that - unfortunately GitHub won over BitBucket, thus deciding the fate of Mercurial too.
I find Mercurial so much easier to use than Git. Many of the concepts are similar but the hg interface feels much easier to learn and use.
I use Mercurial as a client for git, using the hg-git extension. It works absolutely fine for my use case (small numbers of developers on github, mostly). There are a few rough edges when you want to do things that git doesn't like, like moving tags, and the bidirectional branchbookmark syncing isn't quite as robust as it should be, but it saves me having to touch git at all.