I think that I have not properly communicated what we are doing and why we
are asking for this thing that seems irrational.
Before trying to do that, let me respond to a few other things.
If you had a pre-merge hook, then it would run even on local merges between
> branches.
>
This is where a pre-merge hook is a problem. It will drive the devs nuts
every time they merge a local branch.
The "magic" of a fetch is simple: copies of objects in other repos wind up
> in your repo unaltered, and remote branch pointers are updated. In
> particular, there is no need for a fetch to be followed by a merge.
You can do a fetch any time you want to know "What is Alice doing now?".
>
Yes. We all understand this. I promise. We know that a fetch is safe.
We know that it does not alter the local repo.
> We definitely want to avoid having different versions of
> merge/fetch/pull/etc. because we don't want the devs to have to remember to
> do the special thing. Besides, we already have a special 'pull'.
>
> Umm ... why?
>
You might be asking one of two things:
* Why do we have a special 'pull'? I'll try to explain better below.
* Why don't we want different versions? Because we need a fail-safe, not
a safety procedure. We already have a safety procedure (the special pull).
Which, now that I think about it, really means a post-merge check, not a
> pre-fetch check. Because remember, if you do a fetch, you're seeing what
> the other person has, including the other person's state of that shared
> updated data. Any changes to that shared updated data happens on your merge
> of their data.
>
This was the statement that made me certain that I had not explained well
enough. A post-merge will not do. Apologies for not explaining very
well. Please read on.
We want a fail-safe that does these things:
* Happens in the course of normal work with no special or different dev
behavior. So, it needs to be a hook and not a separate command.
* Adds as little overhead to the developer's job as possible (this is why
we don't want it on 'merge').
I find that this is not easy to explain. Please say if anything seems not
to make sense.
Here is the setup:
Developer A has made changes to the data in the database, but *has not*
dumped the data to the file that is git-managed.
Developer B has made changes to the database data and *has* dumped the data
to the file. Dev B commits the changes and pushes them up to the shared
repo.
Developer A gets distracted for a minute or a week and forgets about the
changes to the data. Dev A fetches and merges the changes from Dev B.
At this point, we do not yet have a problem. But, we probably will very
soon because one of these two things is likely to happen:
Situation 1: Dev A loads the data from Dev B into the database,
potentially overwriting, in a non-recoverable way, the changes made by Dev
A. If Dev A is lucky, Dev B was working on something else. But... there
is no way to know because the data were not in git's purview.
Situation 2: Dev A remembers about the data, but doesn't realize that Dev
B changed the data, and dumps it (A's data) to the git-managed data file,
overwriting Dev B's data. This is a recoverable situation. But, it could
be months before the problem is noticed, and at that point, it could take
many person-hours to find and fix it.
We want, and desperately need, for git to produce merge conflicts for this
data when there are colliding changes. But, git cannot produce a merge
conflict if Dev A has not dumped the data to a file that git manages before
merging with the changes Dev B made. So, we need to make sure that the
data is in git's graph before any merging happens.
We want a pre-fetch (or post-fetch) hook for these reasons:
* It conveniently targets only problems that might be introduced by
receiving data from *external* sources. That is, it doesn't interfere with
local repo activities like merging branches. We know that a fetch is
safe. But, a fetch happens to be special in that it is a *fetch*. So,
before I fetch, I want to make sure that I'm in a state where receiving
external data is safe. In other words, if my house isn't in order, there's
no point inviting guests. A post-fetch hook is ok. A pre-fetch hook just
saves the time waiting for the fetch to complete before finding out that
you still have housework to do. To say that another way: what is in the
fetch is not the problem. The problem is what isn't yet in the local repo.
* It does this without making the dev have to remember to run a separate
script or manually inspect the changes coming in.
* it tries to prevent the dev from having to revert commits or dig through
histories, etc.
* It stays as much as possible out of the way of other normal activities.
This is, as I said, why a pre-merge hook isn't preferred.
Our special 'pull' just checks to be sure that the data in the git-managed
files matches the corresponding data in the database. If it does not, the
dev is
