* 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
* Re: [PATCH] git-cvs*: Make building (and testing) of CVS interface scripts optionally selectable
From: Jonathan Nieder @ 2011-01-07 22:01 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: git
In-Reply-To: <1294433290-9262-1-git-send-email-robbat2@gentoo.org>
Robin H. Johnson wrote:
> 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 explanation seems quite odd to me. Are you saying we can't rely
on the 'cvs' name being "taken" and should live in fear that someone
will implement an incompatible utility with the same name? Did that
actually happen?
I would find it easier to believe
Building and testing git's cvs support is slow, because ...
So give users with no interest in cvs interoperability a way
out. By defining NO_CVS you can avoid this time-consuming
piece of the build process.
Or for a different patch:
Add a NO_CVS knob so users with no interest in cvs support
can avoid polluting their $(libexecdir) with unwanted entries.
Or:
Introduce a new NO_CVS knob. If set, the CVS interop scripts
will be replaced by unimplemented.sh so sysadmins and
distributors can hopefully get a nice, clear error report instead
of confusion when users try to run them with cvs not installed.
^ permalink raw reply
* Re: clone breaks replace
From: Phillip Susi @ 2011-01-07 22:09 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Christian Couder, Stephen Bash
In-Reply-To: <20110107214907.GA9194@burratino>
On 1/7/2011 4:49 PM, Jonathan Nieder wrote:
> 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?
That's why a replace record seems to be the perfect solution. The
original record still references the old history, but you ignore it in
favor of the replacement, which does not. Thus you have a choice; you
ignore the replacement and use the original with the full history
attached, or you respect the replacement and the history is truncated.
As long as git-upload-pack respects the replacement, then new checkouts
will ignore the old history. You could then create a new historical
branch that points to the parent commit of the replaced one, and tell
people to fetch that branch to get the old history, or pass
--no-replace-objects over the wire to git-upload-pack.
^ permalink raw reply
* Re: [PATCH] git-cvs*: Make building (and testing) of CVS interface scripts optionally selectable
From: Junio C Hamano @ 2011-01-07 22:05 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: git, Ævar Arnfjörð Bjarmason
In-Reply-To: <1294433290-9262-1-git-send-email-robbat2@gentoo.org>
"Robin H. Johnson" <robbat2@gentoo.org> writes:
> 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.
Is that a problem?
It makes sense to let people whose system happens to have a working cvs to
omit cvs interoperability bits when they know the do not want them, and
that alone would be a good enough motivation.
I'd even consider the above justification of yours detrimental---it would
be an excuse for other people to add patches to support NO_CAT, NO_DIFF,
NO_LS, ... saying "if a binary 'cat' that is not cat is there, things
break, so work it around". That is a road to nonsense land.
> 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).
While the patch looks good, some people seem to prefer skipping individual
tests without shortcut; see 900eab4 (t/t9600-cvsimport.sh: change from
skip_all=* to prereq skip, 2010-08-13) for example. I am slightly in
favor of the short-cut as I haven't heard convincing argument against it
other than "skipped statistics" which I don't think is interesting nor
accurate anyway.
I wonder if "check PERL and CVS prerequisite and say test_done" should be
made into a helper in lib-cvs.sh or somewhere instead of repeating them in
individual tests, but that is a minor point.
^ permalink raw reply
* Re: clone breaks replace
From: Jeff King @ 2011-01-07 22:09 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Phillip Susi, git, Christian Couder, Stephen Bash
In-Reply-To: <20110107214907.GA9194@burratino>
On Fri, Jan 07, 2011 at 03:49:07PM -0600, Jonathan Nieder wrote:
> 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.
I think there are two separate issues here:
1. Should transport protocols respect replacements (i.e., if you
truncate history with a replacement object and I fetch from you,
should you get the full history or the truncated one)?
2. Should clone fetch refs from refs/replace (either by default, or
with an option)?
Based on previous discussions, I think the answer to the first is no.
The resulting repo violates a fundamental assumption of git. Yes,
because of the replacement object, many things will still work. But many
parts of git intentionally do not respect replacement, and they will be
broken.
Instead, I think of replacements as a specific view into history, not a
fundamental history-changing operation itself. Which means you can never
save bandwidth or space by truncating history with replacements. You can
only give somebody the full history, and share with them your view. If
you want to truncate, you must rewrite history[1].
Which leads to the second question. It is basically a matter of saying
"do you want to fetch the view that upstream has"? I can definitely see
that being useful, and meriting an option. However, it may or may not be
worth turning on by default, as upstream's view may be confusing.
-Peff
[1] Actually, what we are talking about it basically shallow clone.
Which does do exactly this truncation, but does not use the replace
mechanism. So it _is_ possible, but lots of things need to be
tweaked to understand the shallow-ness. Perhaps in the long run
making git understand replacement-truncated repos with missing
objects would be a good thing, and shallow clones can be implemented
simply as a special case of that. It would probably make the code a
bit cleaner.
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: Ilari Liusvaara @ 2011-01-07 22:21 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, Zenaan Harkness, git
In-Reply-To: <20110107215631.GA10343@sigill.intra.peff.net>
On Fri, Jan 07, 2011 at 04:56:31PM -0500, Jeff King wrote:
> On Fri, Jan 07, 2011 at 11:45:01PM +0200, Ilari Liusvaara wrote:
>
>
> 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.
Also add protocol that grabs a bundle from HTTP and then opens that
up? :-)
> 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.
The first thing one should get/do when connecting to another repository
is its list of references. One can see from there if what one has got
is complete or not (with --use-mirror that only allows skipping commit
negotiation and fetch, not the whole connection due to the fact that the
repositories are contacted in order)...
-Ilari
^ permalink raw reply
* Re: [RFC/PATCH] t9157-*.sh: Add an svn version check
From: Eric Wong @ 2011-01-07 22:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Walter, Ramsay Jones, GIT Mailing-list
In-Reply-To: <AANLkTi=VpHtQ+x5hyfCei-=X=ry4X=+TSGg7EKa7zs4j@mail.gmail.com>
Steven Walter <stevenrwalter@gmail.com> wrote:
> On Fri, Jan 7, 2011 at 12:31 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
> >> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> ---
> >
> > Consider this
> > Acked-by: Eric Wong <normalperson@yhbt.net>
>
> Acked-by: Steven Walter <stevenrwalter@gmail.com>
I've pushed out Ramsay's patch along with a small manpage fix
that was mailed to me privately to git://git.bogomips.org/git-svn.git
Ramsay Allan Jones (1):
t9157-*.sh: Add an svn version check
StephenB (1):
git svn: fix the final example in man page
--
Eric Wong
^ permalink raw reply
* Job Opportunity at Amazon.com
From: Neil Macneale @ 2011-01-07 22:25 UTC (permalink / raw)
To: git
Hello Git Enthusiasts,
I am a software engineer at Amazon.com on the Developer Tools Team, and
we are looking for engineers with significant git expertise. We have
lots of great features in the pipeline and could use your help!
The job listing is here: https://us-amazon.icims.com/jobs/130459/job
If you have questions about what we are building or what it's like to
work at Amazon, I encourage you to contact me directly at macneale [at]
amazon.com.
Regards,
Neil Macneale
--
Neil Macneale IV - macneale [at] amazon.com
Software Engineer - Developer Tools
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again) - stable packs?
From: Jeff King @ 2011-01-07 22:27 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Nicolas Pitre, Zenaan Harkness, git
In-Reply-To: <20110107222133.GA2377@LK-Perkele-VI.localdomain>
On Sat, Jan 08, 2011 at 12:21:33AM +0200, Ilari Liusvaara wrote:
> On Fri, Jan 07, 2011 at 04:56:31PM -0500, Jeff King wrote:
> > On Fri, Jan 07, 2011 at 11:45:01PM +0200, Ilari Liusvaara wrote:
> >
> >
> > 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.
>
> Also add protocol that grabs a bundle from HTTP and then opens that
> up? :-)
Well, yes, that still needs to be implemented. But it's all client-side,
so the server just has to provide the bundle somewhere.
> > 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.
>
> The first thing one should get/do when connecting to another repository
> is its list of references. One can see from there if what one has got
> is complete or not (with --use-mirror that only allows skipping commit
> negotiation and fetch, not the whole connection due to the fact that the
> repositories are contacted in order)...
Yes, but it would be cool to be able to skip even that connect in some
cases (e.g., mirrors can be useful not just to take load off the master,
but also when the master isn't available, either for downtime or because
the client is behind a firewall). But the default should definitely be
to double-check that the master is right, and we can leave more advanced
cases for later (we just need to be aware of leaving room for them now).
I'm going to start working on a patch series for this, so hopefully
we'll see how it's shaping up in a day or two.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] t9157-*.sh: Add an svn version check
From: Junio C Hamano @ 2011-01-07 22:32 UTC (permalink / raw)
To: Eric Wong; +Cc: Steven Walter, Ramsay Jones, GIT Mailing-list
In-Reply-To: <20110107222232.GA10624@dcvr.yhbt.net>
Thanks!
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Junio C Hamano @ 2011-01-07 22:50 UTC (permalink / raw)
To: Jeff King; +Cc: Uwe Kleine-König, Junio C Hamano, git
In-Reply-To: <20110107195417.GC6175@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Here is the test script I worked out which shows the issue (and checks
> that the right messages are shown to the user):
This is a band-aid that is not quite right (even though it passes the
tests). Attempting to check out a branch "frotz" in a repository with a
tag "frotz" that point at a non-commit would still fail, which is not a
new problem.
builtin/checkout.c | 7 +++++++
t/t2019-checkout-amiguous-ref.sh | 23 ++++++++++++++++++++++-
2 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index a54583b..f6fea2f 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -840,6 +840,13 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
;
else
new.path = NULL;
+ if (hashcmp(new.commit->object.sha1, rev))
+ /*
+ * Yikes, arg is an ambiguous and higher
+ * precedence SHA-1 expression than the
+ * branch name
+ */
+ new.commit = lookup_commit_reference_gently(rev, 1);
parse_commit(new.commit);
source_tree = new.commit->tree;
} else
diff --git a/t/t2019-checkout-amiguous-ref.sh b/t/t2019-checkout-amiguous-ref.sh
index 0981f11..fa1d4e6 100755
--- a/t/t2019-checkout-amiguous-ref.sh
+++ b/t/t2019-checkout-amiguous-ref.sh
@@ -6,8 +6,10 @@ test_description='checkout handling of ambiguous (branch/tag) refs'
test_expect_success 'setup ambiguous refs' '
test_commit branch file &&
git branch ambiguity &&
+ git branch vagueness &&
test_commit tag file &&
git tag ambiguity &&
+ git tag vagueness HEAD:file &&
test_commit other file
'
@@ -19,7 +21,7 @@ test_expect_success 'checkout produces ambiguity warning' '
grep "warning.*ambiguous" stderr
'
-test_expect_failure 'checkout chooses branch over tag' '
+test_expect_success 'checkout chooses branch over tag' '
echo branch >expect &&
test_cmp expect file
'
@@ -29,4 +31,23 @@ test_expect_success 'checkout reports switch to detached HEAD' '
! grep "^HEAD is now at" stderr
'
+test_expect_failure 'checkout vague ref succeeds' '
+ git checkout vagueness >stdout 2>stderr &&
+ test_set_prereq VAGUENESS_SUCCESS
+'
+
+test_expect_success VAGUENESS_SUCCESS 'checkout produces ambiguity warning' '
+ grep "warning.*ambiguous" stderr
+'
+
+test_expect_success VAGUENESS_SUCCESS 'checkout chooses branch over tag' '
+ echo branch >expect &&
+ test_cmp expect file
+'
+
+test_expect_success VAGUENESS_SUCCESS 'checkout reports switch to detached HEAD' '
+ grep "Switched to branch" stderr &&
+ ! grep "^HEAD is now at" stderr
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] git-cvs*: Make building (and testing) of CVS interface scripts optionally selectable
From: Robin H. Johnson @ 2011-01-07 22:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: Robin H. Johnson, git, Ævar Arnfjörð Bjarmason
In-Reply-To: <7v39p45pyw.fsf@alter.siamese.dyndns.org>
On Fri, Jan 07, 2011 at 02:05:59PM -0800, Junio C Hamano wrote:
> > 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.
> It makes sense to let people whose system happens to have a working cvs to
> omit cvs interoperability bits when they know the do not want them, and
> that alone would be a good enough motivation.
Ok, i'll respin to a different explanation.
> While the patch looks good, some people seem to prefer skipping individual
> tests without shortcut; see 900eab4 (t/t9600-cvsimport.sh: change from
> skip_all=* to prereq skip, 2010-08-13) for example. I am slightly in
> favor of the short-cut as I haven't heard convincing argument against it
> other than "skipped statistics" which I don't think is interesting nor
> accurate anyway.
I did it this was because of your prior comment on my perl prereq patch
for the send-email tests.
> I wonder if "check PERL and CVS prerequisite and say test_done" should be
> made into a helper in lib-cvs.sh or somewhere instead of repeating them in
> individual tests, but that is a minor point.
I'll see if I can respin to do this.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
^ permalink raw reply
* Re: [PATCH] git-cvs*: Make building (and testing) of CVS interface scripts optionally selectable
From: Robin H. Johnson @ 2011-01-07 22:55 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Robin H. Johnson, git
In-Reply-To: <20110107220147.GB9194@burratino>
On Fri, Jan 07, 2011 at 04:01:48PM -0600, Jonathan Nieder wrote:
> This explanation seems quite odd to me. Are you saying we can't rely
> on the 'cvs' name being "taken" and should live in fear that someone
> will implement an incompatible utility with the same name? Did that
> actually happen?
Not in the linked bug report, but it does explain a previous bug I had
seen, where a user had a little script in /usr/local/bin that complained
at him whenever he ran 'cvs', so he would learn to migrate away faster.
> I would find it easier to believe
I'm going to respin the patch with a new text, and one other improvement
from Junio.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
^ permalink raw reply
* Re: clone breaks replace
From: Junio C Hamano @ 2011-01-07 22:58 UTC (permalink / raw)
To: Jeff King
Cc: Jonathan Nieder, Phillip Susi, git, Christian Couder,
Stephen Bash
In-Reply-To: <20110107220942.GB10343@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 2. Should clone fetch refs from refs/replace (either by default, or
> with an option)?
> ...
> Which leads to the second question. It is basically a matter of saying
> "do you want to fetch the view that upstream has"? I can definitely see
> that being useful, and meriting an option. However, it may or may not be
> worth turning on by default, as upstream's view may be confusing.
I think that should be stated a bit differently. "Do you want to fetch
the view that the upstream offers as an option, and if you want, which
ones (meaning: there could be more than one replacement grafts to give
different views)?"
And as an optional view, I would say it is perfectly Ok to fetch whichever
view you want as a separate step after the initial clone.
^ permalink raw reply
* Re: problem with cherry-picking a commit which comes before introducing a new submodule
From: Jonathan Nieder @ 2011-01-07 23:00 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git, Elijah Newren
In-Reply-To: <20110107183226.GG6040@onerussian.com>
Yaroslav Halchenko wrote [abbreviated]:
> Merging HEAD with todonotloose
> Merging:
> 855981d just placeholders in the abstract
> a00c497 Initial draft for HBM abstract.
> CONFLICT (file/directory): There is a directory with name frontiers/code in todonotloose. Adding frontiers/code as
> +frontiers/code~HEAD
> % git ls-files -u
> 160000 a2b5787 2 frontiers/code
> % git diff-tree todonotloose
> a00c497
> :040000 040000 40427e34 c7ba910 M poster-hbm2011_neurodebian
> % git diff-tree todonotloose^ HEAD
> :100644 100644 378e137 c39ced7 M .gitmodules
> :000000 040000 0000000 141dbc1 A challenge-execpapers
> :040000 040000 401fd66 ee190f0 M frontiers
> :040000 040000 26c884a ad3e829 M sty
One more piece of protocol: what git version are you using? The
release notes mention a fix in this area in v1.7.3[1]:
* "git merge -s recursive" (which is the default) did not handle cases
where a directory becomes a file (or vice versa) very well.
Hopefully this is that. In any case, sounds like a bug.
(Hopefully someone else can comment on why cherry-pick uses the
merge machinery to notice conflicts that would not be clear from
the patch alone.)
Thanks again.
Jonathan
[1] There is an updated Debian source package at [2]. Or, probably
faster: one can use the build result in bin-wrappers/ from a git.git
clone in place.
[2] http://mentors.debian.net/debian/pool/main/g/git/git_1.7.4~rc1-0.1.dsc
^ permalink raw reply
* git clone --update ?
From: Darxus @ 2011-01-07 22:54 UTC (permalink / raw)
To: git
I'm working on a build script that pulls source from 12 git repos:
http://www.chaosreigns.com/wayland/wayland-build-ubuntu-all.sh
I would like to be able to do the equivalent of:
rm -rf gtk+; git clone git://git.gnome.org/gtk+ --branch gdk-backend-wayland
Without re-downloading the entire thing. Even if I made any kind of
modifications to the repo.
One suggestion I've gotten was;
git checkout gdk-backend-wayland && git fetch git://git.gnome.org/gtk+ gdk-backend-wayland && git reset --hard FETCH_HEAD && git clean -fxd
Possibly replacing the branch name with HEAD if I want the default branch.
It would be nice if, instead, I could just run something like:
git clone --update git://git.gnome.org/gtk+ --branch gdk-backend-wayland
Bonus points for working if I have not already cloned it.
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Junio C Hamano @ 2011-01-07 23:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Uwe Kleine-König, git
In-Reply-To: <7vsjx449bv.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> Here is the test script I worked out which shows the issue (and checks
>> that the right messages are shown to the user):
>
> This is a band-aid that is not quite right (even though it passes the
> tests). Attempting to check out a branch "frotz" in a repository with a
> tag "frotz" that point at a non-commit would still fail, which is not a
> new problem.
>
>
> builtin/checkout.c | 7 +++++++
> t/t2019-checkout-amiguous-ref.sh | 23 ++++++++++++++++++++++-
> 2 files changed, 29 insertions(+), 1 deletions(-)
... And this comes on top (should probably be squashed into one) to really
favor a branch over a tag.
builtin/checkout.c | 26 ++++++++++----------------
t/t2019-checkout-amiguous-ref.sh | 2 +-
2 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index f6fea2f..48e547b 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -832,25 +832,19 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
argc--;
new.name = arg;
- if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
- setup_branch_path(&new);
+ 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;
- if (hashcmp(new.commit->object.sha1, rev))
- /*
- * Yikes, arg is an ambiguous and higher
- * precedence SHA-1 expression than the
- * branch name
- */
- new.commit = lookup_commit_reference_gently(rev, 1);
+ if ((check_ref_format(new.path) != CHECK_REF_FORMAT_OK) ||
+ !resolve_ref(new.path, rev, 1, NULL))
+ new.path = NULL; /* not an existing branch */
+
+ if (!(new.commit = lookup_commit_reference_gently(rev, 1))) {
+ /* not a commit */
+ source_tree = parse_tree_indirect(rev);
+ } else {
parse_commit(new.commit);
source_tree = new.commit->tree;
- } else
- source_tree = parse_tree_indirect(rev);
+ }
if (!source_tree) /* case (1): want a tree */
die("reference is not a tree: %s", arg);
diff --git a/t/t2019-checkout-amiguous-ref.sh b/t/t2019-checkout-amiguous-ref.sh
index fa1d4e6..e2b330b 100755
--- a/t/t2019-checkout-amiguous-ref.sh
+++ b/t/t2019-checkout-amiguous-ref.sh
@@ -31,7 +31,7 @@ test_expect_success 'checkout reports switch to detached HEAD' '
! grep "^HEAD is now at" stderr
'
-test_expect_failure 'checkout vague ref succeeds' '
+test_expect_success 'checkout vague ref succeeds' '
git checkout vagueness >stdout 2>stderr &&
test_set_prereq VAGUENESS_SUCCESS
'
^ permalink raw reply related
* Re: git clone --update ?
From: Zenaan Harkness @ 2011-01-07 23:41 UTC (permalink / raw)
To: Darxus; +Cc: git
In-Reply-To: <20110107225405.GH20411@chaosreigns.com>
On Sat, Jan 8, 2011 at 09:54, <Darxus@chaosreigns.com> wrote:
> I'm working on a build script that pulls source from 12 git repos:
> http://www.chaosreigns.com/wayland/wayland-build-ubuntu-all.sh
>
> I would like to be able to do the equivalent of:
>
> rm -rf gtk+; git clone git://git.gnome.org/gtk+ --branch gdk-backend-wayland
>
> Without re-downloading the entire thing. Even if I made any kind of
> modifications to the repo.
Are you aware of local cloning? ie:
git clone ../my-repos/gtk+ --branch gdk-backend-wayland
First of course, you create my-repos/ somewhere, and inside that dir, run
git clone --bare git://git.gnome.org/$which $which.git
for each of your 12 repos that your build script will work with.
Then whilst in my-repos/, when you need to update from upstream, do:
for i in *; do cd $i; git fetch; cd ..; done
Your build scripts can clone from your local repos as often as you
like, without ever hitting the server.
But your question suggests you really have not read much git
documentation or experimented much - there is a heap, and lots of it
high quality. Read, do, learn.
Good luck
Zen
^ permalink raw reply
* Re: debugging git clone via git-daemon "cannot handle daemon internally"
From: Jonathan Nieder @ 2011-01-07 23:42 UTC (permalink / raw)
To: John Griessen; +Cc: git, Shawn O. Pearce, Ilari Liusvaara
In-Reply-To: <4D234FEF.2030501@ecosensory.com>
John Griessen wrote:
> john@toolbench:~/EEProjects/test$ telnet mail.cibolo.us 9418
> Trying 76.191.252.85...
> Connected to mail.cibolo.us.
> Escape character is '^]'.
> fatal: cannot handle daemon internally
> Connection closed by foreign host.
>
>
> What does "cannot handle daemon internally" signify to you all?
Progress. :) Interesting.
The message comes from "main" in git.c:
if (!prefixcmp(cmd, "git-")) {
cmd += 4;
argv[0] = cmd;
handle_internal_command(argc, argv);
die("cannot handle %s internally", cmd);
}
Perhaps you have inetd set up to try to run git with argv[0] set
to git-daemon? git-daemon (daemon.c) has its own "main" so it
would take something of that nature to produce this symptom.
Maybe something like this would have made diagnosis easier.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
diff --git a/pkt-line.c b/pkt-line.c
index 295ba2b..694571d 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -121,6 +121,22 @@ static int packet_length(const char *linelen)
return len;
}
+static void NORETURN die_bad_length(int fd, const char linelen[4])
+{
+ struct strbuf msg = STRBUF_INIT;
+ FILE *fp;
+
+ if ((memcmp(linelen, "fata", 4) &&
+ memcmp(linelen, "erro", 4) &&
+ memcmp(linelen, "warn", 4)) ||
+ !(fp = fdopen(fd, "r")))
+ die("protocol error: bad line length character: %.4s", linelen);
+
+ strbuf_getline(&msg, fp, '\n');
+ die("protocol error: bad line length character: %.4s%s",
+ linelen, msg.buf);
+}
+
int packet_read_line(int fd, char *buffer, unsigned size)
{
int len;
@@ -129,7 +145,7 @@ int packet_read_line(int fd, char *buffer, unsigned size)
safe_read(fd, linelen, 4);
len = packet_length(linelen);
if (len < 0)
- die("protocol error: bad line length character: %.4s", linelen);
+ die_bad_length(fd, linelen);
if (!len)
return 0;
len -= 4;
^ permalink raw reply related
* [RFD] My thoughts about implementing gitweb output caching
From: Jakub Narebski @ 2011-01-07 23:42 UTC (permalink / raw)
To: git; +Cc: J.H., John 'Warthog9' Hawley
Those are my thoughts on gitweb output caching, brought by working on
my rewrite of gitweb output caching, based on ideas (and some code)
from John 'Warthog9' Hawley (J.H.) series, and on reviewing J.H. code.
I'd apreciate very much comments on this
Table of contents:
~~~~~~~~~~~~~~~~~~
1. Splitting gitweb (and infractructure for it)
2. require Gitweb::Cache vs do 'cache.pl'
3. cache key (href(-replay => 1,...) vs $cgi->self_url())
4. caching, error handling, progress info and persistent environments
(blocking progress info via parameter, or referer, or ...)
5. capturing and saving STDOUT by redirection vs select(FH) or print $out
6. being able to use other caching engines, and capturing to scalar
capturing to memory vs capturing to file,
7. saving in text or binary; printing data from cache in binary mode
8. atomic file write and locking
9. background cache generation
10. HTTP aware output caching, HTTP aware caching engine (c.f. CHI)
1. Splitting gitweb (and infractructure for it)
Because gitweb is getting quite large (7341 lines, in byte size next
to largest in git.git repository after gitk-git/gitk), and caching is
meant to be optional, therefore (most of) code related to gitweb
caching should be put in a separate file.
This means that adding support for caching to gitweb should bring
infrastructure that will be required for splitting gitweb for easier
maintenance and extending. Which is a good side effect of adding
caching support to gitweb.
One question remains: current infrastructure supports having gitweb
modules (or "modules", see the next item) in 'lib/' subdirectory
alongside gitweb.cgi, and in directories in PERL5LIB or PERLLIB.
There was request to support installing gitweb modules in a separate
directory, but that would require changes to "gitweb: Prepare for
splitting gitweb" patch (but it is doable). Is there wider interest
in supporting such feature?
2. require Gitweb::Cache vs do 'cache.pl'
One of the differences between original J.H. code and my rewrites of
it is that in J.H. patches caching code is in 'cache.pm' file and must
be loaded using "do 'cache.pm'", while in my rewrite caching is put
into proper Perl module and can be loaded using something like
"require Gitweb::Cache".
(Digression: the name 'cache.pm' is bad because of two reasons.
First, the *.pm extension sugests that it is a proper Perl module,
with a separate namespace, that can be loaded using "require".
Second, it is good practice to restrict all lowercase package names to
pragma-like modules, like 'strict', 'warnings' or 'namespace::clean'.
That is why in "minimal fixup" response to J.H. patches I renamed
it from cache.pm to cache.pl (or rather lib/cache.pl).)
The main advantage of 'cache.pl' solution is that you don't need to
separate gitweb parts from caching parts, and you don't need to
carefully design API for interaction between caching layer and
application layer. For example in J.H.'s patches cache.pm uses
variables and subroutines from gitweb.perl, e.g. $my_url or %actions,
and die_error. This allow for fast no-design development... leading
to (somewhat at least) spaghetti code.
But this is also main disadvantage of this method. Without proper
separation (proper encapsulation) of caching layer testing the caching
engine separately would be difficult, if at all possible (perhaps with
mocking...). In my rewrite caching engine has a separate set of
tests checking its behavior; in J.H. series it doesn't.
Currently 'cache.pl' is loaded in "minimal fixup" version using the
following code
if (!exists $INC{'cache.pl'}) {
my $return = do 'cache.pl';
die $@ if $@;
die "Couldn't read 'cache.pl': $!" if (!defined $return);
}
though nowadays I think that "require 'cache.pl';" could be enough.
Removing some of entaglements is quite easy: instead of calculating key
based on $my_url or $cgi in cache_fetch, calculate it in caller i.e. in
gitweb; instead of passing $action and using $actions{$action}->(), just
pass code reference i.e. $actions{$action} as parameter; pass options in
a hash or hashref. Removing other dependencise is harder: to remove
dependency on die_error you need either 'on_error' handler, or extract
error handling in separate package and use it (which is harder than it
looks, at least with current error handling, but see below).
There is also additional advantage in putting caching layer into
separate Perl package: there is possibility of (re)using it outside of
gitweb. But this is rather minor issue...
3. cache key (href(-replay => 1,...) vs $cgi->self_url())
The key used for gitweb caching, to find apropriate cache entry, is
based on URL of current page. The question is if some URLs are to be
considered equivalent, and what class of URL do we consider equivalent,
i.e. having the same key.
Simplest solution is to use $cgi->self_url() (note that what J.H. v8
uses, i.e.: "$my_url?". $ENV{'QUERY_STRING'}, where $my_url is just
$cgi->url() is not enough - it doesn't take path_info into account).
Alternate solution, which I used in my rewrite, is to come up with
"canonical" URL, e.g. href(-replay => 1, -full => 1, -path_info => 0);
with this solution using path_info vs query parameters or reordering
query parameters still gives the same key.
4. caching, error handling, progress info and persistent environments
(blocking progress info via parameter, or referer, or ...)
This needs an intro:
J.H. gitweb caching series introduced non-JavaScript HTML-only progress
indicator, to notify user that there is data being (re)generated. It is
based on the trick that HTML redirection via http-equiv="Refresh" meta
header is done only after connection is closed / HTML page is rendered
in full. So by not printing final '</html>' and closing connection, and
by printing e.g. '.' every few seconds to prevent closing connection, we
can have simple progress indicator.
Other solution, presented in one of first versions of my rewrite, would
be to use Ajax based progress indicator. The problem with this solution
is that you need to guess if web browser (client) supports JavaScript
from server side; though there are tricks to do that (see
'blame_incremental' support).
J.H. patches up and including v7, and my rewrite up and including v6,
excluded error pages from caching. I think that the original resoning
behind choosing to do it this way was that A.), each of specific error
pages is usually accessed only once, so caching them would only take up
space bloating cache, but what is more important B.) that you can't
cache errors from caching engine.
Error handling in gitweb is done using die_error() subroutine (renamed
from error_page() very, very early in gitweb history). It is used
similarly to how "die" could be used in an ordinary application; in
place of for example
open my $fh, '<', $filename
or die "Can't open $filename: $!"
gitweb uses
open my $fd, "-|", git_cmd(), "ls-tree", $base, "--", $path
or die_error(500, "Open git-ls-tree failed");
Because gitweb is not a simple web application, and error can occur
quite deep in the call stack, having to check if each subroutine ended
in an error is impractical: it is much easier to rely on the fact that
calling die_error() ends current request.
Description of problem:
The problem is interaction with HTML-only progress indicator, and
non-cached pages. When the "Generating..." page starts to be send to
web browser (in my rewrite there was initial delay; if non-cached page
started to be generated within this initial delay then "Generating..."
page was not displayed at all), it means that page we wait for has to be
generated in background process. When the page is finished,
"Generating..." page would force redirection... but if page it was
waiting for is not saved in cache, the same thing would repeat: again
running generating data in background, again "Generating..." page.
So what's the solution? One would be to actually cache error pages.
This is not easy with die_error() both printing error page (sending it
to web browser after turning off capturing), and ending request,
originally by the way of exit(0) (note: ModPerl::Registry redefines it
to end request and not worker process), later with nonlocal goto to
END_GITWEB or (in one of my unapplied patches) a bit later to
END_REQUEST label. The proposed solution is to actually separate the
creating and throwing error from generating an error page; this should
allow easy caching of error pages -- gitweb would use die/eval to throw
and catch exceptions (similar to what SVN::Web does).
Possible improvement, but an additional complication, would be to make
cached error pages shorl lived, perhaps cleaning them up after using
them. This might be done via HTTP awareness, see below.
Another possible solution I have just thought about is to ensure somehow
that page (re)loaded from "Generating..." page has progress info
disabled. But that means that error page would get generated twice,
second time without progress indicator.
This is cerrtainly an issue that needs some thought.
5. capturing and saving STDOUT by redirection vs select(FH) or print $out
One of the goals in designing capturing mechanism for caching engine to
be used in gitweb output caching is that when caching is disabled gitweb
behaviour should not change at all (or at least the change should be
minimal). That means not collecting output to print it or save it to
cache at the end, as this would change bahvior from current streaming,
print as you go behavior... and make 'blame_data' part of
'blame_incremental' useless.
The solution with changing every 'print LIST' to 'print $out LIST' was
discarded because it would mean changes in almost all of gitweb,
resulting in very large patch.
The solution finally chosen is to redirect STDOUT to a file (reopen to a
file), while duplicating it to save it for later restoring. This is the
same solution that Capture::Tiny uses.
Alternate solution is to use select(FH) to change default filehandle for
'print' and 'printf'... but this seems less elegant solution.
6. being able to use other caching engines, and capturing to scalar
capturing to memory vs capturing to file,
The standard API to access cache supported by various Perl caching
engines (Cache::Cache, Cache, CHI, Cache::FastMmap, Cache::Memcached) is
based around $cache->get($key) and $cache->set($key, $data) methods:
my $data = $cache->get($key);
if (!defined $data) {
$data = compute_data($key);
$cache->set($key, $data);
}
Some caching engines support single instruction "get and set" equivalent
to above code, by providing code callback to generate data if it is not
in cache, though it is not as standardized as ->get/->set methods API.
CHI for example has $cache->compute($key, $code) method.
Note that $data might be a reference to a more complicated Perl
structure (ir might be arrayref or hashref) -- the usual example is to
cache results of a database query. This means that $data must be
serialized before writing to cache, though some cache implementations
allow to cache raw, unserialized data. This is complicated even more by
the fact that some caching engines wrap $data in a cache entry object
which stores entry-specific options, e.g. expiration time for cache
entry, so we need serializing even if $data is scalar.
More important issue is that (with sole exception of old Cache engine)
caching is done for data stored in memory. For caching captured output,
while using file-based cache, this means that when generating data we
have to capture output to variable (e.g. by capturing it to in-memory
file, or capturing to temporary file and slurping it to variable / to
memory), and then dump (spew) this variable to cache entry file (perhaps
with serialization as intermediate step). For when data exist in file
based cache this means slurping contents of cache entry file to variable
/ to memory (perhaps with deserialization in between), then dumping
(spewing) this content to STDOUT.
This means that to support existing caching engines (Cache::Cache, CHI,
Cache::FastMmap, Cache::Memcached, Cache::Ref, etc.) we need to support
capturing output to scalar, and dumping data to STDOUT.
If caching driver gitweb uses is file based, if data being cached is
unstructured and by itself does not require serialization, and if
capturing output is based on redirecting STDOUT to a file (perhaps
in-memory file), then this intermediate step of in-memory representation
(of storing captured output in variable) seems wasteful. Why not
capture directly to cache entry file, or dump / copy contents of cache
entry file directly to STDOUT? The problem is to design a good API that
allows separation of caching, capturing, cache management and gitweb
itself.
In my rewrite I have chosen to model API after
my $data = $cache->compute($key, $code);
The difference is that instead of returning scalar value (from cache or
calculated by $code), ->compute_fh() method returns a pair of filehandle
(opened for reading) and filename:
my ($fh, $filename) = $cache->compute_fh($key, $code_fh);
The $code_fh is coderef, which instead of returning value to be cached,
is passed filehandle opened for writing and filename to write to.
7. saving in text or binary; printing data from cache in binary mode
I'd like to repeat what I have written a few times earlier: if we take
care that PerlIO ':utf8' or ':raw' layers are applied correctly during
capture, then the data saved to cache can be treated as binary. This
means that we can read cache entry file in ':raw' mode and dump it to
STDOUT which is also in ':raw' (binary mode), regardless whether output
was done in text or binary mode.
This means that there is no need to special case in the caching layer
actions which output or can write binary (':raw') output.
8. atomic file write and locking
There is yet another are where original J.H. patches and my rewrite
differs, namely in using atomic file write and in locking.
In my code caching engine writes data to temporary file (File::Temp
without locking, <entry>.tmp with locking), then it gets [atomically]
renamed to final destination. This means that if there is data in cache
(possibly stale), we can read it *without locking*.
Locking in my rewrite is needed only to chose one of clients as the one
that would be (re)generating data in cache, which is done via non
blocking writer (exclusive) lock, and to notify other clients when data
is ready (written to cache), via blocking reader (shared) lock.
Sidenote: CHI has different mechanism to avoid cache miss stampedes
(though it doesn't protect against generic concurrent access when there
is no data in cache), namely the 'expires_variance' mechanism, see CHI
documentation, e.g. http://p3rl.org/CHI. It is meant to protect against
stampede at the end of cache expiration time, via "smearing" expiration
time: it allows items to expire a little earlier than the stated
expiration time.
9. background cache generation
In my rewrite caching engine first checks if forking a background
process is needed (it is configurable), and only then fork() is used.
There are two slightly different situations where background cache
generation can be used. First is when there is stale (but not too
stale) data to be served. In this case caching engine runs process
generating data in background, and foreground process (all foreground
processes: the one responsible for regenerating data (got lock) and
others) returns stale data. Foreground process doesn't, and shouldn't,
wait for background process. This means that background process has to
be detached as to not generate zombie processes. I do this in my
rewrite.
Second is if there is no stale data to serve (or data is too stale), but
we have progress indicator. In this case the foreground process is
responsible for rendering progress indicator, and background process is
responsible for generating data. In this case foreground process waits
for data to be generated (unless progress info subroutine exits), so
strictly spaking we don't need to detach background process in this
case.
10. HTTP aware output caching, HTTP aware caching engine (c.f. CHI)
In one of additional patches sent in last version (v7) of my (shortened)
rewrite I have make use of the fact that what gitweb caches is HTTP
response.
One of things that were done in this patch was adding 'Content-Length'
header if it was not present already. In the case of this header, it
can be added when printing data from cache, or it can be added when
saving data to cache. In the case of adding it when saving data to
cache it can be done by caching engine itself, or it can be done by
output caching "middleware". (In the case of patch in question it is
added during printing by output caching middleware.)
Other such header is 'Expires' header (or 'Cache-Control: max-age=').
It can be used when printing data from cache to reflect _current_
expiration time (which depends on current load in the case of adaptive
cache lifetime), like it is done in my patch. On the other hand it can
be used by caching engine to store per-entry expiration time: current
code only supports global (per-cache) expiration time.
There are however two complications with 'Expires' header. First, it
should never be in the past - this might happen when we are serving
stale data while waiting for data in cache to be regenerated,... or if
gitweb set some expire time, like when it knows that the data would
never change, because link uses SHA-1 identifier. Second, when gitweb
sets expire time then outpot cahcing middleware should probably rewrite
it to be maximum of gitweb's expire at the time of generation and cache
entry expire... or gitweb can be modified to use Cache-Control: max-age
instead.
Perhaps we could also add 'Last-Modified' header, setting it to the date
of cache generation; maybe even add support for If-Modified-Since
conditional request, though I am not sure where in the layer it should
be added: perhaps yet another middleware between gitweb and output
caching?
With output caching gitweb can also support 'Range' requests, which
means that it would support resumable download. This would mean hat we
would be able to resume downloading of snapshot (or in the future
bundle)... if we cannot do this now. This would require some more code
to be added.
We might also want to compress body (payload) of HTTP response, and add
'Content-Encoding: gzip' header... perhaps supporting transparent
decompression in the case when web browser doesn't support required
encoding. In this case we must do compression and adding of header when
saving data to cache, and must do transparent decompression (if needed)
on sending data to browser.
Another HTTP header that could be added is 'X-Sendfile' or
'X-Accel-Redirect', though I think that it needs to be done in the
output caching middleware (i.e. cache_output subroutine in
GitwebCache::CacheOutput in my rewrite).
--
Jakub Narębski
Poland
^ permalink raw reply
* Re: problem with cherry-picking a commit which comes before introducing a new submodule
From: Yaroslav Halchenko @ 2011-01-07 23:48 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Elijah Newren
In-Reply-To: <20110107230017.GA15495@burratino>
sorry -- lame me... 1.7.2.3 ... I will check with current version as soon as
kids permit ;-)
% apt-cache policy git
git:
Installed: 1:1.7.2.3-2.2
Candidate: 1:1.7.2.3-2.2
Version table:
*** 1:1.7.2.3-2.2 0
900 http://debian.lcs.mit.edu/debian/ squeeze/main amd64 Packages
800 http://debian.lcs.mit.edu/debian/ sid/main amd64 Packages
100 /var/lib/dpkg/status
% git --version
git version 1.7.2.3
On Fri, 07 Jan 2011, Jonathan Nieder wrote:
> One more piece of protocol: what git version are you using? The
> release notes mention a fix in this area in v1.7.3[1]:
> * "git merge -s recursive" (which is the default) did not handle cases
> where a directory becomes a file (or vice versa) very well.
> Hopefully this is that. In any case, sounds like a bug.
> (Hopefully someone else can comment on why cherry-pick uses the
> merge machinery to notice conflicts that would not be clear from
> the patch alone.)
> Thanks again.
> Jonathan
> [1] There is an updated Debian source package at [2]. Or, probably
> faster: one can use the build result in bin-wrappers/ from a git.git
> clone in place.
> [2] http://mentors.debian.net/debian/pool/main/g/git/git_1.7.4~rc1-0.1.dsc
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
^ permalink raw reply
* Re: 'git add' option to non-interactively stage working tree changes
From: Jakub Narebski @ 2011-01-07 23:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Hrvoje Nikšić, git
In-Reply-To: <7vfwt45tqv.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> 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,
You meant --relative[1] here (instead of --no-full-tree), didn't you?
[1] Supported by diff, and in a way by git-diff-tree
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-cvs*: Make building (and testing) of CVS interface scripts optionally selectable
From: Junio C Hamano @ 2011-01-07 23:50 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Jonathan Nieder, git
In-Reply-To: <robbat2-20110107T225413-429815896Z@orbis-terrarum.net>
"Robin H. Johnson" <robbat2@gentoo.org> writes:
> On Fri, Jan 07, 2011 at 04:01:48PM -0600, Jonathan Nieder wrote:
>> This explanation seems quite odd to me. Are you saying we can't rely
>> on the 'cvs' name being "taken" and should live in fear that someone
>> will implement an incompatible utility with the same name? Did that
>> actually happen?
> Not in the linked bug report, but it does explain a previous bug I had
> seen, where a user had a little script in /usr/local/bin that complained
> at him whenever he ran 'cvs', so he would learn to migrate away faster.
I suspect that NO_CVS is not the best way to help a person who is trying
to wean herself off of cvs by having a phony cvs in a directory that is
early on the $PATH (be it $HOME/bin/cvs or /usr/local/bin/cvs). Before
ceasing to actively build more histories in cvs, it would help to have an
access to git-cvsimport and friends to salvage what's already there, no?
A change that models after PERL_PATH, not after NO_PERL, would be a more
appropriate thing to do for that particular purpose.
I still think the patch itself is a worthy thing to have, so everything
above is a tangent that is orthogonal to what your patch tries to do,
though.
^ permalink raw reply
* Re: problem with cherry-picking a commit which comes before introducing a new submodule
From: Yaroslav Halchenko @ 2011-01-08 0:01 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Elijah Newren
In-Reply-To: <20110107230017.GA15495@burratino>
message is different -- result the same:
I: writing typescript to /home/yoh/.tmp/script.git-cherry-pick.17386.20110107.1857 ...
% git --version
git version 1.7.4.rc1
% git reset --hard
HEAD is now at 855981d just placeholders in the abstract
% export GIT_MERGE_VERBOSITY=5
% git cherry-pick todonotloose
CONFLICT (file/directory): There is a directory with name frontiers/code in a00c497... Initial draft for HBM abstract.. Adding frontiers/code as frontiers/code~HEAD
error: could not apply a00c497... Initial draft for HBM abstract.
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit -c a00c497'
% git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: poster-hbm2011_neurodebian/abstract.txt
# modified: poster-hbm2011_neurodebian/jb.txt
#
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# added by us: frontiers/code
#
% git reset --hard
HEAD is now at 855981d just placeholders in the abstract
% base=todonotloose^
% next=todonotloose
% head=HEAD
%
% git merge-recursive $base -- $head $next
Merging HEAD with todonotloose
Merging:
855981d just placeholders in the abstract
a00c497 Initial draft for HBM abstract.
found 1 common ancestor(s):
4708e24 minor moves around
CONFLICT (file/directory): There is a directory with name frontiers/code in todonotloose. Adding frontiers/code as frontiers/code~HEAD
% git ls-files -u; # after the merge
160000 a2b57871d2d79bef06ba6214739d82b9a63772a8 2 frontiers/code
zsh: command not found: #
% git diff-tree todonotloose
a00c497fa399c00486c97121ed0b8fda72c7ce47
:040000 040000 40427e34a1ff89c458f2a5f262a108d46b4fa004 c7ba91028b1cef63f4f7eef70f0c4054b31e92b6 M poster-hbm2011_neurodebian
% git diff-tree todonotloose^ HEAD
:100644 100644 378e1379ec5ebb7abac59fec162b7238b5846525 c39ced763aeb5fd352cecd6fef1bfc40471f2246 M .gitmodules
:000000 040000 0000000000000000000000000000000000000000 141dbc1bfe1be2eab77f04ca03f6f28feb372cca A challenge-execpapers
:040000 040000 401fd66867de412b8653dc3a698bbaa45441bec1 ee190f09786f324abdda6e7a36e8278c201a20a0 M frontiers
:040000 040000 26c884a67efb55bdf96d7453d9acd50cee36ae90 ad3e829d15b302c4342a6b2a9fb5dfede0ed77c9 M sty
On Fri, 07 Jan 2011, Jonathan Nieder wrote:
> Yaroslav Halchenko wrote [abbreviated]:
> > Merging HEAD with todonotloose
> > Merging:
> > 855981d just placeholders in the abstract
> > a00c497 Initial draft for HBM abstract.
> > CONFLICT (file/directory): There is a directory with name frontiers/code in todonotloose. Adding frontiers/code as
> > +frontiers/code~HEAD
> > % git ls-files -u
> > 160000 a2b5787 2 frontiers/code
> > % git diff-tree todonotloose
> > a00c497
> > :040000 040000 40427e34 c7ba910 M poster-hbm2011_neurodebian
> > % git diff-tree todonotloose^ HEAD
> > :100644 100644 378e137 c39ced7 M .gitmodules
> > :000000 040000 0000000 141dbc1 A challenge-execpapers
> > :040000 040000 401fd66 ee190f0 M frontiers
> > :040000 040000 26c884a ad3e829 M sty
> One more piece of protocol: what git version are you using? The
> release notes mention a fix in this area in v1.7.3[1]:
> * "git merge -s recursive" (which is the default) did not handle cases
> where a directory becomes a file (or vice versa) very well.
> Hopefully this is that. In any case, sounds like a bug.
> (Hopefully someone else can comment on why cherry-pick uses the
> merge machinery to notice conflicts that would not be clear from
> the patch alone.)
> Thanks again.
> Jonathan
> [1] There is an updated Debian source package at [2]. Or, probably
> faster: one can use the build result in bin-wrappers/ from a git.git
> clone in place.
> [2] http://mentors.debian.net/debian/pool/main/g/git/git_1.7.4~rc1-0.1.dsc
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
^ permalink raw reply
* Re: bug in gitk: history moves right when scrolling up and down with mouse wheel
From: Neal Kreitzinger @ 2011-01-08 0:17 UTC (permalink / raw)
To: Stefan Haller; +Cc: Uwe Kleine-König, git
In-Reply-To: <1juqtpt.1dxkc9x1ho9gxzM%lists@haller-berlin.de>
On 1/7/2011 2:24 PM, Stefan Haller wrote:
> 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.
>
I agree. What would be ideal is a left-right scroll bar like the
up-down scrollbar.
v/r,
Neal
^ 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