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

51–60 of 80 posts

Re: Git Reflow

#51

Post by tunesmith »

zelos wrote: post #49
tunesmith wrote: post #38

Earlier quoted context omitted.

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…

But leaving a day's work locally on your laptop is dangerous, no? You have to organise some other backup system, instead of pushing to the central, RAIDed, backed up repo.

I suppose you can always set up a private bitbucket as a second remote and push to there. It might be against your team's policy, though.

Re: Git Reflow

#52

Post by amk_ »

CJefferson wrote: post #12
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 agree, I wish some VCS would figure out how to do a "history of history". I hate every time in git I destroy history (delete a branch, do a force push / update), but it is almost impossible to use git without doing these things, particularly when committing to another project.

git reflog

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

Re: Git Reflow

#53

Post by JoshTriplett »

npsimons wrote: post #15
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…

> But there are so many people into it, that I feel I must be missing something obvious and it bothers me. As someone in favor of squashing, I can say that I don't want to see things like "oops, reverting last commit" popup in my git history, especially if I'm browsing history or bisecting a bug. That's noise - useless data. OTOH, commits should be the Minimum Necessary Change to accomplish a well-defined goal. The c…

You should definitely squash away fixes to commits that are part of the same commit series you're submitting; you don't want to submit a broken patch followed by a second patch to fix that broken patch.

But as part of your point that commits should be the "minimum necessary change", it makes sense to send a logical series of patches that iteratively change a project to implement a new feature (e.g. adding new infrastructure), rather than one big patch to implement that feature.

Re: Git Reflow

#54

Post by ecobiker »

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…

The way I see it, I don't want somebody else to do the squash for me. It's my responsibility to make sure my commits are logical. I do as many rebases, fixups, squashes as necessary and provide a logical set of commits. I want the merges to preserve that as it is. But as others have said, there are plenty of really valid reasons to alter history as one deems necessary.

Re: Git Reflow

#55

Post by ghayes »

JimDabell wrote: post #37
npsimons wrote: post #15

Earlier quoted context omitted.

> But there are so many people into it, that I feel I must be missing something obvious and it bothers me. As someone in favor of squashing, I can say that I don't want to see things like "oops, reverting last commit" popup in my git history, especially if I'm browsing history or bisecting a bug. That's noise - useless data. OTOH, commits should be the Minimum Necessary Change to accomplish a well-defined goal. The c…

> As someone in favor of squashing, I can say that I don't want to see things like "oops, reverting last commit" popup in my git history There's a middle ground between squashing and leaving a load of disorganised crap in the history. Rebase before merging. It gives you a chance to clean up the rubbish, but it doesn't force you to squash an entire feature's work into a single commit. You can preserve the logical chan…

I agree here. Be a good steward of your commits, and let `rebase -i` be your tool for that. A bunch of "err, try this instead" should be washed away, but it doesn't help to commit "Add Huge Feature" +10,000/-2,000 because "I should squash my feature"

Re: Git Reflow

#56

Post by gsylvie »

juped wrote: post #34
bennofs wrote: post #16

Earlier quoted context omitted.

Doesn't `git blame --first-parent` work for that? From my quick tests, it seems like it shows the merge commit if you have such a structure (`--first-parent` also works for `git log` etc)

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

Re: Git Reflow

#57

Post by sergiosgc »

bennofs wrote: post #16
sergiosgc wrote: post #10

Earlier quoted context omitted.

I get close to the milestone-ish commit by opening feature branches and then merging with no fast forward. All commits in the main branch are merges, and all of those are features. The feature incremental commits go in the branch. It's ok, I'd just like to be able to apply this structure to stuff like bisect or blame.

Doesn't `git blame --first-parent` work for that? From my quick tests, it seems like it shows the merge commit if you have such a structure (`--first-parent` also works for `git log` etc)

Thanks! It does. Learning something everyday.

Re: Git Reflow

#58

Post by deathanatos »

0942v8653 wrote: post #8
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 agree, but here's their reasoning: https://github.com/reenhanced/gitreflow/issues/52 > When it really comes down to it, the only place we care about enforcing a particular style of commit is in the master branch. We don't care if you make a thousand commits to get there, the only thing we care about is the individual features that come in from each (small) pull request. > And while the history is nice, the biggest…

> but their commit in the full context of why that change was made, including an easy-to-reference link to the pull request and ideally (through the pull request description)

This is somewhat fair, but I feel it needs to be noted that even if you don't squash commit, if you look up a commit in Github, at the top of the page it will link you to the PR even if that commit is not the merge commit. I use this all the time to go from a random commit to a PR in our code, even though we do not squash commit. (We encourage, but do not enforce, an autosquash rebase against master; that is, history is kept, but you're permitted fixup! commits for really silly things like typos that we don't care to remain in the history, and it's left to your judgement what should be kept. The rebase cuts down on the amount of criss-crossing branches.) That said, I also use the individual commit message to, as the grandparent noted, figure out what a dev was — or wasn't — thinking.

Re: Git Reflow

#59

Post by mikepurvis »

ghayes wrote: post #55
JimDabell wrote: post #37

Earlier quoted context omitted.

> As someone in favor of squashing, I can say that I don't want to see things like "oops, reverting last commit" popup in my git history There's a middle ground between squashing and leaving a load of disorganised crap in the history. Rebase before merging. It gives you a chance to clean up the rubbish, but it doesn't force you to squash an entire feature's work into a single commit. You can preserve the logical chan…

I agree here. Be a good steward of your commits, and let `rebase -i` be your tool for that. A bunch of "err, try this instead" should be washed away, but it doesn't help to commit "Add Huge Feature" +10,000/-2,000 because "I should squash my feature"

If you're putting up 10k lines of code in a single review, you're doing it wrong anyway. Why wouldn't you have multiple reviews that each add different parts of a feature and link to the same ticket?

Re: Git Reflow

#60

Post by deathanatos »

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…

An actual flag wouldn't be bad, but I know that I've sometimes given out conditional approvals in a code review (i.e., "if you change this, then I approve; if you don't agree, then we should talk"). The idea being to remove a round-trip that would otherwise waste the reviewee's time. (This of course implies a certain degree of trust that the reviewee makes the change as you desire, but in practice I find this isn't a problem.)
Post reply on HN