lets say a repo is in working state. we check out the latest thing. then we want to make additions to the code base. we create several files here and there. some of it is wired correctly, some of it is not.
while designing commits, we might think that we are making an atomic commit, atomic as in, the commit represents next consistent and sane snapshot of the repo, when we are selecting changes to put in a commit.
not only does the code present in the commit, not reference things in files not in the commit, but internally as well, the wiring is sane.
the code base itself runs on the entire gamut of files present in the repo, the trickery comes on part of the untracked files. what if one of the file we put in a commit, depends on some code outside, that we forgot to include in the commit? so there's no enforceability except if we could #18
lets say a repo is in working state. we check out the latest thing. then we want to make additions to the code base. we create several files here and there. some of it is wired correctly, some of it is not.
while designing commits, we might think that we are making an atomic commit, atomic as in, the commit represents next consistent and sane snapshot of the repo, when we are selecting changes to put in a commit.
not only does the code present in the commit, not reference things in files not in the commit, but internally as well, the wiring is sane.
the code base itself runs on the entire gamut of files present in the repo, the trickery comes on part of the untracked files. what if one of the file we put in a commit, depends on some code outside, that we forgot to include in the commit? so there's no enforceability except if we could #18