121–130 of 142 posts
I prefer the Fox News tutorial on the subject. 'Repo' means 'reciprocity' or 'reposotory' if you didn't know.
http://static4.businessinsider.com/image/52330e4deab8eaef7ac... I also wanted to post this screenshot and then saw your comments...
Earlier quoted context omitted.
I'm a huge fan of git (but became one the hard way) and I think that most of the poor design decisions are in the command layer. Largely the tendency for the same command to do several things that, to the user, are wildly different (often because they map to the same fundamental operation on the DAG). As the most simple example, git add both adds a new file to the index and adds changes to an existing file to the ind…
Even just simple commands kind of bother me for poor consistency. git remote -v git branch -a git tag -l git stash list 1 concept, 4 commands. I don't even use git much but this stuff makes it really slow to pick up.
"git stash" is certainly the outlier; the reason is that when "git stash" was first added it was meant to be a short-and-sweet command. Otherwise, you'd be forced to type "git stash save ", which is not so short and sweet. "git stash list" was added later.
This has been danced-around in the comments, so I'm just going to say it: I don't need the concepts of git simplified, I need a better explanation of how git's bizarre command set maps onto the obvious DAG/filesystem operations.
Earlier quoted context omitted.
I'm a huge fan of git (but became one the hard way) and I think that most of the poor design decisions are in the command layer. Largely the tendency for the same command to do several things that, to the user, are wildly different (often because they map to the same fundamental operation on the DAG). As the most simple example, git add both adds a new file to the index and adds changes to an existing file to the ind…
Even just simple commands kind of bother me for poor consistency. git remote -v git branch -a git tag -l git stash list 1 concept, 4 commands. I don't even use git much but this stuff makes it really slow to pick up.
For the latter two, no disagreement there. For the former two, there is a difference between returning a verbose response within the context queried and expanding the inclusive parameters of the query. 'git remote -a' makes no sense as all remotes are equivalent (there is no such thing as a local remote).
Earlier quoted context omitted.
Even just simple commands kind of bother me for poor consistency. git remote -v git branch -a git tag -l git stash list 1 concept, 4 commands. I don't even use git much but this stuff makes it really slow to pick up.
If you're curious, "git remote", "git branch", and "git tag" all present a list without supplying those options. You only need "git branch -a" if you want to see remote branches. "git stash" is certainly the outlier; the reason is that when "git stash" was first added it was meant to be a short-and-sweet command. Otherwise, you'd be forced to type "git stash save ", which is not so short and sweet. "git stash list" w…
Earlier quoted context omitted.
It's that its porcelain is a clusterfuck. The staging area is a hack that greatly convolutes the UI, and it would have been better if it were left out and you just had a way to cherry-pick what you want to commit at commit time (if it wasn't everything). There's no symmetry in commands. The opposite of "git commit" is "git reset --soft HEAD^", not "git uncommit". "git reset" is three commands in one. I could go on an…
You're basically railing against orthogonality. I don't think anybody disagrees that some flags could be made more consistent, but creating a separate git-uncommit when that functionality is fundamentally encompassed by the purpose of the third invocation of git-reset is a mistake. If you make a specific case for 'git reset --hard/--soft HEAD^' then you would either be left without the more general (and more useful)…
git reset --hard tells you absolutely nothing obvious about what it's going to do unless you understand git and its specific incantations. You have to learn git commands, rather than intuit them.
Earlier quoted context omitted.
I'm not using git at all , I'm trying to understand how it works before I start. Every guide to git I read before was a completely opaque mess of terminology, so this is the first time it's starting to make a lick of sense.
I think Git is much easier to understand if you understand the underlying data model. The core object in Git (as far as you need to care) is a commit. Each commit holds a link to the commit(s) it was based on. If two commits have the same parent, you have two branches. If one commit has two parents, it's a merge. Individual commits don't know what branch(es) they are a part of. Branches are just pointers to commits.…
Did you mean to say tags point to a commit?
Earlier quoted context omitted.
> (having sources which are compiled in different base directories) With my nascent Git understanding, I think you would just have multiple branches for v1, v2... and then clone the repository multiple times so you have multiple working copies. Check out v1 in the first one, v2 in the second one. Although changing between related branches is usually quite quick in Git. Also, a fresh checkout of ~100mb is not a lot. A…
> and then clone the repository multiple times so you have multiple working copies. This is probably not what you want. First, you should know that switching between branches in Git is insanely fast. In general, it won't get in your way. If you clone the repository, each one is a full git repository. That means you'll triple the storage on the disk. Worse, you'll have to do 3x as many pulls to keep all 3 repositories…
Earlier quoted context omitted.
It's that its porcelain is a clusterfuck. The staging area is a hack that greatly convolutes the UI, and it would have been better if it were left out and you just had a way to cherry-pick what you want to commit at commit time (if it wasn't everything). There's no symmetry in commands. The opposite of "git commit" is "git reset --soft HEAD^", not "git uncommit". "git reset" is three commands in one. I could go on an…
I love the staging area, and I miss it everytime I have to us SVN at work. I actually use the GIT-SVN bridge to work with git locally, pushing my changes up to SVN when I've resolved a topic. I do this in part because of the staging area. I have accidentally included changes in SVN commits so many times that I try to avoid SVN altogether. I agree though, so many of the commands are just plain painful, the reset comma…
I'm curious, as someone who actually loves it, what if there were just better tools for incrementally altering the last commit instead? I'm not sure that a more robust git commit --amend couldn't achieve the same goals as the index with less conceptual overhead.