deiwin
Re:Amazon EKS Windows Container Support Now Generally Available
on Wednesday October 09, 2019 @11:59AM (#21204436)
How does licensing work for this?
Productionproofing Amazon EKS
Re:Four rules for effective collaboration – Guidelines for better commits
on Thursday March 08, 2018 @12:26AM (#16542499)
Also, the ticket and the commits can provide answers to the same questions without being redundant. The answers are just at a different level of abstraction and for different readers. Tickets usually describe product-level decisions, while commits describe implementation-specific details. E.g. a ticket may discuss alternative user flows, while a related commit explains why a specific algorithm, module, or default configuration value was used.
Re:Four rules for effective collaboration – Guidelines for better commits
on Wednesday March 07, 2018 @04:49PM (#16540244)
What makes you say that? The Focused rule from the article is also meant to persuade you to split the work into similarly concise and focused commits.
Re:Four rules for effective collaboration – Guidelines for better commits
on Wednesday March 07, 2018 @02:07PM (#16538898)
One Size Fits All, probably.
Re:Four rules for effective collaboration – Guidelines for better commits
on Wednesday March 07, 2018 @10:23AM (#16536956)
Tying the ticketing system and the repository together is a good idea and definitely worth implementing, but there's a fine balance in deciding what context should be kept in the ticket and what in the code repository. If you put too much into to the ticket and too little into the commits, then git blame loses it's value, for example.
Re:Four rules for effective collaboration – Guidelines for better commits
on Wednesday March 07, 2018 @10:19AM (#16536926)
Thinking that providing additional context for commits is a waste of time is short-sighted. Yes, it requires more time and effort in the short-term (i.e. for creating the commit), but if it's a complex, long-lived project, then that extra effort will save a lot of time in the long run.
Sometimes the extra time and effort is already made up for in the review process, which without proper context could drag out and cause a lot of back and forth. Sometimes it might save somebody hours and days of investigation time. This is not to mention the benefits that both the author and the readers of the commit get by better understanding both the problem and the solution.
Re:Four rules for effective collaboration – Guidelines for better commits
on Wednesday March 07, 2018 @09:47AM (#16536697)
Where did you find the 7 character suggestion? 7 used to be the default suggestion, but the problem of collisions has been acknowledged and dealt with by the git project. Linus himself authored the change that made the abbreviated revision length vary based on the size of the repository: https://github.com/git/git/commit/e6c587c733b4634030b353f402.... Also, the command for creating references to other commits which comes from the git project and is linked to in the article also uses automatic abbreviation length.
Re:Four rules for effective collaboration – Guidelines for better commits
on Wednesday March 07, 2018 @07:36AM (#16535936)
You're correct. There are more fundamental conditions that have to be met for effective collaboration.