Live data from Hacker News

GitFlow considered harmful

endoflineblog.com

291–300 of 342 posts

Re: GitFlow considered harmful

#291

Earlier quoted context omitted.

When you say it's another form of ^S, how often are we talking here? I reflexively ^S every couple of words, are you literally talking about committing every couple of words? Every few lines? Less? What's the purpose committing more often than logical chunks of code which can be considered in some sense "done"?

>I reflexively ^S every couple of words... Why not just decrease the autosave interval in your editor :) >What's the purpose committing more often than logical chunks of code which can be considered in some sense "done"? There are different degrees of "doneness". For example, (1) code that isn't finished but you don't want to lose it if the power goes out, (2) code that you're not sure if you're going to keep, but yo…

My ^S reflex is almost 30 years old. It costs nothing, and occasionally saves me, so I have no reason to fight it. Autosave is great, but every so often you'll hit a situation where it turns out that it's not firing (misconfiguration or something) and then you're doomed. Belt and suspenders is best.

As for the rest, that's interesting stuff to ponder.

Re: GitFlow considered harmful

#292

Earlier quoted context omitted.

It's not so much what the true historical record gets you, but what you potentially lose with the fake one. Do the commits in your edited history actually work? If you go back to see why a given change was made, will you get an accurate picture of the state of the rest of the code at that time?

But one of the points of editing the history is to make sure that both of those are more likely to be yes -- it's to make the history easier to review historically than it would be unedited. (IMO, obviously). And this is probably partly why there's what you originally called an "obsession" with rewriting history: retroactively rewriting something 5 months old is probably going to be a disaster. But rewriting 1 day's…

Are you building and testing your edited commits as you make them? If so, that seems fair, but a lot of work. If not, I don't see how it increases the chances of good results.

Re: GitFlow considered harmful

#293

> ...the history of a project managed using GitFlow for some time invariably starts to resemble a giant ball of spaghetti. Try to find out how the project progressed from something like this... It's simple. Read backwards down the `develop` branch and read off the `feature/whatever` branches. Just because the graph isn't "pretty" doesn't mean it's useless. In general, I'm starting to dislike "XXX considered harmful"…

Articles like this are harmful. There are many of us successfully using gitflow without _any_ of the issues raised in the article.

And yet people who want to argue against the use of it simply because they don't want to learn something new now have a useful link to throw around as "proof" that a very successful strategy is "harmful". I guarantee in the next year I will have to go point by point and refute this damn article to some stubborn team lead or another senior dev.

Nobody should ever write an article outright bashing a strategy that they either don't fully understand or personally have not managed to integrate successfully in their own day-to-day. Bare minimum, if you're going to publish an article critical of a tool, don't name it so aggressively as to sound like it's fact rather than a single personal point of view.

Re: GitFlow considered harmful

#294
post #72
post #24

GitLab CEO here. I agree that GitFlow is needlessly complex and that there should be one main branch. The author advises to merge in feature branches by rebasing them on master. I think that it is harmful to rewrite history. You will lose cherry-picks, references in issues and testing results (CI) of those commits if you give them a new identifier. The power of git is the ability to work in parallel without getting i…

The obsession of git users with rewriting history has always puzzled me. I like that the feature exists, because it is very occasionally useful, but it's one of those things you should almost never use. The whole point of history is to have a record of what happened. If you're going around and changing it, then you no longer have a record of what happened, but a record of what you kind of wish had actually happened.…

I can make 20 or 30 commits during some code changes in a morning's worth of coding. This allows me to easily trace back to any point, or cross-reference changes across many local branches, etc.

At the end, it might all be squashed down into a single bug-fix commit for the devel branch.

The commit granularity that's desirable and effective for an individual is very different to the history you want in the main feature branches.

Re: GitFlow considered harmful

#295

Earlier quoted context omitted.

Also this is a problem with Git not GitFlow. In Mercurial, for example, every commit is attached to a branch so it's very easy to follow where the changes happened.

Mercurial branches are not meant to be used for short-lived feature branches, though. As "hg branch" puts it: "branches are permanent and global, did you want a bookmark?".

You can close a branch and it will not show up as being active but you still have the info for every commit which is what makes history readable.

Re: GitFlow considered harmful

#296
post #282

Earlier quoted context omitted.

I will get pull requests where later commits fix bugs introduced in former commits. I generally ask people to rewrite such PRs, as I’m not going to pull known buggy commits into master, even if they are followed by fixes. That is just noise. It might also be that some commits in the PR has changed tabs to spaces or vice versa.

I think the point was: if you have a PR with two commits, you can squash it to a single commit and force push. This will update the PR to just have the single commit. (Similarly with a rebase.)

sorbits' point was in response to:

clinta > Why do you need to rewrite? If a pull request is not completed, you can continue to push it and the PR is updated to pull the latest commit.

sorbits is saying that no, you really should rewrite your PR.

You, hayd, seem to be merely reiterating sorbits' point.

Re: GitFlow considered harmful

#297

Earlier quoted context omitted.

But one of the points of editing the history is to make sure that both of those are more likely to be yes -- it's to make the history easier to review historically than it would be unedited. (IMO, obviously). And this is probably partly why there's what you originally called an "obsession" with rewriting history: retroactively rewriting something 5 months old is probably going to be a disaster. But rewriting 1 day's…

Are you building and testing your edited commits as you make them? If so, that seems fair, but a lot of work. If not, I don't see how it increases the chances of good results.

All of the extra building and testing can be automated, so the extra work just becomes a matter of reorganizing the work to make logically cohesive commits and it's more work in the same sense that writing good comments is more work. Whether building and testing each commit is done as often as it should be....

I would bet that many people eyeball it, build and test the end result, and claim that that's good enough. Since many of these people probably edited out a commit with a message like "lol typo broke the build" that might be an overly optimistic attitude ;)

In any case, I don't see how it decreases the chances of good results. You already dismissed my suggestion that it's nice to have each commit build and pass tests, so it's a bit strange to start worrying about it now.

Re: GitFlow considered harmful

#298
post #280

Earlier quoted context omitted.

Agreed, most people hear "rewrite history" and immediately assume "public history". Rebase is a part of code review. If someone spots a typo and a "fix typo" commit follows it up as happens for a good proportion of GitHub model projects, I cringe. This information is uttery useless to the projects history, and should be rebased as a fixup. Only once code review is done, should a commit be considered for merge. It's a…

Then someone else rebases over that commit, there's a conflict and lo! the tests fail. Why? typo. It's fixed in the subsequent commit (which you can't see). Lovely. There's something to be said for having every commit pass tests/work (or if it doesn't saying explicitly in the commit message), if anyone is ever going to step over this commit.

That's a hard one; trying to make a single commit in a pull request helps me but sometimes even then a pull request gets ignored and they want me to rebase it.

The problem is they ask /me/ to rebase it; I think they should take a little ownership in the potential rewriting of history.

Re: GitFlow considered harmful

#299
post #72
post #24

GitLab CEO here. I agree that GitFlow is needlessly complex and that there should be one main branch. The author advises to merge in feature branches by rebasing them on master. I think that it is harmful to rewrite history. You will lose cherry-picks, references in issues and testing results (CI) of those commits if you give them a new identifier. The power of git is the ability to work in parallel without getting i…

The obsession of git users with rewriting history has always puzzled me. I like that the feature exists, because it is very occasionally useful, but it's one of those things you should almost never use. The whole point of history is to have a record of what happened. If you're going around and changing it, then you no longer have a record of what happened, but a record of what you kind of wish had actually happened.…

[deleted]

Re: GitFlow considered harmful

#300

Earlier quoted context omitted.

Please tell me what company you work at so i can avoid it. There's no other way to say it other than that your ideas horrify me.

Wow, way to be literally the opposite of constructive. Grow up.

Both this comment and its parent break the HN guidelines. Please don't post comments here unless they are civil.
Post reply on HN