Still hatin' on git: now with added Actual Reasons

Re:Still hatin' on git: now with added Actual Reasons by dlsspy on Wednesday May 12, 2010 @11:08PM (#1343147)

Your first two commands can be replaced with (one time):

git config --global branch.autosetuprebase always

Then "git pull"

Without doing the config change, you can just do a "git pull --rebase"

Your "git push origin master" is typically what I spell "git push" (recommend "git config --global push.default tracking" just to make sure you're pushing the same stuff that's tracked automatically).

So, my every day workflow (rebasing upstream and building on top of stuff) looks like this:

    git pull
    [edit a bunch of files]
    git add -p
    git commit
    git push

My mouth is minty fresh.

[ Parent | on HN ]

Re:Still hatin' on git: now with added Actual Reasons by moe on Thursday May 13, 2010 @11:21AM (#1344495)

I guessed I'd have something like that coming and yes, that might work.

Except when you regularly need to create new working copies on varying git versions where those config details tend to differ in subtle ways. Too often did I have to wrestle problems on someones MacBook simply because the config or command syntax changed slightly between a few git revisions.

I'd go as far as to say that local (i.e. not repository-wide) config settings that change the semantics of how the commands work are deeply harmful in a team-setting.

It's yet another layer of complexity that you have to keep in mind when debugging problems.

Sure, it can save typing when everyone involved uses the same git version and has a good understanding of git. Unfortunately neither has been the case on most projects I've been involved with.

[ Parent | on HN ]