Live data from Hacker News

GitFlow considered harmful

endoflineblog.com

301–310 of 342 posts

Re: GitFlow considered harmful

#301
post #134

Earlier quoted context omitted.

The point of rebasing for clarity, IMHO, is to take what might be a large, unorganized commit or commits (i.e. the result of a few hours good hacking) and turning it into a coherent story of how that feature is implemented. This means splitting it into commits (which change one thing), giving them good commit messages (describing the one thing and its effects), and putting them in the right order. Rather than hiding…

I agree with you, but only for local commits that haven't been pushed to a shared repo. Rewriting local history seems no different than rewriting code in your editor. Rewriting shared history is (almost) always bad.

Making 'temporary' commits and rewriting local history before pushing to a shared repo has analogs in other revision control systems:

* In Subversion, people track patches using tools like quilt to manage them before actually putting them together into a commit.

* In Mercurial, people use `hg mq` which is like a more featureful version `git-stash`.

These are basically all ways to track a series of patches prior to 'committing' them into the code base shared with others.

Re: GitFlow considered harmful

#302
post #283

Earlier quoted context omitted.

One of the things I like about git is that I can make bad commits and fix them later. If I'm working on one feature and I'm interrupted by another task, I can commit "wip - blah", then check out a different branch and work on that. When I go back, I pick up exactly where I left off, and amend the half-finished commit into something that actually makes sense before pushing it out to the rest of the team. In the past,…

"git stash" was created for this purpose

git stash is handy. I tend to forget about stashed code, though, so I only stash stuff if I know I will pop it soon.

Re: GitFlow considered harmful

#303
post #279

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…

In my Github experience, rebasing/tidying your commits is expected before a Pull Request is merged, just like your description of Linux development. Eg, the numpy/scipy/matplotlib projects.

Unfortunately, this is not true for many repositories. GitHub's interface (i.e., the "Merge" button), encourages users to merge from the web interface, where this tidying can't happen.

Re: GitFlow considered harmful

#304

Earlier quoted context omitted.

We have a rule that you never go home at night without pushing your work, even if it's garbage. Put it in a super-short-term feature branch if needed, and push that, but don't leave it imprisoned on your machine.

There are people who follow this rule, and there are people that think disk failures are what happen to other people. Few things sting as bad as loosing hours or days worth of work.

And there are people who have good backup systems.

Re: GitFlow considered harmful

#305
post #252

Earlier quoted context omitted.

Immediate backup (I hope I'm not alone in saying this...)

I kinda hope you are, because backup and source control really should be separate functions. Obviously your source control repository should be backed up, and pushing stuff into it acts to create a backup, but you really should have a separate backup system at work as well, to cover unpushed code as well as all the other useful info contained on your computer.

I use it the same way too. I do not really see why backup should be separate from source control as there is no valuable information on my (work) computer apart from the source code, and I never spend more than a few hours without pushing.

Re: GitFlow considered harmful

#306
post #189

Earlier quoted context omitted.

You don't have to rewrite history to do this. You just have to run your tests before committing. You know, like people used to in the old days. Indeed, i think the widespread rewriting of history that goes on in the Git world makes it more likely that there will be failing commits, because every time you rewrite, you create a sheaf of commits which have never been tested. Now, in your case, it sounds like you have se…

Running test before committing locally adds a lot of friction. It often happens to me that I work on a feature in component A, and in doing so, realize that it would be great to have some additional feature in component B (or perhaps there's a bug that needs to be fixed). As long as the components are logically separate, it's usually a good idea to make those changes in separate commits. While you can do that using s…

When you come up with the idea for a feature in component B, or a bug to fix, rather than implementing it, make a note of it, and carry on with what you were doing. Once that's done and committed, you can go back to the other thing. That way, you end up with coherent separate commits, that you can test individually as you make them, without having to rewrite history. Not only that, but you can give each commit your full attention as you work on it, rather than spreading your attention over however many things.

Again, this is the traditional way of doing things (as an aside, in pair programming, one of the roles of the navigator is to maintain these notes of what to do next, so the pair can focus on one thing at a time). Seen from this perspective, history rewriting is again a way to cover up poor, undisciplined programming practice.

Re: GitFlow considered harmful

#307
post #276

Earlier quoted context omitted.

I don't understand why you ask this. I already presented my solution to the problem in the post he was replying to. That one is still valid.

Surely it isn't a great idea once "the" repo has a copy of the dodgy commit, though? Because once everybody else has a copy of it, the history hashes will include it, and removing it with a rebase is going to become more bothersome. (N.B., I am English - by "bothersome" what I suppose I actually mean is "a massive pain in the arse". Because everybody is going to have to take all their commits since the dodgy one and…

Generally it is not a good idea. But sometimes one has to admit having fucked up, put a marker on an old branch to let people know it's fucked and clean things up. Especially when the alternative is "break half of git's tools by injecting revert + revert-revert".

If i am understanding you right you seem to consider the act of rebasing itself to be "a massive pain in the arse".

In a culture where rebasing of feature branches is considered mandatory anyhow, rebasing a feature branch sideways onto a new unbroken master branch is nothing out of the ordinary and quick and easy.

Re: GitFlow considered harmful

#308
post #300

Earlier quoted context omitted.

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.

Are you serious? I was being polite and posted a question asking for some constructive feedback. I got some of this, then Mithaldu went off the deep-end and decided to start ridiculing me and tell me how he'd avoid the company I work at because of the questions I'm asking. And now you're saying that I'm the one crossing a line here? Seriously? I just re-read the guidelines, which did I break? The only one I can imagine is not flagging the comment but that was because the software did not let me since it was a reply to one of my posts.

I have been perfectly civil. Telling someone they are not being constructive and should grow up is not uncivil when it's in response to:

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

Be sure to read that again and let it sink in. This person wants to know what company I work at so he can avoid it because of a question I asked on the internet about git.

Re: GitFlow considered harmful

#309
post #300

Earlier quoted context omitted.

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.

How does that comment break HN's guidelines?

Re: GitFlow considered harmful

#310
post #300

Earlier quoted context omitted.

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

Are you serious? I was being polite and posted a question asking for some constructive feedback. I got some of this, then Mithaldu went off the deep-end and decided to start ridiculing me and tell me how he'd avoid the company I work at because of the questions I'm asking. And now you're saying that I'm the one crossing a line here? Seriously? I just re-read the guidelines, which did I break? The only one I can imagi…

It wasn't your questions that bothered me, but your ideas expressed in these posts: https://news.ycombinator.com/item?id=9744910 https://news.ycombinator.com/item?id=9744929

Your initial question was perfectly fine to me.

Further, while i think HN is inconsistent at best in how it applies its rules², i realize that dang does have a point and i could've dug further with questions, to see if your mind could be changed. However, the same applies to you just as much. Instead of accusing me of being a child³, you could just as well have asked why i recoiled in horror and thus rerail the discussion in a constructive direction, like to3m did: https://news.ycombinator.com/item?id=9745547

--

² The rules are hilariously strict, which can be a good thing, but applied to only a small percentage of rule-breaking posts.

³ Not that i particularly care.

Post reply on HN