From: Sérgio Basto ser...@serjux.com
On Sáb, 2014-12-06 at 15:04 +, Philip Oakley wrote:
Many users misunderstand the --assume-unchanged contract, believing
it means Git won't look at the flagged file.
Be explicit that the --assume-unchanged contract is by the user that
they will NOT
From: Philip Oakley philipoak...@iee.org
From: Sérgio Basto ser...@serjux.com
On Sáb, 2014-12-06 at 15:04 +, Philip Oakley wrote:
Many users misunderstand the --assume-unchanged contract, believing
it means Git won't look at the flagged file.
[...]
retrospect, so my patch seeks to clarify
Sérgio Basto schrieb am 09.12.2014 um 04:43:
On Sáb, 2014-12-06 at 15:04 +, Philip Oakley wrote:
Many users misunderstand the --assume-unchanged contract, believing
it means Git won't look at the flagged file.
Be explicit that the --assume-unchanged contract is by the user that
they
On Mon, Dec 08, 2014 at 05:38:59PM +0100, Johannes Schindelin wrote:
At least on this developer's MacOSX (Snow Leopard, gcc-4.2.1), GCC prints
a warning that 'hash' may be used uninitialized when compiling
test-hashmap that 'hash' may be used uninitialized (but GCC 4.6.3 on this
developer's
Hi Peff,
On Tue, 9 Dec 2014, Jeff King wrote:
On Mon, Dec 08, 2014 at 05:38:59PM +0100, Johannes Schindelin wrote:
At least on this developer's MacOSX (Snow Leopard, gcc-4.2.1), GCC prints
a warning that 'hash' may be used uninitialized when compiling
test-hashmap that 'hash' may be
On Mon, Dec 08, 2014 at 09:05:07PM +0700, Nguyễn Thái Ngọc Duy wrote:
If the user enables untracked cache, then
- move worktree to an unsupported filesystem
- or simply upgrade OS
- or move the whole (portable) disk from one machine to another
- or access a shared fs from another
git-update-index --assume-unchanged was never meant to ignore changes
to tracked files (only to spare some stats). So do not suggest it
as a means to achieve that.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Documentation/gitignore.txt | 4
1 file changed, 4 deletions(-)
Quite a few users seem to get confused about which commands to use
as the main git interface. While `git --help' gives an overview,
users seem to discover commands from the man page which does not
tell them to stay away from plumbing commands first.
Introduce a category section in each man page
My name is Gatan Magsino, I work with Mediterranean Bank in Malta. Can i trust
you with a business worth $8.3M USD? Please reply ONLY to my private email:
mga...@rogers.commailto:mga...@rogers.com for more information
--
To unsubscribe from this list: send the line unsubscribe git in
the
I wondered if I could mark some untracked files but 'precious' using
git attributes. Then I worried that the majority of people who don't
care about this precious thing will have to pay for git_check_attr()
just because some people want it.
Which led me to try to optimize the attr machinery so
Keep track of all recognized macros in the new maybe_macro field.
This this field is true, it _may_ be a macro (depending on what's in
the current attr stack). But if the field is false, it's definitely
not a macro, no need to go through the whole attr stack in
macroexpand_one() to search for one.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
attr.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/attr.c b/attr.c
index 583d36a..def09c7 100644
--- a/attr.c
+++ b/attr.c
@@ -705,14 +705,9 @@ static int macroexpand_one(int attr_nr, int
This name attr_nr is used elsewhere as local variable, shadowing the
global one. Let's rename the global one into something else to avoid
accidents due to shadow in future.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
attr.c | 14 +++---
1 file changed, 7 insertions(+), 7
If we have never seen attr 'X' in any .gitattributes file we have
examined so far, we can be sure that 'X' is not defined. So no need to
go over all the attr stack to look for attr 'X'. This is the purpose
behind this new field maybe_real.
This optimization breaks down if macros are involved
On Mon, Dec 08, 2014 at 05:22:23PM +0100, Martin Scherer wrote:
# invoke bfg --delete-folders something multiple times with different
pattern.
# try to cleanup
git gc --aggressive --prune=now # big blobs still in history
git fsck # no results
git fsck --full --unreachable --dangling #
On 9 December 2014 at 14:14, Jeff King p...@peff.net wrote:
On Mon, Dec 08, 2014 at 05:22:23PM +0100, Martin Scherer wrote:
# invoke bfg --delete-folders something multiple times with different
pattern.
# try to cleanup
git gc --aggressive --prune=now # big blobs still in history
git fsck
You have a cash grant of $2,000.000.00 USD from Mrs Patricia Chandler, contact
her on: patriciachandlerca...@gmail.com
--
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
Junio C Hamano wrote:
So I am OK to special case fast-import and single it out as a
notable implementation technology, which is what your patch does.
More importantly, helpers implementing the import or export
capability are indicating that they grok the fast-import format. What
they use
---
Documentation/git-am.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 9adce37..d4ef16c 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -83,7 +83,6 @@ default. You can use `--no-utf8` to override this.
When we send out pkt-lines with refnames, we use a static
1000-byte buffer. This means that the maximum size of a ref
over the git protocol is around 950 bytes (the exact size
depends on the protocol line being written, but figure on a sha1
plus some boilerplate).
This is enough for any sane
On Tue, Dec 09, 2014 at 12:49:58PM -0500, Jeff King wrote:
Another option would be to use a static strbuf. Then we're only wasting
heap, and even then only as much as we need (we'd still manually cap it
at LARGE_PACKET_MAX since that's what the protocol dictates). This would
also make
Jeff King p...@peff.net writes:
But the one place I do not agree is:
I think sequence.editor and core.editor are better because:
- they use the same syntax as the config variables, so they are easier
to remember and to discover, and
I really don't like using core.editor here, because it
Signed-off-by: Ronald Wampler rdwamp...@gmail.com
---
I forgot to add the sign-off in the previous patch. Sorry for the additional
noise.
Documentation/git-am.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 9adce37..d4ef16c 100644
Jeff King p...@peff.net writes:
On Fri, Dec 05, 2014 at 10:00:05AM -0800, Junio C Hamano wrote:
I am more worried about variable length part pushing the information
that is given later out to the right, e.g. error: missing file '%s'
prevents us from doing X. Chomping to [1024] is not a good
Michael Haggerty mhag...@alum.mit.edu writes:
This isn't documented very well. I thought I saw a comment somewhere in
the code that stated it explicitly, but I can't find it now. In any
case, my understanding of the locking protocol for reflogs is:
The reflog for $refname, which is
On Tue, Dec 09, 2014 at 10:43:52AM -0800, Junio C Hamano wrote:
Unless we can do something clever with a set of global error strbufs or
something (i.e., that expand as needed, but the caller does not have to
free themselves, as they will get recycled eventually). That has its own
corner
Hi,
i am runningthis command
git filter-branch --env-filter 'export
GIT_COMMITTER_EMAIL=$GIT_AUTHOR_EMAIL
GIT_COMMITTER_NAME=$GIT_AUTHOR_NAME
GIT_COMMITTER_DATE=$GIT_AUTHOR_DATE' --prune-empty --tag-name-filter
cat -- --all
in a repository which i copied to /dev/shm before. According to
On Tue, Dec 09, 2014 at 10:47:24AM -0800, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
This isn't documented very well. I thought I saw a comment somewhere in
the code that stated it explicitly, but I can't find it now. In any
case, my understanding of the locking
On Tue, Dec 09, 2014 at 07:52:33PM +0100, Henning Moll wrote:
i am runningthis command
git filter-branch --env-filter 'export
GIT_COMMITTER_EMAIL=$GIT_AUTHOR_EMAIL
GIT_COMMITTER_NAME=$GIT_AUTHOR_NAME GIT_COMMITTER_DATE=$GIT_AUTHOR_DATE'
--prune-empty --tag-name-filter cat -- --all
in a
Onno Kortmann o...@gmx.net writes:
Hi,
These lines above --- will become the only log message text, which
is probably not what you intended. Use -- 8 -- marker instead
(that is a perforation line with a pair of scissors on it)?
Thanks, hopefully fixed below.
+commitcount=$(git stripspace
Jonathan Nieder jrnie...@gmail.com writes:
+/*
+ * Clears the string list, so it has zero items. All former items are freed.
+ * If free_util is true, all util pointers are also freed.
+ */
void string_list_clear(struct string_list *list, int free_util);
The api doc says
Free a
Jeff King p...@peff.net writes:
Also, I forgot to mention: if we consistently put the API docs into the
header files and extracted it automatically into standalone documents,
we would not need to have two places.
This is something I've been meaning to look at for a long time, but it
never
Michael Blume blume.m...@gmail.com writes:
Failures start from
commit d2384abff7a6181fd7b9a51af7e780aa21e5cb8d (refs/bisect/bad)
Author: Luis Henriques hen...@camandro.org
Date: Thu Dec 4 19:11:30 2014 +
test/send-email: --[no-]xmailer tests
Add tests for the --[no-]xmailer
On Tue, Dec 9, 2014 at 11:37 AM, Junio C Hamano gits...@pobox.com wrote:
Perhaps the API doc that currently says Free is the only thing
that needs fixing? And perhaps add See $doc at the beginning of
the header and remove duplicated comments we already have in the
file?
The reason I wrote
Hi Git devs,
I have a feature request for git gui:
While browsing the changes, it is very easy to add (or remove) lines or
hunks for commit via the context menu. I would like to revert the
changes of a line or a hunk in a similar way. I have often white-space
or formatting changes I don't
Am 09.12.2014 um 18:49 schrieb Jeff King:
+test_expect_success 'create repo with absurdly long refname' '
+ ref240=$_z40/$_z40/$_z40/$_z40/$_z40/$_z40
+ ref1440=$ref240/$ref240/$ref240/$ref240/$ref240/$ref240
+ git init long
+ (
+ cd long
+
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
+/*
+ * Clears the string list, so it has zero items. All former items are
freed.
+ * If free_util is true, all util pointers are also freed.
+ */
void string_list_clear(struct string_list *list, int free_util);
The api
On Tue, Dec 09, 2014 at 08:58:26PM +0100, Johannes Sixt wrote:
Am 09.12.2014 um 18:49 schrieb Jeff King:
+test_expect_success 'create repo with absurdly long refname' '
+ ref240=$_z40/$_z40/$_z40/$_z40/$_z40/$_z40
+ ref1440=$ref240/$ref240/$ref240/$ref240/$ref240/$ref240
+ git
Am 20.11.2014 um 16:17 schrieb Jeff King:
+#define COLOR_FOREGROUND '3'
+#define COLOR_BACKGROUND '4'
This (COLOR_BACKGROUND) causes an ugly redefinition warning on Windows,
because we inherit a definition from a Windows header. How would you
like it fixed? A different name or #undef in front
On Tue, Dec 09, 2014 at 11:41:44AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Also, I forgot to mention: if we consistently put the API docs into the
header files and extracted it automatically into standalone documents,
we would not need to have two places.
This is
Stefan Beller wrote:
On Tue, Dec 9, 2014 at 11:37 AM, Junio C Hamano gits...@pobox.com wrote:
Perhaps the API doc that currently says Free is the only thing
that needs fixing? And perhaps add See $doc at the beginning of
the header and remove duplicated comments we already have in the
file?
Joshua Jensen jjen...@workspacewhiz.com writes:
Jonathan Nieder wrote on 12/8/2014 6:31 PM:
Joshua Jensen wrote:
I think it has been discussed before, but maybe Git needs a
core.casefold in addition to core.ignorecase.)
Would it work for --casefold to be a commandline flag to fast-import,
Am 09.12.2014 um 20:49 schrieb Christoph Grüninger:
While browsing the changes, it is very easy to add (or remove) lines or
hunks for commit via the context menu. I would like to revert the
changes of a line or a hunk in a similar way. I have often white-space
or formatting changes I don't
On Tue, Dec 09, 2014 at 09:14:29PM +0100, Johannes Sixt wrote:
Am 20.11.2014 um 16:17 schrieb Jeff King:
+#define COLOR_FOREGROUND '3'
+#define COLOR_BACKGROUND '4'
This (COLOR_BACKGROUND) causes an ugly redefinition warning on Windows,
because we inherit a definition from a Windows
Jeff King wrote:
On Tue, Dec 09, 2014 at 11:41:44AM -0800, Junio C Hamano wrote:
Yeah, that is a thought.
Some existing documentation pages like allocation-growing may not be
a good match for this strategy, though; cache.h has a lot more than
just alloc-grow, and there needs to be a way to
Hi,
I'm wondering why the built-in patterns (defined in userdiff.c) are not
being applied by default, e.g. what you would normally do in
core.attributesfile via:
*.py diff=python
Wouldn't it make sense to provide certain defaults for attributes, where
Git provides enhanced patterns?
Michael J Gruber g...@drmicha.warpmail.net writes:
Rather than changing git-foo.txt, we could do the substitution magic
from Documentation/Makefile, of course, to keep man pages and command-list
in sync. Although this would keep me from submitting the final series
with 1 patch per file :)
I
Ronald Wampler rdwamp...@gmail.com writes:
---
Documentation/git-am.txt | 1 -
1 file changed, 1 deletion(-)
Of course ;-) git apply does not care about dates as it does not
make the commit.
Thanks.
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 9adce37..d4ef16c
On Tue, Dec 09, 2014 at 12:17:13PM -0800, Jonathan Nieder wrote:
Stefan Beller wrote:
On Tue, Dec 9, 2014 at 11:37 AM, Junio C Hamano gits...@pobox.com wrote:
Perhaps the API doc that currently says Free is the only thing
that needs fixing? And perhaps add See $doc at the beginning of
On Tue, Dec 9, 2014 at 12:27 PM, Jeff King p...@peff.net wrote:
In which case can we simply start migrating api-strbuf.txt into
in-header comments, without worrying about a parsing tool?
-Peff
That would be my preference as well. Putting the API documentation
into the header files.
On Tue, Dec 09, 2014 at 09:18:30PM +0100, Daniel Hahler wrote:
I'm wondering why the built-in patterns (defined in userdiff.c) are not
being applied by default, e.g. what you would normally do in
core.attributesfile via:
*.py diff=python
Wouldn't it make sense to provide certain
On Tue, Dec 09, 2014 at 12:32:15PM -0800, Stefan Beller wrote:
As said above the Documentation/technical would only serve a purpose to
explain very high level concepts. So racy-git.txt or
pack-heuristics.txt will fit
in there very good.
Yeah, I think we would leave anything that isn't api-*,
Am 09.12.2014 um 21:21 schrieb Jeff King:
On Tue, Dec 09, 2014 at 09:14:29PM +0100, Johannes Sixt wrote:
Am 20.11.2014 um 16:17 schrieb Jeff King:
+#define COLOR_FOREGROUND '3'
+#define COLOR_BACKGROUND '4'
This (COLOR_BACKGROUND) causes an ugly redefinition warning on Windows,
because we
On Tue, Dec 9, 2014 at 3:14 PM, Johannes Sixt j...@kdbg.org wrote:
Am 20.11.2014 um 16:17 schrieb Jeff King:
+#define COLOR_FOREGROUND '3'
+#define COLOR_BACKGROUND '4'
This (COLOR_BACKGROUND) causes an ugly redefinition warning on Windows,
because we inherit a definition from a Windows
On Tue, Dec 09, 2014 at 09:52:10PM +0100, Johannes Sixt wrote:
This patch would actually be my personal preference. The comment near
the literal makes it all clear.
Thanks. Here it is ready to be applied.
Junio, this goes on top of the jk/colors topic.
-- 8 --
Subject: [PATCH] parse_color:
On Tuesday, 9 December 2014, Jeff King p...@peff.net wrote:
I actually think filter-branch's refs/original is a bit outdated at
this point. The information is there in the reflogs already, and
dealing with refs/original often causes confusion in my experience. It
could probably use a git
Jeff King wrote:
Elsewhere I mentioned a tool to extract comments and format them. But do
people actually care about the formatting step?
If formatting means convert to a straightforward text document that I
can read through, then I do.
Does
Jeff King p...@peff.net writes:
On Tue, Dec 09, 2014 at 12:49:58PM -0500, Jeff King wrote:
Another option would be to use a static strbuf. Then we're only wasting
heap, and even then only as much as we need (we'd still manually cap it
at LARGE_PACKET_MAX since that's what the protocol
Jonathan Nieder wrote:
Stefan Beller wrote:
On Tue, Dec 9, 2014 at 11:37 AM, Junio C Hamano gits...@pobox.com wrote:
Perhaps the API doc that currently says Free is the only thing
that needs fixing? And perhaps add See $doc at the beginning of
the header and remove duplicated comments we
On Tue, Dec 9, 2014 at 5:04 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Mon, Dec 08, 2014 at 09:05:07PM +0700, Nguyễn Thái Ngọc Duy wrote:
If the user enables untracked cache, then
- move worktree to an unsupported filesystem
- or simply upgrade OS
- or move the whole
On Tue, Dec 09, 2014 at 02:49:50PM -0800, Jonathan Nieder wrote:
Jonathan Nieder wrote:
Stefan Beller wrote:
On Tue, Dec 9, 2014 at 11:37 AM, Junio C Hamano gits...@pobox.com wrote:
Perhaps the API doc that currently says Free is the only thing
that needs fixing? And perhaps add See
Stefan Beller wrote:
On Tue, Dec 09, 2014 at 02:49:50PM -0800, Jonathan Nieder wrote:
And another:
this goes on top or replaces the previous one? (This applies cleanly on
origin/master)
They're independent. :)
[...]
Reported-by: Stefan Beller sbel...@google.com
Signed-off-by: Jonathan
Jonathan Nieder jrnie...@gmail.com writes:
Jeff King wrote:
Elsewhere I mentioned a tool to extract comments and format them. But do
people actually care about the formatting step?
If formatting means convert to a straightforward text document that I
can read through, then I do.
If the
On Tue, Dec 9, 2014 at 8:53 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
Keep track of all recognized macros in the new maybe_macro field.
This this field is true, it _may_ be a macro (depending on what's in
s/This this/If this/
the current attr stack). But if the field is false, it's
On Mon, Dec 8, 2014 at 9:04 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
diff --git a/Documentation/technical/index-format.txt
b/Documentation/technical/index-format.txt
index fe6f316..b97ac8d 100644
---
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This name attr_nr is used elsewhere as local variable, shadowing the
global one. Let's rename the global one into something else to avoid
accidents due to shadow in future.
Even though I do not think I would reject a patch to add this entire
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Keep track of all recognized macros in the new maybe_macro field.
This this field is true, it _may_ be a macro (depending on what's in
the current attr stack). But if the field is false, it's definitely
not a macro, no need to go through the
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
+static void collect_selected_attrs(const char *path, int num,
+struct git_attr_check *check)
+{
+ struct attr_stack *stk;
+ int i, pathlen, rem, dirlen;
+ int basename_offset;
+
+ pathlen =
On Mon, Dec 8, 2014 at 9:04 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
+void write_untracked_extension(struct strbuf *out, struct untracked_cache
*untracked)
+{
+ struct ondisk_untracked_cache *ouc;
+ struct write_data wd;
+ unsigned char varbuf[16];
+ int
I have a repository that's just under 2 GiB in size and contains over
2 refs, with a copy of it on a server. Both sides are using Git
2.1.2. If I push a branch that contains a single commit, it takes about
15 seconds to push. However, if everything is up-to-date, it completes
within 2
Sérgio Basto ser...@serjux.com writes:
Also don't understand why --assumed-untracked shouldn't deal with
changed files instead fallback in the user promises not to change the
file and sometimes works others not.
Also if this is the contract when a file is different from commit,
should
Michael J Gruber wrote:
git-update-index --assume-unchanged was never meant to ignore changes
to tracked files (only to spare some stats). So do not suggest it
as a means to achieve that.
[...]
+++ b/Documentation/gitignore.txt
@@ -138,9 +138,6 @@ NOTES
The purpose of gitignore files is to
On Ter, 2014-12-09 at 16:44 -0800, Junio C Hamano wrote:
Sérgio Basto ser...@serjux.com writes:
Also don't understand why --assumed-untracked shouldn't deal with
changed files instead fallback in the user promises not to change the
file and sometimes works others not.
Also if this
On Tue, Dec 9, 2014 at 2:41 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
On Tue, Dec 09, 2014 at 12:49:58PM -0500, Jeff King wrote:
Another option would be to use a static strbuf. Then we're only wasting
heap, and even then only as much as we need (we'd still
On 12/09/2014 11:53 PM, Duy Nguyen wrote:
On Tue, Dec 9, 2014 at 5:04 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Mon, Dec 08, 2014 at 09:05:07PM +0700, Nguyễn Thái Ngọc Duy wrote:
If the user enables untracked cache, then
- move worktree to an unsupported filesystem
- or
On Tue, Dec 9, 2014 at 4:37 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
I have a repository that's just under 2 GiB in size and contains over
2 refs, with a copy of it on a server. Both sides are using Git
2.1.2. If I push a branch that contains a single commit, it takes
On Tue, Dec 09, 2014 at 10:15:31PM +, Roberto Tyley wrote:
Not that I expect you to want to work on filter-branch. :) But maybe
food for thought for a BFG feature.
I haven't heard much demand for a recover/restore feature on the BFG
(I think by the time people get to the BFG, they're
On Tue, Dec 09, 2014 at 02:41:51PM -0800, Junio C Hamano wrote:
Another option would be to use a static strbuf. Then we're only wasting
heap, and even then only as much as we need (we'd still manually cap it
at LARGE_PACKET_MAX since that's what the protocol dictates). This would
also
On Tue, Dec 9, 2014 at 9:21 PM, Johannes Sixt j...@kdbg.org wrote:
Am 09.12.2014 um 20:49 schrieb Christoph Grüninger:
While browsing the changes, it is very easy to add (or remove) lines or
hunks for commit via the context menu. I would like to revert the
changes of a line or a hunk in a
Christoph Grüninger f...@grueninger.de wrote:
While browsing the changes, it is very easy to add (or remove) lines or
hunks for commit via the context menu. I would like to revert the
changes of a line or a hunk in a similar way. I have often white-space
or formatting changes I don't want to
80 matches
Mail list logo
