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

Git 2.0 release notes

git.kernel.org

Post reply on HN
Print view View original

71–80 of 93 posts

Re: Git 2.0 release notes

#71

Post by bronson »

marincounty wrote: post #38
anton_gogolev wrote: post #7

Is it just me or "simple semantics" is not at all simple? Compare with: hg push -- pushes everything to "default push location" hg push -r . -- pushes currently checked out branch hg push -r foo where -- pushes foo to where

No it's not you. It's overly complicated. This is what has always irked me about computing--making something seem more difficult than needed. I'm not asking for for an Apple solution, just cut the bull shit--high brow--If you don't know GIT you shouldn't be programming. It's a repository. I shouldn't need a git pocket guide. I want things fast and efficient. I don't like to spend daylight hours figuring out things; l…

Just curious, where is this highbrow "if you don't know GIT you shouldn't be programming" bullshit you speak of?

Re: Git 2.0 release notes

#72

Post by stefan_kendall3 »

penguindev wrote: post #66
stefan_kendall3 wrote: post #25

"git push -f" will no longer ruin days (as badly)

... due to force pushing multiple branches?

I've seen someone do it. If your workflow is 'git push -f feature' after rebasing, instead of 'git push feature -f', you can tap enter and break the world.

Re: Git 2.0 release notes

#74

Post by eslaught »

Is there any intention among the Git developers to ever make --recursive a default option for git clone? (This is an option that causes git clone to recursively clone any submodules as well as the top-level repo.)

Sure, arguably there are fundamental issues with submodules that you won't ever solve, and some people might prefer subtree to become the default. (I won't get into that argument here as there is another thread addressing that topic.)

But the fact still stands that a lot of the ugliness of submodules comes from the fact that the UI forces users to learn a whole extra set of commands, while the regular commands are largely oblivious to the existence of submodule. If I make a Git repo with submodules, I can't just pass a link to my Git-novice friends and have them clone it, because the UI for submodules is separate from the main Git UI. Arguably, for users who don't need to actually touch the submodule, the fact that the submodule is there should be invisible from the perspective of the UI. Although Git has been gradually getting closer to this being true, it is not currently the case (clone being an example of one command which is not aware of submodules by default).

Re: Git 2.0 release notes

#75

Post by recursive »

bronson wrote: post #71
marincounty wrote: post #38

Earlier quoted context omitted.

No it's not you. It's overly complicated. This is what has always irked me about computing--making something seem more difficult than needed. I'm not asking for for an Apple solution, just cut the bull shit--high brow--If you don't know GIT you shouldn't be programming. It's a repository. I shouldn't need a git pocket guide. I want things fast and efficient. I don't like to spend daylight hours figuring out things; l…

Just curious, where is this highbrow "if you don't know GIT you shouldn't be programming" bullshit you speak of?

Here's a similar one. https://news.ycombinator.com/item?id=7385563

Re: Git 2.0 release notes

#76

Post by nnethercote »

krig wrote: post #23
anton_gogolev wrote: post #7

Is it just me or "simple semantics" is not at all simple? Compare with: hg push -- pushes everything to "default push location" hg push -r . -- pushes currently checked out branch hg push -r foo where -- pushes foo to where

When you say "the currently checked out branch", do you mean the current branch, bookmark, head, local branch or mutable branch? Or maybe you are referring to the current phase, or a secret changeset? "Mercurial is so much simpler than git" is only true for one reason: You prefer mercurial and dislike git, and so you look for flaws in git while glossing over flaws in mercurial.

http://jordi.inversethought.com/blog/on-gitology/ is a good explanation of how git is overly complex.

Re: Git 2.0 release notes

#77

Post by doidydoidy »

lobster_johnson wrote: post #73

I like the "add" is more inclusive by default. But does this mean that "add -p" also can add untracked files? (If not, it seems inconsistent to me.)

Like it says in the man page, git add -p "effectively runs add --interactive, but bypasses the initial command menu and directly jumps to the patch subcommand". Interactive mode does support adding untracked files.

Re: Git 2.0 release notes

#78

Post by markmark »

glasser wrote: post #69
penguindev wrote: post #66

Earlier quoted context omitted.

... due to force pushing multiple branches?

Exactly. Doing that by mistake (and then being taught to set `push.default` to upstream or simple) has been a rite of passage for engineers at my company.

I never quite understood why the default was what it was. I can count the times I've wanted to push all branches at once on no hands. But maybe that's just my work flow.

Re: Git 2.0 release notes

#79

Post by lobster_johnson »

doidydoidy wrote: post #77
lobster_johnson wrote: post #73

I like the "add" is more inclusive by default. But does this mean that "add -p" also can add untracked files? (If not, it seems inconsistent to me.)

Like it says in the man page, git add -p "effectively runs add --interactive, but bypasses the initial command menu and directly jumps to the patch subcommand". Interactive mode does support adding untracked files.

Not what I'm asking. "add -p" will offer deletions, but it should also offer to add untracked files, essentially showing a diff with all lines added (with an empty file as the base).

"add -p --all some_untracked_file" does nothing, "--interactive" does something completely different; a menu system, not a "yes/no/etc." patch prompt.

Re: Git 2.0 release notes

#80

Post by acchow »

stefan_kendall3 wrote: post #25

"git push -f" will no longer ruin days (as badly)

Possibly the most confusing default in git. My gitconfig has:

  [push]
    config = default
        default = tracking
I once made a virtual machine and didn't pull in my usual .gitconfig. It ruined my day.
Post reply on HN