4 ms·

Don't give up faith my friend. Git and mercurial are not the end of the story. I'm optimistic that, within another few years (give or take a decade), someone w

by moe 17y ago

Don't give up faith my friend. Git and mercurial are not the end of the story. I'm optimistic that, within another few years (give or take a decade), someone will come up with a VCS that's both powerful and usable. :-) Other than that: I enjoyed your article. Very nice walk through some of the problems and hair-pulling that I'm going through regularly, too. Pro-Tip: My life with git got a bit easier since I keep this big bucket of paste-ready shell-snippets near my terminal window. You know, those handy little 14-liners that look like line-noise at a glance, but get you out of "situations" when chanted.

DTrejo 17y ago
link to your 14-liners?
- moe 17y ago
  Sadly I guess they most of them don't make much sense without context or the discussion/thinking that led to them. But for example, this is my snippet for merging my current branch into master and pushing that to origin (hopefully merging/cleaning up in between as appropiate): # on local branch git fetch origin master git rebase origin/master # tidy up git rebase -i origin/master # merge to master git checkout master git merge $my_branch # push to master git push origin master # go back to local branch git checkout $my_branch I didn't originally come up with all that, mind you. It's pulled from a workflow tutorial and you'll find basically the same procedure recommended in every tutorial (keywords: feature branches and "don't work directly on master"). And yes, I paste that multiple times per day and still throw up a little bit inside my mouth every time.
  - dlsspy 17y ago
    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.
    - moe 17y ago
      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.
pellicle 17y ago
> Git and mercurial are not the end of the story. > I'm optimistic that, within another few years (give or take a decade), someone will come up with a VCS that's both powerful and usable. :-) Do you think Hg shares the same amount of usability as Git?

by moe 17y ago

DTrejo 17y ago

link to your 14-liners?

moe 17y ago
Sadly I guess they most of them don't make much sense without context or the discussion/thinking that led to them. But for example, this is my snippet for merging my current branch into master and pushing that to origin (hopefully merging/cleaning up in between as appropiate): # on local branch git fetch origin master git rebase origin/master # tidy up git rebase -i origin/master # merge to master git checkout master git merge $my_branch # push to master git push origin master # go back to local branch git checkout $my_branch I didn't originally come up with all that, mind you. It's pulled from a workflow tutorial and you'll find basically the same procedure recommended in every tutorial (keywords: feature branches and "don't work directly on master"). And yes, I paste that multiple times per day and still throw up a little bit inside my mouth every time.
- dlsspy 17y ago
  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.
  - moe 17y ago
    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.

pellicle 17y ago

> Git and mercurial are not the end of the story. > I'm optimistic that, within another few years (give or take a decade), someone will come up with a VCS that's both powerful and usable. :-) Do you think Hg shares the same amount of usability as Git?