On Sat, Aug 10, 2013 at 9:07 AM, Felipe Contreras
wrote:
> On Sat, Aug 10, 2013 at 1:50 AM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> If I clone ~/git, and then change my username, and move my home
>>> directory, doing a 'git fetch' in ~/git wouldn't work anymore, because
>>> we h
On Sat, Aug 10, 2013 at 1:50 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> If I clone ~/git, and then change my username, and move my home
>> directory, doing a 'git fetch' in ~/git wouldn't work anymore, because
>> we have expanded the path and fixed it to my old home, if instead we
Felipe Contreras writes:
> If I clone ~/git, and then change my username, and move my home
> directory, doing a 'git fetch' in ~/git wouldn't work anymore, because
> we have expanded the path and fixed it to my old home, if instead we
> simply return without fixing, it would still work just fine.
On Sat, Aug 10, 2013 at 12:18 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> Hmph, do you mean the third example of this?
>>>
>>> $ python
>>> >>> import os
>>> >>> os.path.expanduser("~/repo")
>>> '/home/junio/repo'
>>> >>> os.path.expanduser("
Felipe Contreras writes:
>> Hmph, do you mean the third example of this?
>>
>> $ python
>> >>> import os
>> >>> os.path.expanduser("~/repo")
>> '/home/junio/repo'
>> >>> os.path.expanduser("~junio/repo")
>> '/home/junio/repo'
>> >>> os.path.
On Fri, Aug 9, 2013 at 6:39 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Fri, Aug 9, 2013 at 5:15 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
> OK, I think I see why you are puzzled.
>
> Cloning works fine because we "fix the path" *after* the clone is
Felipe Contreras writes:
> On Fri, Aug 9, 2013 at 5:15 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
OK, I think I see why you are puzzled.
Cloning works fine because we "fix the path" *after* the clone is done
successfully, for the following reason:
>>>
>>> So if
On Fri, Aug 9, 2013 at 5:15 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> OK, I think I see why you are puzzled.
>>>
>>> Cloning works fine because we "fix the path" *after* the clone is done
>>> successfully, for the following reason:
>>
>> So if we didn't store a different path, it
Felipe Contreras writes:
>> OK, I think I see why you are puzzled.
>>
>> Cloning works fine because we "fix the path" *after* the clone is done
>> successfully, for the following reason:
>
> So if we didn't store a different path, it would work. So instead of
> expanding '~' ourselves, it would b
On Fri, Aug 9, 2013 at 11:45 PM, Junio C Hamano wrote:
> OK, so clone works, but subsequent fetch from the cloned resoitory
> does not? "git fetch hg::~/my_repo" will still work but the call to
> "git config" done near the place your patch touches does not store
> "hg::~/my_repo" because it think
On Fri, Aug 9, 2013 at 4:19 PM, Antoine Pelisse wrote:
> Confusion everywhere :-)
>
> On Fri, Aug 9, 2013 at 10:53 PM, Junio C Hamano wrote:
>> Antoine Pelisse writes:
>>
>>> So when we run:
>>>
>>> git clone hg::~/my/repo
>>>
>>> Git will remove the "hg::" part, and Mercurial will expand tilde
Antoine Pelisse writes:
> OK, I think I see why you are puzzled.
> ...
> But my issue is when I do that:
>
> git clone hg::~/my_repo my_new_repo
>
> The clone works successfully by cloning $HOME/my_repo, but then, when
> we try to fix the repo path, we think that ~/my_repo is not an
> absolut
Confusion everywhere :-)
On Fri, Aug 9, 2013 at 10:53 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> So when we run:
>>
>> git clone hg::~/my/repo
>>
>> Git will remove the "hg::" part, and Mercurial will expand tilde and
>> clone $HOME/my/repo.
>
> Now you confused me. If the impleme
Antoine Pelisse writes:
> So when we run:
>
> git clone hg::~/my/repo
>
> Git will remove the "hg::" part, and Mercurial will expand tilde and
> clone $HOME/my/repo.
Now you confused me. If the implementation were for us to remove
the hg:: prefix and let Mercurial do whatever it wants to do wit
On Fri, Aug 9, 2013 at 8:49 PM, Junio C Hamano wrote:
> Antoine Pelisse writes:
>> On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras
>> wrote:
>>> Shouldn't that be the job of the shell? (s/~/$HOME/)
>>
>> I'm not sure what you mean here. Does it mean that I should stop cloning
>> using "~" ?
Antoine Pelisse writes:
> The current code fixes the path to make it absolute when cloning, but
> doesn't consider tilde expansion, so that scenario fails throwing an
> exception because /home/myuser/~/my/repository doesn't exists:
>
> $ git clone hg::~/my/repository && cd repository && git f
The current code fixes the path to make it absolute when cloning, but
doesn't consider tilde expansion, so that scenario fails throwing an
exception because /home/myuser/~/my/repository doesn't exists:
$ git clone hg::~/my/repository && cd repository && git fetch
Expand the tilde when checkin
On Mon, Aug 5, 2013 at 10:30 PM, Felipe Contreras
wrote:
> On Mon, Aug 5, 2013 at 3:12 PM, Antoine Pelisse wrote:
>> $ git clone hg::~/my/repository && cd repository && git fetch
>>
>> Fix that by using python os.path.expanduser method.
>
> Shouldn't that be the job of the shell? (s/~/$HOME/)
On Mon, Aug 5, 2013 at 3:12 PM, Antoine Pelisse wrote:
> The current code fixes the path to make it absolute when cloning, but
> doesn't consider tilde expansion, so that scenario fails throwing an
> exception because /home/myuser/~/my/repository doesn't exists:
>
> $ git clone hg::~/my/reposi
The current code fixes the path to make it absolute when cloning, but
doesn't consider tilde expansion, so that scenario fails throwing an
exception because /home/myuser/~/my/repository doesn't exists:
$ git clone hg::~/my/repository && cd repository && git fetch
Fix that by using python os.p
20 matches
Mail list logo
