Hi Josh,
On Tue, 17 May 2016, Josh McCullough wrote:
> TL;DR: Git should ignore files if they are in `.gitignore`, regardless
> of whether or not the file has changed (or been removed).
This would break at least one of my setups, where I was too lazy to add
negative rules to .gitignore.
I imagi
ping?
On Thu, May 5, 2016 at 8:22 PM, Junio C Hamano wrote:
> Pat, we haven't heard from you for a long time. Are you still
> around and interested in helping us by maintaining git-gui?
>
> Otherwise we may have to start recruiting a volunteer or two to take
> this over.
>
> Thanks.
>
> Orgad Sh
seq is not available everywhere.
Signed-off-by: Johannes Sixt
---
t/t6044-merge-unrelated-index-changes.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t6044-merge-unrelated-index-changes.sh
b/t/t6044-merge-unrelated-index-changes.sh
index 20a3ffe..0102348 100755
--
Felipe Contreras writes:
> On Tue, May 17, 2016 at 10:59 PM, Junio C Hamano wrote:
>> On Tue, May 17, 2016 at 8:31 PM, Felipe Contreras
>> wrote:
>>> On Tue, May 17, 2016 at 5:22 PM, Junio C Hamano wrote:
>
- Even if we did not read from any existing marks file, if we are
given e
On 05/17/2016 08:58 PM, Junio C Hamano wrote:
tbo...@web.de writes:
#define HASH_WRITE_OBJECT 1
#define HASH_FORMAT_CHECK 2
+#define HASH_CE_HAS_SHA1 4
How does one pronounce the words in this constant? Does it make a
listener understand what this constant means?
How about
HASH_USE_SHA
On Tue, May 17, 2016 at 10:59 PM, Junio C Hamano wrote:
> On Tue, May 17, 2016 at 8:31 PM, Felipe Contreras
> wrote:
>> On Tue, May 17, 2016 at 5:22 PM, Junio C Hamano wrote:
>>> - Even if we did not read from any existing marks file, if we are
>>>given export_marks_file that names an exis
On Tue, May 17, 2016 at 8:31 PM, Felipe Contreras
wrote:
> On Tue, May 17, 2016 at 5:22 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>> - Even if we are reading from somewhere, export_marks_file can
>>point at a completely new file that is different from
>>import_marks file,
On Tue, May 17, 2016 at 7:06 PM, SZEDER Gábor wrote:
> Quoting Junio C Hamano :
>> Jeff King writes:
>>> On Tue, May 17, 2016 at 04:48:33PM -0400, Eric Sunshine wrote:
On Tue, May 17, 2016 at 4:37 PM, Junio C Hamano
wrote:
> Eric Sunshine writes:
>> + git $
On Tue, May 17, 2016 at 5:22 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Certain lines of the marks file might be corrupted (or the objects
>> missing due to a garbage collection), but that's no reason to truncate
>> the file and essentially destroy the rest of it.
>
> Hmm, so the i
TL;DR: Git should ignore files if they are in `.gitignore`, regardless
of whether or not the file has changed (or been removed).
Use Case
An initial set of "local" config files are committed to a repo. Each
developer will pull down this set of files, but changes will be
auto-ignored unless the fi
On Tue, May 17, 2016 at 08:40:08PM -0400, Jeff King wrote:
> So we need some way to tell strftime "...and by the way, this is the
> timezone for the value we are currently feeding you." There isn't a slot
> in "struct tm" for that, but I think maybe you can hack around it by
> setting the global "
On Tue, May 17, 2016 at 07:25:31PM +0200, Michael Heerdegen wrote:
> Michael Heerdegen writes:
>
> > the command
> >
> >git log --pretty=format:%ad --date=format:%s
> >
> > displays wrong unixtime values; apparently how much the printed value
> > differs from the expected value depends on th
Quoting Junio C Hamano :
Jeff King writes:
On Tue, May 17, 2016 at 04:48:33PM -0400, Eric Sunshine wrote:
On Tue, May 17, 2016 at 4:37 PM, Junio C Hamano wrote:
Eric Sunshine writes:
+ git ${dir:+-C "$dir"} rev-parse --$o >actual &&
This is kosher POSIX, but I vag
Jeff King writes:
> On Tue, May 17, 2016 at 04:48:33PM -0400, Eric Sunshine wrote:
>
>> On Tue, May 17, 2016 at 4:37 PM, Junio C Hamano wrote:
>> > Eric Sunshine writes:
>> >> + git ${dir:+-C "$dir"} rev-parse --$o >actual &&
>> >
>> > This is kosher POSIX, but I vaguely rec
On Tue, May 17, 2016 at 5:52 PM, Jeff King wrote:
> On Tue, May 17, 2016 at 04:48:33PM -0400, Eric Sunshine wrote:
>> On Tue, May 17, 2016 at 4:37 PM, Junio C Hamano wrote:
>> > Eric Sunshine writes:
>> >> + git ${dir:+-C "$dir"} rev-parse --$o >actual &&
>> >
>> > This is ko
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 ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The 'master' branch now has 390 no
On Wed, 2016-05-04 at 13:13 -0700, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > Later on when we introduce the version 2 transport protocol, the
> > capabilities will not be transported in one lone string but each
>
> s/lone/long/, I think.
>
> > capability will be carried in its own pkt
Felipe Contreras writes:
> Certain lines of the marks file might be corrupted (or the objects
> missing due to a garbage collection), but that's no reason to truncate
> the file and essentially destroy the rest of it.
Hmm, so the issue is:
- we use die_nicely() that calls dump_marks() after wr
On Tue, May 17, 2016 at 10:02:22PM +0200, Johannes Sixt wrote:
> > Interesting. It replicates out of the box for me.
>
> "Out of the box" are the magic words. I usually compile with -O0, which
> doesn't trigger the valgrind report.
Heh, I meant that Noam's test worked out of the box. I also buil
On Tue, May 17, 2016 at 04:48:33PM -0400, Eric Sunshine wrote:
> On Tue, May 17, 2016 at 4:37 PM, Junio C Hamano wrote:
> > Eric Sunshine writes:
> >> + git ${dir:+-C "$dir"} rev-parse --$o >actual &&
> >
> > This is kosher POSIX, but I vaguely recall some shells had trouble
Certain lines of the marks file might be corrupted (or the objects
missing due to a garbage collection), but that's no reason to truncate
the file and essentially destroy the rest of it.
Ideally missing objects should not cause a crash, we could just skip
them, but that's another patch.
Signed-of
Junio C Hamano writes:
> Given that one of the two expected callers, namely, "check-attr" and
> Stefan's pathspec label magic, of this "alloc and then append" side
> of the API wants to have an access to git_attr(name), I think
> the function signature for this one should be updated to take not
>
On Tue, May 17, 2016 at 4:37 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> + git ${dir:+-C "$dir"} rev-parse --$o >actual &&
>
> This is kosher POSIX, but I vaguely recall some shells had trouble
> with the SP between -C and "$dir" in the past. Let's see if anybody
> s
Eric Sunshine writes:
> + git ${dir:+-C "$dir"} rev-parse --$o >actual &&
This is kosher POSIX, but I vaguely recall some shells had trouble
with the SP between -C and "$dir" in the past. Let's see if anybody
screams; hopefully I am misremembering or buggy shells died out.
Karthik Nayak writes:
> Sorry for that.
> The only reason I haven't based it on 'master' is because it doesn't contain
> 'f307218'.
>
> ➔ git branch --contains=f307218
> next
> ref-filter
It is not clear from the above what your local ref-filter contains
beyond 'master', so it is not very us
Stefan Beller writes:
> On Mon, May 16, 2016 at 10:03 PM, Junio C Hamano wrote:
>> When matching (i.e. the match_attrs() function), you would instead
>> do
>>
>> path = xmemdupz(name, namelen);
>> git_check_attr(path, item->attr_check);
>>
>> to grab values for only attributes th
Am 17.05.2016 um 21:45 schrieb Jeff King:
On Tue, May 17, 2016 at 09:07:33PM +0200, Johannes Sixt wrote:
Am 15.05.2016 um 15:05 schrieb Noam Postavsky:
With a certain topology involving an octopus merge, git log --graph
--oneline --all --color=never produces output which includes some ANSI
esc
Karthik Nayak writes:
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 2ecde53..141168d 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -361,39 +361,6 @@ static void add_verbose_info(struct strbuf *out, struct
> ref_array_item *item,
> strbuf_release(&subject);
> }
On Tue, May 17, 2016 at 03:51:37PM -0400, Jeff King wrote:
> On Tue, May 17, 2016 at 03:45:34PM -0400, Jeff King wrote:
>
> > Note that we set up f90, fa0, and fb0, but then pass fc0 into
> > strbuf_write_column (and it has bogus color values). It looks like we're
> > reading one past the end of
On Tue, May 17, 2016 at 03:45:34PM -0400, Jeff King wrote:
> Note that we set up f90, fa0, and fb0, but then pass fc0 into
> strbuf_write_column (and it has bogus color values). It looks like we're
> reading one past the end of our array, but I haven't figured out where
> or why.
Looking at the v
On Tue, May 17, 2016 at 09:07:33PM +0200, Johannes Sixt wrote:
> Am 15.05.2016 um 15:05 schrieb Noam Postavsky:
> > With a certain topology involving an octopus merge, git log --graph
> > --oneline --all --color=never produces output which includes some ANSI
> > escape code coloring. Attached is a
This is a re-roll of [1] which modernizes t1500 by updating tests to set
up their own needed state rather than relying upon manipulation of
global state.
Changes since v1[1]:
In v1 patch 1/6, which makes test_rev_parse() for-loop driven, the loop
control has been moved to the top of the loop for
Ideally, each test should be responsible for setting up state it needs
rather than relying upon transient global state. Toward this end, teach
test_rev_parse() to accept a "-C " option to allow callers to
instruct it explicitly in which directory its tests should be run. Take
advantage of this new
Tests run by test_rev_parse() are nearly identical; each invokes
git-rev-parse with a single option and compares the result against an
expected value. Such duplication makes it onerous to extend the tests
since any change needs to be repeated in each test. Avoid the
duplication by parameterizing th
Ideally, each test should be responsible for setting up state it needs
rather than relying upon transient global state. Toward this end, teach
test_rev_parse() to accept a "-b " option to allow callers to set
"core.bare" explicitly or undefine it. Take advantage of this new option
to avoid setting
The final batch of git-rev-parse tests work against a non-local object
database named repo.git. This is done by renaming .git to repo.git and
pointing GIT_DIR at it, but the name is never restored to .git at the
end of the script, which can be problematic for tests added in the
future. Be more frie
Ideally, each test should be responsible for setting up state it needs
rather than relying upon transient global state. Toward this end, teach
test_rev_parse() to accept a "-g " option to allow callers to
specify the value of the GIT_DIR environment variable explicitly. Take
advantage of this new o
On Mon, May 16, 2016 at 10:03 PM, Junio C Hamano wrote:
> When matching (i.e. the match_attrs() function), you would instead
> do
>
> path = xmemdupz(name, namelen);
> git_check_attr(path, item->attr_check);
>
> to grab values for only attributes that matter to you, instead of
> ca
Am 15.05.2016 um 15:05 schrieb Noam Postavsky:
With a certain topology involving an octopus merge, git log --graph
--oneline --all --color=never produces output which includes some ANSI
escape code coloring. Attached is a script to reproduce the problem
(creates a git repository in subdir log-for
On Tue, May 17, 2016 at 11:22 PM, Junio C Hamano wrote:
> Karthik Nayak writes:
>
>> Hello, sorry for the confusion, it's built on top of 'next' which contains
>> f307218 (t6302: simplify non-gpg cases). The merge conflict is due to the
>> commit made by you 1cca17df (Documentation: fix linkgit r
tbo...@web.de writes:
> #define HASH_WRITE_OBJECT 1
> #define HASH_FORMAT_CHECK 2
> +#define HASH_CE_HAS_SHA1 4
How does one pronounce the words in this constant? Does it make a
listener understand what this constant means?
/*
* We need a comment around here to say what these two
* parame
tbo...@web.de writes:
> From: Torsten Bögershausen
>
> t6038 uses different code, depending if NATIVE_CRLF is set ot not.
> When the native line endings are LF, merge.renormalize is not tested very
> well.
> Change the test to always use CRLF by setting core.eol=crlf.
> ---
> Broke the 10/10 ser
Stefan Beller writes:
> I'll just drop support for values
> in the first series.
I do not think an exact string match to support :(attr:eol=crlf) is
so bad. The "crazy stuff" aka over-engineering is when it goes
beyond that, e.g. 'eol is set to one of these values"
--
To unsubscribe from this l
Junio C Hamano wrote:
> Joey Hess writes:
>
> > Appears to be a bug in git. Seems that it's assuming GIT_INDEX_FILE is
> > relative to the top of the worktree and not to the CWD.
>
> I think that has always been the case. You can always specify it as
> relative to the top. Of course, you can u
On Tue, May 17, 2016 at 11:16 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> So as a developer I wish we would close all leaks that are non-concerning.
>
> Valgrind suppression (and if you use other tools, suppression for
> them) sounds like the way to go, I would think.
>
> Reducing fals
Stefan Beller writes:
> So as a developer I wish we would close all leaks that are non-concerning.
Valgrind suppression (and if you use other tools, suppression for
them) sounds like the way to go, I would think.
Reducing false positive is a good goal; it helps to highlight the
real problems.
On Tue, May 17, 2016 at 11:05 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> I am not talking about crazy stuff here, but consider our own
>> .gitattributes file:
>>
>> * whitespace=!indent,trail,space
>> *.[ch] whitespace=indent,trail,space
>> *.sh whitespace=indent,trail,spa
As stash does not know how to deal with submodules,
it should not try to save/restore their states
as it leads to redundant merge conflicts.
Added test checks if 'stash pop' does not trigger merge conflicts
in submodules.
Signed-off-by: Vasily Titskiy
---
git-stash.sh | 2 +-
t/t3903-stash
Stefan Beller writes:
> I am not talking about crazy stuff here, but consider our own
> .gitattributes file:
>
> * whitespace=!indent,trail,space
> *.[ch] whitespace=indent,trail,space
> *.sh whitespace=indent,trail,space
>
> Now I want to search for
>
> "the whitespace attribute
On Mon, May 16, 2016 at 8:41 PM, Eric Sunshine wrote:
> On Mon, May 16, 2016 at 11:22 PM, Stefan Beller wrote:
>> When using automated tools to find memory leaks, it is hard to distinguish
>> between actual leaks and intentional non-cleanups at the end of the program,
>> such that the actual leak
Karthik Nayak writes:
> Hello, sorry for the confusion, it's built on top of 'next' which contains
> f307218 (t6302: simplify non-gpg cases). The merge conflict is due to the
> commit made by you 1cca17df (Documentation: fix linkgit references).
That is not "confusion", but an "incorrect piece o
On Tue, May 17, 2016 at 10:34 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> Then while parsing ":(attr:VAR1=VAL1 -VAR2 VAR3...)path/to/dir/",
>>
>> This syntax is not pleasant to parse IMHO as it is not clear if the token
>> after white space (-VAR2 here) is another attribute or the nex
Joey Hess writes:
> Appears to be a bug in git. Seems that it's assuming GIT_INDEX_FILE is
> relative to the top of the worktree and not to the CWD.
I think that has always been the case. You can always specify it as
relative to the top. Of course, you can use absolute.
--
To unsubscribe from
Stefan Beller writes:
>> Then while parsing ":(attr:VAR1=VAL1 -VAR2 VAR3...)path/to/dir/",
>
> This syntax is not pleasant to parse IMHO as it is not clear if the token
> after white space (-VAR2 here) is another attribute or the next part of
> the list of VAR1, ...
Remove the ambiguity by decla
Michael Heerdegen writes:
> the command
>
>git log --pretty=format:%ad --date=format:%s
>
> displays wrong unixtime values; apparently how much the printed value
> differs from the expected value depends on the system's time zone and
> whether daylight savings time is enabled or not.
Two mor
joey@darkstar:/tmp>git init test
Initialized empty Git repository in /tmp/test/.git/
joey@darkstar:/tmp>cd test
joey@darkstar:/tmp/test>mkdir sub
joey@darkstar:/tmp/test>cd sub
joey@darkstar:/tmp/test/sub>GIT_INDEX_FILE=../.git/otherindex git write-tree
fatal: Unable to create '/tmp/test/../.git/ot
The command does nothing, so it's not needed. There is also a typo in
my patch description, so I'll resend it again with needed changes.
--
Regards,
Vasily Titskiy
On Tue, May 17, 2016 at 1:04 PM, Junio C Hamano wrote:
> Vasily Titskiy writes:
>
>> You're right, it's redundant here. Should
Vasily Titskiy writes:
> You're right, it's redundant here. Should I resubmit the path without this
> line?
I wasn't pointing out that it was not needed. I was only asking
what it was meant to do.
If you now think it shouldn't have been there, that merely means
your code was wrong. It does n
On Mon, May 16, 2016 at 10:03 PM, Junio C Hamano wrote:
>
> int attr_match_nr;
> int attr_match_alloc;
> struct attr_match {
> struct git_attr *attr;
> char *value;
> enum attr_match_mode {
> ...
>
Junio C Hamano writes:
> +struct git_attr_check *git_attr_check_alloc(void)
> +{
> + return xcalloc(1, sizeof(struct git_attr_check));
> +}
> +
> +void git_attr_check_append(struct git_attr_check *check, const char *name)
> +{
> + struct git_attr *attr;
> +
> + if (check->finalized)
>
On Tue, May 17, 2016 at 9:16 AM, Vasily Titskiy wrote:
> As stash does not know how to deal with submodules,
> it should not try to save/restore their states
> as it leads to redundant merge conflicts.
>
> Added test checks if 'stash pop' does not trigger merge conflics
/conflics/conflicts/
> in
On Mon, May 16, 2016 at 9:23 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> + * attr:+val to find value set to true
>> + * attr:-val to find a value set to false
>> + * attr:!val to find a value that is not set
>> + * (i.e. it is neither set as "val", "val=", nor unset as "-val")
>> +
Hi Junio,
You're right, it's redundant here. Should I resubmit the path without this line?
--
Regards,
Vasily Titskiy
On Tue, May 17, 2016 at 12:15 PM, Junio C Hamano wrote:
>
> Vasily Titskiy writes:
>
> > diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
> > index 2142c1f..1be62f3 100755
From: Torsten Bögershausen
To compare a file in working tree with the index, convert_to_git() is used,
the the result is hashed and the hash value compared with ce->sha1.
Deep down would_convert_crlf_at_commit() is invoked, to check if CRLF
are converted or not: When a CRLF had been in the index
From: Torsten Bögershausen
Factor out the retrieval of the sha1 for a given path in
read_blob_data_from_index() into the function get_sha1_from_index().
This will be used in the next commit, when convert.c can do the
analyze for "text=auto" without slurping the whole blob into memory
at once.
A
From: Torsten Bögershausen
Break up the old 10/10 series about CLRF handling into smaller
series. This is a small bugfix, when merge.renormalize is used
with core.autocrlf (and no attributes are set).
Prepare the refactoring to use the streaming interface.
Torsten Bögershausen (2):
read-cache:
Vasily Titskiy writes:
> diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
> index 2142c1f..1be62f3 100755
> --- a/t/t3903-stash.sh
> +++ b/t/t3903-stash.sh
> @@ -731,4 +731,38 @@ test_expect_success 'stash list --cc shows combined
> diff' '
> test_cmp expect actual
> '
>
> +test_expect_
From: Torsten Bögershausen
t6038 uses different code, depending if NATIVE_CRLF is set ot not.
When the native line endings are LF, merge.renormalize is not tested very well.
Change the test to always use CRLF by setting core.eol=crlf.
---
Broke the 10/10 series into smaller pieces, this is the up
As stash does not know how to deal with submodules,
it should not try to save/restore their states
as it leads to redundant merge conflicts.
Added test checks if 'stash pop' does not trigger merge conflics
in submodules.
Signed-off-by: Vasily Titskiy
---
git-stash.sh | 2 +-
t/t3903-stash.
On Tue, May 17, 2016 at 10:07:16AM +0200, Lars Schneider wrote:
> I think that is pretty much the problem. Here is what is happening:
>
> 1. git-p4 imports all changelists for the "main" branch
>
> 2. git-p4 starts to import a second branch and creates a fast-import
> "progress checkpoint"
Eric Sunshine wrote:
> On Mon, May 16, 2016 at 11:22 PM, Stefan Beller wrote:
> > When using automated tools to find memory leaks, it is hard to distinguish
> > between actual leaks and intentional non-cleanups at the end of the program,
> > such that the actual leaks hide in the noise.
>
> Cons
Lars Schneider wrote:
> I am no expert in "fast-import". Does anyone have a few hints how to
> proceed?
I don't know fast-import or the C internals of git well at all,
either. But capturing the exact input to fast-import (using
tee) would be useful for non-p4 users to debug the problem
and would
Stefan Beller writes:
> The end goal of this (unfinished) series is to close all intentional memory
> leaks when enabling the -DFREE_ALL_MEMORY switch. This is just
> demonstrating how the beginning of such a series could look like.
One potential issue with this is: if all developers and the tes
On 14 May 2016 at 19:15, Junio C Hamano wrote:
> Lars Schneider writes:
>
>>> On 13 May 2016, at 18:37, Junio C Hamano wrote:
>>>
>>> Are you saying that "git p4" itself breaks unless fast-import always
>>> writes a new (tiny) packfile? That sounds quite broken, and setting
>>> unpacklimit to 0
> On 14 May 2016, at 20:15, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> On 13 May 2016, at 18:37, Junio C Hamano wrote:
>>>
>>> Are you saying that "git p4" itself breaks unless fast-import always
>>> writes a new (tiny) packfile? That sounds quite broken, and setting
>>> unpackl
On Tue, May 17, 2016 at 3:42 AM, Junio C Hamano wrote:
>
> Karthik Nayak writes:
>
> > This is part of unification of the commands 'git tag -l, git branch -l
> > and git for-each-ref'. This ports over branch.c to use ref-filter's
> > printing options.
> >
> > Initially posted here: $(gmane/279226
76 matches
Mail list logo
