On Fri, Jan 11, 2013 at 06:21:11PM +0700, Nguyễn Thái Ngọc Duy wrote:
> - for (i = 0; i < specs; i++) {
> + for (i = 0; i < pathspec->nr; i++) {
> if (!seen[i])
> - die(_("pathspec '%s' did not match any files"),
> pathspec[i]);
> + die
On Sun, Dec 30, 2012 at 7:05 PM, Jeff King wrote:
> So I was thinking about this, which led to some coding, which led to
> some benchmarking.
I like your way of thinking! May I suggest you take a new year break
first, then "think" about reachability bitmaps ;-) 2013 will be an
exciting year.
> I
On Sat, Dec 29, 2012 at 12:07 PM, Jeff King wrote:
> On Sat, Dec 29, 2012 at 11:34:09AM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> On Sat, Dec 29, 2012 at 7:41 AM, Jeff King wrote:
>> > I wonder if we could do even better, though. For a traversal, we only
>> > need to
On Sat, Dec 29, 2012 at 7:41 AM, Jeff King wrote:
> I wonder if we could do even better, though. For a traversal, we only
> need to look at the commit header. We could potentially do a progressive
> inflate and stop before getting to the commit message (which is the bulk
> of the data, and the par
On Fri, Dec 28, 2012 at 1:24 PM, Junio C Hamano wrote:
>> if (*++p == '*') {
>> const uchar *prev_p = p - 2;
>> while (*++p == '*') {}
>> - if ((prev_p == text || *prev_p == '/') ||
>> +
On Fri, Dec 28, 2012 at 1:24 PM, Junio C Hamano wrote:
>> + while ((t_ch = *text) != '\0' &&
>> +(!(flags & WM_PATHNAME) || t_ch
>> != '/')) {
>
> Why do we look at (flags & WM_PATHMAME) and not "special" here?
Becau
On Tue, Dec 25, 2012 at 2:10 AM, Junio C Hamano wrote:
>> I looked briefly at reflog before writing my previous mail and noticed
>> that when I create a new branch (usually using "git checkout -b branch
>> ref") it does not record the base commit.
>
> Hmph. Perhaps you are referring to something
On Mon, Dec 24, 2012 at 1:27 PM, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky
>> wrote:
>>>> Maybe we should store this information. reflog is a perfect place for
>>>> this, I think. If t
On Mon, Dec 24, 2012 at 1:19 PM, Jeff King wrote:
> On Mon, Dec 24, 2012 at 12:28:45PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> > You want to know "what commit was I at when I typed `git branch
>> > mybranch`"? The problem is git doesn't record this informat
On Mon, Dec 24, 2012 at 12:34 PM, Tomas Carnecky
wrote:
>> Maybe we should store this information. reflog is a perfect place for
>> this, I think. If this information is reliably available, git rebase
>> can be told to "rebase my whole branch" instead of my choosing the
>> base commit for it.
>
>
On Mon, Dec 24, 2012 at 11:09 AM, Seth Robertson wrote:
>
> In message <20121224035825.GA17203@zuhnb712>, Woody Wu writes:
>
> How can I find out what's the staring reference point (a commit number
> or tag name) of a locally created branch? I can use gitk to find out it
> but this met
On Thu, Dec 20, 2012 at 8:55 AM, Nguyen Thai Ngoc Duy wrote:
>> As long as simpler patterns fnmatch() groks (namely, '?', '*', and
>> '[class]' wildcards only) are not slowed down by replacing it with
>> wildmatch(), that is, of course.
>
>
On Thu, Dec 20, 2012 at 1:36 AM, Junio C Hamano wrote:
>> @@ -627,7 +628,7 @@ enum interesting tree_entry_interesting(const struct
>> name_entry *entry,
>> return entry_interesting;
>>
>> if (item->use_wildcard) {
>> -
On Thu, Dec 20, 2012 at 12:24 AM, Junio C Hamano wrote:
> When that happens, we should want to retain the same "do not bother
> to descend into subdirectories that will never match" optimization
> for a pattern like "Doc*tion/**/*.txt". Because of FNM_PATHNAME, we
> can tell if a subdirectory is
On Thu, Dec 20, 2012 at 3:34 AM, Jeff King wrote:
> Part of me thinks this is just gross, because ":(noglob)" is the right
> solution. But after spending a few hours trying it this morning, there
> is a ton of refactoring required to make it work correctly everywhere
> (although we could die() if
On Wed, Dec 19, 2012 at 8:08 PM, Nguyễn Thái Ngọc Duy wrote:
> For those who have not followed, nd/wildmatch brings another
> fnmatch-like implementation which can nearly replace fnmatch.
> System fnmatch() seems to behave differently in some cases. It's
> better to stay away and use one implement
On Mon, Dec 17, 2012 at 6:33 PM, Dinesh Subramani
wrote:
> I am using the below command :
>
> git log --stat --decorate=full --since=
>
> Can you please let me know if the above command will list all the
> commits and would not skip any of the commits due to History
> Simplification. Any help woul
On Mon, Dec 17, 2012 at 3:40 PM, Junio C Hamano wrote:
> Traditionally, %C(color attr) always emitted the ANSI color
> sequence; it was up to the scripts that wanted to conditionally
> color their output to omit %C(...) specifier when they do not want
> colors.
>
> Optionally allow "auto," to be p
On Sun, Dec 16, 2012 at 2:20 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> entry_count is used in update_one() for two purposes:
>>
>> 1. to skip through the number of processed entries in in-memory index
>> 2. to record the number of entries this cache-tree covers on disk
>>
>>
On Sun, Dec 16, 2012 at 2:19 AM, Ramsay Jones
wrote:
>
> The failing tests make use of a POSIX character class, '[:xdigit:]'
> in this case, which some versions of the fnmatch() library function
> do not support. In the spirit of commit f1cf7b79 ("t3070: disable
> unreliable fnmatch tests", 15-10-
On Sat, Dec 15, 2012 at 2:45 PM, Felipe Contreras
wrote:
> Couple of facts first:
> a) This code was already merged
> b) This code is for a test
> c) I'm the only developer so far
>
>> Cruft in the codebase is a problem for git *developers* because it makes
>> the code harder to maintain and exten
On Thu, Dec 13, 2012 at 8:13 PM, Jeff King wrote:
> If you are using --format="%C(red)" or similar placeholders,
> they are the odd duck by not respecting the auto-color mode.
But they should, shouldn't they? Just asking. I may do it to when I
revive nd/pretty-placeholder-with-color-option.
--
D
On Sat, Dec 15, 2012 at 5:09 AM, Jeff King wrote:
> I always compile git with "gcc -Wall -Werror", because it catches a lot
> of dubious constructs, and we usually keep the code warning-free.
> However, I also typically compile with "-O0" because I end up debugging
> a fair bit.
>
> Sometimes, tho
On Thu, Dec 13, 2012 at 9:04 AM, Junio C Hamano wrote:
>> @@ -324,7 +325,14 @@ static int update_one(struct cache_tree *it,
>> if (!sub)
>> die("cache-tree.c: '%.*s' in '%s' not found",
>> entlen, path + baselen,
On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky
wrote:
> If it doesn't, it would be trivial to add. It's a one-liner. It's been a while
> since I used Lua, but it would be something like this:
>
> void L_putenv(lua_State *L) {
> putenv(lua_tostring(L, 1));
> }
>
> and then somewher
On Mon, Dec 10, 2012 at 1:31 PM, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> On Sat, Dec 8, 2012 at 12:59 AM, Junio C Hamano wrote:
>>>> * If somebody has a working replacement URL, we could use that
>>>>instead, of course. Takers?
>
On Mon, Dec 10, 2012 at 1:50 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> diff --git a/cache-tree.c b/cache-tree.c
>> index 28ed657..989a7ff 100644
>> --- a/cache-tree.c
>> +++ b/cache-tree.c
>> @@ -248,6 +248,7 @@ static int update_one(struct cache_tree *it,
>> int missin
On Sat, Dec 8, 2012 at 12:59 AM, Junio C Hamano wrote:
>> * If somebody has a working replacement URL, we could use that
>>instead, of course. Takers?
>
> A possible alternative could be
> https://www.ohloh.net/p/git/contributors/summary
Nice charts!
--
Duy
--
To unsubscribe from this lis
On Wed, Dec 5, 2012 at 2:39 AM, Junio C Hamano wrote:
>> Or a project commit hook?
>
> Surely. It is OK to have "cd t && make test-lint" in your
> pre-commit hook.
No, what I meant is a shared pre-commit script that all git devs are
encouraged (or forced) to install so bugs are found locally rat
On Mon, Dec 3, 2012 at 11:56 PM, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> The test suite needs to be run on different platforms.
>> As it may be difficult for contributors to catch syntax
>> which work on GNU/linux, but is unportable, make a quick check
>> for the most common pro
On Fri, Nov 30, 2012 at 7:06 AM, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>>> An alternative might be to add a "phoney" bit next to "used" in the
>>> cache_tree structure, mark the cache tree as phoney when we skip an
>>&
On Wed, Nov 28, 2012 at 9:27 AM, Jeff King wrote:
> A tree with meta-paths like '.' or '..' does not work well
> with git; the index will refuse to load it or check it out
> to the filesystem (and even if we did not have that safety,
> it would look like we were overwriting an untracked
> director
On Mon, Nov 26, 2012 at 8:45 AM, Brandon Casey wrote:
> From: Brandon Casey
>
> I hate to have the battle of the patches, but I kinda prefer the
> append_signoff code in sequencer.c over the code in log-tree.c as a
> foundation to build on.
>
> So, this series is similar to Duy's "unification" se
On Sun, Nov 25, 2012 at 5:44 PM, Michael Haggerty wrote:
> On the contrary, there is *constant* traffic on the mailing list about
> incompatibilities between different shell implementations (sh, dash,
> bash, etc), not to mention those in other utilities (sed, grep, etc)
> that one is forced to wo
On Wed, Nov 21, 2012 at 7:05 AM, Junio C Hamano wrote:
> * nd/unify-appending-of-s-o-b (2012-11-15) 1 commit
> - Unify appending signoff in format-patch, commit and sequencer
>
> I am not sure if the logic to refrain from adding a sign-off based
> on the existing run of sign-offs is done correc
On Tue, Nov 20, 2012 at 4:20 AM, Junio C Hamano wrote:
>> $ time git rev-list --quiet HEAD -- '*.c'
>>
>> real0m40.770s
>> user0m40.290s
>> sys 0m0.256s
>>
>> With the patch
>>
>> $ time ~/w/git/git rev-list --quiet HEAD -- '*.c'
>>
>> real0m34.288s
>> user0m33.997s
>> sys
On Tue, Nov 20, 2012 at 3:54 AM, Junio C Hamano wrote:
> How would we protect this optimization from future breakages?
>
> Once we start using FNM_PERIOD, this becomes unsafe, as the simple
> part in "foo/bar*baz" would be "foo/bar" with remainder "*baz".
>
> The pattern "foo/bar*baz" should match
On Tue, Nov 20, 2012 at 8:50 AM, Thomas Gay wrote:
> Sorry for the late reply; I've been out of the office for the past few days.
>
> On Fri, Nov 16, 2012 at 7:11 PM, Nguyen Thai Ngoc Duy
> wrote:
>> If it still says "unpack-objects died of signal 11" then
On Fri, Nov 16, 2012 at 1:54 PM, Thomas Gay wrote:
>> If you set receive.unpacklimit to 1 on the receiving end, does it still
>> crash?
>
> Yes. The crash log looks the same too.
If it still says "unpack-objects died of signal 11" then it was not
done the right way. The receiving end can use eit
On Fri, Nov 16, 2012 at 12:44 PM, Thomas Gay wrote:
> Using Git 1.8 on Mac OS X 10.7.5. I just added a large binary file to
How large exactly?
> my repo, and each time I try to push it, Git crashes. I've attached
> the crash log to this email and pasted the console output below.
>
> Counting obj
On Fri, Nov 16, 2012 at 12:13 AM, "Jan H. Schönherr"
wrote:
>> #define isprint(x) (sane_istest(x, GIT_ALPHA | GIT_DIGIT | GIT_SPACE | \
>> GIT_PUNCT | GIT_REGEX_SPECIAL | GIT_GLOB_SPECIAL | \
>> - GIT_PATHSPEC_MAGIC))
>> + GIT_PATHSPEC_MAGIC) && \
>> +
On Fri, Nov 16, 2012 at 3:42 AM, Brandon Casey wrote:
>> Interestingly this patch triggers the fault that it fixes.
>> I was surprised that there was no blank line before my S-o-b
>> and thought I broke something. It turns out I used unmodified
>> format-patch and it mistook the S-o-b quote as
On Wed, Nov 14, 2012 at 2:55 AM, Douglas Mencken wrote:
>> Could you try re-building git with the
>> NO_THREAD_SAFE_PREAD build variable set?
>
> Yeah! It works!!!
>
> --- evil/Makefile
> +++ good/Makefile
> @@ -957,6 +957,7 @@
> HAVE_PATHS_H = YesPlease
> LIBC_CONTAINS_LIBINTL =
On Mon, Nov 12, 2012 at 4:15 AM, David Lang wrote:
> Using a web browser requires connectivity at the time you are doing the
> review.
>
> Mailing list based reviews can be done at times when you don't have
> connectivity.
I am not against email-based reviews but I'd like to point out that
with G
On Sun, Nov 11, 2012 at 6:11 PM, suvayu ali wrote:
> I'm just a user, I found this discussion intriguing and was wondering if
> any of you have heard of patchwork server[1]. It is a patch aggregator
> for mailing lists and provides a convenient bug tracker like web
> interface without getting in
On Fri, Nov 9, 2012 at 6:57 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> diff --git a/cache-tree.c b/cache-tree.c
>> index 28ed657..30a8018 100644
>> --- a/cache-tree.c
>> +++ b/cache-tree.c
>> @@ -381,6 +381,9 @@ int cache_tree_update(struct cache_tree *it,
>> i = update_
On Fri, Nov 9, 2012 at 5:25 PM, John Szakmeister wrote:
> On Fri, Nov 9, 2012 at 4:27 AM, Tomas Carnecky
> wrote:
> [snip]
>> When merging two branches, git only looks at the tips. It doesn't inspect
>> their histories to see how the files were moved around. So i doesn't matter
>> whether you re
On Thu, Nov 8, 2012 at 3:57 PM, Jonathon Mah wrote:
> Nathan,
>
> I find myself performing similar actions to you: using git add -p to stage
> hunks, sometimes editing the staged patch; and keeping mental notes of things
> I wanted to revert, sometimes changing them in the editor in another wind
On Mon, Nov 5, 2012 at 4:00 AM, Johannes Sixt wrote:
> Patterns beginning with a slash are converted to Windows paths before
> test-wildmatch gets to see them. Use a different first character.
Or we could prepend the paths with something, which is then cut out by
test-wildmatch. Not sure if it's
On Tue, Nov 06, 2012 at 12:53:27AM -0800, Jonathon Mah wrote:
> It appears the index forgot that those files were new. So not only
> has the intent-to-add status been lost, but git status shows a file
> existing in neither HEAD nor the index as not-new-but-modified.
>
> Tracing through it, I narro
On Tue, Oct 30, 2012 at 4:28 PM, Orgad Shaneh
> Any news? This still doesn't work with 1.8.0.
Nope, sorry. It's still in my todo list.
--
Duy
--
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
On Sat, Oct 27, 2012 at 7:33 PM, Junio C Hamano wrote:
>
>
> Nguyen Thai Ngoc Duy wrote:
>>
>>Notice the --cc in the first line, which is combined diff. Usually
>>combined-diff is between two points and one parent. Though somehow git
>>passes 4 parents down com
On Sat, Oct 27, 2012 at 4:26 AM, Aaron Schrab wrote:
> I came across this odd question on stackoverflow:
> http://stackoverflow.com/q/13092854/1507392
>
>
> If git diff is run with "..." as a separate argument between two commit-ish
> arguments causes it to produce strange output. The dif
On Thu, Oct 25, 2012 at 4:45 PM, Jeff King wrote:
> On Tue, Oct 23, 2012 at 09:24:51AM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> These functions are called in sequencer.c, which is part of
>> libgit.a. This makes libgit.a potentially require builtin/merge.c for
>&g
On Wed, Oct 24, 2012 at 12:21 PM, Uri Moszkowicz wrote:
> Continuing to work on improving clone times, using "git gc
> --aggressive" has resulted in a large number of tags combining into a
> single file but now I have a large number of files in the objects
> directory - 131k for a ~2.7GB repositor
On Wed, Oct 24, 2012 at 1:30 AM, Uri Moszkowicz wrote:
> I have a large repository which I ran "git gc --aggressive" on that
> I'm trying to clone on a local file system. I would expect it to
> complete very quickly with hard links but it's taking about 6min to
> complete with no checkout (git clo
On Sun, Oct 21, 2012 at 7:20 PM, Drew Northup wrote:
> On Tue, Oct 9, 2012 at 1:58 AM, Matthieu Moy
> wrote:
>> David Aguilar writes:
>>
>>> I would advise against the file locking, though. You ain't gonna need
>>> it ;-)
>>
>> What do you suggest to merge Word files?
>
> If the files are in the
On Sat, Oct 20, 2012 at 4:03 AM, Junio C Hamano wrote:
> * nd/wildmatch (2012-10-15) 13 commits
>
> Allows pathname patterns in .gitignore and .gitattributes files
> with double-asterisks "foo/**/bar" to match any number of directory
> hierarchies.
>
> I suspect that this needs to be plugged t
On Sat, Oct 20, 2012 at 2:50 AM, Junio C Hamano wrote:
> Not particularly interested in the cause, but not so strongly
> against it to veto it.
I wonder how many people keep old branches like I do, which are
usually far from remotes.
> Doesn't it make more sense to use a notes-cache that is keye
On Fri, Oct 19, 2012 at 6:10 AM, Uri Moszkowicz wrote:
> I'm testing out the sparse checkout feature of Git on my large (14GB)
> repository and am running into a problem. When I add "dir1/" to
> sparse-checkout and then run "git read-tree -mu HEAD" I see dir1 as
> expected. But when I add "dir2/"
On Thu, Oct 18, 2012 at 12:45 PM, Junio C Hamano wrote:
> This replaces the earlier "wip" with a real thing.
>
> We never advertised the "--notes" option to format-patch (or
> anything related to the pretty format options for that matter)
> because the behaviour of these options was whatever they
On Wed, Oct 17, 2012 at 7:09 PM, "Jan H. Schönherr"
wrote:
>> const unsigned char sane_ctype[256] = {
>> - 0, 0, 0, 0, 0, 0, 0, 0, 0, S, S, 0, 0, S, 0, 0, /* 0.. 15 */
>> - 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 16.. 31 */
>> + X, X, X, X, X, X, X, X, X,
On Wed, Oct 17, 2012 at 5:53 PM, Peter Krefting wrote:
> Hi!
>
> The output of "git format-patch" and "git diff --stat" no longer becomes
> localized when using 1.8.0.rc2, compared to 1.7.12
It's the result of this discussion [1]. I don't remember exactly the
open issues. But I think it involves
On Tue, Oct 16, 2012 at 9:09 PM, Adam Spiers wrote:
> I was *intending* to finish it off soon, but I have been really busy
> with work and other commitments recently, which has prevented this. I
> don't currently have any unpublished changes which would conflict with
> your recent work, and I'm a
On Tue, Oct 16, 2012 at 4:03 AM, Junio C Hamano wrote:
>> Coloring is to me an improvement over --summary. Probably the main
>> point. Without it, perhaps it's not worth putting extra text to
>> diffstat.
>
> It is kind of surprising that you did not choose to paint new in
> green and gone in red,
Adam, do you have time to continue this series? I can help polish it
for inclusion, but I don't want to step in your way if you are quietly
updating it.
On Tue, Oct 16, 2012 at 5:31 AM, Junio C Hamano wrote:
>> +
>> +If `-z` is specified, the output is a series of lines of the form:
>> +
>
> Hmph
On Mon, Oct 15, 2012 at 6:05 PM, Matthieu Moy
wrote:
> Angelo Borsotti writes:
>
>> the push command checks first if the tips of the branches match those
>> of the remote references, and if it does uploads the snapshot.
>
> The update does two things: upload objects to the database, and then
> up
On Mon, Oct 15, 2012 at 12:36 AM, Junio C Hamano wrote:
> With your "teach attr.c match the same optimization as dir.c"
> series, you would need something like this
>
> diff --git i/attr.c w/attr.c
> index 6d39406..528e935 100644
> --- i/attr.c
> +++ w/attr.c
> @@ -710,7 +710,7 @@ static int path_
On Sun, Oct 14, 2012 at 03:59:31PM +0200, René Scharfe wrote:
> Am 14.10.2012 15:25, schrieb Nguyen Thai Ngoc Duy:
> > On Sun, Oct 14, 2012 at 7:59 PM, René Scharfe
> > wrote:
> >> With that, couldn't you squeeze the other two classes into the existing
> >>
On Sun, Oct 14, 2012 at 7:59 PM, René Scharfe
wrote:
>> +const unsigned char sane_ctype2[256] = {
>> + CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, /*
>> 0..15 */
>> + CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, CN, /*
>> 16..31 */
>> + 0, PU,
On Sun, Oct 14, 2012 at 12:04 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>
> The comment-fix seems to be new but otherwise this is unchanged,
> right?
Right.--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
On Sun, Oct 14, 2012 at 12:02 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>
> The description to justify why it is ctype2[] seems to have been
> lost. Intended?
Nope. I added the description after generating patches and forgot to
up
On Sun, Oct 14, 2012 at 12:44 AM, Ramsay Jones
wrote:
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Junio,
>
> This test in the current pu branch (commit bb0e6bf "Merge branch
> 'aw/rebase-am-failure-detection' into pu", 11-10-2012) overwrites
> the contents of t/.gitattributes. Note that the merg
On Fri, Oct 12, 2012 at 12:09:57PM -0700, Junio C Hamano wrote:
> This is not entirely your fault, but please don't do that "cd ..".
>
> The original test had "cd bare", made an assumption that step will
> never fail (which is mostly correct), and ran everything afterward
> in that subdirectory.
>
On Fri, Oct 12, 2012 at 10:05:06AM -0700, Junio C Hamano wrote:
> Nguyen, how about updating the match () shell function in 3070 so
> that it not just says not-ok, but indicates what failed (wildmatch
> failed, or wildmatch passed but fnmatch failed), at least when the
> test is run as "./t3070-*.s
On Thu, Oct 11, 2012 at 3:03 AM, Junio C Hamano wrote:
> It would save time from both of us if you can check what is queued
> on 'pu'. I do not think I touched the code for off-by-one bugs
> there, though.
'pu' looks good.
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git"
On Fri, Oct 12, 2012 at 2:22 PM, Johannes Sixt wrote:
> Am 10/10/2012 12:40, schrieb Nguyễn Thái Ngọc Duy:
>> fnmatch on glibc-2.12.1 returns no match. glibc-2.15 returns ok.
>
> There are many more cases that fail with the fnmatch() that we ship in
> compat/fnmatch. To test this on Linux, you hav
On Thu, Oct 11, 2012 at 9:18 PM, Matthieu Moy
wrote:
> For example, it makes the output of git status look like:
>
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD ..." to unstage)
> # Set advice.statusHints to false to turn off this message
> #
> # modified:
On Thu, Oct 11, 2012 at 4:13 AM, Junio C Hamano wrote:
> This sounds a lot stronger than "let" to me. All existing callers
> that assumed that buf to be emptied by the function now has to clear
> it. "quote: stop resetting output buffer of quote_path_relative()"
> may better describe what this r
On Fri, Oct 05, 2012 at 01:03:28PM -0700, Junio C Hamano wrote:
> >>> OK. I think I was surprised that some messages were controlled by
> >>> advice.* but gave no hints about that and I found that out by other
> >>> means. I'll check all the advice messages.
> >
> > It's about the commands, not the
On Thu, Oct 11, 2012 at 11:33 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> Really small updates. I did not want to resend it this soon but this
>>> may fix the compile errors for Junio.
>
> t3070 seems to break TAP,
>
> *** prove ***
> t307
On Thu, Oct 11, 2012 at 2:04 PM, Michael Haggerty wrote:
> Maybe I'm being too much of a purist, but I don't think that git should
> retroactively reinterpret history on its own initiative in a way that
> might not be correct (e.g., maybe your encoding changed from ASCII to
> Shift-JIS sometime in
On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt wrote:
>> + git commit -m new &&
>> + echo "Binary file HEAD:t matches" >expect &&
>> + git grep text HEAD -- t >actual &&
>> + test_cmp expect actual &&
>> + git reset HEAD^
>> +'
>
> And in yet another test, should
>
> gi
On Thu, Oct 11, 2012 at 3:46 AM, Junio C Hamano wrote:
> Steffen Prohaska writes:
>
>> I've recently discovered that the current protocol can be amazingly
>> inefficient when it comes to transferring binary objects. Assuming two
>> repositories that are in sync. After a 'git checkout --orphan &
On Thu, Oct 11, 2012 at 4:41 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>>@@ -690,16 +689,18 @@ static int path_matches(const char *pathname, int
>> pathlen,
>>* contain the trailing slash
>>*/
>>
>>- if (pathlen < baselen ||
>>+ if (pathlen < basel
This is the documentation part of
1a9d7e9 (attr.c: read .gitattributes from index as well. - 2007-08-14)
06f33c1 (Read attributes from the index that is being checked out - 2009-03-13)
Signed-off-by: Nguyễn Thái Ngọc Duy
---
I looked around but did not see anywhere mentioning this. If I did
no
On Wed, Oct 10, 2012 at 7:43 PM, Johannes Sixt wrote:
> Am 10/10/2012 14:32, schrieb Nguyen Thai Ngoc Duy:
>> git-archive has --worktree-attributes to specify where attributes come
>> from. Sparse checkout can choose to read index version first then
>> worktree's or
On Wed, Oct 10, 2012 at 7:12 PM, Johannes Sixt wrote:
> Is there already an established definition which the "correct"
> .gitattributes are?
If I ask to grep the index then to me it should read only the index.
Although other people can counter that they may want different
attributes than the one
On Wed, Oct 10, 2012 at 6:51 PM, Johannes Sixt wrote:
> Thanks for working on this issue!
>
> Am 10/10/2012 13:34, schrieb Nguyễn Thái Ngọc Duy:
>> + linkgit:gitattributes[5]). Note that .gitattributes are only
>> + support for searching files in working directory.
>
> Does this mean it do
On Wed, Oct 10, 2012 at 12:31 PM, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> Git's ctype does not seem to be complete for wildmatch's use so
>> ctype.h is required. But that can be easily fixed later on.
>
> Until "later on", I cannot
On Wed, Oct 10, 2012 at 12:33 PM, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> On Wed, Oct 10, 2012 at 1:59 AM, Junio C Hamano wrote:
>>> Jeff King writes:
>>>
>>>> I think we just need to have callers of grep_source_init provide us with
On Tue, Oct 9, 2012 at 2:57 PM, Michael Haggerty wrote:
>> + - A trailing "/**" matches everything inside. For example,
>> + "abc/**" is equivalent to "`/abc/`".
>
> It seems odd that you add a leading slash in this example. I assume
> that is because of the rule that a pattern containing a sla
On Wed, Oct 10, 2012 at 1:59 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> I think we just need to have callers of grep_source_init provide us with
>> the actual pathname (or NULL, in the case of GREP_SOURCE_BUF). That is
>> where the information is lost.
>
> Yes. I agree that is the right
On Wed, Oct 10, 2012 at 3:47 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> diff --git a/wildmatch.c b/wildmatch.c
>> index 7b64a6b..2382873 100644
>> --- a/wildmatch.c
>> +++ b/wildmatch.c
>> @@ -11,8 +11,8 @@
>>
>> #include
>> #include
>> -#include
>>
>> +#include "cache.h"
On Tue, Oct 09, 2012 at 04:38:32PM +0700, Nguyen Thai Ngoc Duy wrote:
> #5 0x0815e736 in userdiff_find_by_path (path=0x820e7f0
> "HEAD:Documentation/.gitattributes") at userdiff.c:278
> #6 0x081058ca in grep_source_load_driver (gs=0xbfffd978) at grep.c:1504
A bandage patch
On Tue, Oct 9, 2012 at 4:03 PM, Johannes Sixt wrote:
> Running 'git grep needle origin/master' on Windows gives numerous warnings
> of the kind
>
> warning: unable to access 'origin/master:Documentation/.gitattributes':
> Invalid argument
strace confirms it. Stack trace
#0 read_attr_from_file (
On Tue, Oct 9, 2012 at 6:33 AM, Junio C Hamano wrote:
> * Unify pathspec semantics
>
>This has happened and commands that used to take only path prefix
>style pathspecs now take globs as well [ND]
I've been thinking about it lately and will probably restart soon with
a different approach
se of
different attribute assignments):
*.c attr1
!foo.c attr2
It could be even more confusing in multiple attribute manipulation:
*.c attr1
*.h -attr2
!foo.[ch] attr1 -attr2
So "not supported" and "forbidden" are equally OK. I just want to
raise a point that it has some use bef
On Wed, Oct 3, 2012 at 10:44 PM, Alexey Spiridonov
wrote:
> Thanks a lot for trying this.
>
> My hashes match. I just re-reproduced it on two flavors of Linux (64
> and 32-bit), with two different Git versions (see below). What
> platform are you using?
x86, 32 bit. Perhaps it has something to do
On Sat, Oct 6, 2012 at 6:33 PM, Philip Oakley wrote:
>> Asciidoc 8.2.6 does not like me writing
>> "Put \# if you need a literal #.." so I go with "backslash" and
>> "hash" instead. `\!` displays fine both in man page and html format.
>> '!' changed to `!` because it looks clearer in monospace.
>
1 - 100 of 231 matches
Mail list logo
