Earlier quoted context omitted.
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?
Telling someone to "grow up" is obviously uncivil.
GitFlow considered harmful
321–330 of 342 posts
Re: GitFlow considered harmful
#322Earlier quoted context omitted.
> Are you sure you wanted to say merge? If the master branch is rewritten into a new branch, feature branches on it would need to be rebased normally. Yes. The way we currently do things is keeping things as simple as possible for everyone, even if this doesn't produce the prettiest history. A developer first creates their feature branch based off of master, commits several times to this feature branch, tests it and…
Merging feature branches off of one branch that was rewritten into a new one into the new one is nothing anybody would ever do or recommend. Rebasing is a requirement here, and truthfully an operation with less mental overhead, since it's actually just "copy all of those commits over to here, then put the branch marker at the end of the new copy". It kind of sounds to me as if you're saying "i don't want my developer…
> Merging feature branches off of one branch that was rewritten into a new one into the new one is nothing anybody would ever do or recommend. Rebasing is a requirement here, and truthfully an operation with less mental overhead, since it's actually just "copy all of those commits over to here, then put the branch marker at the end of the new copy".
I'm not even sure what you're trying to say here. In general we don't rewrite history of shared branches thus rebasing is certainly not a requirement.
> It kind of sounds to me as if you're saying "i don't want my developers to not learn rebase because it's easier if they learn a little less". Is that a correct understanding? If so, then you're trading a little upfront work for a lot of cleanup work later on.
They're not my developers. I'm one of the developers. I'm trying to educate my coworkers more in the ways of the git, but it's slow progress. There has been no cleanup work so far, mostly because we're not obsessive over having a "clean history", and are instead more than happy with a realistic one.
> Depends on how shared they are and how big the fuck-up is. Everything is relative.
It's not a fuck-up. Bugs happen, noticing and fixing them is progress. The revert commit references the issue tracker, and this itself is valuable history. Instead of the commits simply disappearing for a time.
> That developer gets a notice to get his shit together and gets fired if he persists. This is teamwork, not cowboy work.
Git is there to faciliate teamwork, not to get in the way.
Re: GitFlow considered harmful
#323Earlier quoted context omitted.
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. S…
When did I dismiss the idea that all commits should build and pass tests? That's certainly what I aim for.
Re: GitFlow considered harmful
#324Earlier quoted context omitted.
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.
Backups of your work computer would close that hours-long window between pushes.
Re: GitFlow considered harmful
#325Earlier quoted context omitted.
Merging feature branches off of one branch that was rewritten into a new one into the new one is nothing anybody would ever do or recommend. Rebasing is a requirement here, and truthfully an operation with less mental overhead, since it's actually just "copy all of those commits over to here, then put the branch marker at the end of the new copy". It kind of sounds to me as if you're saying "i don't want my developer…
> Merging feature branches off of one branch that was rewritten into a new one into the new one is nothing anybody would ever do or recommend. Rebasing is a requirement here, and truthfully an operation with less mental overhead, since it's actually just "copy all of those commits over to here, then put the branch marker at the end of the new copy". I'm not even sure what you're trying to say here. In general we don'…
Just to remind you of what the context of this discussion is:
You commented on an article that says, paraphrased: "Stop merging criss and cross y'all, it's dumb and counterproductive; rebase everything instead, it'll help you in the long run."
In that context, you asked "well merge commits are easily to revert, if i can't merge, how to i revert a feature branch?"
I answered to that, in the context given by the article on which you were commenting. That context is: "Rebasing all your things is mandatory."
As i said in my previous post, if you're not willing to even mentally adopt that context, then nothing i can say would be helpful.
Are you interested in doing that?
--
> we're not obsessive over having a "clean history", and are instead more than happy with a realistic one.
I deeply resent the implication. This kind of stance is what led me to my initial post you took offense to. What you perceive as obsession is experience and knowledge by people who have experienced both sides of the coin, along with their benefits and pains, and made a rational decision on which is more favourable in the long term.
You won't find me accusing you of obsession with fixed history just because you haven't had the (mis)fortune to make the full range of experiences on this.
> Instead of the commits simply disappearing for a time.
Nothing disappears, that is specifically why i mentioned tags. If one abandons a branch and the history is valuable to keep around, you stick a tag on the end of that branch, give it a description pointing at the ticket, then put a similar tag on the end of the remade branch, and off you go.
> not to get in the way.
How is git getting in the way of teamwork in your opinion?
> It's not a fuck-up.
Bugs are fuck-ups. There are no two ways around that. Especially when they're bad enough that a feature branch would be removed wholesale, and not simply disabled with a flag.
Re: GitFlow considered harmful
#326Earlier quoted context omitted.
> Merging feature branches off of one branch that was rewritten into a new one into the new one is nothing anybody would ever do or recommend. Rebasing is a requirement here, and truthfully an operation with less mental overhead, since it's actually just "copy all of those commits over to here, then put the branch marker at the end of the new copy". I'm not even sure what you're trying to say here. In general we don'…
Just to remind you of what the context of this discussion is: You commented on an article that says, paraphrased: "Stop merging criss and cross y'all, it's dumb and counterproductive; rebase everything instead, it'll help you in the long run." In that context, you asked "well merge commits are easily to revert, if i can't merge, how to i revert a feature branch?" I answered to that, in the context given by the articl…
Maybe you two could have this discussion in email?
Re: GitFlow considered harmful
#327Earlier quoted context omitted.
Yeah that's why you squash your 12 commits into a single commit that represents the deliverable. This is my point I find the 12 commits to be unnecessary. I've never been burned by squashing. The only arguments I've heard against it are ideological(you're destroying history, etc.)
oh! Well, I like reading many little diffs more than I like reading a few big diffs, but the distinction is purely aesthetic. A team should try to agree on an aesthetic, but otherwise, ::shrug::.
Its not exactly aesthetic. Little diffs and big diffs are not isomorphic. They could conflict with eachother. The only true diff is either diffing a squashed commit or diffing over the whole range. And if you are diffing over a range all the time you might as well be squashing and rebasing so you get the benefits of linear history.
This is my primary complaint regarding rebasing and no-ff. It leaves all these useless and confusing commits around. A lot of times the content of the commit was undone by a commit in the family. Its usually not useful to anyone and can only be reasoned about by the original author. When you merge all that crap lands in `master`
Interestingly I think I am actually learning something during this thread. The hardcore `no-ff` actually misunderstands rebase. They find the billion crap commits to be disruptive as well and want the merge commit so they can get rid of that mess. But I just say the mess is unnecessary. Just squash and you get the best of all worlds. You'll never miss those 12 commits
Re: GitFlow considered harmful
#328Earlier quoted context omitted.
This. So much this. I hate looking through history and seeing crap like "lol forgot semicolon". Rebasing when you're still in your feature branch before the code hitting master to make your commits succinct, readable and above all not contain known broken code is a must.
Why are you committing code you haven't even tried to build? In the scenario you're presenting, the problem is that somebody even needed a "lol forgot semicolon" commit in the first place. Stop doing that. We all make mistakes and this will come up sometimes, but if it's happening so often that you need to rewrite your VCS history to stop from annoying other people, something is wrong.
Because people make mistakes? Not all test suites are 100% perfect so bugs go missed? That's the point of a pull request and code review. I get that mistakes happen but we don't need a record of your mistake and subsequent fix in master (unless it's already in master. Then that history is sacred). Just squash the appropriate commits (--fixup is my favoritist thing ever) before merging to master and send the right code to public history the first time.
Re: GitFlow considered harmful
#329Earlier quoted context omitted.
I recommend regularly updating your branch of master via fast-forward. That way if you are working with a slightly different git history, git will complain loudly (refuse to update). This also has the benefit of complaining if someone else has force pushed (changed history / removed commits) to upstream/master. Catch it early. https://leanpub.com/sanegit (I consult/train on this in SF/Bay area.)
I'm not sure I understand how this will solve my problem to be honest, and unfortunately it's not something we would seek to hire a consultant for.
I guess it's unclear what you meant by "mess". Some companies think training their devs is worthwhile, especially after losing days/work/$ through git messes. :)
Re: GitFlow considered harmful
#330Earlier quoted context omitted.
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 f…
It's possible that we just have different styles of working. Still, to clarify: Not all, but some of the situations I have in mind are situation where the changes in component A cannot possibly work without the changes in component B. So an alternative workflow could rather be: Stash all your changes made so far, then do the changes in component B, commit, and then reapply the stashed changes in component A. That's s…
I agree that the situation where you need the changes in B to make the changes in A is both genuine and annoying!
I have often taken the stash A - change B - commit B - pop A - finish A route. If you know what changes to B you need, it's fine, but you're right, the changes to A can be useful context.
In that case, you can make the changes to B with the changes to A still around, then stash A, run the tests, commit, pop A, and continue. Then you can have the best of both worlds, and you still don't need to edit history.
If you just can't make the changes to B without the changes to A, then they probably belong in a single commit, and you've just identified a possible coupling that needs refactoring as a bonus.