On Tue, Dec 20, 2016 at 1:15 AM, Stefan Beller <sbel...@google.com> wrote:
> On Sun, Dec 18, 2016 at 9:35 PM, Duy Nguyen <pclo...@gmail.com> wrote:
>> On Mon, Dec 12, 2016 at 11:04:35AM -0800, Stefan Beller wrote:
>>> diff --git a/dir.c b/dir.c
>>> index e0efd3c2c3..d872cc1570 100644
>>> --- a/dir.c
>>> +++ b/dir.c
>>> @@ -2773,3 +2773,15 @@ void connect_work_tree_and_git_dir(const char 
>>> *work_tree_, const char *git_dir_)
>>>       free(work_tree);
>>>       free(git_dir);
>>>  }
>>> +
>>> +/*
>>> + * Migrate the git directory of the given path from old_git_dir to 
>>> new_git_dir.
>>> + */
>>> +void relocate_gitdir(const char *path, const char *old_git_dir, const char 
>>> *new_git_dir)
>>> +{
>>> +     if (rename(old_git_dir, new_git_dir) < 0)
>>> +             die_errno(_("could not migrate git directory from '%s' to 
>>> '%s'"),
>>> +                     old_git_dir, new_git_dir);
>>> +
>>> +     connect_work_tree_and_git_dir(path, new_git_dir);
>>
>> Should we worry about recovering (e.g. maybe move new_git_dir back to
>> old_git_dir) if this connect_work_tree_and_git_dir() fails?
>
> What if the move back fails?

That's when you pray the UNIX gods that recovery steps don't fail :-)
This is why I don't _suggest_ to do things but just wonder about it.
In theory though, if we keep recovery to dead simple operations (e.g.
a series of rename() and nothing else) then it's less likely to fail.
I'll look at the new patches when I get home.
-- 
Duy

Reply via email to