On Fri, Dec 27, 2013 at 12:12 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano gits...@pobox.com 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
Duy Nguyen pclo...@gmail.com writes:
On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano gits...@pobox.com 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,
On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com 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
Duy Nguyen pclo...@gmail.com 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
Duy Nguyen pclo...@gmail.com 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
On Sat, Dec 21, 2013 at 3:32 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com 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
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: id
gitdir: path
--
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 everything
On Sat, Dec 14, 2013 at 5:54 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
9 matches
Mail list logo
