I'll try to answer some of the concerns.
> I have not yet got the basics of GIT - call me idiot, whatever ...
Don't worry, it is very different from CVS and SVN, and that can be a
good thing. I think it depends a lot on the environment and workflow.
Personally I like git for it's benefits, and I haven't really met
with any big problems so far.
> error: failed to push some refs to
> refusing to pull with rebase: your working tree is not up-to-date
> argh!! GIT is really a non-intuitive system for me;
> why is that such hell?
Maybe it's because git has many rather low-level commands? For some
workflows they should be combined in one way, but for others in
another, so there is still a reason to keep them distinct.
> Please advice correct usage! Thanks!
Alexander Lamaison wrote:
> It will only pull remote changes into a clean working copy.
> The solution is to use 'git stash' to put your local, uncommitted
> changes on hold for the time being, then run 'git pull' (which
> should automerge nicely), then run 'git stash apply' which will
> merge your own changes back into the latest code and possibly
> require you to resolve conflict manually. Why does GIT insist on
> doing it this way? Not a clue.
I'm happy to try to explain what I think I understand about git
design but I recommend watching Tech Talk: Linus Torvalds on git
git is distributed, meaning that everyone has equivalent repository
copies, and that people work only relative to their own repository.
Of course people want to sync repositories as well, but that is
separate from work. Local commit = working, sending patch = syncing.
Branching is really cheap with git. The idea is to keep distinct
development efforts in branches of their own, until they go into
mainline. So far, I suck at this in my own projects. I haven't even
used stash yet.
> I've given up trying to understand GIT and now I just do what I'm
I think that's unfortunate, but I also understand not everyone wants
to figure git out. I'm getting to know git since a year or so and I
really like it in many ways (distributed, commit id == content hash,
cheap branches, nice tricks) but yes, it has a higher threshold.
Maybe it's also more low level than you prefer, in which case it
could be worthwhile to look into some of the utilities (porcelain)
that go on top of the lowest level git commands (plumbing) and can
also be used to work with git repositories. I googled git porcelain
and got a few hits:
And a curious sequence: (no, I don't know exactly what it does, but
it looks like maybe it adds sourceview into a gnome svn module?)
Also, there's the git cheat sheet:
Received on 2009-09-03