This is how I git
daniel.haxx.se
This is how I git
1–10 of 140 posts
Re: This is how I git
#2Seems pretty standard to me. Anything notable here?
Re: This is how I git
#3>Never stash
Er, no. Right tool for the right job.
Whilst I agree that the idea of putting differing lines of work into different branches is great, that's not what stash is for. That's what checkout is for.
Stash is used to record the current state of the working directory and index while also returning to a clean working state.
I guess for the author, stash is used to preserve changes when pulling in upstream changes you missed. It can, but it does waaaay more.
What happens if, like many people, you're working on a few branches at a time. Could be a monorepo, could be a couple long living branches, w/e. What do you do if you've done work against a branch and want to lift and shift to another branch?
You could commit and rebase and all sorts of clever mangling of the history.
OR you could use the right tool for the job
---
Follow up
[0] https://medium.com/@yankee.exe/mastering-git-stash-workflow-...
[1] https://git-scm.com/book/fa/v2/Git-Tools-Stashing-and-Cleani...
Re: This is how I git
#4Seems pretty standard to me. Anything notable here?
If it’s not particularly contentious maybe it’s a good example for neophytes to follow?
Re: This is how I git
#5Too much verbing with nouns. Stop it.
Also, Git doesn't have pull requests. Did you mean GitHub?
Re: This is how I git
#6Seems pretty standard to me. Anything notable here?
Standard for github, maybe.
Re: This is how I git
#7Seems pretty standard to me. Anything notable here?
> Seems pretty standard to me. Anything notable here?
I agree, it's pretty vanilla git usage. I was curious to see any insightful take of whimsical twist, but it boils down to a basic take of good old git flow, which is git 101 for a long time.
https://nvie.com/posts/a-successful-git-branching-model/
The only surprising thing in the article was the refusal to use git stash, which can't really be explained on a rational level.
Re: This is how I git
#8>Never stash Er, no. Right tool for the right job. Whilst I agree that the idea of putting differing lines of work into different branches is great, that's not what stash is for. That's what checkout is for. Stash is used to record the current state of the working directory and index while also returning to a clean working state. I guess for the author, stash is used to preserve changes when pulling in upstream chang…
The problem with stash is that its easy to create a mess.
Yes, it's useful to quickly stash your work, switch to a different branch, do some quick fix, then go back to your original branch.
But in practice, what often happens is that your quick fix takes way longer than expected, and you don't immediately go back to your original branch.
Then you pull in some changes, maybe someone else pushed something to the branch you were working on, and you end up with a bunch of stashes on outdated branches and it's really hard to make sense of it all. Most of my working copies have at least half a dozen old stashes that I don't remember any details about anymore.
One approach to avoid this mess that git stash can lead to is to never use it, and just commit all your work before switching to a different branch. Clean up the current state of the repo, try to document your changes in the commit message, and commit them. Then switch branches.
You can always squash or rewrite the commits later, and it's a lot easier rebasing or merging a few old commits than working with stashes.
If you like stashes, please use them!
But I agree with the author, using them a lot can lead to a mess, and temporary branches are usually a cleaner way of saving your work.
Re: This is how I git
#9Seems pretty standard to me. Anything notable here?
> Seems pretty standard to me. Anything notable here? I agree, it's pretty vanilla git usage. I was curious to see any insightful take of whimsical twist, but it boils down to a basic take of good old git flow, which is git 101 for a long time. https://nvie.com/posts/a-successful-git-branching-model/ The only surprising thing in the article was the refusal to use git stash, which can't really be explained on a ration…
It's not git-flow, as all commits are rebased on top of master to make the history of master linear.
It is one of the more standard workflows, and it's a concise overview of how the maintainer of curl does their job.
For a more complex workflow, I recommend reading the notes from the maintainer of the git project [0].
Re: This is how I git
#10I git like this: https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278
A few utility commands and a most important safety net against git reset --hard throwing away work.