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

71–80 of 140 posts

Re: This is how I git

#71

Post by SassyGrapefruit »

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…

Agreed! I have trouble taking anyone's advice seriously(even if they contribute to a major library) when they say the phrase "Never do X". The only thing I feel confident in saying I'll never do is committing to the prospect of never doing something.

"One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision."

-Bertrand Russel

Re: This is how I git

#72

Post by jbergens »

formerly_proven wrote: post #20

> I use git almost exclusively from the command line in a terminal. Is certainly key. Most git frontends seem to be really quite bad for many reasons. Though "Push failed, want to pull, merge and push again? [Yes]" => constant "merged ssh://upstream.server/foo/bar/repo.git merged into branch master" commits being added to the history certainly irks my OCD the most. These frontends also seem to try and hide what git d…

GitKraken allows you to set "pull fast-forward only" or "pull rebase" as the default, very nice. This gets you out of most of those problems.

You can also do merge by dragging branches in the GUI which for me lowers the risk of taking the wrong branch. And it has a nicer looking interactive rebase than the command line which is very good for beginners.

Re: This is how I git

#73

Post by SassyGrapefruit »

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.

I can confidently say I've never encountered this. To diagnose I'd have to see what exactly you are doing, but I suspect you have issues with the way you organize your work. Git is not a magic wand. Making effective use of a hammer starts with the boards and nails.

Re: This is how I git

#74

Post by barumi »

Cogito wrote: post #54
barumi wrote: post #44

Earlier quoted context omitted.

> It's not git-flow, as all commits are rebased on top of master to make the history of master linear. I fail to see how that is relevant. I mean, the only possible impact that has is if individual commits within a feature branch are recorded or not, which is arguably irrelevant. You wouldn't get a different workflow if instead of reading you simply did a squashed merge. > It is one of the more standard workflows, an…

I don't know what you think git-flow is, but a linear history it is not. Look at any post on git-flow (or even just the original [0]), and you will see a myriad of merges. Quoting the original git-flow post: > When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number. How this is don…

> I don't know what you think git-flow is, but a linear history it is not.

Your statement makes no sense at all. Gitflow is a workflow. What do you believe it's supposed to be? It's irrelevant how you see commit histories, because with regards to the master/mainline branch it's always linear, isn't it?

What do you personally believe gitflow is?

> Quoting the original git-flow post:

I don't know what you expected to show, but you are only describing a workflow. Changes are made in dedicated branches, and later these changes are merged back into the master/mainline branch in a single commit, which is expected to have been validated and tested and working. That's a workflow. How the log ends up looking is entirely indifernet or irrelevant, isn't it?

Again, what do you personally believe is the whole point of a workflow like git flow, specially in light of allowing large teams to continuously integrate their work ? I mean, what do you believe is the whole point of getting devs to work on branches independent of what changes go into master/mainline, and leave merging as a last step that's the responsibility of the developer prposing a change?

Re: This is how I git

#75

Post by NateEag »

modderation wrote: post #34
globular-toast wrote: post #12

Earlier quoted context omitted.

It's not git flow. Git flow is horrendous, completely unnecessary and designed by someone who doesn't understand git. The article describes a pretty standard git rebase workflow that is simple and works well.

Git Flow actually makes some sense if you need to track and retain history of self-contained fixes and features across concurrent release trains, where "retain history" means more than just a commit message. With that said, I don't think this need is particularly common. Most projects are happier to throw away merge history in favor of a linear history with ephemeral branches and semantic versioning, and that's perfe…

The author of "GitFlow Considered Harmful" put out a simpler workflow that achieves all the upsides of GitFlow with none of the downsides:

https://www.endoflineblog.com/oneflow-a-git-branching-model-...

If you can tell me something GitFlow buys you which OneFlow doesn't, I'd be very intrigued.

Re: This is how I git

#76

Post by stinos »

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…

>Never stash

Er, no. Right tool for the right job.

Yup. pull --rebase --autostash for example. Technically also stashing, and would be insane not to use it :)

More serious note: agreed. I use stashing multiple times a day and never have problems with things being messy. Though I admit I usually look t stashed in a gui, not from the terminal.

Re: This is how I git

#77

Post by kcolford »

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…

If you're working on something and have to switch to another branch to do something else midway, that's what git-worktree is for.

Re: This is how I git

#78

Post by linuxftw »

cjfd wrote: post #35

The ease of branching has people treat branches as if they were cookies. You cannot possibly have too many of them. But, actually, branches make refactoring more difficult. What if one person just added a parameter to a function while another person is adding new calls to that same function. The automated merge cannot fix this conflict. The KISS principle that is the corner stone of all software development would dic…

> What if one person just added a parameter to a function while another person is adding new calls to that same function. The automated merge cannot fix this conflict.

If you're working in a large codebase and the function in question is part of your API, don't mutate it, add another function and deprecate the older function.

In any case, either developer A or developer B has to pay the cost of mutating the function at some point.

Re: This is how I git

#79

Post by mplanchard »

yarcob wrote: post #8
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…

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…

I started using emacs recently, largely for org-mode and magit. The default stash behavior of prompting for a message in magit helps me a lot with the problem of keeping stashes organized and knowing when old stashes I’ve forgotten about are safe to get rid of. Even when working on the command line now, I try to always stash with a message to provide some context for future me.

Re: This is how I git

#80

Post by bradstewart »

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.

This. I have these aliased as `git save` and `git unsave`, which makes it as convenient as `git stash`.
Post reply on HN