* [PATCH] work around Python warnings from AsciiDoc
From: Junio C Hamano @ 2008-12-08 2:38 UTC (permalink / raw)
To: git
It appears that a reference to an anchor defined as [[anchor-name]] from
another place using <<anchor-name>> syntax, when the anchor name contains
a string "-with-" in its name, triggers these warnings from Python
interpreter.
asciidoc -b docbook -d book user-manual.txt
<string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
<string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
<string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
<string>:1: Warning: 'with' will become a reserved keyword in Python 2.6
There currently is no reference to "Finding comments with given content",
but for consistency and for futureproofing, the anchor is also updated as
the other ones that are actually used and trigger these warnings.
Signed-off-by: Junio C Hamano <junio@pobox.com>
---
Documentation/user-manual.txt | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git c/Documentation/user-manual.txt w/Documentation/user-manual.txt
index 9f527d3..c0c2f8d 100644
--- c/Documentation/user-manual.txt
+++ w/Documentation/user-manual.txt
@@ -13,7 +13,7 @@ to build and test a particular version of a software project, search for
regressions, and so on.
People needing to do actual development will also want to read
-<<Developing-with-git>> and <<sharing-development>>.
+<<Developing-With-git>> and <<sharing-development>>.
Further chapters cover more specialized topics.
@@ -399,7 +399,7 @@ the order it uses to decide which to choose when there are multiple
references with the same shorthand name, see the "SPECIFYING
REVISIONS" section of linkgit:git-rev-parse[1].
-[[Updating-a-repository-with-git-fetch]]
+[[Updating-a-repository-With-git-fetch]]
Updating a repository with git-fetch
------------------------------------
@@ -955,7 +955,7 @@ echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"
and then he just cut-and-pastes the output commands after verifying that
they look OK.
-[[Finding-comments-with-given-content]]
+[[Finding-comments-With-given-Content]]
Finding commits referencing a file with given content
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -972,7 +972,7 @@ Figuring out why this works is left as an exercise to the (advanced)
student. The linkgit:git-log[1], linkgit:git-diff-tree[1], and
linkgit:git-hash-object[1] man pages may prove helpful.
-[[Developing-with-git]]
+[[Developing-With-git]]
Developing with git
===================
@@ -1675,7 +1675,7 @@ dangling objects can arise in other situations.
Sharing development with others
===============================
-[[getting-updates-with-git-pull]]
+[[getting-updates-With-git-pull]]
Getting updates with git-pull
-----------------------------
@@ -1683,7 +1683,7 @@ After you clone a repository and make a few changes of your own, you
may wish to check the original repository for updates and merge them
into your own work.
-We have already seen <<Updating-a-repository-with-git-fetch,how to
+We have already seen <<Updating-a-repository-With-git-fetch,how to
keep remote tracking branches up to date>> with linkgit:git-fetch[1],
and how to merge two branches. So you can merge in changes from the
original repository's master branch with:
@@ -1794,7 +1794,7 @@ Public git repositories
Another way to submit changes to a project is to tell the maintainer
of that project to pull the changes from your repository using
-linkgit:git-pull[1]. In the section "<<getting-updates-with-git-pull,
+linkgit:git-pull[1]. In the section "<<getting-updates-With-git-pull,
Getting updates with git-pull>>" we described this as a way to get
updates from the "main" repository, but it works just as well in the
other direction.
@@ -2004,7 +2004,7 @@ $ git push ssh://yourserver.com/~you/proj.git +master
Normally whenever a branch head in a public repository is modified, it
is modified to point to a descendant of the commit that it pointed to
before. By forcing a push in this situation, you break that convention.
-(See <<problems-with-rewriting-history>>.)
+(See <<problems-With-rewriting-history>>.)
Nevertheless, this is a common practice for people that need a simple
way to publish a work-in-progress patch series, and it is an acceptable
@@ -2573,7 +2573,7 @@ There are numerous other tools, such as StGIT, which exist for the
purpose of maintaining a patch series. These are outside of the scope of
this manual.
-[[problems-with-rewriting-history]]
+[[problems-With-rewriting-history]]
Problems with rewriting history
-------------------------------
^ permalink raw reply related
* Re: [PATCH] fetch-pack: Avoid memcpy() with src==dst
From: Junio C Hamano @ 2008-12-08 2:47 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <1228596609-12720-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> memcpy() may only be used for disjoint memory areas, but when invoked
> from cmd_fetch_pack(), we have my_args == &args. (The argument cannot
> be removed entirely because transport.c invokes with its own
> variable.)
It makes me wonder if it might be a better fix to abolish the use of file
scoped global "args" and pass a pointer to "struct fetch_pack_args"
throughout the callchain instead.
In the current code, cmd_fetch_pack() is the only caller that passes &args
to this function, but it is not so implausible to have a future callchain
that makes two calls to cmd_fetch_pack(), perhaps implementing some sort
of alias to fetch from multiple places, would horribly break without such
a fix, because cmd_fetch_pack() assumes that args is in its pristine
state.
I'll apply this to 'maint' and merge it up, because the patch is
independent of the above issue.
Thanks.
^ permalink raw reply
* Can Git push only first parent history commits?
From: Li Frank @ 2008-12-08 2:52 UTC (permalink / raw)
To: git
The commit history is:
origin/master
Commit1..Commit2..Commit3(T1 branch).
I want to combined Commit1, Commit2 and Commit3 to one commit_X
and push to origin master and keep old T1 branch history. So I can't
use rebase. T1 branch history will be lost after rebase.
So I create T2 branch at origin/master:
origin/master
Commit1..Commit2..Commit3(T1 branch).
T2 (branch).
Then I use "git merge --no-ff --log T1" merge T1 to T2.
So
origin/master
+--Commit1..Commit2..Commit3(T1 branch). +
+----------------------------------------------------------------+--Comm
itX(T2 branch).
But when I push T2 to origin master, Commit1 ,2, 3 also pushed.
I expect there are only CommitX at origin master branch.
How can I do?
best regards
Frank Li
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.1-rc2
From: Junio C Hamano @ 2008-12-08 2:53 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Another week, another rc. There are no outstanding features that should
graduate from 'next' anymore until final.
http://www.kernel.org/pub/software/scm/git/
git-1.6.1-rc2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.1-rc2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.1-rc2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also there.
testing/git-*-1.6.1-rc2-1.fc9.$arch.rpm (RPM)
----------------------------------------------------------------
Changes since v1.6.1-rc1 are as follows:
Alex Riesen (3):
Make some of fwrite/fclose/write/close failures visible
Make chdir failures visible
Report symlink failures in merge-recursive
Alexander Gavrilov (2):
gitk: Make line origin search update the busy status
gitk: Add a menu option to start git gui
Christian Couder (2):
bisect: fix "git bisect skip <commit>" and add tests cases
Documentation: describe how to "bisect skip" a range of commits
Christian Stimming (1):
gitk: Update German translation
Davide Libenzi (1):
xdiff: give up scanning similar lines early
Deskin Miller (1):
git-svn: Make branch use correct svn-remote
Giuseppe Bilotta (2):
gitweb: make gitweb_check_feature a boolean wrapper
Update comment on gitweb_check/get_feature
Jakub Narebski (2):
gitweb: Fix handling of non-ASCII characters in inserted HTML files
gitweb: Make project specific override for 'grep' feature work
Jeff King (2):
add stage to gitignore
tag: delete TAG_EDITMSG only on successful tag
Johannes Sixt (1):
t4030-diff-textconv: Make octal escape sequence more portable
Junio C Hamano (17):
builtin-rm.c: explain and clarify the "local change" logic
git add --intent-to-add: fix removal of cached emptiness
git add --intent-to-add: do not let an empty blob be committed by accident
gitweb: fix 'ctags' feature check and others
gitweb: rename gitweb_check_feature to gitweb_get_feature
Makefile: introduce NO_PTHREADS
Install git-stage in exec-path
git-am --whitespace: do not lose the command line option
git-am: propagate -C<n>, -p<n> options as well
git-am: propagate --3way options as well
Test that git-am does not lose -C/-p/--whitespace options
git-am: rename apply_opt_extra file to apply-opt
Update draft release notes to 1.6.1
GIT 1.6.0.5
Update draft release notes for 1.6.1
Revert "git-stash: use git rev-parse -q"
Point "stale" 1.6.0.5 documentation from the main git documentation page
Linus Torvalds (1):
Add backslash to list of 'crud' characters in real name
Mark Burton (1):
git-gui: Teach start_push_anywhere_action{} to notice when remote is a mirror.
Matt McCutchen (1):
"git diff <tree>{3,}": do not reverse order of arguments
Miklos Vajna (8):
User's Manual: remove duplicated url at the end of Appendix B
git-stash: use git rev-parse -q
filter-branch: use git rev-parse -q
lost-found: use git rev-parse -q
pull: use git rev-parse -q
rebase: use git rev-parse -q
submodule: use git rev-parse -q
http.c: use 'git_config_string' to get 'curl_http_proxy'
Nguyễn Thái Ngọc Duy (1):
Extend index to save more flags
Paul Mackerras (3):
gitk: Fix context menu items for generating diffs when in tree mode
gitk: Highlight only when search type is "containing:".
gitk: Fix bug in accessing undefined "notflag" variable
Scott Chacon (1):
Add a built-in alias for 'stage' to the 'add' command
Thomas Rast (1):
fetch-pack: Avoid memcpy() with src==dst
Tor Arvid Lund (1):
git-p4: Fix bug in p4Where method.
^ permalink raw reply
* [PATCH 1/3] reorder ALLOW_TEXTCONV option setting
From: Jeff King @ 2008-12-08 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Right now for the diff porcelain and the log family, we
call:
init_revisions();
setup_revisions();
DIFF_OPT_SET(ALLOW_TEXTCONV);
However, that means textconv will _always_ be on, instead of
being a default that can be manipulated with
setup_revisions. Instead, we want:
init_revisions();
DIFF_OPT_SET(ALLOW_TEXTCONV);
setup_revisions();
which is what this patch does.
We'll go ahead and move the callsite in wt-status, also;
even though the user can't pass any options here, it is a
cleanup that will help avoid any surprise later if the
setup_revisions line is changed.
Signed-off-by: Jeff King <peff@peff.net>
---
This is a "bug fix" in the sense that the code does not match the
original intent (which was to set a default for these porcelains). But
you can't _trigger_ the bug since setup_revisions never munges the value
(but it will in 2/3).
builtin-diff.c | 4 ++--
builtin-log.c | 2 +-
wt-status.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index dddcf69..d75d69b 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -290,8 +290,9 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
/* Otherwise, we are doing the usual "git" diff */
rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
- /* Default to let external be used */
+ /* Default to let external and textconv be used */
DIFF_OPT_SET(&rev.diffopt, ALLOW_EXTERNAL);
+ DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
if (nongit)
die("Not a git repository");
@@ -303,7 +304,6 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
}
DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
- DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
/*
* If the user asked for our exit code then don't start a
diff --git a/builtin-log.c b/builtin-log.c
index b164717..840daf9 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -37,6 +37,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
DIFF_OPT_SET(&rev->diffopt, RECURSIVE);
rev->show_root_diff = default_show_root;
rev->subject_prefix = fmt_patch_subject_prefix;
+ DIFF_OPT_SET(&rev->diffopt, ALLOW_TEXTCONV);
if (default_date_mode)
rev->date_mode = parse_date_format(default_date_mode);
@@ -60,7 +61,6 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
} else
die("unrecognized argument: %s", arg);
}
- DIFF_OPT_SET(&rev->diffopt, ALLOW_TEXTCONV);
}
/*
diff --git a/wt-status.c b/wt-status.c
index 3edae43..96ff2f8 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -279,11 +279,11 @@ static void wt_status_print_verbose(struct wt_status *s)
struct rev_info rev;
init_revisions(&rev, NULL);
+ DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
setup_revisions(0, NULL, &rev,
s->is_initial ? EMPTY_TREE_SHA1_HEX : s->reference);
rev.diffopt.output_format |= DIFF_FORMAT_PATCH;
rev.diffopt.detect_rename = 1;
- DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
rev.diffopt.file = s->fp;
rev.diffopt.close_file = 0;
/*
--
1.6.1.rc2.285.gc1cf2
^ permalink raw reply related
* [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Jeff King @ 2008-12-08 2:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Some history viewers use the diff plumbing to generate diffs
rather than going through the "git diff" porcelain.
Currently, there is no way for them to specify that they
would like to see the text-converted version of the diff.
This patch adds a "--textconv" option to allow such a
plumbing user to allow text conversion. The user can then
tell the viewer whether or not they would like text
conversion enabled.
While it may be tempting add a configuration option rather
than requiring each plumbing user to be configured to pass
--textconv, that is somewhat dangerous. Text-converted diffs
generally cannot be applied directly, so each plumbing user
should "opt in" to generating such a diff, either by
explicit request of the user or by confirming that their
output will not be fed to patch.
Signed-off-by: Jeff King <peff@peff.net>
---
My ultimate goal is to see these diffs in gitk, which is implemented in
3/3. As a bonus side effect, the --no-textconv option can be used with
"git diff" or "git log" if you really don't want to see them there
(e.g., because you are abusing "git log" to produce a binary patch you
mean to apply).
I know this is not strictly a bugfix and we are in -rc, but:
1. It is an enhancement to a previously unreleased feature, and
shouldn't affect anything outside of that.
2. It affects the scripting interface to textconv, so I would like to
get it in before textconv is ever released so that it is always the
"right way" to turn text conversion off or on.
diff.c | 4 ++++
diff.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index f644947..e21af3b 100644
--- a/diff.c
+++ b/diff.c
@@ -2477,6 +2477,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_OPT_SET(options, ALLOW_EXTERNAL);
else if (!strcmp(arg, "--no-ext-diff"))
DIFF_OPT_CLR(options, ALLOW_EXTERNAL);
+ else if (!strcmp(arg, "--textconv"))
+ DIFF_OPT_SET(options, ALLOW_TEXTCONV);
+ else if (!strcmp(arg, "--no-textconv"))
+ DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
else if (!strcmp(arg, "--ignore-submodules"))
DIFF_OPT_SET(options, IGNORE_SUBMODULES);
--
1.6.1.rc2.285.gc1cf2
^ permalink raw reply related
* Re: Can Git push only first parent history commits?
From: Junio C Hamano @ 2008-12-08 3:00 UTC (permalink / raw)
To: Li Frank; +Cc: git
In-Reply-To: <402F4B33D9C9DE4083DB96B416549FAF9E12@zch01exm23.fsl.freescale.net>
Your drawing nor explanation unfortunately does not make much sense to me,
so I'll respond only to the subject.
Pushing only first parent history would mean that the commits you will be
transferring will still record their true parents, but you are not sending
any parents but the first ones. The repository that receives such a push
would not pass fsck, in other words, you are deliberately corrupting the
repository.
Naturally we won't support such an operation by default.
It is plausible that you can implement an option to do so, but it would
make it hard at the receiving end to tell between a true repository
corruption and a corruption you are deliberately introducing by such a
push, so it won't be useful unless accompanied by a corresponding option
to fsck to make it not complain when parent commits and associated objects
that are not necessary for first parent history.
^ permalink raw reply
* [gitk PATCH 3/3] gitk: allow text-conversion in diffs
From: Jeff King @ 2008-12-08 3:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
The "textconv" feature of git requires explicit enabling in
plumbing because the resulting diffs are not useful for
feeding to "git-apply" or "patch". Thus any callers should
make a conscious choice that they want the human-friendly
version.
Since the diffs presented by gitk are meant primarily for
human consumption, and not applying, it makes sense to allow
text conversion.
---
Paul,
I am cc'ing you only on 3/3 since it is the only gitk patch (the others
implement --textconv in git itself). Textconv is basically a feature to
show human-readable text diffs of binary files by doing a one-way binary
to text conversion (and so they can't be applied).
I think gitk would always want to support these; if not, then the
alternative is a "diff flags" option for gitk where the user could
specify this flag manually.
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index a5e24e4..0fb87c7 100755
--- a/gitk
+++ b/gitk
@@ -7198,7 +7198,7 @@ proc getblobdiffs {ids} {
global limitdiffs vfilelimit curview
global diffencoding targetline diffnparents
- set cmd [diffcmd $ids "-p -C --cc --no-commit-id -U$diffcontext"]
+ set cmd [diffcmd $ids "-p -C --cc --no-commit-id -U$diffcontext --textconv"]
if {$ignorespace} {
append cmd " -w"
}
--
1.6.1.rc2.285.gc1cf2
^ permalink raw reply related
* RE: Can Git push only first parent history commits?
From: Li Frank @ 2008-12-08 3:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i6bbcc6.fsf@gitster.siamese.dyndns.org>
I don't know the detail of git internal. Or my email subject
description have some problem.
I just want to combine some commits to one commit and push combined
commit to remote. And at same time, keep commits history at my local
repository. Rebase will make original history lost.
-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Monday, December 08, 2008 11:00 AM
To: Li Frank-B20596
Cc: git@vger.kernel.org
Subject: Re: Can Git push only first parent history commits?
Your drawing nor explanation unfortunately does not make much sense to
me, so I'll respond only to the subject.
Pushing only first parent history would mean that the commits you will
be transferring will still record their true parents, but you are not
sending any parents but the first ones. The repository that receives
such a push would not pass fsck, in other words, you are deliberately
corrupting the repository.
Naturally we won't support such an operation by default.
It is plausible that you can implement an option to do so, but it would
make it hard at the receiving end to tell between a true repository
corruption and a corruption you are deliberately introducing by such a
push, so it won't be useful unless accompanied by a corresponding option
to fsck to make it not complain when parent commits and associated
objects that are not necessary for first parent history.
^ permalink raw reply
* Re: [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Junio C Hamano @ 2008-12-08 3:55 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081208025700.GB22072@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I know this is not strictly a bugfix and we are in -rc, but:
>
> 1. It is an enhancement to a previously unreleased feature, and
> shouldn't affect anything outside of that.
>
> 2. It affects the scripting interface to textconv, so I would like to
> get it in before textconv is ever released so that it is always the
> "right way" to turn text conversion off or on.
I'd agree with #1, especially if you said "doesn't" instead of
"shouldn't".
But I am not 100% sure if the scripting part is "the right way".
If a script wants to take whatever Porcelain users are happy as the
"presentation for human consumption" and pass that through as its own
output to the end user, maybe it is better off reading from Porcelain,
instead of reading from the plumbing (the latter of which requires making
the plumbing output less reliable)?
When we later enhance textconv output from the "diff" Porcelain to benefit
interactive users, it will automatically help the script that passes
through the "diff" output to the end users.
You can certainly argue that this "textconv" feature that is grafted from
Porcelain into plumbing is a special case in that its output is subject to
change any time to help human consumption and we never strive for its
stability as we do for other features in the plumbing to support machine
readability by scripts. You can propagate the later enhancement of
textconv diff output we'd make for Porcelain to the scripted users that
reads from the plumbing that way.
But then wouldn't it be the same for these scripts that do value the
"presentation meant for human consumption" over "machine readability" to
read from Porcelain? That would not have to blur the distinction between
the Porcelain and plumbing like the approach you are suggesting here.
^ permalink raw reply
* Re: Can Git push only first parent history commits?
From: Boyd Stephen Smith Jr. @ 2008-12-08 4:03 UTC (permalink / raw)
To: git; +Cc: Li Frank
In-Reply-To: <402F4B33D9C9DE4083DB96B416549FAF9E12@zch01exm23.fsl.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]
On Sunday 07 December 2008, "Li Frank" <Frank.Li@freescale.com> wrote
about 'Can Git push only first parent history commits?':
> The commit history is:
> origin/master
> Commit1..Commit2..Commit3(T1 branch).
>
> I want to combined Commit1, Commit2 and Commit3 to one commit_X
>and push to origin master and keep old T1 branch history. So I can't
>use rebase. T1 branch history will be lost after rebase.
I'm pretty sure you want to do something like this:
git branch T2 T1
git rebase -i master T2
# Editor opens
# Edit commit list to squash 3 commits into 1.
git push origin T2:master
git fetch origin
At the end, you'll have a history that looks like:
*--> origin/master (T2)
\
-> C1 --> C2 --> C3 (T1)
I'm not sure why you'd want to do this though. If the commits don't stand
alone well, they should be squashed on T1 before pushing. If the commits
do stand alone well, the history should preserve them on master as well.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Junio C Hamano @ 2008-12-08 4:08 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <7vfxkz9v8f.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> I know this is not strictly a bugfix and we are in -rc, but:
>>
>> 1. It is an enhancement to a previously unreleased feature, and
>> shouldn't affect anything outside of that.
>>
>> 2. It affects the scripting interface to textconv, so I would like to
>> get it in before textconv is ever released so that it is always the
>> "right way" to turn text conversion off or on.
>
> I'd agree with #1, especially if you said "doesn't" instead of
> "shouldn't".
>
> But I am not 100% sure if the scripting part is "the right way".
But I'll apply them anyway.
^ permalink raw reply
* Re: [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Jeff King @ 2008-12-08 4:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxkz9v8f.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 07, 2008 at 07:55:12PM -0800, Junio C Hamano wrote:
> But I am not 100% sure if the scripting part is "the right way".
>
> If a script wants to take whatever Porcelain users are happy as the
> "presentation for human consumption" and pass that through as its own
> output to the end user, maybe it is better off reading from Porcelain,
> instead of reading from the plumbing (the latter of which requires making
> the plumbing output less reliable)?
But I don't think having gitk call the porcelain makes sense, either.
That would enable, for example, external diff drivers which might
actually spawn an entirely new window. And I don't think most people
would want that from gitk.
Now, obviously it could call "git diff --no-ext-diff" to opt out of
that. But I think it is backwards to call porcelain but opt out of
features that you don't want. It makes more sense to start with the bare
minimum (i.e., plumbing) and opt in to features that you are OK with.
And yes, you increase the risk that a script which blindly passes
options to plumbing may now be asked to generate a textconv'd diff which
will be useless to the user. But:
1. that is already a risk with --ext-diff
2. it is actually a _feature_. It is asking the user to say "is this
a sane option to pass for my situation or not" instead of forcing
the script to make that decision.
> When we later enhance textconv output from the "diff" Porcelain to
> benefit interactive users, it will automatically help the script that
> passes through the "diff" output to the end users.
I'm not sure what enhancement you mean. But it is possible that gitk
would not _want_ such an enhancement, and it would then have to opt out
of it.
> You can certainly argue that this "textconv" feature that is grafted from
> Porcelain into plumbing is a special case in that its output is subject to
> change any time to help human consumption and we never strive for its
> stability as we do for other features in the plumbing to support machine
> readability by scripts. You can propagate the later enhancement of
> textconv diff output we'd make for Porcelain to the scripted users that
> reads from the plumbing that way.
Right. _If_ it's a change that won't upset any plumbing consumers. If it
is, then it needs to be a separate option so that the plumbing consumers
who don't mind the change can start using it.
> But then wouldn't it be the same for these scripts that do value the
> "presentation meant for human consumption" over "machine readability" to
> read from Porcelain? That would not have to blur the distinction between
> the Porcelain and plumbing like the approach you are suggesting here.
I don't agree that this is blurring the distinction. I don't see
textconv diffs as a "porcelain feature" that has been grafted on to
plumbing. I see it as a core diff feature which can be turned off or on.
Porcelain has it on by default, and plumbing has it off by default. But
you can ask either to change their default settings[1].
-Peff
[1]: You can argue that the current implementation is buggy in this
sense, though, since some porcelains will accept "--textconv" but not
change their behavior. I think blame, for example, will have that
problem, because it accepts diff options but does not necessarily use
them to create diffs. But I think that just means we have a bug and
eventually should handle the case of "git blame --textconv" correctly.
^ permalink raw reply
* [PATCH v2] git-svn: Make following parents atomic
From: Deskin Miller @ 2008-12-08 6:20 UTC (permalink / raw)
To: git; +Cc: normalperson, gitster, Deskin Miller
In-Reply-To: <20081207222444.GA10881@euler>
find_parent_branch generates branch@rev type branches when one has to
look back through SVN history to properly get the history for a branch
copied from somewhere not already being tracked by git-svn. If in the
process of fetching this history, git-svn is interrupted, then when one
fetches again, it will use whatever was last fetched as the parent
commit and fail to fetch any more history which it didn't get to before
being terminated. This is especially troubling in that different
git-svn copies of the same SVN repository can end up with different
commit sha1s, incorrectly showing the history as divergent and
precluding easy collaboration using git push and fetch.
To fix this, when we initialise the Git::SVN object $gs to search for
and perhaps fetch history, we check if there are any commits in SVN in
the range between the current revision $gs is at, and the top revision
for which we were asked to fill history. If there are commits we're
missing in that range, we continue the fetch from the current revision
to the top, properly getting all history before using it as the parent
for the branch we're trying to create.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
Fixes the bug I found after sending v1. I squashed in a check for it
into the testcase; if it's preferable I can split it into its own
testcase (this one runs quite long as-is).
Deskin Miller
git-svn.perl | 16 ++++++++++---
t/t9104-git-svn-follow-parent.sh | 43 ++++++++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 56238da..25ed2f4 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2318,12 +2318,20 @@ sub find_parent_branch {
$gs = Git::SVN->init($u, $p, $repo_id, $ref_id, 1);
}
my ($r0, $parent) = $gs->find_rev_before($r, 1);
- if (!defined $r0 || !defined $parent) {
- my ($base, $head) = parse_revision_argument(0, $r);
- if ($base <= $r) {
+ {
+ my ($base, $head);
+ if (!defined $r0 || !defined $parent) {
+ ($base, $head) = parse_revision_argument(0, $r);
+ } else {
+ if ($r0 < $r) {
+ $gs->ra->get_log([$gs->{path}], $r0 + 1, $r, 1,
+ 0, 1, sub { $base = $_[1] - 1 });
+ }
+ }
+ if (defined $base && $base <= $r) {
$gs->fetch($base, $r);
}
- ($r0, $parent) = $gs->last_rev_commit;
+ ($r0, $parent) = $gs->find_rev_before($r, 1);
}
if (defined $r0 && defined $parent) {
print STDERR "Found branch parent: ($self->{ref_id}) $parent\n";
diff --git a/t/t9104-git-svn-follow-parent.sh b/t/t9104-git-svn-follow-parent.sh
index 4d964e2..45138a2 100755
--- a/t/t9104-git-svn-follow-parent.sh
+++ b/t/t9104-git-svn-follow-parent.sh
@@ -149,6 +149,49 @@ test_expect_success "track initial change if it was only made to parent" '
"`git rev-parse r9270-d~1`"
'
+test_expect_success "follow-parent is atomic" '
+ cd wc &&
+ svn up &&
+ svn mkdir stunk &&
+ cd stunk &&
+ echo "trunk stunk" > readme &&
+ svn add readme &&
+ cd .. &&
+ svn ci -m "trunk stunk" &&
+ echo "stunk like junk" >> stunk/readme &&
+ svn ci -m "really stunk" &&
+ echo "stink stank stunk" >> stunk/readme &&
+ svn ci -m "even the grinch agrees" &&
+ cd .. &&
+ svn copy -m "stunk flunked" "$svnrepo"/stunk "$svnrepo"/flunk &&
+ (svn cp -m "early stunk flunked too" \
+ "$svnrepo"/stunk@17 "$svnrepo"/flunked ||
+ svn cp -m "early stunk flunked too" \
+ -r17 "$svnrepo"/stunk "$svnrepo"/flunked) &&
+ git svn init --minimize-url -i stunk "$svnrepo"/stunk &&
+ git svn fetch -i stunk &&
+ git update-ref refs/remotes/flunk@18 refs/remotes/stunk~2 &&
+ git update-ref -d refs/remotes/stunk &&
+ git config --unset svn-remote.svn.fetch stunk &&
+ mkdir -p "$GIT_DIR"/svn/flunk@18 &&
+ rev_map=$(cd "$GIT_DIR"/svn/stunk && ls .rev_map*) &&
+ dd if="$GIT_DIR"/svn/stunk/$rev_map \
+ of="$GIT_DIR"/svn/flunk@18/$rev_map bs=24 count=1 &&
+ rm -rf "$GIT_DIR"/svn/stunk &&
+ git svn init --minimize-url -i flunk "$svnrepo"/flunk &&
+ git svn fetch -i flunk &&
+ git svn init --minimize-url -i stunk "$svnrepo"/stunk &&
+ git svn fetch -i stunk &&
+ git svn init --minimize-url -i flunked "$svnrepo"/flunked &&
+ git svn fetch -i flunked
+ test "`git rev-parse --verify refs/remotes/flunk@18`" \
+ = "`git rev-parse --verify refs/remotes/stunk`" &&
+ test "`git rev-parse --verify refs/remotes/flunk~1`" \
+ = "`git rev-parse --verify refs/remotes/stunk`" &&
+ test "`git rev-parse --verify refs/remotes/flunked~1`" \
+ = "`git rev-parse --verify refs/remotes/stunk~1`"
+ '
+
test_expect_success "track multi-parent paths" '
svn cp -m "resurrect /glob" "$svnrepo"/r9270 "$svnrepo"/glob &&
git-svn multi-fetch &&
--
1.6.1.rc1.45.g123ed
^ permalink raw reply related
* How to config git-daemon?
From: Ren LingYan-E5949C @ 2008-12-08 6:27 UTC (permalink / raw)
To: git
Hello,
I want to public my repository testproject, which can be accessed by git
protocol.
My steps are as below:
On Server machine (for example 10.194.66.71) 1. Created testproject
under /home/e5949c/repositories 2. Created a file "git-daemon-export-ok"
under testproject/ .git directory.
3. Run command "git daemon --verbose --export-all"
On test machine
1. Run command "git clone
git://10.194.66.71/home/e5949c/repositories/testproject.git". Error as
below :
Initialized empty Git repository in
/export/home/e5949c/repositories/test/testproject/.git/
fatal: The remote end hung up unexpectedly
Can anyone help me on this error? What did I miss ?
Your help will be highly appreciated !
Thanks,
Emily
^ permalink raw reply
* Re: [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Junio C Hamano @ 2008-12-08 6:52 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081208045924.GA22780@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> You can certainly argue that this "textconv" feature that is grafted from
>> Porcelain into plumbing is a special case in that its output is subject to
>> change any time to help human consumption and we never strive for its
>> stability as we do for other features in the plumbing to support machine
>> readability by scripts. You can propagate the later enhancement of
>> textconv diff output we'd make for Porcelain to the scripted users that
>> reads from the plumbing that way.
>
> Right. _If_ it's a change that won't upset any plumbing consumers. If it
> is, then it needs to be a separate option so that the plumbing consumers
> who don't mind the change can start using it.
In the above argument, you are assuming that you can have a complete
enumeration of "plumbing consumers", so that we can tell what kind of
changes to textconv output do affect them in a negative way, and what kind
of changes are safe.
Yes, you can enumerate in-tree consumers, but that misses the whole point
of having "plumbing", which can be used by any scripts out of tree and
they can rely on stable output from the plumbing. By giving --textconv to
them to use with the plumbing, you are effecively casting textconv output
in stone. By definition we will never know what kind of changes to the
output from the textconv filter out of tree consumers would mind.
Currently "diff" machinery uses the output of textconv filter as-is
without any further embellishment, but I think it is too early to tell if
that is really what we would want, or we may need some minimum
postprocessing on what we receive from the textconv filter before feeding
that to the textual diff machinery, because the feature has not been used
in the field at all yet.
In any case, I've applied the series for an entirely different reason.
The patch is the most natural way to allow users of Porcelain to disable
textconv with the --no-textconv option, just like --no-ext-diff can be
used to disable the external diff.
We _might_ want to add another patch to make the plumbing layer ignore (or
error out) --textconv option given from the command line before 1.6.1
ships, and after we gain confidence with the stability of the feature,
revert that patch to allow use of --textconv freely from the plumbing.
It always is easier to introduce a new feature in a more limited form and
then later loosen it, than adding it in an unrestricted form and having
later to limit it for whatever reason.
^ permalink raw reply
* Re: [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Jeff King @ 2008-12-08 7:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskoz88g8.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 07, 2008 at 10:52:39PM -0800, Junio C Hamano wrote:
> > Right. _If_ it's a change that won't upset any plumbing consumers. If it
> > is, then it needs to be a separate option so that the plumbing consumers
> > who don't mind the change can start using it.
>
> In the above argument, you are assuming that you can have a complete
> enumeration of "plumbing consumers", so that we can tell what kind of
> changes to textconv output do affect them in a negative way, and what kind
> of changes are safe.
No, I'm assuming we have an idea of what is a "reasonable" change to the
feature that won't break consumers, and what is a change that will
break them. And it's the same judgement we have to make all the time
when thinking about how changes will impact the scriptable interface.
And furthermore, I'm proposing to take the safest path, which is to
say that the scriptable interface _doesn't_ change unless each consumer
decides to ask it to do so. That is, the output of "git diff-tree" is
unchanged unless the caller explicitly allows textconv. So now we have
given a meaning to "--textconv". If you want a _new_ textconv variant
(let's say you want it to output the textconv patch with some "this
isn't a real patch" munging, and also include the binary patch -- which
would make it both human readable and applicable), then I think it is
safe to say that is an incompatible change. And it gets called
--textconv-with-patch or whatever, and porcelain can move to it by
default. But the plumbing consumers still get the same thing via
--textconv, and they can opt into the new format if that is useful to
them.
So uptake of the new feature is slower (you have to wait for the
maintainer of the script to support it) but you never break
compatibility.
> Yes, you can enumerate in-tree consumers, but that misses the whole point
> of having "plumbing", which can be used by any scripts out of tree and
> they can rely on stable output from the plumbing. By giving --textconv to
> them to use with the plumbing, you are effecively casting textconv output
> in stone. By definition we will never know what kind of changes to the
> output from the textconv filter out of tree consumers would mind.
Right. But we _have_ to cast it in stone if we want to make it available
to them at all. So I am proposing to give what exists now a name, and
further enhancements will have to have a different name.
If you want to argue that it is too early to cast in stone, since we
will have to carry around this implementation and the name "--textconv"
forever, then I can accept that. But it is a bit annoying, since I want
to use it in gitk _now_. :)
But I do run 'next' usually, so maybe it is worth pushing it off until
the next release cycle.
> In any case, I've applied the series for an entirely different reason.
> The patch is the most natural way to allow users of Porcelain to disable
> textconv with the --no-textconv option, just like --no-ext-diff can be
> used to disable the external diff.
Yes, I agree that is worthwhile and should have been there since the
beginning (and I think should definitely ship in 1.6.1).
> We _might_ want to add another patch to make the plumbing layer ignore (or
> error out) --textconv option given from the command line before 1.6.1
> ships, and after we gain confidence with the stability of the feature,
> revert that patch to allow use of --textconv freely from the plumbing.
If you want to do that, the simplest thing is to simply take the
"--no-textconv" part of 2/3 and drop the rest. There is not really any
point in supporting --textconv just for porcelain, which already has it
on by default.
-Peff
^ permalink raw reply
* RE: How to config git-daemon?
From: LIU JIN-YU-KFQP84 @ 2008-12-08 7:36 UTC (permalink / raw)
To: Ren LingYan-E5949C, git
In-Reply-To: <D13CA5792E8D5140A50EEDB89972CDCB053E21AA@zmy16exm63.ds.mot.com>
Hi,
Try to check if GIT_PROXY_COMMAND is set and your proxy can accept
internal address.
Regards
Simon Liu
-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
Behalf Of Ren LingYan-E5949C
Sent: Monday, December 08, 2008 2:28 PM
To: git@vger.kernel.org
Subject: How to config git-daemon?
Hello,
I want to public my repository testproject, which can be accessed by git
protocol.
My steps are as below:
On Server machine (for example 10.194.66.71) 1. Created testproject
under /home/e5949c/repositories 2. Created a file "git-daemon-export-ok"
under testproject/ .git directory.
3. Run command "git daemon --verbose --export-all"
On test machine
1. Run command "git clone
git://10.194.66.71/home/e5949c/repositories/testproject.git". Error as
below :
Initialized empty Git repository in
/export/home/e5949c/repositories/test/testproject/.git/
fatal: The remote end hung up unexpectedly
Can anyone help me on this error? What did I miss ?
Your help will be highly appreciated !
Thanks,
Emily
^ permalink raw reply
* Re: Can Git push only first parent history commits?
From: Matthieu Moy @ 2008-12-08 7:44 UTC (permalink / raw)
To: Li Frank; +Cc: Junio C Hamano, git
In-Reply-To: <402F4B33D9C9DE4083DB96B416549FAF9E2D@zch01exm23.fsl.freescale.net>
"Li Frank" <Frank.Li@freescale.com> writes:
> I don't know the detail of git internal. Or my email subject
> description have some problem.
>
> I just want to combine some commits to one commit and push combined
> commit to remote. And at same time, keep commits history at my local
> repository. Rebase will make original history lost.
git merge --squash may help.
--
Matthieu
^ permalink raw reply
* Re: [PATCH 2/3] diff: allow turning on textconv explicitly for plumbing
From: Junio C Hamano @ 2008-12-08 8:27 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <7vskoz88g8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> In any case, I've applied the series for an entirely different reason.
> The patch is the most natural way to allow users of Porcelain to disable
> textconv with the --no-textconv option, just like --no-ext-diff can be
> used to disable the external diff.
I imagine that web developers may want to use a textconv filter that
replaces ">" with "\n>" on the HTML files their designer-colleagues throw
in the source tree to make "git log -p" of the whole project easier to
follow. When the developers would want to suggest improvements to what
their designer-colleagues did, however, by running "git diff --stat -p" in
their dirty work tree to produce a patch (like I just did just now,
visible from the mnemonic prefixes below), they would want to disable
textconv temporarily to get an appliable patch with --no-textconv option.
Once we have --no-textconv, somebody would inevitably ask about its
positive counterpart, --textconv option. Even though it might not make
sense from patch applicability viewpoint, the option would allow the end
user to explicitly ask for "git format-patch --textconv" and get a patch
that can only be reviewed by humans but cannot be applied. Hence the
attached update to the draft release notes to version 1.6.1 [Update #1].
You raised an intriguing possibility to use textconv in blame. It would
also be useful if we allowed "git show --textconv $blob" to pass the blob
via textconv filter and any other transformation controlled by the
attributes mechanism.. When "git show" sees the above command line, it
only knows the blob object name and not the path, so we may need to allow
a new option to tell the command to pretend as if the content came from a
path, perhaps with a syntax like:
$ git show --attribute-path=a/b/c $blob
$ git show --attribute-path=a/b/c --textconv $blob
Note that I envision that the above two commands would produce different
results. The former would behave as if $blob were recorded at path a/b/c
and what would be checked out (i.e. usual crlf, ident, and smudge that are
in effect for the path are applied) to the standard output. The latter
would apply the textconv filter that would apply to what is recorded at
the given path and show that.
[Update #1]
Documentation/RelNotes-1.6.1.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git c/Documentation/RelNotes-1.6.1.txt w/Documentation/RelNotes-1.6.1.txt
index 0405309..09bbcad 100644
--- c/Documentation/RelNotes-1.6.1.txt
+++ w/Documentation/RelNotes-1.6.1.txt
@@ -133,7 +133,8 @@ on.
contents can be munged into human readable form and the difference
between the results of the conversion can be viewed (obviously this
cannot produce a patch that can be applied, so this is disabled in
- format-patch among other things).
+ format-patch and plumbing, but if you really wanted to, you can enable
+ it by giving them --textconv command line option explicitly).
* "--cached" option to "git diff has an easier to remember synonym "--staged",
to ask "what is the difference between the given commit and the
^ permalink raw reply related
* Re: [PATCH v2] git-svn: Make following parents atomic
From: Junio C Hamano @ 2008-12-08 8:33 UTC (permalink / raw)
To: Deskin Miller; +Cc: git, normalperson
In-Reply-To: <1228717252-1016-1-git-send-email-deskinm@umich.edu>
Deskin Miller <deskinm@umich.edu> writes:
> +test_expect_success "follow-parent is atomic" '
> + cd wc &&
> + svn up &&
> + svn mkdir stunk &&
> + cd stunk &&
> + echo "trunk stunk" > readme &&
> + svn add readme &&
> + cd .. &&
If you need to chdir around inside a test, please do that in a subshell,
so that after failing any command in between, the next test will not start
in an unexpected directory.
> + svn ci -m "trunk stunk" &&
> + echo "stunk like junk" >> stunk/readme &&
> + svn ci -m "really stunk" &&
> + echo "stink stank stunk" >> stunk/readme &&
> + svn ci -m "even the grinch agrees" &&
> + cd .. &&
> + svn copy -m "stunk flunked" "$svnrepo"/stunk "$svnrepo"/flunk &&
> + (svn cp -m "early stunk flunked too" \
> + "$svnrepo"/stunk@17 "$svnrepo"/flunked ||
> + svn cp -m "early stunk flunked too" \
> + -r17 "$svnrepo"/stunk "$svnrepo"/flunked) &&
On the other hand, I do not see a need for this portion to be in a
subshell. Wouldn't a normal statement grouping with {} work just as well?
^ permalink raw reply
* Re: [PATCH] git-stash: use git rev-parse -q
From: Miklos Vajna @ 2008-12-08 8:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, git
In-Reply-To: <7vhc5fcui1.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 247 bytes --]
On Sun, Dec 07, 2008 at 05:42:46PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Thanks; I'll revert this one. Use of -q is simply not worth this
> aggravation.
Sorry, I missed that 2>/dev/null is used for this purpose there as well.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Nguyen Thai Ngoc Duy @ 2008-12-08 12:51 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <alpine.LNX.1.00.0812071455020.19665@iabervon.org>
On 12/8/08, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > This was discussed since the beginning of this feature. I recall that
> > the index reflects worktree, and because we mark CE_NO_CHECKOUT on
> > file basis, it's best to save the information there, not separately.
> > We do save high level information to form the checkout area (sparse
> > patterns) in the last half, but basically you should be able to live
> > without that.
>
>
> We need to mark in the index the information that reflects the worktree.
>
> If, however, we take CE_VALID to be the flag for "ignore the worktree
> entirely at this path; act as it if contains what the index contains" (and
> use this to cause that aspect of no-checkout), and we then entirely ignore
> the worktree, including not caring whether there are files there or not
> (except, of course, that in the transition from caring to not caring for
> no-checkout, we make the worktree empty, while in the case for
> "stat-is-expensive", we bring it into agreement with the index), then
> there is no additional information that needs to be conveyed in the index.
That's not enough. CE_VALID is "ignore the worktree files" while
CE_NO_CHECKOUT is stricter: "those files does (or should) not exist".
The difference is
- for "git grep", we ignore path with CE_NO_CHECKOUT (while using
cache version for CE_VALID)
- porcelain-level support to widen/narrow checkout area will need
CE_NO_CHECKOUT, not CE_VALID
>
> > > unless it's ever important to remember whether an entry is CE_VALID due to
> > > having been outside the checkout when the index was written, even though
> > > the checkout area now includes it. I don't have a good intuition as to
> > > what ought to happen if the user manually changes what's specified for
> > > checkout without actually updating the index and working tree.
> >
> > So if a user changes worktree without updating index, they will have
> > the same results as they do now: files are shown as modified if they
> > don't have CE_NO_CHECKOUT set. If those files do, they are considered
> > 'orphaned' or staled and are recommended to be removed/updated to
> > avoid unexpected consequences (not availble this this first half
> > series because that belongs to "git status").
>
>
> I was actually thinking that there would be a file for "this is what the
> user wants to have checked out" (as opposed to the index, which must
> contain "this is what is checked out"), and the porcelain would instruct
> the plumbing as to what to do with the worktree (that the plumbing with
> then ignore, due to the index bit) based on this information.
>
> The index obviously can't contain the user's full instructions for what
> should be checked out, because the user will want to say "I don't care
> about anything in Documentation/" and have this apply to
> Documentation/some-file-not-in-the-index, so that if this file is in the
> worktree, the user gets a warning.
>
> I think you're doing this with core.defaultsparse, although you seem to
> allow the index to diverge from this easily.
Yes they can.
>
> The question, then, is what happens when the index and core.defaultsparse
> disagree, either because the porcelain supports causing it or because the
> user has simply editting the config file or used plumbing to modify the
> index. That is, (1) we have index entries that say that the worktree is
> ignored, and the rules don't say they're outside the sparse checkout; do
> we care whether we expect the worktree to be empty or match the index?
> And, (2) we have index entries that say we do care about them, but the
> rules say they're outside the sparse checkout; what happens with these?
The rule is CE_NO_CHECKOUT is king. core.defaultsparse only helps
setting CE_NO_CHECKOUT on new entries when they enter the index.
So if core.defaultsparse does not match what is in index, that's fine.
You may get more files with "git merge", "git checkout".. but
already-removed files should stay removed.
If you are not happy with core.defaultsparse, you can replace it with
your own tools by manipulating directly CE_NO_CHECKOUT using "git
update-index" and "git ls-files". BTW the implementation has not had
an easy way to replace core.defaultsparse. You have to modify
apply_narrow_spec(). But if someone really needs it, a hook can be
added.
--
Duy
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Michael J Gruber @ 2008-12-08 13:10 UTC (permalink / raw)
To: Grzegorz Kossakowski; +Cc: Peter Harris, git
In-Reply-To: <493C47FD.4080302@tuffmail.com>
Grzegorz Kossakowski venit, vidit, dixit 07.12.2008 23:02:
> Peter Harris pisze:
>> After the git clone, I do the following:
>> git svn init -s svn://repo/sitory
>> git svn rebase
>>
>> No data is transferred[1], although 'git svn rebase' does spend a
>> minute or so reading the commit messages to rebuild its index.
>
> I've tried this method with Cocoon repository
> (http://jukka.zitting.name/git/?p=cocoon.git;a=summary) and got this error:
>
> git clone git://jukka.zitting.name/cocoon.git
> git svn init -s https://svn.eu.apache.org/repos/asf/cocoon/
> git svn rebase
> Unable to determine upstream SVN information from working tree history
>
> git --version
> git version 1.6.0.2
Could it be as simple as a missing "cd cocoon" between git clone and git
svn rebase? No, you probably did that.
But note that you did not follow Peter's instructions. The point is that
your clone creates "remotes/origin/trunk" whereas Peter's instructions
mirror the source, creating "remotes/trunk", which is what git svn needs
(unless you say "git svn init -s --prefix=origin/" or "git config
svn-remote.svn.fetch trunk:refs/trunk" etc.). The prefix solution should
be the best.
Michael
P.S.: Peter starts off a different layout (standard svn remotes, which
need special instructions to be cloned). Ordinary clone + git svn init
--prefix=origin/ should work fine for the cocoon layout.
P.P.S.: We can't test cocoon unless we have an account on the apache
server...
^ permalink raw reply
* [PATCH] gitweb: Fix bug in insert_file() subroutine
From: Jakub Narebski @ 2008-12-08 13:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Tatsuki Sugiura, Gerrit Pape, Recai Oktas
In-Reply-To: <7vfxl5c66h.fsf@gitster.siamese.dyndns.org>
In insert_file() subroutine (which is used to insert HTML fragments as
custom header, footer, hometext (for projects list view), and per
project README.html (for summary view)) we used:
map(to_utf8, <$fd>);
This doesn't work, and other form has to be used:
map { to_utf8($_) } <$fd>;
Now with test for t9600 added, for $GIT_DIR/README.html.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>>
>> With "close $fd" removed the patch is correct (and patches t9500*).
>
> Yeah, it passes that test here, too. Let's unleash it to 'master' and in
> an unlikely case where it still has bugs we know which commit to revert
> ;-).
I'm extremely sorry about that, but it still had bugs. I thought
I could use "map EXPR,LIST" form instead of "map BLOCK LIST" here,
i.e. "map(to_utf8, <$fd>)" instead of "map {to_utf8($_)} <$fd>;"
in original patch by Tatsuki Sugiura.
Just in case I have added check for this in t9500 gitweb test.
Once again, I'm very sorry for my buggy patches...
gitweb/gitweb.perl | 2 +-
t/t9500-gitweb-standalone-no-errors.sh | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9517392..6eb370d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2764,7 +2764,7 @@ sub insert_file {
my $filename = shift;
open my $fd, '<', $filename;
- print map(to_utf8, <$fd>);
+ print map { to_utf8($_) } <$fd>;
close $fd;
}
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index 64c4cce..43cd6ee 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -673,4 +673,14 @@ test_expect_success \
gitweb_run "p=.git;a=tree"'
test_debug 'cat gitweb.log'
+# ----------------------------------------------------------------------
+# non-ASCII in README.html
+
+test_expect_success \
+ 'README.html with non-ASCII characters (utf-8)' \
+ 'echo "<b>UTF-8 example:</b><br />" > .git/README.html &&
+ cat "$TEST_DIRECTORY"/t3900/1-UTF-8.txt >> .git/README.html &&
+ gitweb_run "p=.git;a=summary"'
+test_debug 'cat gitweb.log'
+
test_done
--
Stacked GIT 0.14.3
git version 1.6.0.4
^ 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