kannonboy

12 ms·

61.
Git 2.4 is out!(repo.or.cz)
2 points by kannonboy 11y ago|0 comments
62.
Zero to Bitbucket in three weeks(developer.atlassian.com)
11 points by kannonboy 12y ago|0 comments
63.
by kannonboy 12y ago
I was curious about this too. I don't use Slack, do they enforce a password complexity and use a bcrypt work factor high enough to justify not requiring a reset?
64.
by kannonboy 12y ago
There's a (paid, third-party) add-on for Stash that implements Snippets: https://marketplace.atlassian.com/plugins/com.simplenia.stas... I haven't tried it myself though.
65.
by kannonboy 12y ago
One of the Bitbucket engineers put a one-liner in the comments on the post that will generate diff-like output similar to what you're describing: https://developer.atlassian.com/blog/2015/01/a-better-pull
66.
by kannonboy 12y ago
That would solve the issue until master progresses again. The problem is that on many projects the master branch will progress during the lifetime of a pull request.
67.
by kannonboy 12y ago
From my experience, Github does attempt a merge commit behind the scenes and indicates that a PR can't be merged via the UI if there are conflicts. However, it still just shows the diff from the merge-base to the tip of your feature br
68.
by kannonboy 12y ago
This is tricky to pull off on busy projects, as master is continually progressing and all open pull request branches would need to be constantly rebased. With the Bitbucket approach, you get to see the conflict in the pull request UI, but y
69.
by kannonboy 12y ago
Great point. Almost all of the problems I've seen with pull requests and branching workflows stem from the size of the change. If you can avoid long-lived branches / giant diffs, most integration problems just disappear. It's
70.
by kannonboy 12y ago
In Bitbucket's implementation you still only see the changes that are unique to your branch, but they're diff'd against the current tip of master rather than the merge base.
71.
A better pull request(developer.atlassian.com)
479 points by kannonboy 12y ago|161 comments
72.
How to revert an octopus merge(developer.atlassian.com)
4 points by kannonboy 12y ago|0 comments
73.
Using octopus merge to deploy multiple branches to a single staging server(developer.atlassian.com)
1 points by kannonboy 12y ago|0 comments
74.
by kannonboy 12y ago
You might've missed Linus' second comment on the page, wherein he talks about case-insensitivity and NFD normalization.
75.
by kannonboy 12y ago
Scroll down for Linus' commentary. > "The true horrors of HFS+ are not in how it's not a great > filesystem, but in how it's actively designed to be a bad > filesystem by people who thought they had good ideas.&
76.
Linus Torvalds on HFS+(plus.google.com)
177 points by kannonboy 12y ago|119 comments
77.
Securing your Git server against CVE-2014-9390(developer.atlassian.com)
1 points by kannonboy 12y ago|0 comments
78.
What's new in Git 2.2.0(developer.atlassian.com)
17 points by kannonboy 12y ago|1 comments
79.
Git workflows for SaaS teams [video](youtube.com)
2 points by kannonboy 12y ago|0 comments
80.
What's new in Git 2.1(blogs.atlassian.com)
126 points by kannonboy 12y ago|31 comments
81.
by kannonboy 12y ago
True, I built it in JS for the library support, but there's no reason I couldn't rewrite essentially the same thing as a shell script.
82.
by kannonboy 12y ago
Thanks! I'd have to spend a lot of time dusting off my C skills before considering contributing to git core. If enough people find it useful it's always a possibility.
83.
Show HN: Git-guilt – view blame change over time(blogs.atlassian.com)
9 points by kannonboy 12y ago|4 comments
84.
Vive la git diff(blogs.atlassian.com)
6 points by kannonboy 13y ago|1 comments
85.
Show HN: Firepad-based editor for Stash(blogs.atlassian.com)
2 points by kannonboy 14y ago|0 comments