* Re: [PATCH] Cache stat_tracking_info() for faster status and branch -v
From: Junio C Hamano @ 2012-10-19 19:50 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1350408967-13919-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> stat_tracking_info() is used to calculated how many commits ahead or
> behind for a branch. Rev walking can be slow especially when the
> branch is way behind its remote end. By caching the results, we won't
> have to rev walk every time we need these information.
> stat_tracking_info() cost can be greatly reduced this way.
>
> This makes sure "git status" instant no matter how far behind HEAD
> is, except the first time after HEAD changes. This also makes
> "branch -v" usable (for me) as it's now also instant versus 3.5
> seconds in non-cache case on my machine.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> I wanted guaranteed-fast status for another reason, but it turns out
> "branch -v" benefits even more. Recent commit walking is not
> efficiently optimized even with Shawn's pack bitmaps. This may be
> useful some people, I guess.
Not particularly interested in the cause, but not so strongly
against it to veto it.
The design looks questionable.
You can fork one or more branches off of a single branch. You may
fork your 'frotz' branch off of remotes/origin/master but also
another 'xyzzy' branch may be forked from the same.
I understand that you are trying to optimize, given two commit
object names X and Y, the cost to learn the symmetric distances
between them.
Doesn't it make more sense to use a notes-cache that is keyed off of
the commit object name X of the remote? You will have a single note
that stores a blob for the commit object remotes/origin/master, and
the blob tells you how far the commit at the tip of 'frotz' is from
it, and the same for 'xyzzy'.
You would obviouly need to run "gc" on such a notes-cache tree from
time to time, removing notes for commits that are not tip of any
branch that could be a fork point, and from the remaining notes
blobs, entries that describe commits that are not tip of any branch,
if you go that route.
>
> remote.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/remote.c b/remote.c
> index 04fd9ea..db825b8 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1549,6 +1549,7 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
> struct rev_info revs;
> const char *rev_argv[10], *base;
> int rev_argc;
> + int fd;
>
> /*
> * Nothing to report unless we are marked to build on top of
> @@ -1579,6 +1580,33 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
> if (theirs == ours)
> return 0;
>
> + if (!access(git_path("stat_tracking_cache/%s",
> + branch->refname), R_OK)) {
> + struct strbuf sb = STRBUF_INIT;
> + unsigned char sha1_ours[20], sha1_theirs[20];
> + int n1, n2;
> + if ((fd = open(git_path("stat_tracking_cache/%s",
> + branch->refname),
> + O_RDONLY)) != -1 &&
> + strbuf_read(&sb, fd, 0) != -1 &&
> + sb.len > (40 + 1) * 2 &&
> + !get_sha1_hex(sb.buf, sha1_ours) &&
> + sb.buf[40] == '\n' &&
> + !get_sha1_hex(sb.buf + 41, sha1_theirs) &&
> + sb.buf[81] == '\n' &&
> + !hashcmp(sha1_ours, ours->object.sha1) &&
> + !hashcmp(sha1_theirs, theirs->object.sha1) &&
> + sscanf(sb.buf + 82, "%d\n%d\n", &n1, &n2) == 2) {
> + *num_ours = n1;
> + *num_theirs = n2;
> + close(fd);
> + strbuf_release(&sb);
> + return 1;
> + }
> + close(fd);
> + strbuf_release(&sb);
> + }
> +
> /* Run "rev-list --left-right ours...theirs" internally... */
> rev_argc = 0;
> rev_argv[rev_argc++] = NULL;
> @@ -1608,6 +1636,20 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
> (*num_theirs)++;
> }
>
> + if (!safe_create_leading_directories(git_path("stat_tracking_cache/%s",
> + branch->refname)) &&
> + (fd = open(git_path("stat_tracking_cache/%s",
> + branch->refname),
> + O_CREAT | O_TRUNC | O_RDWR, 0644)) != -1) {
> + struct strbuf sb = STRBUF_INIT;
> + strbuf_addf(&sb, "%s\n", sha1_to_hex(ours->object.sha1));
> + strbuf_addf(&sb, "%s\n", sha1_to_hex(theirs->object.sha1));
> + strbuf_addf(&sb, "%d\n%d\n", *num_ours, *num_theirs);
> + write(fd, sb.buf, sb.len);
> + strbuf_release(&sb);
> + close(fd);
> + }
> +
> /* clear object flags smudged by the above traversal */
> clear_commit_marks(ours, ALL_REV_FLAGS);
> clear_commit_marks(theirs, ALL_REV_FLAGS);
^ permalink raw reply
* Re: Re: Git for Windows and line endings
From: Junio C Hamano @ 2012-10-19 17:22 UTC (permalink / raw)
To: Chris B; +Cc: Johannes Schindelin, Erik Faye-Lund, git, msysgit
In-Reply-To: <CADKp0pxuFsSEeZoeemyaqhSJEcsjj1arEOsF4Ub8=76y7tkwHg@mail.gmail.com>
Chris B <chris.blaszczynski@gmail.com> writes:
> - If there was SO MUCH thought into this, then it was too much...
I do not have much to add to what area experts already said on bits
specific to Git for Windows, but on just this part:
> - Our builds were not breaking, it was production due to deployment
> model utilizing Git. What if there was a process to extract from Git
> and then distribute?
Do you mean something like "git archive"? Or do you have something
else in mind?
> - Developers are not expecting revision control system to make changes
> to files they commit.
But isn't there a distinction between the logical content and its
physical representation? In source code (that is what developers
use a source code management system for), especially those of
cross-platform projects, the logical lines end with LF and physical
lines end with whatever is convenient on the platform of each
participant of the project. There needs a way to convert between
the two.
It does not sound fair to call it a crime if the port to a platform,
whose users (at least the majority of them) expect the latter to be
CRLF, chose to default to that to help the majority, as long as
there are ways for the minority power users to choose to use LF in
the physical representation on their working trees.
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: Fix potential hang in https handshake.
From: Daniel Stenberg @ 2012-10-19 17:08 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jeff King, Junio C Hamano, szager, git, sop
In-Reply-To: <CAJo=hJvWV0WPN5rCYK-JxfaEPWp7syUM1H0w4=Eb27=50+pXjg@mail.gmail.com>
On Fri, 19 Oct 2012, Shawn Pearce wrote:
> The issue with the current code is sometimes when libcurl is opening a
> CONNECT style connection through an HTTP proxy it returns a crazy high
> timeout (>240 seconds) and no fds. In this case Git waits forever.
Is this repeatable with a recent libcurl? It certainly sounds like a bug to
me, and I might be interested in giving a try at tracking it down...
--
/ daniel.haxx.se
^ permalink raw reply
* [PATCH] tree-walk: use enum interesting instead of integer
From: Nguyễn Thái Ngọc Duy @ 2012-10-19 17:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
Commit d688cf0 (tree_entry_interesting(): give meaningful names to
return values - 2011-10-24) converts most of the tree_entry_interesting
values to the new enum, except "never_interesting". This completes the
conversion.
---
tree-walk.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tree-walk.c b/tree-walk.c
index 0e49299..42fe610 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -490,11 +490,11 @@ int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned ch
static int match_entry(const struct name_entry *entry, int pathlen,
const char *match, int matchlen,
- int *never_interesting)
+ enum interesting *never_interesting)
{
int m = -1; /* signals that we haven't called strncmp() */
- if (*never_interesting) {
+ if (*never_interesting != entry_not_interesting) {
/*
* We have not seen any match that sorts later
* than the current path.
@@ -522,7 +522,7 @@ static int match_entry(const struct name_entry *entry, int pathlen,
* the variable to -1 and that is what will be
* returned, allowing the caller to terminate early.
*/
- *never_interesting = 0;
+ *never_interesting = entry_not_interesting;
}
if (pathlen > matchlen)
@@ -584,7 +584,7 @@ enum interesting tree_entry_interesting(const struct name_entry *entry,
{
int i;
int pathlen, baselen = base->len - base_offset;
- int never_interesting = ps->has_wildcard ?
+ enum interesting never_interesting = ps->has_wildcard ?
entry_not_interesting : all_entries_not_interesting;
if (!ps->nr) {
--
1.8.0.rc2.22.gad9383a
^ permalink raw reply related
* Re: Fix potential hang in https handshake.
From: Junio C Hamano @ 2012-10-19 17:02 UTC (permalink / raw)
To: Stefan Zager; +Cc: Shawn Pearce, git, Jeff King, sop
In-Reply-To: <CAHOQ7J9W8FdKqzqbuDqj4bcFyN02kUigWtbL_xCen-PYWF9LUg@mail.gmail.com>
Stefan Zager <szager@google.com> writes:
> On Oct 19, 2012 7:11 AM, "Shawn Pearce" <spearce@spearce.org> wrote:
>>
>> The issue with the current code is sometimes when libcurl is opening a
>> CONNECT style connection through an HTTP proxy it returns a crazy high
>> timeout (>240 seconds) and no fds. In this case Git waits forever.
>> Stefan observed that using a timeout of 50 ms in this situation to
>> poll libcurl is better, as it figures out a lot more quickly that it
>> is connected to the proxy and can issue the request.
>
> Correct. Anecdotally, the zero-file-descriptor situation happens only once
> per process invocation, so the risk of passing a too-long timeout to
> select() is small.
Thanks.
^ permalink raw reply
* Re: Unexpected directories from read-tree
From: Uri Moszkowicz @ 2012-10-19 16:10 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8BeMPwRtU9LQ9aS=0NY7vo_hXQs5Vxo9krXb+epqf=Fdw@mail.gmail.com>
I am using 1.8.0-rc2 but also tried 1.7.8.4. Thanks for the suggestion
to use "ls-files -t" - that's exactly what I was looking for. With
that I was easily able to tell what the problem is: missing "/" from
the sparse-checkout file.
On Thu, Oct 18, 2012 at 10:34 PM, Nguyen Thai Ngoc Duy
<pclouds@gmail.com> wrote:
> On Fri, Oct 19, 2012 at 6:10 AM, Uri Moszkowicz <uri@4refs.com> 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/" to sparse-checkout and read-tree
>> again I see dir2 and dir3 appear and they're not nested. If I replace
>> "dir2/" with "dir3/" in the sparse-checkout file, then I see dir1 and
>> dir3 but not dir2 as expected again. How can I debug this problem?
>
> Posting here is step 1. What version are you using? You can look at
> unpack-trees.c The function that does the check is excluded_from_list.
> You should check "ls-files -t", see if CE_SKIP_WORKTREE is set
> correctly for all dir1/*, dir2/* and dir3/*. Can you recreate a
> minimal test case for the problem?
> --
> Duy
^ permalink raw reply
* Re: [msysGit] Re: Git for Windows and line endings
From: Chris B @ 2012-10-19 14:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Erik Faye-Lund, git, msysgit
In-Reply-To: <alpine.DEB.1.00.1210190801490.2695@bonsai2>
Hi. I'm sorry about the tone of the email; I was writing it after
spending a lot of energy fixing things up and I should have taken some
time to breathe. I recognize this is likely not going to change and
even if I could jump in to contribute it wouldn't matter. I also
recognize that changing it now might cause more problems. I am hopeful
though.
I would like to point out:
- Git on Linux does not mess around with line endings. I can create
and edit a file in either line ending on Linux and commit and still
have it untouched.
- Git on Windows via Cygwin also does not mess around.
- If those flavors of Git don't mess around, why should msysgit do it?
- Windows has been able to cope with UNIX line endings a long time; no
developer is using a default Notepad to open files with high
expectations. Any Windows development tool and editor worth anything
I've used is able to handle both just fine.
- VIM also handles Windows line endings just fine as well. I just
tested it on a Linux machine. Maybe old version? (pure VI is not even
on this machine but hard to press these days it can't handle it.)
- The files in .git folder are in UNIX format anyway, so why are those
not also included in line ending changes? Isn't is because there is a
Windows app (msysgit) running on Windows that expects the UNIX line
ending? So in the same manor, someone might have a Windows system
using some Cygwin components perhaps, or a Windows C program possibly
poorly written or just old, that demand some text files to be left
alone in the format we saved it.
- If there was SO MUCH thought into this, then it was too much; it was
the wrong thought. There should not have been much at all, and just
allow Git to do what it does: store things *exactly* as you put it in.
Allow the clients to worry about things like line endings should they
have the need to worry about it. I'm not seeing how the revision
system has any business making alterations to things one commits into
it.
- Our builds were not breaking, it was production due to deployment
model utilizing Git. What if there was a process to extract from Git
and then distribute? Sounds like it's simple and should work and there
are good advantages to this process to overcome speed of deployment
issues. That process is free to be either Linux or Windows, and to
distribute to either a Linux or Windows server. This process you may
consider a mistake, but the point is that Git is just storing things,
not worried about the process in which it is used.
- While there might be options to make the other flavors of Git mess
around with line endings, the default is to not touch it which is
critical. Because as you bring on developers you never know what they
selected during the installation, and you have to go back and have
them change it if they did something different.
- Developers are not expecting revision control system to make changes
to files they commit.
^ permalink raw reply
* Re: Fix potential hang in https handshake.
From: Shawn Pearce @ 2012-10-19 14:10 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, szager, git, sop
In-Reply-To: <20121019103627.GA29366@sigill.intra.peff.net>
On Fri, Oct 19, 2012 at 3:36 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Oct 18, 2012 at 03:59:41PM -0700, Junio C Hamano wrote:
>
>> > It will sometimes happen that curl_multi_fdset() doesn't
>> > return any file descriptors. In that case, it's recommended
>> > that the application sleep for a short time before running
>> > curl_multi_perform() again.
>> >
>> > http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
>> >
>> > Signed-off-by: Stefan Zager <szager@google.com>
>> > ---
>>
>> Thanks. Would it be a better idea to "patch up" in problematic
>> case, instead of making this logic too deeply nested, like this
>> instead, I have to wonder...
>>
>>
>> ... all the existing code above unchanged ...
>> curl_multi_fdset(..., &max_fd);
>> + if (max_fd < 0) {
>> + /* nothing actionable??? */
>> + select_timeout.tv_sec = 0;
>> + select_timeout.tv_usec = 50000;
>> + }
>>
>> select(max_fd+1, ..., &select_timeout);
>
> But wouldn't that override a potentially shorter timeout that curl gave
> us via curl_multi_timeout, making us unnecessarily slow to hand control
> back to curl?
>
> The current logic is:
>
> - if curl says there is something to do now (timeout == 0), do it
> immediately
>
> - if curl gives us a timeout, use it with select
>
> - otherwise, feed 50ms to selection
>
> It should not matter what we get from curl_multi_fdset. If there are
> fds, great, we will feed them to select with the timeout, and we may
> break out early if there is work to do. If not, then we are already
> doing this wait.
>
> IOW, it seems like we are _already_ following the advice referenced in
> curl's manpage. Is there some case I am missing? Confused...
The issue with the current code is sometimes when libcurl is opening a
CONNECT style connection through an HTTP proxy it returns a crazy high
timeout (>240 seconds) and no fds. In this case Git waits forever.
Stefan observed that using a timeout of 50 ms in this situation to
poll libcurl is better, as it figures out a lot more quickly that it
is connected to the proxy and can issue the request.
^ permalink raw reply
* Re: [PATCH 0/2] gitk: fix --full-diff handling
From: Felipe Contreras @ 2012-10-19 13:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Paul Mackerras
In-Reply-To: <508151A0.3050505@viscovery.net>
On Fri, Oct 19, 2012 at 3:12 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 10/19/2012 12:56, schrieb Felipe Contreras:
>> I find usel to do 'git log --full-duff -- file' to find out all the commits
>> that touched the file, and show the full diff (not just the one of the file).
>>
>> Unfortunately gitk doesn't honour this option; the diff is limited in the UI.
>
> There is Edit->Preferences->General->Limit diff to listed paths. Doesn't
> it do what you want if you switch it off?
Hmm, I guess so, but it's not triggered from the command line. Maybe
the --full-diff option should enable that flag.
--
Felipe Contreras
^ permalink raw reply
* [DOCBUG] git subtree synopsis needs updating
From: Yann Dirson @ 2012-10-19 13:21 UTC (permalink / raw)
To: git list
As the examples in git-subtree.txt show, the synopsis in the same file should
surely get a patch along the lines of:
-'git subtree' add -P <prefix> <commit>
+'git subtree' add -P <prefix> <repository> <commit>
Failure to specify the repository (by just specifying a local commit) fails with
the cryptic:
warning: read-tree: emptying the index with no arguments is deprecated; use --empty
fatal: just how do you expect me to merge 0 trees?
Furthermore, the doc paragraph for add, aside from mentionning <repository>, also
mentions a <refspec> which the synopsis does not show either.
As a sidenote it someone wants to do some maintainance, using "." as repository when
the branch to subtree-add is already locally available does not work well either
(fails with "could not find ref myremote/myhead").
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: [PATCH 0/2] gitk: fix --full-diff handling
From: Johannes Sixt @ 2012-10-19 13:12 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Paul Mackerras
In-Reply-To: <1350644213-4882-1-git-send-email-felipe.contreras@gmail.com>
Am 10/19/2012 12:56, schrieb Felipe Contreras:
> I find usel to do 'git log --full-duff -- file' to find out all the commits
> that touched the file, and show the full diff (not just the one of the file).
>
> Unfortunately gitk doesn't honour this option; the diff is limited in the UI.
There is Edit->Preferences->General->Limit diff to listed paths. Doesn't
it do what you want if you switch it off?
-- Hannes
^ permalink raw reply
* [PATCH 2/2] gitk: handle --full-diff correctly
From: Felipe Contreras @ 2012-10-19 10:56 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Felipe Contreras
In-Reply-To: <1350644213-4882-1-git-send-email-felipe.contreras@gmail.com>
Otherwise the files are missing from the diff, and the list of files.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
gitk-git/gitk | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index b79dfdf..8109eed 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -155,7 +155,7 @@ proc unmerged_files {files} {
}
proc parseviewargs {n arglist} {
- global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
+ global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs vfileargs env
global worddiff git_version
set vdatemode($n) 0
@@ -165,6 +165,7 @@ proc parseviewargs {n arglist} {
set nextisval 0
set revargs {}
set origargs $arglist
+ set fileargs {}
set allknown 1
set filtered 0
set i -1
@@ -187,7 +188,7 @@ proc parseviewargs {n arglist} {
"--no-renames" - "--full-index" - "--binary" - "--abbrev=*" -
"--find-copies-harder" - "-l*" - "--ext-diff" - "--no-ext-diff" -
"--src-prefix=*" - "--dst-prefix=*" - "--no-prefix" -
- "-O*" - "--text" - "--full-diff" - "--ignore-space-at-eol" -
+ "-O*" - "--text" - "--ignore-space-at-eol" -
"--ignore-space-change" - "-U*" - "--unified=*" {
# These request or affect diff output, which we don't want.
# Some could be used to set our defaults for diff display.
@@ -233,6 +234,9 @@ proc parseviewargs {n arglist} {
set filtered 1
lappend glflags $arg
}
+ "--full-diff" {
+ lappend fileargs $arg
+ }
"-n" {
# This appears to be the only one that has a value as a
# separate word following it
@@ -276,6 +280,7 @@ proc parseviewargs {n arglist} {
set vrevs($n) $revargs
set vfiltered($n) $filtered
set vorigargs($n) $origargs
+ set vfileargs($n) $fileargs
return $allknown
}
@@ -7519,10 +7524,11 @@ proc diffcmd {ids flags} {
}
proc gettreediffs {ids} {
- global treediff treepending limitdiffs vfilelimit curview
+ global treediff treepending limitdiffs vfilelimit vfileargs curview
set cmd [diffcmd $ids {--no-commit-id}]
if {$limitdiffs && $vfilelimit($curview) ne {}} {
+ set cmd [concat $cmd $vfileargs($curview)]
set cmd [concat $cmd -- $vfilelimit($curview)]
}
if {[catch {set gdtf [open $cmd r]}]} return
@@ -7613,7 +7619,7 @@ proc getblobdiffs {ids} {
global diffcontext
global ignorespace
global worddiff
- global limitdiffs vfilelimit curview
+ global limitdiffs vfilelimit vfileargs curview
global diffencoding targetline diffnparents
global git_version currdiffsubmod
@@ -7633,6 +7639,7 @@ proc getblobdiffs {ids} {
append cmd " --word-diff=porcelain"
}
if {$limitdiffs && $vfilelimit($curview) ne {}} {
+ set cmd [concat $cmd $vfileargs($curview)]
set cmd [concat $cmd -- $vfilelimit($curview)]
}
if {[catch {set bdf [open $cmd r]} err]} {
--
1.8.0.rc2.7.g0961fdf.dirty
^ permalink raw reply related
* [PATCH 1/2] gitk: simplify file filtering
From: Felipe Contreras @ 2012-10-19 10:56 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Felipe Contreras
In-Reply-To: <1350644213-4882-1-git-send-email-felipe.contreras@gmail.com>
git diff is perfectly able to do this with '-- files', no need for
manual filtering.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
gitk-git/gitk | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..b79dfdf 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7519,9 +7519,13 @@ proc diffcmd {ids flags} {
}
proc gettreediffs {ids} {
- global treediff treepending
+ global treediff treepending limitdiffs vfilelimit curview
- if {[catch {set gdtf [open [diffcmd $ids {--no-commit-id}] r]}]} return
+ set cmd [diffcmd $ids {--no-commit-id}]
+ if {$limitdiffs && $vfilelimit($curview) ne {}} {
+ set cmd [concat $cmd -- $vfilelimit($curview)]
+ }
+ if {[catch {set gdtf [open $cmd r]}]} return
set treepending $ids
set treediff {}
@@ -7565,17 +7569,7 @@ proc gettreediffline {gdtf ids} {
return [expr {$nr >= $max? 2: 1}]
}
close $gdtf
- if {$limitdiffs && $vfilelimit($curview) ne {}} {
- set flist {}
- foreach f $treediff {
- if {[path_filter $vfilelimit($curview) $f]} {
- lappend flist $f
- }
- }
- set treediffs($ids) $flist
- } else {
- set treediffs($ids) $treediff
- }
+ set treediffs($ids) $treediff
unset treepending
if {$cmitmode eq "tree" && [llength $diffids] == 1} {
gettree $diffids
--
1.8.0.rc2.7.g0961fdf.dirty
^ permalink raw reply related
* [PATCH 0/2] gitk: fix --full-diff handling
From: Felipe Contreras @ 2012-10-19 10:56 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Felipe Contreras
Hi,
I find usel to do 'git log --full-duff -- file' to find out all the commits
that touched the file, and show the full diff (not just the one of the file).
Unfortunately gitk doesn't honour this option; the diff is limited in the UI.
The following patches fix that.
Felipe Contreras (2):
gitk: simplify file filtering
gitk: handle --full-diff correctly
gitk-git/gitk | 33 +++++++++++++++++----------------
1 file changed, 17 insertions(+), 16 deletions(-)
--
1.8.0.rc2.7.g0961fdf.dirty
^ permalink raw reply
* Re: Fix potential hang in https handshake.
From: Jeff King @ 2012-10-19 10:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: szager, git, sop
In-Reply-To: <7vd30fl736.fsf@alter.siamese.dyndns.org>
On Thu, Oct 18, 2012 at 03:59:41PM -0700, Junio C Hamano wrote:
> > It will sometimes happen that curl_multi_fdset() doesn't
> > return any file descriptors. In that case, it's recommended
> > that the application sleep for a short time before running
> > curl_multi_perform() again.
> >
> > http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
> >
> > Signed-off-by: Stefan Zager <szager@google.com>
> > ---
>
> Thanks. Would it be a better idea to "patch up" in problematic
> case, instead of making this logic too deeply nested, like this
> instead, I have to wonder...
>
>
> ... all the existing code above unchanged ...
> curl_multi_fdset(..., &max_fd);
> + if (max_fd < 0) {
> + /* nothing actionable??? */
> + select_timeout.tv_sec = 0;
> + select_timeout.tv_usec = 50000;
> + }
>
> select(max_fd+1, ..., &select_timeout);
But wouldn't that override a potentially shorter timeout that curl gave
us via curl_multi_timeout, making us unnecessarily slow to hand control
back to curl?
The current logic is:
- if curl says there is something to do now (timeout == 0), do it
immediately
- if curl gives us a timeout, use it with select
- otherwise, feed 50ms to selection
It should not matter what we get from curl_multi_fdset. If there are
fds, great, we will feed them to select with the timeout, and we may
break out early if there is work to do. If not, then we are already
doing this wait.
IOW, it seems like we are _already_ following the advice referenced in
curl's manpage. Is there some case I am missing? Confused...
-Peff
^ permalink raw reply
* Re: Re: Git for Windows and line endings
From: Johannes Schindelin @ 2012-10-19 6:09 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Chris B, git, msysgit
In-Reply-To: <CABPQNSZE7TP0G-uW1b1nbsNgpxYCEiD5KefS62GB5gZbWyZXDQ@mail.gmail.com>
Hi,
On Fri, 19 Oct 2012, Erik Faye-Lund wrote:
> On Fri, Oct 19, 2012 at 12:13 AM, Chris B <chris.blaszczynski@gmail.com> wrote:
> > Hi.. it is such a crime to have that default option of MSysGit mess
> > around with the line endings.
>
> No it's not.
Let's keep things professional. Eliciting emotions, especially negative
ones, traditionally makes it more unlikely to get what one asks for.
Also to clarify: as so many Open Source projects (but unlike Git itself),
msysGit is a purely volunteer-driven software. So naturally, contributors
have a lot more to say about the defaults than non-contributors [*1*].
Besides, there is a fantastic and very detailed page when running the
installer where the interested user can inform herself and change the
defaults to her likings very easily.
Therefore I consider this bug report -- insofar it was one -- as closed.
Ciao,
Johannes
Footnote [*1*]: And yes, the line endings default was changed from this
developer's preference to what it is now -- based on a discussion with
convincing arguments. Since msysGit is developed as an Open Source project
with a truly Open Source process, all of these discussions can be found in
the mailing list archives.
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: fatal: cannot convert from utf8 to UTF-8
From: Junio C Hamano @ 2012-10-19 5:50 UTC (permalink / raw)
To: Cristian Tibirna; +Cc: git
In-Reply-To: <1532361.Y42DjGJIX1@leto>
Cristian Tibirna <ctibirna@giref.ulaval.ca> writes:
> This error:
>
> fatal: cannot convert from utf8 to UTF-8
> ...
> This is in part our fault: during the standardisation of our git environment,
> we (re)enforced UTF-8 encodings by setting "i18n.commitenconding" and
> "i18n.logOutputEncoding" to "utf8".
> ...
> I know "utf8" is not an accepted denomination ("UTF-8" or "utf-8" should be
> used, according to IANA standards),...
Perhaps like this.
-- >8 --
Subject: [PATCH] reencode_string(): introduce and use same_encoding()
Callers of reencode_string() that re-encodes a string from one
encoding to another all used ad-hoc way to bypass the case where the
input and the output encodings are the same. Some did strcmp(),
some did strcasecmp(), yet some others when converting to UTF-8 used
is_encoding_utf8().
Introduce same_encoding() helper function to make these callers
use the same logic. Notably, is_encoding_utf8() has a work-around
for common misconfiguration to use "utf8" to name UTF-8 encoding,
which does not match "UTF-8" hence strcasecmp() would not consider
the same. Make use of it in this helper function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/mailinfo.c | 2 +-
notes.c | 2 +-
pretty.c | 2 +-
sequencer.c | 2 +-
utf8.c | 7 +++++++
utf8.h | 1 +
6 files changed, 12 insertions(+), 4 deletions(-)
diff --git c/builtin/mailinfo.c w/builtin/mailinfo.c
index da23140..e4e39d6 100644
--- c/builtin/mailinfo.c
+++ w/builtin/mailinfo.c
@@ -483,7 +483,7 @@ static void convert_to_utf8(struct strbuf *line, const char *charset)
if (!charset || !*charset)
return;
- if (!strcasecmp(metainfo_charset, charset))
+ if (same_encoding(metainfo_charset, charset))
return;
out = reencode_string(line->buf, metainfo_charset, charset);
if (!out)
diff --git c/notes.c w/notes.c
index bc454e1..ee8f01f 100644
--- c/notes.c
+++ w/notes.c
@@ -1231,7 +1231,7 @@ static void format_note(struct notes_tree *t, const unsigned char *object_sha1,
}
if (output_encoding && *output_encoding &&
- strcmp(utf8, output_encoding)) {
+ !is_encoding_utf8(output_encoding)) {
char *reencoded = reencode_string(msg, output_encoding, utf8);
if (reencoded) {
free(msg);
diff --git c/pretty.c w/pretty.c
index 8b1ea9f..e87fe9f 100644
--- c/pretty.c
+++ w/pretty.c
@@ -504,7 +504,7 @@ char *logmsg_reencode(const struct commit *commit,
return NULL;
encoding = get_header(commit, "encoding");
use_encoding = encoding ? encoding : utf8;
- if (!strcmp(use_encoding, output_encoding))
+ if (same_encoding(use_encoding, output_encoding))
if (encoding) /* we'll strip encoding header later */
out = xstrdup(commit->buffer);
else
diff --git c/sequencer.c w/sequencer.c
index e3723d2..73c396b 100644
--- c/sequencer.c
+++ w/sequencer.c
@@ -60,7 +60,7 @@ static int get_message(struct commit *commit, struct commit_message *out)
out->reencoded_message = NULL;
out->message = commit->buffer;
- if (strcmp(encoding, git_commit_encoding))
+ if (same_encoding(encoding, git_commit_encoding))
out->reencoded_message = reencode_string(commit->buffer,
git_commit_encoding, encoding);
if (out->reencoded_message)
diff --git c/utf8.c w/utf8.c
index a544f15..6a52834 100644
--- c/utf8.c
+++ w/utf8.c
@@ -423,6 +423,13 @@ int is_encoding_utf8(const char *name)
return 0;
}
+int same_encoding(const char *src, const char *dst)
+{
+ if (is_encoding_utf8(src) && is_encoding_utf8(dst))
+ return 1;
+ return !strcasecmp(src, dst);
+}
+
/*
* Given a buffer and its encoding, return it re-encoded
* with iconv. If the conversion fails, returns NULL.
diff --git c/utf8.h w/utf8.h
index 3c0ae76..93ef600 100644
--- c/utf8.h
+++ w/utf8.h
@@ -7,6 +7,7 @@ int utf8_width(const char **start, size_t *remainder_p);
int utf8_strwidth(const char *string);
int is_utf8(const char *text);
int is_encoding_utf8(const char *name);
+int same_encoding(const char *, const char *);
int strbuf_add_wrapped_text(struct strbuf *buf,
const char *text, int indent, int indent2, int width);
^ permalink raw reply related
* Re: libgit2 status
From: Ramkumar Ramachandra @ 2012-10-19 3:54 UTC (permalink / raw)
To: Thiago Farina
Cc: Junio C Hamano, git, dag, Nicolas Sebrecht, Andreas Ericsson,
greened
In-Reply-To: <CACnwZYe6BZVuqCCPho5+3dy=rzKqDv1A8uGAvhLm2JPO9b2LMw@mail.gmail.com>
Thiago Farina wrote:
> [...]
> With some structure like:
>
> include/git.h
> src/git.c
>
> ...
>
> whatever.
> [...]
Junio- is it reasonable to expect the directory-restructuring by 2.0?
Ram
^ permalink raw reply
* Re: Unexpected directories from read-tree
From: Nguyen Thai Ngoc Duy @ 2012-10-19 3:34 UTC (permalink / raw)
To: Uri Moszkowicz; +Cc: git
In-Reply-To: <CAMJd5AQhcvWVwsZHPknAXvNpqnfqdCtx-xUv39Au1=x-1_ExMg@mail.gmail.com>
On Fri, Oct 19, 2012 at 6:10 AM, Uri Moszkowicz <uri@4refs.com> 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/" to sparse-checkout and read-tree
> again I see dir2 and dir3 appear and they're not nested. If I replace
> "dir2/" with "dir3/" in the sparse-checkout file, then I see dir1 and
> dir3 but not dir2 as expected again. How can I debug this problem?
Posting here is step 1. What version are you using? You can look at
unpack-trees.c The function that does the check is excluded_from_list.
You should check "ls-files -t", see if CE_SKIP_WORKTREE is set
correctly for all dir1/*, dir2/* and dir3/*. Can you recreate a
minimal test case for the problem?
--
Duy
^ permalink raw reply
* fatal: cannot convert from utf8 to UTF-8
From: Cristian Tibirna @ 2012-10-19 0:03 UTC (permalink / raw)
To: git
This error:
fatal: cannot convert from utf8 to UTF-8
occured in two distinct situations in our work group with git binaries older
or equal to 1.7.7. Once during a commit, the other time during a rebase. Both
occurences are 100% reproductible. But the commit that gives the error during
a rebase doesn't do so in a cherry-pick.
This is in part our fault: during the standardisation of our git environment,
we (re)enforced UTF-8 encodings by setting "i18n.commitenconding" and
"i18n.logOutputEncoding" to "utf8".
It is the "i18n.logOutputEncoding = utf8" that *sometimes* triggers the error
above.
I know "utf8" is not an accepted denomination ("UTF-8" or "utf-8" should be
used, according to IANA standards), but we have attenuating circumstances in
the fact that most things dealing with encoding accept the erroneous name.
That includes at least iconv(1) and python(1). Thus we ignored that a
distinction existed and, as self-respecting lazy typers, we preferred the (one
touch) shorter version.
I wonder if it should be expected that git accepts these name variants ("utf8"
and "UTF8") as valid and equivalent to the standard ones.
Of course it is very easy for us to work around the error, since setting
"i18n.logOutputEncoding = utf-8" or removing it altogether from the git config
file chases the error away. It's only that these kinds of things are bound to
happen and for a good proportion of git users it might be well opaque,
difficult to fix and, in drastic (user ignorance-induced) cases, a
showstopper.
Thanks for listening.
--
Cristian Tibirna (418) 656-2131 / 4340
Laval University - Québec, CAN ... http://www.giref.ulaval.ca/~ctibirna
Research professional - GIREF ... ctibirna@giref.ulaval.ca
^ permalink raw reply
* Re: libgit2 status
From: Thiago Farina @ 2012-10-19 0:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, dag, Nicolas Sebrecht, Andreas Ericsson, greened
In-Reply-To: <7vvcg2zwvq.fsf@alter.siamese.dyndns.org>
Just an addendum, the libfication would come from within the core git
developers, i.e, they start making the git library inside git itself.
The git project would provide the API, not an external project.
With some structure like:
include/git.h
src/git.c
...
whatever.
And doing the way Jeff did with argv_array for example and with rigid
style guide defining how new APIs should be written. Just my 2 cents.
Don't take it to seriously.
^ permalink raw reply
* Re: Fix potential hang in https handshake (v2).
From: Junio C Hamano @ 2012-10-19 0:37 UTC (permalink / raw)
To: szager; +Cc: git, sop
In-Reply-To: <7v8vb3l2q5.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> We end up calling select() without any bit set in fds, so it would
> become micro-sleep of select_timeout in such a case, but as far as I
> can see, the existing code either
>
> * does not select() and keeps polling step_active_slots() without
> delay, when curl_timeout gives a 0 return value; or
>
> * sets 50ms timeout or whatever negative value derived from
> curl_timeout when the returned value is not 0 nor -1.
>
> Is the symptom that select(), when given a negative timeout and no
> fd to wake it, sleeps forever (or "loooong time, taking that negative
> value as if it is a large unsigned long") or something?
Addendum.
What I am trying to get at are (1) three line description I can put
in the release notes for this fix when it is merged to the
maintenance track, and (2) a feel of how often this happens and how
bad the damage is.
The latter helps us judge if this "do the normal thing, but if in a
rare case where we do not find any fds, patch it up to proceed" is a
better approach over your original.
Thanks.
^ permalink raw reply
* A design for distributed submodules
From: Lauri Alanko @ 2012-10-19 0:31 UTC (permalink / raw)
To: git
In-Reply-To: <7v4nlxylpm.fsf@alter.siamese.dyndns.org>
I think I finally agree that it's best to develop submodules further
rather than introduce a new tool for the functionality I require. Here
are some explicit proposals for submodules so we can at least establish
agreement on what should be done. These are in order of decreasing
importance (to me).
* Upstreamless submodules
If there is no 'url' key defined for a submodule in .gitconfig, there is
no "authoritative upstream" for it. When a recursive
fetch/pull/clone/push is performed on a remote superproject, its
upstreamless submodules are also fetched/pulled/cloned/pushed directly
from/to the submodule repositories under the superproject .git/modules.
If this is the first time that remote's submodules are accessed, that
remote is initialized for the local submodules: the submodule of the
remote superproject becomes a remote of the local submodule, and is
given the same name as the remote of the superproject.
So, suppose we have a superproject with .gitmodules:
[submodule "sub"]
path = sub
which is hosted at repositories at URL1 and URL2. Then we do:
git clone --recursive URL1 super
cd super
git remote add other URL2
git fetch --recursive URL2
Now .git/modules/sub/config has:
[remote "origin"]
url = URL1/.git/modules/sub
[remote "other"]
url = URL2/.git/modules/sub
So the effect is similar to just setting the submodule's url as
".git/modules/sub", except that:
- it hides the implementation detail of the exact location of the
submodule repository from the publicly visible configuration file
- it also works with bare remotes (where the actual remote submodule
location would be URL/modules/sub)
- it allows multiple simultaneous superproject remotes (where
git-submodule currently always resolves relative urls against
branch.$branch.remote with no option to fetch from a different
remote).
* Submodule discovery across all refs
This is what Jens already mentioned. If we fetch multiple refs of a
remote superproject, we also need to fetch _all_ of the submodules
referenced by _any_ of the refs, not just the ones in the currently
active branch. Finding the complete list of submodules probably has to
be implemented by reading .gitmodules in all of the (updated) refs,
which is a bit ugly, but not too bad.
* Recording the active branch of a submodule
When a submodule is added, its active branch should be stored in
.gitmodules as submodule.$sub.branch. Then, when the submodule is
checked out, and the head of that branch is the same as the commit in
the gitlink (i.e. the superproject tree is "current"), then that branch
is set as the active branch in the checked-out submodule working tree.
Otherwise, a detached head is used.
* Multiple working trees for a submodule
A superproject may have multiple paths for the same submodule,
presumably for different commits. This is for cases where the
superproject is a snapshot of a developer's directory hierarchy, and the
developer is simultaneously working on multiple branches of a submodule
and it is convenient to have separate working trees for each of them.
This is a bit hard to express with the current .gitconfig format, since
paths are attributes of repository ids instead of vice versa. I'd
introduce an alternative section format where you can say:
[mount "path1"]
module = sub
branch = master
[mount "path2"]
module = sub
branch = topic
Implementing this is a bit intricate, since we need to use the
git-new-workdir method to create multiple working directories that share
the same refs, config, and object store, but have separate HEAD and
index. I think this is a problem with the repository layout: the
non-workdir-specific bits should all be in a single directory so that a
single symlink would be enough.
Obviously, I'm willing to implement the above functionalities since I
need them. However, I think I'm going to work in Dulwich (which doesn't
currently have any submodule support): a Python API is currently more
important to me than a command-line tool, and the git.git codebase
doesn't look like a very attractive place to contribute anyway. No
offense, it's just not to my tastes.
So the main reason I'd like to reach some tentative agreement about the
details of the proposal is to ensure that _once_ someone finally
implements this kind of functionality in git.git, it will use the same
configuration format and same conventions, so that it will be compatible
with my code. The compatibility between different tools is after all the
main reason for doing this stuff as an extension to submodules instead
of something completely different.
Lauri
^ permalink raw reply
* Re: Fix potential hang in https handshake (v2).
From: Junio C Hamano @ 2012-10-19 0:33 UTC (permalink / raw)
To: szager; +Cc: git, sop
In-Reply-To: <5080906b.xT6aRtW1ELoWhZZw%szager@google.com>
szager@google.com writes:
> From aa77ab3dd5b98a5786ac158528f45355fc0ddbc3 Mon Sep 17 00:00:00 2001
> From: Stefan Zager <szager@google.com>
> Date: Thu, 18 Oct 2012 16:23:53 -0700
> Subject: [PATCH] Fix potential hang in https handshake.
Please don't do the above (as usual ;-)
> It will sometimes happen that curl_multi_fdset() doesn't
> return any file descriptors. In that case, it's recommended
> that the application sleep for a short time before running
> curl_multi_perform() again.
>
> http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
>
> Signed-off-by: Stefan Zager <szager@google.com>
> ---
The above sounds like "the code is doing something against a
recommended practice", but is there a user-visible symptom due to
this?
We end up calling select() without any bit set in fds, so it would
become micro-sleep of select_timeout in such a case, but as far as I
can see, the existing code either
* does not select() and keeps polling step_active_slots() without
delay, when curl_timeout gives a 0 return value; or
* sets 50ms timeout or whatever negative value derived from
curl_timeout when the returned value is not 0 nor -1.
Is the symptom that select(), when given a negative timeout and no
fd to wake it, sleeps forever (or "loooong time, taking that negative
value as if it is a large unsigned long") or something?
Thanks.
> http.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/http.c b/http.c
> index df9bb71..e8aba7f 100644
> --- a/http.c
> +++ b/http.c
> @@ -630,6 +630,10 @@ void run_active_slot(struct active_request_slot *slot)
> FD_ZERO(&writefds);
> FD_ZERO(&excfds);
> curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
> + if (max_fd < 0) {
> + select_timeout.tv_sec = 0;
> + select_timeout.tv_usec = 50000;
> + }
>
> select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
> }
^ permalink raw reply
* Fix potential hang in https handshake (v2).
From: szager @ 2012-10-18 23:27 UTC (permalink / raw)
To: git; +Cc: gitster, sop
>From aa77ab3dd5b98a5786ac158528f45355fc0ddbc3 Mon Sep 17 00:00:00 2001
From: Stefan Zager <szager@google.com>
Date: Thu, 18 Oct 2012 16:23:53 -0700
Subject: [PATCH] Fix potential hang in https handshake.
It will sometimes happen that curl_multi_fdset() doesn't
return any file descriptors. In that case, it's recommended
that the application sleep for a short time before running
curl_multi_perform() again.
http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
Signed-off-by: Stefan Zager <szager@google.com>
---
http.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c
index df9bb71..e8aba7f 100644
--- a/http.c
+++ b/http.c
@@ -630,6 +630,10 @@ void run_active_slot(struct active_request_slot *slot)
FD_ZERO(&writefds);
FD_ZERO(&excfds);
curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
+ if (max_fd < 0) {
+ select_timeout.tv_sec = 0;
+ select_timeout.tv_usec = 50000;
+ }
select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
}
--
1.7.7.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox