|
MAR
10
2010
|
git everywhere... (how to compare my stuff to the central repository)KDE will be moving to git, Qt has moved to git, recently also CMake moved to git. So, it's time to start using git. ...until now it really looks so complicated, compared to cvs/svn. Ok, one has to get used to that "git add" is something different from "svn add", and "git commit" is different from "svn commit". Did you mean this? Ah, right, I think "git checkout" is the same as "svn update". At least "git diff" seemed to do the same as "svn diff" (or cvs diff). I mean, I'd like to know that before I push. So, some browsing and googling follows: I read things like "committing with a detached HEAD" or "Create a local reference to the remote repository as" and other things which sound quite complicated. And finally I find a web page which seems to contain what I'm looking for, how do I compare my stuff to the central repository: Phhh, is it really that complicated, doing like one of the most basic things ? So, how do I do this ? Alex |
 |
Comments
git
I'm glad someone else in KDE is as put off by the complexity of git as I am. Git seems to be all the fashion but I have no idea why. That our translators are staying in Subversion suggests to me something is wrong with the choice of tool here. It has nothing to do with being distributed, bzr is just as easy to learn as Subversion.
why not bzr
"That our translators are staying in Subversion suggests to me something is wrong with the choice of tool here."
no, the translators are staying with subversion so their workflow doesn't change. at all. bzr would be no different here.
in general, bzr fails on a number of fronts.
first, it doesn't have the mass of projects and users around it that git has. by at least an order of magnitude, if not more. yes, that's a popularity contest, but it's about time we got back to a lingua franca for f/oss development. for a company that preaches incessantly, if rather self-servingly, about rhythm and cadence, i think it is unfortunate that Canonical is not doing more to get our global development tools into a similar vision of coherence. i have my opinions on why Canonical doesn't care so much about this aspect of things, but it's not really on topic here.
the number of tools available for git absolutely dwarfs those available for other options. this matters. a lot.
bzr has a bunch of launchpad integration features. that's cool, but it also makes bzr reek as a distribution-specific tool and one that is not really general purpose. i understand the pragmatism behind the decision to do that, and it's a nice set of features, but it was a very silly move if the idea was to get more people using bzr. does the launchpad integration in bzr allow you to specify the server, btw? i couldn't see that in the docs for that stuff last time i checked. is it something in the sources that would need adjusting?
in short, git has momentum and incredible capabilities, which i don't see bzr, hg or any other tool coming anywhere near matching in any forseeable future.
the problem with git is that it is very powerful and so can do a lot of things, but it is also simultaneously poorly documented for getting the simple things done quickly. there are easy ways to do things (see my other reply in this blog entry) but finding them can be tricky.
my answers :)
to see what you've committed but not pushed, try this: git log origin..HEAD
fwiu, you can also do 'git pull' instead of 'git merge --rebase' most of the time.
it is quite evident to me that:
a) we need more documentation on techbase
b) we really need to host some workshops on irc for everyone
> to see what you've
> to see what you've committed but not pushed, try this: git log origin..HEAD
I did "git log '^origin/master' master" and this gave the log, i.e. the two commit ids and the log messages, but not the diff.
I also tried "git diff HEAD..master", "git HEAD...master" and vice versa, but didn't work.
Do I need to do something with these ...long commit ids ?
Alex
> but not the diff. git log
> but not the diff.
git log -p ?
or: git diff revision1 revision2
> Do I need to do something with these ...long commit ids ?
You can abbreviate them, and git will figure out which one you meant.
Every other label (e.g. "master" or "HEAD") references a single commit.
git diff HEAD..master means: all commits leading to master, but not leading to HEAD.
So you see all commits from the point both branches (or chains of commits) diverged.
"master" is the name of your
"master" is the name of your current local branch and "HEAD" is a simple way to refer to the latest commit on that branch. That's why you did not see any changes. "origin/master" on the other hand refers to the "master" branch on the remote repository "origin", so "git log origin/master..master" shows you the commits which have not been pushed. If you are on the "master" branch, this can be shortened to "git log origin..", as Aaron suggested.
"git log" shows commit messages, quite similar to "svn log" (except faster, since it's local, of course). You can then see the diff of a commit with "git show". If you want to see the latest commit the simplest command is probably "git show HEAD" (or even "git show" without arguments). It will show the latest commit message and diff (with paging and colors, quite nice).
There is a lot of different ways to see other commits. The most basic is "git show [commitid]", where commitid is the long commit id you were refering to, but you are not forced to use those long commit ids: you can use the first few characters, as long as they are not ambiguous (git will tell you otherwise). You can also refer to commits relative to their "distance" from HEAD: "git show HEAD~1" shows the commit before HEAD, "git show HEAD~2" shows the commit before HEAD~1 and so on. Have a look at "man git-rev-parse" for the many ways to refer to a commit in git.
DSCMs
I still like DSCMs much more than SVN & Co. I use mercurial but git is not much different (except, what is this "stash"?). When I want to see what I've changed since my last pull I just fire up hgtk log (or gitk) and look what was the last rev that wasn't committed by me. Then I could do a "hg bundle --base 6047 mychanges.hg". Then I send the bundle to a user who can just pull it, which is exactly the same as if he would have pulled from my repo! That is a cool thing.
Other things I like about hg (which I think most apply to git as well):
Things that only apply to hg (AFAIK):
Oh and I think its "git pull --rebase". At least that's what I do when I linearize my history when I want to push changes to amarok. But the hg philosophy is to preserve and not change history. Ok, linearistaion of only local changes should no make a big problem, but jsut in principle history should not change. After all only Guido has a time machine.
Another thing I like about hg is that pull does NOT update the working copy. You can pull and before you update to tip, another head or whatever you can use hgtk to look at what has changed and decide to which rev you really want to update (but if you like you can also do "hg pull --rebase -u" in order to pull, rebase and update at the same time). Oh and hg does not need repacks. ;)
But if you really do not want to use git: git has a pretty good svn bridge. This means it can push/pull to/from an svn server but also act as an svn server itself. I think this git does better than hg.
I think the equivalent of 'hg
I think the equivalent of 'hg pull' is 'git fetch'. 'git pull' runs 'git fetch' and then 'git merge'. AFAIK it's slightly different, since git fetch only updates the tracking branch, but the concept seems very much the same: pull in all new commits and update the tips/heads you didn't create yourself. Am I wrong about that? I use git myself, but only use hg for building projects from repositories.
Also, while TortoiseGit is only for Windows, QGit is cross-platform.
easy peasy
git diff HEAD..[remote-name]/[remote-branch]
e.g.
git diff HEAD..origin/master
There is a lot of good git documentation out there -- it help to take an hour to learn the basic concepts. Makes you much more productive in the long run. For instance, the tutorial is a place to get a feel for how to use it.
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
Don't try to figure it out as you go.
I think the real trick to learning git (or any other DVCS for the first time), is not to assume that you can figure it out as you go. Moving from CVS to SVN, that's a pretty safe assumption, but with git, you'll just waste your time.
Invest an hour or two and read through a few tutorials. Once you grasp the basic concepts behind it, things start to become a lot clearer. There's no question that you'll still frequently hit roadblocks and have to resort to Google, but at least you'll have a base of knowledge to build on.
Pages