Jeff King wrote:
So I do not see any problem with the current Makefile. Running make or
make test should let t5800 pass. Can you describe how you are
triggering the issue in more detail?
master, at the time of reporting the issue:
artagnon|master=:~/src/git$ make -j 8
On Fri, Jun 21, 2013 at 12:07:50PM +0530, Ramkumar Ramachandra wrote:
Yesterday's jc publish fixed it: 6c473a5 (build: generate and clean
test scripts, 2013-06-07) graduated to master; it adds $NO_INSTALL to
the target all, among other things.
Ah, makes sense. Sorry to be slow.
-Peff
--
To
Jeff King wrote:
So I'm not sure if there is a better option than reverting 81d340d4 and
living with the lesser of two evils (no good message when the helper
dies silently).
I dug around, but I still can't justify that there is no better
option. Could you write a commit message for this?
--
Ramkumar Ramachandra wrote:
diff --git a/transport-helper.c b/transport-helper.c
index 06c08a1..db9bd18 100644
--- a/transport-helper.c
+++ b/transport-helper.c
Oh, and we have to remove test 23 - proper failure checks for
pushing from t5801-remote-helpers.sh.
--
To unsubscribe from this
On Fri, Jun 21, 2013 at 12:14:33PM +0530, Ramkumar Ramachandra wrote:
Jeff King wrote:
So I'm not sure if there is a better option than reverting 81d340d4 and
living with the lesser of two evils (no good message when the helper
dies silently).
I dug around, but I still can't justify
Hi,
On Thu, Jun 20, 2013 at 3:47 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Francis Moreau wrote:
Basically I have an initial set (or can be several different sets)
expressed as a revision specification described by git-rev-list man
page. I just want to find the common set of commit
Francis Moreau wrote:
Slower ? why do you think Thomas' solution is slower than the obvious one ?
There's really only one way to find out: try it and see. YMMV
depending on your data.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
From: Yaakov Selkowitz yselkow...@users.sourceforge.net
While both GUI and console Cygwin browsers do exist, anecdotal evidence
suggests most users rely on their native Windows browser. cygstart,
which is a long-standing part of the base Cygwin installation, will
cause the page to be opened in
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:
Reading from a named tree
The dataref can be a mark reference (:idnum) or the full 40-byte
SHA-1 of a Git tag, commit, or tree object, preexisting or waiting
1/3 should be pretty sane, just adding a warning in documentation and 'git
remote add' about overlapping refspecs.
2/3 only makes sense if 3/3 is accepted, as it's a test for that change.
3/3 I'm not 100% sure about, though the approach feels reasonably ok. It changes
get_stale_heads to also
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin would mark all refs from other repos as
stale. There's no good way to solve, this so the best thing we can do
is refusing to prune if we detect this and warning the user.
Signed-off-by: Dennis Kaarsemaker
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
t/t5505-remote.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index dd10ff0..439e996 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -428,6 +428,15 @@ test_expect_success
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin will mark all refs from other repos as stale.
Add a warning to the documentation, and warn the user when we detect
such things during git remote add.
Signed-off-by: Dennis Kaarsemaker
On Thu, Jun 20, 2013 at 9:16 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Hi,
So this should explain the problem:
# using v1.8.3.1
$ git clone https://google.com
Cloning into 'google.com'...
fatal: repository 'https://google.com/' not found
# using master
$ git clone
Hi,
Until now, my interest in corrupted repositories has been very
limited. Just now, the power went out for a second and my UPS failed
me. As a result, my ~/src/git is completely borked. For your
amusement, here's a quick session showing me bumbling around:
$ ~/src/git
error: object file
Junio C Hamano wrote:
* rr/triangle-push-fix (2013-06-20) 9 commits
- push: honor branch.*.push
- SQUASH??? fix git-config push.default description
- SQUASH??? minimum simple safety fix-up
- t/t5528-push-default: test pushdefault workflows
- t/t5528-push-default: generalize test_push_*
Hi,
This is a cleanup operation to get rid of the historical
$GIT_DIR/{branches,remotes} cruft. Mostly no-brainers that don't
deserve a second look. The ordering of the series might be somewhat
weird, but that's because it's the order in which I wrote those
patches: rebasing results in stupid
One outdated example encourages the use of $GIT_DIR/branches files.
Replace it with an equivalent example using a remote.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-ls-remote.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
remote.c | 8
1 file changed, 8 insertions(+)
diff --git a/remote.c b/remote.c
index 128b210..b487865 100644
--- a/remote.c
+++ b/remote.c
@@ -227,6 +227,10 @@ static void add_instead_of(struct rewrite *rewrite, const
char
Since we plan to edit the test migrate a remote from named file in
$GIT_DIR/remotes in later patches, modernize the subshell-style by
putting the parenthesis on separate lines and indenting the body.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5505-remote.sh | 20
Replace it with the equivalent gitconfig configuration, using the
results of the corresponding tests in t/t5505-remote.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5515-fetch-merge-logic.sh | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
The test migrate a remote from named file in $GIT_DIR/branches reads
the branches-file, but only checks that the url and fetch-refspec are
set correctly. Check that the push-refspec is also set correctly.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5505-remote.sh | 3 ++-
1
Replace instances of ! test -f with test_path_is_missing.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5505-remote.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 38c62ec..dcb6c2f 100755
---
Replace the repository paragraph containing specific references to
$GIT_DIR/branches and . with a generic urls-or-remotes paragraph
referencing the relevant sections in the git-fetch(1) manpage.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-ls-remote.txt | 6 +++---
Add one more test similar to migrate a remote from named file in
$GIT_DIR/branches to check that a url with a # can be used to specify
the branch name (as opposed to the constant master).
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5505-remote.sh | 23 +++
1
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 artag...@gmail.com
---
t/t5505-remote.sh | 16 ++--
1 file changed, 14 insertions(+), 2
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.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-ls-remote.txt | 3 +--
1
Since we plan to edit the test migrate a remote from named file in
$GIT_DIR/remotes in later patches, modernize the subshell-style by
putting the parenthesis on separate lines and indenting the body.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5505-remote.sh | 16
The first line of the function checks that the remote-name contains a
slash ('/'), and sets the slash variable accordingly. The only caller
of read_branches_file() is remote_get_1(); the calling codepath is
guarded by valid_remote_nick(), which checks that the remote does not
contain a slash.
Four tests exercising fetch and push functionality unnecessarily depend
on $GIT_DIR/branches files. Modern Git does not encourage the use of
those files, and the parser remote.c:read_branches_file() is only
provided for backward compatibility with older repositories. We already
have tests in
In the tests migrate a remote from named file in
$GIT_DIR/{remotes,branches}, we are only checking that a configuration
is migrated successfully; it has no correspondence with whether or not
those values do something sensible with other git
operations (fetch/push). Therefore, there is no need to
Replace it with the equivalent gitconfig configuration, using the
results of a test in t/t5505-remote.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t5510-fetch.sh | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
2901bbe (apply: free patch-{def,old,new}_name fields, 2012-03-21)
cleaned up the memory management of filenames in the patches, but
forgot that find_name_traditional() can return NULL as a way of saying
I couldn't find a name.
That NULL unfortunately gets passed into xstrdup() next, resulting in
Hi,
Following my previous email Tracking vendor release with Git [1][2],
and the advice from Git users/developers, I'm trying to use
.gitattributes
to handle CRLF/LF conversion.
While testing the behavor of Git regarding CRLF handling,
when core.safecrlf is set to true, I've found that git
Hi (again),
Following my previous email Tracking vendor release with Git [1][2],
and the advice from Git users/developers, I'm trying to use
.gitattributes
to handle CRLF/LF conversion.
I'm following advices from:
- Dealing with line endings
Hi,
Le 21.06.2013 15:41, Yann Droneaud a écrit :
I believe git rebase should not fail here, but more, it must not
fail in a different fashion randomly.
Please find in reply to this email:
- a shell script to demonstrate the behavor
Please find a shell script to test git rebase with
This patch add two tests to reproduce the problems described
in thread git rebase fail with CRLF conversion
fb20a7d711fdd218f58f1f2090b1c...@meuh.org
http://thread.gmane.org/gmane.comp.version-control.git/228613
http://marc.info/?l=gitm=137182211414404w=2
- Add and commit a file with CRLF,
-
Le 21.06.2013 16:15, Yann Droneaud a écrit :
This patch add two tests to reproduce the problems described
in thread git rebase fail with CRLF conversion
fb20a7d711fdd218f58f1f2090b1c...@meuh.org
http://thread.gmane.org/gmane.comp.version-control.git/228613
Le 21.06.2013 15:41, Yann Droneaud a écrit :
In thoses two latter cases, running git add does not fail with a
fatal error: it does nothing.
I need to run touch test to make git add fail with error fatal:
CRLF would be replaced by LF in test.
While searching on the Internet, I've found other
Ramkumar Ramachandra artag...@gmail.com writes:
This is a cleanup operation to get rid of the historical
$GIT_DIR/{branches,remotes} cruft. Mostly no-brainers that don't
deserve a second look.
Only reacting to no-brainer.
The last time I hinted removal of .git/branches/, Andrew Morton
Johannes Sixt j.s...@viscovery.net writes:
Am 6/20/2013 20:11, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net writes:
But you can't have this string:
Splitting a commit while rebasing branch '%2$s' on '%3$s'.
neither in the template nor in the translation, because the numbers
Yann Droneaud ydrone...@opteya.com writes:
While testing the behavor of Git regarding CRLF handling,
when core.safecrlf is set to true, I've found that git diff is
returning
fatal: CRLF would be replaced by LF without returning any kind of
diff.
This make me wonder if its the correct
Ramkumar Ramachandra artag...@gmail.com writes:
Four topics are awaiting review (they're important to me in this order):
- rr/for-each-ref-pretty at $gmane/227057.
No comment on this at this moment.
- rr/describe-contains-all at $gmane/228278.
This may overlap with a topic in flight (but
Jeff King p...@peff.net writes:
Note that I haven't thought too hard about this; there may be a way to
detect for specific operations that we were expecting more data from the
helper and didn't get it. But even if we do want to go that route, I
think reverting the change to recvline_fh is
Yaakov (Cygwin/X) yselkow...@users.sourceforge.net writes:
From: Yaakov Selkowitz yselkow...@users.sourceforge.net
While both GUI and console Cygwin browsers do exist, anecdotal evidence
suggests most users rely on their native Windows browser. cygstart,
which is a long-standing part of the
Junio C Hamano wrote:
- rr/describe-contains-all at $gmane/228278.
This may overlap with a topic in flight (but I didn't look at it).
Let me know if I can do anything to make it easier for you. I'm quite
excited about this one.
- rr/mixed-case-aliases at $gmane/227959.
Personally, not
Any Mercurial tag/branch/bookmark that ended with a period would be
rejected by fast-import. The repository could be cloned, but any
further fetch would fail.
Use a similar trick to the space handling, but only when the period is
at the end of the ref.
Probably need a more general solution to
Junio C Hamano wrote:
The last time I hinted removal of .git/branches/, Andrew Morton
reminded me that there are those who use Git primarily to fetch from
many dozens of other people's branches, to maintain his own quilt
patch series on top of, and never push anything back. To them,
being
Ramkumar Ramachandra artag...@gmail.com writes:
$ ~/src/git
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
fatal: loose object
Jonathan Nieder jrnieder at gmail.com writes:
After sleeping on it, here are two patches for 'maint'. One plugs a
memory leak. The other makes my above comment actually true, so
trying to use this missing feature results in an error message that
can help the frontend author instead of the
Junio C Hamano gits...@pobox.com writes:
I myself thought that replacing the established work process of
these people to the one that instead uses git config should be
simple enough even back then, and in the longer term, these old
mechanisms will become disused so that we can remove them,
Junio C Hamano wrote:
$ ~/src/git
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
error: object file
.git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
in
Ramkumar Ramachandra artag...@gmail.com writes:
... I've noticed a significant decline in
list-reviews in general: a lot of good code on the list hasn't been
reviewed.
Hmph, I do not particularly see that happening.
I actually think all the usual suspects (I could name them, but I
Hi,
With bash-3.0 (NOTE: CentOS 4's /bin/sh is actually a symlink to bash 3.0),
t/t1402-check-ref-format.sh failed.
Here is output.
% ~/bash-3.0.16/bin/bash --version
GNU bash, version 3.00.16(2)-release (x86_64-unknown-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
% cd ~/git/t
%
On Jun 21, 2013, at 12:49 AM, Jeff King p...@peff.net wrote:
I'm not sure what else to look at...I guess try ratcheting up the
debugging/log level on your failing copy and see if it prints anything
useful.
I found this error in the error.log:
[Fri Jun 21 12:59:59 2013] [emerg] (2)No such
Heiko Voigt hvo...@hvoigt.net writes:
Hi,
On Mon, Jun 17, 2013 at 11:55:36AM +0200, Fredrik Gustafsson wrote:
set_rev_name is a possible expensive operation. If a submodule has
changes in it, set_rev_name was called twice.
Solution is to move set_rev_name so it's only called once, no
John Szakmeister j...@szakmeister.net writes:
On Thu, Jun 20, 2013 at 9:16 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Hi,
So this should explain the problem:
# using v1.8.3.1
$ git clone https://google.com
Cloning into 'google.com'...
fatal: repository
Junio C Hamano wrote:
... I've noticed a significant decline in
list-reviews in general: a lot of good code on the list hasn't been
reviewed.
Hmph, I do not particularly see that happening.
Observer bias. To verify either claim, could you run some stats on
the ML archives [1] and report
On Fri, Jun 21, 2013 at 7:13 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Junio C Hamano wrote:
... I've noticed a significant decline in
list-reviews in general: a lot of good code on the list hasn't been
reviewed.
Hmph, I do not particularly see that happening.
Observer bias. To
On Fri, Jun 21, 2013 at 01:03:40PM -0400, Brian Gernhardt wrote:
On Jun 21, 2013, at 12:49 AM, Jeff King p...@peff.net wrote:
I'm not sure what else to look at...I guess try ratcheting up the
debugging/log level on your failing copy and see if it prints anything
useful.
I found this
On Jun 21, 2013, at 2:03 PM, Jeff King p...@peff.net wrote:
IfVersion comes from mod_version. I assume that if it were not loaded,
apache would complain about the directive entirely. But it's true that
we don't load it until later. Maybe try moving the IfVersion/Lockfile
stanza down below
On Fri, Jun 21, 2013 at 02:08:49PM -0400, Brian Gernhardt wrote:
On Jun 21, 2013, at 2:03 PM, Jeff King p...@peff.net wrote:
IfVersion comes from mod_version. I assume that if it were not
loaded, apache would complain about the directive entirely. But it's
true that we don't load it
On Jun 21, 2013, at 2:12 PM, Jeff King p...@peff.net wrote:
On Fri, Jun 21, 2013 at 02:08:49PM -0400, Brian Gernhardt wrote:
On Jun 21, 2013, at 2:03 PM, Jeff King p...@peff.net wrote:
IfVersion comes from mod_version. I assume that if it were not
loaded, apache would complain about the
On Fri, Jun 21, 2013 at 02:15:39PM -0400, Brian Gernhardt wrote:
Cool. I think the patch should look like the one below, then.
Basically identical to what I've done, you're just faster to the actual
patch. :-D
I started writing the rationale immediately after making the suggestion,
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
... I've noticed a significant decline in
list-reviews in general: a lot of good code on the list hasn't been
reviewed.
Hmph, I do not particularly see that happening.
Observer bias. To verify either claim, could you
Dennis Kaarsemaker den...@kaarsemaker.net writes:
When cloning a repo with --mirror, and adding more remotes later,
Even though --mirror is not the only way to trigger this, I think it
is good to mention it because it is the most common way to do so.
get_stale_heads for origin will mark all
Mostly fixes to initial indentation with 8-SP (they should be HT)
and wrapping long lines.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/lib-t6000.sh | 87 +++---
1 file changed, 40 insertions(+), 47 deletions(-)
diff --git
The --date-order output is a slight twist of --topo-order in
that commits from parallel histories are shown in their committer
date order without an attempt to clump commits from a single line
of history together like --topo-order does.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Complete the series to teach --author-date-order to the commands
in the log family by adding some tests.
We did not have explicit tests for --date-order, so the third patch
in this series adds one while at it.
Junio C Hamano (5):
t/lib-t6000: style fixes
topology tests: teach a helper to
The on_committer_date helper in t/lib-t6000 is used in t6002 and
t6003 with timestamps on a single day within a single minute
(i.e. 1971-08-16 00:00) and the tests repeat this over and over.
The actual value of the timestamp, however, does not matter very
much; only their relative ordering does.
Junio C Hamano wrote:
Unfortunately, I tend to become bottleneck more often than you do,
so I do not think that would be a good use of my time.
Besides, as Antoine points out, those numbers might well be useless
(or worse, misleading). It's probably not worth the effort.
Which ones went
Tweak the --topo/date-order test vector a bit and mark the author
dates of two commits (a2 and a3) earlier than their own committer
dates, making them much older than other commits that are made on
parallel branches to simulate the case where a long running topic
was rebased recently.
They will
Introduce on_dates helper that is similar to on_committer_date but
also sets the author date, not just the committer date.
At this step, just set the same timestamp to the author date as the
committer date, as no test looks at author date yet.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Dennis Kaarsemaker den...@kaarsemaker.net writes:
+static int check_overlapping_remotes(struct remote *first, void *priv) {
+ struct remote *second = priv;
+ int i, j;
+ if(!second)
+ return for_each_remote(check_overlapping_remotes, first);
+ if(first == second)
Ramkumar Ramachandra artag...@gmail.com 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
fatal: loose object
Junio C Hamano wrote:
So from my point of view, a proposal to remove them has an almost no
benefit vs potentially very high cost of having to break many people
who are silently happily using them; not a very good benefit/cost
ratio.
Yep, it should stay around because it's useful to some
Junio C Hamano wrote:
A tl;dr is that we _trust_ our refs and everything reachable from
them has to be complete. If that is not the case, things will not
work, and it is not a priority to add workarounds in the normal
codepath to slow things down.
Makes sense.
That does not forbid an
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
- rr/describe-contains-all at $gmane/228278.
This may overlap with a topic in flight (but I didn't look at it).
Let me know if I can do anything to make it easier for you. I'm quite
excited about this one.
-
Arnaud Fontaine ar...@debian.org writes:
Merge strategy and its options can be specified in `git rebase`,
but with `--interactive`, they were completely ignored.
And why is it a bad thing? If you meant s/--interactive/-m/ in the
above, then I can sort of understand the justification, though.
Jeff King p...@peff.net writes:
Cool. I think the patch should look like the one below, then.
Just to double-check that I have explained the issue correctly, can you
share the output of apache2 -l? Mine has:
$ apache2 -l
Compiled in modules:
core.c
mod_log_config.c
Junio C Hamano gits...@pobox.com writes:
The helper may want to learn a way to be told to demote that error
to a warning.
Perhaps something like this?
diff.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/diff.c b/diff.c
index f0b3e7c..9b4f3ac 100644
--- a/diff.c
Ramkumar Ramachandra artag...@gmail.com writes:
Since we plan to edit the test migrate a remote from named file in
$GIT_DIR/remotes in later patches, modernize the subshell-style by
putting the parenthesis on separate lines and indenting the body.
Signed-off-by: Ramkumar Ramachandra
Ramkumar Ramachandra artag...@gmail.com writes:
The test migrate a remote from named file in $GIT_DIR/branches reads
the branches-file, but only checks that the url and fetch-refspec are
set correctly. Check that the push-refspec is also set correctly.
Signed-off-by: Ramkumar Ramachandra
Ramkumar Ramachandra artag...@gmail.com writes:
In the tests migrate a remote from named file in
$GIT_DIR/{remotes,branches}, we are only checking that a configuration
is migrated successfully; it has no correspondence with whether or not
those values do something sensible with other git
Ramkumar Ramachandra artag...@gmail.com writes:
The first line of the function checks that the remote-name contains a
slash ('/'), and sets the slash variable accordingly. The only caller
of read_branches_file() is remote_get_1(); the calling codepath is
guarded by valid_remote_nick(), which
Ramkumar Ramachandra artag...@gmail.com writes:
Add one more test similar to migrate a remote from named file in
$GIT_DIR/branches to check that a url with a # can be used to specify
the branch name (as opposed to the constant master).
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
Ramkumar Ramachandra artag...@gmail.com writes:
Four tests exercising fetch and push functionality unnecessarily depend
on $GIT_DIR/branches files. Modern Git does not encourage the use of
those files, and the parser remote.c:read_branches_file() is only
provided for backward compatibility
Ramkumar Ramachandra artag...@gmail.com writes:
Replace the 'git config' calls in tests with test_config for greater
robustness.
That may be a good thing in principle, but I _think_
mk_empty testrepo
(
cd testrepo
do whatever to its config
Ramkumar Ramachandra artag...@gmail.com 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.
Hmph, I am on the fence but slightly on the negative
Ramkumar Ramachandra artag...@gmail.com writes:
Replace the repository paragraph containing specific references to
$GIT_DIR/branches and . with a generic urls-or-remotes paragraph
referencing the relevant sections in the git-fetch(1) manpage.
Signed-off-by: Ramkumar Ramachandra
On Fri, Jun 21, 2013 at 7:12 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
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 artag...@gmail.com
---
91 matches
Mail list logo
