Re: a few scenarios before I create my first repo [Scanned]

On 2008-12-26, Junio C Hamano [off-list ref] wrote:

What's [scanned]?

"Conor Rafferty" [off-list ref] writes:

quoted

(3) if I create a repo and commit the first baseline, can I later create
an ancestor commit to that baseline, if I subsequently find an older
version of the project lying around on the file system (or, same concept
i guess, if i find a project version that sits between say version v1.0
and v1.1 (where v1.0 is the parent tag of v1.1) can i interleave the
project files as say v1.01.

You can graft the older ones behind the root commit and filter-branch the
result to cast the graft in stone.  You are strongly recommended to do
that in one repository first, and have reasonable level of confidence in
the result before you publish it to other repositories, as running
filter-branch to rewrite the history after people (or yourself) cloned the
history to multiple places would cause trouble to thoese .

Considering the level of questions that Conor had, I thought
the following may be useful:

The way git works is that each commit is represented by a
sha-1 hash, which is an immutable 160-bit number that
"represents" that commit.  The hash of the parent commit(s),
if any, as well as the contents of the current "tree" are
inputs to this hash, so if you create or change a parent,
the hash will change.

The sanctity of these hashes is fundamental to the
distributedness of git, so when you do something like that,
you're causing problems to any other repos which "pull"ed
from you, or which you "push"ed to -- they thought your
"latest" commit had, say, hash "A", but now hash "A" no
longer exists in your repo and has been replaced by hash
"B".

I have not (yet) had occasion to use either grafting or
filter-branch, but I'm pretty sure someone would have a nice
tutorial somewhere they can point to...