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

Git concepts simplified

gitolite.com

Post reply on HN
Print view View original

131–140 of 142 posts

Re: Git concepts simplified

#131

Post by pjmlp »

pjmlp wrote: post #26
jlgreco wrote: post #12

Earlier quoted context omitted.

> Name another end-user product for which you are even vaguely aware of what data structures were used. Unix. You are operating primarily on a tree of files and streams of text. To operate on these you have a wide array of utilities that perform simple tasks (and a handful that perform complex tasks as well) that, when composed, allow you to perform any transformation you want. You can get a freshman CS student off t…

Except there isn't a single version of UNIX, each flavour has its own deviations.

So I get downvoted by stating the truth. It shows how many HN readers have done portable development across real UNIX systems.

Re: Git concepts simplified

#132

Post by ezquerra »

jlgreco wrote: post #11
dcre wrote: post #2

I love Git, but I'm pretty sure there's no way to explain it simply.

I don't get this attitude. The DAG is exceedingly simple and I think can be taught reasonably in only a few minutes. From there you really only need to teach a very minor amount of the UI, and teach the user how to perform "I want to do this to the DAG" => "This is what I type" translations on their own. I've seen all of this done well in sub-hour presentations. Mercurial on the other hand has a pain in the ass datam…

I find that your comment about mercurial's data model a bit ridiculous.

The reason why most introductions to mercurial do not mention its data model is because it is _not_ important. You really do not need to care about it at all on your day to day use. I've been using mercurial for years and I've never had to ask myself what is mercurial's data model.

IMHO the reason why git forces you to understand its data model is because its UI is terrible. It is a failure of the tool when you need to understand how it works internally to use it. If git's UI were better its awesome data model would be something that only git devs would need to understand.

Re: Git concepts simplified

#133

Post by Sir_Cmpwn »

It's the stuff behind the curtain that makes me love git. It doesn't just seem like version control software - it seems like the software is an interface to a much more powerful version control engine. Git just makes sense under the covers.

Re: Git concepts simplified

#134

Post by Ygg2 »

ranman wrote: post #79
ender7 wrote: post #66

Earlier 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?

The commands, my god there are numerous commands that have no rhyme or reason.

Want to checkout a branch?

   git checkout
Want to make a branch?

   git checkout -b
Want to reset a file?

   git checkout --
Want to make a sandwich?

   git checkout ++D@A#32
Want to rebuild universe from Big Bang?

   git checkout 0 --rebuild-universe
Add to this, duplicated commands, arcane commands (hello fsck --lost-found), commands that seem deceptively similar but aren't, doesn't work out of the box like hg, doesn't work on Windows etc.

I love git, but its CLI is horribad. And that is after most of weird/confusing stuff was removed...

Git, like Linux is a power tool. It's like those drills that can drill through solid rock easy, but if they jam, they'll spin you around.

Re: Git concepts simplified

#135

Post by VeejayRampay »

EdwardDiego wrote: post #100
VeejayRampay wrote: post #37

Earlier quoted context omitted.

Word. I have a theory that while git has completely taken over the software industry and most users can "get shit done" with it, very few of them actually understand what the fuck is going on. All those "simple explanations" are really nice theoretical pieces about the merits and design of git itself and most of the time tend to completely ignore (or dodge) the clusterfuck that every day git can be, especially for pe…

> the subtle differences between fetch and pull While I agree with some of your criticisms, as the resident 'Git guy', I've found no difficulty in explaining to people that pull is a convenience alias for 'fetch followed by merge'.

True, but to understand that you also need to understand what fetch and merge do respectively. Not so easy for the profane/beginner. You're correct that this one is a bit of dishonesty on my part though :)

Re: Git concepts simplified

#136

Post by acqq »

taspeotis wrote: post #129
MBCook wrote: post #118

Earlier quoted context omitted.

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

I know this, but GP was asking about how to do it with "different base directories" which I'm assuming is asking for an analogy to Subversion's multiple working copies (i.e. check out this location from the repository to this location on disk).

Yes you're right, the thing is, the project produces different binaries which should be accessible for all different versions, which was solved by having only different base directories, all the configuration files build to same subdirectories no matter which version. If I'd switch to "always having only one version in a single base directory" then I'd have to maintain different temporary output and binary output names in all the configuration files in every version which is quite ugly. Then I can't use any "known fixed subdirectory names" in the projects.

Re: Git concepts simplified

#137

Post by Perseids »

develop7 wrote: post #103
Perseids wrote: post #92

Earlier quoted context omitted.

The underlying data structures do matter, even with mercurial. One workflow I immensely appreciate with Git is locally committing some series of messy changesets and commit messages and then afterwards, when I have finished the feature, tidying everything up by rewriting the history (git rebase -i) before I push my commits. When I tried the same approach with mercurial I found that rewriting the history is not reason…

Your rebase-based workflow is easily achievable with Mercurial. And there's even --outgoing switch in histedit. > Histedit extension which is meant to provide this feature has warnings all over the place Ignore them — you do know, what are you doing, right? > changeset backups written to locations in the working tree That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked.

> Ignore them — you do know, what are you doing, right?

No, I don't :). I heavily rely on my CVS to never loose any data and to be able to go back to a previous state whenever I need to. This works great with Git's reflog.

> That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked.

I stand corrected then. Maybe I'm mixing that up with amend or revert? I last used mercurial 9 months ago, but believe to remember there was some command that left .orig files lying around and that if you applied a history rewrite command several times those backups were overwritten with the new backups and you weren't able to come back all the way.

Re: Git concepts simplified

#138

Post by develop7 »

Perseids wrote: post #137
develop7 wrote: post #103

Earlier quoted context omitted.

Your rebase-based workflow is easily achievable with Mercurial. And there's even --outgoing switch in histedit. > Histedit extension which is meant to provide this feature has warnings all over the place Ignore them — you do know, what are you doing, right? > changeset backups written to locations in the working tree That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked.

> Ignore them — you do know, what are you doing, right? No, I don't :). I heavily rely on my CVS to never loose any data and to be able to go back to a previous state whenever I need to. This works great with Git's reflog. > That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked. I stand corrected then. Maybe I'm mixing that up with amend or revert? I last used mercurial 9 months ago,…

> to be able to go back to a previous state whenever I need to

as I've said, old commits are backed up.

> This works great with Git's reflog.

except git reflog is cleaned on git gc

Not mentioning http://mercurial.selenic.com/wiki/ChangesetEvolution feature is being in development.

> there was some command that left .orig files lying around

Only way .orig files may pop up is failure to replay rebased commit(s). No way these are backups — their purpose is to make user able to fix things and continue.

Re: Git concepts simplified

#139

Post by MBCook »

dolinsky wrote: post #128
MBCook wrote: post #116

Earlier quoted context omitted.

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

> Tags point to branches, but they don't get updated. Did you mean to say tags point to a commit?

Yep, good catch.

Re: Git concepts simplified

#140

Post by EdwardDiego »

VeejayRampay wrote: post #135
EdwardDiego wrote: post #100

Earlier quoted context omitted.

> the subtle differences between fetch and pull While I agree with some of your criticisms, as the resident 'Git guy', I've found no difficulty in explaining to people that pull is a convenience alias for 'fetch followed by merge'.

True, but to understand that you also need to understand what fetch and merge do respectively. Not so easy for the profane/beginner. You're correct that this one is a bit of dishonesty on my part though :)

Yep, that's true. I think I've nearly taught our testers the difference. :D
Post reply on HN