Junio C Hamano wrote:
> __gitcomp_nl "$(__git_heads)" "$pfx" "$cur_" "."
> __gitcomp_nl_append $"autosetupmerge\nautosetuprebase\n" "$pfx"
> "$cur_" " "
This is not a bad idea at all. I'm just afraid that we might be
leaving open ends: What happens if the $pfx isn't the same in bo
Junio C Hamano wrote:
> If we are looking at "branch.autosetupmerge." followed by something,
> who typed that final dot?
I admit that it's a very unlikely case. The user did:
$ branch.autosetupmer
hit backspace to delete the trailing space, inserted a dot, and hit again.
> If you are working
Junio C Hamano writes:
> stephen_le...@stephe-leake.org writes:
>
>> However, in this case, even running the fetch was a mistake; I would
>> have prefered that it leave FETCH_HEAD in its previous state.
>
> I think the clearing of leftover FETCH_HEAD is one of the early
> things "git fetch" does,
When we have a remote-tracking branch named "frotz/nitfol" from a
previous fetch, and the upstream now has a branch named "frotz". Prior
to this patch fetch would fail to remove "frotz/nitfol" with a "git
fetch --prune" from the upstream. git would inform the user to use "git
remote prune" to fix t
If "fetch --prune" is run with no new refs to fetch, but it has refs
to prune. Then, the header url is not printed as it would if there were
new refs to fetch.
Output before this patch:
$ git fetch --prune remote-with-no-new-refs
x [deleted] (none) -> origin/world
Ou
On Thu, Jan 02, 2014 at 02:28:33PM -0800, Jonathan Nieder wrote:
> > This is not exactly true. The TEST_OUTPUT_DIRECTORY setting does not
> > leak. t sets $TEST_DIRECTORY (which it must, so the sub-scripts can
> > find test-lib.sh and friends), and then TEST_OUTPUT_DIRECTORY uses that
> > as a
2014/1/3 Francesco Pretto :
> Concluding, my point is that at the current state submodules in git
> seem to be flawed because of the inconsistent HEAD state between "add"
> and "update" users. With my patch applied the attached HEAD behavior
> would be fully supported. At some point "git submodule
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Dec 31, 2013, at 04:07, Kyle J. McKay wrote:
Since 64a99eb4 git gc refuses to run without the --force option if
another gc process on the same repository is already running.
However, if the repository is shared and user A runs git gc on the
repository and while that gc is still running user B
Ramkumar Ramachandra writes:
> branch.*.*)
> local pfx="${cur%.*}." cur_="${cur##*.}"
> + if [ "$pfx" == "branch.autosetupmerge." ] ||
> + [ "$pfx" == "branch.autosetuprebase." ]; then
> + return
> + fi
>
Ramkumar Ramachandra writes:
> There are situations where two classes of completions possible. For
> example
>
> branch.
>
> should try to complete
>
> branch.master.
> branch.autosetupmerge
> branch.autosetuprebase
>
> The first candidate has the suffix ".", and the second/ third candida
2014/1/2 Junio C Hamano :
> Francesco Pretto writes:
>
>> by default "git submodule" performs its add or update operations on a
>> detached
>> HEAD. This works well when using an existing full-fledged/indipendent
>> project as
>> the submodule, as there's less frequent need to update it or commi
Jonathan Nieder writes:
> Jeff King wrote:
>> On Mon, Dec 30, 2013 at 10:51:25AM -0800, Jonathan Nieder wrote:
>
>>> These scratch areas for sub-tests should be under the t
>>> trash directory, but because the TEST_OUTPUT_DIRECTORY
>>> setting from the toplevel test leaks
> [...]
Jeff King wrote:
> On Mon, Dec 30, 2013 at 10:51:25AM -0800, Jonathan Nieder wrote:
>> These scratch areas for sub-tests should be under the t
>> trash directory, but because the TEST_OUTPUT_DIRECTORY
>> setting from the toplevel test leaks
[...]
> This is not exactly true. The
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> This has a bit of conflict with another topic in flight; I think I
>> resolved it correctly, but please double check. The following is
>> how it would apply on top of 'pu'.
>>
>> sha1_file.c | 9 +
>> 1 file changed, 5 insertions(+),
db5360f3f496 (name-hash: refactor polymorphic index_name_exists();
2013-09-17) split index_name_exists() into index_file_exists() and
index_dir_exists() but retained index_name_exists() as a thin wrapper
to avoid disturbing possible in-flight topics. Since this change
landed in 'master' some time a
Junio C Hamano writes:
> This has a bit of conflict with another topic in flight; I think I
> resolved it correctly, but please double check. The following is
> how it would apply on top of 'pu'.
>
> sha1_file.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/s
"Bernhard R. Link" writes:
> When giving git-blame the new option introduced with my patch, only
> the order of parents determines which commit is blamed. Without
> the option (i.e. the currently only possible behaviour) which commit
> is blamed depends what else touches other parts of the file.
On Thu, Jan 2, 2014 at 4:11 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> On Fri, Dec 27, 2013 at 5:13 PM, Junio C Hamano wrote:
>>> Eric Sunshine writes:
>>>
On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano wrote:
> [New Topics]
Would $gmane/239575 [1] be of interes
Sebastian Schuberth writes:
> When cloning to a directory "C:\foo\bar" from Windows' cmd.exe where "foo"
> does not exist yet, Git would throw an error like
>
> fatal: could not create work tree dir 'c:\foo\bar'.: No such file or directory
>
> Fix this by not hard-coding a platform specific direc
Hi Junio,
On Thu, 2 Jan 2014, Junio C Hamano wrote:
> If we are going to change the meaning of the function so that it can
> now take any random path in platform-specific convention
Note that nothing in the function name or documentation suggests
otherwise.
> that may be incompatible with the i
* Junio C Hamano [140102 21:29]:
> > This optimization, while being faster in the usual case, means that in
> > the case of cherry-picks the blamed commit depends on which other commits
> > touched a file.
> >
> > If for example one commit A modified both files b and c. And there are
> > commits B
Eric Sunshine writes:
> On Fri, Dec 27, 2013 at 5:13 PM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>
>>> On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano wrote:
[New Topics]
>>>
>>> Would $gmane/239575 [1] be of interest for "New Topics"?
>>>
>>> [1]: http://article.gmane.org/gmane.c
Hi,
On Thu, 2 Jan 2014, Sebastian Schuberth wrote:
> When cloning to a directory "C:\foo\bar" from Windows' cmd.exe where "foo"
> does not exist yet, Git would throw an error like
>
> fatal: could not create work tree dir 'c:\foo\bar'.: No such file or directory
>
> Fix this by not hard-coding
Sebastian Schuberth writes:
> On 02.01.2014 20:55, Junio C Hamano wrote:
>
>> Thanks; the conclusion is correct --- you need a good commit
>> message in the recorded history. That does not have anything to do
>> with integrating with pulling from subsystem maintainers, which we
>> regularly do.
On Thu, Jan 2, 2014 at 9:31 PM, Jonathan Nieder wrote:
> would just leave me wondering "I never claimed it was built-in; what's
> going on?" I think it would be simplest to keep it as
>
> $ git whatever
> fatal: cannot handle "whatever" internally
>
> which at least makes it clea
On Thu, Jan 2, 2014 at 8:43 PM, Junio C Hamano wrote:
>> Documentation/technical/api-builtin.txt | 2 +-
>> Makefile| 1 +
>> builtin.c | 225 ++
>> builtin.h | 21 +++
>>
When cloning to a directory "C:\foo\bar" from Windows' cmd.exe where "foo"
does not exist yet, Git would throw an error like
fatal: could not create work tree dir 'c:\foo\bar'.: No such file or directory
Fix this by not hard-coding a platform specific directory separator into
safe_create_leading_
On 02.01.2014 20:55, Junio C Hamano wrote:
> Thanks; the conclusion is correct --- you need a good commit
> message in the recorded history. That does not have anything to do
> with integrating with pulling from subsystem maintainers, which we
> regularly do.
I'll send a v2 which adds a proper c
On Fri, Dec 27, 2013 at 5:13 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano wrote:
>>> [New Topics]
>>
>> Would $gmane/239575 [1] be of interest for "New Topics"?
>>
>> [1]: http://article.gmane.org/gmane.comp.version-control.git/239575/
>
Hi Sebastian,
On Thu, 2 Jan 2014, Sebastian Schuberth wrote:
> On 02.01.2014 18:33, Johannes Schindelin wrote:
>
> > -- snip --
> > On Linux, we can get away with assuming that the directory separator is a
> > forward slash, but that is wrong in general. For that purpose, the
> > is_dir_sep() fu
Hi Junio,
On Thu, 2 Jan 2014, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Thu, 2 Jan 2014, Sebastian Schuberth wrote:
> >
> >> See https://github.com/msysgit/git/pull/80.
> >
> > Thanks Sebastian!
> >
> > However, since the git.git project is not comfortable with the concept
>
On 02.01.2014 19:18, John Keeping wrote:
That said, I see any further explanations on top of the commit message
title is an added bonus, and as "just" a bonus a link to a pull request
should be fine. You don't need to understand or appreciate the concept
of pull requests in order to follow the l
Hi,
Sebastian Schuberth wrote:
[...]
> --- a/Documentation/technical/api-builtin.txt
> +++ b/Documentation/technical/api-builtin.txt
> @@ -14,7 +14,7 @@ Git:
>
> . Add the external declaration for the function to `builtin.h`.
>
> -. Add the command to `commands[]` table in `handle_internal_c
"Bernhard R. Link" writes:
> Allows to disable the git blame optimization of assuming that if there is a
> parent of a merge commit that has the exactly same file content, then
> only this parent is to be looked at.
I think this is what we usually call --full-history in "git log"
family, but mor
Francesco Pretto writes:
> by default "git submodule" performs its add or update operations on a detached
> HEAD. This works well when using an existing full-fledged/indipendent project
> as
> the submodule, as there's less frequent need to update it or commit back
> changes. When the submodule
Johannes Schindelin writes:
> Hi,
>
> On Thu, 2 Jan 2014, Sebastian Schuberth wrote:
>
>> See https://github.com/msysgit/git/pull/80.
>
> Thanks Sebastian!
>
> However, since the git.git project is not comfortable with the concept of
> pull requests (which is why you submitted this patch via mail
Sebastian Schuberth writes:
> Signed-off-by: Sebastian Schuberth
> ---
> Documentation/technical/api-builtin.txt | 2 +-
> Makefile| 1 +
> builtin.c | 225 ++
> builtin.h
Sebastian Schuberth writes:
> Since 2dce956 is_git_command() is a bit slow as it does file I/O in the
> call to list_commands_in_dir(). Avoid the file I/O by adding an early
> check for internal commands.
I think it is a good thing to check with the list of built-in's
first, but in order to see
Jeff King writes:
> ... But the test suite, of course, always uses askpass because it
> cannot rely on accessing a terminal (we'd have to do some magic with
> lib-terminal, I think).
>
> So it doesn't detect the problem in your patch, but I wonder if it is
> worth applying the patch below anyway,
Thanks for the comments, my replies below. Before, a couple of general
questions:
- I'm also writing some tests, should I commit them together with the
feature patch?
- to determine the attached/detached state I did this:
head_detached=
if test "$(rev-parse --abbrev-ref HEAD)" = "HEAD"
then
he
On Thu, Jan 02, 2014 at 07:11:42PM +0100, Sebastian Schuberth wrote:
> On 02.01.2014 18:33, Johannes Schindelin wrote:
>
> > -- snip --
> > On Linux, we can get away with assuming that the directory separator is a
> > forward slash, but that is wrong in general. For that purpose, the
> > is_dir_se
On 02.01.2014 18:33, Johannes Schindelin wrote:
-- snip --
On Linux, we can get away with assuming that the directory separator is a
forward slash, but that is wrong in general. For that purpose, the
is_dir_sep() function was introduced a long time ago. By using it in
safe_create_leading_directo
stephen_le...@stephe-leake.org writes:
> However, in this case, even running the fetch was a mistake; I would
> have prefered that it leave FETCH_HEAD in its previous state.
I think the clearing of leftover FETCH_HEAD is one of the early
things "git fetch" does, unless "--append" is in effect. I
Allows to disable the git blame optimization of assuming that if there is a
parent of a merge commit that has the exactly same file content, then
only this parent is to be looked at.
This optimization, while being faster in the usual case, means that in
the case of cherry-picks the blamed commit d
Hi,
On Thu, 2 Jan 2014, Sebastian Schuberth wrote:
> See https://github.com/msysgit/git/pull/80.
Thanks Sebastian!
However, since the git.git project is not comfortable with the concept of
pull requests (which is why you submitted this patch via mail), I believe
that we have to explain the rati
See https://github.com/msysgit/git/pull/80.
Signed-off-by: Johannes Schindelin
Signed-off-by: Sebastian Schuberth
---
sha1_file.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 760dd60..2114c58 100644
--- a/sha1_file.c
+++ b/s
help
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signed-off-by: Sebastian Schuberth
---
Documentation/technical/api-builtin.txt | 2 +-
Makefile| 1 +
builtin.c | 225 ++
builtin.h | 21 +++
git.c
Signed-off-by: Sebastian Schuberth
---
Documentation/technical/api-builtin.txt | 2 +-
git.c | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/technical/api-builtin.txt
b/Documentation/technical/api-builtin.txt
i
This avoids list_commands_in_dir() being called when not needed which is
quite slow due to file I/O in order to list matching files in a directory.
Signed-off-by: Sebastian Schuberth
---
builtin/help.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/help.c b/builtin
Since 2dce956 is_git_command() is a bit slow as it does file I/O in the
call to list_commands_in_dir(). Avoid the file I/O by adding an early
check for internal commands.
Signed-off-by: Sebastian Schuberth
---
Documentation/technical/api-builtin.txt | 4 +-
builtin.h
This is the second iteration of the patches in
http://www.spinics.net/lists/git/msg222428.html
http://www.spinics.net/lists/git/msg222429.html
which
* adds a commit to use the term "builtin" instead of "internal command",
* also modifies the docs accordingly,
* moves the is_builtin() declaration
On 02.01.2014 09:51, Christian Couder wrote:
diff --git a/builtin/help.c b/builtin/help.c
index b6fc15e..1f0261e 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -284,10 +284,15 @@ static int git_help_config(const char *var, const char
*value, void *cb)
return git_default_config(var
On Mon, Dec 30, 2013 at 10:07 PM, Sebastian Schuberth
wrote:
> Since 2dce956 is_git_command() was a bit slow as it does file I/O in the
> call to list_commands_in_dir(). Avoid the file I/O by adding an early
> check for internal commands.
>
> Signed-off-by: Sebastian Schuberth
> ---
> builtin/he
55 matches
Mail list logo
