On Mon, Dec 2, 2024 at 4:57 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> While [Torek's sequence of commands] would _work_ in the sense
> that you can revert the effect of what the discarded commits
> did, I would not recommend any of the above since it does not
> leave any record of what you discarded.
[alternate method with `git merge -s ours --no-ff` snipped, but note
that it will do this:]
> - Record the discarded history (i.e. master@{1}) as the side branch
> of the resulting history.
This is a good point and illustrates the key issue I left out.. I was
describing (and kind of deliberately hammering on, for teaching
purposes) the fact that every commit node in the commit graph
records the _full state of all files_ as of that particular commit.
Hence if the only thing you care about is "state of files", that's
also the only part of a commit that matters.
But commits do one other thing, in addition to the usual housekeeping
work of remembering who made them and when and a log message.
That specific other thing is: each commit remembers a list[1] of
_previous commits_, and stringing this commit up after its
predecessor(s) is what produces "history".
That is, Git does not _store_ history (specifically, history of files).
Instead, it stores the _information needed to discover history
any time you wish to discover it_. The list-of-previous commits
is how this works. Using a merge allows you to store a list of
_two or more_ previous commits. The _first_ entry in this list,
which is often the only entry, is what we think of as "the immediate
previous commit", and following this list-of-first-entries gives you
the history of what happened to each file.
Second (and additional) list entries, if present, help you figure
out _how_ you got this particular version of every file in this
particular commit, in the usual merge cases. In unusual cases
(such as Junio's method here) it can help you figure out what
you deliberately left behind, and the fact that the new commit is
a merge commit -- a commit with two or more parents, instead
of just one -- is a clue that something out of the ordinary
occurred.
[1] I say "list" instead of "set" here because order matters:
the first entry is special. "Set" would also imply de-duplication.
While the list entries don't normally contain any duplicates,
there's nothing in the machinery to prevent them. What (if
anything) such duplicates might mean -- well, that's up to you.
Chris
