Re: [PATCHv8 6/6] submodule: add absorb-git-dir function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 20, 2016 at 1:15 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> On Sun, Dec 18, 2016 at 9:35 PM, Duy Nguyen <pclouds@xxxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]