
Git 2.0 release notes - redox_
https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes/2.0.0.txt
======
stormbrew
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.

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

~~~
bru
>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 them
inside your .vim.

I look forward to having the opportunity to use subtrees.

~~~
sanderjd
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...](http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-
git-subtree/)

~~~
bronson
For me the the most obvious win is still being able to merge, move forward in
time, move backward in time, rebase, etc. Everything that makes Git great.

Once you have submodules in your repo, all that becomes heinous. PLUS
everything you mentioned...

Sure, if you don't use those features, then submodules would probably work
fine. But then why not just use Dropbox?

~~~
sanderjd
Yep, I think a good way to put it is that subtrees are (or feel like) far more
"first class" \- you can do all the normal stuff with them.

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

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

~~~
krig
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.

~~~
egork8n
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 the changeset. Head is a changeset
(that have no successors). Phase is information about whether it is safe to
modify changeset. Mercurial is indeed a lot simpler.

~~~
Skinney
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
inherently safe.

~~~
jgraham
Also, mercurial has mq, which adds a whole extra layer of complexity. Instead
of making safe commits, you continually update ("refresh") a set of patch
files. Each time you refresh you lose all the history (as if you exclusively
used git commit --amend for work in progress). In order to solve this someone
got the idea that the patch queue itself could be versioned by creating a
second repository that you would commit each revision of the patches to.
Unsurprisingly it turns out that two repos are not better than one and doing
"simple" things (moving a patch queue between two clones of the same remote)
requires fiddly manual operations.

Mercurial has some neat features, but this idea that it's always easy to use
and git is always hard to use simply isn't true.

~~~
ygra
To be fair, mq is needed only for very few specialised needs (apart from
strip, maybe). Most hg users can get by just fine with never enabling it at
all.

~~~
acdha
For years the Hg community proclaimed it was the answer to git rebase. Might
be time for a concerted doc push to get those references updated with pointers
to the rebase extension instead.

~~~
kyrra
Because it was the answer originally (it's wiki page appeared in 2005, rebase
appeared in 2008). Then rebase became the better answer. What proclaimed
answer are you referring to here? On their GitConcepts[0] page, it says "hg
rebase" or "hg histedit" should be used to do "git rebase" type operations.
The only time they recommend MQ is if you want the index or the "git am" type
command.

And as anton_gogolev mentioned, ChangesetEvolution[1] will probably help
augment HistEdit and Rebase for a number of operations. It will allow pushable
history rewriting.

[0]
[http://mercurial.selenic.com/wiki/GitConcepts](http://mercurial.selenic.com/wiki/GitConcepts)

[1]
[http://mercurial.selenic.com/wiki/ChangesetEvolution](http://mercurial.selenic.com/wiki/ChangesetEvolution)

~~~
acdha
> What proclaimed answer are you referring to here?

You answered that in your first paragraph: for many years, the first time
people looked at Mercurial the answer for that class of problems was mq. The
problem now is that it's still easy to find stale internal documentation, old
blog posts, etc. which haven't been updated with the new recommendations. I
thought that it might be worth having a small campaign to encourage people to
update old wikis, contact blog authors, etc. when they find those
recommendations and suggest a simple “this is no longer recommended – see …”
update.

------
rplnt
Is this released already or are those just preliminary release notes?

~~~
chiefsucker
The current version is still 1.9, but it shouldn’t take long for 2.0 to be the
official stable release.

------
nbouscal
Minor feature that's really nice: the pull.ff config setting. I had made an
alias for doing that manually, now I can start actually using git pull again.

~~~
Aissen
Haha, me too, my lovely "git pfo" will have to go… Maybe.

The problem with git is that new options aren't simply ignored by old git
versions, meaning that if you synchronize your gitconfig as part of your
dotfiles, then the machines that have old git versions will start spitting
error messages at every command for options specific to new versions. I
learned that painfully with push.default=simple.

~~~
davvid
For `push.default`, older versions understood `push.default` but only later
was the `simple` mode added.

For `pull.ff`, old versions will simply ignore the setting. I know because I
wrote the patch ;-)

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

~~~
penguindev
... due to force pushing _multiple_ branches?

~~~
stefan_kendall3
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.

~~~
penguindev
It really blows my mind that you say those two aren't equivalent. I now must
read the man pages...

Edit did you mean to say (plus)feature or is something ruining the formatting?
That seems to be how to specify only one branch. Yuck.

I'm lucky I haven't run into this, I guess, because I set my push default to
simple a long time ago, so long ago I can't even remember why.

~~~
stefan_kendall3
The two are equivalent if you type them in full, but if you stop one before
typing the feature branch name, you've broken everything.

git push -f (enter) => Death to all branches. git push feature -f => Can only
ever force push the feature branch

No matter when you press enter in the second line, intentionally or
accidentally, you can't break all branches.

~~~
penguindev
Ah, I see. Thanks for clarifying.

------
lobster_johnson
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.)

~~~
doidydoidy
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.

~~~
lobster_johnson
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.

