* Re: log -p hides changes in merge commit
From: Phillip Susi @ 2011-01-07 19:27 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git
In-Reply-To: <20110106210438.GB15090@burratino>
On 1/6/2011 4:04 PM, Jonathan Nieder wrote:
> In case (1), -c will show a "combined diff" for files where master
> does not match either the old master or topic. --cc, on the other
> hand, will correctly suppress these uninteresting diffs.
>
> In case (2), -c will show a noisy "combined diff" as before.
> --cc will show a combined diff when the changes from both parents
> touch nearby code, even if it merged trivially.
>
> In case (3), -c and --cc will show the semantically boring but
> syntactically interesting merge.
>
> Case (4) is underspecified. So let's give a more precise example:
> the old master and topic tried to fix the same bug in two incompatible
> ways. When merging, I decide I like the topic's way better, so I
> resolve conflicts in favor of the topic. Hopefully all unrelated
> changes on master were preserved!
>
> In this case, -c and --cc will very likely show nothing at all.
> Each file matches one of the two parents (old master or topic) so
> there is no easy way to distinguish the case from (0) or (1).
That does help me understand the difference between -c and -cc, but I
still don't see why one or the other is not the default behavior of log
-p, instead of opting to never show anything at all for merges?
^ permalink raw reply
* Re: [PATCH] Mark gitk script executable
From: Junio C Hamano @ 2011-01-07 19:29 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Anders Kaseorg, git, Paul Mackerras
In-Reply-To: <20110107030119.GA32290@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>> Anders Kaseorg <andersk@MIT.EDU> writes:
>
>>> The executable bit on gitk-git/gitk was lost (accidentally it seems) by
>>> commit 62ba5143ec2ab9d4083669b1b1679355e7639cd5. Put it back, so that
>>> gitk can be run directly from a git.git checkout.
>>>
>>> Note that the script is already executable in gitk.git, just not in
>>> git.git.
>>
>> It did not lose the bit by accident but 62ba5143 pretty much was a
>> deliberate fix. "gitk" is a source file, and its build product,
>> gitk-wish, is what is eventually installed with executable bit on.
>
> How does this case differ from other executable source files like
> git-am.sh?
Ok, strike that.
In the old days, some of us (but not me) used to value somewhat to be able
to run git-$frotz.sh from the build directory before installing, and having
the executable bit was in line with that philosophy.
I don't know if it still hold today, though. For one thing, our Makefile
replace a lot more than it used to when building $(SCRIPTS) out of the
source files and git-$frotz.sh may not run in place as easily as before
anymore.
So it doesn't matter too much either way (and of course you can always say
"sh ./git-$frotz.sh" when it is not executable and the functioning of the
script does not depend on replacement done by the Makefile).
It seems that the majority is marked with executable bit, so just for the
sake of uniformity it probably is Ok to make it executable. From a
purist's point of view, I'd rather see them uniformly marked as
non-executable, but as I said, it doesn't matter much to me (iow, meh).
The change needs to come from gitk repository, so I'll leave it up to Paul
;-)
Thanks for a sanity, Jonathan.
^ permalink raw reply
* Re: clone breaks replace
From: Phillip Susi @ 2011-01-07 19:43 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Christian Couder
In-Reply-To: <20110106213338.GA15325@burratino>
On 1/6/2011 4:33 PM, Jonathan Nieder wrote:
> Therefore if you want clients to be able to choose between a minimal
> history and a larger one to save bandwidth, it has to work like this
>
> - to get the minimal history, fetch _without_ any replacement refs
> - to get the full history, fetch the replacement refs on top of that.
>
> because an additional reference can only increase the number of
> objects to be downloaded.
This seems backwards. The original commit links to its parent and
therefore, the full history trail going back. The reason you add the
replacement record is to get rid of that parent link, thus truncating
the history. Therefore, if you fetch the original record that still has
the reference to its parent, and not the replacement record, you end up
with the full history. Ergo, to get only the truncated history, you
must fetch the replacement record, and pay attention to it to stop
fetching commits older than the truncation point.
> 3. Use "git filter-branch" to make that history a reality (branch
> "simpler"). Remove the replacement refs.
Isn't the whole purpose of using replace to avoid having to use
filter-branch, which throws out all of the existing commit records, and
creates an entirely new commit chain that is slightly modified?
> 4. Use "git replace" to graft back on the pieces you cauterized.
> Publish the result.
If you are going to use filter-branch, then what do you need to replace?
And publishing the result of a replace seems to have no effect, since
other people do not get the replace ref when they clone.
> 5. Perhaps also run and publish "git replace big simpler", so
> contributors of branches based against the old 'big' can merge
> your latest changes from 'simpler'. Encourage contributors to
> use 'git rebase' or 'git filter-branch' to rebase their
> contributions against the new, simpler history.
Again, the entire point of replace seems to be to AVOID having to go
through the hassle of having to rebase or filter-branch. Isn't that
exactly how you would accomplish this before replace was added?
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Junio C Hamano @ 2011-01-07 19:44 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20110107104650.GA5399@pengutronix.de>
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
> So working copy and cache are at refs/tags/sgu/mxs-amba-uart, HEAD
> points to refs/heads/sgu/mxs-amba-uart
I somehow thought that we had an explicit logic to favor an exact branch
name for "git checkout $branch" even when refs/something-other-than-head/$branch
exists, while issuing the ambiguity warning.
Ahh, what this part of the code in builtin/checkout.c does is totally
wrong:
/* we can't end up being in (2) anymore, eat the argument */
argv++;
argc--;
new.name = arg;
if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
setup_branch_path(&new);
if ((check_ref_format(new.path) == CHECK_REF_FORMAT_OK) &&
resolve_ref(new.path, rev, 1, NULL))
;
else
new.path = NULL;
parse_commit(new.commit);
source_tree = new.commit->tree;
} else
source_tree = parse_tree_indirect(rev);
It uses lookup_commit_reference_gently() that follows the usual
tags-then-heads preference order, but then uses setup_branch_path() to
prefix the raw name with "refs/heads", which is totally backwards.
It should do something like:
- use setup-branch-path to get refs/heads/$name
- check-ref-format and resolve it; if these fail, then we are detaching
head at rev;
- otherwise, if the result of the resolution is not the same as rev, what
we have in rev is incorrect (it was taken from the usual
tags-then-heads rule but "checkout $name" must favor local branches).
update the rev with the result of resolving refs/heads/$name
- parse new.commit out of rev. we are checking out the branch $name.
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Jeff King @ 2011-01-07 19:49 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20110107104650.GA5399@pengutronix.de>
On Fri, Jan 07, 2011 at 11:46:50AM +0100, Uwe Kleine-König wrote:
> ukl@octopus:~/gsrc/linux-2.6$ git diff; git diff --cached
>
> ukl@octopus:~/gsrc/linux-2.6$ git checkout sgu/mxs-amba-uart
> warning: refname 'sgu/mxs-amba-uart' is ambiguous.
> Previous HEAD position was c13fb17... Merge commit '65e29a85a419f9a161ab0f09f9d69924e36d940e' into HEAD
> Switched to branch 'sgu/mxs-amba-uart'
>
> OK, it might be a bad idea to have this ambiguity, still ...
> [...]
> So working copy and cache are at refs/tags/sgu/mxs-amba-uart, HEAD
> points to refs/heads/sgu/mxs-amba-uart
Yeah, we generally resolve ambiguities in favor of the tag (and that
warning comes from deep within get_sha1_basic). So the real bug here is
that it still said "Switched to branch", which is totally wrong.
That being said, it probably would make more sense for "git checkout" to
prefer branches to tags. That's probably going to take a lot more
surgery, and we're in -rc right now. So I think the best thing to do is
to fix the broken message and add some tests, and then if somebody wants
to revisit it with a larger patch, they can do so on top.
I'll work on the first part and post a patch in a few minutes.
-Peff
^ permalink raw reply
* Re: [PATCH] commit: suggest --amend --reset-author to fix commiter identity
From: Junio C Hamano @ 2011-01-07 19:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1294409671-5479-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> The advantage of this command is that it is cut-and-paste ready, while
> using --author='...' requires the user to type his name and email a
> second time.
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> builtin/commit.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 22ba54f..440223c 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -47,7 +47,11 @@ static const char implicit_ident_advice[] =
> "\n"
> "If the identity used for this commit is wrong, you can fix it with:\n"
> "\n"
> -" git commit --amend --author='Your Name <you@example.com>'\n";
> +" git commit --amend --author='Your Name <you@example.com>'\n"
> +"\n"
> +"or\n"
> +"\n"
> +" git commit --amend --reset-author\n";
I don't think making the "cheat-sheet" insn longer by offering more
choices is a good idea. These are messages for lazy and busy people.
Wouldn't it work better to just get rid of the longer form and say
something like:
... here is how to tell your name to git (existing message) ...
After doing the above, run
git commit --amend --reset-author
to fix the identity used for this commit.
^ permalink raw reply
* Re: 'git add' option to non-interactively stage working tree changes
From: Andreas Schwab @ 2011-01-07 19:52 UTC (permalink / raw)
To: Hrvoje Nikšić; +Cc: git
In-Reply-To: <AANLkTimLKZnVn8Lr-E-8M8T5mXA55XabCT5rC+broeFJ@mail.gmail.com>
Hrvoje Nikšić <hniksic@gmail.com> writes:
> Specifying the root may seem innocuous, but it is inconsistent with
> "git diff" and "git commit [-a]", which don't care where in the tree
> you are.
You can always use "$(git rev-parse --show-cdup)." as the root.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Jeff King @ 2011-01-07 19:54 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Junio C Hamano, git
In-Reply-To: <20110107194909.GB6175@sigill.intra.peff.net>
On Fri, Jan 07, 2011 at 02:49:09PM -0500, Jeff King wrote:
> That being said, it probably would make more sense for "git checkout" to
> prefer branches to tags. That's probably going to take a lot more
> surgery, and we're in -rc right now. So I think the best thing to do is
> to fix the broken message and add some tests, and then if somebody wants
> to revisit it with a larger patch, they can do so on top.
>
> I'll work on the first part and post a patch in a few minutes.
Ah, never mind. After reading Junio's response, it looks like we already
try to do the right thing in checkout, but it's just broken. So forget
my two-step plan.
Here is the test script I worked out which shows the issue (and checks
that the right messages are shown to the user):
---
t/t2019-checkout-amiguous-ref.sh | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
create mode 100755 t/t2019-checkout-amiguous-ref.sh
diff --git a/t/t2019-checkout-amiguous-ref.sh b/t/t2019-checkout-amiguous-ref.sh
new file mode 100755
index 0000000..12edce8
--- /dev/null
+++ b/t/t2019-checkout-amiguous-ref.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+test_description='checkout handling of ambiguous (branch/tag) refs'
+. ./test-lib.sh
+
+test_expect_success 'setup ambiguous refs' '
+ test_commit branch file &&
+ git branch ambiguity &&
+ test_commit tag file &&
+ git tag ambiguity &&
+ test_commit other file
+'
+
+test_expect_success 'checkout ambiguous ref succeeds' '
+ git checkout ambiguity >stdout 2>stderr
+'
+
+test_expect_success 'checkout produces ambiguity warning' '
+ grep "warning.*ambiguous" stderr
+'
+
+test_expect_failure 'checkout chooses branch over tag' '
+ echo branch >expect &&
+ test_cmp expect file
+'
+
+test_expect_success 'checkout reports switch to detached HEAD' '
+ grep "Switched to branch" stderr &&
+ ! grep "^HEAD is now at" stderr
+'
+
+test_done
--
1.7.4.rc1.23.g84303
^ permalink raw reply related
* Re: 'git add' option to non-interactively stage working tree changes
From: Hrvoje Nikšić @ 2011-01-07 20:03 UTC (permalink / raw)
To: git
In-Reply-To: <m2aajcbiei.fsf@igel.home>
On Fri, Jan 7, 2011 at 8:52 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Hrvoje Nikšić <hniksic@gmail.com> writes:
>
>> Specifying the root may seem innocuous, but it is inconsistent with
>> "git diff" and "git commit [-a]", which don't care where in the tree
>> you are.
>
> You can always use "$(git rev-parse --show-cdup)." as the root.
Thanks for the tip. I'll note that this is not exactly easy to
discover, though, and it's quite some typing. Since git add -p and git
add -i seem capable of determining the root themselves, maybe there
should be a way to do the same for -u? Or even make it the default?
^ permalink raw reply
* Re: Why don't git-init and git-clone probe for core.ignorecase on Windows > XP?
From: Junio C Hamano @ 2011-01-07 20:18 UTC (permalink / raw)
To: Dun Peal; +Cc: Git ML
In-Reply-To: <AANLkTimqgCsmC96fkWQJ0yB+FuyC6Xkgn3UAfZrqMqK_@mail.gmail.com>
Dun Peal <dunpealer@gmail.com> writes:
> The git-config manpage says about core.ignorecase:
>
> "The default is false, except git-clone(1) or git-init(1) will probe
> and set core.ignorecase true if appropriate when the repository is
> created."
>
> I assume this is happening when you clone or init on FAT, which is
> explicitly mentioned earlier in that section. But apparently it
> doesn't happen for either XP, Vista or 7. While those newer releases
> use NTFS, which technically supports case-sensitivity, the operating
> itself still apparently doesn't, so it would seem like git-clone and
> git-init should probe regarding the core.ignorecase on any version of
> Windows, no?
Sorry, but it is unclear if you are complaining that core.ignorecase is
set (but you believe it shouldn't be) or it is not set (but you believe it
should be) on NTFS from the description.
As far as I can tell from the code (I obviously only look at the plain
vanilla git, and msysgit might have some patch to this part, I dunno. Oh
by the way you didn't say which version you are complaining about,
either), we do the probing on all systems (including POSIX folks with FAT
filesystem mounted) by first creating .git/config and then checking if a
file .git/CoNfIg which we know we never created can be accessed. If we
can, that means the filesystem ignores case, iow, we cannot have two files
config and CoNfIg at the same time, and set core.ignorecase to true.
^ permalink raw reply
* Re: bug in gitk: history moves right when scrolling up and down with mouse wheel
From: Uwe Kleine-König @ 2011-01-07 20:22 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <4D275F02.1030100@gmail.com>
On Fri, Jan 07, 2011 at 12:44:18PM -0600, Neal Kreitzinger wrote:
> On 1/7/2011 4:55 AM, Uwe Kleine-König wrote:
>> Hello,
>>
>> I don't know yet how to reliably trigger that, but it feels scary.
>>
>> If that help, it happens with the view
>>
>> {karo {} ^linus/master {git for-each-ref --format='%(refname)' refs/remotes/customers/karo refs/heads/karo}}
>>
>> If I knew how to record a video of my screen, I'd do this. Maybe
>> someone knows? Maybe this report is already enough?
>>
>> Happens with Debian's git 1:1.7.2.3-2.2.
>>
>
> Actually, I've wanted the ability to scroll left and right in the
> history pane for quite a while. Resorting to shrinking the fontsize and
> the other columns only goes so far when trying to see a list of
> equivalent refs. If the ability to scroll left and right can be kept
> that would be cool.
you can press the middle mouse button and move it left/right to scroll
sideways. (This is standard for tcl/tk apps.) But this is not my problem.
I turn the scroll wheel and the window scrolls up and down (which is
expected and good). But at the same time parts of the *content* of the
window starts moving right and so make the (virtual) window broader.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: bug in gitk: history moves right when scrolling up and down with mouse wheel
From: Stefan Haller @ 2011-01-07 20:24 UTC (permalink / raw)
To: Neal Kreitzinger, Uwe Kleine-König; +Cc: git
In-Reply-To: <4D275F02.1030100@gmail.com>
Neal Kreitzinger <nkreitzinger@gmail.com> wrote:
> Actually, I've wanted the ability to scroll left and right in the
> history pane for quite a while. Resorting to shrinking the fontsize and
> the other columns only goes so far when trying to see a list of
> equivalent refs. If the ability to scroll left and right can be kept
> that would be cool.
Interesting. On the Mac it *is* possible to scroll left and right, and
it absolutely drives me nuts, so I disabled it in my private build.
I guess it's ok with a mouse, where shift-wheel scrolls horizontally,
but on a track-pad with two-finger scrolling, where you can scroll both
horizontally and vertically with a single guesture, it is completely
undesirable.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ permalink raw reply
* Re: log -p hides changes in merge commit
From: Junio C Hamano @ 2011-01-07 20:27 UTC (permalink / raw)
To: Phillip Susi; +Cc: Jonathan Nieder, git
In-Reply-To: <4D276926.2020407@cfl.rr.com>
Phillip Susi <psusi@cfl.rr.com> writes:
> That does help me understand the difference between -c and -cc, but I
> still don't see why one or the other is not the default behavior of log
> -p, instead of opting to never show anything at all for merges?
Assuming this is about the default, the answer is very simple. The
features to support -c and --cc came _much_ later than -p, and many people
have got used to the default behaviour after using "log -p" for a long
time. It simply is rude to change the default on them.
As -c or --cc won't do anything special on a non-merge commit, you can
always say "log -p --cc" if that output is what you want to see.
^ permalink raw reply
* Re: [PATCH] Mark gitk script executable
From: Anders Kaseorg @ 2011-01-07 20:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Paul Mackerras
In-Reply-To: <7v4o9k7brc.fsf@alter.siamese.dyndns.org>
On Fri, 7 Jan 2011, Junio C Hamano wrote:
> The change needs to come from gitk repository, so I'll leave it up to Paul
> ;-)
No, the script has always been executable in gitk.git. The patch should
be applied directly to git.git to bring the two repositories in sync.
Anders
^ permalink raw reply
* Re: 'git add' option to non-interactively stage working tree changes
From: Junio C Hamano @ 2011-01-07 20:44 UTC (permalink / raw)
To: Hrvoje Nikšić; +Cc: git
In-Reply-To: <AANLkTi=iwOGv3PzrRcVGDwwoTXmJ4CuC11vuYsjn4xxV@mail.gmail.com>
Hrvoje Nikšić <hniksic@gmail.com> writes:
> Thanks for the tip. I'll note that this is not exactly easy to
> discover, though, and it's quite some typing. Since git add -p and git
> add -i seem capable of determining the root themselves, maybe there
> should be a way to do the same for -u? Or even make it the default?
The general design principle when talking about an operation to build
towards the next commit is to limit the operation to the current working
directory when working from a subdirectory, so I would have to say that
what -p and -i do is wrong, but this is already a very well established
behaviour and there is no way to change the default (the same thing can be
said for what -u does).
I think it might be Ok to introduce a --full-tree option to "git add" (and
"git grep"), though. But introduction of corresponding configuration
variable to flip the default needs to be done carefully in steps across
major version boundaries as usual (i.e. first introduce --no-full-tree,
wait for 9 to 12 months to make sure scripts are updated, then start
honoring add.fullTree and grep.fullTree configuration variables).
^ permalink raw reply
* Re: [PATCH] Mark gitk script executable
From: Junio C Hamano @ 2011-01-07 20:45 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: Junio C Hamano, Jonathan Nieder, git, Paul Mackerras
In-Reply-To: <alpine.DEB.2.02.1101071526180.31807@dr-wily.mit.edu>
Anders Kaseorg <andersk@MIT.EDU> writes:
> On Fri, 7 Jan 2011, Junio C Hamano wrote:
>> The change needs to come from gitk repository, so I'll leave it up to Paul
>> ;-)
>
> No, the script has always been executable in gitk.git. The patch should
> be applied directly to git.git to bring the two repositories in sync.
If that is the case perhaps the next pull will fix that ;-)
^ permalink raw reply
* [PATCH] git-cvs*: Make building (and testing) of CVS interface scripts optionally selectable
From: Robin H. Johnson @ 2011-01-07 20:48 UTC (permalink / raw)
To: git; +Cc: Robin H. Johnson
Presently, the CVS interface scripts are always built, and their
test-suites run based on a binary named 'cvs' happening to return zero.
If there something other than the real CVS there, bad things happened
during the test-suite run.
This patch implements NO_CVS in the manner of NO_PERL, and ensures that
the CVS scripts get the unimplemented variant when appropriate, as well
as making sure that the tests properly declare CVS as a prerequisite
(shortcut to test_done like the Perl prerequisites).
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
X-Gentoo-Bug: 350330
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=350330
---
Makefile | 37 ++++++++++++++++++++++++--------
t/t9200-git-cvsexportcommit.sh | 5 ++++
t/t9400-git-cvsserver-server.sh | 8 ++++++-
t/t9401-git-cvsserver-crlf.sh | 15 ++++++++----
t/t9600-cvsimport.sh | 41 ++++++++++++++++++++++-------------
t/t9601-cvsimport-vendor-branch.sh | 11 +++++++++
t/t9602-cvsimport-branches-tags.sh | 11 +++++++++
t/t9603-cvsimport-patchsets.sh | 11 +++++++++
t/test-lib.sh | 1 +
9 files changed, 110 insertions(+), 30 deletions(-)
diff --git a/Makefile b/Makefile
index 775ee83..158489a 100644
--- a/Makefile
+++ b/Makefile
@@ -188,6 +188,8 @@ all::
#
# Define NO_TCLTK if you do not want Tcl/Tk GUI.
#
+# Define NO_CVS if you do not want any CVS interface utilities.
+#
# The TCL_PATH variable governs the location of the Tcl interpreter
# used to optimize git-gui for your system. Only used if NO_TCLTK
# is not set. Defaults to the bare 'tclsh'.
@@ -347,6 +349,7 @@ LIB_OBJS =
PROGRAM_OBJS =
PROGRAMS =
SCRIPT_PERL =
+SCRIPT_PERL_CVS =
SCRIPT_PYTHON =
SCRIPT_SH =
SCRIPT_LIB =
@@ -384,17 +387,18 @@ SCRIPT_LIB += git-sh-setup
SCRIPT_PERL += git-add--interactive.perl
SCRIPT_PERL += git-difftool.perl
SCRIPT_PERL += git-archimport.perl
-SCRIPT_PERL += git-cvsexportcommit.perl
-SCRIPT_PERL += git-cvsimport.perl
-SCRIPT_PERL += git-cvsserver.perl
SCRIPT_PERL += git-relink.perl
SCRIPT_PERL += git-send-email.perl
SCRIPT_PERL += git-svn.perl
+SCRIPT_PERL_CVS += git-cvsexportcommit.perl
+SCRIPT_PERL_CVS += git-cvsimport.perl
+SCRIPT_PERL_CVS += git-cvsserver.perl
+
SCRIPT_PYTHON += git-remote-testgit.py
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
- $(patsubst %.perl,%,$(SCRIPT_PERL)) \
+ $(patsubst %.perl,%,$(SCRIPT_PERL) $(SCRIPT_PERL_CVS)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
git-instaweb
@@ -1721,13 +1725,25 @@ $(SCRIPT_LIB) : % : %.sh
$(QUIET_GEN)$(cmd_munge_script) && \
mv $@+ $@
+_SCRIPT_PERL_BUILD =
+_SCRIPT_PERL_NOBUILD =
+
ifndef NO_PERL
-$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
+
+_SCRIPT_PERL_BUILD += $(SCRIPT_PERL)
+
+ifndef NO_CVS
+_SCRIPT_PERL_BUILD += $(SCRIPT_PERL_CVS)
+else # NO_CVS
+_SCRIPT_PERL_NOBUILD += $(SCRIPT_PERL_CVS)
+endif # NO_CVS
+
+$(patsubst %.perl,%,$(_SCRIPT_PERL_BUILD)): perl/perl.mak
perl/perl.mak: GIT-CFLAGS perl/Makefile perl/Makefile.PL
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' $(@F)
-$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
+$(patsubst %.perl,%,$(_SCRIPT_PERL_BUILD)): % : %.perl
$(QUIET_GEN)$(RM) $@ $@+ && \
INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
@@ -1784,14 +1800,17 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/static/gitweb.css gitweb/
chmod +x $@+ && \
mv $@+ $@
else # NO_PERL
-$(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh
+_SCRIPT_PERL_NOBUILD += $(SCRIPT_PERL) $(SCRIPT_PERL_CVS) git-instaweb
+endif # NO_PERL
+
+# This is any perl scripts that were disabled it might be empty...
+$(patsubst %.perl,%,$(_SCRIPT_PERL_NOBUILD)): % : unimplemented.sh
$(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's|@@REASON@@|NO_PERL=$(NO_PERL)|g' \
unimplemented.sh >$@+ && \
chmod +x $@+ && \
mv $@+ $@
-endif # NO_PERL
ifndef NO_PYTHON
$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS
@@ -1826,7 +1845,7 @@ configure: configure.ac
# These can record GIT_VERSION
git.o git.spec \
$(patsubst %.sh,%,$(SCRIPT_SH)) \
- $(patsubst %.perl,%,$(SCRIPT_PERL)) \
+ $(patsubst %.perl,%,$(SCRIPT_PERL) $(SCRIPT_PERL_CVS)) \
: GIT-VERSION-FILE
TEST_OBJS := $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index e5da65b..4b3f010 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -12,6 +12,11 @@ if ! test_have_prereq PERL; then
test_done
fi
+if ! test_have_prereq CVS; then
+ skip_all='skipping git cvsexportcommit tests, cvs not available'
+ test_done
+fi
+
cvs >/dev/null 2>&1
if test $? -ne 1
then
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 9199550..52ea99d 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -11,9 +11,15 @@ cvs CLI client via git-cvsserver server'
. ./test-lib.sh
if ! test_have_prereq PERL; then
- skip_all='skipping git cvsserver tests, perl not available'
+ skip_all='skipping git-cvsserver tests, perl not available'
test_done
fi
+
+if ! test_have_prereq CVS; then
+ skip_all='skipping git-cvsserver tests, cvs not available'
+ test_done
+fi
+
cvs >/dev/null 2>&1
if test $? -ne 1
then
diff --git a/t/t9401-git-cvsserver-crlf.sh b/t/t9401-git-cvsserver-crlf.sh
index ff6d6fb..f0d7aad 100755
--- a/t/t9401-git-cvsserver-crlf.sh
+++ b/t/t9401-git-cvsserver-crlf.sh
@@ -38,15 +38,20 @@ not_present() {
fi
}
-cvs >/dev/null 2>&1
-if test $? -ne 1
+if ! test_have_prereq PERL
then
- skip_all='skipping git-cvsserver tests, cvs not found'
+ skip_all='skipping git-cvsserver tests, perl not available'
test_done
fi
-if ! test_have_prereq PERL
+if ! test_have_prereq CVS
then
- skip_all='skipping git-cvsserver tests, perl not available'
+ skip_all='skipping git-cvsserver tests, cvs not available'
+ test_done
+fi
+cvs >/dev/null 2>&1
+if test $? -ne 1
+then
+ skip_all='skipping git-cvsserver tests, cvs not found'
test_done
fi
"$PERL_PATH" -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 4c384ff..d601f32 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -3,14 +3,25 @@
test_description='git cvsimport basic tests'
. ./lib-cvs.sh
-test_expect_success PERL 'setup cvsroot environment' '
+if ! test_have_prereq PERL
+then
+ skip_all='skipping git cvsimport tests, perl not available'
+ test_done
+fi
+if ! test_have_prereq CVS
+then
+ skip_all='skipping git cvsimport tests, cvs not available'
+ test_done
+fi
+
+test_expect_success 'setup cvsroot environment' '
CVSROOT=$(pwd)/cvsroot &&
export CVSROOT
'
-test_expect_success PERL 'setup cvsroot' '$CVS init'
+test_expect_success 'setup cvsroot' '$CVS init'
-test_expect_success PERL 'setup a cvs module' '
+test_expect_success 'setup a cvs module' '
mkdir "$CVSROOT/module" &&
$CVS co -d module-cvs module &&
@@ -42,23 +53,23 @@ EOF
)
'
-test_expect_success PERL 'import a trivial module' '
+test_expect_success 'import a trivial module' '
git cvsimport -a -R -z 0 -C module-git module &&
test_cmp module-cvs/o_fortuna module-git/o_fortuna
'
-test_expect_success PERL 'pack refs' '(cd module-git && git gc)'
+test_expect_success 'pack refs' '(cd module-git && git gc)'
-test_expect_success PERL 'initial import has correct .git/cvs-revisions' '
+test_expect_success 'initial import has correct .git/cvs-revisions' '
(cd module-git &&
git log --format="o_fortuna 1.1 %H" -1) > expected &&
test_cmp expected module-git/.git/cvs-revisions
'
-test_expect_success PERL 'update cvs module' '
+test_expect_success 'update cvs module' '
(cd module-cvs &&
cat <<EOF >o_fortuna &&
O Fortune,
@@ -86,7 +97,7 @@ EOF
)
'
-test_expect_success PERL 'update git module' '
+test_expect_success 'update git module' '
(cd module-git &&
git config cvsimport.trackRevisions true &&
@@ -97,7 +108,7 @@ test_expect_success PERL 'update git module' '
'
-test_expect_success PERL 'update has correct .git/cvs-revisions' '
+test_expect_success 'update has correct .git/cvs-revisions' '
(cd module-git &&
git log --format="o_fortuna 1.1 %H" -1 HEAD^ &&
@@ -105,7 +116,7 @@ test_expect_success PERL 'update has correct .git/cvs-revisions' '
test_cmp expected module-git/.git/cvs-revisions
'
-test_expect_success PERL 'update cvs module' '
+test_expect_success 'update cvs module' '
(cd module-cvs &&
echo 1 >tick &&
@@ -114,7 +125,7 @@ test_expect_success PERL 'update cvs module' '
)
'
-test_expect_success PERL 'cvsimport.module config works' '
+test_expect_success 'cvsimport.module config works' '
(cd module-git &&
git config cvsimport.module module &&
@@ -126,7 +137,7 @@ test_expect_success PERL 'cvsimport.module config works' '
'
-test_expect_success PERL 'second update has correct .git/cvs-revisions' '
+test_expect_success 'second update has correct .git/cvs-revisions' '
(cd module-git &&
git log --format="o_fortuna 1.1 %H" -1 HEAD^^ &&
@@ -135,7 +146,7 @@ test_expect_success PERL 'second update has correct .git/cvs-revisions' '
test_cmp expected module-git/.git/cvs-revisions
'
-test_expect_success PERL 'import from a CVS working tree' '
+test_expect_success 'import from a CVS working tree' '
$CVS co -d import-from-wt module &&
(cd import-from-wt &&
@@ -148,12 +159,12 @@ test_expect_success PERL 'import from a CVS working tree' '
'
-test_expect_success PERL 'no .git/cvs-revisions created by default' '
+test_expect_success 'no .git/cvs-revisions created by default' '
! test -e import-from-wt/.git/cvs-revisions
'
-test_expect_success PERL 'test entire HEAD' 'test_cmp_branch_tree master'
+test_expect_success 'test entire HEAD' 'test_cmp_branch_tree master'
test_done
diff --git a/t/t9601-cvsimport-vendor-branch.sh b/t/t9601-cvsimport-vendor-branch.sh
index 827d39f..d730a41 100755
--- a/t/t9601-cvsimport-vendor-branch.sh
+++ b/t/t9601-cvsimport-vendor-branch.sh
@@ -34,6 +34,17 @@
test_description='git cvsimport handling of vendor branches'
. ./lib-cvs.sh
+if ! test_have_prereq PERL
+then
+ skip_all='skipping git cvsimport tests, perl not available'
+ test_done
+fi
+if ! test_have_prereq CVS
+then
+ skip_all='skipping git cvsimport tests, cvs not available'
+ test_done
+fi
+
setup_cvs_test_repository t9601
test_expect_success PERL 'import a module with a vendor branch' '
diff --git a/t/t9602-cvsimport-branches-tags.sh b/t/t9602-cvsimport-branches-tags.sh
index e1db323..68f0974 100755
--- a/t/t9602-cvsimport-branches-tags.sh
+++ b/t/t9602-cvsimport-branches-tags.sh
@@ -6,6 +6,17 @@
test_description='git cvsimport handling of branches and tags'
. ./lib-cvs.sh
+if ! test_have_prereq PERL
+then
+ skip_all='skipping git cvsimport tests, perl not available'
+ test_done
+fi
+if ! test_have_prereq CVS
+then
+ skip_all='skipping git cvsimport tests, cvs not available'
+ test_done
+fi
+
setup_cvs_test_repository t9602
test_expect_success PERL 'import module' '
diff --git a/t/t9603-cvsimport-patchsets.sh b/t/t9603-cvsimport-patchsets.sh
index 52034c8..db4d682 100755
--- a/t/t9603-cvsimport-patchsets.sh
+++ b/t/t9603-cvsimport-patchsets.sh
@@ -14,6 +14,17 @@
test_description='git cvsimport testing for correct patchset estimation'
. ./lib-cvs.sh
+if ! test_have_prereq PERL
+then
+ skip_all='skipping git cvsimport tests, perl not available'
+ test_done
+fi
+if ! test_have_prereq CVS
+then
+ skip_all='skipping git cvsimport tests, cvs not available'
+ test_done
+fi
+
setup_cvs_test_repository t9603
test_expect_failure 'import with criss cross times on revisions' '
diff --git a/t/test-lib.sh b/t/test-lib.sh
index cb1ca97..d594c95 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1066,6 +1066,7 @@ case $(uname -s) in
;;
esac
+test -z "$NO_CVS" && test_set_prereq CVS
test -z "$NO_PERL" && test_set_prereq PERL
test -z "$NO_PYTHON" && test_set_prereq PYTHON
--
1.7.3.4
^ permalink raw reply related
* Re: clone breaks replace
From: Jonathan Nieder @ 2011-01-07 20:51 UTC (permalink / raw)
To: Phillip Susi; +Cc: git, Christian Couder
In-Reply-To: <4D276CD2.60607@cfl.rr.com>
Phillip Susi wrote:
> Isn't the whole purpose of using replace to avoid having to use
> filter-branch, which throws out all of the existing commit records, and
> creates an entirely new commit chain that is slightly modified?
No. What documentation suggested that? Maybe it can be fixed.
The original purpose of grafts (the ideological ancestor of
replacement refs) was to serve a very particular use case. Sit down
by the fire, if you will, and...
Git had just came into existence and pack files did not exist yet. A
full import of the Linux kernel history was possible but the result
was enormous and not something ready to be imposed on all Linux
contributors. So what can one do?
$ git show -s v2.6.12-rc2^0
commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Sat Apr 16 15:20:36 2005 -0700
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Fast forward three months, and there is discussion[1] about what to do
with the historical git archive. A clever idea: teach git to _pretend_
that the historical archive is the parent to v2.6.12-rc2, so
"git log --grep", "gitk", and so on work as they ought to.
So grafts were born. One of the nicest advantages of grafts is that
they make it easy to do complex history surgery: make some grafts ---
cut here, paste there --- and then run "git filter-branch" to make it
permanent.
But grafts have a serious problem.
Transport machinery needs to ignore grafts --- otherwise, the two ends
of a connection could have different ideas of the history preceding a
commit, resulting in confusion and breakage. A fix to that was
finally grafted on a few years later (see also [2]).
$ GIT_NOTES_REF=refs/remotes/charon/notes/full \
git log --grep=graft --grep=repack --all-match --no-merges
[...]
git repack: keep commits hidden by a graft
[...]
Archived-At: <http://thread.gmane.org/gmane.comp.version-control.git/123874>
There is also the problem that grafts are too "raw": it is very easy
to make a graft pointing to a nonexistent object, say. And meanwhile
git has no native support for transfering grafts over the wire.
In that context there emerged the nicer (imho) refs/replace mechanism:
- reachability checking and transport machinery can treat them like
all other references --- no need for low-level tools to pay
attention to the artificial history;
- easy to script around with "git replace" and "git for-each-ref"
- can choose to fetch or not fetch with the usual
"git fetch repo refs/replace/*:refs/replace/*" syntax
Common applications:
- locally staging history changes that will later be made permanent
with "git filter-branch";
- grafting on additional (historical) history;
- replacing ancient broken commits with fixed ones, for use by "git
bisect".
Hope that helps,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/6470/focus=6484
found with "git log --grep=graft --reverse"
[2] http://thread.gmane.org/gmane.comp.version-control.git/37744/focus=37908
^ permalink raw reply
* Re: [PATCH] Mark gitk script executable
From: Anders Kaseorg @ 2011-01-07 20:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Paul Mackerras
In-Reply-To: <7vbp3s5tpl.fsf@alter.siamese.dyndns.org>
On Fri, 7 Jan 2011, Junio C Hamano wrote:
> If that is the case perhaps the next pull will fix that ;-)
Nope. There’s nothing to pull; the current gitk.git master was already
taken by the last pull. Even once there are commits to pull, the common
ancestor will be 6758ad94, in which the script is executable, so the
script will remain non-executable in the merge result. (And you can see
for yourself that the last 28 pulls since 62ba5143 haven’t added the
executable bit.)
The point is that 62ba5143 introduced a change to git.git that wasn’t in
gitk.git, and that change will remain in git.git until it’s undone in
git.git.
Anders
^ permalink raw reply
* Re: clone breaks replace
From: Stephen Bash @ 2011-01-07 21:15 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Christian Couder, Phillip Susi
In-Reply-To: <20110107205103.GC4629@burratino>
----- Original Message -----
> From: "Jonathan Nieder" <jrnieder@gmail.com>
> To: "Phillip Susi" <psusi@cfl.rr.com>
> Cc: git@vger.kernel.org, "Christian Couder" <chriscool@tuxfamily.org>
> Sent: Friday, January 7, 2011 3:51:03 PM
> Subject: Re: clone breaks replace
> Phillip Susi wrote:
>
> > Isn't the whole purpose of using replace to avoid having to use
> > filter-branch, which throws out all of the existing commit records,
> > and creates an entirely new commit chain that is slightly modified?
>
> No. What documentation suggested that? Maybe it can be fixed.
I'll chime in here as another person who read the ProGit blog entry on git-replace [1] and came to the same conclusion Phillip (and I'm guessing others) did. OTOH when I attempted to read the actual git-replace manpage, I got completely lost, so I retained my (apparently incorrect) understanding from ProGit.
Thanks,
Stephen
[1] http://progit.org/2010/03/17/replace.html
^ permalink raw reply
* Re: clone breaks replace
From: Jonathan Nieder @ 2011-01-07 21:34 UTC (permalink / raw)
To: Phillip Susi; +Cc: git, Christian Couder, Stephen Bash
In-Reply-To: <20110107205103.GC4629@burratino>
Jonathan Nieder wrote:
> Transport machinery needs to ignore grafts --- otherwise, the two ends
> of a connection could have different ideas of the history preceding a
> commit, resulting in confusion and breakage. A fix to that was
> finally grafted on a few years later (see also [2]).
Sorry, I walked away mid-paragraph and left out a crucial piece when I
returned. Because transport machinery ignores grafts, garbage
collection must make sure not to remove pieces of the non-artificial
history. It is the garbage collection that Dscho fixed with
v1.6.4-rc3~7^2.
Sorry for the nonsense.
^ permalink raw reply
* Re: clone breaks replace
From: Phillip Susi @ 2011-01-07 21:44 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Christian Couder
In-Reply-To: <20110107205103.GC4629@burratino>
On 1/7/2011 3:51 PM, Jonathan Nieder wrote:
> Phillip Susi wrote:
>
>> Isn't the whole purpose of using replace to avoid having to use
>> filter-branch, which throws out all of the existing commit records, and
>> creates an entirely new commit chain that is slightly modified?
>
> No. What documentation suggested that? Maybe it can be fixed.
It's just what made sense to me. If you can modify the history with
filter-branch, then you don't need replace refs. The downside to
filter-branch is that it breaks people tracking your repository, since
the history they had been tracking is thrown out and replaced with a
completely new commit chain that looks similar, but as far as git is
concerned, is unrelated to the original. Replace refs seem to have been
created to allow you to accomplish the goal of modifying an old commit
record, but without having to rewrite that and all subsequent commits,
causing breakage.
> - can choose to fetch or not fetch with the usual
> "git fetch repo refs/replace/*:refs/replace/*" syntax
It seems like this should be the default behavior. Or perhaps
refs/replace should be forked into one meant to be private, and one
meant to be public, and fetched by default. Or maybe it should be
fetched by default, but not pushed, so you have to explicitly push
replacements to the public mirror that you intend for public
consumption. Having the replace only apply locally and still needing to
filter-branch to make the change visible to the public seems to render
the replace somewhat pointless.
Take the kernel history as an example, only imagine that Linus did not
originally make that first commit leaving out the prior history, but
wants to go back and fix it now. He can do it with a replace, but then
if he runs filter-branch as you suggest to make the change 'real', then
everyone tracking his tree will fail the next time they try to pull.
You could get the same result without replace, so why bother?
If the replace was fetched by default, the people already tracking would
get it the next time they pull and would not have a problem. If they
wanted to see the old history, then they would already have it in the
repository and just need to add --no-replace-objects to see it, or run
git log on the original commit id that the replace record should refer
you to ( in the comments ). Those cloning the repository for the first
time would get it, and avoid fetching all of the old history since they
would be using the replace record in place of the original commit.
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: Ilari Liusvaara @ 2011-01-07 21:45 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, Zenaan Harkness, git
In-Reply-To: <20110107191719.GA6175@sigill.intra.peff.net>
On Fri, Jan 07, 2011 at 02:17:19PM -0500, Jeff King wrote:
> On Fri, Jan 07, 2011 at 08:52:18PM +0200, Ilari Liusvaara wrote:
>
> >
> > git clone --use-mirror=~/repositories/linux-2.6 git://foo.example/linux-foo
> >
> > This would first fetch everything from local source and then update that
> > from remote, likely being vastly faster.
>
> I'm not clear in your example what ~/repositories/linux-2.6 is. Is it a
> repo? In that case, isn't that basically the same as --reference? Or is
> it a local mirror list?
Yes, it is a repo. No, it isn't the same as --reference. It is list
of mirrors to try first before connecting to final repository and can
be any type of repository URL (local, true smart transport, smart HTTP,
dumb HTTP, etc...)
Idea is that you have list of mirrors that are faster than the final
repository, but not necressarily complete. You want to download most of
the stuff from there.
> If the latter, then yeah, I think it is a good idea. Clients should
> definitely be able to ignore, override, or add to mirror lists provided
> by servers. The server can provide hints about useful mirrors, but it is
> up to the client to decide which methods are useful to it and which
> mirrors are closest.
This is essentially adding mirrors to mirror list (modulo that mirrors
are not assumed to be complete).
Security:
Confidentiality: The connection to mirror must transverse only trusted
links or be encrypted if material from mirror is sensitive.
Integerity: The same integerity as the connection to final repo (assuming
SHA-1 can't be collided) due to fact that git object naming is securely
unique.
> Of course there are some servers who will want to do more than hint
> (e.g., the gentoo case where they really don't want people cloning from
> the main machine). For those cases, though, I think it is best to
> provide the hint and to reject clients who don't follow it (e.g., by
> barfing on somebody who tries to do a full clone). You have to implement
> that rejection layer anyway for older clients.
With option like this, a client could do:
git clone --use-mirror=http://git.example.org/base/foo git://git.example.org/foo
To first grab stuff via HTTP (well-packed dumb HTTP is very light on the
server) and then continue via git:// (now much cheaper because client is
relatively up to date).
-Ilari
^ permalink raw reply
* Re: clone breaks replace
From: Jonathan Nieder @ 2011-01-07 21:49 UTC (permalink / raw)
To: Phillip Susi; +Cc: git, Christian Couder, Stephen Bash
In-Reply-To: <4D278930.7010100@cfl.rr.com>
Phillip Susi wrote:
> Take the kernel history as an example, only imagine that Linus did not
> originally make that first commit leaving out the prior history, but
> wants to go back and fix it now. He can do it with a replace, but then
> if he runs filter-branch as you suggest to make the change 'real', then
> everyone tracking his tree will fail the next time they try to pull.
> You could get the same result without replace, so why bother?
>
> If the replace was fetched by default, the people already tracking would
> get it the next time they pull and would not have a problem.
Interesting. I hadn't thought about this detail before.
> Those cloning the repository for the first
> time would get it, and avoid fetching all of the old history since they
> would be using the replace record in place of the original commit.
No, it doesn't work that way. Imagine for a moment that each commit
object actually contains all of its ancestors. That isn't precisely
right but in a way it is close.
To change the ancestry of a commit, you really do need to change its
name. If you disagree, feel free to try it and I'd be glad to help
where I can with the coding if the design is sane. Deal?
Maybe it would be nice if git replace worked that way, but that would
be fundamentally a _different_ feature.
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: Jeff King @ 2011-01-07 21:56 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Nicolas Pitre, Zenaan Harkness, git
In-Reply-To: <20110107214501.GA29959@LK-Perkele-VI.localdomain>
On Fri, Jan 07, 2011 at 11:45:01PM +0200, Ilari Liusvaara wrote:
> > I'm not clear in your example what ~/repositories/linux-2.6 is. Is it a
> > repo? In that case, isn't that basically the same as --reference? Or is
> > it a local mirror list?
>
> Yes, it is a repo. No, it isn't the same as --reference. It is list
> of mirrors to try first before connecting to final repository and can
> be any type of repository URL (local, true smart transport, smart HTTP,
> dumb HTTP, etc...)
OK, I understand what you mean. I was thrown off by your example using a
local repository (in which case you probably would want --reference to
save disk space, unless the burden of alternates management is too
much).
So yeah, I think we are on the same page, except that you were proposing
to pass the mirror directly, and I was proposing passing a mirror file
which would contain a list of mirrors. Yours is much simpler and would
probably be what people want most of the time.
> > If the latter, then yeah, I think it is a good idea. Clients should
> > definitely be able to ignore, override, or add to mirror lists provided
> > by servers. The server can provide hints about useful mirrors, but it is
> > up to the client to decide which methods are useful to it and which
> > mirrors are closest.
>
> This is essentially adding mirrors to mirror list (modulo that mirrors
> are not assumed to be complete).
I think there should always be an assumption that mirrors are not
necessarily complete. That is necessary for bundle-like mirrors to be
feasible, since updating the bundle for every commit defeats the
purpose.
It would be nice for there to be a way for some mirrors to be marked as
"should be considered complete and authoritative", since we can optimize
out the final check of the master in that case (as well as for future
fetches). But that's a future feature. My plan was to leave space in the
mirror list for arbitrary metadata of that sort.
> > Of course there are some servers who will want to do more than hint
> > (e.g., the gentoo case where they really don't want people cloning from
> > the main machine). For those cases, though, I think it is best to
> > provide the hint and to reject clients who don't follow it (e.g., by
> > barfing on somebody who tries to do a full clone). You have to implement
> > that rejection layer anyway for older clients.
>
> With option like this, a client could do:
>
> git clone --use-mirror=http://git.example.org/base/foo git://git.example.org/foo
>
> To first grab stuff via HTTP (well-packed dumb HTTP is very light on the
> server) and then continue via git:// (now much cheaper because client is
> relatively up to date).
Yes, exactly.
-Peff
^ 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