On Mon, Mar 09, 2015 at 02:19:20AM -0400, Jeff King wrote:
> We don't turn on copy-detection in "git status" by default (only rename
> detection), and I think you are right that there is currently no way to
> turn it on manually.
Actually, I take it back. We do break-detection in git-status, whic
On Fri, Mar 06, 2015 at 09:12:45PM -0800, Kyle J. McKay wrote:
> And I responded and that response and the rest of the thread are available
> on gmane [1], but the first two messages are not. I waited 10 days just to
> make sure there were no bounce emails or undeliverable notifications coming
>
On Mar 7, 2015, at 23:52, Junio C Hamano wrote:
"Kyle J. McKay" writes:
If the user has set SHELL_PATH in the Makefile then we
should respect that value and use it.
Signed-off-by: Kyle J. McKay
---
builtin/help.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/help
On Sun, Mar 08, 2015 at 09:41:08PM -0400, Matthew Rothenberg wrote:
> I see, thank you. But how would one ever get a copy operation to show
> up in the output of `git status -z` to begin with? It appears copies
> are only detected in `diff` and `show`, can be forced with the
> --find-copies-harder
On Sun, Mar 08, 2015 at 10:19:20PM -0700, Kyle J. McKay wrote:
> >I am not convinced this isn't a violation of POSIX (which specifies that
> >field splitting is done on the results of parameter expansions outside
> >of double-quotes). But whether it is or not, we have to live with it.
>
> That's
On Mar 8, 2015, at 18:22, brian m. carlson wrote:
On Sun, Mar 08, 2015 at 06:15:55PM -0400, Eric Sunshine wrote:
On Sun, Mar 8, 2015 at 6:04 PM, brian m. carlson
wrote:
Perhaps this is better?
Unfortunately when running the test, that message is found in the
standard
output of git show -s
On Mar 8, 2015, at 10:56, Jeff King wrote:
On Sun, Mar 08, 2015 at 08:37:50AM -0700, Kyle J. McKay wrote:
The FreeBSD shell converts this expression:
git ${1:+-c push.default="$1"} push
to this when "$1" is not empty:
git "-c push.default=$1" push
which causes git to fail.
Hmph, just wh
Because "--graph" is about connected history while --no-walk
is about discrete points, it does not make sense to allow
giving these two options at the same time. [1]
This change allows git-show to have such options' combination
as a special case, because git-show itself has underlying
--no-walk op
On Sun, Mar 8, 2015 at 4:14 AM, Junio C Hamano wrote:
> I think this is how -z was designed to be used, and if that isn't
> clear, then the documentation must be updated to clarify. Rename
> and Copy are the only ones that needs two pathnames, and I suspect
> that whoever did the original descrip
On Sun, Mar 08, 2015 at 06:15:55PM -0400, Eric Sunshine wrote:
On Sun, Mar 8, 2015 at 6:04 PM, brian m. carlson
wrote:
Perhaps this is better?
Unfortunately when running the test, that message is found in the standard
output of git show -s --show-signature, but in the standard error of git
On Thu, Mar 5, 2015 at 8:28 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> +versionsort.prereleaseSuffix::
>>> +When version sort is used in linkgit:git-tag[1], prerelease
>>> +tags (e.g. "1.0-rc1") may appear after the main release
>>> +"1.0". By specifying the suffix "-rc"
This is a patch to add a much needed option to the bash completion
script. I'm not subscribed to this list, so please include me in your
reply if you'd like me to see your response.
Thanks,
James
From ca976de5bfeccc9bd69c22183f82b9d1e59d2547 Mon Sep 17 00:00:00 2001
From: James Shubin
Date: Sun,
On Sun, Mar 08, 2015 at 12:39:10PM -0700, Linus Torvalds wrote:
> On Sun, Mar 8, 2015 at 12:02 PM, Ken Moffat wrote:
> >
> > The comments on git bisect were for linus'skernel tree, on a local
> > disk. 2.3GB of repo, just under 57000 files.
>
> Ugh. I hope you are talking about checked-out size.
On Sun, Mar 8, 2015 at 7:03 AM, Hiroyuki Sano wrote:
> Add regex patterns for CSS. The word regex maches selectors, properties,
> and values. On the other hand, the funcname regex matches lines contains
> the curly brace character.
>
> Signed-off-by: Hiroyuki Sano
> ---
> diff --git a/t/t4034/css
On Sun, Mar 8, 2015 at 7:03 AM, Hiroyuki Sano wrote:
> attrs: add "css" to the list of userdiff bulit-in patterns
s/bulit/built/
> Signed-off-by: Hiroyuki Sano
> ---
> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
> index c892ffa..8904a2a 100644
> --- a/Document
On Thu, Mar 5, 2015 at 1:19 PM, Karthik Nayak wrote:
> made changes to "cat-file" to include a "--literally"
Write in imperative mood: "Teach cat-file a --literally option..."
> option which prints the type of the object without any
> complaints.
Unfortunately, this explanation is quite lacking
On Thu, Mar 5, 2015 at 1:18 PM, Karthik Nayak wrote:
> cache: modify for "cat-file --literally -t"
It is desirable for the first line of the commit message to explain,
as well as possible, the intent of the patch. The bulk of the commit
message then elaborates. Unfortunately, this line says almos
On Sun, Mar 8, 2015 at 6:04 PM, brian m. carlson
wrote:
> On Sun, Mar 08, 2015 at 05:43:41PM -0400, Eric Sunshine wrote:
>> On Sun, Mar 8, 2015 at 11:40 AM, Kyle J. McKay wrote:
>>> Warning: using insecure memory!
>>>
>>> Unfortunately when running the test, that message gets
>>> collected in t
On Sun, Mar 08, 2015 at 05:43:41PM -0400, Eric Sunshine wrote:
On Sun, Mar 8, 2015 at 11:40 AM, Kyle J. McKay wrote:
Depending on how gpg was built, it may issue the following
message to stderr when run:
Warning: using insecure memory!
Unfortunately when running the test, that message gets
Sundararajan R writes:
> I am sorry for the mistakes in the code formatting. It was because I was in
> a hurry that day and I wanted to submit a working patch.
No need to apologize for mistakes. Mistakes are expected part of
being human and the review process is designed to catch exactly
that.
On Sun, Mar 8, 2015 at 11:03 AM, Kevin Daudt wrote:
> rev-list --bisect is used by git bisect, but never together with
> --first-parent. Because rev-list --bisect together with --first-parent
> is not handled currently, and even leads to segfaults, refuse to use
> both options together.
>
> Signed
On Sun, Mar 8, 2015 at 11:40 AM, Kyle J. McKay wrote:
> Depending on how gpg was built, it may issue the following
> message to stderr when run:
>
> Warning: using insecure memory!
>
> Unfortunately when running the test, that message gets
> collected in the stdout result of git show -s --show-s
Stefan Beller writes:
>> I do not see a good reason why we want "I am sending N caps"
>> upfront, instead of "this, that, and here is the end of the group".
>
> I thought about having an end marker, so something like
> capabilities start
> thin-pack
> lang
> ofs-delta
> capabilities done
>
> (Eac
On Sun, Mar 8, 2015 at 12:37 PM, David Kastrup wrote:
>
> Since git blame outputs everything once it is finished ("the first
> screen" is purely the pager's business), it needs to unpack the entire
> history of the file (unless no blameable lines remain at all) and look
> at it. 6 seconds tends n
Dongcan Jiang writes:
> Because --graph is about connected history while
> --no-walk is about discrete points. [1]
The convention around here is that the title of the patch on the
Subject line is *not* the beginning part of the first sentence, you
would need to phrase the above more like:
On Sun, Mar 8, 2015 at 12:02 PM, Ken Moffat wrote:
>
> The comments on git bisect were for linus'skernel tree, on a local
> disk. 2.3GB of repo, just under 57000 files.
Ugh. I hope you are talking about checked-out size.
[torvalds@i7 linux]$ du -sh .git
850M .git
because otherwise it so
Ken Moffat writes:
> On Sun, Mar 08, 2015 at 05:21:22PM +0100, David Kastrup wrote:
>
>> Particularly not git-blame in 2.1. I should be quite surprised to see
>> any git-blame call running noticeably slower in 2.1 than in any
>> preceding version.
>>
>> What may have happened is that the reposi
On Sun, Mar 08, 2015 at 05:21:22PM +0100, David Kastrup wrote:
> Kevin D writes:
>
> > On Sat, Mar 07, 2015 at 01:30:07AM +, Ken Moffat wrote:
> >> Hi, please CC me if that is not your usual fashion, because I am not
> >> subscribed.
> >>
> >> I use git for my build scripts - those are acces
karthik nayak writes:
> Sorry for the confusion, you did already say that in $gmane/264955 , I'm
> talking about how I tackled the issue in $gmane/264855.
Well, I am suggesting how to improve what you did in your
$gmane/264855 and a part of that was to suggest that teaching
parse_sha1_header() t
On Sun, Mar 08, 2015 at 04:51:36PM +0100, Kevin D wrote:
> On Sat, Mar 07, 2015 at 01:30:07AM +, Ken Moffat wrote:
> > Hi, please CC me if that is not your usual fashion, because I am not
> > subscribed.
> >
> > I use git for my build scripts - those are accessed over nfs. Since
> > I started
Kyle,
Thanks, I suppose that works well enough for my needs. I wasn't aware
that aliases were that flexible in git.
I also have no problem to git-init and do all the other steps manually.
Thanks,
Diego
On Sat, Mar 7, 2015 at 11:32 PM, Kyle J. McKay wrote:
> On Mar 7, 2015, at 17:53, Diego Vio
Hi,
On Sun, Mar 08, 2015 at 08:28:40PM +0530, Sudhanshu Shekhar wrote:
> Four test cases have been added
>
> 1) when user does reset - without any previous branch => Leads to error
> 2) when user does reset - with a previous branch => Ensure it
> behaves like {-1}
>
> Other two deal with
On Sun, Mar 08, 2015 at 08:37:50AM -0700, Kyle J. McKay wrote:
> The FreeBSD shell converts this expression:
>
> git ${1:+-c push.default="$1"} push
>
> to this when "$1" is not empty:
>
> git "-c push.default=$1" push
>
> which causes git to fail.
Hmph, just when I thought I knew about a
Kevin D writes:
> On Sat, Mar 07, 2015 at 01:30:07AM +, Ken Moffat wrote:
>> Hi, please CC me if that is not your usual fashion, because I am not
>> subscribed.
>>
>> I use git for my build scripts - those are accessed over nfs. Since
>> I started using 2.1 and later (I don't think I used 2
PAYMENT INFO.pdf
Description: Binary data
On Sat, Mar 07, 2015 at 01:30:07AM +, Ken Moffat wrote:
> Hi, please CC me if that is not your usual fashion, because I am not
> subscribed.
>
> I use git for my build scripts - those are accessed over nfs. Since
> I started using 2.1 and later (I don't think I used 2.0) commands
> such as 'c
Depending on how gpg was built, it may issue the following
message to stderr when run:
Warning: using insecure memory!
Unfortunately when running the test, that message gets
collected in the stdout result of git show -s --show-signature
but is collected in the stderr result of git verify-commit
The FreeBSD shell converts this expression:
git ${1:+-c push.default="$1"} push
to this when "$1" is not empty:
git "-c push.default=$1" push
which causes git to fail. To avoid this we simply break up the
expansion into two parts so that the whitespace which creates
two arguments instead o
rev-list --bisect is used by git bisect, but never together with
--first-parent. Because rev-list --bisect together with --first-parent
is not handled currently, and even leads to segfaults, refuse to use
both options together.
Signed-off-by: Kevin Daudt
Suggested-by: Junio C. Hamano
---
Sorry f
rev-list --bisect is used by git bisect, but never together with
--first-parent. Because rev-list --bisect together with --first-parent
is not handled currently, and even leads to segfaults, refuse to use
both options together.
Signed-off-by: Kevin Daudt
Suggested-by: Junio C. Hamano
---
Sorry f
Four test cases have been added
1) when user does reset - without any previous branch => Leads to error
2) when user does reset - with a previous branch => Ensure it
behaves like {-1}
Other two deal with the situation when we have a file named '-'. We
ignore such a file and - is always tre
"-" now means the previous branch.
Signed-off-by: Sudhanshu Shekhar
Thanks-to: Junio C Hamano, Matthieu Moy, Eric Sunshine
---
Thank you all for your feedback. Please let me know if I am missing out on
anything else.
builtin/reset.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-
On Sun, Mar 08, 2015 at 04:57:36PM +0700, Duy Nguyen wrote:
On Sun, Mar 8, 2015 at 6:23 AM, brian m. carlson
wrote:
I'm not very excited about having to put the #include in the middle of
cache.h. The alternative, of course, is to move enum object_type up,
which I can do if necessary. Another
rev-list --bisect is used by git bisect, but never together with
--first-parent. Because rev-list --bisect together with --first-parent
is not handled currently, and even leads to segfaults, refuse to use
both options together.
Signed-off-by: Kevin Daudt
Suggested-by: Junio C. Hamano
---
* Chang
On Sun, Mar 8, 2015 at 1:04 PM Junio C Hamano wrote:
Sundararajan R writes:
> diff --git a/builtin/reset.c b/builtin/reset.c
> index 4c08ddc..62764d4 100644
> --- a/builtin/reset.c
> +++ b/builtin/reset.c
> @@ -203,8 +203,16 @@ static void parse_args(struct pathspec *pathspec,
>*
>
Add regex patterns for CSS. The word regex maches selectors, properties,
and values. On the other hand, the funcname regex matches lines contains
the curly brace character.
Signed-off-by: Hiroyuki Sano
---
t/t4018-diff-funcname.sh | 1 +
t/t4034-diff-words.sh| 1 +
t/t4034/css/expect
Signed-off-by: Hiroyuki Sano
---
Documentation/gitattributes.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index c892ffa..8904a2a 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -52
On 03/08/2015 02:33 PM, Junio C Hamano wrote:
karthik nayak writes:
> What parse_sha1_header() does to get the type is just find the first
> occurrence of a " " manually and store everything before it as the
> type. Then it finds the size of the object if needed. And finally
> returns the type
Sudhanshu Shekhar writes:
> + if(!strcmp(argv[0], "-")) {
[...]
> diff --git a/builtin/reset.c b/builtin/reset.c
> index 9f8967d..02f33ef 100644
> --- a/builtin/reset.c
> +++ b/builtin/reset.c
> @@ -206,7 +206,7 @@ static void parse_args(struct pathspec *pathspec,
>*/
>
>
"Kyle J. McKay" writes:
> About 10 days ago I sent out this message (just reproducing the
> relevant headers here):
>
>> From: Kyle J. McKay
>> Date: February 24, 2015 09:16:05 PST
>> To: Junio C Hamano
>> Cc: Git Mailing List
>> Subject: Any chance for a Git v2.1.5 release?
>> Message-Id:
>>
It is really helpful. Thanks a lot!
2015-03-08 17:34 GMT+08:00 Duy Nguyen :
> On Sun, Mar 8, 2015 at 3:57 PM, Dongcan Jiang wrote:
>> Hi, all
>>
>> After digging into how "git fetch" works, I have found that my previous
>> understanding was too rash. I'm sorry for that.
>>
>> I find that the curr
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 machine
there's no guarantee that untracked cache can still function properly.
Rec
When a good user sees the "too long, consider -uno" advice when
running `git status`, they should check out the man page to find out
more. This change suggests they try untracked cache before -uno.
Helped-by: brian m. carlson
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
Helped-by: Eric Sunshine
Helped-by: Junio C Hamano
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
Documentation/git-update-index.txt | 6 ++
builtin/update-index.c | 168 +
2 files changed, 174 insertions(+)
diff --git a
Helped-by: Eric Sunshine
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
compat/mingw.c | 11 +++
compat/mingw.h | 9 +
2 files changed, 20 insertions(+)
diff --git a/compat/mingw.c b/compat/mingw.c
index c5c37e5..88140e4 100644
--- a/compat/mingw.c
+++ b
On 03/08/2015 12:44 PM, Junio C Hamano wrote:
Eric Sunshine writes:
On Sat, Mar 7, 2015 at 5:49 AM, karthik nayak wrote:
Also "*(*argv)[1]" seems more readable to me, maybe more of a perspective?
I also had considered suggesting (*argv)[1][0] as more readable, but
it is primarily person
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
.gitignore | 1 +
Makefile | 1 +
t/t7063-status-untracked-cache.sh (new +x) | 353 +
test-dump-untracked-cache.c (new)
Overall time saving on "git status" is about 40% in the best case
scenario, removing ..collect_untracked() as the most time consuming
function. read and refresh index operations are now at the top (which
should drop when index-helper and/or watchman support is added). More
numbers and analysis belo
This can be used to double check if results with untracked cache are
correctly, compared to vanilla version. Untracked cache remains in
index, but not used.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
update_index_if_able() is moved down so that the updated untracked
cache could be written out.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
builtin/commit.c | 5 +++--
wt-status.c | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin/commit
This could be used to verify correct behavior in tests
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
dir.c | 12
1 file changed, 12 insertions(+)
diff --git a/dir.c b/dir.c
index 7d57623..01f0032 100644
--- a/dir.c
+++ b/dir.c
@@ -1923,6 +1923,18 @@ int rea
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
cache.h | 1 +
dir.c| 9 +
read-cache.c | 2 +-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index f8b3dc5..fca979b 100644
--- a/cache.h
+++ b/cache.h
@@ -295,6 +295,7 @
Helped-by: Stefan Beller
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
Documentation/technical/index-format.txt | 58 +
cache.h | 3 +
dir.c| 139 +++
dir.h
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c| 219 +++
dir.h| 2 +
read-cache.c | 5 ++
3 files changed, 226 insertions(+)
diff --git a/dir.c b/dir.c
index 8f0deb1..0b37c65 100644
--- a/dir.c
+++ b/dir.c
@@ -2279,3 +227
Ideally we should implement untracked_cache_remove_from_index() and
untracked_cache_add_to_index() so that they update untracked cache
right away instead of invalidating it and wait for read_directory()
next time to deal with it. But that may need some more work in
unpack-trees.c. So stay simple as
When a directory is updated within the same second that its timestamp
is last saved, we cannot realize the directory has been updated by
checking timestamps. Assume the worst (something is update). See
29e4d36 (Racy GIT - 2005-12-20) for more information.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signe
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
read-cache.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index d643a3f..f12a185 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -270,20 +270,26 @@ s
The idea is if we can capture all input and (non-rescursive) output of
read_directory_recursive(), and can verify later that all the input is
the same, then the second r_d_r() should produce the same output as in
the first run.
The requirement for this to work is stat info of a directory MUST
chan
Akshay Aurora writes:
> Thanks Junio. Working on v2 for this patch.
>
> On Sat, Mar 7, 2015 at 12:00 AM, Junio C Hamano wrote:
Please, don't top-post on this list.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
ewah/ewah_io.c | 13 +
ewah/ewok.h| 2 ++
split-index.c | 11 ++-
3 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/ewah/ewah_io.c b/ewah/ewah_io.c
index 1c2d7af..43481b9 100644
--- a/ew
This cuts down a signficant number of open(.gitignore) because most
directories usually don't have .gitignore files.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
dir.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/dir.c b
The main readdir loop in read_directory_recursive() is replaced with a
new one that checks if cached results of a directory is still valid.
If a file is added or removed from the index, the containing directory
is invalidated (but not its subdirs). If directory's mtime is changed,
the same happens
Make sure the starting conditions and all global exclude files are
good to go. If not, either disable untracked cache completely, or wipe
out the cache and start fresh.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
dir.c | 113
It's easy to see that if an existing .gitignore changes, its SHA-1
would be different and invalidate_gitignore() is called.
If .gitignore is removed, add_excludes() will treat it like an empty
.gitignore, which again should invalidate the cached directory data.
if .gitignore is added, lookup_untr
Compared to 'pu', this fixes two bugs (in 01/24 and 10/24) and one
style vololation (in 11/24), found by Junio and Stefan. Diff
-- 8< --
diff --git a/dir.c b/dir.c
index b8a4f9e..8a037ee 100644
--- a/dir.c
+++ b/dir.c
@@ -687,7 +687,8 @@ static int add_excludes(const char *fname, const char
*base
This is not used anywhere yet. But the goal is to compare quickly if a
.gitignore file has changed when we have the SHA-1 of both old (cached
somewhere) and new (from index or a tree) versions.
Helped-by: Junio C Hamano
Helped-by: Torsten Bögershausen
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-
This allows us to feed different info to read_directory_recursive()
based on untracked cache in the next patch.
Helped-by: Ramsay Jones
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
dir.c | 55 +++
1 file changed, 47 i
If we redo this thing in a functional style, we would have one struct
untracked_dir as input tree and another as output. The input is used
for verification. The output is a brand new tree, reflecting current
worktree.
But that means recreate a lot of dir nodes even if a lot could be
shared between
Junio C Hamano writes:
> Jeff King writes:
>
>> On Fri, Mar 06, 2015 at 12:53:57PM +0100, Matthieu Moy wrote:
>>
>>> Idea and most of the wording comes from Junio's message on the list. I
>>> added a hint to include links to review in the application (which makes
>>> the suggestion a bit stronge
On Sun, Mar 8, 2015 at 6:23 AM, brian m. carlson
wrote:
> There are several utility functions (hashcmp and friends) that are used
> for comparing object IDs (SHA-1 values). Using these functions, which
> take pointers to unsigned char, with struct object_id requires tiresome
> access to the sha1
On Sun, Mar 8, 2015 at 3:57 PM, Dongcan Jiang wrote:
> Hi, all
>
> After digging into how "git fetch" works, I have found that my previous
> understanding was too rash. I'm sorry for that.
>
> I find that the current workflow of "git fetch --depth" is as follows:
>
> 1. 'fetch module' calls 'git
karthik nayak writes:
> What parse_sha1_header() does to get the type is just find the first
> occurrence of a " " manually and store everything before it as the
> type. Then it finds the size of the object if needed. And finally
> returns the type by calling type_from_string(). This is where we
Hi, all
After digging into how "git fetch" works, I have found that my previous
understanding was too rash. I'm sorry for that.
I find that the current workflow of "git fetch --depth" is as follows:
1. 'fetch module' calls 'git-upload-pack service' via 'transport module'
to fetch ref with
On 03/08/2015 01:39 PM, Junio C Hamano wrote:
karthik nayak writes:
On 03/07/2015 12:58 AM, Junio C Hamano wrote:
case 't':
oi.typep = &type;
oi.typename = &sb;
sha1_object_info_extended(sha1, &oi, flags);
if (sb.len) {
printf("%s\n", sb.buf);
Matthew Rothenberg writes:
> 2. Read from buffer until the first NUL, parse the entry status
> codes, and if the entry status code represents a status that *should*
> have multiple filenames, read from buffer until a second NUL is found,
> and then reparse that entry with both filenames. The iss
karthik nayak writes:
> On 03/07/2015 12:58 AM, Junio C Hamano wrote:
>
> case 't':
> oi.typep = &type;
> oi.typename = &sb;
> sha1_object_info_extended(sha1, &oi, flags);
> if (sb.len) {
> printf("%s\n", sb.buf);
> strbuf_release(&sb);
>
Anton Trunov writes:
> On 04/03/15 23:01, Junio C Hamano wrote:
>
> My apologies for pushing this topic, but what would you recommend?
> Should we treat both sides line-wise or should we correct the documentation?
My gut feeling is that the change to swap which side is examined
first would end u
Kevin Daudt writes:
> On Sat, Mar 07, 2015 at 10:31:16PM +0100, Kevin Daudt wrote:
>> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
>> index ff84a82..c271e15 100644
>> --- a/builtin/rev-list.c
>> +++ b/builtin/rev-list.c
>> @@ -291,6 +291,9 @@ int cmd_rev_list(int argc, const char **argv,
88 matches
Mail list logo
