Or why is that we do not like “attachments” … neither should you!

It's not just with Emails. Many office management systems such as Slack, Teams and countless others allow users to attach files and send those to others. Sounds convenient, right? But it can be downright painful and can sometimes even lead to data loss and corruption. And we are not even pointing out the obvious disadvantage: Your attachment goes thru someone else's server before reaching you! You may end up providing data to them, to train their AI!

We use the term “V-Four” to denote that often attachments lead to 4 different versions scattered around.

Here is Rohit who is a junior under Mohan. Mohan is a busy executive, who is now called to make a presentation. He delegates the work to Rohit, who dutifully prepares a PPT and then attaches it to an email (or Slack or Teams or what-have-you). It reaches Mohan, who downloads it and immediately starts working on refining it. Then he saves the new file in the right location on his computer (and not really where the email/Slack/… had downloaded it).

He then closes the laptop, and reaches the conference where he's about to present. He opens the laptop only to find that it has crashed and he now does not have time to get the file.

Before enumerating the chaos that is about to follow, let us track how many version of the PPT are now in that office:

1. The PPT that Rohit made in his laptop (V1).
2. The PPT that is now sitting in Rohit's email (or slack…) system.(V2)
3. The PPT that is downloaded in the default location of Mohan's email (or slack…) system. (V3)
4. The PPT that is in the folder on Mohan's laptop (where he has neatly organized his life) (V4)

So there are actually four different versions. Now some may say, all four are the same. Yes, to begin with all the four versions would likely to be the same. But it will not remain that way for long (usually). For e.g. Rohit may idly keep changing the PPT (V1) after he has sent it as an attachment to Mohan. Or Mohan, in his eagerness, modified the one at the default location where the attachment was downloaded (V3) and of course, the final place (V4) also gets modified.

Soon enough; all four versions of the same file are all different!

So let's come back to the desperate situation Mohan is facing: His laptop is not working and he needs to present the PPT. So he calls up Rohit, and asks him to send over the PPT file. Rohit; again in desperation, attaches the V1 file (instead of the one that was already in the previous sent-email i.e. V2)

Now, Mohan is puzzled. Not only is he staring at an old version, he possibly may not have agreed to the changes Rohit had made after Rohit had sent it as an attachment! Extremely annoying, and potentially a huge loss too.

This kind of situation happens so many times that it is best not to violate the “DRY” principle when handling files. DRY = Do NOT repeat Yourself!

Git Winch keeps a single source of truth
All work inside Git Winch is done with one strict single source of truth. Every team member knows that they can always get the very latest version from the Git Host Git Winch is configured for. Not just that; in case Mohan really does want any earlier version, he can get that instead

Learn the concepts | Table of Contents