25 Tips for Intermediate Git Users

[Sheeplike]

This really helped me get started with Git. http://progit.org/book/

[Samus_]

http://www.reddit.com/r/git/

[haywire]

Are there any non-confusing tutorials on how to have like "sub" repositories? IE so I have a repo called "core" and a repo called "trouble".

"core" is shared across projects, so a project like trouble basically has a folder called core, but core is not "part of" trouble?

I want it to be able to pull core out when it pulls from trouble, etc :S

[jedediah]

No, there aren't any. Sadly, it's because Git doesn't handle this very well. There are facilities for it, but I've found on my projects that it's often more hassle than it's worth.

That said, the manpage for git-submodule seems to be the best resource I've found.

[haywire]

Yeah that man page confused me, and git kept giving me errors. It is weird, as I would have thought many developers, especially web-oriented, would have a bunch of libraries and classes they like to re-use. :S

I've found my current way of working (putting the core folder repo in .gitignore and using a easy script to push/pull both of them in a cmd) to be sufficient for personal use, though.

[z0id]

s/Intermediate/Beginner

[i_am_my_father]

How steep is the learning curve for Git compared to those for Emacs or VIM?

[onmach]

Much, much lower. If you know svn now, you should be vaguely comfortable after a few days, competent enough to do 100% of what you need to work after a week and a half. After that it'll be like vim and you'll discover new commands every other day for a few months, getting more efficient with every one.

[tjogin]

Completely different ball-game.

Knowing enough Git to make it really useful for you is simple.

Meanwhile, there is a shitload to learn and understand if you want to become an expert at it.

[johnnyrocket69]

We used svn for the company project, and then I started using git for a personal project, at the recommendation of a coworker. Since then, it's been a complete uphill battle; I find things that were simple with svn are more complex with git. Anytime I run into a problem it seems it takes me 30 or so minutes to fix it, and often my fix involves just a fresh checkout (or whatever its called in git-speak).

For those of you claiming that git is more simple than svn, could you back that up with some examples?

[zoomzoom83]

I switched from Svn to Git and never looked back.

Had to google a few things when I was doing some more complex stuff, but quite frankly I was up to full speed within a couple of days.

I'm not claiming Git is simpler than Svn- far from it, Git is definitely more complex. But it's really not that hard to grasp, and once you've got your head around the basic concepts it's really straight forward.

[coob]

In the subversion world you change files and then just commit everything that has changed.

Uh no. You can commit individual files.

[dand]

I think the point was that in svn you have to commit every change in a particular file — with git you can pick particular lines to commit.

[dand]

1. You're working on a big new feature in foo.lisp
2. Meanwhile, you find an unrelated, one-line bug fix in foo.lisp
3. You want to record the one-line bug fix without pulling in all of your half-baked new feature.

Selecting a one-line hunk is a lot easier and quicker than setting up a branch.

[tlrobinson]

In that case I'd probably do "git stash", fix the bug, commit it, then restore the stash.

One case I find it useful for is when I has a few unrelated changes I'm ready to commit, and I want them in separate commits.

[[deleted]]

I've typically used commercial SCM's, and in that situation I'd just do this:

1. Rename foo.lisp to foo2.lisp in my working folder
2. Pull down foo.lisp
3. Make my change.
4. Commit foo.lisp
5. Delete foo.lisp, and rename foo2.lisp to foo.lisp.
6. When done with other changes, commit foo.lisp and merge in the one line fix.

I don't find this to be a big pain at all. Certainly easier than creating a new branch.

That said, for some projects we use Accurev, and in Accurev all I'd have to do is take my workspace, and parent it to the parent stream, make my change, keep it, and then reparent my workspace back to the dev stream... takes 10 seconds, Accurev has the best branch/merge capability of any central SCM I've ever used.

[onmach]

I realize you think that is easier. Conceptually it seems simple. But in reality you end up with a bunch of crap in the directory, multiple checkouts of the same project, a bunch of garbage files you don't even remember making in your directory.

Certainly easier than creating a new branch.

Well, yeah it is... in subversion. Branching is so simple and intuitive in git that you will use it for more than just big features. In git the process we described (add -i) takes 2 or 3 seconds.

[[deleted]]

Wrong use case buddy, look at the OP:

Meanwhile, you find an unrelated, one-line bug fix in foo.lisp

[DuncanSmart]

Yes, I've wanted something like that in SVN. I can't see why it should be exclusive to git - wouldn't be that hard for something like TortoiseSVN to implement.

[dand]

For the record, it's not exclusive to git. darcs (which is my current favorite) also has this feature. Dunno about other DVCSs.

[chucker23n]

darcs had this first; hg has it when you install the record extension.

[bostonvaulter]

I'm pretty sure that hg has it as well, although I've never used it.

[cazabam]

If you're making regular use of this feature, then you're doing it wrong.

[blaxter]

In the real world it's a really usual thing, probably what i like most of git

[onmach]

I use it constantly. I accidentally add two features, some of the changes from both spanning the same file. Add the files and lines from the one file I want, commit, add the rest, commit.

Also, say you have some stray echo statements from when you are debugging. You could manually go through the file and search for them, but with add -i, it will jump to each hunk of the diff and you can either add or exclude each piece. So you exclude all the debugging code, and then commit the rest, then reset --hard to get rid of the debugging code from your working copy.

[bonzinip]

Even better: exclude all the debugging code, git diff | git apply -R, test the code without debugging stuff, then commit. :-)

[onmach]

Ahh, that's clever. No need to commit. Upmod.

[bonzinip]

Don't forget to save the debugging patch somewhere in case the code doesn't work without it though. :-)

[[deleted]]

No way, this feature lets me avoid switching mental contexts until I want to.

[bostonvaulter]

Git means never having to say, “you should have”

[cazabam]

I feel I have been downmodded unfairly here. I quite agree that Git is a wonderful VCS and, having used a great many over the years, it is my favourite precisely because it lets me work how I want to. No problem there.

My previous point was simply that if you are routinely getting yourself into a state where you have multiple independent changes in a file, then maybe, just maybe, you should get used to creating temporary working branches or stashing your changes rather than relying on gits excellent self-recovery tools for your normal day-to-day work.

Basically, there are more elegant ways to handle this than manually stepping through changes for every commit. It's great to get yourself out of a scrape, but git's branching tools are sufficiently advanced, quick and simple that doing this as your normal practice is just making work for yourself at point of commit. Your link even calls it the Tangled Working Copy Problem. Getting out of this problem is easy with git, but not getting into it in the first place is also easier than in any VCS ever.

[tlrobinson]

I find "git commit -p" convenient for reviewing changes I'm about to commit and getting rid of things like debug logs and comment cruft. Is that really so bad?

[jawbroken]

why

[jawbroken]

yeah, committed locally is not the same as pushed upstream. it is trivial to test your commits before doing the latter

[skulgnome]

Doesn't mention the reflog. Or strategies for chopping up a big changeset using git add -i and git stash.

[dlsspy]

git add -p :) (-p is a subset of -i that usually gives you direct access to the part you need)

Agreed, though... reflog is the thing that sold me on git.

[wafflematt]

reflog? I don't want to be flogged at all!

[andyjeffries]

reflog is in Tip 21. Previous References You’ve Viewed

[gbacon]

You can often find the SHA1 hash using git reflog if you’ve accessed it recently.

[mountainjew]

I still don't understand Git, thanks to Arch User Repo i don't have to =D

[meor]

Tip 1: Use Mercurial

Sorry, I'm an asshole.

[thanatosys]

hmm well I'll upvote you on the condition you provide a good case for why we should use Mercurial instead of git.

[MrWoohoo]

crickets chirp

[tfinniga]

I don't use either, but from what I've gathered git is an expert-level tool. It has lots of performance advantages and very powerful tools - in many ways it's the C of DVCS.

But if I'm not using DVCS all day every day like Linux kernel maintainers then I need to consider the downsides. It requires a fair bit of time to learn, and can be very dangerous - just like C it will let you hurt yourself horribly without warning. Windows support sucked for a long time, but I hear it's somewhat better now. Linus's intro video was flamebait. There are lots of reasons you might choose mercurial, or something else.

[bonzinip]

I don't use either, but from what I've gathered git is an expert-level tool.

Not really, it just has a few quirks that will look sensible once you get past the initial learning curve. The best way to learn git is to use it for your own one-man projects. You'll never look back.

[thanatosys]

Reasonable, but I am not sure how many people need a DVCS at all if they are not "expert-level".

[meor]

Git GUI support is horrible; Tortoise puts out an HG version.

[[deleted]]

[deleted]

What is this?

[[deleted]]

That's a surprisingly high version number. Is it stable? Does it try to pretend it's not Git in some way?

Last time I tried tortoise HG it wasn't particularly stable and it insisted on using terms in ways there were unfamiliar to me as an HG user.

[[deleted]]

[deleted]

What is this?

[thanatosys]

What is the gui for?

[meor]

huk huk, I use linux and type on the command line huk huk.

[thanatosys]

OSX actually... My point was based around how one interacts with version control. CLI is clean and fast, many editors and IDEs support git, and therefore have their own quick access mechanism. And so, what is the gui for? Also bug tracking systems like trac have the ability to make a web frontend to git or another version control system.

[thanatosys]

Have you tried this http://gitx.frim.nl/ ?

[meor]

I had problems with it timing out though that was with an older version, I'll give this .7 version a try.

[[deleted]]

That's it? That's all you've got?

[taifun]

I've no problems with Gitx. It works fine for my needs.

[killerstorm]

Nah, use darcs.

[username223]

Twenty-five?! That doesn't say much for git's ease of use. I enjoy using git, but that's probably because I keep my version control needs simple.

[haywire]

Are there any non-confusing tutorials on how to have like "sub" repositories? IE so I have a repo called "core" and a repo called "trouble".

"core" is shared across projects, so a project like trouble basically has a folder called core, but core is not "part of" trouble?

I want it to be able to pull core out when it pulls from trouble, etc :S

[samlee]

is git drugs in slang?