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

21–30 of 140 posts

Re: This is how I git

#21

Post by Vinnl »

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…

> 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?

One "right tool for the job" I really underappreciated until recently is git worktree, which fits this use case neatly, I think, without the risk of losing your stash.

Re: This is how I git

#22

Post by secondcoming »

nickcw wrote: post #13

I use almost exactly this workflow with rclone. This bit resonated particularly: begin quote Never merge with GitHub! There’s a button GitHub that says “rebase and merge” that could theoretically be used for merging pull requests. I never use that (and if I could, I’d disable/hide it). The reasons are simply: I don’t feel that I have the proper control of the commit message(s) I can’t select to squash a subset of the…

Personally, I always merge with Github. Never had an issue, and never had concerns about non-linear commit history. So much is made about commit history that I think there are flaws elsewhere in other people's processes, or people are just getting off on their git-fu.

But this comment will just descend into a dull, tedious flame war. I don't care. git merge is totally fine.

Re: This is how I git

#23

Post by gtsteve »

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 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.

Re: This is how I git

#24

Post by Vinnl »

teekert wrote: post #14

Looks like my flow. One thing I do wonder, how do people deal with the tests and the time it takes for a PR to be approved (including tests, discussion, people in different time zones)? I often have interdependent branches (large pieces of related work chopped into small tasks) and take my previous branch along in my new one, this leads to an order in PRs sometimes when a big tasks is followed by a small/fast one. So…

I don't often have that much interdependent work, but if I do, I usually just base the new PR off the old one, and rebase them after the first one is merged. Worst I've experienced is four of those PRs in a row, which wasn't too bad.

Re: This is how I git

#25

Post by zwp »

brmgb wrote: post #16
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…

I don't understand your comment about tools. Checkout is a git command (with an admittedly terrible ux). It is not part of git data model. Like the article writer, I never myself use stash. I personally don't understand why they were added to the git ux. I think they needlessly make git more complex. Under the hood, a stash is just a commit anyway. You might retort that this is an implementation detail but as usual w…

I have a vague recollection of feature parity with Mercurial's shelves but I don't remember which came first. They look very similar: https://www.mercurial-scm.org/wiki/ShelveExtension

Perhaps a Mercurial user can say if shelves are more useful? (And if so, why?).

Re: This is how I git

#26

Post by helloguillecl »

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…

Push and Pull almost always from the cli. But one of the things I find tools like Sourcetree useful for is selecting which changes (hunks, files or selected lines) to stage for commit, which is in my opinion much easier than with the CLI only.

Re: This is how I git

#27

Post by steerablesafe »

zwp wrote: post #25
brmgb wrote: post #16

Earlier quoted context omitted.

I don't understand your comment about tools. Checkout is a git command (with an admittedly terrible ux). It is not part of git data model. Like the article writer, I never myself use stash. I personally don't understand why they were added to the git ux. I think they needlessly make git more complex. Under the hood, a stash is just a commit anyway. You might retort that this is an implementation detail but as usual w…

I have a vague recollection of feature parity with Mercurial's shelves but I don't remember which came first. They look very similar: https://www.mercurial-scm.org/wiki/ShelveExtension Perhaps a Mercurial user can say if shelves are more useful? (And if so, why?).

I'm a Mercurial user and I use bookmarks instead, aka git-like branches.

Re: This is how I git

#28

Post by lifthrasiir »

> The downside with not using the merge button is that the message in the PR says “closed by [hash]” instead of “merged in…” which causes confusion to a fair amount of users who don’t realize it means that it actually means the same thing! I consider this is a (long-standing) GitHub UX flaw.

This is so true, if the automatic detection of the PR merger vs. closure is hard (and I can see some reasons why) there should at least be a switch for maintainers to update the outcome message.

Re: This is how I git

#29

Post by jlelse »

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…

Lazygit (https://github.com/jesseduffield/lazygit) is pretty awesome.

Re: This is how I git

#30

Post by adimitrov »

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…

I would like to say that not all git front ends are like that. I used to be a CLI only user, but now you can pry magit from my cold, dead hands. It's very close to the command line in what it does, it's very easy to see what exactly it does, and where it abstracts from git commands, it does so while following Git's mental model very well.

It has great discoverability while at the same time being an amazingly streamlined power user tool.

In other words, there can be great git front ends. It's just that most of them suck, usually because of a desire to dumb down the git UI. If you don't do that, and accept Git's complexity it can work out great.

Post reply on HN