13 ms·

Git 2.0

405 points by pantalaimon 12y ago

joemaller1 12y ago
So I'm excited this is finally here. But I'm also terrified. You go first.
- kzrdude 12y ago
  The changes feel extremely conservative. That's ok, but it's not exactly "exciting" nor is it scary.
  - rdtsc 12y ago
    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 12y ago
      Git's release numbering scheme (if there is any 'system' to it) is mysterious to me.
      - roryokane 12y ago
        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.
  - mrnil 12y ago
    Yes, Git is maintained very conservative and a lot of effort is put into review and testing even before patches hit the 'pu' or 'next' branch (Git's staging branches), where they usually cook for some time before getting merged (if at all). I even use pu on my work machine to be able to test and use the latest features and never had a serious problem.
zobzu 12y ago
I wanted the auto gpg sign for a while. I wonder if itll get more adoption.
ultimoo 12y ago
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.
- joeblau 12y ago
  Yeah, I just picked up git about 3 years ago and I probably wouldn't even take a job if they were using one of the other DVCSs.
  - delive 12y ago
    I've been using git-svn for workflow the past 2 years or so. It's not perfect, but it seems to cover all the use cases I've had and integrates well with the regular svn workflow.
  - eddieroger 12y ago
    I really hope you're being sarcastic. If you're turning a job down because of the VCS, hopefully you've got a surplus of work to choose from.
    - zbowling 12y ago
      engineers do in the bay area.
      - balls187 12y ago
        and in seattle
    - zellyn 12y ago
      I understand the sentiment: the fact that a company uses Visual Sourcesafe, or ClearCase, or something else terrible tells you a lot about their culture.
ww520 12y ago
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 12y ago
  There is, in the linked article.
  - yebyen 12y ago
    There is a summary, you mean. At first I thought you were saying, there is that feature there. The summary reads like the git manpage -- a new mode, scissors, huh? This was probably complicated by the fact I thought you were saying "the feature is there, go RTFM." This is not a regular feature of Git and I think architecturally it's the wrong idea. You want to delete objects, you better go learn rebase, and be prepared to piss off anyone who already has a clone since you're going to have to break fast-forwarding.
  - stouset 12y ago
    Not to mention, the requested feature already exists in git, and has for years.
    - ww520 12y ago
      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
yeukhon 12y ago
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.
- ams6110 12y ago
  Nothing unique about VCS. A subtle bug in a word processor has the potential to destroy someone's manuscript. A subtle bug in a payment processing system has the potential to expose a million credit card numbers. This is the nature of software.
- sjwright 12y ago
  No, it won't, because you keep your workstation backed up. You do keep a backup, right?
  - Walkman 12y ago
    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!
    - sjwright 12y ago
      That's assuming you routinely push all your changes and branches -- without exception -- to a server. Of course you can always pull from elsewhere to grab a copy of the repo, but that's no excuse for not backing up your local environment.
    - _ikke_ 12y ago
      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.
justinmk 12y ago
> "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.
- wfn 12y ago
  > but there still doesn't seem to be a way to sparse-checkout without fetching the entire .git repo. I'm not entirely sure if this is what you want, but sparse-checkouting only parts of the repo is possible: http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/ http://jasonkarns.com/blog/subdirectory-checkouts-with-git-s... For cloning a particular branch, there's also (since 1.7.10) git clone -b your_branch_name --single-branch git://some.remote/repo.git
- jackyb 12y ago
  Use "git clone --depth [depth] [remote-url]"?
  - justinmk 12y ago
    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 12y ago
I can't tell if Git, the project itself, uses semantic versioning. Is 2.0 considered a major (backwards-compatibility-breaking) release?
- goldfeld 12y ago
  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.
- erikb 12y ago
  Yes, that's exactly what it's saying. I'm really, really happy that these versioning schemes become more popular and that people really start to read something into it. In my company people's opinion about Git2.0 is strongly split. Some people understand an increase of the major to have API changes, while the others didn't know about this versioning scheme and got a lot of unexpected problems.
_RPM 12y ago
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?"
- burkaman 12y ago
  I would try not to judge companies like that. I had an internship at a place that was consistently rated the best place to work in the area, interesting work, great development environment, etc., but they used this source control product called AccuRev. It was this slow GUI-based thing with it's own unique vocabulary, nobody really liked it, but it was still a great place to work. If they don't use source control at all, that's obviously a problem, but don't discount a company just because they don't use your favorite software.
  - a_c_s 12y ago
    Excellent advice - the converse is true too: just because a company uses the right tools doesn't mean that the company doesn't have a toxic corporate culture that makes it a terrible place to work.
- hueving 12y ago
  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?
  - _RPM 12y ago
    As long as I don't have to use a windows GUI, and can use the terminal to commit changes, then I could be in.
  - ZeroGravitas 12y ago
    "Why do you need to control/audit all work done locally rather than what is pushed to your main git repository, and how can you realistically enforce that with any tool?"
jc123 12y ago
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.
spb 12y ago
How common is this style of describing changes to parts of code as "teach" and "learn"? I like it.

Git 2.0

405 points by pantalaimon 12y ago

joemaller1 12y ago

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

kzrdude 12y ago
The changes feel extremely conservative. That's ok, but it's not exactly "exciting" nor is it scary.
- rdtsc 12y ago
  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 12y ago
    Git's release numbering scheme (if there is any 'system' to it) is mysterious to me.
    - roryokane 12y ago
      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.
- mrnil 12y ago
  Yes, Git is maintained very conservative and a lot of effort is put into review and testing even before patches hit the 'pu' or 'next' branch (Git's staging branches), where they usually cook for some time before getting merged (if at all). I even use pu on my work machine to be able to test and use the latest features and never had a serious problem.

zobzu 12y ago

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

ultimoo 12y ago

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.

joeblau 12y ago
Yeah, I just picked up git about 3 years ago and I probably wouldn't even take a job if they were using one of the other DVCSs.
- delive 12y ago
  I've been using git-svn for workflow the past 2 years or so. It's not perfect, but it seems to cover all the use cases I've had and integrates well with the regular svn workflow.
- eddieroger 12y ago
  I really hope you're being sarcastic. If you're turning a job down because of the VCS, hopefully you've got a surplus of work to choose from.
  - zbowling 12y ago
    engineers do in the bay area.
    - balls187 12y ago
      and in seattle
  - zellyn 12y ago
    I understand the sentiment: the fact that a company uses Visual Sourcesafe, or ClearCase, or something else terrible tells you a lot about their culture.

ww520 12y ago

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 12y ago
There is, in the linked article.
- yebyen 12y ago
  There is a summary, you mean. At first I thought you were saying, there is that feature there. The summary reads like the git manpage -- a new mode, scissors, huh? This was probably complicated by the fact I thought you were saying "the feature is there, go RTFM." This is not a regular feature of Git and I think architecturally it's the wrong idea. You want to delete objects, you better go learn rebase, and be prepared to piss off anyone who already has a clone since you're going to have to break fast-forwarding.
- stouset 12y ago
  Not to mention, the requested feature already exists in git, and has for years.
  - ww520 12y ago
    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

yeukhon 12y ago

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.

ams6110 12y ago
Nothing unique about VCS. A subtle bug in a word processor has the potential to destroy someone's manuscript. A subtle bug in a payment processing system has the potential to expose a million credit card numbers. This is the nature of software.
sjwright 12y ago
No, it won't, because you keep your workstation backed up. You do keep a backup, right?
- Walkman 12y ago
  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!
  - sjwright 12y ago
    That's assuming you routinely push all your changes and branches -- without exception -- to a server. Of course you can always pull from elsewhere to grab a copy of the repo, but that's no excuse for not backing up your local environment.
  - _ikke_ 12y ago
    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.

justinmk 12y ago

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

wfn 12y ago
> but there still doesn't seem to be a way to sparse-checkout without fetching the entire .git repo. I'm not entirely sure if this is what you want, but sparse-checkouting only parts of the repo is possible: http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/ http://jasonkarns.com/blog/subdirectory-checkouts-with-git-s... For cloning a particular branch, there's also (since 1.7.10) git clone -b your_branch_name --single-branch git://some.remote/repo.git
jackyb 12y ago
Use "git clone --depth [depth] [remote-url]"?
- justinmk 12y ago
  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 12y ago

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

goldfeld 12y ago
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.
erikb 12y ago
Yes, that's exactly what it's saying. I'm really, really happy that these versioning schemes become more popular and that people really start to read something into it. In my company people's opinion about Git2.0 is strongly split. Some people understand an increase of the major to have API changes, while the others didn't know about this versioning scheme and got a lot of unexpected problems.

_RPM 12y ago

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

burkaman 12y ago
I would try not to judge companies like that. I had an internship at a place that was consistently rated the best place to work in the area, interesting work, great development environment, etc., but they used this source control product called AccuRev. It was this slow GUI-based thing with it's own unique vocabulary, nobody really liked it, but it was still a great place to work. If they don't use source control at all, that's obviously a problem, but don't discount a company just because they don't use your favorite software.
- a_c_s 12y ago
  Excellent advice - the converse is true too: just because a company uses the right tools doesn't mean that the company doesn't have a toxic corporate culture that makes it a terrible place to work.
hueving 12y ago
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?
- _RPM 12y ago
  As long as I don't have to use a windows GUI, and can use the terminal to commit changes, then I could be in.
- ZeroGravitas 12y ago
  "Why do you need to control/audit all work done locally rather than what is pushed to your main git repository, and how can you realistically enforce that with any tool?"

jc123 12y ago

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.

spb 12y ago

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