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

61–70 of 100 posts

Re: Die Git Die

#61

Post by LeonidasXIV »

Rarebox wrote: post #34
kansface wrote: post #9

Earlier quoted context omitted.

git has no user interface. git expects its users to have an in depth understanding of its implementation details. These are failures of git. Ideally, studying abstruse man pages to avert disaster wouldn't be required of new users.

Git interface is hard, because git is hard. Git is hard because it is so powerful. Git developers don't care about newbie users who can't even bother to RTFM. There is just no reason they should. Git user interface is fine when you finally learn how to use git.

A browser is hard. Firefox is easy.

I don't think your reasoning holds. That's why we have abstractions, to make hard things easy.

Re: Die Git Die

#62

Post by bumeye »

harshreality wrote: post #57

Code section 3: why create a new clone of the repo when all he needed was to create a new branch and modify that? Code section 5 and 6 are apparently modifying the code branch, and the pages branch, respectively, but doing so in separate local clones of the repo. I think there's a typo in code section 6, where I think he meant to start with cd ../die-git-die.pages This doesn't seem like a situation where multiple loc…

This is the way that github recommends (https://help.github.com/articles/creating-project-pages-manu...).

A separate folder for the gh-pages branch makes sense because this branch has nothing in common with any of the other branches. It doesn't share any code or commits with your master branch.

The repository actually has two base commits and it's like two repositories contained in one. Thus needing two separate folders.

Re: Die Git Die

#63

Post by jrdn »

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.

I really, really want to be able to lose some history sometimes. Like if someone checks in sensitive user data by accident. Rolling it back is insufficient, I want that expunged. Maybe git doesn't do it perfectly, but it has reason to do it.

Re: Die Git Die

#64

Post by nessus42 »

johnny22 wrote: post #55
sjwright wrote: post #45

Earlier quoted context omitted.

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

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

Re: Die Git Die

#65

Post by nessus42 »

skybrian wrote: post #46
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…

Except, why isn't it "git branch --nocheckout" for the rare cases when you don't want to check out?

Why doesn't "mkdir" cd you into the new subdir unless you type "mkdir --no-cd my-dir"?

Re: Die Git Die

#66

Post by 178 »

He is using a hack to store the GitHub pages. That this is even possible is due to the awesomeness of git. Since it is a hack, you have to be careful what you're doing. He should have done all the gh-pages stuff in a separate clone. The GitHub instructions where he pasted the branch creation commands from also tells you to do just that. Keep the pages branch in a clone of the repo inside the repo, just in a folder called 'docs'. You'll never have to mess with these branches, as you can generate docs, commit and push from a Makefile.

Re: Die Git Die

#67

Post by jhaglund »

niggler wrote: post #30
jhaglund wrote: post #26

Earlier quoted context omitted.

Git doesn't have much of a user interface because it's target is developers who want to use the command line. Git is confusing until it's not, and then it's awesome. It's kinda like you're using wget to surf the web, and complaining that it doesn't have a GUI. http://git-scm.com/downloads/guis

GUI != UI parent comment is arguing that the command-line interface is nontrivial, which is a fair criticism. Contrast with 'cp' or 'mv'

Well, go right ahead and use cp and mv for your source control!

No one (except maybe linus) ever said git is easy. But it is flexible and powerful.

Anyway, this whole thing comes down to the user ignoring clear warnings. It seems clear to me that using "force" can break things.

Re: Die Git Die

#68

Post by cjh_ »

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.

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.

Re: Die Git Die

#69

Post by peff »

I notice that he omits the full output of `git push`. A lot of the confusion is caused by the fact that the default push mode is `matching`. I don't know what git version he is running, so I can't say exactly what text was omitted, but I would have expected to see two things:

1. Not only mention of the rejected `master` branch, but also the successful push of the `gh-pages` branch. Which makes it a lot more clear that git is trying to push multiple branches, and that the rejection has to do with `master` and not `gh-pages`.

2. The push default of `matching` is changing soon in upstream git (because it is suitable for certain types of workflow, but can cause confusion, as seen here), and the last several versions complain loudly if you do not set the default. This is intended to call attention to this common pitfall, and to notify users so that they are not surprised by the change when it happens.

With git v1.8.2, here is the full output of `git push` in his situation (you may note that the non-fast-forward advice has been improved, too):

  $ git push
  warning: push.default is unset; its implicit value is changing in
  Git 2.0 from 'matching' to 'simple'. To squelch this message
  and maintain the current behavior after the default changes, use:
  
    git config --global push.default matching
  
  To squelch this message and adopt the new behavior now, use:
  
    git config --global push.default simple
  
  See 'git help config' and search for 'push.default' for further information.
  (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
  'current' instead of 'simple' if you sometimes use older versions of Git)
  
  Counting objects: 8, done.
  Delta compression using up to 8 threads.
  Compressing objects: 100% (2/2), done.
  Writing objects: 100% (6/6), 428 bytes, done.
  Total 6 (delta 0), reused 0 (delta 0)
  To /home/peff/foo/die-git-die/parent.git
     148db6f..25cd4ef  pages -> pages
   ! [rejected]        master -> master (fetch first)
  error: failed to push some refs to '/home/peff/foo/die-git-die/parent.git'
  hint: Updates were rejected because the remote contains work that you do
  hint: not have locally. This is usually caused by another repository pushing
  hint: to the same ref. You may want to first merge the remote changes (e.g.,
  hint: 'git pull') before pushing again.
  hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Re: Die Git Die

#70

Post by cjh_ »

stormbrew wrote: post #54
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.

To be fair, I don't think even in the scenario in question the history is truly lost. It'll still be in the reflog at least.

Mistakes like this happen often, being able to purposefully delete history (at least as far as the remote is concerned) is a very important feature of a VCS.
Post reply on HN