Can someone please convert this into a nice pdf? Chances are I will do this type of reading when I am offline...
Git concepts simplified
81–90 of 142 posts
Re: Git concepts simplified
#82Earlier quoted context omitted.
There's also a bit of "people in glass houses..." to this comment. I don't think git really wants to start a fight when it comes to poor design decisions.
out of curiosity could you enumerate some of the poor design choices in git?
Re: Git concepts simplified
#83Earlier quoted context omitted.
There's also a bit of "people in glass houses..." to this comment. I don't think git really wants to start a fight when it comes to poor design decisions.
out of curiosity could you enumerate some of the poor design choices in git?
Not sure what ender7 refers to. As far as I know, there are a few things in git that its maintainers think are missing - e.g.,
Linus mentioned that having a "generation" in a commit, which is 0 for the empty commit and 1+max(generation of ancestors), would have sped up some merge operations.
Finding the history of a single file requires traversing the entire commit tree.
But there is no "fundamental" problem or bad design choice - and in fact, this data can easily be cached without adding it into the protocol.
EDIT: saw some complaints listed in this thread - they all have to do with UI, not with a design choice that is limiting use. Wrappers like "eg" and "legit", and macros, can be used to fix the UI (except no one agrees on what a better UI looks like).
Re: Git concepts simplified
#84Earlier quoted context omitted.
There's also a bit of "people in glass houses..." to this comment. I don't think git really wants to start a fight when it comes to poor design decisions.
out of curiosity could you enumerate some of the poor design choices in git?
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 index. They are both fundamentally the same operation, but your intentions are different.
Checkout, likewise, both changes HEAD's symbolic reference and changes the working copy to match the index or a commit. This makes it both a means of full tree changes and local reversion.
And then there's rebase...
I don't think these are huge issues, but I do think they're barriers and a source of common early issues with git for new users.
Re: Git concepts simplified
#85Earlier quoted context omitted.
Git and Linux were both invented by Linus Torvalds.
Linus just created a kernel that can be used with a Unix-like system. The difference here isn't academic, what I am talking about above was created before Linus was born. (mildly interestingly, he apparently missed Unix Epoch by only a few days)
After looking at Git I wonder how Linus could ever constraint himself to POSIX? How come linux system calls don't have ten optional parameters each? Some of them actually mandatory, some changing meaning of the whole call?
Why go with boring open, creat, read, write when you can have rerere and prune and annex and reflog?
Re: Git concepts simplified
#86Earlier quoted context omitted.
I think part of the problem is that git, like other version control systems, does not enforce any particular way of working (workflow). When authors try to explain how to use git, they often have a very particular workflow in mind and don't necessarily describe exactly what that workflow is. This can cause major problems when somebody tries to apply advice to their own workflow. I like the graphical approach. It help…
That's not it. Following any reasonable workflow still requires a set of arcane commands and flags that only make the slightest bit of sense if you know how git is implemented. I was able to use SVN successfully without ever knowing a thing about the implementation. I've generally had the same experience with HG and even CVS and VSS back in the day. Git adds sophistication over a prodcut like SVN, but adds vastly mor…
I had to use svn in college for some projects and we frequently ran into terrible merge problems that we simply couldn't figure out because we didn't know what was actually going on behind the scenes.
git is more complex on the surface, but I really find it to be so much simpler when you end up in real nontrivial use cases, especially when something goes wrong. I would agree that the commands are sometimes too memorization-intensive, but I've never been in a situation with git, even as a beginner, that I couldn't figure out and resolve relatively easily, especially with all the online resources available. I can't say the same for svn. Maybe I was just an idiot when using svn, but if I was an idiot there, I don't see why I wouldn't be an idiot with git as well unless there was just something fundamentally more useable and flexible and understandable about git.
Re: Git concepts simplified
#87I don't use Git and would like to know how the following problem is solved in Git.
Say you have a project which is a hundred megabytes big. And you have to develop almost in parallel three or four "generations" of the project -- let's say. v1, v2 and v3. In parallel means you'd like to be able to build any of the three versions without having to take the version out of the repository first. You can't say that v1 is obsolete, as soon as some bugs are reported in v1 you have to fix them in v1, v2 and v3. And every bigger version is "newer" but some features can be added in v2 and v3 some just in v3 etc.
How can you work on such a big project and have a single repository where all three versions are present, and work on these three versions in parallel (having sources which are compiled in different base directories)?
Re: Git concepts simplified
#88Git's learning curve feels similar to the learning curve of a programming language like Python. Once you understand you're not going to pick it all up in an afternoon (just like a language) and that there will be lots more to learn down the road (like a language), git feels great.
Programming language is 80% of my work effort but version control is more like 5%. It should be an utility, I don't want it to be a world of its own right, I don't have needs for insanely powerful version control system because my needs are sane and limited - and that's where git is not so cool.
Re: Git concepts simplified
#89Earlier quoted context omitted.
out of curiosity could you enumerate some of the poor design choices in git?
Not sure what ender7 refers to. As far as I know, there are a few things in git that its maintainers think are missing - e.g., Linus mentioned that having a "generation" in a commit, which is 0 for the empty commit and 1+max(generation of ancestors), would have sped up some merge operations. Finding the history of a single file requires traversing the entire commit tree. But there is no "fundamental" problem or bad d…
"saw some complaints listed in this thread - they all have to do with UI, not with a design choice that is limiting use."
For many people, UI issues carry way more weight as "design choices that limit use" than issues such as speed, efficient disk usage, data normalization, etc.
"Wrappers like "eg" and "legit", and macros, can be used to fix the UI"
I disagree. There may be some that _could_ be used, if 'the internet' wasn't filled with helpful comments using the 'real' UI. As it stands now, there is no replacement that has sufficient market share to give users a good chance of finding questions to answers they may have. It is a bit like the early days of Windows, where "how do I..." Questions got answered by "that's easy. Exit to DOS..." (Linux on the desktop has a bit of a similar problem, but I think it is slowly outgrowing it)
"except no one agrees on what a better UI looks like".
That may be an indication that it really is hard (maybe even impossible) to find a good alternative UI hat does not leave out git features.
Re: Git concepts simplified
#90I don't use Git and would like to know how the following problem is solved in Git. Say you have a project which is a hundred megabytes big. And you have to develop almost in parallel three or four "generations" of the project -- let's say. v1, v2 and v3. In parallel means you'd like to be able to build any of the three versions without having to take the version out of the repository first. You can't say that v1 is o…
> (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. At least for an SSD.
This also relies on having a centralised Git repository for you to push/pull changes to. But I believe Git allows you to synchronise multiple repositories on disk.
You're rarely developing two things at once in any given instant of time... why not just quickly check out the branch you want?