Eric Sunshine sunsh...@sunshineco.com writes:
When check_linked_checkout() discovers that the branch is already
checked out elsewhere, it emits the diagnostic:
'blorp' is already checked out at '/some/path/.git'
which is mildly misleading and a bit unsightly due to the trailing
/.git.
This should have been changed by 93a3649 (Documentation: move linked
worktree description from checkout to worktree, 2015-07-06).
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, Jul 16, 2015 at 8:17 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
This should have been changed by 93a3649 (Documentation: move linked
worktree description from checkout to worktree, 2015-07-06).
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
diff --git
Ping. Don't have write access.
Applied as an attachment, in case there were any formatting issues.
On Wed, May 13, 2015 at 4:28 AM, Michael Darling darli...@gmail.com wrote:
In Fedora 21, docbook2x-texi binary is named db2x_docbook2texi.
If binary docbook2-texi is not found, looks for
When check_linked_checkout() discovers that the branch is already
checked out elsewhere, it emits the diagnostic:
'blorp' is already checked out at '/some/path/.git'
which is mildly misleading and a bit unsightly due to the trailing
/.git. For the user, /some/path is significant, whereas
Make 'new_branch' be the name of the new branch for both forced and
non-forced cases; and add boolean 'force_new_branch' to indicate forced
branch creation. This will simplify logic later on when git-worktree
handles branch creation locally rather than delegating it to
git-checkout as part of the
The caller of add_worktree() provides it with a command to invoke to
populate the new worktree. This was a useful abstraction during the
conversion of git checkout --to functionality to git worktree add
since git-checkout and git-worktree constructed the population command
differently. However,
Hi Stefan, Hi Frederik,
maybe I stated the case not clearly enough.
The repo is just inside an shared/mounted folder from the VM to the Host, so
that we can access the sourcecode via an IDE running on the host. The git
commands are executed inside the VM on an ubuntu system. So there is no mix
add_worktree() will eventually need to deal with some options itself, so
introduce a structure into which options can be conveniently bundled,
and pass it along to add_worktree().
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
No changes since v1.
builtin/worktree.c | 45
Now that git-worktree sets HEAD explicitly to its final value via either
git-symbolic-ref or git-update-ref, rather than relying upon
git-checkout to do so, the hack for pacifying is_git_directory() with
a temporary HEAD, though still necessary, can be simplified.
Since the real HEAD is now
git-worktree currently conflates new branch creation, setting of HEAD in
the new wortkree, and worktree population into a single sub-invocation
of git-checkout. However, these operations will eventually be separated,
and git-worktree itself will need to be able to detect if the branch is
already
Be consistent with git-checkout which disallows this (not particularly
meaningful) combination.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
No changes since v1.
builtin/worktree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/worktree.c
git-worktree currently conflates setting of HEAD in the new worktree and
initial worktree population into a single git-checkout invocation which
requires git-checkout to have special knowledge that it is operating on
a newly created worktree. The eventual goal is to rid git-checkout of
that
Now that git-worktree handles all functionality (--force, --detach,
-b/-B) previously delegated to git-checkout, actual population of the
new worktree can be accomplished more directly and lightweight with
git reset --hard in place of git checkout.
Signed-off-by: Eric Sunshine
This is v2 of [1] which rids git-checkout of the need to have
specialized knowledge that it's operating in a newly created linked
worktree, and decouples git-worktree from git-checkout. Thanks to Duy
and Junio for reviews.
A v1 to v2 interdiff is included below.
Changes since v1:
* patch 03/20:
check_linked_checkout() only understands symref-style HEAD (i.e. ref:
refs/heads/master), however, HEAD may also be a an actual symbolic link
(on platforms which support it). To accurately detect if a branch is
checked out elsewhere, it needs to handle symbolic link HEAD, as well.
Signed-off-by:
check_linked_checkout() only understands symref-style HEAD (i.e. ref:
refs/heads/master), however, HEAD may also be a an actual symbolic link
(on platforms which support it), thus it will need to check that style
HEAD, as well (via readlink()). As a preparatory step, simplify parsing
of
git-worktree currently conflates setting of HEAD in the new worktree
with initial worktree population via a single git-checkout invocation,
which requires git-checkout to have special knowledge that it is
operating in a newly created worktree. The eventual goal is to separate
these operations and
When --ignore-other-worktree is specified, we unconditionally skip the
check to see if the requested branch is already checked out in a linked
worktree. Since we know that we will be skipping that check, there is no
need to resolve HEAD in order to detect other conditions under which we
may skip
Now that git-worktree no longer relies upon git-checkout for new branch
creation, new worktree HEAD set up, or initial worktree population,
git-checkout no longer needs intimate knowledge that it may be operating
in a newly created worktree. Therefore, drop 'new_worktree_mode' and the
private
Take advantage of 'struct child_process.env' to make it obvious that
environment variables set by add_worktree() are intended specifically
for sub-commands it invokes to operate in the new worktree.
We assign a local 'struct argv_array' to child_process.env, rather than
utilizing the
git-worktree currently conflates branch creation, setting of HEAD in the
new worktree, and worktree population into a single sub-invocation of
git-checkout, which requires git-checkout to be specially aware that it
is operating in a newly-created worktree. The goal is to free
git-checkout of that
die_if_checked_out() is intended to check if the branch about to be
checked out is already checked out either in the main worktree or in a
linked worktree. However, if .git/worktrees directory does not exist,
then it never bothers checking the main worktree, even though the
specified branch might
check_linked_checkouts() doesn't just check linked checkouts for
something; specifically, it aborts the operation if the branch about
to be checked out is already checked out elsewhere. Therefore, rename it
to die_if_checked_out() to give a better indication of its function.
The more meaningful
There is no reason to keep the strbuf active long after its last use.
By releasing it as early as possible, resource management is simplified
and there is less worry about future changes resulting in a leak.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
No changes since v1.
The plan is to publish die_if_checked_out() so that callers other than
git-checkout can take advantage of it, however, those callers won't have
access to git-checkout's struct branch_info. Therefore, change it to
accept the full name of the branch as a simple string instead.
While here, also give
The problem was down to the linker and archiver. I had to make sure that I
used the ar and ld in /usr/bin (rather than aix ld and gnu ar) and the gnu
compiler. Also, I did not realise I had already created libs so had to run
clean and start with the right PATH to pick up the above.
Finally, have
When referring to earlier commits in commit messages or other text, one
of the established formats is
abbrev-sha (summary, author-date)
Add a Copy commit summary command to the context menu that puts this
text for the currently selected commit on the clipboard. This makes it
easy for our
Beat Bolli dev+...@drbeat.li writes:
When referring to earlier commits in commit messages or other text, one
of the established formats is
abbrev-sha (summary, author-date)
...
+proc copysummary {} {
+global rowmenuid commitinfo
+
+set id [string range $rowmenuid 0 7]
+
This makes it possible to implement bash completion for add-on commands,
that will work even when the bash completion scripts are being loaded
on-demand, as is done by the bash-completion package.
git's bash completion handles subcommands by running a _git_$command
function. As well as the many
Stefan Beller sbel...@google.com writes:
A few weeks ago we weren’t able to clone and get an error: could
not commit /vagrant/.git/config file. Manually we were able to
change that file and also the clone command works outside the shared
folder.
Why are you trying to commit a file inside
Dave Borowitz dborow...@google.com writes:
When git-send-pack is exec'ed, as is done by git-remote-http, it does
not reread the config, so it does not respect the configured
http.signingkey, either from the config file or -c on the command
line. Thus it is currently impossible to specify a
On Fri, Jun 12, 2015 at 11:52 AM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
OK wells I'm curious about more research / effort when trying to
evaluate a diff with two seprate but adjoining preprocessor directives
and if anyone has implemented an optimizaiton option to let the diff
Dave Borowitz dborow...@google.com writes:
On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano gits...@pobox.com wrote:
Perhaps something like this?
Seems like it should work.
Jonathan had suggested there might be some principled reason why
send-pack does not respect config options, and
Also in a linked checkout of git.git itself, t5601.21 seems to fail
with:
fatal: Not a git repository: /home/gitster/w/src/.git/worktrees/rerere
not ok 21 - clone respects global branch.autosetuprebase
#
# (
# test_config=$HOME/.gitconfig
#
When git-send-pack is exec'ed, as is done by git-remote-http, it does
not reread the config, so it does not respect the configured
http.signingkey, either from the config file or -c on the command
line. Thus it is currently impossible to specify a signing key over
HTTP, other than the default one
On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano gits...@pobox.com wrote:
Perhaps something like this?
Seems like it should work.
Jonathan had suggested there might be some
Dave Borowitz dborow...@google.com writes:
On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano gits...@pobox.com wrote:
Perhaps something like this?
Seems like it should work.
Eric Sunshine sunsh...@sunshineco.com writes:
Now that git-worktree no longer relies upon git-checkout for new branch
creation, new worktree HEAD set up, or initial worktree population,
git-checkout no longer needs intimate knowledge that it may be operating
in a newly created worktree.
Am 16.07.2015 um 17:29 schrieb Beat Bolli:
When referring to earlier commits in commit messages or other text, one
of the established formats is
abbrev-sha (summary, author-date)
Add a Copy commit summary command to the context menu that puts this
text for the currently selected commit on
On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
When git-send-pack is exec'ed, as is done by git-remote-http, it does
not reread the config, so it does not respect the configured
http.signingkey, either from the config file
On Thu, Jul 16, 2015 at 9:22 PM, Jacob Keller jacob.kel...@gmail.com wrote:
On Thu, Jul 16, 2015 at 12:07 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
On Fri, Jun 12, 2015 at 11:52 AM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
OK wells I'm curious about more research / effort
On Fri, Jul 17, 2015 at 7:32 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
In the new world order with GIT_DIR and GIT_COMMON_DIR, does
$GIT_DIR always have to be the same as $GIT_WORK_TREE/.git? Do
we need some sanity check if that is the case? Perhaps: if you have
$GIT_DIR set to
On Thu, Jul 16, 2015 at 7:13 PM, Duy Nguyen pclo...@gmail.com wrote:
On Fri, Jul 17, 2015 at 3:39 AM, Junio C Hamano gits...@pobox.com wrote:
Also in a linked checkout of git.git itself, t5601.21 seems to fail
with:
fatal: Not a git repository: /home/gitster/w/src/.git/worktrees/rerere
not
On Thu, Jul 16, 2015 at 12:07 PM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
On Fri, Jun 12, 2015 at 11:52 AM, Luis R. Rodriguez
mcg...@do-not-panic.com wrote:
OK wells I'm curious about more research / effort when trying to
evaluate a diff with two seprate but adjoining preprocessor
On Thu, Jul 16, 2015 at 6:57 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
These should have been changed to git worktree add by fc56361
(worktree: introduce add command, 2015-07-06.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
By the
Eric Sunshine sunsh...@sunshineco.com writes:
These should have been changed to git worktree add by fc56361
(worktree: introduce add command, 2015-07-06.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Changes since v1[1]: Reference the correct commit (fc56361, not b979d95)
in
On Thu, Jul 16, 2015 at 1:55 PM, Junio C Hamano gits...@pobox.com wrote:
How does this work with manually configured GIT_DIR environment, by
the way? I think GIT_DIR=/collection/of/repos/foo.git would be OK,
as strbuf_strip_suffix() would hopefully leave it intact, but I am
more interested in
These should have been changed to git worktree add by fc56361
(worktree: introduce add command, 2015-07-06.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Changes since v1[1]: Reference the correct commit (fc56361, not b979d95)
in the commit message. Sorry for the noise.
[1]:
These should have been changed to git worktree add by b979d95
(checkout: retire --to option, 2015-07-06).
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Atop what is already in 'master'...
Documentation/git-worktree.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
On Thu, Jul 16, 2015 at 2:10 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano gits...@pobox.com wrote:
Dave Borowitz dborow...@google.com writes:
On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano
On Fri, Jul 17, 2015 at 3:39 AM, Junio C Hamano gits...@pobox.com wrote:
Also in a linked checkout of git.git itself, t5601.21 seems to fail
with:
fatal: Not a git repository: /home/gitster/w/src/.git/worktrees/rerere
not ok 21 - clone respects global branch.autosetuprebase
#
#
52 matches
Mail list logo
