If git_config_rename_section() fails, rename_ref() used to return 1, which
left HEAD pointing to an absent refs/heads file (since the actual renaming
had already occurred).
Signed-off-by: Lars Hjemli <hjemli@xxxxxxxxx>
---
On 4/5/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> Hi,
>
> On Thu, 5 Apr 2007, Geert Bosch wrote:
>
> > Make git_config_rename_section return success if no config file
> > exists.
>
> I don't think this is correct. git_config_rename_section() _should_ return
> an error.
>
> > Otherwise, renaming a branch would abort, leaving the repository in an
> > inconsistent state.
>
> This should take the hint from --rename-section, and print a warning (or
> not).
I think both arguments makes sense. There really is no reason to abort the
rename operation if the config file update fails (for any reason).
refs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index f471152..2ac6384 100644
--- a/refs.c
+++ b/refs.c
@@ -835,7 +835,7 @@ int rename_ref(const char *oldref, const char *newref, const char *logmsg)
snprintf(oldsection, 1024, "branch.%s", oldref + 11);
snprintf(newsection, 1024, "branch.%s", newref + 11);
if (git_config_rename_section(oldsection, newsection) < 0)
- return 1;
+ error("unable to update config-file");
}
return 0;
--
1.5.1.53.g77e6f
-
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