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

Git Reflow

github.com

Post reply on HN
Print view View original

61–70 of 80 posts

Re: Git Reflow

#61

Post by juped »

gsylvie wrote: post #56
juped wrote: post #34

Earlier quoted context omitted.

Totally does (though your maintainer has to care about first-parentage order, which they should, and which should be enforced by the software but isn't - see Junio's blogpost "fun with non-fast-forward", or "fun with --first-parent" for more basic info)

And this: http://bit-booster.blogspot.ca/2016/02/no-foxtrots-allowed.h... (p.s. your old comment on "git branching models" that starts "Not another one. All good git workflows are different..." was hilarious/awesome - https://news.ycombinator.com/item?id=11193048. )

Thanks. Git superstitions bug me a lot because it shouldn't have to be this way.

Re: Git Reflow

#62

Post by jcoder »

tunesmith wrote: post #38
32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

I think there's an inherent tension between your style, and the style that prefers pushing new branches immediately. I personally like to create a new branch locally - sometimes I'm experimenting and get ahead of my commits, and then I'll make 3-4 commits in bite-sized concepts. Other times I'll commit something that seems like it will probably work, and then I realize it doesn't, so I'm able to revert/reset the comm…

There's no reason you couldn't rebase your feature branch work atop the commit it shares with the master branch, and push it. You would not be rewriting anything that the remote knows about.

Another option you might consider, if you need more flexibility, is doing your work in a branch off of your `feature-branch`, e.g., `feature-branch-wip`. When you're happy with your progress on `feature-branch-wip`, interactively rebase atop `feature-branch`, merge in, and push. Their process is satisfied, and they'll never be the wiser.

Re: Git Reflow

#63

Post by tjbiddle »

Created something in-house very similar for a job a few years ago; We could accept a ticket, it would create a feature branch, update the ticket and comment on it that it was being worked on, then when we submit, it would update the ticket status - assign it to a reviewer, squash commits, create a pull request and comment with the link.

This project seems to be done much cleaner though and in a more abstract and reusable manner. Well done!

Re: Git Reflow

#64

Post by tjbiddle »

32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

It's a good idea when you're working with small changes. If I'm working on fixing some bug, it should probably be in one-commit and done. But sometimes you're working on a bunch of "testing123" "save where I'm at" commits - and you don't want those in the end.

And then if you're working on a larger feature, you have that feature branch and make these small one-commit merges into that branch. When you merge that larger feature - it'd be great not to squash those commits.

Re: Git Reflow

#65

Post by junke »

jerf wrote: post #36
juped wrote: post #3

Another "I like to deliberately lose information to no benefit because I'm bad at git" 'workflow' hits Hacker News. Something is deeply wrong with the ecosystem when people want to do things like this!

"bisect". Bisect becomes useless if not every commit compiles (or local equivalent). Bisect is a critical feature, even if I don't necessarily use it often, because when I need it, I need it. As long as I can bisect, I don't much care about the details. But this is definitely not compatible with three dozen commits mostly consisting of "oops didn't compile" and "forgot comma" and "fix syntax erorr". You've gotta do s…

Not saying that you should keep everything, but your argument does not take into account "git bisect skip", which works both manually and automatically.

https://git-scm.com/docs/git-bisect.

Re: Git Reflow

#67

Post by tomsmeding »

maxxxxx wrote: post #19
32bitkid wrote: post #5

The "squash and merge" trend with git bothers me, and perhaps I'm "doing it wrong" but it just doesn't capture what I need a commit history/git-blame for. Usually, I don't care what feature a line code was for. I want to know why a developer thought that was the right change. And to get that visibility I tend to make lots of commits, treating commits almost as out-of-band comments that don't clutter the file/repo. Wh…

I don't think history should ever be changed but there should be a way to view history as if a "squash and merge" or whatever you like had happened.

This would give the best of both worlds. People preferring the squash style can view the log cleanly, and people preferring detailed history can get detailed history.

Re: Git Reflow

#68

Post by cyphar »

junke wrote: post #65
jerf wrote: post #36

Earlier quoted context omitted.

"bisect". Bisect becomes useless if not every commit compiles (or local equivalent). Bisect is a critical feature, even if I don't necessarily use it often, because when I need it, I need it. As long as I can bisect, I don't much care about the details. But this is definitely not compatible with three dozen commits mostly consisting of "oops didn't compile" and "forgot comma" and "fix syntax erorr". You've gotta do s…

Not saying that you should keep everything, but your argument does not take into account "git bisect skip", which works both manually and automatically. https://git-scm.com/docs/git-bisect .

I never liked git bisect skip, becuase the bug you're tracking down somehow always manages to be in a set of 3 or 4 commits, of which you can't build 2. Maybe I'm just lucky.

Re: Git Reflow

#69

Post by cyphar »

Dru89 wrote: post #24

I'm unhappy with the approval process being a simple search for "LGTM". I wish GitHub pull requests had actual support for a review process, e.g.: * open issues to address * review state, such as "changes requested" or "approved" (along with users that are in each state). We've been using Phabricator's[1] Differential tool for code reviews and it feels superior to this process, but it would certainly be nice to have…

Whenever I'm working on a big patchset, I always make sure I add a checklist. Unfortunately nothing forces me to do this, so some people make huge patchsets and there's no history of what was changed or fixed in that patchset. This makes review and maintainence quite frustrating.

Re: Git Reflow

#70

Post by junke »

cyphar wrote: post #68
junke wrote: post #65

Earlier quoted context omitted.

Not saying that you should keep everything, but your argument does not take into account "git bisect skip", which works both manually and automatically. https://git-scm.com/docs/git-bisect .

I never liked git bisect skip, becuase the bug you're tracking down somehow always manages to be in a set of 3 or 4 commits, of which you can't build 2. Maybe I'm just lucky.

You can't blame git bisect skip for that.

Note also that many other commits that could not build did not contain the bugs ;-)

(Speaking of luck, I worked with a codebase where the bug was always inside a jumbo commit involving at least a hundred of files)

Post reply on HN