* [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
* Unexpected directories from read-tree
From: Uri Moszkowicz @ 2012-10-18 23:10 UTC (permalink / raw)
To: git
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?
^ permalink raw reply
* git subtree error (just how do you expect me to merge 0 trees?)
From: Drew Crawford @ 2012-10-18 23:04 UTC (permalink / raw)
To: git@vger.kernel.org
I noticed today that if you leave off the branch name from git subtree like so:
$ git subtree add --prefix somewhere -m "adding CDH as subtree" path/to/repo
warning: read-tree: emptying the index with no arguments is deprecated; use --empty
fatal: just how do you expect me to merge 0 trees?
The error message is not particularly helpful (and seems to actually be in read-subtree?) The solution in my case was to add the branch name on the end of the command.
Ideally it would be better to emit an error-message from a script higher up the calling chain that would be more descriptive about the problem (such as suggesting no branch is specified).
^ permalink raw reply
* Re: Fix potential hang in https handshake.
From: Junio C Hamano @ 2012-10-18 22:59 UTC (permalink / raw)
To: szager; +Cc: git, sop
In-Reply-To: <5080761e.IEDySUuQzlCwL6fM%szager@google.com>
szager@google.com writes:
> From 700b8075c578941c8f951711825c390ac68b190f Mon Sep 17 00:00:00 2001
> From: Stefan Zager <szager@google.com>
> Date: Thu, 18 Oct 2012 14:03:59 -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>
> ---
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);
> http.c | 40 ++++++++++++++++++++++++++--------------
> 1 files changed, 26 insertions(+), 14 deletions(-)
>
> diff --git a/http.c b/http.c
> index df9bb71..a6f66c0 100644
> --- a/http.c
> +++ b/http.c
> @@ -602,35 +602,47 @@ void run_active_slot(struct active_request_slot *slot)
> int max_fd;
> struct timeval select_timeout;
> int finished = 0;
> + long curl_timeout;
>
> slot->finished = &finished;
> while (!finished) {
> step_active_slots();
>
> if (slot->in_use) {
> + max_fd = -1;
> + FD_ZERO(&readfds);
> + FD_ZERO(&writefds);
> + FD_ZERO(&excfds);
> + curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
> +
> #if LIBCURL_VERSION_NUM >= 0x070f04
> - long curl_timeout;
> - curl_multi_timeout(curlm, &curl_timeout);
> - if (curl_timeout == 0) {
> - continue;
> - } else if (curl_timeout == -1) {
> + /* 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
> + */
> + if (max_fd == -1) {
> select_timeout.tv_sec = 0;
> select_timeout.tv_usec = 50000;
> } else {
> - select_timeout.tv_sec = curl_timeout / 1000;
> - select_timeout.tv_usec = (curl_timeout % 1000) * 1000;
> + curl_timeout = 0;
> + curl_multi_timeout(curlm, &curl_timeout);
> + if (curl_timeout == 0) {
> + continue;
> + } else if (curl_timeout == -1) {
> + select_timeout.tv_sec = 0;
> + select_timeout.tv_usec = 50000;
> + } else {
> + select_timeout.tv_sec = curl_timeout / 1000;
> + select_timeout.tv_usec = (curl_timeout % 1000) * 1000;
> + }
> }
> #else
> select_timeout.tv_sec = 0;
> select_timeout.tv_usec = 50000;
> #endif
> -
> - max_fd = -1;
> - FD_ZERO(&readfds);
> - FD_ZERO(&writefds);
> - FD_ZERO(&excfds);
> - curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
> -
> select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
> }
> }
^ permalink raw reply
* [PATCH] Documentation/fetch-options.txt: Clarify --prune with option --tags
From: jari.aalto @ 2012-10-18 22:41 UTC (permalink / raw)
To: git; +Cc: Jari Aalto
From: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/fetch-options.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index b4d6476..90d50fb 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -38,7 +38,8 @@ ifndef::git-pull[]
-p::
--prune::
After fetching, remove any remote-tracking branches which
- no longer exist on the remote.
+ no longer exist on the remote. If used with option `--tags`,
+ remove tags in a similar manner.
endif::git-pull[]
ifdef::git-pull[]
--
1.7.10.4
^ permalink raw reply related
* Re: Git for Windows and line endings
From: Erik Faye-Lund @ 2012-10-18 22:40 UTC (permalink / raw)
To: Chris B; +Cc: git, msysgit
In-Reply-To: <CADKp0pyy=Nnv29LyhzAOX4B5wJNYnZ0h5d7zxNRyZxV2OGUSjg@mail.gmail.com>
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.
> There is no thought to the fact that it's possible the Git users are
> not using Git the exact way the authors thought it would be used.
Suggesting this is just insulting. A lot of thought was laid to ground
for the decision.
> We have both Windows and Linux systems that have parts of their files
> stored in Git repositories. And in addition to that, some Linux and
> Windows Git clients. If everyone leaves the line endings alone,
> everything works out just fine!
No, it will not. Notepad, which is the default text editor on Windows,
barfs on LF line-endings, and many vi installations does the same
thing on Unix-systems bards on CRLF line-endings. And so does a huge
amount of custom, less tested tools.
Thinking that "this works for me, so it must work for everyone" is
exactly the reason why this whole situation is a big mess. You are
only making it worse by not realizing the issues.
> But messing with the line endings broke some things in production.
I'm not even sure what you're trying to say with this e-mail other
than to blame us for your own problems. Stop making broken commits.
Clean up after you when you did by accident. And for the love of God,
stop blaming other people when you messed up.
--
*** 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
* Git for Windows and line endings
From: Chris B @ 2012-10-18 22:13 UTC (permalink / raw)
To: git, msysgit
Hi.. it is such a crime to have that default option of MSysGit mess
around with the line endings.
Caused us a lot of trouble.
There is no thought to the fact that it's possible the Git users are
not using Git the exact way the authors thought it would be used.
We have both Windows and Linux systems that have parts of their files
stored in Git repositories. And in addition to that, some Linux and
Windows Git clients. If everyone leaves the line endings alone,
everything works out just fine!
But messing with the line endings broke some things in production.
^ permalink raw reply
* Re: [PATCH 6/6] format-patch --notes: show notes after three-dashes
From: Junio C Hamano @ 2012-10-18 22:08 UTC (permalink / raw)
To: Philip Oakley; +Cc: git
In-Reply-To: <C2D3CE0879B345FFAC2A6487760B5378@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> From: "Junio C Hamano" <gitster@pobox.com>
>> When inserting the note after the commit log message to format-patch
>> output, add three dashes before the note. Record the fact that we
>> did so in the rev_info and omit showing duplicated three dashes in
>> the usual codepath that is used when notes are not being shown.
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Should this also include a documentation update to make this
> substantive benefit visible, whether that be in the format-patch man
> pages, the SubmittingPatches guide, in the git-notes description of 'A
> typical use...', or even in the user-manual?
Eric Blake (http://mid.gmane.org/507EB310.8020904@redhat.com) was
already working on a documentation updates already, I thought.
As long as what it does is explained in format-patch, that is fine.
I do not think this deserves to be in the SubmittingPatches. We do
tell people to hide "here is the context of the change" additional
explanation after three dashes, but how the submitters prepare that
text is entirely up to them (and I personally do not think notes is
not necessarily the right tool to do so).
^ permalink raw reply
* Fix potential hang in https handshake.
From: szager @ 2012-10-18 21:35 UTC (permalink / raw)
To: git; +Cc: gitster, sop
>From 700b8075c578941c8f951711825c390ac68b190f Mon Sep 17 00:00:00 2001
From: Stefan Zager <szager@google.com>
Date: Thu, 18 Oct 2012 14:03:59 -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 | 40 ++++++++++++++++++++++++++--------------
1 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/http.c b/http.c
index df9bb71..a6f66c0 100644
--- a/http.c
+++ b/http.c
@@ -602,35 +602,47 @@ void run_active_slot(struct active_request_slot *slot)
int max_fd;
struct timeval select_timeout;
int finished = 0;
+ long curl_timeout;
slot->finished = &finished;
while (!finished) {
step_active_slots();
if (slot->in_use) {
+ max_fd = -1;
+ FD_ZERO(&readfds);
+ FD_ZERO(&writefds);
+ FD_ZERO(&excfds);
+ curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
+
#if LIBCURL_VERSION_NUM >= 0x070f04
- long curl_timeout;
- curl_multi_timeout(curlm, &curl_timeout);
- if (curl_timeout == 0) {
- continue;
- } else if (curl_timeout == -1) {
+ /* 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
+ */
+ if (max_fd == -1) {
select_timeout.tv_sec = 0;
select_timeout.tv_usec = 50000;
} else {
- select_timeout.tv_sec = curl_timeout / 1000;
- select_timeout.tv_usec = (curl_timeout % 1000) * 1000;
+ curl_timeout = 0;
+ curl_multi_timeout(curlm, &curl_timeout);
+ if (curl_timeout == 0) {
+ continue;
+ } else if (curl_timeout == -1) {
+ select_timeout.tv_sec = 0;
+ select_timeout.tv_usec = 50000;
+ } else {
+ select_timeout.tv_sec = curl_timeout / 1000;
+ select_timeout.tv_usec = (curl_timeout % 1000) * 1000;
+ }
}
#else
select_timeout.tv_sec = 0;
select_timeout.tv_usec = 50000;
#endif
-
- max_fd = -1;
- FD_ZERO(&readfds);
- FD_ZERO(&writefds);
- FD_ZERO(&excfds);
- curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
-
select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
}
}
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH 6/6] format-patch --notes: show notes after three-dashes
From: Philip Oakley @ 2012-10-18 21:35 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <1350539128-21577-7-git-send-email-gitster@pobox.com>
From: "Junio C Hamano" <gitster@pobox.com>
> When inserting the note after the commit log message to format-patch
> output, add three dashes before the note. Record the fact that we
> did so in the rev_info and omit showing duplicated three dashes in
> the usual codepath that is used when notes are not being shown.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Should this also include a documentation update to make this substantive
benefit visible, whether that be in the format-patch man pages, the
SubmittingPatches guide, in the git-notes description of 'A typical
use...', or even in the user-manual?
Do you have a preference?
> ---
> log-tree.c | 15 +++++++++++----
> revision.h | 1 +
> t/t4014-format-patch.sh | 7 +++++--
> 3 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/log-tree.c b/log-tree.c
> index 4390b11..712a22b 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -677,8 +677,13 @@ void show_log(struct rev_info *opt)
> append_signoff(&msgbuf, opt->add_signoff);
>
> if ((ctx.fmt != CMIT_FMT_USERFORMAT) &&
> - ctx.notes_message && *ctx.notes_message)
> + ctx.notes_message && *ctx.notes_message) {
> + if (ctx.fmt == CMIT_FMT_EMAIL) {
> + strbuf_addstr(&msgbuf, "---\n");
> + opt->shown_dashes = 1;
> + }
> strbuf_addstr(&msgbuf, ctx.notes_message);
> + }
>
> if (opt->show_log_size) {
> printf("log size %i\n", (int)msgbuf.len);
> @@ -710,6 +715,7 @@ void show_log(struct rev_info *opt)
>
> int log_tree_diff_flush(struct rev_info *opt)
> {
> + opt->shown_dashes = 0;
> diffcore_std(&opt->diffopt);
>
> if (diff_queue_is_empty()) {
> @@ -737,10 +743,11 @@ int log_tree_diff_flush(struct rev_info *opt)
> opt->diffopt.output_prefix_data);
> fwrite(msg->buf, msg->len, 1, stdout);
> }
> - if ((pch & opt->diffopt.output_format) == pch) {
> - printf("---");
> + if (!opt->shown_dashes) {
> + if ((pch & opt->diffopt.output_format) == pch)
> + printf("---");
> + putchar('\n');
> }
> - putchar('\n');
> }
> }
> diff_flush(&opt->diffopt);
> diff --git a/revision.h b/revision.h
> index a95bd0b..059bfff 100644
> --- a/revision.h
> +++ b/revision.h
> @@ -111,6 +111,7 @@ struct rev_info {
>
> /* Format info */
> unsigned int shown_one:1,
> + shown_dashes:1,
> show_merge:1,
> show_notes:1,
> show_notes_given:1,
> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
> index bea6381..9750ba6 100755
> --- a/t/t4014-format-patch.sh
> +++ b/t/t4014-format-patch.sh
> @@ -623,9 +623,12 @@ test_expect_success 'format-patch --signoff' '
> test_expect_success 'format-patch --notes --signoff' '
> git notes --ref test add -m "test message" HEAD &&
> git format-patch -1 --signoff --stdout --notes=test >out &&
> - # Notes message must come after S-o-b
> + # Three dashes must come after S-o-b
> ! sed "/^Signed-off-by: /q" out | grep "test message" &&
> - sed "1,/^Signed-off-by: /d" out | grep "test message"
> + sed "1,/^Signed-off-by: /d" out | grep "test message" &&
> + # Notes message must come after three dashes
> + ! sed "/^---$/q" out | grep "test message" &&
> + sed "1,/^---$/d" out | grep "test message"
> '
>
> echo "fatal: --name-only does not make sense" > expect.name-only
> --
> 1.8.0.rc3.112.gdb88a5e
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2741 / Virus Database: 2614/5837 - Release Date:
> 10/17/12
>
^ permalink raw reply
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