Live data from Hacker News

Gitless: a version control system

gitless.com

101–110 of 390 posts

Re: Gitless: a version control system

#101
post #67
post #62

Earlier quoted context omitted.

Is there a gentle introduction, comparable to hginit.com for mercurial? When I first started version control I was trying to choose between hg and git. The site hginit was huge for getting me to swing towards hg.

https://www.atlassian.com/git/tutorials/ This is generally where I point people who have a technical background

Atlassian has put some great "mind abstractions" on top of git to help people understand how to use it.

It's definitely fashionable these days to hate on complicated tools. I wonder if the same is true in other professions. Simple tools are easy to use, yes. But anyone who as worked on a Bicycle or other equipment that requires specialized tools knows that the having the correct, often more complicated tool beats the hell out of wacking on it with the wrong type of wrench.

Re: Gitless: a version control system

#102
Git 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 changed and which of them are staged

    git add -p // add "chunks" of changed files to the stage

    git commit -m "" // commit everything added to the stage with a commit message

    git log // show a list of commits

    git checkout  // throw away all changes since the last commit (one file)

    git reset --hard // throw away all changes since the last commit (all files)
If you want to work with a repo from somewhere else like Github etc., you need a few extra commands:

    git clone   // clone a remote repository locally

    git pull // download and merge new commits in the remote repo that happened since the last clone/pull

    git push // uploading your own changes after a commit to the remote repo
I think these 10 commands are all that is needed to get your own project into Git.

Yes, the more people are working on a project, the more commands you need, like creating a new branch and getting commits from one branch to another, or amending commits because you forgot something etc.

For a professional tool this isn't too much, I think. The 10 commands I mentioned will be remembered in less than a week. Most of the rest isn't needed often (maybe merge/rebase and branch depending on how you intend to use Git), but they shouldn't take too long either.

Re: Gitless: a version control system

#103
post #51

Earlier quoted context omitted.

I was referring to the fact that in git you can cherry-pick a commit as the similar mechanism.

Ah, such a misnomer: you don't cherry pick a commit , you cherry pick the patch that lies between the selected commit and its parent. It may feel like nitpicking, but it's quite important when trying to understand the differences and commonalities between various version control systems.

Yes, and it's why running git-am on the isolated commit can fail whereas cherry-picking does a proper merge and is more likely to apply cleanly.

Re: Gitless: a version control system

#104
post #28

When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the k…

I use git all the time and prefer it for all types of workflow as a VCS, but this idea that git is perfect and it's your own fault for not learning it properly is ridiculous. UX/UI in programs is important. I believe that git has one of the worst, most inconsistent UX's of all time. You can see this by the fractured commands. Quick examples: 'git reset' vs. 'git revert' and sometime 'git checkout' 'git checkout' vs.…

Agree. There needs to be a higher level git command interface for those of us who appreciate git's power but would prefer to just get common stuff done without worrying if we just messed up months of work and have to unwind and fix the screwed up code base. git reminds me of C, super powerful and super easy to mess up.

Re: Gitless: a version control system

#106
post #89

Earlier quoted context omitted.

> Have you ever worked with a different VCS? Yes, I've worked with RCS, CVS, SVN, SourceSafe, Perforce and some others, though know them less well. Git is bar none the best of all (of which I've had experience) the VCS' out there. I would pick it over anything else. The issues I'm pointing out are not because I don't use it, don't understand it, or don't appreciate it. I just believe that it's too complex. If git was…

It can be though. That's like saying Linux would be better if they only gave you ls, cat and nano because vi, sed and xargs were too complicated. There is nothing about gitless that provides a decent experience (compared to git) and certainly nothing about gitless that has anything to do with operating at "scale". The truth is commands like filter-branch, rebase, cherry-pick, etc. which are notoriously difficult to u…

> That's like saying Linux would be better if they only gave you ls, cat and nano because vi, sed and xargs were too complicated.

That's a rather condescending thing to say and not accurate or supportive of the view of git you seem to hold.

> The truth is commands like filter-branch, rebase, cherry-pick, etc. which are notoriously difficult to use... you don't even have to use them.

Until someone on the team _does_ use them and then things can become messed up in ways it takes a git expert to figure out how to fix. I've used git for several years and had never even come across filter-branch, I'd have to chase down the git docs to see what it even does. I never had to filter anything with CVS, Continuus, Perforce, SourceSafe or Subversion.

Re: Gitless: a version control system

#107

Earlier quoted context omitted.

You don't think that the "git push" output includes a lot of verbose tehnical junk not meaningful to most users?

Not really, while I'm not sure what 50% of that means, it's just reassuring that after push I see that 5 lines and a percentage counter. I can also copy the commit hash and refer to it in a ticket.

The first 5 lines in that image could be replaced with a simple progress bar and no one, except for git developers, would lose anything worth keeping. That stuff in a normal CLI tool would only pop up if you use --verbose/-v, it's almost irrelevant to the average user.

Re: Gitless: a version control system

#108
post #102

Git 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…

> Git is, like many professional tools, something you simply got to learn.

Nailed it.

Re: Gitless: a version control system

#109
My criteria for whether an interface to git is truly easier is whether artists can use it. I've worked in games alongside artists, with everyone using Perforce. At some point we switched to Perforce for the art, and git for the programmers, with a big janky glue system in-between.

Git couldn't really handle all the binary assets, and the artists couldn't really handle git, so it made sense. When we switched, it also took a long time before the programmers could really handle git too, fwiw.

I've long said I'd love to see something that's as nice a GUI as p4v, but with git under the hood. I haven't yet seen a git GUI that even approaches now nice p4v is, and git on the command line, once you learn it, is the best interface to git hands down.

I can't tell, but does gitless look like it could make a simpler gui to anyone else? I love the idea of gitless, I'll have to try it, but I get the sense that I'd end up needing to switch to git for some things.

Re: Gitless: a version control system

#110
post #109

My criteria for whether an interface to git is truly easier is whether artists can use it. I've worked in games alongside artists, with everyone using Perforce. At some point we switched to Perforce for the art, and git for the programmers, with a big janky glue system in-between. Git couldn't really handle all the binary assets, and the artists couldn't really handle git, so it made sense. When we switched, it also…

Re. GUIs for git, have you taken a look at GitKraken [1]? I haven't had the chance to put it through its paces, but it looks pretty good.

[1]: https://www.gitkraken.com/

Post reply on HN