* [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
* 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
* 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: 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 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: 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
* [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: 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
* [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
* [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
* [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
* 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
* 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
* [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
* [ANNOUNCE] GIT 1.6.0.5
From: Junio C Hamano @ 2008-12-08 2:13 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.6.0.5 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.0.5.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.0.5.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.0.5.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also provided
as courtesy.
RPMS/$arch/git-*-1.6.0.5-1.fc9.$arch.rpm (RPM)
Although we are into 1.6.1-rc cycle, we have accumulated enough fixes to
warrant a new maintenance release, so here it is.
----------------------------------------------------------------
GIT v1.6.0.5 Release Notes
==========================
Fixes since v1.6.0.4
--------------------
* "git checkout" used to crash when your HEAD was pointing at a deleted
branch.
* "git checkout" from an un-checked-out state did not allow switching out
of the current branch.
* "git diff" always allowed GIT_EXTERNAL_DIFF and --no-ext-diff was no-op for
the command.
* Giving 3 or more tree-ish to "git diff" is supposed to show the combined
diff from second and subsequent trees to the first one, but the order was
screwed up.
* "git fast-export" did not export all tags.
* "git ls-files --with-tree=<tree>" did not work with options other
than -c, most notably with -m.
* "git pack-objects" did not make its best effort to honor --max-pack-size
option when a single first object already busted the given limit and
placed many objects in a single pack.
* "git-p4" fast import frontend was too eager to trigger its keyword expansion
logic, even on a keyword-looking string that does not have closing '$' on the
same line.
* "git push $there" when the remote $there is defined in $GIT_DIR/branches/$there
behaves more like what cg-push from Cogito used to work.
* when giving up resolving a conflicted merge, "git reset --hard" failed
to remove new paths from the working tree.
* "git tag" did not complain when given mutually incompatible set of options.
* The message constructed in the internal editor was discarded when "git
tag -s" failed to sign the message, which was often caused by the user
not configuring GPG correctly.
* "make check" cannot be run without sparse; people may have meant to say
"make test" instead, so suggest that.
* Internal diff machinery had a corner case performance bug that choked on
a large file with many repeated contents.
* "git repack" used to grab objects out of packs marked with .keep
into a new pack.
* Many unsafe call to sprintf() style varargs functions are corrected.
* Also contains quite a few documentation updates.
----------------------------------------------------------------
Changes since v1.6.0.4 are as follows:
Alexandre Julliard (2):
checkout: Don't crash when switching away from an invalid branch.
git-submodule: Avoid printing a spurious message.
Brandon Casey (12):
t7700: demonstrate mishandling of objects in packs with a .keep file
packed_git: convert pack_local flag into a bitfield and add pack_keep
pack-objects: new option --honor-pack-keep
repack: don't repack local objects in packs with .keep file
repack: do not fall back to incremental repacking with [-a|-A]
builtin-gc.c: use new pack_keep bitfield to detect .keep file existence
t7700: demonstrate mishandling of loose objects in an alternate ODB
sha1_file.c: split has_loose_object() into local and non-local counterparts
pack-objects: extend --local to mean ignore non-local loose objects too
t7700: test that 'repack -a' packs alternate packed objects
repack: only unpack-unreachable if we are deleting redundant packs
revision.c: use proper data type in call to sizeof() within xrealloc
Bryan Drewery (1):
Fix misleading wording for git-cherry-pick
Christian Couder (3):
Documentation: rev-list: change a few instances of "git-cmd" to "git cmd"
Documentation: bisect: change a few instances of "git-cmd" to "git cmd"
Documentation: fix links to "everyday.html"
Daniel Lowe (1):
Fix non-literal format in printf-style calls
Davide Libenzi (1):
xdiff: give up scanning similar lines early
Jakub Narebski (1):
gitweb: Make project specific override for 'grep' feature work
Jan Krüger (1):
Documentation: git-svn: fix example for centralized SVN clone
Jeff King (2):
commit: Fix stripping of patch in verbose mode.
tag: delete TAG_EDITMSG only on successful tag
Joey Hess (1):
sha1_file: avoid bogus "file exists" error message
Johannes Schindelin (1):
fast-export: use an unsorted string list for extra_refs
Johannes Sixt (1):
compat/mingw.c: Teach mingw_rename() to replace read-only files
Junio C Hamano (8):
Makefile: help people who run 'make check' by mistake
checkout: Fix "initial checkout" detection
Start 1.6.0.5 cycle
builtin-ls-files.c: coding style fix.
Teach ls-files --with-tree=<tree> to work with options other than -c
Teach "git diff" to honour --[no-]ext-diff
Update draft release notes to 1.6.0.5
GIT 1.6.0.5
Linus Torvalds (1):
date/time: do not get confused by fractional seconds
Martin Koegler (1):
git push: Interpret $GIT_DIR/branches in a Cogito compatible way
Matt Kraai (1):
Remove the period after the git-check-attr summary
Matt McCutchen (3):
config.txt: alphabetize configuration sections
git checkout: don't warn about unborn branch if -f is already passed
"git diff <tree>{3,}": do not reverse order of arguments
Miklos Vajna (3):
Add new testcase to show fast-export does not always exports all tags
User's Manual: remove duplicated url at the end of Appendix B
http.c: use 'git_config_string' to get 'curl_http_proxy'
Nguyễn Thái Ngọc Duy (1):
generate-cmdlist.sh: avoid selecting synopsis at wrong place
Nicolas Pitre (1):
Fix pack.packSizeLimit and --max-pack-size handling
Pete Wyckoff (1):
git-p4: fix keyword-expansion regex
Ralf Wildenhues (1):
Fix typos in the documentation.
SZEDER Gábor (2):
bash: remove dashed command leftovers
bash: offer refs instead of filenames for 'git revert'
Sam Vilain (1):
sha1_file.c: resolve confusion EACCES vs EPERM
Samuel Tardieu (2):
tag: Check that options are only allowed in the appropriate mode
tag: Add more tests about mixing incompatible modes and options
Stefan Naewe (2):
git ls-remote: make usage string match manpage
request-pull: make usage string match manpage
Thomas Rast (1):
fetch-pack: Avoid memcpy() with src==dst
^ permalink raw reply
* Re: [PATCH] git-stash: use git rev-parse -q
From: Junio C Hamano @ 2008-12-08 1:42 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Miklos Vajna, git
In-Reply-To: <20081207231723.GA5068@atjola.homenet>
Thanks; I'll revert this one. Use of -q is simply not worth this
aggravation.
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Nick Andrew @ 2008-12-08 0:03 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Grzegorz Kossakowski, git
In-Reply-To: <8c9a060812070043r472e10abu7a76152b5fe1314d@mail.gmail.com>
On Sun, Dec 07, 2008 at 12:43:32AM -0800, Jacob Helwig wrote:
> I use git-svn quite a bit at $work, but I haven't seen a way to clone
> a git repo, and have it Just Work(TM) with git-svn in the new clone,
> unfortunately.
At $work I nightly publish a .tar.gz file of a pristine git repo
synced from svn, with the metadata. So if a developer wants to start
using git they untar the file into their directory and start working,
and after that they have to do "git svn fetch" themselves.
Nick.
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Peter Harris @ 2008-12-07 23:51 UTC (permalink / raw)
To: Grzegorz Kossakowski; +Cc: git
In-Reply-To: <493C47FD.4080302@tuffmail.com>
On Sun, Dec 7, 2008 at 5:02 PM, Grzegorz Kossakowski wrote:
> 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
Odd. Usually that indicates a lack of metadata, but that repo appears
to contain the right stuff. Beats me.
Peter Harris
^ permalink raw reply
* Re: [PATCH] git-stash: use git rev-parse -q
From: Björn Steinbrink @ 2008-12-07 23:17 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1228179369-3766-1-git-send-email-vmiklos@frugalware.org>
On 2008.12.02 01:56:09 +0100, Miklos Vajna wrote:
> Don't redirect stderr to /dev/null, use -q to suppress the output on
> stderr.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> # clear_stash if we just dropped the last stash entry
> - git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
> + git rev-parse -q --verify "$ref_stash@{0}" > /dev/null || clear_stash
This one causes an error message to pop up when the last stash entry is
dropped:
doener@atjola:git (master) $ echo 123 >> Makefile
doener@atjola:git (master) $ git stash
Saved working directory and index state "WIP on master: 2dd6202...
Update draft release notes to 1.6.1"
HEAD is now at 2dd6202 Update draft release notes to 1.6.1
(To restore them type "git stash apply")
doener@atjola:git (master) $ git stash drop
Dropped refs/stash@{0} (e692e43ce03fe0b5f0eb94123123ea61a0f2097a)
fatal: Log .git/logs/refs/stash is empty.
git version 1.6.1.rc1.56.g2dd62
After "git stash drop" finished the rev-parse won't complain anymore,
even if you recreate an empty .git/logs/refs/stash file, because
.git/refs/stash is also gone, and then it doesn't seem to care anymore.
But having a valid ref and an empty log makes it unhappy:
doener@atjola:git (master) $ git rev-parse HEAD > .git/refs/stash
doener@atjola:git (master) $ : > .git/logs/refs/stash
doener@atjola:git (master) $ git rev-parse -q --verify 'refs/stash@{1}'
fatal: Log .git/logs/refs/stash is empty.
Björn
^ permalink raw reply
* Re: [PATCH] git-svn: Make following parents atomic
From: Deskin Miller @ 2008-12-07 22:24 UTC (permalink / raw)
To: git; +Cc: normalperson, gitster
In-Reply-To: <1228665970-21204-1-git-send-email-deskinm@umich.edu>
On Sun, Dec 07, 2008 at 11:06:10AM -0500, Deskin Miller wrote:
> [...]
>
> 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.
On looking at the patch again, I think I might have introduced a bug:
it'll take the most commit on the parent branch, even if it was branched
from an earlier point. I'll spend more time looking at it and should
have a v2 in a day at most if I'm rigth, hopefully more like a few
hours.
Deskin Miller
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Grzegorz Kossakowski @ 2008-12-07 22:02 UTC (permalink / raw)
To: Peter Harris, git
In-Reply-To: <eaa105840812071230l5e8d54bcg21b36019711bc3cd@mail.gmail.com>
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
Any idea what's wrong here?
> This could all be in a common script you distribute to your users.
Good suggestion.
> "git help svn" mentions the rebuild only in passing. I'm not sure if
> it is described in better detail elsewhere.
Ah, I didn't spot this earlier. Thanks.
> If something is in A's tree, it is coming from A. Either A has
> authority, or A has received authority from someone else, or A is
> bringing the legal problem down on himself. When A says "Please Pull"
> (or when A pushes) A is effectively saying "These changes are legally
> mine to give you".
>
> The Developer's Certificate of Origin 1.0 was designed to address this
> issue; see also "Signed-off-by"
>
> Of course, if it's a legal issue, make sure you consult your own lawyer.
I see. Thanks for insightful comments.
>>> You could maybe use signed tags ("git help tag")...
>> The question is why Git doesn't sign all commits by default but only tags? Creating tags all the
>> time is rather tedious process and seems to have no sense, right?
>
> Typing in your GPG passphrase for every single little commit would be
> even more tedious, IMHO.
Yep, that's true.
>> Does it mean that with current Git design it's the best to not use advanced features of Git like
>> tree merging but simply go with posting e-mails with patches instead if contributors cannot be trusted?
>
> That would be my policy. At the very least, I would have a human
> review the tree before merging it.
Agreed.
> Note that git was designed around a "git am" workflow, so it is very
> efficient at dealing with large numbers of patches at a time.
>
> Note also that you can do tree merging with an email-patch based
> workflow, since git format-patch preserves parent information,
> although it does take a little bit more work. See also: "git help am"
> under --3way.
Thanks for all your valuable information. As soon as I resolve problem with git svn rebase I'll
start reading on how git am --3way works.
--
Best regards,
Grzegorz Kossakowski
^ permalink raw reply
* Re: missing "commit | commitdiff | tree | snapshot" within we web git page
From: Jakub Narebski @ 2008-12-07 21:30 UTC (permalink / raw)
To: Toralf Förster; +Cc: git
In-Reply-To: <200812072155.52456.toralf.foerster@gmx.de>
Toralf Förster <toralf.foerster@gmx.de> writes:
> While watching this
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=shortlog
> I'm wondering why the last line doesn't contain sth. like
> "commit | commitdiff | tree | snapshot"
It contains it?
Unless you are talking about line with the 'next' link...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Daniel Barkalow @ 2008-12-07 21:26 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0812070427s64438216s41bf1294aa6398a3@mail.gmail.com>
On Sun, 7 Dec 2008, Nguyen Thai Ngoc Duy wrote:
> On 12/7/08, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > > There is not much work for CE_NO_CHECKOUT on plumbling level except
> > > some fixes. The last half of the series, for porcelain level, you will
> > > see more.
> >
> >
> > For the porcelain level, do we need the difference to be in the index? If
> > the porcelain knows the sparse checkout area and can instruct the plumbing
> > appropriately, the information shouldn't need to be stored in the index
>
> 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.
> > 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.
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?
Case (1) is where we would need to know, in the index, whether we expect
the worktree to actually match the index (traditional CE_VALID) or whether
we expect the worktree to be empty (CE_NO_CHECKOUT), if our behavior
should actually differ. My vague feeling is that we don't want it to
differ, and these paths are unexpectional "interesting to the user, but
the worktree is ignored" until reading a tree into the index again. (But
note that we will have to check on the worktree when reading into the
index if this changes the index from "blobA, CE_VALID" to
"blobA, !CE_VALID", since the worktree could differ in a way that we don't
want to retain. And I think we want it to be an error to have the worktree
be something other than blobA or nothing before, but "nothing" is fine and
we just write it out. (This means that users of CE_VALID who remove files
behind git's back may lose their removal work; but this is a pretty
trivial danger).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* missing "commit | commitdiff | tree | snapshot" within we web git page
From: Toralf Förster @ 2008-12-07 20:55 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 314 bytes --]
While watching this
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=shortlog
I'm wondering why the last line doesn't contain sth. like
"commit | commitdiff | tree | snapshot"
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Peter Harris @ 2008-12-07 20:30 UTC (permalink / raw)
To: Grzegorz Kossakowski; +Cc: git
In-Reply-To: <493C1F36.7050504@tuffmail.com>
On Sun, Dec 7, 2008 at 2:08 PM, Grzegorz Kossakowski wrote:
> Peter Harris pisze:
>> Make sure you don't use the --no-metadata flag when setting up
>> git-svn. This will embed the metadata into commit messages, so git-svn
>> can rebuild it from scratch whenever it needs to. (You probably also
>> want git 1.6.1rc for incremental rebuild support). This also has the
>> advantage that you can see the svn revision number when looking at a
>> commit message.
>
> Not sure what you exactly mean here. Do you mean that if metadata is included in commit messages
> then there is an easy way to initialize git-svn after cloning the repo?
Yes.
> By easy I mean:
> a) it does not require to much of interactive actions to be performed
> b) it does not pull too much from svn server
>
> Point b) is important because we usually have quite large repositories.
To set up the remotes to mirror the remote svn-remotes, I do the clone manually:
git init
git remote add origin git://svn/mirror
git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
git fetch
git reset --hard trunk
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.
This could all be in a common script you distribute to your users.
> Also, could you point me to a place where this rebuild support is described? I would like to know
> what our committer has to do after cloning from Jukka's server.
"git help svn" mentions the rebuild only in passing. I'm not sure if
it is described in better detail elsewhere.
>> In terms of re-pulling from the git-svn mirror, git-svn will create
>> the same commits (with the same sha1s) from svn every time, so there
>> will be no conflicts there.
>
> Just to make sure: so if one person pulls from git-svn mirror and another one pulls using git svn
> rebase they result in the same tree right?
Yes[2].
>> If C doesn't trust A, C should not pull from A. C should pull only
>> from (trusted) B. Presumably B knows who (of A and B) did which work,
>> and B's repository can be trusted?
>>
>> If neither of A or B can be trusted, then you have problems that a
>> computer cannot solve for you.
>
> Yep, I was having in mind the case when both A and B are untrusted. I don't want my computer to
> check if something coming from A or B is safe or not I just want to know which bits are coming from
> A and which from B.
>
> This is really important for us because of legal reasons.
If something is in A's tree, it is coming from A. Either A has
authority, or A has received authority from someone else, or A is
bringing the legal problem down on himself. When A says "Please Pull"
(or when A pushes) A is effectively saying "These changes are legally
mine to give you".
The Developer's Certificate of Origin 1.0 was designed to address this
issue; see also "Signed-off-by"
Of course, if it's a legal issue, make sure you consult your own lawyer.
>> You could maybe use signed tags ("git help tag")...
>
> The question is why Git doesn't sign all commits by default but only tags? Creating tags all the
> time is rather tedious process and seems to have no sense, right?
Typing in your GPG passphrase for every single little commit would be
even more tedious, IMHO.
> Does it mean that with current Git design it's the best to not use advanced features of Git like
> tree merging but simply go with posting e-mails with patches instead if contributors cannot be trusted?
That would be my policy. At the very least, I would have a human
review the tree before merging it.
Note that git was designed around a "git am" workflow, so it is very
efficient at dealing with large numbers of patches at a time.
Note also that you can do tree merging with an email-patch based
workflow, since git format-patch preserves parent information,
although it does take a little bit more work. See also: "git help am"
under --3way.
Peter Harris
[1] Not strictly true. git-svn does contact the svn server to see if
there are any revisions newer than the latest present in the git repo,
and will transfer those revisions (if any).
[2] Unless (a) someone edited the svn:log (or other) revprop in
between, or (b) you triggered the bug I saw reported (and fixed?) on
this list today. I've never personally triggered (b), but I have seen
(a).
^ 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