Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This is how I git

daniel.haxx.se

Post reply on HN
Print view View original

61–70 of 140 posts

Re: This is how I git

#61

Post by FreeFull »

ricardobeat wrote: post #42
smokey_circles wrote: post #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 chang…

git add . git commit -m "wip" when you're back git reset HEAD^ Keeps working changes nice and tidy in the branch they belong to, you can push them, and they are easily recoverable from the ref log, unlike stashes. Also, god help you when a stash fails to apply.

Alternatively, instead of `git reset HEAD^` you could do `git commit --amend` to merge further changes into the latest commit

Re: This is how I git

#62

Post by laudable-logic »

zikzak wrote: post #49
gtsteve wrote: post #23

Earlier quoted context omitted.

I personally only use stashes when I've given up on my current approach and want to reset but I might change my mind later (rarely happens). I don't think they're appropriate for stuff you want to keep across branches, there's no real visibility and they'd be easily forgotten.

I use them to stash changes to config files that remain fairly stable across branches but require local paths, etc. I realize this isn't a best practice for config files but it is what I need to do for my particular mountain of technical debt. This works particularly well since the config files rarely change in a permanent way. I will only do it short term, though. For me, Stash is a tool I use sparingly as a conveni…

> I use them to stash changes to config files that remain fairly stable across branches but require local paths, etc.

I had to resort to git's assume-unchanged[O] to keep these changes out of commits made in the heat of battle.

> this isn't a best practice for config files

Have had great results (in dotnet land) with MS' Secrets Manager[1].

[0] https://www.git-scm.com/docs/git-update-index [1] https://docs.microsoft.com/en-us/aspnet/core/security/app-se...

Re: This is how I git

#63

Post by norswap »

smokey_circles wrote: post #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 chang…

My personal rule is "never go to sleep with a stash on the stack".

They are for short terms manipulations, but it's easy to make mistakes with them and lose data (dropped stashes don't show up in the reflog for instance).

Things to be preserved for longer should be committed and saved in temporary branches.

Re: This is how I git

#64

Post by lucideer »

smokey_circles wrote: post #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 chang…

> Stash is used to record the current state of the working directory and index while also returning to a clean working state.

Er, no. Stash does not return to a clean working state. Stash stashes modifications, not new files. And it makes a real mess if those new files happen to exist on another branch you want to check out.

Stash seems like a half-implemented feature tbh, if only for the infuriating limitation above. It's really just not safe to use.

Re: This is how I git

#65

Post by Nagyman »

lucideer wrote: post #64
smokey_circles wrote: post #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 chang…

> Stash is used to record the current state of the working directory and index while also returning to a clean working state. Er, no. Stash does not return to a clean working state. Stash stashes modifications, not new files. And it makes a real mess if those new files happen to exist on another branch you want to check out. Stash seems like a half-implemented feature tbh, if only for the infuriating limitation above…

> Adding the -u option (or --include-untracked) tells git stash to also stash your untracked files.

https://www.atlassian.com/git/tutorials/saving-changes/git-s...

Re: This is how I git

#66

Post by ufo »

jgraham wrote: post #51
ricardobeat wrote: post #43

The most important bit in my opinion: > When merging fixes and features into master, we avoid merge commits and use rebases and fast-forward as much as possible. Rebasing feature branches, and avoiding non-ff merges has been the best change I've ever made to my workflow. Makes it very easy to keep a clean, readable history that is actually useful when doing code archeology months later. Resolving conflicts is far eas…

If you have tooling to support it, rebase-and-ff-merge is perhaps an even better workflow. In this model every commit on the main branch has a first parent that's the previous merge, and a second parent that's a linear set of the commits that were landed together, with the parent of the first commit being the previous state of master. This has the following advantages: * It's clear which states master has actually be…

Does anyone know how to make this "cactus" workflow work better on github?

We use it in our organization and between us we know to always manually rebase before merging. However, when we receive an external PR from someone else it's a pain. It's also easy to accidentally forget to rebase before merging.

Re: This is how I git

#68

Post by IggleSniggle »

ricardobeat wrote: post #42
smokey_circles wrote: post #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 chang…

git add . git commit -m "wip" when you're back git reset HEAD^ Keeps working changes nice and tidy in the branch they belong to, you can push them, and they are easily recoverable from the ref log, unlike stashes. Also, god help you when a stash fails to apply.

I needed this comment today. I am an avid stasher, despite knowing the downsides. It’s just so convenient (until it’s not...at which point I usually give up and trash it, and yell at myself for not settling into a partial commit sooner).

But this workflow (which seems so very obvious in retrospect), keeps my current workflow, with so many benefits. The only place where it even requires extra steps is when you want to apply the stash to a different branch, and even there, it just feels right:

“Oh yeah, I was working on that feature over there, let’s pop it off and go put it on this feature over here.”

Since this generally requires careful diffing anyway to make sure things end up in the right place, there’s not much lost here, and without the downsides of stash.

Re: This is how I git

#69

Post by mklein994 »

gwenzek wrote: post #56
ricardobeat wrote: post #43

The most important bit in my opinion: > When merging fixes and features into master, we avoid merge commits and use rebases and fast-forward as much as possible. Rebasing feature branches, and avoiding non-ff merges has been the best change I've ever made to my workflow. Makes it very easy to keep a clean, readable history that is actually useful when doing code archeology months later. Resolving conflicts is far eas…

The issue is that Git sucks at rebasing. Every conflict you fix when rebasing will need to be fixed again next time you rebase.

Enter git rerere: https://git-scm.com/docs/git-rerere

This will "REuse REcorded REsolutions" of conflicted merges.

Once enabled, it will record how a merge conflict was resolved, and replay it back the next time it encounters it. Saves a lot of time in cases where you already solved the merge once before.

https://git-scm.com/book/en/v2/Git-Tools-Rerere

Re: This is how I git

#70

Post by IggleSniggle »

MaulingMonkey wrote: post #48
smokey_circles wrote: post #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 chang…

> You could commit and rebase and all sorts of clever mangling of the history. > OR you could use the right tool for the job Stashes are just another form of DAG node with their own special syntax and commands and quirks. I've already learned one set of commands for all that, why learn a second, less general set of commands? I have started using stashes in one very specific case: 1. I realize I'm on the wrong branch…

I usually do comment my stashes for this reason (git stash save “words to remind me what this is”). But I’ve also been convinced by comments here that I’m going to be happier with WIP commits.

I like making all my commits “canonical at all times,” but that’s just something I can see it’s time for me to evolve beyond.

Post reply on HN