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

Die Git Die

github.com

Post reply on HN
Print view View original

71–80 of 100 posts

Re: Die Git Die

#71

Post by ryanknapp »

stormbrew wrote: post #25
jrockway wrote: post #7

"The git, the?" But seriously, yes, you have to learn how to use Git in order to use Git. But you don't have to use Git. Click here to renew your Visual Source Safe license, or better, just copy your file to file.1 every time you edit it. No way that can go wrong!

You say that, but the next version of Visual Studio's gonna have git built in. Seriously. Gonna be a lot of new (and probably confused) users out there.

It's already pretty close to being there; you only need to install a plugin now in order to get first class support in the IDE [0]. A few days ago, you would have had to install the VS2012 Update 2 CTP (hard to justify in a corporate environment in case bugs slow development), but now that it has gone RTM, there isn't much a barrier to entry besides awareness that the plugin exists.

[0] http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-...

Re: Die Git Die

#72

Post by glurgh »

stormbrew wrote: post #52
glurgh wrote: post #48

Earlier quoted context omitted.

>no matter how proud Torvalds is of the fact that he >never looked at another version control system for >inspiration What gave you that impression? Git was strongly influenced by BitKeeper and to a much lesser extent by Monotone. And, arguably, 'anti-inspired' by several other VCS's Linus would have surely been at least passingly familiar with.

There's a rather famous video of him talking about how wonderful his lack of experience with traditional VCS' was for producing git. Obviously he had used bitkeeper (but wasn't very fond of it), and he was probably exaggerating a bit even after that. I think most of the outside influence came from people who weren't Torvalds, but the command set is just so weirdly different from every other VCS (even where functional…

I haven't seen the video but generally he's been very complimentary of BK:

http://marc.info/?l=git&m=114685143200012 http://marc.info/?l=git&m=116129092117475

And two basic verbs 'pull' and 'push' are straight from BK.

My impression's been that the crazy command set is in part due to the early design idea that the basic commands represent primitives that operate on the fundamental git model on top of which something, potentially separate and more human-friendly will be built. Except it didn't quite work out that way.

Re: Die Git Die

#73

Post by cjh_ »

sjwright wrote: post #45
damncabbage wrote: post #21

Earlier quoted context omitted.

you list, move, rename and delete branches with branch, but create branches using checkout? Seriously??? git checkout -b new-branch ... is a shortcut for: git branch new-branch git checkout new-branch You can create the branch or otherwise manipulate it without actually checking it out, so it's useful to have it separate and have a shortcut. (I agree that git's interface is terrible, but I disagree that this is one o…

> but I disagree that this is one of those cases I do think this is precisely one of those cases. "Branch" is a major, repo-modifying operation; "checkout" is a trivial context switch operation. The user interface disaster here was that the major operation is treated as subservient to the trivial operation. It should be the other way around. Therefore, the shortcut for creating a branch and switching to it should be…

I don't understand how creating a branch is a major operation.

Creating a branch is non-destructive and cheap, tidying up after accidental creation is also easy.

Re: Die Git Die

#74

Post by cjh_ »

defen wrote: post #29

> However, git will not pull matching branches. That means that all your branches except your current branch will not get updated when you pull. > Of course, a less good but at least sane behavior would have been if pull also pulled matching branches by default I don't see any way this could work in the face of potentially having merge conflicts in non-current branches.

This is the reason pulling all matching branches (and pushing all matching branches) by default is generally a bad idea.

Re: Die Git Die

#75

Post by [deleted] »

glitchdout wrote: post #59
barumrho wrote: post #12

Earlier quoted context omitted.

From my experience, git pull origin branch didn't do what I expected. (Pulling from the remote branch to the current branch.) I haven't figured out what it does, so I just use git fetch then merge. :(

Git pull does a git fetch of the branch specified and then does a git merge into the current branch.

[deleted]

Re: Die Git Die

#76

Post by sjwright »

nessus42 wrote: post #64
johnny22 wrote: post #55

Earlier quoted context omitted.

branches aren't supposed to be "major". That's the major difference between a system like git and svn. branches are cheap. They are supposed to be used often and even be disposable.

Indeed. "git branch" is a lot like "mkdir". If you accidentally make a branch, deleting it with "git branch -d my-branch" is about as easy as typing "rmdir my-dir".

Nobody would argue that mkdir is a more major operation than cd. Which is my point.

Re: Die Git Die

#78

Post by stormbrew »

cjh_ wrote: post #68
pifflesnort wrote: post #44

Earlier quoted context omitted.

It still is a broken design that you can ever lose history or hose a repository in a tool that is designed to store history, forever. That's a sharp edge that should be exposed, and its not the only one in git.

Most of the time the information is not lost, and if you act quickly, it often just takes some git-reflog-foo to wrestle it out (or possibly as simple as looking at ORIG_HEAD, depending on how you 'lost' it). History not referenced will eventually be reaped by the garbage collector though.

Just to be clear here, since I think the combination of quickly and garbage collection is likely to create a wrong impression: quickly means days/weeks, not seconds.

Re: Die Git Die

#79

Post by knowtheory »

pifflesnort wrote: post #44
wonderzombie wrote: post #11

I'm not trying to argue that git is divinely inspired or whatever— this is confusing behavior. It tells me I can lose history, but this is a revision control system, surely they don't mean I can actually lose history? Sorry, but why did you think that they said that except to tell you that you could actually lose history? You ignored the rest of the error message and used --force. And then you were surprised that wha…

It still is a broken design that you can ever lose history or hose a repository in a tool that is designed to store history, forever. That's a sharp edge that should be exposed, and its not the only one in git.

You are making a mistake regarding how you think about git.

Git is not really a revision tracking system.

Git is a content tracking file system manager. It happens to be the case that these two uses largely overlap, but what Git really lets you do is take snapshots of your filesystem, annotate each snap shot, and allow you to compare snapshots.

It does not keep track of your changes. You keep track of your changes when you use git by annotating each snapshot.

Re: Die Git Die

#80

Post by cjh_ »

stormbrew wrote: post #78
cjh_ wrote: post #68

Earlier quoted context omitted.

Most of the time the information is not lost, and if you act quickly, it often just takes some git-reflog-foo to wrestle it out (or possibly as simple as looking at ORIG_HEAD, depending on how you 'lost' it). History not referenced will eventually be reaped by the garbage collector though.

Just to be clear here, since I think the combination of quickly and garbage collection is likely to create a wrong impression: quickly means days/weeks, not seconds.

Good point. It is setting dependent and the default is 2-3 weeks IIRC.
Post reply on HN