On Mon, Jun 24, 2013 at 6:33 AM, Junio C Hamano wrote:
> When branch.*.push configuration variable is defined for the current
> branch, a lazy-typing "git push" (and "git push there") will push
> the commit at the tip of the current branch to the destination and
> update the branch named by that v
On Mon, Jun 24, 2013 at 6:33 AM, Junio C Hamano wrote:
> From: Ramkumar Ramachandra
>
> The setup creates two bare repositories: repo1 and repo2, but
> test_push_commit() hard-codes checking in repo1 for the actual output.
> Generalize it and its caller, test_push_success(), to optionally accept
On Mon, Jun 24, 2013 at 6:33 AM, Junio C Hamano wrote:
> From: Ramkumar Ramachandra
>
> When remote.pushdefault or branch..pushremote is set (a triangular
> workflow feature), master@{u} != origin, and push.default is set to
> `upstream` or `simple`:
>
> $ git push
> fatal: You are pushing to
Martin von Zweigbergk writes:
> On Sun, Jun 23, 2013 at 4:54 PM, Jonathan Nieder wrote:
>>
>> In other words, HEAD always either points to an unborn or existing
>> branch or an existing commit. It's not clear to me what it would
>> mean to detach from an unborn branch.
>
> I think it should mea
From: Ramkumar Ramachandra
4d35924e (Merge branch 'rr/triangle', 2013-04-07) introduced support
for triangular workflows, but the push.default values still assume
central workflows.
Rewrite the descriptions of `nothing`, `current`, `upstream` and
`matching` for greater clarity, and explicitly ex
This is mostly Ram's triangular-push-fix series, but the fix-up
commits I queued on top of it when the series was queued to 'pu'
have been squashed in.
[PATCH 1/6] t/t5528-push-default: remove redundant test_config lines
No changes, as posted by Ram.
[PATCH 2/6] config doc: rewrite push.de
When branch.*.push configuration variable is defined for the current
branch, a lazy-typing "git push" (and "git push there") will push
the commit at the tip of the current branch to the destination and
update the branch named by that variable.
Signed-off-by: Junio C Hamano
---
builtin/push.c | 1
From: Ramkumar Ramachandra
The line
test_config push.default upstream
appears unnecessarily in two tests, as the final test_push_failure sets
push.default before pushing anyway.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Junio C Hamano
---
t/t5528-push-default.sh | 2 --
1 file ch
From: Ramkumar Ramachandra
Introduce test_pushdefault_workflows(), and test that all push.default
modes work with central and triangular workflows as expected.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Junio C Hamano
---
t/t5528-push-default.sh | 57 ++
From: Ramkumar Ramachandra
The setup creates two bare repositories: repo1 and repo2, but
test_push_commit() hard-codes checking in repo1 for the actual output.
Generalize it and its caller, test_push_success(), to optionally accept
a third argument to specify the name of the repository to check f
From: Ramkumar Ramachandra
When remote.pushdefault or branch..pushremote is set (a triangular
workflow feature), master@{u} != origin, and push.default is set to
`upstream` or `simple`:
$ git push
fatal: You are pushing to remote 'origin', which is not the upstream of
your current branch '
On Sun, Jun 23, 2013 at 4:54 PM, Jonathan Nieder wrote:
>
> In other words, HEAD always either points to an unborn or existing
> branch or an existing commit. It's not clear to me what it would
> mean to detach from an unborn branch.
I think it should mean that the next commit would be a root co
Ramkumar Ramachandra writes:
> @@ -59,6 +63,9 @@ else
> return $?
> fi
>
> + # always reset GIT_REFLOG_ACTION before calling any external
> + # scripts; they have no idea about our base_reflog_action
> + GIT_REFLOG_ACTION="$base_reflog_action"
> git am $git
Hi,
SZEDER Gábor wrote:
> $ git init
> Initialized empty Git repository in /tmp/test/.git/
> $ git checkout --detach
> fatal: You are on a branch yet to be born
>
> Are there some plumbing commands and options that would still allow
> this, or can I rely on that that it's impossible?
gitreposito
I suspect that detaching HEAD before a root commit is not possible by
design. What would HEAD contain then!? 'git checkout' seems to
corroborate:
$ git init
Initialized empty Git repository in /tmp/test/.git/
$ git checkout --detach
fatal: You are on a branch yet to be born
Are there some plumb
Dennis Kaarsemaker writes:
> On zo, 2013-06-23 at 14:22 -0700, Junio C Hamano wrote:
>> Dennis Kaarsemaker writes:
>>
>> > Equality for
>> > wildcards is allowed and tested for, so do we really want to 'outlaw'
>> > equality of non-wildcard refspecs?
>>
>> I am not sure what you mean by "equal
Ramkumar Ramachandra writes:
> I disagree. It is trivial to prove that the tests in t/remote will
> break if this fringe feature breaks: I don't know where "we will never
> know when we break them" is coming from.
If you remove tests that configure the remotes via the .git/branches
and the .g
On zo, 2013-06-23 at 14:22 -0700, Junio C Hamano wrote:
> Dennis Kaarsemaker writes:
>
> > Equality for
> > wildcards is allowed and tested for, so do we really want to 'outlaw'
> > equality of non-wildcard refspecs?
>
> I am not sure what you mean by "equality for wildcards is allowed".
> Do yo
Dennis Kaarsemaker writes:
> Equality for
> wildcards is allowed and tested for, so do we really want to 'outlaw'
> equality of non-wildcard refspecs?
I am not sure what you mean by "equality for wildcards is allowed".
Do you mean this pair of remote definition is sane and not warned?
[
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
Reminds me of the strategy to deprecate functionality in X (cf.
http://lwn.net/Articles/536520/) ;-)
>>>
>>> Leaving dead code around to confuse readers? :\
>>
>> We broke the use case to access jgarzik/netdev-2.6 only by having
>> jg
John Keeping writes:
> The patch below involves deeper Perl magic than I fully grok, but
> wouldn't it be simpler to simply use the fact that the string is
> "command --options..." and use:
>
> splice @diff_cmd 1, 0, "--diff-algorithm=${diff_algorithm}";
That inserts the extra options as the
On Sun, Jun 23, 2013 at 12:19:05PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> >> > +my $diff_algorithm = ($repo->config('diff.algorithm') or 'default');
> >> > +
> >> > my $use_readkey = 0;
> >> > my $use_termcap = 0;
> >> > my %term_escapes;
> >> > @@ -731,6 +733,9 @@ sub run_git
John Keeping writes:
>> > +my $diff_algorithm = ($repo->config('diff.algorithm') or 'default');
>> > +
>> > my $use_readkey = 0;
>> > my $use_termcap = 0;
>> > my %term_escapes;
>> > @@ -731,6 +733,9 @@ sub run_git_apply {
>> > sub parse_diff {
>> >my ($path) = @_;
>> >my @diff_cmd =
This is not really meant for external use, and thus not documented. It
allows the next commit to neatly distinguish between sub-tests and the
main run.
The format is intentionally not valid TAP. The use in the next commit
would not result in anything valid either way, and it seems better to
make
With the new --valgrind-only= option, one can enable
--valgrind at a per-test granularity, exactly analogous to
--verbose-only from the previous commit.
The options are wired such that --valgrind implies --verbose (as
before), but --valgrind-only= implies
--verbose-only= unless --verbose is also i
> Please hold off; Fredrik found an issue with the test automation that
> bisects to "verbose mode for only tests matching a pattern"; when
> running with the 'test' target (not with prove however), the suite
> reports
>
> failed test(s):
>
> fixed 0
> success 9788
> failed 2
> bro
This moves
* the early setup part from test_skip to a new function test_start_
* the final common parts of test_expect_* to a new function
test_finish_
to make the next commit more obvious.
Signed-off-by: Thomas Rast
---
t/test-lib-functions.sh | 6 --
t/test-lib.sh | 9 ++
It's already used twice, and we will have more of the same kind of
matching in a minute.
Helped-by: Johannes Sixt
Signed-off-by: Thomas Rast
---
t/test-lib.sh | 41 -
1 file changed, 24 insertions(+), 17 deletions(-)
diff --git a/t/test-lib.sh b/t/test-l
With the new --valgrind-parallel= option, we support running the
tests in a single test script under valgrind in parallel using 'n'
processes.
This really follows the dumbest approach possible, as follows:
* We spawn the test script 'n' times, using a throw-away
TEST_OUTPUT_DIRECTORY. Each of
1b3185f (MALLOC_CHECK: various clean-ups, 2012-09-14) moved around the
MALLOC_CHECK_ and MALLOC_PERTURB_ assignments, intending to limit
their effect to only the test runs. However, they were actually
enabled only during test cleanup. Call setup/teardown_malloc_check
also around the evaluation of
t contains some light self-tests of test-lib.sh, but --verbose was
not covered. Add a test.
The only catch is that the presence of a test harness influences the
output (specifically, the presence of some empty lines). So we need
to unset TEST_HARNESS or set it to a known value. Leaving it u
With the new --verbose-only= option, one can enable --verbose
at a per-test granularity. The pattern is matched against the test
number, e.g.
./t-basic.sh --verbose-only='2[0-2]'
to see only the full output of test 20-22, while showing the rest in the
one-liner format.
As suggested by Jef
Junio C Hamano writes:
> Ramkumar Ramachandra writes:
>
>> Junio C Hamano wrote:
$ ~/src/git
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
Junio C Hamano writes:
> * tr/test-v-and-v-subtest-only (2013-06-18) 8 commits
> - test-lib: support running tests under valgrind in parallel
> - test-lib: allow prefixing a custom string before "ok N" etc.
> - test-lib: valgrind for only tests matching a pattern
> - test-lib: verbose mode fo
Commit 178e1de (fast-import: don't allow 'ls' of path with empty
components, 2012-03-09) restricted paths which:
. contain an empty directory component (e.g. foo//bar is invalid),
. end with a directory separator (e.g. foo/ is invalid),
. start with a directory separator (e.g. /foo is
Because fast-import.c::tree_content_remove does not check for the empty
path, it is not possible to move the root tree to a subdirectory.
Instead the error "Path not in branch" is produced (note the double
space where the empty path has been inserted).
Fix this by explicitly checking for the empt
This series addressed Dave Abraham's recent bug report [1] about using
fast-import's "ls" command with an empty path. I also found a couple of
other places that do not handle the empty path when it can reasonably be
interpreted as meaning the root tree object, which are also fixed here.
[1] http:
When given an empty path, fast-import sometimes reports "missing"
instead of using the root tree object. On top of this, for "ls" and
file copy (but not move) it dies with "Empty path component found in
input".
Document this behaviour with failing test cases.
Reported-by: Dave Abrahams
Signed-o
This prevents a failure later when we lift the restriction on ls with
the empty path.
Signed-off-by: John Keeping
---
fast-import.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fast-import.c b/fast-import.c
index 23f625f..bdbadea 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -3051,6
On Sun, Jun 23, 2013 at 07:19:25AM -0700, Dave Abrahams wrote:
> on Sun Jun 23 2013, John Keeping wrote:
> > In this case, I think I do now understand why the mode is 0: in
> > parse_ls a new tree object is created and the SHA1 of the original is
> > copied in but the mode is left blank; clearly t
On Sat, Jun 22, 2013 at 01:45:38PM -0300, Eduardo D'Avila wrote:
> 2013/6/22 Øystein Walle :
> > I've gotten the impression it's better to use tput to generate the escape
> > sequences instead of hardcoding them. So something like:
> >
> > local c_red='\['"$(tput setaf 1)"'\]'
> > local c_green='\[
on Sun Jun 23 2013, John Keeping wrote:
> On Sat, Jun 22, 2013 at 07:16:48PM -0700, Dave Abrahams wrote:
>> I also note that the docs
>> don't make it clear that quoting the path is mandatory if it might turn
>> out to be empty.
>
> That's not quite t
On vr, 2013-06-21 at 11:42 -0700, Junio C Hamano wrote:
> > +(!fnmatch(refspec, remote->fetch[i].dst, 0) ||
> > + !fnmatch(remote->fetch[i].dst, refspec, 0))) {
>
> Does .dst always exist and is never a NULL? My quick scan of
> remote.c::parse_refspec_internal() te
On Sat, Jun 22, 2013 at 07:16:48PM -0700, Dave Abrahams wrote:
>
> on Sat Jun 22 2013, John Keeping wrote:
>
> > On Fri, Jun 21, 2013 at 02:21:47AM -0700, Dave Abrahams wrote:
> >> The docs for fast-import seem to imply that I can use "ls" to get the
> >> SHA1 of a commit for which I have a mark
On Sat, Jun 22, 2013 at 1:41 PM, Andreas Krey wrote:
> diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
> index 223f731..007d3fc 100644
> --- a/Documentation/git-daemon.txt
> +++ b/Documentation/git-daemon.txt
> @@ -113,6 +113,10 @@ OPTIONS
> Log to syslog instead o
Junio C Hamano wrote:
>>> Reminds me of the strategy to deprecate functionality in X (cf.
>>> http://lwn.net/Articles/536520/) ;-)
>>
>> Leaving dead code around to confuse readers? :\
>
> We broke the use case to access jgarzik/netdev-2.6 only by having
> jgarzik remote accidentally, and waited fo
Junio C Hamano wrote:
> I'll reject 04/14 and tweak this patch to use 'next' for the new ref
> mappings, not duplicated 'master'.
It's a matter of taste: I don't like "realistic" (albeit misleading)
values when I'm testing configuration variables, while you think they
make the tests more readable.
Ramkumar Ramachandra writes:
>> Reminds me of the strategy to deprecate functionality in X (cf.
>> http://lwn.net/Articles/536520/) ;-)
>
> Leaving dead code around to confuse readers? :\
Did you actually read what was quoted?
We broke the use case to access jgarzik/netdev-2.6 only by having
jg
Ramkumar Ramachandra writes:
> Extend the test "migrate a remote from named file in $GIT_DIR/remotes"
> to test that multiple "Push:" and "Pull:" lines in the remotes-file
> works as expected.
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> t/t5505-remote.sh | 16 ++--
> 1 file chan
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Ramkumar Ramachandra writes:
>>
>>> Under the EXAMPLES section, there is one invocation on the git.git
>>> repository that attempts to list the refs master, pu, and rc. The ref
>>> rc does not exist in today's repository, so remove it. Am
Used only when a clone is initialized. This is useful when the submodule(s)
are huge and you're not really interested in anything but the latest commit.
Signed-off-by: Fredrik Gustafsson
---
git-submodule.sh | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/git-s
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> Under the EXAMPLES section, there is one invocation on the git.git
>> repository that attempts to list the refs master, pu, and rc. The ref
>> rc does not exist in today's repository, so remove it. Among other
>> things, this example demo
Junio C Hamano wrote:
> I do not think you are creating a quux repository to be pushed into
> and fetched from with this change. Placing 'quux' in the "URL:" field
> feels a lot more misleading to me. What am I missing?
Dropped.
I'll send in a re-roll based on what you put up on pu.
--
To unsubs
Junio C Hamano wrote:
> This smells like a largely blind conversion done with a script,
It is :)
> I'll queue with this fix-up squashed in.
Thanks; I really appreciate it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More
Ramkumar Ramachandra writes:
> Modernize the style of all tests throughout the file:
> - Remove spurious blank lines.
> - Indent the test body.
> - Make sure that all lines end with &&, to make it easier to spot breaks
> in the chain.
> - When executing something in a subshell, put the parenthe
"Eduardo D'Avila" writes:
> However, I agree that they became redundant.
>
> Would it make sense to include a patch that only removes the zsh
> tests, after the refactorization?
I think that would be a sensible thing to do.
In any case, Szeder seems to be giving a good guidance on patches in
th
Ramkumar Ramachandra writes:
> Under the EXAMPLES section, there is one invocation on the git.git
> repository that attempts to list the refs master, pu, and rc. The ref
> rc does not exist in today's repository, so remove it. Among other
> things, this example demonstrates that the "..." argum
Ramkumar Ramachandra writes:
> - /*
> - * With "slash", e.g. "git fetch jgarzik/netdev-2.6" when
> - * reading from $GIT_DIR/branches/jgarzik fetches "HEAD" from
> - * the partial URL obtained from the branches file plus
> - * "/netdev-2.6" and does not store it in any tra
58 matches
Mail list logo
