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) correct
Am 05.12.2013 23:06, schrieb Martin Langhoff:
> On Thu, Dec 5, 2013 at 2:54 PM, Jens Lehmann wrote:
>> Am 05.12.2013 20:27, schrieb Martin Langhoff:
>>> On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann wrote:
Without knowing more I can't think of a reason why submodules should
not suit your
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 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)
> Receiving objects
On Fri, 6 Dec 2013 21:00:35 +0400
Konstantin Khomoutov 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 is reported on the s
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 modules/interesting/l
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
wrote:
> On Fri, 6 Dec 2013 21:00:35 +0400
> Konstantin Khomoutov wrote:
>
> [...]
>> > Res
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)?
On Fri, 6 Dec 2013 19:44:21 +0200
Muzaffer Tolga Ozses 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 o
Samuel Bronson writes:
> From: Anders Waldenborg
>
> diff.orderfile acts as a default for the -O command line option.
>
> [sb: fixed testcases & revised docs based on Jonathan Nieder's suggestions]
>
> Signed-off-by: Anders Waldenborg
> Thanks-to: Jonathan Nieder
> Signed-off-by: Samuel Bronso
Nguyễn Thái Ngọc Duy 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 majordomo info at
---
* 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(-)
Hi,
> What protocol/transport are you using (http, ssh, git)?
I am cloning over http
> Can you try running with:
GIT_TRACE_PACKET=$PWD/trace.out git clone ...
GIT_TRACE_PACKET=$PWD/trace.out git clone
http://git.webciniz.im/project/night_pharmacy.git
Cloning into 'night_pharmacy'...
Checking co
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 wrote:
> Hi,
>
>> What protocol/transport are you using (http, ssh, git)?
> I am cloning over http
>
>> Can you try running with:
>
> GIT_TRACE_PACK
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
On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann 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 over time it lea
Jonathan Nieder 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
> progress
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 lis
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
no
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 re
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
---
Hmm, looking at this again, I guess we need to g
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 m
Zoltan Klinger writes:
> Reworked patch to use run_command_v_opt_cd_env() function when invoking
> the external diff program. Modified test script to use write_script
> helper function.
Thanks; will queue with a minor tweak.
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
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 --
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 re
When rev-parse looks at whether an argument like "foo..bar"
or "foobar^@" is a difference or parent-shorthand, it
internally munges the arguments so that it can pass the
individual rev arguments to get_sha1. However, we do not
consistently un-munge the result.
For cases where we do not match (e.g.
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
---
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 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
> >
> > b
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 ba
On Fri, Dec 06, 2013 at 11:26:51AM -0800, Jonathan Nieder 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
Heiko Voigt writes:
> When the user wants to bypass the ignored status configured by
> submodule..ignore=all it is now allowed by using the -f option.
>
> Signed-off-by: Heiko Voigt
> ---
> builtin/add.c | 49 +
> submodule.c | 10 ++
>
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
On Fri, Dec 06, 2013 at 03:25:56PM -0800, Jonathan Nieder wrote:
> > commit=$(git rev-parse HEAD)
> >
> > I'm tempted to say that people who did that are stupid and wrong (and
> > ugly, too). They should probably be using "--verify" in this case. But
> > it has been that way for a long time, and
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 foo
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 bra
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 t
2013/12/7 Martin Langhoff :
> 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/in
On Fri, Dec 6, 2013 at 1:11 PM, Junio C Hamano wrote:
> Samuel Bronson 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 fail properly when the feature i
On Sat, Dec 7, 2013 at 12:26 AM, Martin Langhoff
wrote:
> # Untracked files:
> # (use "git add ..." to include in what will be committed)
> #
> # modules/boring/
> # modules/interesting/other.c
>
> $ echo '/modules/' > .gitignore
> $ echo '!/modules/interesting/' >> .gitignore
Once you ignore t
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 OPT_
41 matches
Mail list logo
