Age | Commit message (Collapse) | Author |
|
|
|
It's the same as the post-checkout hook, doing the same job. I thought
about symlinking instead of copying, but something doesn't sit quite
right about that.
|
|
|
|
If the user is running `git commit` to resolve a conflict, it's
dangerous to just save the metadata from the filesystem. It's possible
that they just fixed a conflict in the metadata file, but didn't update
the on-disk metadata to match.
(I know it's possible, because I did this!)
Our normal mode of operation, of just saving the metadata during a
commit to match whatever's on-disk, would wipe out their careful
conflict resolution! (On the other hand, just overwriting the on-disk
metadata might not be the best idea either.)
But the point of a conflict is that the changes between two different
branches *can't* be resolved automatically, and requires manual
intervention. Given that situation, asking them to resolve the
difference manually seems to be the most obvious option.
|
|
Previously after first metastore commit, metastore -c would show
./.metadata: added
which was misleading.
Now metastore -s is run twice if .metadata is not in repository yet.
|
|
|
|
|
|
Fixes #26.
|
|
|
|
|
|
This is analagous script to the pre-commit one, but it applies metadata
automatically after a git checkout.
Signed-off-by: Przemyslaw Pawelczyk <przemoc@gmail.com>
|
|
Scripts seem to be POSIX shell conformant, so no need to be specific.
Signed-off-by: Przemyslaw Pawelczyk <przemoc@gmail.com>
|
|
|
|
Hooks now run with stdin closed (since Git version 1.5.4) and prompting
will not work when using a high-level interface such as git-gui or Emacs
anyway.
|
|
|