This is another reroll of the pre-vtable part of the refs-backend
patch series dt/refs-backend-pre-vtable. v6 [1] proved cumbersome
because it conflicted messily with lf/ref-is-hidden-namespace [2]. The
conflicts were partly due to the motion of code across files but, even
worse, due to the change of order of function definitions between old
and new files.
So I have heavily "optimized" this reroll for reviewability and to
minimize conflicts with other work in the area. The only such work
that I know of is lf/ref-is-hidden-namespace, which can now be merged
with this series *without conflicts*.
Changes since v6:
* It doesn't move refs.c to the refs/ subdirectory, as v6 did.
Instead, leave the shared code in the existing file, refs.c.
* Don't rename refs.c to refs/files-backend.c and then selectively
move content back to refs.c. Instead, move content only once and
only in one direction, namely from refs.c -> refs/files-backend.c
(in patch 08/11). This is a giant commit but *it makes no other
changes* so it should be easy to review. (The "--patience" option of
"git diff" is quite helpful here. It was turned on when this patch
series was generated.)
* Preserve the order of code during the move. Aside from a few lines
of boilerplate, each of the following commands, when applied to
commit 08, shows only lines being deleted:
git diff --patience $commit^:refs.c $commit:refs.c
git diff --patience $commit^:refs.c $commit:refs/files-backend.c
* To make all of the above possible, patches 01 through 06 do a little
bit of preparatory code untangling. These commits have themselves
been split up a bit to make them as "obviously correct" as possible.
Patch 07 creates the new header file, refs/refs-internal.h, thereby
increasing the visibility of some declarations.
* The final patches 09, 10, and 11 are not quite as "obviously
correct" as the first eight, but I left them in to keep the logical
contents of this patch series the same as v6. But these last three
commits could just as well be postponed until the next tranche of
patches if that helps speed the way of the first eight patches into
master.
* I also fixed a commit message and fixed the implementation of the
new verify_refname_available() function to return a negative number
on error as documented (previously it returned 1 on error).
I've tried to attribute authorship of these changes as fairly as
possible based on who initiated the corresponding changes. If anybody
feels that I have appropriated his work or, conversely, put words into
his mouth, just let me know and I would be happy to adjust the
authorship.
It would be great to get this patch series (at least the first eight
patches) reviewed and merged as soon as possible. Even though it no
longer conflicts with lf/ref-is-hidden-namespace, it is still very
prone to conflicting with any other work in the references code.
This patch series is also available on my GitHub fork [3] as branch
"refs-backend-pre-vtable".
Michael
[1] http://thread.gmane.org/gmane.comp.version-control.git/280325/focus=280754
[2] http://article.gmane.org/gmane.comp.version-control.git/281004
[3] https://github.com/mhagger/git
David Turner (5):
refs: make is_branch public
copy_msg(): rename to copy_reflog_msg()
initdb: make safe_create_dir public
files_log_ref_write: new function
refs: break out ref conflict checks
Michael Haggerty (4):
pack_if_possible_fn(): use ref_type() instead of is_per_worktree_ref()
refname_is_safe(): improve docstring
refs/refs-internal.h: new header file
refs: split filesystem-based refs code into a new file
Ronnie Sahlberg (2):
verify_refname_available(): rename function
verify_refname_available(): new function
Makefile | 3 +-
builtin/init-db.c | 12 -
cache.h | 8 +
path.c | 12 +
refs.c | 3709 +---------------------------------------
refs.h | 2 +
refs.c => refs/files-backend.c | 1287 +-------------
refs/refs-internal.h | 202 +++
8 files changed, 315 insertions(+), 4920 deletions(-)
copy refs.c => refs/files-backend.c (75%)
create mode 100644 refs/refs-internal.h
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html