canpolat

joined 1 year ago
MODERATOR OF
git
71
The Stupidity Manifesto (insimpleterms.blog)
submitted 9 months ago* (last edited 9 months ago) by [email protected] to c/[email protected]
 

The Stupidity Manifesto

LET’S STOP MAKING EACH OTHER FEEL STUPID. Instead, let’s…

  • ENCOURAGE EVERYONE TO ASK QUESTIONS
  • Lead by example: Be honest when we’re confused
  • Value curiosity over knowledge
  • Prioritise clarity over jargon
  • Remember we all forget stuff
  • Get excited about teaching and learning
  • Acknowledge the broad range of knowledge in our industry, and avoid judging someone if their knowledge doesn’t match ours
  • LET’S STOP MAKING EACH OTHER FEEL STUPID.
 

Do you have a story to share?

[–] [email protected] 6 points 9 months ago (2 children)

Please also consider posting to [email protected]

[–] [email protected] 1 points 11 months ago* (last edited 11 months ago)

That's explained at the end (Revisions). Fowler is probably looking for a general term that can be used to describe this specific way of debugging. Since he is aware of git bisect (and I'm sure he knows about hg bisect) there must be a reason he is not preferring "bisect debugging," for example.

Edit: The term diff has a clear link with version control. bisect is not that obvious. It may be ambiguous/vague in debugging context. I would still call it "bisect debugging."

[–] [email protected] 4 points 1 year ago (1 children)

Beginning in Git 2.43, Git will realize when it’s about to perform a double-revert, and instead produce the much more pleasing message

Doesn't happen very often, but I'm glad we have a better solution to this now.

[–] [email protected] 7 points 1 year ago

This sounds more like a Github question.

[–] [email protected] 1 points 1 year ago

Reading the manual? That's cheating!

[–] [email protected] 5 points 1 year ago (1 children)

Apart from the historical value, the most important part of this article now is the "Note of reflection" added 10 years after it's inception:

If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

I don't think this work flow is relevant any more even for teams that don't do CD, to be honest. It was a messy work flow to begin with and I haven't seen it applied successfully in practice.

view more: ‹ prev next ›