
Git 2.0 - pantalaimon
http://lkml.iu.edu/hypermail/linux/kernel/1405.3/02592.html
======
ultimoo
I find git's growth and adoption remarkable. It was only 5 years ago that as a
young programmer I was first exposed to git and the concept of version
control. I remember that every other team I knew at my organization was using
svn and no one really understood how git could improve their workflow or how
it worked and what it brought to the table.

Now that I look around, almost everyone in the programming world _(at least
the part I 'm exposed to)_ is familiar with git as a version control software
and github as a social-coding/code-hosting site.

~~~
jasonkester
I've been using git (and GitHub) at my day job for a couple years now, and I'm
still not sure I'm sold on it over Subversion.

In the past, version control was something that existed but you never had to
think about. When you got to a good place, you'd hit the big red Save Button
and up your code would go. Once in a blue moon you'd step on somebody's
changes and have to do a quick merge. No big deal.

Now with Git, version control is part of the workflow. It's never far from
your mind. You're creating branches _before_ writing code (versus creating
branches three times a year when you needed them). You're doing silly
housekeeping tasks like reverting a change that you accidentally checked in to
the main branch then branching and copy/pasting your changes back into the IDE
just so that the source control system (and possibly some ops overlord
somewhere) doesn't get mad at you.

I'm sure there are times where Git has actually made things easier, but most
of the time it's just one extra thing taking up my attention.

It's like timesheets for your code. Not a big deal, but ever so slightly
insulting that you have to deal with them.

~~~
anko
What the heck? I couldn't disagree more.

You don't have to create a branch before you write some code. Write the code,
and if you think it should go on a different branch, type "git checkout -b
'branchname'". But if you don't want to, you don't have to! work on master for
all anyone cares. Branches just help you! IF they are too hard, don't use
them.

Branches were so problematic in subversion that nobody did them. In git, if
you want to, then do it.

If you accidently check in something, just "git rm" it. You have this extra
staging area.

If you are finding there is something problematic with your workflow, take the
time to look up how to do it, and you'll find that the fix is a command away.
You should never be copying/pasting stuff back into your IDE. If you are,
you're doing it wrong.

[http://gitref.org/](http://gitref.org/) is pretty good if you get stuck.

~~~
craigching
I agree with you, and would like to add to it. The parent said git gets in the
way ... I couldn't disagree more with that. More than any other version
control software, git stays out of my way and my workflow _until I need it_.
Rename a file? No big deal, take care of it before I commit, for now rename it
and keep working. Need these changes to go on a branch? As you said, "git
checkout -b <branchname>" and BAM! I'm on a branch (most unlike SVN
branching). Contrast that with something like perforce (and I know the parent
was comparing to SVN) where it intrudes into my workflow whether I want it to
or not. p4 edit? pshaw! I have been using the "git p4" module for a few years
now in my corporate p4 environment. It ain't native git, but it's better than
p4 IMO.

EDIT: Come on. If you disagree with me, don't downvote, reply so you can
contribute to the conversation. Coward.

------
justinmk
> "git rebase" learned to interpret a lone "-" as "@{-1}", the branch that we
> were previously on.

Cool, I was just looking for something like this with "git merge". Turns out
"git merge" already supports it, and I need to get better at using the reflog
(@{...}).

> "git add <path>" is the same as "git add -A <path>" now.

> The "-q" option to "git diff-files", which does _NOT_ mean "quiet", has been
> removed

More intuitive.

> The bitmap-index feature from JGit has been ported, which should
> significantly improve performance when serving objects from a repository
> that uses it.

Improves clone performance if you're pulling lots of history, but there still
doesn't seem to be a way to sparse-checkout without fetching the entire .git
repo.

~~~
jackyb
Use "git clone --depth [depth] [remote-url]"?

~~~
justinmk
Even with depth=1 it still pulls the .git/ blobs for the entire repo. The use
case is: only want a subdirectory, and only want the repo/history objects for
that subdirectory.

------
dj-wonk
I can't tell if Git, the project itself, uses semantic versioning. Is 2.0
considered a major (backwards-compatibility-breaking) release?

~~~
goldfeld
Off the top of my head, I'd say it has breaking changes such as changing
push.default's default setting to only your current branch, as opposed to
pushing all branches when you do a 'git push'. Git cli has been warning me of
this change for a while where I didn't have a configured push.default, so I'll
assume this is as 'breaking' as it gets.

------
ww520
Is there a summary for the new features in 2.0?

One feature I really hope git to add is an _easy_ way to clean up deleted
files in the repository. Some times I accidentally check in some large zip
files or built files and that really blows up the repository size. Those files
stay in there even if I've deleted them. It's a pain to clean them up.

~~~
beaumartinez
There is, in the linked article.

~~~
stouset
Not to mention, the requested feature already exists in git, and has for
years.

~~~
ww520
Can you elaborate what the command is? I would be really happy to learn about
it. I know the complicate way to do it. Just want an easier way to do it,
rather than multiple steps.

Here are the steps I know of to get rid of big blobs. Long and complicate. Is
there a better way?

    
    
      - Find out size of the big blobs and their HASH.
        git verify-pack -v .git\objects\pack\pack-HASH.idx | sort -k3n
    
      - Find out the name of a blob hash to verify the blob is the one to delete.
        git ls-tree -r HEAD | grep HASH
        git ls-tree -r COMMIT_HASH | grep HASH
        git log --all --raw --no-abbrev | grep HASH
    
      - Expire all working reflog now, and then prune deleted blob
        git reflog expire --expire=all
        git gc --prune=now
    
      - Remove a blob.
        git push -force
        git filter-branch --index-filter 'git rm --cached *.zip --ignore-unmatch ' HEAD
        git filter-branch --index-filter 'git rm --cached *.zip --ignore-unmatch ' --prune-empty -- --all
        git filter-branch --index-filter 'git update-index --remove webapp.zip' <introduction-revision-sha1>..HEAD
        git filter-branch --index-filter 'git update-index --remove webapp.zip' HASH..HEAD
    
      - Clean up reflogs.
        rm -Rf .git/refs/original
        git reflog expire --expire=now --all
        git gc --aggressive
        git prune

~~~
ninkendo
You already seem to know about filter-branch, but:

    
    
        git filter-branch --tree-filter 'rm -f path/to/bigfile.zip'
    

is one command.

~~~
yebyen
Thanks! I would have tried to muddle through with rebase.

It may be obvious that this solution is also going to cause the same issue as
with rebasing, but just in case, from the man page for filter-branch:

WARNING! The rewritten history will have different object names for all the
objects and will not converge with the original branch. You will not be able
to easily push and distribute the rewritten branch on top of the original
branch. Please do not use this command if you do not know the full
implications, and avoid using it anyway, if a simple single commit would
suffice to fix your problem. (See the "RECOVERING FROM UPSTREAM REBASE"
section in git-rebase(1) for further information about rewriting published
history.)

------
joemaller1
So I'm excited this is finally here. But I'm also terrified. You go first.

~~~
kzrdude
The changes feel extremely conservative. That's ok, but it's not exactly
"exciting" nor is it scary.

~~~
rdtsc
That is my impression. There are some changes, but I can see how this could
have been a 1.10.0 release as well.

~~~
dj-wonk
Git's release numbering scheme (if there is any 'system' to it) is mysterious
to me.

~~~
roryokane
I think they increased the major version number because they did break
backwards compatibility for a few things – the biggest of which is the default
`git push` behavior. Relatively small breakages, but this upgrade is probably
the only time they are allowing such changes.

------
zobzu
I wanted the auto gpg sign for a while. I wonder if itll get more adoption.

------
jc123
Git is remarkably deep in its functionality that its possible to learn
something new about it on a weekly or even daily basis: if you have the time.
Whenever you are trying to manipulate code, there is usually a clean way of
doing it in git if one takes the time to master its power. Next time you have
such a problem, if you have the time, take the opportunity and you'll probably
pleased at learning something new instead of using what you currently know
about git plus a workaround or two.

------
yeukhon
For me the amazing thing about writing VCS is that a subtle bug or change
could destroy someone's history and future commits. For example, in some old
Mercurial release, _hg mv_ had a bug (something affects history integrity) and
the bug is fixed in recent release (the default version install on Ubuntu
12.04 should see that bug).

Maybe I lack of the domain knowledge, but writing VCS must be a very difficult
task if you care about preserving history.

~~~
sjwright
No, it won't, because you keep your workstation backed up. You do keep a
backup, right?

~~~
Walkman
If you backup a git repository, that would be the same than making backup from
a backup. How far would you go? :D Git repo itself is a backup!

~~~
_ikke_
No, your git repository is _not_ a backup. It's a record of the history of
your project, but it's not sufficient as a backup.

You could see pushing as making a backup, but even that wouldn't backup the
exact state of your repository (private branches, configuration, reflog,
rerere, etc..).

If an object gets corrupt, it's almost impossible to fix it, unless you have a
copy of that object somewhere.

That's why it's still important to make backups of your repository.

~~~
Walkman
I disagree. Even if you are a couple of commits behind, and you totally
screwed, you should be able to recreate it from top of your head. maybe a
couple of local git hooks, but still, if you pushed, the most important work
should be available somewhere else and you can pull it.

------
spb
How common is this style of describing changes to parts of code as "teach" and
"learn"? I like it.

------
_RPM
I'm about to graduate with CS degree, and my first question to potential
employers is going to be "Do you use source control, and is it Git?"

~~~
hueving
And what is your follow-up when they say they don't because they need more
centralized control/auditing due to the sensitivity of their work?

~~~
vidarh
"Bye."

Given that nothing stops you from running a centralized Git repo for things
that are candidates for audits or release. If someone uses that as their
reason for not switching to Git, it indicates to me that they don't understand
their requirements and/or is using it as an excuse because they don't have any
real reasons.

I'd even argue that if you want more control and auditing, Git is an
_improvement_ over alternatives like Subversion, because it makes it more
manageable (and so more likely to actually happen) to set up workflows with
far more frequent commits and subsequent reviews by a gatekeeper. You don't
need to let your lower level developers even have any kind of access to the
main repository, yet you can retain full history of changes that happens
before their code is approved and pushed to the main repo by a suitably
anointed person.

~~~
hueving
If you're using a gate keeping process, it doesn't matter what the committers
even use then. They can just push a patch to the gate keeper.

You sound pretty close-minded and relatively inexperienced if you would turn
down a great career because they used something other than git. It's
borderline idiotic to make such a large decision based on something
inconsequential. Maybe that's okay in the Web app industry where most of the
jobs are just variants of the same thing so you have plenty to filter through,
but the idea of turning down a job at somewhere you've been hoping to work
like NASA or Google just because they don't use a tool you like is one of the
dumbest things I've heard in a long time.

