On Thu, Jul 16, 2015 at 9:22 PM, Jacob Keller wrote:
> On Thu, Jul 16, 2015 at 12:07 PM, Luis R. Rodriguez
> wrote:
>> On Fri, Jun 12, 2015 at 11:52 AM, Luis R. Rodriguez
>> wrote:
>>> OK wells I'm curious about more research / effort when trying to
>>> evaluate a diff with two seprate but adjoi
On Thu, Jul 16, 2015 at 12:07 PM, Luis R. Rodriguez
wrote:
> On Fri, Jun 12, 2015 at 11:52 AM, Luis R. Rodriguez
> 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
On Thu, Jul 16, 2015 at 7:13 PM, Duy Nguyen wrote:
> On Fri, Jul 17, 2015 at 3:39 AM, Junio C Hamano 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 gl
On Fri, Jul 17, 2015 at 7:32 AM, Eric Sunshine 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 $somewhere/.git/wo
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 wrote:
> In Fedora 21, docbook2x-texi binary is named db2x_docbook2texi.
> If binary docbook2-texi is not found, looks for db2x_docbook2texi.
> Als
On Thu, Jul 16, 2015 at 1:55 PM, Junio C Hamano 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 the general w
On Thu, Jul 16, 2015 at 8:17 PM, Eric Sunshine 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
> ---
> diff --git a/Documentation/git.txt b/Documentation/git.txt
> index d
This should have been changed by 93a3649 (Documentation: move linked
worktree description from checkout to worktree, 2015-07-06).
Signed-off-by: Eric Sunshine
---
Documentation/git.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git.txt b/Documentation/git.t
On Thu, Jul 16, 2015 at 6:57 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> These should have been changed to "git worktree add" by fc56361
>> (worktree: introduce "add" command, 2015-07-06.
>>
>> Signed-off-by: Eric Sunshine
>> ---
> By the way, given the rate of bugs and glitches I am fi
On Fri, Jul 17, 2015 at 3:39 AM, Junio C Hamano 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
> #
> # (
> #
Eric Sunshine writes:
> These should have been changed to "git worktree add" by fc56361
> (worktree: introduce "add" command, 2015-07-06.
>
> Signed-off-by: Eric Sunshine
> ---
>
> Changes since v1[1]: Reference the correct commit (fc56361, not b979d95)
> in the commit message. Sorry for the noi
These should have been changed to "git worktree add" by fc56361
(worktree: introduce "add" command, 2015-07-06.
Signed-off-by: Eric Sunshine
---
Changes since v1[1]: Reference the correct commit (fc56361, not b979d95)
in the commit message. Sorry for the noise.
[1]: http://article.gmane.org/gma
On Thu, Jul 16, 2015 at 2:10 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano wrote:
>>> Dave Borowitz writes:
>>>
On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano wrote:
> Perhaps something like this?
Seems like it s
These should have been changed to "git worktree add" by b979d95
(checkout: retire --to option, 2015-07-06).
Signed-off-by: Eric Sunshine
---
Atop what is already in 'master'...
Documentation/git-worktree.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/
Dave Borowitz writes:
> On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano wrote:
>> Dave Borowitz writes:
>>
>>> On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano wrote:
>>>
Perhaps something like this?
>>>
>>> Seems like it should work.
>>>
>>> Jonathan had suggested there might be some prin
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
("", )
Add a "Copy commit summary" command to the context menu that puts this
text for the currently selected commit on the clipboard. This make
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" &&
#
On Thu, Jul 16, 2015 at 1:12 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano wrote:
>>
>>> Perhaps something like this?
>>
>> Seems like it should work.
>>
>> Jonathan had suggested there might be some principled reason why
>> send-pack does
Dave Borowitz writes:
> On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano 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 suggested passing it in
> as a fla
On Thu, Jul 16, 2015 at 1:06 PM, Junio C Hamano wrote:
> Dave Borowitz 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. T
Dave Borowitz 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 signing key over
>
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 m
On Fri, Jun 12, 2015 at 11:52 AM, Luis R. Rodriguez
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
> generator join them.
>
> F
Eric Sunshine 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. Therefore, drop 'new_work
Eric Sunshine 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". For the user, "
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 su
Beat Bolli writes:
> When referring to earlier commits in commit messages or other text, one
> of the established formats is
>
> ("", )
> ...
> +proc copysummary {} {
> +global rowmenuid commitinfo
> +
> +set id [string range $rowmenuid 0 7]
> +set info $commitinfo($rowmenuid)
>
Stefan Beller 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 the .git
When referring to earlier commits in commit messages or other text, one
of the established formats is
("", )
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 users to create well-formatt
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 t
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 giv
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
---
No changes since v1.
builtin/checkout.c | 7 +++
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 i
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
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 w
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 popu
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 ch
Be consistent with git-checkout which disallows this (not particularly
meaningful) combination.
Signed-off-by: Eric Sunshine
---
No changes since v1.
builtin/worktree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 253382a
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 overly-
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 s
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
---
No changes since v1.
builtin/worktree.c | 45 +++-
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
---
Changes si
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 symref-st
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 r
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 th
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 child_process
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,
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 GIT_C
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
52 matches
Mail list logo
