* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Lars Hjemli @ 2009-01-24 20:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <alpine.DEB.1.00.0901242049580.14855@racer>
On Sat, Jan 24, 2009 at 20:52, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 24 Jan 2009, Lars Hjemli wrote:
>
>> $ git archive --submodules <tree-ish>: Create an archive which
>> includes the trees of all gitlink entries in <tree-ish>, fail unless
>> all the required objects are available.
>>
>> $ git archive --submodules=<group>: Same as above, but only traverse
>> submodules in the specified group (as defined in $GIT_CONFIG).
>
> How about having the former with --submodules='*' and let --submodules
> without argument include those submodules that are checked out (none in a
> bare repository)?
Yeah, that might make more sense (since you'd normally not have access
to the content of non-checked out submodules). I'm also considering
something like --submodules[=(all|checkedout|[group:]<name>)], i.e.
the 'group:'-part could be optional as long as <name> is unambiguous.
--
larsh
^ permalink raw reply
* Re: [PATCH v2] Makefile: Use libc strlcpy on OSX >= 10.2
From: Benjamin Kramer @ 2009-01-24 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wp0o5il.fsf@gitster.siamese.dyndns.org>
On Sat, Jan 24, 2009 at 20:42, Junio C Hamano <gitster@pobox.com> wrote:
>
> This existing one says "If 'uname -r' output does not begin with two
> characters '9.' (nine and dot), then set OLD_ICONV".
>
> I am guessing that 'uname -r' says 9.X in "Darwin 9.X" (which is OSX
> 10.5), and existing conditional says that versions before 9.X needs
> OLD_ICONV but later ones do not need it.
Yeah, that's because versions before 10.5 aka darwin 9 aka "Leopard" have a
broken iconv implementation.
> Does 1.X stand for OSX 10.2? A quick googling finds a handful pages that
> say that OSX 10.2 = Darwin 6.x and OSX 10.3 = Darwin 7.x, and I am not
> sure where you are getting that "begins with one-and-dot" from....
I've got my information from [1]. It says:
darwin 1.3 => OSX 10.0
darwin 1.4 => OSX 10.1
darwin 6 => OSX 10.2
darwin 7 => OSX 10.3
etc.
I don't know why they chose this weird versioning scheme, but wait, it gets
even crazier
darwin 1.4.1 => OSX 10.1
darwin 5.1 => OSX 10.1.1
So my patch checks only for 10.1 but not for 10.1.1 *sigh*
- NO_STRLCPY = YesPlease
+ ifeq ($(shell expr "$(uname_R)" : '[015]\.'),2)
+ NO_STRLCPY = YesPlease
+ endif
Should get all darwin versions before 6.0 in which strlcpy(3) was
introduced. Thanks for your patience ;)
---------------
[1] http://www.opensource.apple.com/darwinsource/
^ permalink raw reply
* Heads up: major rebase -i -p rework coming up
From: Johannes Schindelin @ 2009-01-24 20:25 UTC (permalink / raw)
To: git, Stephen Haberman, spearce, Thomas Rast,
Björn Steinbrink
Hi all,
as probably everybody agrees, the code to preserve merges is a big mess
right now.
Worse, the whole concept of "pick <merge-sha1>" just does not fly well.
So I started a _major_ cleanup, which happens to reduce the code very
nicely so far.
It will take a few days to flesh out, I guess, but these are the major
ideas of my work:
- pick $sha1
will only work on non-merges in the future
- merge $sha1 [$sha1...] was $sha1 "Merge ..."
will merge the given list of commits into the current HEAD, for
the user's reference and to keep up-to-date what was rewritten,
the original merge is shown after the keyword "was" (which is not
a valid SHA-1, luckily)
- goto $sha1
will reset the HEAD to the given commit
- $sha1'
for merge and goto, if a $sha1 ends in a single quote, the
rewritten commit is substituted (if there is one)
Example:
A - B - - - E
\ /
C - D
could yield this TODO script:
pick A
pick C
pick D
goto A'
pick B
merge D' was E
This should lead to a much more intuitive user experience.
I am very sorry if somebody actually scripted rebase -i -p (by setting
GIT_EDITOR with a script), but I am very certain that this cleanup is
absolutely necessary to make rebase -i -p useful.
As always, I am thankful for suggestions to make this even more useful, or
even easier to operate.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Junio C Hamano @ 2009-01-24 20:26 UTC (permalink / raw)
To: Jeff King; +Cc: markus.heidelberg, René Scharfe, git
In-Reply-To: <20090124191700.GA17935@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Jan 24, 2009 at 10:36:24AM -0800, Junio C Hamano wrote:
> ...
>> You did not find the breakage in format-patch either to begin with; so
>> your not finding does not give us much confidence that there is no other
>> breakage, does it?
>>
>> Grumble...
>
> Sadly, this is an area that is not covered very well in the tests
> (partially, I think, because it is "just" output which we tend to
> neglect, and partially because the isatty() stuff is hard to test with
> our harness). So I don't think it's _entirely_ Markus' fault.
Oh, don't get me wrong. I am not interested in finding whose fault it
was. I was just stating the fact that one person not finding a breakage
does not mean much as an assurance.
It is actually not trivial to test this breakage in our test suite.
Before committing 9383af1 (Revert previous two commits, 2009-01-23), I
spent about 20 minutes trying to come up with a test to expose the
breakage in an acceptable way. A test that assumes that it is run with a
controlling terminal is relatively easy to write, but I couldn't come up
with a test that would have triggered even when the tests were run without
a tty (for gory details, see git_config_colorbool() and how stdout_is_tty
is used).
Here is the "relatively easy" but an unacceptable one.
diff --git c/t/t4014-format-patch.sh w/t/t4014-format-patch.sh
index 9d99dc2..609946a 100755
--- c/t/t4014-format-patch.sh
+++ w/t/t4014-format-patch.sh
@@ -255,4 +255,10 @@ test_expect_success 'format-patch respects -U' '
'
+test_expect_success 'format-patch is colorless even with color.ui = auto' '
+ git config color.ui auto &&
+ TERM=ansi git format-patch -1 >/dev/tty &&
+ grep "^+5$" 0001-foo.patch
+'
+
test_done
Points that makes the above patch unacceptable are:
(1) It hardcodes 0001-foo.patch. You could try doing these:
(1.1) patchname=$( ... git format-patch -1) && grep ... <"$patchname"
(1.2) git format-patch -1 --stdout >patchfile && grep ... <patchfile
but they won't work, because "color.ui = auto" will not color unless
the standard output is a tty, and TERM is better than "dumb".
(2) It would not trigger if /dev/tty cannot be opened for writing.
^ permalink raw reply related
* Re: Heads up: major rebase -i -p rework coming up
From: Junio C Hamano @ 2009-01-24 20:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Stephen Haberman, spearce, Thomas Rast,
Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0901242056070.14855@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> pick A
> pick C
> pick D
> goto A'
> pick B
> merge D' was E
>
> This should lead to a much more intuitive user experience.
>
> I am very sorry if somebody actually scripted rebase -i -p (by setting
> GIT_EDITOR with a script), but I am very certain that this cleanup is
> absolutely necessary to make rebase -i -p useful.
Three questions.
- An obvious one first. How does this relate to the sequencer project (that
seems to have gone somewhat dark?)
- What's with the apostrophe? I seem to remember that you argued it would
be enough to make "A" stand for the original when it is used for the
first time and the second and later use can stand for the result of the
last use (e.g. the "goto A'" above can be simply spelled as "goto A"),
when I suggested to use "mark" in a way similar to how fast-import
language uses it during the sequencer discussion?
I am not complaining; I am just being curious why the sudden change of
heart.
- Why do you need "merge D' was E"? Shouldn't "pick E" be able to notice
that E is a merge and decompose it into "merge D' was E" internally?
This one I am somewhat complaining, unless your answer is "because this
way the user could drop some parents from the merge in the editor".
And if your answer is that, then my next question will be "if that is
the case, can the user be expected to easily find out which commit each
parent SHA-1 refers to, without having more hint on the 'merge' insn
line?"
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Jeff King @ 2009-01-24 20:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: markus.heidelberg, René Scharfe, git
In-Reply-To: <7vvds4movp.fsf@gitster.siamese.dyndns.org>
On Sat, Jan 24, 2009 at 12:26:50PM -0800, Junio C Hamano wrote:
> > Sadly, this is an area that is not covered very well in the tests
> > (partially, I think, because it is "just" output which we tend to
> > neglect, and partially because the isatty() stuff is hard to test with
> > our harness). So I don't think it's _entirely_ Markus' fault.
>
> Oh, don't get me wrong. I am not interested in finding whose fault it
> was. I was just stating the fact that one person not finding a breakage
> does not mean much as an assurance.
OK. I was just trying to encourage Markus to keep trying. ;)
> +test_expect_success 'format-patch is colorless even with color.ui = auto' '
> + git config color.ui auto &&
> + TERM=ansi git format-patch -1 >/dev/tty &&
> + grep "^+5$" 0001-foo.patch
> +'
> +
Actually, could this not just be "format-patch is colorless even with
color.ui = always"? I.e., shouldn't format-patch _always_ not have
color, no matter what (and we assume that "always" is a superset of
"auto"). And then it is also much easier to test.
Of course that doesn't fix the fact that it would _also_ be nice to test
"auto" functionality in general. Here you use the fact that format-patch
sends output to a file. But I don't think there is a good way to test
that "git log --color=auto" works as expected.
-Peff
^ permalink raw reply
* Re: CR codes from git commands
From: Brent Goodrick @ 2009-01-24 20:54 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Brent Goodrick, Daniel Barkalow, Mike Ralphson, Junio C Hamano,
git
In-Reply-To: <alpine.DEB.1.00.0901231747340.21467@intel-tinevez-2-302>
Junio C Hamano writes:
> I do not think so. --no-progress should imply --no-cr ;-)
>
> I do not think it makes much sense to pollute your non-terminal with 100
> lines of 1%,2%,3%,...100% if it cannot sensibly do carriage-returns. It
> may be another knob to tweak, but it's a kind of thing you implement
> because you could, not because it makes sense. I would be mildly against
> no-cr.
Good point. I'll drop the --no-cr as redundant.
Johannes Schindelin writes:
> Hi,
>
> On Fri, 23 Jan 2009, Brent Goodrick wrote:
>
> > - Bare minimum: Add a new --no-cr option
>
> I do not see any value of this over "--progress | tr '\r' '\n'". (The
> --progress option being the natural counterpart to --no-progress,
> _forcing_ the display of the progress.)
Agreed. Both --progress and --no-progress are the only options to be
implemented for this.
> Just have a
> look at 7d1864c(Introduce is_bare_repository() and core.bare configuration
> variable).
Note that I'm coming from a CVS and Perforce user background but am
still new to git usage. How do I "take a look" at "7d1864c"?
I will take a closer look at the list of things you explained in your
"Basically, you'll have to" list.
While I'm at it, what is the standard procedure for submitting git
patches for review once I've cooked up and validated it on my end? I'm
guessing posting the patch into this mailing list is part of the
answer to that question.
Thanks,
Brent
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Johannes Schindelin @ 2009-01-24 21:04 UTC (permalink / raw)
To: Junio C Hamano, Stephan Beyer
Cc: git, Stephen Haberman, spearce, Thomas Rast,
Björn Steinbrink
In-Reply-To: <7vpricmoda.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 24 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > pick A
> > pick C
> > pick D
> > goto A'
> > pick B
> > merge D' was E
> >
> > This should lead to a much more intuitive user experience.
> >
> > I am very sorry if somebody actually scripted rebase -i -p (by setting
> > GIT_EDITOR with a script), but I am very certain that this cleanup is
> > absolutely necessary to make rebase -i -p useful.
>
> Three questions.
>
> - An obvious one first. How does this relate to the sequencer project
> (that seems to have gone somewhat dark?)
As far as I can see, Stephan can keep the "mark" command he cherishes so
much, and we can still use thise syntax for rebase -i -p.
> - What's with the apostrophe? I seem to remember that you argued it
> would be enough to make "A" stand for the original when it is used for
> the first time and the second and later use can stand for the result
> of the last use (e.g. the "goto A'" above can be simply spelled as
> "goto A"), when I suggested to use "mark" in a way similar to how
> fast-import language uses it during the sequencer discussion?
>
> I am not complaining; I am just being curious why the sudden change of
> heart.
Very easy explanation. I got convinced by your arguments. Even if I
could imagine that I never use the thing without apostrophe, it is good to
have an obvious indicator that this is not necessarily the original
commit.
> - Why do you need "merge D' was E"? Shouldn't "pick E" be able to
> notice that E is a merge and decompose it into "merge D' was E"
> internally?
>
> This one I am somewhat complaining, unless your answer is "because
> this way the user could drop some parents from the merge in the
> editor".
Not only that; the user could use this to fix mismerges, i.e. by replacing
a SHA-1 with the SHA-1 (or indeed, a short name, unless it is "was") of
the branch that she _actually_ wanted to merge with.
> And if your answer is that, then my next question will be "if that is
> the case, can the user be expected to easily find out which commit
> each parent SHA-1 refers to, without having more hint on the 'merge'
> insn line?"
Nope.
In most cases, however, that should be plenty enough:
merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next
The user does not have to guess much what 9383af1 might refer to.
In case of octopodes, or when the commit message was changed, the user has
to open another command line and look for herself, though.
Ciao,
Dscho
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Johannes Schindelin @ 2009-01-24 21:09 UTC (permalink / raw)
To: Junio C Hamano, Stephan Beyer
Cc: git, Stephen Haberman, spearce, Thomas Rast,
Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0901242156320.14855@racer>
Hi,
On Sat, 24 Jan 2009, Johannes Schindelin wrote:
> > - Why do you need "merge D' was E"? Shouldn't "pick E" be able to
> > notice that E is a merge and decompose it into "merge D' was E"
> > internally?
> >
> > This one I am somewhat complaining, unless your answer is "because
> > this way the user could drop some parents from the merge in the
> > editor".
>
> Not only that; the user could use this to fix mismerges, i.e. by
> replacing a SHA-1 with the SHA-1 (or indeed, a short name, unless it is
> "was") of the branch that she _actually_ wanted to merge with.
>
> > And if your answer is that, then my next question will be "if that
> > is the case, can the user be expected to easily find out which
> > commit each parent SHA-1 refers to, without having more hint on the
> > 'merge' insn line?"
>
> Nope.
>
> In most cases, however, that should be plenty enough:
>
> merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next
>
> The user does not have to guess much what 9383af1 might refer to.
Heh, I think it is much easier than I thought: How about this?
merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next
# \ 9383af1 Revert previous two commits
Obviously, for octopodes, there would be multiple "# \ <SHA-1> <oneline>"
lines...
Ciao,
Dscho
^ permalink raw reply
* Re: CR codes from git commands
From: Johannes Schindelin @ 2009-01-24 21:14 UTC (permalink / raw)
To: Brent Goodrick; +Cc: Daniel Barkalow, Mike Ralphson, Junio C Hamano, git
In-Reply-To: <18811.32772.728276.923430@hungover.brentg.com>
Hi,
On Sat, 24 Jan 2009, Brent Goodrick wrote:
> Note that I'm coming from a CVS and Perforce user background but am
> still new to git usage. How do I "take a look" at "7d1864c"?
Do this in a checkout of git.git:
$ git show 7d1864c
Alternatively, you can follow this URL:
http://repo.or.cz/w/git.git?a=commitdiff;h=7d1864c
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Nanako Shiraishi @ 2009-01-24 21:45 UTC (permalink / raw)
To: Caleb Cushing; +Cc: Junio C Hamano, Charles Bailey, git
In-Reply-To: <81bfc67a0901241036v6ca30c24q54487e118fd67c1c@mail.gmail.com>
Quoting Caleb Cushing <xenoterracide@gmail.com>:
>> There are a few mergetool updates in flight from various authors. How
>> does your submission compare with others' in both form/presentation and
>> clarity of logic (remember, I am not keeping track)?
>
> to be honest, a quick search of the past 2 months of patches didn't
> show me any patches that do the same thing as mine, so I'm not sure
> that comparing one feature to a different feature is good.
Junio never asked what your patch does. He didn't ask if it does
something similar to what other patches do, either.
Your 81bfc67a0901220617l22b5a8e4ma48bb069d67cae91@mail.gmail.com with
'Subject: Re: [PATCH] mergetool merge/skip/abort' that is sent to you and
'Cc: git@vger.kernel.org' starts its body with:
From bf55fdd37f0fa4d0b3a10f43fa3d1815a6dbc6b3 Mon Sep 17 00:00:00 2001
From: Caleb Cushing <xenoterracide@gmail.com>
Date: Tue, 20 Jan 2009 11:33:30 -0500
Subject: [PATCH] mergetool merge/skip/abort
add functionality to skip merging a file or abort from mergetool
---
git-mergetool.sh | 20 ++++++++++++++++++--
1 files changed, 18 insertions(+), 2 deletions(-)
For comparison, 1232578668-2203-1-git-send-email-charles@hashpling.org from
Charles Bailey with 'Subject: [PATCH] mergetool: respect autocrlf by using
checkout-index', with 'Cc: Hannu Koivisto <azure@iki.fi>, Theodore Tso
<tytso@mit.edu>' starts its message body this way:
Previously, git mergetool used cat-file which does not perform git to
worktree conversion. This changes mergetool to use git checkout-index
instead which means that the temporary files used for mergetool use the
correct line endings for the platform.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
git-mergetool.sh | 14 +++++++++++---
t/t7610-mergetool.sh | 15 +++++++++++++--
2 files changed, 24 insertions(+), 5 deletions(-)
Another example is 1232702093-24313-1-git-send-email-heipei@hackvalue.de
from Johannes Gilger with 'Subject: [PATCHv2] git mergetool: Don't repeat
merge tool candidates', sent to Junio, Theodore and the mailing list. Here
is its message body:
git mergetool listed some candidates for mergetools twice, depending on
the environment.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
---
The first patch had the fatal flaw that it listed nothing when DISPLAY
and EDITOR/VISUAL were unset, we fixed that.
The order in which merge-candidates appear is still exactly the same,
only duplicates have been stripped. The check for KDE_FULL_SESSION was
removed since kdiff3 was added as long as DISPLAY was set and we weren't
running gnome.
git-mergetool.sh | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
Let's try to answer the first question Junio asked you together.
Can you spot the differences? How do they compare?
1. You copy-and-pasted output from format-patch, and have the header
part in the message body. Charles and Johannes have moved them to the
Email header.
Their messages are in the form the tool used for patch acceptance
expects. Yours isn't, and forces Junio to manually edit your message
before handling it.
2. You have a two-line Subject: without any commit message. Both Charles
and Johannes describe what their patches are about on the Subject
succinctly in a single line, and they have what old behavior their
patches change, and how their patches do so in their commit
messages. They explained why it is good to apply their patches
well. You didn't.
Johannes Schindelin even pointed out this and the previous point when
you sent your first version but you seem to have ignored him.
3..You quoted other people's comments after the patch and explained that
you addressed the issues, but didn't include them in your Cc list.
Charles has Hanuu on his Cc list, and also Theodore (the original
author) who knows the best about the tool. Johannes also sent his
patch to people who gave him review comments.
They made efforts to make sure that their patches are seen by people
who helped refine thier patches and/or by people who knows the script
that you are modifying well. You didn't.
4. You didn't sign your patch.
Please see Documentation/SubmittingPatches.
About the second question from Junio on the contents of the patch, I can
guess some comments you may receive from him when he reads your patch,
based on review comments I received from him on another shell script
recently.
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..bd5711e 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -177,8 +177,24 @@ merge_file () {
describe_file "$local_mode" "local" "$LOCAL"
describe_file "$remote_mode" "remote" "$REMOTE"
if "$prompt" = true; then
- printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
- read ans
+ while true; do
+ printf "Use (m)erge file or (s)kip file, or (a)bort? (%s): " \
+ "$merge_tool"
+ read ans
+ case "$ans" in
+ [mM]*|"")
+ break
+ ;;
+ [sS]*)
+ cleanup_temp_files
+ return 0
+ ;;
+ [aA]*)
+ cleanup_temp_files
+ exit 0
+ ;;
+ esac
+ done
fi
case "$merge_tool" in
1. Your printf message is funny. You either
(1) Use $merge_tool to merge file, or
(2) Skip file, or
(3) Abort.
but your message makes it look like:
(1) Use $merge_tool to Merge file, or
(2) Use $merge_tool to Skip file, or
(3) Use $merge_tool to Abort.
2. patterns in case command start at the same column as case and esac,
and ";;" is at the same column as any other commands.
case "$ans" in
[mM]*|"")
break
;;
[Ss]*)
...
esac
For what it's worth, I like what your patch does. I use mergetool from
time to time and I can imagine that this new feature will be useful.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [VALGRIND PATCH for nth_last patch series] Fix invalid memory access
From: Thomas Rast @ 2009-01-24 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Johannes Sixt, Johan Herland
In-Reply-To: <200901211019.01493.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
Thomas Rast wrote:
> Thanks for all the work you (both) are doing on this. I hope to find
> the time to read the current state of the series tonight.
I was off by half a week :-(
The debugging 'git log --graph ...' that I forgot about is still in,
sorry. I'll follow up with a small patch. Other than that, I didn't
notice anything, though admittedly it wouldn't have been very hard to
sneak something past me.
By the way, you (Junio) remarked earlier in the thread that we could
forbid any use of 'git checkout -' except in literally that command
(i.e., no options or paths). I'm midly opposed to it because I can
see myself saying 'git checkout -b sidebranch -' (and @{} is somewhat
awkward to type on Swiss keyboards). Admittedly 'git checkout - --
file' looks rather confusing.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH next] t1505: remove debugging cruft
From: Thomas Rast @ 2009-01-24 22:23 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
In-Reply-To: <200901242322.02440.trast@student.ethz.ch>
Remove a call to git-log that I introduced for debugging and that
accidentally made it into d18ba22 (sha1_name: support @{-N} syntax in
get_sha1(), 2009-01-17).
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/t1505-rev-parse-last.sh | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/t/t1505-rev-parse-last.sh b/t/t1505-rev-parse-last.sh
index c745ec4..d709ecf 100755
--- a/t/t1505-rev-parse-last.sh
+++ b/t/t1505-rev-parse-last.sh
@@ -32,8 +32,6 @@ test_expect_success 'setup' '
#
# and 'side' should be the last branch
-git log --graph --all --pretty=oneline --decorate
-
test_rev_equivalent () {
git rev-parse "$1" > expect &&
--
1.6.1.468.g15c0
^ permalink raw reply related
* Re: Heads up: major rebase -i -p rework coming up
From: Thomas Rast @ 2009-01-24 22:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Stephen Haberman, spearce, Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0901242056070.14855@racer>
[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]
Johannes Schindelin wrote:
> Worse, the whole concept of "pick <merge-sha1>" just does not fly well.
[...]
> - merge $sha1 [$sha1...] was $sha1 "Merge ..."
>
> will merge the given list of commits into the current HEAD, for
> the user's reference and to keep up-to-date what was rewritten,
> the original merge is shown after the keyword "was" (which is not
> a valid SHA-1, luckily)
I really like the underlying idea. I'm not even sure if the current
semantics are well-defined in all cases; an explicit merge command at
least makes it very clear what is going on.
However, I think the syntax as proposed above is a bit confusing in
the usual two-parent merge. I couldn't tell whether
merge A was B
was intended to be read as "the merge of A into the current branch" or
"the merge with sha1 A" right away, and I doubt I'll be able to tell
without looking in the (rare) cases I have to invoke rebase -i -p.
I can't really come up with a better replacement for 'was', so how
about
merge A # was B "Merge..."
which would make it more clear that the "was B..." has no effect
whatsoever on the merge's semantics.
> A - B - - - E
> \ /
> C - D
>
> could yield this TODO script:
>
> pick A
> pick C
> pick D
> goto A'
> pick B
> merge D' was E
I kind of wonder if it would be possible to decorate the TODO with
'git log --graph' output, to make it easier to follow the history as
it is built. Perhaps something like
* pick A
|\
* | pick B
goto A'
| * pick C
| * pick D
|/
goto B'
* merge D' # was E
Well, maybe it's not such a good idea after all.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Junio C Hamano @ 2009-01-24 23:01 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Stephan Beyer, git, Stephen Haberman, spearce, Thomas Rast,
Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0901242156320.14855@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> - What's with the apostrophe? I seem to remember that you argued it
>> would be enough to make "A" stand for the original when it is used for
>> the first time and the second and later use can stand for the result
>> of the last use (e.g. the "goto A'" above can be simply spelled as
>> "goto A"), when I suggested to use "mark" in a way similar to how
>> fast-import language uses it during the sequencer discussion?
>>
>> I am not complaining; I am just being curious why the sudden change of
>> heart.
>
> Very easy explanation. I got convinced by your arguments. Even if I
> could imagine that I never use the thing without apostrophe, it is good to
> have an obvious indicator that this is not necessarily the original
> commit.
Now that does not make much sense to me.
The reason I suggested that 'mark' would give a cleaner semantics was
because in your earlier design "A" could either stand for the original or
it could stand for the result of an operation that used "A", and there
could be more than one operation that uses "A". Explicitly naming each
result with a mark would give us an unambiguous way to distinguish them.
I however do not think you would ever use A twice in the context of
"rebase -i/-p". Cherry-picking the same commit twice to create two copies
of them will not happen in that context.
While trying to recreate something like this on top of a commit "o", you
would have to talk about "A" multiple times,...
B---M
/ / \
---o---A---C \
\ \ \
D---N-------O
... but even in such a picture, after one "pick A", you would always want
to refer to the result of the pick, and never the original A.
pick A
goto A'^
pick D
merge A' was N
goto A'
pick B
goto A'
pick C
merge B' was M
merge N' was O
So I am inclined to think that "first use refers to the original, second
and thereafter will refer to the result of the first use" would be a good
enough semantics for "rebase -i/-p", and you do not need "A" vs "A'" for
this.
By the way, I think this example shows that your "goto" might need a way
to refer to the "onto" commit in some way (I just used "A'^" there).
On the other hand, if you are aiming to allow users to create (by editing
the insn file) an arbitrarily different structure like this, starting from
the same topology:
---o---B---C---A
\ \
A---D-------O
that is, rebasing the upper line of development into one linear sequence
with different patch order, while rebasing the lower line into another
linear sequence by rebasing D on top of A, you would need to be able to
refer to the two different results of "using A", and your "A'" notation
would not help.
pick B
pick C
pick A
goto B'^
pick A
pick D
merge A' was O
The last "merge A' was O" is done while on the result of applying D on top
of the result of applying A on the lower line, and wants to call the tip
of the upper line by referring it as "the result of applying A".
But there are two results from applying A, and I do not think you can
avoid 'mark', even though you for some reason seem to hate it.
If this kind of transformation is outside the scope of your redesign
(which I think is a sensible design decision), I do not see why you would
need "A vs A'".
You either need the full power of 'mark', or "A is original until it is
used, and then the one and only one result once it is used,"; nothing in
between like "A vs A'" would make much sense.
^ permalink raw reply
* [PATCH 01/10] cvsserver: removed unused sha1Or-k mode from kopts_from_path
From: Matthew Ogilvie @ 2009-01-24 23:43 UTC (permalink / raw)
To: git; +Cc: Matthew Ogilvie
In-Reply-To: <1232840601-24696-1-git-send-email-mmogilvi_git@miniinfo.net>
sha1Or-k was a vestige from an early, never-released
attempt to handle some oddball cases of CRLF conversion (-k option).
Ultimately it wasn't needed, and I should have gotten rid of it
before submitting the CRLF patch in the first place.
See also 90948a42892779 (add ability to guess -kb from contents).
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
git-cvsserver.perl | 38 +++++---------------------------------
1 files changed, 5 insertions(+), 33 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index fef7faf..1de0c1e 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -2355,42 +2355,14 @@ sub kopts_from_path
}
elsif( ($cfg->{gitcvs}{allbinary} =~ /^\s*guess\s*$/i) )
{
- if( $srcType eq "sha1Or-k" &&
- !defined($name) )
+ if( is_binary($srcType,$name) )
{
- my ($ret)=$state->{entries}{$path}{options};
- if( !defined($ret) )
- {
- $ret=$state->{opt}{k};
- if(defined($ret))
- {
- $ret="-k$ret";
- }
- else
- {
- $ret="";
- }
- }
- if( ! ($ret=~/^(|-kb|-kkv|-kkvl|-kk|-ko|-kv)$/) )
- {
- print "E Bad -k option\n";
- $log->warn("Bad -k option: $ret");
- die "Error: Bad -k option: $ret\n";
- }
-
- return $ret;
+ $log->debug("... as binary");
+ return "-kb";
}
else
{
- if( is_binary($srcType,$name) )
- {
- $log->debug("... as binary");
- return "-kb";
- }
- else
- {
- $log->debug("... as text");
- }
+ $log->debug("... as text");
}
}
}
@@ -2497,7 +2469,7 @@ sub open_blob_or_die
die "Unable to open file $name: $!\n";
}
}
- elsif( $srcType eq "sha1" || $srcType eq "sha1Or-k" )
+ elsif( $srcType eq "sha1" )
{
unless ( defined ( $name ) and $name =~ /^[a-zA-Z0-9]{40}$/ )
{
--
1.6.1.81.g9833d.dirty
^ permalink raw reply related
* [PATCH 00/10] Misc. cvsserver, dashless, and test suite patches
From: Matthew Ogilvie @ 2009-01-24 23:43 UTC (permalink / raw)
To: git; +Cc: Matthew Ogilvie
This series of small patches fixes a few minor issues I noticed
while researching what it would take to for cvsserver to support
cvs's "-r" flags properly. No real progress on the "-r" front,
but see comments in the "cvsserver: add comments about database ..."
email.
The "run test suite without dashed..." patch has wide scope,
even though is is fairly small. It (along with fixing the things it
found in t2300 and t3409) was inspired by a desire to avoid future
regressions of the bug fixed in "cvsserver: run dashless 'git commands'"
patch, where git-cvsserver was trying to run dashed commands that
are not in the default PATH...
As this patch series was going to press, I noticed that
the "run test suite without dashed..." patch probably conflicts with
recently posted valgrind test suite patches. See extra comments in
the email for possible resolutions.
The other patches in this series are mostly independent of each other.
When working on the "git-shell" patch, I noticed a couple of other
things related to "git-shell" that maybe ought to be changed (change
the argc==2 special case, and document the best way(s) to
configure an account to use git-shell). See also extra information in
the email.
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
Matthew Ogilvie (10):
cvsserver: removed unused sha1Or-k mode from kopts_from_path
cvsserver: add comments about database schema/usage
cvsserver: remove unused functions _headrev and gethistory
git-shell: allow running git-cvsserver, not just cvs
cvsserver: run dashless "git command"s to access plumbing
t2300: use documented technique to invoke git-sh-setup
t3409: use dashless "git commit" instead of "git-commit"
run test suite without dashed git-commands in PATH
Revert "adapt git-cvsserver manpage to dash-free syntax"
cvsserver doc: emphasize using CVS_SERVER= phrase within CVSROOT
.gitignore | 1 +
Documentation/git-cvsserver.txt | 29 +++++--
Documentation/git-shell.txt | 5 +-
Makefile | 40 +++++++---
git-cvsserver.perl | 163 ++++++++++++++++---------------------
shell.c | 1 +
t/t2300-cd-to-toplevel.sh | 2 +-
t/t3409-rebase-preserve-merges.sh | 6 +-
t/t9400-git-cvsserver-server.sh | 88 ++++++++++++++++++++
t/test-lib.sh | 14 +++-
test-bin-wrapper.sh | 12 +++
11 files changed, 246 insertions(+), 115 deletions(-)
create mode 100644 test-bin-wrapper.sh
^ permalink raw reply
* [PATCH 02/10] cvsserver: add comments about database schema/usage
From: Matthew Ogilvie @ 2009-01-24 23:43 UTC (permalink / raw)
To: git; +Cc: Matthew Ogilvie
In-Reply-To: <1232840601-24696-2-git-send-email-mmogilvi_git@miniinfo.net>
No functionality changes, but these comments should make it easier to
understand how it works.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
This is the result of some initial research into what it would
take to support switching branches/tags/commithashes for the entire
sandbox using "cvs update -r TAG". This seems like the one remaining
big missing feature that makes git-cvsserver a substantial downgrade
compared to a real CVS server.
git-cvsserver's support for cvs's "-r" arguments is kind of hit
or miss:
- Some commands ignore it completely. This includes "checkout",
but checkout does have a kind of workaround: you can checkout
any branch by specifying "cvs checkout branch". (Normally
it is "cvs checkout module".) But that sandbox is then locked
to that branch, you can't switch to another.
- Some commands (e.g. update) allow you to specify CVS-style
version numbers with -r, but that is generally only useful if
you are examining a single file.
- Some of those commands also recognize git commit hashes. But
due to the internal database model, the commithash form will only
work for files that were actually modified in the requested
commit, and for which cvsserver has previously decided that
the commit is on the same branch that the sandbox
is locked to (it has already assigned CVS revision numbers
for it). Other commands (including update) do not recognize
the commithash form at all (ignores it if it doesn't look like
a CVS version number, even though the underlying getmeta()
function is more a little more general).
Even the relatively simple goal of being able to update to an
older version on the same branch involves some significant costs:
- Perhaps store O(numCommits*totalNumFiles) entries in the
revision table, instead of the current more reasonable
O(numCommits*averageNumChangedFilesPerCommit). Perhaps
this could be combined with a significant schema change that
involves assigning short ints to distinct commithash
values and distinct filenames, looking up author/mode
information directly in git on demand, and just storing the
short ints in the revisions table to shrink each row
as much as possible.
- Fork off extra git commands to find the most recent
commit (relative to the supplied commit) that modified each
file, then look that up in the DB. For many files, it
is likely to have to search quite a ways, and if it the search
is done with a separate command per file, it could
get expensive. Also watch out for "other"
branches that won't be in the DB. Sounds like a lot
of extra CPU usage re-parsing commit history for every
file...
Thoughts about full branch support in cvsserver:
- One way would be to add a "branch" column to the "revisions"
and "headers" tables. Also add a branch table (details TBD)?
- Alternatively, drop the DB and see if maybe we could store
file revision number information using git's core data structures:
"refs/cvsfileversions/{branch}", with a tree structure for storing
file revision number to commithash/path mappings that is
specifically designed to use the strengths of the DAG
representation and pack files.
- I have vague notions of other techniques as well.
- Recognise that names of branches may change as heads advance
and things get merged, but the CVS branch /number/ needs
to remain consistent.
- Recognize that in general you can not reliably regenerate
the DB. Depending on what sequence of git-cvsserver and
git-merge commands, versions of files can end up with
different CVS revision numbers.
- Has anyone thought about implementing server emulators for
other version control systems (git-svnserver and similar)?
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
git-cvsserver.perl | 46 ++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 1de0c1e..f7891b8 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -2045,6 +2045,10 @@ sub statecleanup
$state->{entries} = {};
}
+# Return working directory revision int "X" from CVS revision "1.X" out
+# of the the working directory "entries" state, for the given filename.
+# Return negative "X" to represent the file is scheduled for removal
+# when it is committed.
sub revparse
{
my $filename = shift;
@@ -2775,6 +2779,16 @@ sub new
}
# Construct the revision table if required
+ # The revision table stores an entry for each file, each time that file
+ # changes.
+ # numberOfRecords = O( numCommits * averageNumChangedFilesPerCommit )
+ # This is not sufficient to support "-r {commithash}" for any
+ # files except files that were modified by that commit (also,
+ # some places in the code ignore/effectively strip out -r in
+ # some cases, before it gets passed to getmeta()).
+ # The "filehash" field typically has a git blob hash, but can also
+ # be set to "dead" to indicate that the given version of the file
+ # should not exist in the sandbox.
unless ( $self->{tables}{$self->tablename("revision")} )
{
my $tablename = $self->tablename("revision");
@@ -2802,6 +2816,15 @@ sub new
}
# Construct the head table if required
+ # The head table (along with the "last_commit" entry in the property
+ # table) is the persisted working state of the "sub update" subroutine.
+ # All of it's data is read entirely first, and completely recreated
+ # last, every time "sub update" runs.
+ # This is also used by "sub getmeta" when it is asked for the latest
+ # version of a file (as opposed to some specific version).
+ # Another way of thinking about it is as a single slice out of
+ # "revisions", giving just the most recent revision information for
+ # each file.
unless ( $self->{tables}{$self->tablename("head")} )
{
my $tablename = $self->tablename("head");
@@ -2824,6 +2847,7 @@ sub new
}
# Construct the properties table if required
+ # - "last_commit" - Used by "sub update".
unless ( $self->{tables}{$self->tablename("properties")} )
{
my $tablename = $self->tablename("properties");
@@ -2836,6 +2860,11 @@ sub new
}
# Construct the commitmsgs table if required
+ # The commitmsgs table is only used for merge commits, since
+ # "sub update" will only keep one branch of parents. Shortlogs
+ # for ignored commits (i.e. not on the chosen branch) will be used
+ # to construct a replacement "collapsed" merge commit message,
+ # which will be stored in this table. See also "sub commitmessage".
unless ( $self->{tables}{$self->tablename("commitmsgs")} )
{
my $tablename = $self->tablename("commitmsgs");
@@ -2867,6 +2896,14 @@ sub tablename
=head2 update
+Bring the database up to date with the latest changes from
+the git repository.
+
+Internal working state is read out of the "head" table and the
+"last_commit" property, then it updates "revisions" based on that, and
+finally it writes the new internal state back to the "head" table
+so it can be used as a starting point the next time update is called.
+
=cut
sub update
{
@@ -2980,17 +3017,18 @@ sub update
next;
} elsif (@{$commit->{parents}} > 1) {
# it is a merge commit, for each parent that is
- # not $lastpicked, see if we can get a log
+ # not $lastpicked (not given a CVS revision number),
+ # see if we can get a log
# from the merge-base to that parent to put it
# in the message as a merge summary.
my @parents = @{$commit->{parents}};
foreach my $parent (@parents) {
- # git-merge-base can potentially (but rarely) throw
- # several candidate merge bases. let's assume
- # that the first one is the best one.
if ($parent eq $lastpicked) {
next;
}
+ # git-merge-base can potentially (but rarely) throw
+ # several candidate merge bases. let's assume
+ # that the first one is the best one.
my $base = eval {
safe_pipe_capture('git-merge-base',
$lastpicked, $parent);
--
1.6.1.81.g9833d.dirty
^ permalink raw reply related
* [PATCH 06/10] t2300: use documented technique to invoke git-sh-setup
From: Matthew Ogilvie @ 2009-01-24 23:43 UTC (permalink / raw)
To: git; +Cc: Matthew Ogilvie
In-Reply-To: <1232840601-24696-6-git-send-email-mmogilvi_git@miniinfo.net>
This is needed to allow the test suite to run against a minimal bin
directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
t/t2300-cd-to-toplevel.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
index e42cbfe..eac348a 100755
--- a/t/t2300-cd-to-toplevel.sh
+++ b/t/t2300-cd-to-toplevel.sh
@@ -8,7 +8,7 @@ test_cd_to_toplevel () {
test_expect_success "$2" '
(
cd '"'$1'"' &&
- . git-sh-setup &&
+ . "$(git --exec-path)"/git-sh-setup &&
cd_to_toplevel &&
[ "$(unset PWD; /bin/pwd)" = "$TOPLEVEL" ]
)
--
1.6.1.81.g9833d.dirty
^ permalink raw reply related
* [PATCH 05/10] cvsserver: run dashless "git command"s to access plumbing
From: Matthew Ogilvie @ 2009-01-24 23:43 UTC (permalink / raw)
To: git; +Cc: Matthew Ogilvie
In-Reply-To: <1232840601-24696-5-git-send-email-mmogilvi_git@miniinfo.net>
git-cvsserver has been installed in the default $(bindir)
since 1df2a1ce806, but if you actually invoke it that way
(CVS_SERVER=git-cvsserver), it was failing because most of the
dashed-form plumbing commands cvsserver invokes are not in the PATH.
It seems best not to just switch to pure CVS_SERVER="git cvsserver",
which does not work with cvs's ":fork:" connection scheme. In
this case "cvs" presumably uses the whole value as argv[0] for
exec(), and of course no execuable named "git cvsserver" exists.
But both settings worked under some circumstances:
CVS_SERVER="git cvsserver" works OK for cvs's ":ext:" scheme (at
least with ssh), presumably because of how sshd invokes
/bin/sh -c "{args}" with limited quoting, and "git"
would set up the PATH so that cvsserver could run dashed commands
correctly.
Also, CVS_SERVER="git-cvsserver" has been working OK under git's test
framework, because the test framework currently always sets up a PATH
that includes the dashed forms.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Note: I only changed the actual command invocations; I left error
messages and comments as-is. Should they be changed as well?
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
git-cvsserver.perl | 40 ++++++++++++++++++++--------------------
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index fe23b49..8e9e659 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -283,7 +283,7 @@ sub req_Root
return 0;
}
- my @gitvars = `git-config -l`;
+ my @gitvars = `git config -l`;
if ($?) {
print "E problems executing git-config on the server -- this is not a git repository or the PATH is not set correctly.\n";
print "E \n";
@@ -700,7 +700,7 @@ sub req_Modified
# Save the file data in $state
$state->{entries}{$state->{directory}.$data}{modified_filename} = $filename;
$state->{entries}{$state->{directory}.$data}{modified_mode} = $mode;
- $state->{entries}{$state->{directory}.$data}{modified_hash} = `git-hash-object $filename`;
+ $state->{entries}{$state->{directory}.$data}{modified_hash} = `git hash-object $filename`;
$state->{entries}{$state->{directory}.$data}{modified_hash} =~ s/\s.*$//s;
#$log->debug("req_Modified : file=$data mode=$mode size=$size");
@@ -1287,7 +1287,7 @@ sub req_ci
# do a checkout of the file if it is part of this tree
if ($wrev) {
- system('git-checkout-index', '-f', '-u', $filename);
+ system('git', 'checkout-index', '-f', '-u', $filename);
unless ($? == 0) {
die "Error running git-checkout-index -f -u $filename : $!";
}
@@ -1329,15 +1329,15 @@ sub req_ci
{
$log->info("Removing file '$filename'");
unlink($filename);
- system("git-update-index", "--remove", $filename);
+ system("git", "update-index", "--remove", $filename);
}
elsif ( $addflag )
{
$log->info("Adding file '$filename'");
- system("git-update-index", "--add", $filename);
+ system("git", "update-index", "--add", $filename);
} else {
$log->info("Updating file '$filename'");
- system("git-update-index", $filename);
+ system("git", "update-index", $filename);
}
}
@@ -1349,7 +1349,7 @@ sub req_ci
return;
}
- my $treehash = `git-write-tree`;
+ my $treehash = `git write-tree`;
chomp $treehash;
$log->debug("Treehash : $treehash, Parenthash : $parenthash");
@@ -1366,7 +1366,7 @@ sub req_ci
}
close $msg_fh;
- my $commithash = `git-commit-tree $treehash -p $parenthash < $msg_filename`;
+ my $commithash = `git commit-tree $treehash -p $parenthash < $msg_filename`;
chomp($commithash);
$log->info("Commit hash : $commithash");
@@ -1819,7 +1819,7 @@ sub req_annotate
# TODO: if we got a revision from the client, use that instead
# to look up the commithash in sqlite (still good to default to
# the current head as we do now)
- system("git-read-tree", $lastseenin);
+ system("git", "read-tree", $lastseenin);
unless ($? == 0)
{
print "E error running git-read-tree $lastseenin $ENV{GIT_INDEX_FILE} $!\n";
@@ -1828,7 +1828,7 @@ sub req_annotate
$log->info("Created index '$ENV{GIT_INDEX_FILE}' with commit $lastseenin - exit status $?");
# do a checkout of the file
- system('git-checkout-index', '-f', '-u', $filename);
+ system('git', 'checkout-index', '-f', '-u', $filename);
unless ($? == 0) {
print "E error running git-checkout-index -f -u $filename : $!\n";
return;
@@ -1859,7 +1859,7 @@ sub req_annotate
close ANNOTATEHINTS
or (print "E failed to write $a_hints: $!\n"), return;
- my @cmd = (qw(git-annotate -l -S), $a_hints, $filename);
+ my @cmd = (qw(git annotate -l -S), $a_hints, $filename);
if (!open(ANNOTATE, "-|", @cmd)) {
print "E error invoking ". join(' ',@cmd) .": $!\n";
return;
@@ -2080,17 +2080,17 @@ sub transmitfile
die "Need filehash" unless ( defined ( $filehash ) and $filehash =~ /^[a-zA-Z0-9]{40}$/ );
- my $type = `git-cat-file -t $filehash`;
+ my $type = `git cat-file -t $filehash`;
chomp $type;
die ( "Invalid type '$type' (expected 'blob')" ) unless ( defined ( $type ) and $type eq "blob" );
- my $size = `git-cat-file -s $filehash`;
+ my $size = `git cat-file -s $filehash`;
chomp $size;
$log->debug("transmitfile($filehash) size=$size, type=$type");
- if ( open my $fh, '-|', "git-cat-file", "blob", $filehash )
+ if ( open my $fh, '-|', "git", "cat-file", "blob", $filehash )
{
if ( defined ( $options->{targetfile} ) )
{
@@ -2942,7 +2942,7 @@ sub update
push @git_log_params, $self->{module};
}
# git-rev-list is the backend / plumbing version of git-log
- open(GITLOG, '-|', 'git-rev-list', @git_log_params) or die "Cannot call git-rev-list: $!";
+ open(GITLOG, '-|', 'git', 'rev-list', @git_log_params) or die "Cannot call git-rev-list: $!";
my @commits;
@@ -3029,7 +3029,7 @@ sub update
# several candidate merge bases. let's assume
# that the first one is the best one.
my $base = eval {
- safe_pipe_capture('git-merge-base',
+ safe_pipe_capture('git', 'merge-base',
$lastpicked, $parent);
};
# The two branches may not be related at all,
@@ -3041,7 +3041,7 @@ sub update
if ($base) {
my @merged;
# print "want to log between $base $parent \n";
- open(GITLOG, '-|', 'git-log', '--pretty=medium', "$base..$parent")
+ open(GITLOG, '-|', 'git', 'log', '--pretty=medium', "$base..$parent")
or die "Cannot call git-log: $!";
my $mergedhash;
while (<GITLOG>) {
@@ -3083,7 +3083,7 @@ sub update
if ( defined ( $lastpicked ) )
{
- my $filepipe = open(FILELIST, '-|', 'git-diff-tree', '-z', '-r', $lastpicked, $commit->{hash}) or die("Cannot call git-diff-tree : $!");
+ my $filepipe = open(FILELIST, '-|', 'git', 'diff-tree', '-z', '-r', $lastpicked, $commit->{hash}) or die("Cannot call git-diff-tree : $!");
local ($/) = "\0";
while ( <FILELIST> )
{
@@ -3157,7 +3157,7 @@ sub update
# this is used to detect files removed from the repo
my $seen_files = {};
- my $filepipe = open(FILELIST, '-|', 'git-ls-tree', '-z', '-r', $commit->{hash}) or die("Cannot call git-ls-tree : $!");
+ my $filepipe = open(FILELIST, '-|', 'git', 'ls-tree', '-z', '-r', $commit->{hash}) or die("Cannot call git-ls-tree : $!");
local $/ = "\0";
while ( <FILELIST> )
{
@@ -3448,7 +3448,7 @@ sub commitmessage
return $message;
}
- my @lines = safe_pipe_capture("git-cat-file", "commit", $commithash);
+ my @lines = safe_pipe_capture("git", "cat-file", "commit", $commithash);
shift @lines while ( $lines[0] =~ /\S/ );
$message = join("",@lines);
$message .= " " if ( $message =~ /\n$/ );
--
1.6.1.81.g9833d.dirty
^ permalink raw reply related
* [PATCH 03/10] cvsserver: remove unused functions _headrev and gethistory
From: Matthew Ogilvie @ 2009-01-24 23:43 UTC (permalink / raw)
To: git; +Cc: Matthew Ogilvie
In-Reply-To: <1232840601-24696-3-git-send-email-mmogilvi_git@miniinfo.net>
Remove:
- _headrev() - cvsserver already uses similar functionality
from getmeta() and gethead().
- gethistory() - cvsserver already uses similar functions
gethistorydense() and getlog().
- #'annotate' comment - Uncommented annotate line is 2 lines earlier.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
git-cvsserver.perl | 37 ++++---------------------------------
1 files changed, 4 insertions(+), 33 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index f7891b8..fe23b49 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -78,7 +78,6 @@ my $methods = {
'editors' => \&req_EMPTY,
'annotate' => \&req_annotate,
'Global_option' => \&req_Globaloption,
- #'annotate' => \&req_CATCHALL,
};
##############################################
@@ -3310,19 +3309,6 @@ sub insert_head
$insert_head->execute($name, $revision, $filehash, $commithash, $modified, $author, $mode);
}
-sub _headrev
-{
- my $self = shift;
- my $filename = shift;
- my $tablename = $self->tablename("head");
-
- my $db_query = $self->{dbh}->prepare_cached("SELECT filehash, revision, mode FROM $tablename WHERE name=?",{},1);
- $db_query->execute($filename);
- my ( $hash, $revision, $mode ) = $db_query->fetchrow_array;
-
- return ( $hash, $revision, $mode );
-}
-
sub _get_prop
{
my $self = shift;
@@ -3382,6 +3368,8 @@ sub gethead
=head2 getlog
+See also gethistorydense().
+
=cut
sub getlog
@@ -3467,25 +3455,6 @@ sub commitmessage
return $message;
}
-=head2 gethistory
-
-This function takes a filename (with path) argument and returns an arrayofarrays
-containing revision,filehash,commithash ordered by revision descending
-
-=cut
-sub gethistory
-{
- my $self = shift;
- my $filename = shift;
- my $tablename = $self->tablename("revision");
-
- my $db_query;
- $db_query = $self->{dbh}->prepare_cached("SELECT revision, filehash, commithash FROM $tablename WHERE name=? ORDER BY revision DESC",{},1);
- $db_query->execute($filename);
-
- return $db_query->fetchall_arrayref;
-}
-
=head2 gethistorydense
This function takes a filename (with path) argument and returns an arrayofarrays
@@ -3495,6 +3464,8 @@ This version of gethistory skips deleted entries -- so it is useful for annotate
The 'dense' part is a reference to a '--dense' option available for git-rev-list
and other git tools that depend on it.
+See also getlog().
+
=cut
sub gethistorydense
{
--
1.6.1.81.g9833d.dirty
^ permalink raw reply related
* [PATCH 04/10] git-shell: allow running git-cvsserver, not just cvs
From: Matthew Ogilvie @ 2009-01-24 23:43 UTC (permalink / raw)
To: git; +Cc: Matthew Ogilvie, Johannes.Schindelin
In-Reply-To: <1232840601-24696-4-git-send-email-mmogilvi_git@miniinfo.net>
Add the ability to ask a git-shell restricted account to explicitly run
git-cvsserver, instead of requesting a fake "cvs". With this, an account
could be reconfigured to use/not use git-shell without requiring
changes to client side configuration. It also avoids confusing
users about which way cvs should be configured; if cvs is accessing
a git repository, always set CVS_SERVER=git-cvsserver.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
--------------
Question 1:
There is a surprising shortage of solid information about the
best way(s) restrict what commands can be run by ssh accounts,
both in general and for git specifically. Is
putting git-shell in /etc/passwd the best way? Are there other ways,
just as good or better?
Perhaps someone who really knows could add something to the git-shell.txt
man page describing the possible way(s) to configure an account to
be restricted to git-shell.
--------------
Question 2:
As near as I can tell, git-shell as run by sshd is typically
invoked such that it ends up with an argv with 3 arguments of the
form ("git-shell","-c","command arguments").
But the (argc==2 "cvs server") special case near line 69 of shell.c
appears to allow the middle argument ("-c") to be missing, but
only for "cvs server".
My question is, why was this special case put there? Is a remnant of
an imperfect ad-hoc test framework someone used, or is there a
legitimate configuration where the "-c" is missing?
It seems to me that either this missing "-c" case should be
eliminated, or it should be made more general: If some
configuration of sshd leaves out the "-c", then it probably
leaves it out for anything you try to invoke, not just
"cvs server".
--------------
Hints about testing:
In addition to the test cases that are included in the patch, I tested
this by setting up an extra user account with the following
shell script set as the shell in /etc/passwd (yes, a shell script
is my shell...). This allows me to tweak enviornment variables,
log how it is invoked, maybe tee off the stdin/stdout, etc:
---CUT---
#!/bin/sh
log()
{ echo "$1" >> remote.log
}
log "------------"
log ""
log "cmd:$0"
for arg in "$@" ; do
log "arg:$arg"
done
PATH="/path/to/version/to/test:$PATH"
log "path: $PATH"
#tee input.out | git-shell "$@" | tee output.out
exec git-shell "$@"
---CUT---
But note that you probably do NOT want to route through a
wrapper like this for production...
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
Documentation/git-cvsserver.txt | 7 ++-
Documentation/git-shell.txt | 5 +-
shell.c | 1 +
t/t9400-git-cvsserver-server.sh | 88 +++++++++++++++++++++++++++++++++++++++
4 files changed, 97 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 785779e..e32ad7b 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -113,9 +113,12 @@ cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>
------
This has the advantage that it will be saved in your 'CVS/Root' files and
you don't need to worry about always setting the correct environment
-variable. SSH users restricted to 'git-shell' don't need to override the default
-with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean
+variable. SSH users restricted to 'git-shell' do not need to
+override CVS_SERVER as 'git-cvsserver' because
+'git-shell' understands `cvs` to mean
'git-cvsserver' and pretends that the other end runs the real 'cvs' better.
+But restricted users can still override it for consistency and to avoid
+reconfiguration if they are later promoted to full SSH access.
--
2. For each repo that you want accessible from CVS you need to edit config in
the repo and add the following section.
diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
index 3f8d973..68cb834 100644
--- a/Documentation/git-shell.txt
+++ b/Documentation/git-shell.txt
@@ -18,8 +18,9 @@ of server-side GIT commands implementing the pull/push functionality.
The commands can be executed only by the '-c' option; the shell is not
interactive.
-Currently, only three commands are permitted to be called, 'git-receive-pack'
-'git-upload-pack' with a single required argument or 'cvs server' (to invoke
+Currently, only four commands are permitted to be called, 'git-receive-pack'
+'git-upload-pack' with a single required argument,
+'git-cvsserver server', or 'cvs server' (to invoke
'git-cvsserver').
Author
diff --git a/shell.c b/shell.c
index e339369..6ed960f 100644
--- a/shell.c
+++ b/shell.c
@@ -40,6 +40,7 @@ static struct commands {
} cmd_list[] = {
{ "git-receive-pack", do_generic_cmd },
{ "git-upload-pack", do_generic_cmd },
+ { "git-cvsserver", do_cvs_cmd },
{ "cvs", do_cvs_cmd },
{ NULL },
};
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 6a37f71..b23a774 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -501,4 +501,92 @@ test_expect_success 'cvs annotate' '
test_cmp ../expect ../actual
'
+#------------
+# access server through git-shell:
+#------------
+
+cd "$WORKDIR"
+test_expect_success 'setup fake_ssh' '
+ cd cvswork &&
+ ( echo "#!/bin/sh" &&
+ echo "echo \"cmd:\$*\" >> fake_ssh_sh.log" &&
+ echo "if test x\"\$1 \$2 \$3\" = x\"-l user machine\" ; then" &&
+ echo " shift ; shift ; shift" &&
+ echo " exec /bin/sh -c \"\$*\"" &&
+ echo "fi" &&
+ echo "echo FAIL" &&
+ echo "exit 1"
+ ) > fake_ssh_sh &&
+ ( echo "#!/bin/sh" &&
+ echo "echo \"cmd:\$*\" >> fake_ssh_git-shell.log" &&
+ echo "if test x\"\$1 \$2 \$3\" = x\"-l user machine\" ; then" &&
+ echo " shift ; shift ; shift" &&
+ echo " exec git-shell -c \"\$*\""
+ echo "fi" &&
+ echo "echo FAIL" &&
+ echo "exit 1"
+ ) > fake_ssh_git-shell &&
+ chmod +x fake_ssh_sh fake_ssh_git-shell
+'
+
+cd "$WORKDIR"
+test_expect_success 'fake_ssh ... sh git-cvsserver' '
+ ( cd cvswork &&
+ CVS_SERVER="git-cvsserver" &&
+ CVS_RSH="./fake_ssh_sh" &&
+ CVSROOT=":ext:user@machine$SERVERDIR" &&
+ export CVS_SERVER CVS_RSH CVSROOT &&
+ GIT_CONFIG="$git_config" cvs -d "$CVSROOT" up -p status.file > ../out &&
+ cmp status.file ../out
+ )
+'
+
+cd "$WORKDIR"
+test_expect_success 'fake_ssh ... sh git cvsserver' '
+ ( cd cvswork &&
+ CVS_SERVER="git cvsserver" &&
+ CVS_RSH="./fake_ssh_sh" &&
+ CVSROOT=":ext:user@machine$SERVERDIR" &&
+ export CVS_SERVER CVS_RSH CVSROOT &&
+ GIT_CONFIG="$git_config" cvs -d "$CVSROOT" up -p status.file > ../out &&
+ cmp status.file ../out
+ )
+'
+
+cd "$WORKDIR"
+test_expect_success 'fake_ssh ... git-shell git-cvsserver' '
+ ( cd cvswork &&
+ CVS_SERVER="git-cvsserver" &&
+ CVS_RSH="./fake_ssh_git-shell" &&
+ CVSROOT=":ext:user@machine$SERVERDIR" &&
+ export CVS_SERVER CVS_RSH CVSROOT &&
+ GIT_CONFIG="$git_config" cvs -d "$CVSROOT" up -p status.file > ../out &&
+ cmp status.file ../out
+ )
+'
+
+cd "$WORKDIR"
+test_expect_success 'fake_ssh ... git-shell git cvsserver' '
+ ( cd cvswork &&
+ CVS_SERVER="git cvsserver" &&
+ CVS_RSH="./fake_ssh_git-shell" &&
+ CVSROOT=":ext:user@machine$SERVERDIR" &&
+ export CVS_SERVER CVS_RSH CVSROOT &&
+ GIT_CONFIG="$git_config" cvs -d "$CVSROOT" up -p status.file > ../out &&
+ cmp status.file ../out
+ )
+'
+
+cd "$WORKDIR"
+test_expect_success 'fake_ssh ... git-shell cvs' '
+ ( cd cvswork &&
+ CVS_SERVER="cvs" &&
+ CVS_RSH="./fake_ssh_git-shell" &&
+ CVSROOT=":ext:user@machine$SERVERDIR" &&
+ export CVS_SERVER CVS_RSH CVSROOT &&
+ GIT_CONFIG="$git_config" cvs -d "$CVSROOT" up -p status.file > ../out &&
+ cmp status.file ../out
+ )
+'
+
test_done
--
1.6.1.81.g9833d.dirty
^ permalink raw reply related
* [PATCH 10/10] cvsserver doc: emphasize using CVS_SERVER= phrase within CVSROOT
From: Matthew Ogilvie @ 2009-01-24 23:43 UTC (permalink / raw)
To: git; +Cc: Matthew Ogilvie
In-Reply-To: <1232840601-24696-10-git-send-email-mmogilvi_git@miniinfo.net>
Add information about CVSROOT=":ext;CVS_SERVER=git-cvsserver:..." to
"SYNOPSIS" section. This information was/is already spelled out deep in
the "INSTALLATION" section, but this new method is far superior to
the old backwards-compatible option (separate environment variable),
so try to emphasize it's use for versions of CVS that support it.
Also mention how to connect to a local git repository using
git-cvsserver.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Documentation/git-cvsserver.txt | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 6f8cd88..d1dc5be 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -14,6 +14,18 @@ SSH:
export CVS_SERVER=git-cvsserver
'cvs' -d :ext:user@server/path/repo.git co <HEAD_name>
+SSH with newer CVS versions (>= 1.12.11):
+
+[verse]
+export CVSROOT=":ext;CVS_SERVER=git-cvsserver:user@server/path/repo.git"
+'cvs' -d "$CVSROOT" co <HEAD_name>
+
+Local repository:
+
+[verse]
+export CVSROOT=":fork;CVS_SERVER=git-cvsserver:/path/repo.git"
+'cvs' -d "$CVSROOT" co <HEAD_name>
+
pserver (/etc/inetd.conf):
[verse]
--
1.6.1.81.g9833d.dirty
^ permalink raw reply related
* [PATCH 09/10] Revert "adapt git-cvsserver manpage to dash-free syntax"
From: Matthew Ogilvie @ 2009-01-24 23:43 UTC (permalink / raw)
To: git; +Cc: Matthew Ogilvie
In-Reply-To: <1232840601-24696-9-git-send-email-mmogilvi_git@miniinfo.net>
This reverts commit da9973c6f9600d90e64aac647f3ed22dfd692f70,
and a couple of other remaining references to "git cvsserver".
When da9973c6f9600 was committed, we did not install git-cvsserver
in $(bindir) by default, but that situation did not last long (see
1df2a1ce806 "Install git-cvsserver in $(bindir)"). Also, a recent
commit (cvsserver: use dashless "git command"s to access plumbing)
fixed an issue with git-cvsserver trying to run dashed forms
without setting up the PATH for it.
The dashed form is arguably better in this case, since it is
required for cvs's ":fork:" connection method (although ":ext:"
usually doesn't need dashes), and it can minimize the need to escape
characters when setting up CVS_SERVER and/or CVSROOT.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Note: It might conceivably be worth holding off on this patch for a
release, in case someone tries to use a newer man page from the web with
an older install of git, where git-cvsserver still has the PATH bug
mentioned in the commit message above. But I doubt this is really
common enough to worry about.
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
Documentation/git-cvsserver.txt | 10 +++++-----
git-cvsserver.perl | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index e32ad7b..6f8cd88 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -11,7 +11,7 @@ SYNOPSIS
SSH:
[verse]
-export CVS_SERVER="git cvsserver"
+export CVS_SERVER=git-cvsserver
'cvs' -d :ext:user@server/path/repo.git co <HEAD_name>
pserver (/etc/inetd.conf):
@@ -22,7 +22,7 @@ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
Usage:
[verse]
-'git cvsserver' [options] [pserver|server] [<directory> ...]
+'git-cvsserver' [options] [pserver|server] [<directory> ...]
OPTIONS
-------
@@ -109,7 +109,7 @@ Note: Newer CVS versions (>= 1.12.11) also support specifying
CVS_SERVER directly in CVSROOT like
------
-cvs -d ":ext;CVS_SERVER=git cvsserver:user@server/path/repo.git" co <HEAD_name>
+cvs -d ":ext;CVS_SERVER=git-cvsserver:user@server/path/repo.git" co <HEAD_name>
------
This has the advantage that it will be saved in your 'CVS/Root' files and
you don't need to worry about always setting the correct environment
@@ -161,7 +161,7 @@ allowing access over SSH.
--
------
export CVSROOT=:ext:user@server:/var/git/project.git
- export CVS_SERVER="git cvsserver"
+ export CVS_SERVER=git-cvsserver
------
--
4. For SSH clients that will make commits, make sure their server-side
@@ -286,7 +286,7 @@ To get a checkout with the Eclipse CVS client:
Protocol notes: If you are using anonymous access via pserver, just select that.
Those using SSH access should choose the 'ext' protocol, and configure 'ext'
access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
-"'git cvsserver'". Note that password support is not good when using 'ext',
+'git-cvsserver'. Note that password support is not good when using 'ext',
you will definitely want to have SSH keys setup.
Alternatively, you can just use the non-standard extssh protocol that Eclipse
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 8e9e659..4b817ce 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -100,7 +100,7 @@ my $work =
$log->info("--------------- STARTING -----------------");
my $usage =
- "Usage: git cvsserver [options] [pserver|server] [<directory> ...]\n".
+ "Usage: git-cvsserver [options] [pserver|server] [<directory> ...]\n".
" --base-path <path> : Prepend to requested CVSROOT\n".
" --strict-paths : Don't allow recursing into subdirectories\n".
" --export-all : Don't check for gitcvs.enabled in config\n".
--
1.6.1.81.g9833d.dirty
^ permalink raw reply related
* [PATCH 07/10] t3409: use dashless "git commit" instead of "git-commit"
From: Matthew Ogilvie @ 2009-01-24 23:43 UTC (permalink / raw)
To: git; +Cc: Matthew Ogilvie
In-Reply-To: <1232840601-24696-7-git-send-email-mmogilvi_git@miniinfo.net>
This is needed to allow test suite to run against a minimal bin
directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Semi-related:
I noticed that there are actually two test cases numbered
t3409: t3409-rebase-hook.sh and t3409-rebase-preserve-merges.sh.
Should one of them be renumbered, or is it good enough as-is? I'm
just pointing this out; I don't intend to change it myself.
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
t/t3409-rebase-preserve-merges.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t3409-rebase-preserve-merges.sh b/t/t3409-rebase-preserve-merges.sh
index e6c8327..8878771 100755
--- a/t/t3409-rebase-preserve-merges.sh
+++ b/t/t3409-rebase-preserve-merges.sh
@@ -32,14 +32,14 @@ export GIT_AUTHOR_EMAIL
test_expect_success 'setup for merge-preserving rebase' \
'echo First > A &&
git add A &&
- git-commit -m "Add A1" &&
+ git commit -m "Add A1" &&
git checkout -b topic &&
echo Second > B &&
git add B &&
- git-commit -m "Add B1" &&
+ git commit -m "Add B1" &&
git checkout -f master &&
echo Third >> A &&
- git-commit -a -m "Modify A2" &&
+ git commit -a -m "Modify A2" &&
git clone ./. clone1 &&
cd clone1 &&
--
1.6.1.81.g9833d.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox