The power of DVCS is in that each developer who clones a repository has a fully-functioning local repository complete with history, which can be committed to freely and seamlessly merged into the upstream later.
As opposed to the traditional version control model where, e.g. every commit effectively requires a rebase against the remote and the history cannot be retrieved without a connection to the remote.
The "D" in "DVCS" is about having many copies of the repository, not about having _no_ central repository, which is still a core part of having an effective delivery workflow and very much encouraged by the baked-in concept of a default remote repository.
It's a distinction of technology, not of workflow.
This is really a common misunderstanding about what makes DVCS an effective concept.
In the context of the original post, he is referring to origin (the convention for a default remote repository), not master (the convention for a default branch).
This is why vertically-sliced product teams work - they minimise the communication and coordination overhead associated with Doing a Thing(TM), while layered or function-specific teams make everything take so much longer - particularly as the formal documentation and communication overhead grows enormously when different teams are accountable for different aspects of the same system. When a small team owns an independent(-as-possible) vertical slice, accountability is shared and the need for well-documented communication is largely mitigated.
Yes, but it is also supposed to communicate the point. Which is not always possible in a tl;dr because if it was the author probably would have just written a single paragraph in the first place and saved a whole lot of time for everyone.
I have not read the article (yet; it's bookmarked for later), so I'm speaking generally, here.
> it was [possible] the author probably would have just written a single paragraph in the first place and saved a whole lot of time for everyone.
This does not fit with my experience, even disregarding things like YouTube videos which drag on in order to justify longer ads.
Writing concisely is hard, and often much more time consuming than a lengthy brain dump. It's also tempting to elaborate on every point, however tangential. I have to constantly fight this in my own writing; my desire is to be complete, but really I'm drifting off-topic, diluting my point with irrelevance, making it harder to follow.
Based on the comments above, it seems like the tl;dr missed important nuance, but that isn't always so.
I don't understand. A summary should summarise. An explanation should explain, an argument should convince, a historical overview should retell events.
Obviously, a summary can't be an explanation + an argument + history. It has to be the most salient points presented alone. Think about an abstract for a paper: it should tell you enough that you can understand if you should read the paper now, and enough context so that you can remember to read it later if your situation changes.
If you feel like the tl;dr doesn't pay full respects to the article, that's fine but I feel like not many readers will mind.
A summary is always a compromise, a judgment on which 95% of the text to leave off. Because of this, an ideal summary is hardly possible, and someone may always complain that a salient point was left out. This is not because the summary is "objectively bad", it's because the compression is lossy, and what's seen as salient differs between observers.
I quite liked the tl;dr, except that it left out how most of the article is "...and why". We've all heard the advice, but the article is trying to explain why the advice is true. I think an ideal summary would mention that.
OK, I understand. Though I think the article did a terrible job of explaining why: like, why do deadlines cause engineers to become affected by Student Syndrome? It just mentions it at a superficial level, which is perfectly fine for its purposes.
edit: also thanks for writing that article, it's great.
History is only "cleaner" because Git in its default configuration only throws the raw version graph at you and fails to visualize it in a readable fashion. With a properly structured visualization, such as Bazaar's hierarchical logs, merging is not just as clean, it actually carries more information.
In hierarchical logs, a merge commit stands for the series of commits that are being merged. You can then unfold such commits and view the series of commits as a nested list of commits (which may again contain merge commits).
Think of a merge commit as the equivalent of a procedure call where the procedure body is the series of commits being merged.
(Note that there are other ways to visualize version graphs with merge commits; this is just the simplest way to do it and could actually be easily added on top of Git.)
Rebasing has two problems. It discards the original version structure and it can create commits that never build or don't pass tests (because they never existed as such).
Frequent use of rebasing is almost always an indication that a VCS is lacking important functionality.
None of that information is too relevant. If you have the commits individually cherry picked in your stream, that's most of the info you ever need about those commits. There is some earlier version of those commits in a different stream, where they look different. Usually, who cares.
The way to track that is some sort of additional meta-data. An example of this is the Gerrit Change-ID.
Rebase is not simpler in any context - rebase rewrites history, which, if branches have been pushed to remotes, then necessitates force pushes, which in turn breaks any other instances of the same branch. By using rebase to "keep history clean" you are largely undermining git's power as a DVCS.
Rebase as a tool is not inherently bad but it is definitely not simpler than merge - it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing and in my experience most teams that are using it as a core part of their workflow are doing so for the wrong reasons (generally because of a fundamental misunderstanding of how branching and merging works in git and why it works that way).
That is not correct; rebase per se doesn't rewrite history.
Rebase is basically just cherry picks. You can rewind a branch and then cherry-pick, so that the picks are non-fastforward. That's rewriting history. Cherry picking without rolling back is fastforward, and so doesn't rewrite history.
The Gerrit review system on top of Git is based on cherry-picking; it doesn't rewrite history.
If some developers are collaborating on a feature which is on a branch, they could agree from time to time to rebase that branch to a newer mainline.
Whether or not that is done by a history rewrite simply hinges on whether the same branch name is used for the rebased branch or not. The rebase is what it is: if you plant that rewrite as the original branch name, then you have a non-fastforward change. If a new branch name is made, then it isn't a rewrite.
Merging a feature branch onto a trunk can always be done in a fastforward way using rebase/cherry-pick.
Rebasing is provably simpler than merge. Merge depends on complications in the git object representation which could be removed while rebase remains what it is. If you only ever rebase, you never see a commit with multiple parents; the feature is superfluous and turns git histories into hairballs.
AFAIK rebase always rewrites history. If you rebase your feature branch, you have at least rewritten the history of the local branch even if you then delete it and push to a new remote branch. The trunk will subsequently get a FF merge.
Rebase might give you a "simpler" end result in terms of what the history looks like but conceptually it is much less simple in terms of its mechanism and its implications (e.g. rebasing a branch with multiple contributors screws up the audit trail as it now looks like they made their changes at a different time and in a different context to when they actually did) than the idea of a graph with two branches and a merge commit.
I have seen teams with limited git experience switch from habitually rebasing public branches to accepting merge commits and suddenly cure a whole host of workflow problems.
If you can rebase directly onto a fresh branch (not something I've seen) then I am fairly sure that that's not part of your average workflow - establishing new branches every time you want to update from trunk comes with its own communication overhead too.
> > it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing
I am taught git with rebase (though merge when I use hg) so I am already too used to it. Branching then rebase is not that difficult if you keep your workflow consistent and quick iteration. You should be up to date whenever possible. Amending and rewriting history/comment also requires using rebase.
The point is that returning an Optional gives you nothing above returning a null - in fact it increases complexity and makes calling code more error-prone for no gain.
If your contract says you return a Foo, you could be returning a null. If you change that to Optional<Foo> you could still be returning a null.
It's not what Optionals are for. They are just widely misunderstood and abused.
Thank you for calling this out. I have to fight this fight way too often.
Optional is really for functional code, not for "eliminating NPEs," because it doesn't do that - in fact it means strictly speaking you have to do additional checking.
The real purpose of optional is for allowing me to do things like `foo.first().orElseGet(other)`. `first` has to return an Optional rather than a null or it will blow up.
If you are doing `Optional.isPresent()` as a straight-up replacement for null checks then you are doing it wrong. If you want to avoid returning nulls and doing null checks, use polymorphic null objects.
As opposed to the traditional version control model where, e.g. every commit effectively requires a rebase against the remote and the history cannot be retrieved without a connection to the remote.
The "D" in "DVCS" is about having many copies of the repository, not about having _no_ central repository, which is still a core part of having an effective delivery workflow and very much encouraged by the baked-in concept of a default remote repository.
It's a distinction of technology, not of workflow.
This is really a common misunderstanding about what makes DVCS an effective concept.