Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitless: a version control system

gitless.com

Post reply on HN
Print view View original

271–280 of 390 posts

Re: Gitless: a version control system

#271

Post by nine_k »

tree_of_item wrote: post #187
k__ wrote: 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. No. Why do people think "professional" has to mean "poorly designed"? But then, the rest of your post seems to miss the point of this thing entirely. You go on to say that you basically only need 10 commands...which is pretty much the insight that lead to Gitless in the first place.

Is an aircraft cockpit a poorly designed ux? It does require a fair bit of learning.

Re: Gitless: a version control system

#272

Post by varcharlie »

git init - create a new repo

git clone - download an existing repo from the internet

git status - show changes made in repository and any pending additions that haven't been committed

git diff - show changes made to file that haven't been committed

git pull - pull changes from remote repository

git push - push changes to remote repository

git log - show log of commits

git mv - move a file while preserving diff

git rm - remove a file

git add - add a file

git checkout - checkout a branch, file, etc

git reset --hard origin/master` - undo all changes, reset to last commit in master

git blame - show who is responsible for what in a specific file

git fetch - download objects from another repo/branch

git merge - merge two branches together

... etc.

Re: Gitless: a version control system

#273

Post by slavik81 »

chowells wrote: post #216
tree_of_item wrote: post #187

Earlier quoted context omitted.

> Git is, like many professional tools, something you simply got to learn. No. Why do people think "professional" has to mean "poorly designed"? But then, the rest of your post seems to miss the point of this thing entirely. You go on to say that you basically only need 10 commands...which is pretty much the insight that lead to Gitless in the first place.

"Professional" doesn't mean "Poorly designed". It means "designed so that people with lots of domain knowledge and experience with the tool find that it never gets in their way." In that sense, git is a professional tool. If you know everything about it, it doesn't get in your way. The problem is when you don't know everything about it..

I think this is because the commands are poorly named and badly organised. Professionals will use it frequently enough that they remember everything they need and find it easy from that point forward, but for beginners the unintuitive commands are a double-whammy. It's hard to find the command you want, and the poor naming is a hinderence to building a good mental model of the system.

Re: Gitless: a version control system

#274

Post by nickhuh »

tadfisher wrote: post #240
k__ wrote: 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 wasn't designed to be used by humans. I can't find the quote, but Torvalds said at one point that intention of Git was to provide a content-addressable graph that more human-friendly tools could build upon for different use cases. Those 10 commands are the beginning of the iceberg when you actually start using git with teams. Where are `rebase`, `merge`, `branch`, etc? These are all commands I use daily, they are…

I could be wrong, but I think the article that the Torvalds quote came from was purely satirical [1]. If you look at the tags it says it was posted under satire. Got me at first too!

[1]: http://typicalprogrammer.com/linus-torvalds-goes-off-on-linu...

Re: Gitless: a version control system

#275

Post by gjolund »

k__ wrote: 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 bisect should be on this list.

Re: Gitless: a version control system

#276

Post by cm3 »

loup-vaillant wrote: post #266
cm3 wrote: post #209

Earlier quoted context omitted.

I mean when you get a .patch file and git-am that doesn't provide the same associated info (or environment) for git to resolve a merge.

Oh my, I was confusing git commit -am with git am. Didn't know about that last one. Knowing that, it is very strange that the two methods should yield different results: the patch file is supposed to rely on a parent commit that should be accessible on the local repository, just like a local series of commits. That somehow the associated info/environment differs indicates there's a bug somewhere —or at least yet anot…

I can't find anything in the manpage about git-am checking the patch file's parent(s), but a patch file is accepted by git-apply as well, and then it's certainly not expected to consider a parent. That said, I've had git-am fail while git-merge or git-rebase would do the right thing, so git-am is probably, judging by the docs as well, not taking the history into account. If it does and I forgot to tell it how, I didn't know what options it is.

Re: Gitless: a version control system

#277

Post by zajd »

Certhas wrote: post #263
zajd wrote: post #181

Earlier quoted context omitted.

It's not an argument because that Koans article is horrible satire that people are trying to pass off as a legitimate argument. I detailed in my post one direct example as to why that post shouldn't be taken seriously. Now, if you have some legitimate gripes about git's usability I'd love to respond to them and have a real discussion, but Gitless doesn't make those arguments, it's just a wrapper around git (which cou…

It wasn't entirely obvious what you were responding to in my post exactly. That article is satire, but if you don't even want to accept that maybe the git commands are badly named (and besides your one bad example, there are plenty of real examples in the satire) I don't see much point in having a discussion. It being "just a wrapper around git" is an excellent argument that the user interface and usability are probl…

Thank you so much for posting that pdf, that really should be posted somewhere on that site because without the context just throwing out "it's git without a staging area" seems like a pretty poor argument. After reading the whitepaper I would still say that I'm not sure there's much value in the project, that being said they did manage to simplify the "mental model"... although honestly not by much. I'm not sure the cost is worth the benefit here.

Re: Gitless: a version control system

#278

Post by nkurz »

__david__ wrote: post #234
sametmax wrote: post #54

Earlier quoted context omitted.

This is not objective. Git CMD has terrible flaws that are easily spotted as soon as you start teaching git, because you can see people struggling on difficulties purely created by a bad design. As a professional trainer, here are the most commong problems: - git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the opt…

> - stashing is dangerous. I've seen many students losing work with a stash pop requiring a merge which ended badly. I've seen this assertion before, I don't understand it. If `stash pop` has conflicts and it gets confusing, you can always just `git reset --hard` and `git stash pop` again. The stash does not disappear if there are conflicts. The only time you can lose data is if you explicitly `git stash drop`. So do…

Having just been in this situation, I think you are missing the problem. The problem is that after "git stash pop" has conflicts, the user does not know the state that of the system, and thus does not know how to react.

In my case, I temporarily changed a number of tracked "build" files that are custom my system and that I do not intend to check in for others to use. I was then asked to test a branch that someone else had checked in. My desire was to stash my local changes, check out their branch, and reapply my local changes to build it. But after "git stash pop" failed I had trouble figuring out the state of the system. I couldn't make any sense out of the messages that appeared, and fell back on Googling for answers.

My expectation was that the stash would have been popped, that I would open the build files, find some lines about merge conflicts, that I would manually fix them in an editor, and then I would rebuild. Instead, it does "something else", and hard part was figuring out what that "something else" was. There are probably excellent reasons for the exact behavior, but I'd ask: where is it made clear to the user what happens when "git stash pop" experiences conflicts? Where does it say to do what you suggest?

Separately, if you happen to know, how should I best deal with this personally frequent situation that I have a small "patch set" that I want to be able to apply to arbitrary branches, but that I have no intention of ever making visible to other users? I'm sometimes tempted to fall back on "git diff > patch.local" and manage it manually, but there must be a better way.

Re: Gitless: a version control system

#279

Post by nickhuh »

In my experience, making "gl commit" equivalent to "git commit -a" seems like a bad idea. When leading a team, especially of newer coders, one of the most effective ways I've found of keeping the git logs and the code base sane more generally, is to force people to review their own code at the time when they commit it. Individually adding each file with "git add -p" achieves this, and "git commit -a" squashes it.

Reading the methodology used to develop gitless yesterday was interesting, but if I recall correctly, I think it left something out. They looked at how often a software design allowed users to complete their intention, but the tool ideally not only should allow users to complete their intention, but should encourage users towards practices that increase the quality of the end product. While people may struggle with staging at first, I think it in the end encourages better software, which is my biggest concern.

Re: Gitless: a version control system

#280

Post by lisper »

popmystack wrote: post #258
lisper wrote: post #198

Earlier quoted context omitted.

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) This is a perfect illustration of why git needs a better UI. Two different commands to do exactly the same thing, with the only difference being that one is for one file and the other is for many files? If you tried to design a hard-to-use UI you could hardly do better t…

They are not doing the same thing. It's two completely different operations.

You'll have to take that up with /u/k__.
Post reply on HN