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

31–40 of 80 posts

Re: Git Reflow

#31

Post by juped »

aeontech wrote: post #28
npsimons wrote: post #20

Earlier quoted context omitted.

Very much this. I keep saying: I. Don't. Care. About. Every. Little. Sneeze. A. Developer. Had. On. The. Way. To. Closing. A. Ticket. See how annoying that is? That's what it feels like to me to read non-squashed commits.

Why does everyone seem to insist that there's only two options? option A) SQUASH ALL THE THINGS option B) HISTORY IS SACRED AND HOLY We just make sure that the developer rebases and squashes the meandering micro-commits into parent logical units before merging. This gives us both sensible logical commits, and avoids monster commits. I spend enough time spelunking through history that I dread seeing something like thi…

I know the question is rhetorical, but the answer is that many people don't understand how to use git, and the preferred way of coping with this is to dogmatically declare some git feature (either branching/merging, or the various operations that fall under "rebasing") to be "Beast. Defiler. The source of all my pain."

But only people who are bad at git ever post things on the internet about git! (with the exception of Junio's blog)

Re: Git Reflow

#32

Post by jordigh »

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.

We did figure it out, that's Mercurial Evolve:

https://www.mercurial-scm.org/doc/evolution/sharing.html

Re: Git Reflow

#33

Post by juped »

DannyBee wrote: post #4
teen wrote: post #2

This seems super useful- it matches my team's workflow, I'll def suggest we try it. Squash merge ftw

I'm really curious about it. One of the purported reasons - "it makes git blame more useful", is pretty silly, unless you never have anyone fixing typos or reformatting code or whatever. git blame is already an approximation (because git, and well, everything, does not record what you did for real, only the smallest set of binary delta instructions you must execute to produce file version 2 from file version 1). So t…

>yfw you type `git blame --first-parent`

Re: Git Reflow

#34

Post by juped »

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)

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)

Re: Git Reflow

#35

Post by codenamev »

As one of the maintainers of git-reflow, I understand the controversy over squash-merges. Personally, on all the projects I've worked on with this workflow, I have yet to find any drawbacks when needing to use git-blame; although is not to say that there is no value in maintaining a full history nor that it is our way or the highway. We like to keep all changes in context of a feature.

We have worked in environments that promote rebasing of feature branches, and while that may work well, it can lead to holes in the history of the review process due to the need to force-push.

That said, we are nearing a stabilized core API and have plans to allow for more flexibility in the process. If you are interested in following our ideas behind this, feel free to follow the issue we have open: https://github.com/reenhanced/gitreflow/issues/53

Re: Git Reflow

#36

Post by jerf »

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 something about that.

The way some people talk, the only acceptable history is an asciinema [1] recording of the development process with a microphone recording the developer's mutterings as it goes. The question isn't about what information you "lose" but about what you keep, because you must discard the vast bulk of it. We're arguing here about whether we chuck 99.97% or 99.99% of it.

[1]: https://asciinema.org/

Re: Git Reflow

#37

Post by JimDabell »

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…

> 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 changes without letting the crap into your history.

Re: Git Reflow

#38

Post by tunesmith »

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 commit (so the commit is deleted rather than seeing a commit and then a revert in the log). And once I'm close to done, I can even rebase so my clean commits are all in a row. Then I push my branch.

I lose all that flexibility as soon as a team's process demands I push my branch as soon as I create it. I can no longer rebase (I still don't understand the guides that explain how to use rebase after pushing), reverts add noises to the log, merges from master interrupt the flow, etc. So in that sense, I can see the allure of a squash-and-merge to master.

I just don't think that pushing an empty feature branch takes advantage of the benefits of using git.

Re: Git Reflow

#39

Post by _ikke_ »

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…

That's what things like git rebase are for (nice workflow with git commit --fixup + git rebase -i --autosquash). Then you clean up your fixes, while still keeping valuable history. With squash merges you are throwing out the baby with the bathwater.

Re: Git Reflow

#40

Post by lotyrin »

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…

Push after rebase is safe and easy if:

You have protection on your remote trunk branches against force push.

You have git configured to push only the branch you are on, to the same name on the remote.

git rebase; git push -f;

It is HARD, DANGEROUS and SHITTY under other configurations.

<3 Git.

Post reply on HN