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

51–60 of 93 posts

Re: Git 2.0 release notes

#51

Post by ingy »

aktau wrote: post #3
stormbrew wrote: post #2

I like a lot of these things for sure. The only thing that I really wish they'd do that I've seen no sign they plan to is move git-subtree from contrib into the main distribution. It's such a useful thing.

I agree! Overall I truly prefer git subtree over submodules. I've noticed that most devs seem to have strong opinions one way or another. Perhaps git subtree just seems so good because submodules are so clunky. If only someone would invent a "best of both worlds".

You may want to take a look at https://github.com/ingydotnet/git-subrepo#readme (and join #git-commands on freenode).

Re: Git 2.0 release notes

#52

Post by sanderjd »

bru wrote: post #6
aktau wrote: post #3

Earlier quoted context omitted.

I agree! Overall I truly prefer git subtree over submodules. I've noticed that most devs seem to have strong opinions one way or another. Perhaps git subtree just seems so good because submodules are so clunky. If only someone would invent a "best of both worlds".

>I've noticed that most devs seem to have strong opinions one way or another. I've personally noticed that most devs don't have an opinion either way since they don't use subtrees nor submodules. I don't know what subtrees offer but using submodules has been very pleasant once you know how they work. For example if you version control your .vim I think that adding submodules for extensions is way better than cloning…

Subtrees interact with history in a much more obvious, configurable, and automatic way. The most obvious win is never having to run `git submodule update`. The better control over history is the bigger, but less obvious win. Since you have some experience using submodules for your .vim, maybe try switching to subtrees and see what you think. I like the Atlassian blog post[0] about them for getting started.

[0]: http://blogs.atlassian.com/2013/05/alternatives-to-git-submo...

Re: Git 2.0 release notes

#53

Post by krig »

egork8n wrote: post #26
krig wrote: post #23

Earlier quoted context omitted.

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.

You just need to visualize the tree, and that's it. `hg push -r .` will push checked out changeset and all its ancestors. Mercurial tracks changesets. Git guys are inventing all kings of weird entities. Local branch? Mutable branch? Do these kind of things have separate sets of semantics in the git world? In mercurial, branch is just a constant name for a group of changesets. Bookmark is just a temporary pointer to t…

I think you misunderstood. These "weird entities" that I mention are all part of mercurial. I feel like many of the people who complain that git is too complicated and hold up mercurial as a bastion of simplicity don't really know either of them.

To quote my other comment:

* Branches (named and unnamed) are part of core mercurial.

* Bookmarks are part of core mercurial.

* Multiple heads are part of core mercurial.

* Phases are part of core mercurial.

* Secret changesets is part of core mercurial.

* mq is distributed with Mercurial.

* Local branches is an extension that isn't part of core mercurial, I'll give you that. However, calling it a "third-party extension" is pedantic. It's listed on the official mercurial web site, and using extensions is much more a part of every day usage of mercurial than using extensions in git, for example.

Re: Git 2.0 release notes

#54

Post by VeejayRampay »

exDM69 wrote: post #19
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

> Is it just me or "simple semantics" is not at all simple? It's just you. It's about time we'd put "hg vs. git" to the category of flamebait topics (similar to "emacs vs. vi" etc) that should be avoided. Every time there's a git topic, someone comes and derails the whole discussion with a not-quite-apt comparison with hg. AFAIK, there are decent two-way conversion tools so you can use hg with a git repo and vice ver…

Also, hasn't git won already? I mean, I'm sure Mercurial is a great tool and all, but git is massive and widespread now, there's no going back and sharing of the pie until a new generation of VCS that completely changes the game emerges I think.

Re: Git 2.0 release notes

#55

Post by rip747 »

stormbrew wrote: post #2

I like a lot of these things for sure. The only thing that I really wish they'd do that I've seen no sign they plan to is move git-subtree from contrib into the main distribution. It's such a useful thing.

how close is git-subtree to svn-externals? I've always had people complain about moving from svn to git because there wasn't a feature like svn-externals. git-submodules obviously didn't cut it.

Re: Git 2.0 release notes

#56

Post by TheHippo »

rip747 wrote: post #55
stormbrew wrote: post #2

I like a lot of these things for sure. The only thing that I really wish they'd do that I've seen no sign they plan to is move git-subtree from contrib into the main distribution. It's such a useful thing.

how close is git-subtree to svn-externals? I've always had people complain about moving from svn to git because there wasn't a feature like svn-externals. git-submodules obviously didn't cut it.

In my opinion it's way better then submodule or svn-externals. Basically it allows you to take an specific folder from your repository and push only this folder to an additional repository. This repository could be included into another repository which makes sharing code between repositories very easy while keeping history in each of them and the history for this special folder in an extra repository.

Re: Git 2.0 release notes

#57

Post by Crito »

giulianob wrote: post #36
krig wrote: post #29

Earlier quoted context omitted.

Those are all Mercurial concepts.

Not all Git concepts exist in Mercurial. See more here: http://mercurial.selenic.com/wiki/GitConcepts

He's not saying that they are Git concepts that have analogs in Mercurial. He just listed off Mercurial concepts.

Re: Git 2.0 release notes

#58

Post by Skinney »

sampo wrote: post #43
Skinney wrote: post #31

Earlier quoted context omitted.

All branches can change, and are mutable in that regard (altough commits can't change). Local branch == Bookmark with unpushed changesets All branches and commits/changesets are treated equal. Yeah. In mercurial you have Branches and Bookmarks. In git you just have branches. Head is the current checked out commit/changeset. Git doesn't allow you to alter commits, only branches, so every modification in Git is inheren…

> In mercurial you have Branches and Bookmarks. In git you just have branches. I think git branches correspond more to hg bookmarks, than to hg named branches.

Isn't the only real difference that hg branches are constant, while bookmarks are temporary?

Re: Git 2.0 release notes

#60

Post by aktau »

ingy wrote: post #51
aktau wrote: post #3

Earlier quoted context omitted.

I agree! Overall I truly prefer git subtree over submodules. I've noticed that most devs seem to have strong opinions one way or another. Perhaps git subtree just seems so good because submodules are so clunky. If only someone would invent a "best of both worlds".

You may want to take a look at https://github.com/ingydotnet/git-subrepo#readme (and join #git-commands on freenode).

Wow, from glancing at the description it sounds really good. I hope you guys can pull it off! Something like this would be almost as "freeing" to me as starting to use git in the first place was.
Post reply on HN