]> git.ipfire.org Git - thirdparty/git.git/commit - remote.c
remote.c: drop "remote" pointer from "struct branch"
authorJeff King <peff@peff.net>
Thu, 21 May 2015 04:45:13 +0000 (00:45 -0400)
committerJunio C Hamano <gitster@pobox.com>
Thu, 21 May 2015 17:48:10 +0000 (10:48 -0700)
commit9e3751d4437b43e72497178774c74be1ceac28b9
treef5e84a2ac63ac6e0462b11f4e63f32417cfaac7a
parentee2499fe38d93fcbf4cbecdf83b32a495b0b12b9
remote.c: drop "remote" pointer from "struct branch"

When we create each branch struct, we fill in the
"remote_name" field from the config, and then fill in the
actual "remote" field (with a "struct remote") based on that
name. However, it turns out that nobody really cares about
the latter field. The only two sites that access it at all
are:

  1. git-merge, which uses it to notice when the branch does
     not have a remote defined. But we can easily replace this
     with looking at remote_name instead.

  2. remote.c itself, when setting up the @{upstream} merge
     config. But we don't need to save the "remote" in the
     "struct branch" for that; we can just look it up for
     the duration of the operation.

So there is no need to have both fields; they are redundant
with each other (the struct remote contains the name, or you
can look up the struct from the name). It would be nice to
simplify this, especially as we are going to add matching
pushremote config in a future patch (and it would be nice to
keep them consistent).

So which one do we keep and which one do we get rid of?

If we had a lot of callers accessing the struct, it would be
more efficient to keep it (since you have to do a lookup to
go from the name to the struct, but not vice versa). But we
don't have a lot of callers; we have exactly one, so
efficiency doesn't matter. We can decide this based on
simplicity and readability.

And the meaning of the struct value is somewhat unclear. Is
it always the remote matching remote_name? If remote_name is
NULL (i.e., no per-branch config), does the struct fall back
to the "origin" remote, or is it also NULL? These questions
will get even more tricky with pushremotes, whose fallback
behavior is more complicated. So let's just store the name,
which pretty clearly represents the branch.*.remote config.
Any lookup or fallback behavior can then be implemented in
helper functions.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/technical/api-remote.txt
builtin/merge.c
remote.c
remote.h