On Thu, Jan 15, 2015 at 07:27:34PM -0800, Kyle J. McKay wrote:
> >We implement NOT_ROOT by checking perl's "$>" variable,
> >since we cannot rely on the "id" program being available
> >everywhere (and we would rather avoid writing a custom C
> >program to run geteuid if we can).
>
> Does it make
On Jan 15, 2015, at 17:32, Jeff King wrote:
On Thu, Jan 15, 2015 at 04:04:24PM -0800, Junio C Hamano wrote:
I wondered what 'perl -e 'print $>' would say in mingw, and if that
is portable enough, though.
Good thinking. I guess the best way to find out is to convince
somebody
from msysgit
On Thu, Jan 15, 2015 at 04:04:24PM -0800, Junio C Hamano wrote:
> I wondered what 'perl -e 'print $>' would say in mingw, and if that
> is portable enough, though.
Good thinking. I guess the best way to find out is to convince somebody
from msysgit to try this patch. :)
We may simply find that n
"Kyle J. McKay" writes:
> On Jan 13, 2015, at 11:58, Jeff King wrote:
> ...
> I'm running curl 7.38, and in this context "older" is anything before
> 7.40, so that would explain it. curl 7.38 was released 2014-09-10, so
> it's only 4 months old at this point. 7.40 was only released 5 days
> ago
Ramkumar Ramachandra wrote:
> Eric Wong wrote:
> > I haven't seen this before. Which SVN Perl binding version are you
> > using? Perhaps your "svnadmin" tool is from a different SVN version
> > or installation of SVN than your Perl bindings?
>
> I have two installations of Subversion: the syste
Eric Wong wrote:
> I haven't seen this before. Which SVN Perl binding version are you
> using? Perhaps your "svnadmin" tool is from a different SVN version
> or installation of SVN than your Perl bindings?
I have two installations of Subversion: the system one is at
/Library/Developer/CommandLin
Hi,
I noticed that GitWeb caches based on the "Last-Modified" header.
Won't this break if somebody force pushes a branch with the new newest
commit being older than the previous? The modification date will be
older, which makes little sense to HTTP clients, and it would probably
break since they u
Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
> > To which a natural reaction was "Can the existing breakage
> > demonstrated by a test?".
>
> There's a lot to do, if we really want to dig deeper.
>
> The second git-svn-basic test onwards doesn't pass for me, so I really
> can't do much in
Jeff King writes:
> Exactly. I am happy to submit a patch, but I cannot think of any
> mechanisms besides:
>
> 1. Calling `id`, which I suspect is very not portable.
>
> 2. Writing a C program to check getuid(). That's portable for most
> Unixes. It looks like we already have a hacky wra
On Thu, Jan 15, 2015 at 03:20:09PM -0800, Junio C Hamano wrote:
> OK, thanks. Let's queue something like this for post 2.3 cycle,
> then.
>
> -- >8 --
> Subject: CodingGuidelines: clarify C #include rules
> [...]
Thanks, this looks good to me.
-Peff
--
To unsubscribe from this list: send the l
On Thu, Jan 15, 2015 at 02:39:56PM -0800, Junio C Hamano wrote:
> Before writing that patchlet, I briefly looked at grep output and
> thought that many that are protected only by SANITY lacked POSIXPERM
> by mistake:
>
> t/t1004-read-tree-m-u-wf.sh:test_expect_success SANITY 'funny symlink in...
Junio C Hamano wrote:
> To which a natural reaction was "Can the existing breakage
> demonstrated by a test?".
There's a lot to do, if we really want to dig deeper.
The second git-svn-basic test onwards doesn't pass for me, so I really
can't do much in the way of contributing tests until that's f
On Thu, Jan 15, 2015 at 03:24:15PM -0800, Stefan Beller wrote:
> I see the performance problem as well as the contention problem
> you're pointing out. Dealing with loose refs however creates other
> problems such as directory/file conflicts on renaming. I am trying to
> think of a way which moves
Jeff King writes:
> On Thu, Jan 15, 2015 at 12:36:00PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > FWIW, the full set of CFLAGS I use (which I specify in config.mak) is:
>> >
>> > CFLAGS += -Wall -Werror
>> > CFLAGS += -Wno-format-zero-length
>> > CFLAGS += -Wdeclara
Stefan Beller writes:
> In ref_transaction_commit
> * commit the .lock file to its destination
> * in case this is a deletion:
> * remove the loose ref
> * and repack the packed refs file if necessary
Don't you need to repack and then remove the loose one,
Eric Wong writes:
> Junio C Hamano wrote:
>> Thanks. No tests necessary/feasible? Just being curious.
>
> They seemed simple and obvious enough to me,
> (and most importantly, didn't trigger regressions).
I can see that the top-most one is about .git that is a textual
symlink ".gitdir: " and
On Thu, Jan 15, 2015 at 2:46 PM, Jeff King wrote:
> On Thu, Jan 15, 2015 at 02:36:11PM -0800, Stefan Beller wrote:
>
>> So for here is my proposal for small transactions:
>> (just one ref [and/or reflog] touched):
>
> The implication being that a "large" transaction is any with more than
> one upd
Jeff King writes:
> On Thu, Jan 15, 2015 at 10:50:45AM -0800, Junio C Hamano wrote:
>> ...
>> Thoughts? I am not looking forward to a torrent of patches whose
>> sole purpose is to make the existing C files conform to any such
>> rule, though. Clean-up patches that trickle in at a low rate is
Junio C Hamano wrote:
> Thanks. No tests necessary/feasible? Just being curious.
They seemed simple and obvious enough to me,
(and most importantly, didn't trigger regressions).
If Ramkumar or anybody else has the time, I'd welcome them.
--
To unsubscribe from this list: send the line "unsubscr
On Thu, Jan 15, 2015 at 02:36:11PM -0800, Stefan Beller wrote:
> So for here is my proposal for small transactions:
> (just one ref [and/or reflog] touched):
The implication being that a "large" transaction is any with more than
one update.
I think performance may suffer if you do not also take
Jeff King writes:
> The current scheme does not require POSIXPERM. Would this mean that
> some platforms no longer runs SANITY tests (e.g., Windows)?
>
> Many of the SANITY-marked tests already require both, but not all.
Before writing that patchlet, I briefly looked at grep output and
thought t
On Thu, Jan 15, 2015 at 10:50:45AM -0800, Junio C Hamano wrote:
> So the rule might be:
>
> - The first #include in C files, except in platform specific
>compat/ implementations, must be either git-compat-util.h,
>cache.h or builtin.h.
>
> - A C file must directly include the header fi
For everyday use we want git to be fast. Creating one commit should not
touch the packed refs file. If we do other stuff involving more than
one ref, we may accept touching the packed refs file and have a process
which takes slightly longer but can handle more complex requests correctly,
such as re
On Thu, Jan 15, 2015 at 12:36:00PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > FWIW, the full set of CFLAGS I use (which I specify in config.mak) is:
> >
> > CFLAGS += -Wall -Werror
> > CFLAGS += -Wno-format-zero-length
> > CFLAGS += -Wdeclaration-after-statement
> > C
On Thu, Jan 15, 2015 at 12:29:39PM -0800, Junio C Hamano wrote:
> This should not be the final patch (I think it should become a lazy
> prereq as it does a lot more), but just for testing, how does this
> look?
>
> t/test-lib.sh | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
"Jason Pyeron" writes:
>> Looking at http_config() there, I would guess perhaps:
>>
>> [http]
>> uploadpack = false
>> getanyfile = false
>>
>> but I am not sure if the latter is needed (or anybody seriously
>> tested it, for that matter).
>
> Perfect! Had to add receivepack
> -Original Message-
> From: Junio C Hamano
> Sent: Thursday, January 15, 2015 14:31
>
> "Jason Pyeron" writes:
>
> > I am setting up a continous integration (CI) system for an
> open source
> > project and I want to allow forking developers to use the
> system, but
> > I do not want a
Add more test coverage to the atomic push option. It turns out there is a
breakage when renaming branches within an atomic push. The breakage occurs
because it cannot lock the refs v/v as well as x.
Signed-off-by: Stefan Beller
---
t/t5543-atomic-push.sh | 49
Junio C Hamano writes:
> I do not think that output order is very helpful. Two diffs to the
> same file next to each other may make it easier to notice, though.
> ...
> or it may want to even be like this:
>
> diff --git a/A b/A
> ...
> diff --git to-be-committed/A left-o
Jeff King writes:
> FWIW, the full set of CFLAGS I use (which I specify in config.mak) is:
>
> CFLAGS += -Wall -Werror
> CFLAGS += -Wno-format-zero-length
> CFLAGS += -Wdeclaration-after-statement
> CFLAGS += -Wpointer-arith
> CFLAGS += -Wstrict-prototypes
> CFLAGS += -Wol
"Kyle J. McKay" writes:
> I ran into this problem. It seems like (at least on older Mac OS X)
> that the root directory is created like so:
>
>drwxrwxr-t 39 root admin /
>
> And since the first (and likely only user) on Mac OS X is a member of
> the admin group, the SANITY test fails
Michael J Gruber writes:
> git commit and git status in long format show the diff between HEAD
> and the index when given -v. This allows previewing a commit to be made.
>
> They also list tracked files with unstaged changes, but without a diff.
>
> Introduce '-v -v' which shows the diff between
Alexander Kuleshov writes:
> Signed-off-by: 0xAX
H.
> @@ -50,12 +50,12 @@ Only print error and warning messages; all other
> output will be suppressed.
Linewrapped?
I could apply it after fixing these hunk header lines, but I'd
prefer not to, as we wouldn't know where _else_ the mail tra
"Jason Pyeron" writes:
> I am setting up a continous integration (CI) system for an open source
> project and I want to allow forking developers to use the system, but
> I do not want anyone to do a clone or fetch from the CI git repo, the
> repo.
>
> Any advice on limiting the https smart protoc
Michael J Gruber writes:
> The first part of the man page is a bit sloppy, but refers to the FORMAT
> section. There, it says that "--pretty" is equivalent to
> "--pretty=tformat:" which is different from "--pretty=format:".
It is indeed sloppy. It says --(pretty|format)= can take
these canned
Alexander Kuleshov writes:
> "cache.h" removed, because it's already included at "builtin.h"
>
> Signed-off-by: Alexander Kuleshov
> ---
Let's put this on hold.
$ git grep --all-match -l -e cache\\.h -e builtin\\.h -- \*.c
shows us there are tons, not just this one.
Also I'd like to see this
Alexander Kuleshov writes:
> Yes, right,
>
> how to do it better? Something like: Documentation,
> init-db/init:.? Or something else?
Subject: init-db documentation: fix synopsis style
>>> +'git init-db' [-q | --quiet] [--bare] [--template=]
s/_/-/ while we are at it, perhaps?
--
To unsubs
Eric Wong writes:
> The following changes since commit 563d4e59bd167fe2eecc5480e3841d878b1c8c2b:
>
> Fifth batch for 2.3 cycle (2015-01-14 12:44:03 -0800)
>
> are available in the git repository at:
>
> git://bogomips.org/git-svn.git for-junio
>
> for you to fetch changes up to a94655dcfedc6b
Jeff King writes:
> One of our rules is that git-compat-util.h (or one of the well-known
> headers which includes, cache.h or builtin.h) is included first in any
> translation unit.
Perhaps by now we can spell it out a bit more explicitly and update
CodingGuidelines. We have:
- The first #inc
Signed-off-by: 0xAX
---
Documentation/git-init.txt | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 369f889..f1f0599 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -9,9 +9,9
* line-wrap 'git init-db' synopsis
* last possible argument '[]' was missed
Signed-off-by: Alexander Kuleshov
---
Documentation/git-init-db.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index 648a6cd..b66d
I am setting up a continous integration (CI) system for an open source project
and I want to allow forking developers to use the system, but I do not want
anyone to do a clone or fetch from the CI git repo, the repo.
Any advice on limiting the https smart protocol to push only, blocking clone
a
On Thu, Jan 15, 2015 at 12:08 PM, Alexander Kuleshov
wrote:
> Yes, right,
Etiquette on this list is to avoid top-posting [1].
> how to do it better? Something like: Documentation,
> init-db/init:.? Or something else?
Simplest would be to split it into two patches: one for
git-init-db.txt an
Maybe need to add comments for print_string_list, for preventing
patches like this?
2015-01-15 23:56 GMT+06:00 Junio C Hamano :
> On Thu, Jan 15, 2015 at 9:42 AM, Alexander Kuleshov
> wrote:
>> print_string_list routine has no callers anywhere.
>>
>> Signed-off-by: Alexander Kuleshov
>
> http://
Jeff King writes:
> On Wed, Jan 14, 2015 at 03:40:45PM -0800, Junio C Hamano wrote:
>
>> Here are a handful of patches to make symbols that are only used
>> within a .c file as static. This is not the kind of changes we
>> would want to do in the pre-release freeze period, and it is just
>> for
Michael J Gruber writes:
> If an --author argument is specified but does not contain a '>' then git tries
> to find the argument within the exiting authors; and gives the error
> message "No existing author found with '%s'" if there is no match.
>
> This is confusing for users who try to specify
print_string_list routine has no callers anywhere.
Signed-off-by: Alexander Kuleshov
---
Documentation/technical/api-string-list.txt | 6 --
string-list.c | 10 --
string-list.h | 1 -
3 files changed, 17 deletions(-)
dif
Signed-off-by: Alexander Kuleshov
---
git-stash.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-stash.sh b/git-stash.sh
index 6e30380..dc101f9 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -7,7 +7,7 @@ USAGE="list []
or: $dashless drop [-q|--quiet] []
or: $das
Michael J Gruber writes:
> Unfortunately, "--format" seems to be parsed as ("--pretty" and
> therefore?) "--pretty=tformat:" which I consider a bug.
"tformat:" was introduced to fix "format:, because many people found
the latter hard to use, probably because most of the time they
wanted to use t
Translate 13 new messages came from git.pot update in
beb691f (l10n: git.pot: v2.3.0 round 1 (13 new, 11 removed)).
Signed-off-by: Ralf Thielow
---
po/de.po | 39 +++
1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/po/de.po b/po/de.po
index 2fa
Yes, right,
how to do it better? Something like: Documentation,
init-db/init:.? Or something else?
Thank you
2015-01-15 22:50 GMT+06:00 Eric Sunshine :
> On Thu, Jan 15, 2015 at 5:31 AM, Alexander Kuleshov
> wrote:
>> Subject: Documentation/init-db.txt: minor style and synopsys fixes
>
> Su
On Thu, Jan 15, 2015 at 5:31 AM, Alexander Kuleshov
wrote:
> Subject: Documentation/init-db.txt: minor style and synopsys fixes
Subject is incorrect now that you're modifying git-init-db.txt and git-init.txt.
> This patch constists of two minor changes:
>
> * line-wrap 'git init-db' synopsis
>
>
Francesc Zacarias schrieb am 15.01.2015 um 14:55:
> Hi!
>
> I noticed that git produces differing output for
> "git show --pretty:format show" and "git show --format", even though
> the man page says that both are equivalent.
> "git show --format" always appends an empty line at the end. The only
git commit and git status in long format show the diff between HEAD
and the index when given -v. This allows previewing a commit to be made.
They also list tracked files with unstaged changes, but without a diff.
Introduce '-v -v' which shows the diff between the index and the
worktree in additio
Jeff King schrieb am 15.01.2015 um 15:31:
> On Thu, Jan 15, 2015 at 03:23:08PM +0100, Michael J Gruber wrote:
>
>> If an --author argument is specified but does not contain a '>' then git
>> tries
>> to find the argument within the exiting authors; and gives the error
>> message "No existing auth
On Thu, Jan 15, 2015 at 03:23:08PM +0100, Michael J Gruber wrote:
> If an --author argument is specified but does not contain a '>' then git tries
> to find the argument within the exiting authors; and gives the error
> message "No existing author found with '%s'" if there is no match.
>
> This i
Michael J Gruber schrieb am 15.01.2015 um 15:23:
> If an --author argument is specified but does not contain a '>' then git tries
> to find the argument within the exiting authors; and gives the error
> message "No existing author found with '%s'" if there is no match.
Oh well, I'm bracing already
If an --author argument is specified but does not contain a '>' then git tries
to find the argument within the exiting authors; and gives the error
message "No existing author found with '%s'" if there is no match.
This is confusing for users who try to specify a valid complete author
name.
Renam
Jeff King schrieb am 14.01.2015 um 13:09:
> On Tue, Jan 13, 2015 at 12:24:18PM +0100, Michael J Gruber wrote:
>
>> Gunnar Wagner schrieb am 13.01.2015 um 09:15:
>>> I got APGL licensed code from someone else and want to post it on my
>>> github (without taking credit for the work)
>>>
>>> tried
Hi!
I noticed that git produces differing output for
"git show --pretty:format show" and "git show --format", even though
the man page says that both are equivalent.
"git show --format" always appends an empty line at the end. The only
way I've found to get rid of that empty line in --format is by
Eric Wong writes:
> How big is the parent process which forks the git commands? On Linux at
> least, fork() performance is negatively impacted by parent process
> memory size.
Huh. I thought with the advent of demand-paging, at the very least with
copy-on-write, this was supposed to be sort of
"cache.h" removed, because it's already included at "builtin.h"
Signed-off-by: Alexander Kuleshov
---
builtin/init-db.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 280454a..8edef87 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -3,7 +
On Wed, Jan 14, 2015 at 9:30 PM, Eric Wong wrote:
> Niluge kiwi wrote:
>> Hi all,
>>
>> In magit (http://magit.github.io/), a popular git frontend within
>> emacs, there is a git-svn frontend. With a recent refactoring, it was
>> discovered that git-svn metadata commands (like "git-svn info") ar
On Thu, Jan 15, 2015 at 04:13:00PM +0600, Alexander Kuleshov wrote:
> yes right, missed system_path usage. But it's strange, code still
> compiles successfully without exec_cmd.h.
Sort of. With your patch I get:
builtin/init-db.c: In function ‘copy_templates’:
builtin/init-db.c:127:3: warning: i
This patch constists of two minor changes:
* line-wrap 'git init-db' synopsis
* last possible argument '[]' was missed
Signed-off-by: Alexander Kuleshov
---
Documentation/git-init-db.txt | 5 +++--
Documentation/git-init.txt| 6 +++---
2 files changed, 6 insertions(+), 5 deletions(-)
diff
Baby steps, pushed to my master on git://bogomips.org/git-svn
--8<
Subject: [PATCH] git-svn: lazy load some modules
We can delay loading some modules until we need them for uncommon
code paths. For example, persistent memoization is not often
n
Hello Junio,
yes right, missed system_path usage. But it's strange, code still
compiles successfully without exec_cmd.h.
--
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-
On Jan 15, 2015, at 00:26, Kyle J. McKay wrote:
On Jan 14, 2015, at 11:09, Michael Blume wrote:
On Wed, Jan 14, 2015 at 10:58 AM, Michael Blume
wrote:
On Wed, Jan 14, 2015 at 10:48 AM, Michael Blume > wrote:
On Wed, Jan 14, 2015 at 10:44 AM, Michael Blume > wrote:
On Wed, Jan 14, 2015 at 10:4
The following changes since commit 563d4e59bd167fe2eecc5480e3841d878b1c8c2b:
Fifth batch for 2.3 cycle (2015-01-14 12:44:03 -0800)
are available in the git repository at:
git://bogomips.org/git-svn.git for-junio
for you to fetch changes up to a94655dcfedc6b266ba32a3d32b0d52a1ce6a928:
git
On Thu, Jan 15, 2015 at 6:43 PM, Andreas Krey wrote:
> On Thu, 15 Jan 2015 18:05:46 +, Bryan Turner wrote:
> ...
>
> They do. So it seems it was forked once upon a time, but...
>
> /opt/apps/atlassian/stash-data/shared/data/repositories $ grep ''
> */objects/info/alternates
> 158/objects/info
On Jan 14, 2015, at 11:09, Michael Blume wrote:
On Wed, Jan 14, 2015 at 10:58 AM, Michael Blume
wrote:
On Wed, Jan 14, 2015 at 10:48 AM, Michael Blume
wrote:
On Wed, Jan 14, 2015 at 10:44 AM, Michael Blume > wrote:
On Wed, Jan 14, 2015 at 10:40 AM, Michael Blume > wrote:
On Wed, Jan 14, 2015
71 matches
Mail list logo
