Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Why we don't delete branches in Plastic?

Thursday, August 23, 2018 0 Comments

Sometimes users ask if it is possible to delete branches in Plastic. They want to get rid of them after the branch is merged because they are worried about polluting the repo with countless branches.

If you are a hard-core Plastic user you might think why someone would want to remove a branch with changesets on it. The reason is because these users have a very Git-centric view of version control.

So, if you are new to Plastic, and found this blogpost when trying to find how to "delete branches", I'm sorry to say the answer is NO, we don't delete… but for a reason :-)

We preserve history because it is great to do a diff, or a blame of a file, and find the branch where it was done, and the direct link to the associated task with all the extra info it contains.

We also preserve branches because… Plastic doesn't break with dozens of thousands of branches, not the core, nor the GUIs… unlike Git.

In the following topics, I'm going to explain the whys in detail.

Plastic GUIs don't struggle with thousands of branches… unlike Git GUIs

In Plastic, there are several ways to filter branches to focus on the most recent history.

In the branches view, it is possible to customize the query to show only the branches with changes in the last N days:

Additionally, in the Branch Explorer, it is possible to perform different types of filtering:

  • By date: focusing only on the last few weeks makes a lot of sense (and the graphics will load much faster):
  • Filter branches related to a given branch: something I personally use all the time:

There are many other options, but these two are the ones we use most often.

On the other hand, Git GUIs tend to have trouble dealing with tons of branches. From using drop-downs or lists to handle them (a no-go when the number is high, UX-wise) to simply crashing when a repo has over 1k branches. The core, as far as I know, doesn't suffer as much as the GUIs, but people in Git tend to get rid of them once they are merged.

Core branching differences between Git and Plastic

That being said, let me explain why we do not delete branches in more detail.

As I mentioned, in the Git world it is extremely common to remove branches once they are merged. There are several reasons for this.

1) Branches in Git and Plastic are different. In Plastic, branches are containers, while in Git they are just pointers.

This means that in Git is very easy to lose where a commit came from, while in Plastic, changesets always belong to a single branch and their history is preserved.

We see Plastic acting like a wise librarian — preserving history for the sake of not repeating mistakes and creating lots of knowledge from previous work.

(I wrote a full blogpost about it).

I really like to show the blame of a file, spot a given line, and immediately see which was the task branch in which it was created. This gives me lots of context. In Git you simply lose that.

Yes, that's why they like to squash branches, delete them and so on, but we have a radically different vision about all that. We like to tell a story on each checkin, to help reviewers speed up their work, instead of grouping tons of changes together into a single changeset ready to be merged. It is an underlying different viewpoint.

2) Most Git GUIs crash with lots of branches. We have 11k branches in our repo. Plastic doesn't break. We have customers with way more than that. In Git, you need to delete branches because GUIs are not ready to deal with them. Open two of the most popular Git GUIs out there with as few as 1k branches and watch them crash. Not that they are mistaken or anything — they simply follow a different way of working. We optimized all our tools to be ready to deal with limitless numbers of branches.

Conclusion

We strongly recommend using task branches — short-lived branches where an individual developer works to complete a task. They are merged after as little as a couple of hours of work and never more than a couple of days (and this number is already too high in most cases). Of course, it means a big team can create thousands of branches in a very short period. That's fine; we designed Plastic around this concept. No need to remove part of the history by removing branches; it is ok to keep them around.

0 comentarios: