Hail p4, g4, svn and blessed be their monotonically increasing revision number!
Extremely Linear Git History
191–200 of 366 posts
Re: Extremely Linear Git History
#192Earlier quoted context omitted.
> If you committed something that broke unit tests your colleagues would pass you a really ugly plush animal of shame that would sit on your desk until the next coworker broke the build. We did have an ugly plush animal, but it served more obscure purposes. For blame of broken builds, we had an info screen that counted the number of times a build had passed, and displayed below the name of the person who last broke i…
It's not toxic because every single developer knows that it could be them next time around.
It is literally the definition of toxic. It is the antithesis of making it okay to fail, having the entire team to take responsibility. Instead individual mistakes are highlighted and publicly shamed. How can you possibly not think this is toxic?
Re: Extremely Linear Git History
#193I prefer a linear version number on the main branch and I have a really tiny version file that gets incremented on every change to the src/ directory. That's not entirely automated, but a commit queue could do that. Brute-forcing hash collisions seems like an April Fool's joke. You can't really be serious that people are going to do this regularly?
I don't think people actually take this project seriously
Re: Extremely Linear Git History
#194I want the 'merge' function completely deprecated. I simply don't trust it anymore. If there are no conflicts, you might as well rebase or cherry-pick. If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. Developer end up fixing additional issues in the merge commit instead of actual commits. If you use merge to sync two branches continously, you completely lose trac…
I'd like a "quick ff" that will ff if there are no conflicts, or ff as far as it can with no conflicts - and an easy way to apply to many branches.
Also, a way to "rebase" that works the same as cherry picking commits on top of the target. As far as I can see, the regular rebase works it's way up the target branch, so that I end up resolving conflicts in code that eventually changed in the target.
Re: Extremely Linear Git History
#195Earlier quoted context omitted.
I once interviewed a junior-ish developer who told me that his then-current team had a dunce cap to be worn by whomever broke the build. I copied it immediately. There was no toxicity, it was a good laugh, and as manager I wore it more than once being a bit too liberal with my commits. On another team I was on, in 2002 using CVS, we had an upside-down solo cup as a base for a small plastic pirate flag. If you were re…
> I despair about long-lived git feature branches and pull requests This comes up a lot - multiple people on this thread have even said that it's a bad idea to have a long running feature branch. This seems like a case of the tool imposing it's will on workflows, rather than enabling them. Not all features are tiny. I don't see anything wrong with a long lived branch if the feature is in fact large. After all it may…
A long lived branch was a pain even in the CVS days. I'm in particular thinking about the "aviary" branch (for Phoenix/Thunderbird) Mozilla had for quite a while.
Of course tooling can make it harder — there was no such thing as rebasing on CVS.
Re: Extremely Linear Git History
#196Earlier quoted context omitted.
It's not toxic because every single developer knows that it could be them next time around.
It is literally the definition of toxic. It is the antithesis of making it okay to fail, having the entire team to take responsibility. Instead individual mistakes are highlighted and publicly shamed. How can you possibly not think this is toxic?
Sounds like the definition of making it okay to fail.
The only consequence is a plush toy of shame on your desk until the next person fails? Yes, please.
Sounds like a great way to lighten the mood about failure.
Re: Extremely Linear Git History
#197Earlier quoted context omitted.
It's not toxic because every single developer knows that it could be them next time around.
It is literally the definition of toxic. It is the antithesis of making it okay to fail, having the entire team to take responsibility. Instead individual mistakes are highlighted and publicly shamed. How can you possibly not think this is toxic?
Toxic is not the highlighting of breaking the build with a trophy, it's what gets associated with it.
Imagine an "ugliest shirt" trophy, given out to whoever wheres the ugliest shirt of the week. At a fashion magazine, this may be toxic shaming. At a tech-heavy startup it might have people start buying the worst shirts they can to try to win it.
If the attitude associated with getting the trophy is condemnation, that's bad. If it's a reminder that everyone fucks and be careful, that's fine.
Re: Extremely Linear Git History
#198Earlier quoted context omitted.
> I despair about long-lived git feature branches and pull requests This comes up a lot - multiple people on this thread have even said that it's a bad idea to have a long running feature branch. This seems like a case of the tool imposing it's will on workflows, rather than enabling them. Not all features are tiny. I don't see anything wrong with a long lived branch if the feature is in fact large. After all it may…
A long lived feature branch is not a problem if you rebase it to master often. Move all refactoring to the beginning of the branch and merge them to master if they become too many.
> A long lived feature branch is not a problem if you rebase it to master often.
Yes but if it's a shared branch then you may have problems with this.
The safer way is to merge from master into the branch but nobody wants to do that because it's ugly.
Re: Extremely Linear Git History
#199Earlier quoted context omitted.
Using whitespace is cool, but you know what would be really cool? Using a thesaurus to reword the commit message until it matches the hash :)
... or refactor the code using an automated thesaurus and a bit of AI in a way to generate a particular hash. - Hey Bob, why did you rename the 'pick_person' function to 'choose_desirable_candidate'? - git made me do it
I was going to solve some business problems today but instead there became an urgent need to GPU accelerate the task of making my commit hash appear to have the rich semantics of "a number that goes up". Hm, I bet this old FPGA could be repurposed to add a 2x speedup...
Re: Extremely Linear Git History
#200Earlier quoted context omitted.
Unfortunately, git rebase has a very very annoying limitation that git merge doesn't. If you have a branch with, say, masterX + 10 commits, and commit 1 from your branch is in conflict with masterX+1, then when you rebase your branch onto masterX+1, you will have to resolve the conflict 10 times (assuming all 10 commits happen in the same area that had the original conflict). If instead you merge masterX+1 onto your…
In your example, you pretty much have to change the same line, or neighbouring line, those 10 times to end in that scenario. If it's just somewhere else in the file, git auto-merging will handle it just fine. It seems like a very contrived example to me. We have been running rebase/fast-forward only for close to 10 years now, and I have never experienced anything that unfortunate.
> It seems like a very contrived example to me.
I run in to this quite frequently, even on projects where I'm the only one working on it (I tend to have a lot of things going on in parallel). Once branches diverge and commits accumulate it can become a right pain. Usually my solution is to merge master into the branch just to keep up to date and then just undo everything, make one new commit in the master, and rebase that. But in some more difficult cases it was "just merge and fuck it because life's too short". I've also just manually "copy/paste merged" things to a new branch, because that seemed quicker than dealing with all the merges/conflicts.
Maybe there are better ways of doing this, and arguably I shouldn't have all these long-lived branches in the first place (but it works well for me, so...), but it's not that much of a contrived edge case.