This is an old revision of the document!
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 variations of the same file 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 variations of the same PPT are now in that office:
In short, there are actually four different variations.
Now some may say, all four are the same. Yes, to begin with all the four 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 variations of the same file are all different internally!
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. There are no separate variations of the same file anywhere in the office. Not just that; in case Mohan really does want any earlier version, he can get that instead
Difference between a variation and a version
In the above document, the word “variation” means a file which originally was the exactly the same as some other file, but then someone made some changes to it. The “variation” will be a separate file.
A “version”; on the other hand, is the same original file which was consciously edited and overwritten the original. So one can have multiple “variation” files, but at any point in time there is only one “version” file, and that is always the original.