Things I love about git(rakeroutes.com)
rakeroutes.com
Things I love about git
http://rakeroutes.com/blog/10-things-i-love-about-git/
7 comments
That's really cool, thanks for cluing me in.
But it looks like it's just limited support. Does it support all the github things like forks, pull requests, etc? Do you have a link to an SVN repo on github? I'd love to check one out.
But it looks like it's just limited support. Does it support all the github things like forks, pull requests, etc? Do you have a link to an SVN repo on github? I'd love to check one out.
Actually the way support works is that github emulates a svn acces layer on top of the git repository. So you can use every repository hosted on github with an svn client and get pretty much the same feature-set as git users.
Hm, interesting. So I could:
- fork a repo on github
- use svn to access that repo
- use svn to make a local/remote branch
- code code code
- commit and push up to github
- then use github pull requests as usual?Short answer: Yes, pretty much. The long answer is in this blog post https://github.com/blog/1178-collaborating-on-github-with-su...
There's also Beanstalk which I believe was the original github-style Subversion service.
2. Partial commits
Commit file X, then commit file Y.
You can also commit only a part of file X! `git add -i` brings you to an interactive 'add' mode where you can view, split and add each hunk individually.
Commit file X, then commit file Y.
You can also commit only a part of file X! `git add -i` brings you to an interactive 'add' mode where you can view, split and add each hunk individually.
That's absolutely right and a bit of functionality I had thought I had written up in my post. D'oh!
There's also `git add -p` that takes you straight into the patch mode.
There's also `git add -p` that takes you straight into the patch mode.
I'm on an internship through my University, writing a report for my current employer (as a requirement of said internship program) about their current centralized version control solution (Perforce) and comparing it to a distributed one (Git). Finding sources explaining why Git is "better" is easy, but finding any one arguing the other side is proving to be incredibly difficult.
Are there simply no benefits to using a centralized system, or is no one bragging about them like all of these Git fans?
Are there simply no benefits to using a centralized system, or is no one bragging about them like all of these Git fans?
One of the draw backs that typically gets mentioned about current distributed systems is the lack of locking which makes managing un-merge-able (binary) files impossible to manage correctly. This is why you will not hear of many game dev studios using git, version controlling art assets is fairly common in such situations and perforce handles it like a champ. DVCSs in general tend to have performance issues with large files, I know mercurial warns you about the performance implications of storing anything over 10MB.
A bit old(2009) so it may have changed, but here is a rant about the scalability of git vs perforce. http://stevehanov.ca/blog/index.php?id=50 and a little newer post on git scalability issues: http://news.ycombinator.com/item?id=3548824
A bit old(2009) so it may have changed, but here is a rant about the scalability of git vs perforce. http://stevehanov.ca/blog/index.php?id=50 and a little newer post on git scalability issues: http://news.ycombinator.com/item?id=3548824
Sure, there are tons of benefits to a central repository. I think that's actually what most people want from a VCS (IMHO). And you can set up policies that make Git act more like Perforce (but not so much the other way around).
The primary reason I switched my last employer from SVN to Git is because we frequently found ourselves in merge-conflict hell. Our workflow under Git was really very similar to our workflow under SVN.
The primary reason I switched my last employer from SVN to Git is because we frequently found ourselves in merge-conflict hell. Our workflow under Git was really very similar to our workflow under SVN.
It's worth noting that Git is often used as a centralized VCS. A central server is picked as the authoritative one (e.g. GitHub, or a server at your company) and the team pushes/pulls almost entirely to/from that server. In that common scenario, the difference between Git and whatever VCS it's replacing are really entirely in the UI.
There was a post last week that you might be interested in: https://steveko.wordpress.com/2012/02/24/10-things-i-hate-ab...
Git was not originally meant as a VCS - it was meant to be a platform for other VCSs.
For that reason, you can essentially write a wrapper on top of git to turn it into a centralized VCS that acts similarly to Perforce/SVN/etc., by enforcing a certain workflow that essentially eliminates merge conflicts.
Of course, you lose a lot of the power of git when you do this (the same power that's responsible for many posts like these), but to cut a long story short: it's not an apples-to-apples comparison.
For that reason, you can essentially write a wrapper on top of git to turn it into a centralized VCS that acts similarly to Perforce/SVN/etc., by enforcing a certain workflow that essentially eliminates merge conflicts.
Of course, you lose a lot of the power of git when you do this (the same power that's responsible for many posts like these), but to cut a long story short: it's not an apples-to-apples comparison.
> Bisect for bug hunting awesomeness
svn-bisect [1]
[1] http://search.cpan.org/perldoc?svn-bisect
svn-bisect [1]
[1] http://search.cpan.org/perldoc?svn-bisect
2. Partial commits... Edited file X and made a fix to file Y? No problem. Commit file X, then commit file Y.
partial commits can be made @ line level also, w/ `git add --edit`
partial commits can be made @ line level also, w/ `git add --edit`
-e, --edit
Open the diff vs. the index in an editor and let the user edit it...
Ahh, that's awesome and I haven't seen it before.
I'll add that in later when I fix my omission of git add -p.
I'll add that in later when I fix my omission of git add -p.
Subversion actually records merge metadata in recent versions. In my experience though it often still fails to work when working in branches.
Merge metadata was recorded since the 1.5 releases of Subversion in 2006. As you mentioned, it's still not as nice as the way Git or Mercurial works. One nice thing about Subversion's branching model is that it is relatively easy to merge single revisions from one branch to another and have that information be recorded in merge metadata. In Git or Mercurial, you can cherry pick revisions by essentially duplicating them in a new location in the graph of revisions. This is annoying in scenarios like this:
I'm much happier with the DAG model of Git and Mercurial than I was with the Subversion branching model, but the DAG model is not universally superior.
c--d--e
/
a--b
\
f
c--d--e
/
a--b
\
f--d'
c--d--e
/
a--b
\
f--d'--g--h
c--d--e----
/ \
a--b i
\ /
f--d'--g--h
I'm much happier with the DAG model of Git and Mercurial than I was with the Subversion branching model, but the DAG model is not universally superior.
Yeah? That's awesome. Do you mean that the metadata fails to work with branches or that merging itself fails?
It's been around for some time now. I think 1.7 added it.
I don't know if it was buggy or if we were doing something wrong, but it still caused merging disasters even though in theory it should have been able to avoid them.
I don't know if it was buggy or if we were doing something wrong, but it still caused merging disasters even though in theory it should have been able to avoid them.
The metadata is not enough to track the merging so you get conflicts where there should be enough knowledge to avoid the conflict. If I remember correctly this happens only in some merging patterns.
Actually, it does have a github. It's called "github" and is available at http://github.com.
See https://github.com/blog/966-improved-subversion-client-suppo...