Hi all,
Thanks for your answers:
As you said the solution is:
For non-bare-repos the .git-directory must be specified:
git --git-dir=c:\usertemp\git\appli2\.git tag
for bare-repositories the .git does not exist , so
git --git-dir=c:\usertemp\git\appli3_bare tag
works(bare-repo)
Am 05.12.2013 23:06, schrieb Martin Langhoff:
On Thu, Dec 5, 2013 at 2:54 PM, Jens Lehmann jens.lehm...@web.de wrote:
Am 05.12.2013 20:27, schrieb Martin Langhoff:
On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann jens.lehm...@web.de wrote:
Without knowing more I can't think of a reason why
gitmodules(5) states that submodule.$name.update should be defined in
.gitmodules. However in cmd_update() in git-submodule.sh, git config
is used with -f .gitmodules. Consequently this flag is only
respected in .git/config
Tested against: 1.8.2.1 [sorry! I've checked the relevant bit of
source
Hi,
On another git server, I get reports like
Cloning into 'tcmb'...
remote: Counting objects: 704, done.
remote: Compressing objects: 100% (574/574), done.
remote: Total 704 (delta 369), reused 107 (delta 60)
Receiving objects: 100% (704/704), 129.99 KiB | 23 KiB/s, done.
Resolving deltas: 100%
On Fri, 6 Dec 2013 18:51:47 +0200
Muzaffer Tolga Ozses to...@ozses.net wrote:
On another git server, I get reports like
Cloning into 'tcmb'...
remote: Counting objects: 704, done.
remote: Compressing objects: 100% (574/574), done.
remote: Total 704 (delta 369), reused 107 (delta 60)
On Fri, 6 Dec 2013 21:00:35 +0400
Konstantin Khomoutov flatw...@users.sourceforge.net wrote:
[...]
Resolving deltas: 100% (369/369), done.
whereas I don't get those with my own. What could I be doing wrong?
The documentation on `git push` states:
--progress
Progress status
Tested with git 1.7.12.4 (Apple Git-37) and git 1.8.3.1 on F20.
$ mkdir foo
$ cd foo
$ git init
Initialized empty Git repository in /tmp/foo/.git/
$ mkdir -p modules/boring
$ mkdir -p modules/interesting
$ touch modules/boring/lib.c
$ touch modules/interesting/other.c
$ touch
stty tells me
speed 38400 baud; line = 0;
eol = M-^?; eol2 = M-^?; swtch = M-^?;
ixany iutf8
And I run identical commands on both servers, only URL changes.
On 6 December 2013 19:09, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
On Fri, 6 Dec 2013 21:00:35 +0400
Konstantin
On Fri, Dec 06, 2013 at 07:44:21PM +0200, Muzaffer Tolga Ozses wrote:
stty tells me
speed 38400 baud; line = 0;
eol = M-^?; eol2 = M-^?; swtch = M-^?;
ixany iutf8
And I run identical commands on both servers, only URL changes.
What protocol/transport are you using (http, ssh, git)?
Can
On Fri, 6 Dec 2013 19:44:21 +0200
Muzaffer Tolga Ozses to...@ozses.net wrote:
[...]
Resolving deltas: 100% (369/369), done.
whereas I don't get those with my own. What could I be doing
wrong?
[...]
So it might turn out on your own server Git for some reason fails
to figure out its
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
You
can now say select this path except this subpath... for nearly all
commands that take pathspec.
Good; thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
---
* I'll squash this to tr/config-multivalue-lift-max in preparation
for merging it to 'master',which should happen by the end of
this week.
Thanks.
config.c| 8
t/t1303-wacky-config.sh | 14 +++---
2 files changed, 11 insertions(+), 11 deletions(-)
Sorry, my git server is on CentOS and git 1.8.4.2 and my machine on
which I clone is Ubuntu, 1.8.3.2
On 6 December 2013 21:19, Muzaffer Tolga Ozses to...@ozses.net wrote:
Hi,
What protocol/transport are you using (http, ssh, git)?
I am cloning over http
Can you try running with:
Muzaffer Tolga Ozses wrote:
I am cloning over http
I am guessing you are using the dumb (plain static file transfer)
HTTP protocol. With that protocol the server doesn't do anything
other than shuttle out files, so it doesn't need to do its own
progress reporting.
Perhaps the client should do
On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann jens.lehm...@web.de wrote:
Right you are, we need tutorials for the most prominent use cases.
In the meantime, are there any hints? Emails on this list showing a
current smart workflow? Blog posts? Notes on a wiki?
Early git was very pedantic, and
Jonathan Nieder jrnie...@gmail.com writes:
Muzaffer Tolga Ozses wrote:
I am cloning over http
I am guessing you are using the dumb (plain static file transfer)
HTTP protocol. With that protocol the server doesn't do anything
other than shuttle out files, so it doesn't need to do its own
On Fri, Dec 06, 2013 at 10:46:42AM -0800, Junio C Hamano wrote:
---
* I'll squash this to tr/config-multivalue-lift-max in preparation
for merging it to 'master',which should happen by the end of
this week.
Yeah, all makes sense to me. Thanks.
-Peff
--
To unsubscribe from this list:
On Thu, Dec 05, 2013 at 01:44:12PM -0800, Junio C Hamano wrote:
;-) Good flow of thought. As to your rev-parse change, I don't
immediately think of a hole/flaw offhand; it looked a good
straight-forward change to me.
Here it is with tests and a commit message. While writing the tests, I
Rev-parse understands that a -- may separate revisions and
filenames, and that anything after the -- is taken as-is.
However, it does not understand that anything before the
token must be a revision (which is the usual rule
implemented by the setup_revisions parser).
Since rev-parse prefers
If you have both a file and a branch named foo, running:
git log foo
will complain. We should do the same in rev-parse, and
demand that it be disambiguated with:
git rev-parse foo --
or
git rev-parse -- foo
Signed-off-by: Jeff King p...@peff.net
---
Hmm, looking at this again, I guess
I would like to discuss a very important crude oil project with you,kindly
revert back to me if this is your valid email address for further
information.
Regards,
Lee
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
On Fri, Dec 06, 2013 at 04:15:09PM -0500, Jeff King wrote:
If you have both a file and a branch named foo, running:
git log foo
will complain. We should do the same in rev-parse, and
demand that it be disambiguated with:
git rev-parse foo --
or
git rev-parse -- foo
Rev-parse understands that a -- may separate revisions and
filenames, and that anything after the -- is taken as-is.
However, it does not understand that anything before the
token must be a revision (which is the usual rule
implemented by the setup_revisions parser).
Since rev-parse prefers
If you have both a file and a branch named foo, running:
git log foo
will complain. We should do the same in rev-parse, and
demand that it be disambiguated with:
git rev-parse foo --
or
git rev-parse -- foo
Signed-off-by: Jeff King p...@peff.net
---
builtin/rev-parse.c| 12
On Fri, Dec 06, 2013 at 08:15:52AM +0700, Duy Nguyen wrote:
On Fri, Dec 6, 2013 at 4:28 AM, Jeff King p...@peff.net wrote:
BTW, the raw looping to find -- made me wonder how we handle:
git log --grep -- HEAD
I'd expect it to be equivalent to:
git log --grep=-- HEAD
but it's
On Thu, Dec 05, 2013 at 02:59:45PM -0800, Junio C Hamano wrote:
One test needs to be updated, because it actually corrupts a
pack and expects that re-packing the corrupted bytes will
use the same name. It won't anymore, but we can easily just
use the name that pack-objects hands back.
Heiko Voigt hvo...@hvoigt.net writes:
When the user wants to bypass the ignored status configured by
submodule.name.ignore=all it is now allowed by using the -f option.
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
---
builtin/add.c | 49 +
Jeff King wrote:
Patch 3 is the revised version of this patch which notices ambiguity.
However, I'm having second thoughts on it. I think it's the right thing
to do if you want to help people build something like git log
themselves. But it does mean that we are breaking somebody who does:
Jeff King wrote:
Since rev-parse prefers revisions to files when parsing
before the --, we end up with the correct result (if such
an argument is a revision, we parse it as one, and if it is
not, it is an error either way). However, we misdiagnose
the errors:
$ git rev-parse foobar --
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of 'next' has been rewound, ejecting a few topics that
used to be there.
You can find the changes described here in the integration
Jeff King wrote:
As an aside, this is one of those places where C's string functions do
gross things with const.
Yes, yuck.
The fundamental grossness is that argv is semantically char **
(assuming this doesn't segfault) but passed around as const char **.
I wonder why we don't use the same
2013/12/7 Martin Langhoff martin.langh...@gmail.com:
Tested with git 1.7.12.4 (Apple Git-37) and git 1.8.3.1 on F20.
$ mkdir foo
$ cd foo
$ git init
Initialized empty Git repository in /tmp/foo/.git/
$ mkdir -p modules/boring
$ mkdir -p modules/interesting
$ touch modules/boring/lib.c
$
On Fri, Dec 6, 2013 at 1:11 PM, Junio C Hamano gits...@pobox.com wrote:
Samuel Bronson naes...@gmail.com writes:
Thanks for reviving a stalled topic.
I was asking about such a feature in #git and jrnieder was nice enough
to point me at the stalled patch.
*I* even verified that the tests do
On Sat, Dec 7, 2013 at 12:26 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
# Untracked files:
# (use git add file... to include in what will be committed)
#
# modules/boring/
# modules/interesting/other.c
$ echo '/modules/' .gitignore
$ echo '!/modules/interesting/' .gitignore
After a86a8b9 (sb/parseopt-boolean-removal), the deprecated
OPT_BOOLEAN is not used anywhere except by OPT__* macros. Kill
OPT_BOOLEAN and make OPT__* use OPT_COUNTUP directly instead. This
should stop OPT_BOOLEAN from entering the tree again in new patches.
OPT__DRY_RUN() is converted to use
35 matches
Mail list logo
