On Fri, Dec 27, 2013 at 12:12 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano wrote:
>>
>>> Do we even need to expose them as ref-like things as a part of the
>>> external API/UI in the first place? For end-user scripts that want
>>> to operat
Duy Nguyen writes:
> On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano wrote:
>
>> Do we even need to expose them as ref-like things as a part of the
>> external API/UI in the first place? For end-user scripts that want
>> to operate in a real or borrowing worktree, there should be no
>> reason t
On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>>> I am not happy with the choice of "main/HEAD" that would squat on a
>>> good name for remote-tracking branch (i.e. s/origin/main/), though.
>>> $GIT_DIR/COMMON_HEAD perhaps?
>>
>> It's not just about HEAD. Anything
Duy Nguyen writes:
>> I am not happy with the choice of "main/HEAD" that would squat on a
>> good name for remote-tracking branch (i.e. s/origin/main/), though.
>> $GIT_DIR/COMMON_HEAD perhaps?
>
> It's not just about HEAD. Anything worktree-specific of the main
> checkout can be accessed this wa
On Sat, Dec 21, 2013 at 3:32 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> I've got a better version [1] that fixes everything I can think of
>> (there's still some room for improvements). I'm going to use it a bit
>> longer before reposting again. But here's its basic design without
>> goi
Duy Nguyen writes:
> I've got a better version [1] that fixes everything I can think of
> (there's still some room for improvements). I'm going to use it a bit
> longer before reposting again. But here's its basic design without
> going down to code
>
> New .git file format includes two lines:
>
I've got a better version [1] that fixes everything I can think of
(there's still some room for improvements). I'm going to use it a bit
longer before reposting again. But here's its basic design without
going down to code
New .git file format includes two lines:
-- 8< --
gitid:
gitdir:
-- 8< --
On Sat, Dec 14, 2013 at 5:54 PM, Nguyễn Thái Ngọc Duy wrote:
> Known issues
Scripts that expand "$GIT_DIR/objects" and are not aware about the new
env variable. I introduced "test-path-utils --git-path" to test
git_path(). I could move it to "git rev-parse --git-path" for use in
scripts, but ther
The UI and behavior are taking shape now. On the UI side, you do
git checkout --to /somewhere -b newbranch origin/master
which will create worktree-only repo at /somewhere. "git prune --repos"
could be used to remove cruft in .git/repos.
On the behavior side, you should be able to do everythin
9 matches
Mail list logo
