* Re: Cloning from kernel.org, then switching to another repo
From: Johannes Schindelin @ 2007-11-12 14:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711120557w62a9966bvb61a02a2bf9b99e9@mail.gmail.com>
Hi,
On Mon, 12 Nov 2007, Jon Smirl wrote:
> I'd like to do this sequence, but I can't figure out how without editing
> the config file. There doesn't seem to be a simple command to move the
> origin.
>
> git clone linus
> move origin to digispeaker.git
AKA "git config remote.origin.url <your-digispeaker-url-here>"
> git pull
Hth,
Dscho
^ permalink raw reply
* Re: git packs
From: bob @ 2007-11-12 14:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0711112307070.21255@xanadu.home>
On Nov 11, 2007, at 11:21 PM, Nicolas Pitre wrote:
> On Sun, 11 Nov 2007, bob wrote:
>
>> I applied the patch and these commands:
>>
>> cd rmwHtmlOld
>> rm -fr .git
>> git init
>> git config core.compression 0
>> git add .
>
> Note that I did "git config core.compression 0" simply to disable
> zlib compression altogether when creating the test repo just so it
> gets
> created faster. even then, auto-generating and cloning a 8GB test
> repository isn't particularly quick.
I wasn't sure why you used that, but figured that I should put it
in, because you did. And you are very correct that these tests
can take a very long time.
>
>> I then got the same error as before, "Bus error". Rats!
>
> Do you get that with a 32-bit or 64-bit build of Git?
On that machine, I changed the config.mak to generate nothing
but a 64-bit build. And activity monitor shows it as 64-bit
when I am running it. Also, off_t is 64 bit on regular
MacOSX and as a 64-bit program supported by the
latest MacOSX.
>
>> Then I modified your script since I do not have seq or
>> your test-genrandom.
>
> test-genrandom is built with Git. It is just not installed anywhere.
>
>> I substituted:
>>
>> dd count=XX if=/dev/random of=file_$i
>>
>> where XX is adjusted to meet dd's requirements. Also,
>
> Again I used test-genrandom instead of /dev/random or /dev/urandom
> simply because the former is much faster.
I didn't know that it existed, since I am not that familiar with the
internals and source directory for git.
>
>> I found after searching for a while, that the following
>> works just like your seq command:
>>
>> xyzzy="1 2 3 4"
>> for i in $xyzzy
>> do
>> ...
>> done
>>
>> Your script then ran flawlessly.
>
> However 'seq -w 1 2 63' should be replaced with "01 03 05 07 09 11 13
> 15" and so on up to 63, and 'seq -w 2 2 64' is "02 04 06 08 10 12 16"
> and so on.
That I missed but the files added up to quite a bit over 8gigs,
because my count calculation was off. So, I thought that it
was adequate for the testing. Based on above, it was
quite a few files less as well.
>
>> I looked through index-pack.c some more, but it is
>> very hard to figure it out without doing a lot of research
>> since there doesn't seem to be anything that describes
>> the layout of a pack. The link towards the end of the user's
>> manual doesn't work for me.
>
> Look at Documentation/technical/pack-format.txt in the Git source
> tree.
Thanks.
>
>> The difference between your test and my data is that
>> instead of having a few large files, I have 11,500 files
>> of varying sizes. On average though, the file size is
>> about 370k.
>
> Are you saying that the test repo with big files works for you but not
> your own data set?
That is correct, but you are probably correct that this is a separate
problem, because it is only occurring on the 64-bit side. The 32-bit
side is running without error.
>
> Would you please recap what your problem is?
With more testing last night, I believe that the problem on the 32-bit
side has been fixed. But the 'Bus error' on 64-bit side persists. I
agree that I was combining it and probably shouldn't have.
> With my one line patch you should not get the "serious inflate
> inconsistency" error anymore. The bus error must be another issue.
I no longer do on the 32-bit side.
>
>
> Nicolas
I am going to wait on the 64-bit problem until MacOSX 10.5 (Leopard)
settles down a bit. It has a few bugs in it. I will submit the
crashreporter
issue to Apple. Currently, I don't have the time to commit a lot to
git right
now.
As Apple comes out with new subreleases, I will retry my data.
If it doesn't get resolved after a subrelease or two, then I dig
deeper and
hopefully have more time to devote to it at that point.
Thank you, I do appreciate your help and your patience.
^ permalink raw reply
* Re: What is the idea for bare repositories?
From: David Tweed @ 2007-11-12 14:20 UTC (permalink / raw)
To: Bruno Cesar Ribas; +Cc: David Kastrup, git
In-Reply-To: <20071112131927.GA1701@c3sl.ufpr.br>
On Nov 12, 2007 1:19 PM, Bruno Cesar Ribas <ribas@c3sl.ufpr.br> wrote:
> A bare repository is the way to publish your changes to the public.
Just to mention this: an incredibly minor use, but a bare repository
is also useful for "temporary storage" on a non-case-preserving
filesystem (particularly if you don't have the authority/capability to
change the filesystem for one that is case preserving).
[I have a USB stick that I also occasionally use on Windows so
couldn't reformat. My repo doesn't have files whose names differ only
by case, but does have files with capitals somewhere. Not caring
either way about having checked out files, I initially tried to put a
standard repo on the stick and it wouldn't fast-forward when I tried
to push an update to it because some files checked out files had
"vanished". Making it a bare repository avoided the issue problem.]
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* [PATCH] status&commit: Teach them to show submodule commit summary
From: Ping Yin @ 2007-11-12 14:21 UTC (permalink / raw)
To: "git; +Cc: Ping Yin
In-Reply-To: <47382506.1090106@viscovery.net>
git status/commit just treats submodules as ordinary files when reporting status
changes. However, one may also wonder how submodules change (the commits).
This commit teaches git status/commit to additionally show commit summary of
user-cared (i.e. checked out) modified submodules since HEAD (or HEAD^ if
--amend option is on). For submodules deleted or initially added, commit summary
are not shown.
A configuration variable 'submodule.status' is used to turn this summary
behaviour on or off (default off). Also --submodule and --no-submodule options
are added.
By introducing this commit, git status will additionally give
'Submodules modified' section just before 'Untracked files' section as the
following example shows.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: sm1
# modified: sm2
# modified: sm3
# deleted: sm4
#
# Submodules modifiled: sm1 sm2 sm3
#
# * sm1 354cd45...3f751e5:
# <one line message for C
# <one line message for B
# >one line message for D
# >one line message for E
#
# * sm2 5c8bfb5...ac46d84:
# <msg
#
# * sm3 354cd45...3f751e5:
# Warn: sm3 doesn't contains commit 354cd45
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# file1
This superproject shown has modified/deleted submodules sm1 to sm4.
sm1 has commit C in HEAD and commit E in index. The history of sm1 is
--A-->B-->C (in HEAD:354cd45)
\
-->D-->E (in index:3f751e5)
The 'Submodules modified' section for sm1 shows how to change sm1 from commit C
(in HEAD) to commit E (in index): backward (<) to commit A first, and then
forward (>) to commit E.
Similar illustration for output of sm2 is omitted.
If the commit recorded in HEAD/index for a submodule is not found in the work
tree (say the submodule respository in the work tree), a warning will be issued.
Submodule sm3 falls into this case.
Commits of sm4 are not shown since it's a deleted submodule.
Signed-off-by: Ping Yin <pkufranky@gmail.com>
---
Documentation/git-commit.txt | 10 +++++
Documentation/git-status.txt | 3 +
git-commit.sh | 90 ++++++++++++++++++++++++++++++++++++++++--
3 files changed, 99 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index e54fb12..0680a57 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -139,6 +139,13 @@ but can be used to amend a merge commit.
-q|--quiet::
Suppress commit summary message.
+--submodule|--no-submodule
+ Show/Don't show commit summary for user-cared (i.e. checked out)
+ modified submodules. Summaries for submodules deleted or initial
+ added are not shown. The bool configuration variable
+ 'submodule.status' is used to control the default behaviour
+ (don't show by default).
+
\--::
Do not interpret any more arguments as options.
@@ -259,6 +266,9 @@ GIT_EDITOR environment variable, the core.editor configuration variable, the
VISUAL environment variable, or the EDITOR environment variable (in that
order).
+The bool configuration variable 'submodule.status' is also honored to
+enable/disable the submodule summary behaviour (see option --submodule).
+
HOOKS
-----
This command can run `commit-msg`, `pre-commit`, and
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 8fd0fc6..7afe6a0 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -49,6 +49,9 @@ mean the same thing and the latter is kept for backward
compatibility) and `color.status.<slot>` configuration variables
to colorize its output.
+The bool configuration variable 'submodule.status' is also honored
+to enable/disable the submodule summary behaviour (see option --submodule).
+
See Also
--------
gitlink:gitignore[5]
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..813eb4e 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -33,6 +33,65 @@ save_index () {
cp -p "$THIS_INDEX" "$NEXT_INDEX"
}
+# Show log of modified submodule (index modification since HEAD or $1)
+# $1 is the commit to be compared, default 'HEAD'
+show_module_log () {
+ cwd=$(pwd)
+ cd_to_toplevel
+
+ # get modified modules which have been checked out (i.e. cared by user)
+ modules=$(git diff --cached --name-only $1 |
+ (
+ IFS='' # handle the module name containing space or tab
+ while read name
+ do
+ git ls-files --stage "$name" | grep '^160000 ' >&/dev/null &&
+ GIT_DIR="$name/.git" git-rev-parse --git-dir >&/dev/null &&
+ echo "$name"
+ done
+ )
+ )
+
+ # TODO: quote module names containing space or tab
+ test -n "$modules" && echo -e "# Submodules modifiled: "$modules"\n#"
+ OLDIFS=$IFS
+ IFS=$'\n\r' # '\r' for mac os
+ for name in $modules
+ do
+ range=$(git diff --cached -- "$name" | sed -n '/^index.*160000$/ p' | awk '{print $2}')
+ indexone=${range#*..}
+ headone=${range%..*}
+ (
+ echo "* $name $headone...$indexone:"
+ headfail=
+ indexfail=
+ GIT_DIR="$name/.git" git-rev-parse $headone >&/dev/null || headfail='t'
+ GIT_DIR="$name/.git" git-rev-parse $indexone >&/dev/null || indexfail='t'
+ case "$headfail,$indexfail" in
+ t,)
+ echo " Warn: $name doesn't contains commit $headone"
+ ;;
+ ,t)
+ echo " Warn: $name doesn't contains commit $indexone"
+ ;;
+ t,t)
+ echo " Warn: $name doesn't contains commits $headone and $indexone"
+ ;;
+ *)
+ left=$(GIT_DIR="$name/.git" git log --pretty=format:" <%s" $indexone..$headone 2>&1)
+ right=$(GIT_DIR="$name/.git" git log --reverse --pretty=format:" >%s" $headone..$indexone 2>&1) &&
+ test -n "$left" && echo "$left"
+ test -n "$right" && echo "$right"
+ ;;
+ esac
+ echo
+ ) | sed 's/^/# /'
+ done
+ IFS=$OLDIFS
+
+ cd "$cwd"
+}
+
run_status () {
# If TMP_INDEX is defined, that means we are doing
# "--only" partial commit, and that index file is used
@@ -55,10 +114,25 @@ run_status () {
else
color=--nocolor
fi
- git runstatus ${color} \
- ${verbose:+--verbose} \
- ${amend:+--amend} \
- ${untracked_files:+--untracked}
+ if test -n "$showsubmodule"
+ then
+ git runstatus ${color} \
+ ${verbose:+--verbose} \
+ ${amend:+--amend} \
+ ${untracked_files:+--untracked} |
+ awk -v modulelog="$(show_module_log ${amend:+HEAD^})" '
+ /^# Untracked files:/ {shown=1; if (modulelog) print modulelog}
+ {print}
+ END {
+ if (!shown && modulelog) print modulelog
+ }
+ '
+ else
+ git runstatus ${color} \
+ ${verbose:+--verbose} \
+ ${amend:+--amend} \
+ ${untracked_files:+--untracked}
+ fi
}
trap '
@@ -90,6 +164,8 @@ force_author=
only_include_assumed=
untracked_files=
templatefile="`git config commit.template`"
+showsubmodule=$(git config --bool submodule.status 2>/dev/null)
+test "$showsubmodule" == "true" || showsubmodule=""
while test $# != 0
do
case "$1" in
@@ -230,6 +306,12 @@ do
--untracked-file|--untracked-files)
untracked_files=t
;;
+ --su|--sub|--subm|--submo|--submod|--submodu|--submodul|--submodule)
+ showsubmodule=t
+ ;;
+ --no-su|--no-sub|--no-subm|--no-submo|--no-submod|--no-submodu|--no-submodul|--no-submodule)
+ showsubmodule=
+ ;;
--)
shift
break
--
1.5.3.4
^ permalink raw reply related
* BUG: git-svn does not escape literal backslashes in author names.
From: Adrian Wilkins @ 2007-11-12 14:28 UTC (permalink / raw)
To: git
Recently converted a large (11,000+ revisions) repository.
We authenticate against the NT domain controller, so all our revision
authors are of the form "domain\user". (You can switch off mod_sspi
reporting the domain part, but I didn't know about this at the time,
so it continues for historical reasons.)
git-svn treats the literal backslashes in the author names as escapes.
This leads to authors like
domainkevin
domain\
ichard
I know, I should have read the manual and used my "authors" file. Bah.
I'm sure that part of the revision hash in git includes the author
name... so I guess I'm looking at another multi-day conversion. :-(
Can I suggest that you make the authors file compulsory by default as well?
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Steffen Prohaska @ 2007-11-12 14:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711121203150.4362@racer.site>
On Nov 12, 2007, at 1:21 PM, Johannes Schindelin wrote:
>> * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
>> - refactor fetch's ref matching to use refname_match()
>> - push: use same rules as git-rev-parse to resolve refspecs
>> - add refname_match()
>> - push: support pushing HEAD to real branch name
>>
>> This changes the semantics slightly but I think it is a move in
>> the right direction.
>
> We could add a "--matching" option and output a warning when it is not
> passed. I would like this pretty soon, and would not be sad if it
> went
> into 'next' before this topic.
Is this the road towards
1) "git push --matching" push matching branches.
2) "git push --current" push only current branch.
3) "git push" report error if the config does not contain a Push line.
(after it reported a warning for a while).
I'd like to see this too. Unfortunately it's unlikely that I'll start
working on it before next weekend.
"--matching" would be a no-op at this time. Only a warning would be
printed
if it is missing. Right?
Steffen
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show submodule commit summary
From: Ralf Wildenhues @ 2007-11-12 14:46 UTC (permalink / raw)
To: Ping Yin; +Cc: git
In-Reply-To: <1194877277-31777-1-git-send-email-pkufranky@gmail.com>
Hello,
A couple of portability nits:
* Ping Yin wrote on Mon, Nov 12, 2007 at 03:21:17PM CET:
[...]
> +
> + # TODO: quote module names containing space or tab
> + test -n "$modules" && echo -e "# Submodules modifiled: "$modules"\n#"
Typo: s/modifiled/modified/
Then, "echo -e" is not portable (and not used elsewhere in git), but you
can just use this instead:
test ... && { echo "# ..."; echo "#"; }
Also, it so happens you leave $modules outside quotes which will drop
multiple adjacent white spaces. Did you mean to use
echo "# Submodules modified: \"$modules\""
?
> + OLDIFS=$IFS
> + IFS=$'\n\r' # '\r' for mac os
$' is not portable (and not POSIX either). For example pdksh, OpenBSD
/bin/sh (which are both similar) will add "$" to the list of sepators
here, compare this:
$ foo=$'\n'; echo ".$foo."
.$
.
And at least some ash/dash versions will not interpret this as a newline
at all:
.$\n.
You can instead just use a literal newline:
IFS='
'
(minus the indentation). And add a literal carriage return if need be
(is that really needed on Mac OS?), though you may want to enclose that
in another pair of quotes to avoid it being "optimized" away by some
editor.
Cheers,
Ralf
^ permalink raw reply
* Re: [PATCH] Make builtin-tag.c use parse_options.
From: Pierre Habouzit @ 2007-11-12 14:52 UTC (permalink / raw)
To: Carlos Rica; +Cc: Junio C Hamano, git, Kristian Høgsberg
In-Reply-To: <1b46aba20711120509l104792ebo4ea9a51c710510f3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]
On Mon, Nov 12, 2007 at 01:09:37PM +0000, Carlos Rica wrote:
> 2007/11/10, Junio C Hamano <gitster@pobox.com>:
> > Carlos Rica <jasampler@gmail.com> writes:
> >
> > > Also, this removes those tests ensuring that repeated
> > > -m options don't allocate memory more than once, because now
> > > this is done after parsing options, using the last one
> > > when more are given. The same for -F.
> >
> > The reason for this change is...? Is this because it is
> > cumbersome to detect and refuse multiple -m options using the
> > parseopt API? If so, the API may be what needs to be fixed.
> > Taking the last one and discarding earlier ones feels to me an
> > arbitrary choice.
>
> You can do many things with repeated options.
> Here in git-tag we considered two different ways to manage them:
> Concatenating values for the option and/or refusing more than one.
> I found that current option-parser can do both from the client
> using callbacks, as Pierre shows me, so I think it is the right way to do it.
>
> Pierre, by default, I think that the parser should print an error
> when more than one option of the same type is given,
I beg to differ. It makes sense for OPTION_STRING options, but not for
other. Though you cannot always detect that.
Also note that:
(1) repeating options was already silent in many git commands, so it's
not really a regression ;
(2) for many commands it actually make sense to allow repeating (for
_BOOLEAN e.g.). And I'd argue that for OPTION_BIT it also makes
sense as well.
> in order to report it to the command-line user, but make this
> behaviour optional for the programmer. Specifically, I thought in
> this last option:
>
> enum parse_opt_option_flags {
> PARSE_OPT_OPTARG = 1,
> PARSE_OPT_NOARG = 2,
> PARSE_OPT_ALLOWREP = 4
> };
To do that you need to keep a list of the triggered commands to do
that, there is no way to achieve that reliably right now. As taking the
last one and discarding the other is the usual way for option parsers I
never saw this as a big issue.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Pierre Habouzit @ 2007-11-12 14:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711121232370.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
On Mon, Nov 12, 2007 at 12:33:19PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 12 Nov 2007, Pierre Habouzit wrote:
>
> > On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin wrote:
> >
> > > On Sun, 11 Nov 2007, Junio C Hamano wrote:
> > >
> > > > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
> > > > + rebase: operate on a detached HEAD
> > >
> > > Note: this might have a subtle bug when the last patch in the series
> > > failed. If I was not too tired this morning (which might well have
> > > been the case), rebase could not switch back to the branch correctly
> > > with this.
> >
> > OOOH so this was what happened to me today then. I did a rebase, there
> > was a commit to skip, the last one, and I ended up on a detached head.
> > As I didn't had my coffee yet, I assumed this was my fault and did
> > something stupid. So after all it seems it wasn't the case then :)
>
> Thanks for acknowleding, and sorry for the bug.
well, shit happens, I'm running next especially to spot those :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-12 15:02 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <087FCF8E-74BF-42EA-B7E2-4622DD0F5F9B@zib.de>
Hi,
On Mon, 12 Nov 2007, Steffen Prohaska wrote:
> On Nov 12, 2007, at 1:21 PM, Johannes Schindelin wrote:
>
> > > * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
> > > - refactor fetch's ref matching to use refname_match()
> > > - push: use same rules as git-rev-parse to resolve refspecs
> > > - add refname_match()
> > > - push: support pushing HEAD to real branch name
> > >
> > > This changes the semantics slightly but I think it is a move in
> > > the right direction.
> >
> > We could add a "--matching" option and output a warning when it is not
> > passed. I would like this pretty soon, and would not be sad if it went
> > into 'next' before this topic.
>
> Is this the road towards
> 1) "git push --matching" push matching branches.
> 2) "git push --current" push only current branch.
> 3) "git push" report error if the config does not contain a Push line.
> (after it reported a warning for a while).
AFAIAC yes. Maybe in two years (that's twice an eternity in git time
scales):
4) make "git push --current" the default.
> I'd like to see this too. Unfortunately it's unlikely that I'll start
> working on it before next weekend.
>
> "--matching" would be a no-op at this time. Only a warning would be printed
> if it is missing. Right?
Right.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-commit: Add tests for invalid usage of -a/--interactive with paths
From: Björn Steinbrink @ 2007-11-12 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsso3poo.fsf@gitster.siamese.dyndns.org>
git-commit was/is broken in that it accepts paths together with -a or
--interactive, which it shouldn't. There tests check those usage errors.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
> [Stalled]
>
> * bs/maint-commit-options (Mon Nov 5 20:36:33 2007 +0100) 1 commit
> - git-commit.sh: Fix usage checks regarding paths given when they do
> not make sense
>
> This is meant to go to 'maint' but needs test script to exhibit
> the existing breakage and demonstrate the fix.
>
> The test will help catching future regression even after we
> replace git-commit with Kristian's rewrite in C.
Sorry, didn't take your comment to that patch as a request to provide
tests. Anyway, here they are :-) I hope I got the commit message/comment
formatting right this time.
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 4dc35bd..9dba104 100644
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -34,6 +34,16 @@ test_expect_failure \
"git-commit -C HEAD -m illegal"
test_expect_failure \
+ "using paths with -a" \
+ "echo King of the bongo >file &&
+ git-commit -m foo -a file"
+
+test_expect_failure \
+ "using paths with --interactive" \
+ "echo bong-o-bong >file &&
+ echo 7 | git-commit -m foo --interactive file"
+
+test_expect_failure \
"using invalid commit with -C" \
"git-commit -C bogus"
^ permalink raw reply related
* Re: [PATCH] status&commit: Teach them to show submodule commit summary
From: Ping Yin @ 2007-11-12 15:17 UTC (permalink / raw)
To: Ralf Wildenhues, Ping Yin, git
In-Reply-To: <20071112144605.GA16791@ins.uni-bonn.de>
On Nov 12, 2007 10:46 PM, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> Hello,
>
> A couple of portability nits:
>
> * Ping Yin wrote on Mon, Nov 12, 2007 at 03:21:17PM CET:
> [...]
> > +
> > + # TODO: quote module names containing space or tab
> > + test -n "$modules" && echo -e "# Submodules modifiled: "$modules"\n#"
>
> Typo: s/modifiled/modified/
Oops
>
> Then, "echo -e" is not portable (and not used elsewhere in git), but you
> can just use this instead:
> test ... && { echo "# ..."; echo "#"; }
See
>
> Also, it so happens you leave $modules outside quotes which will drop
> multiple adjacent white spaces. Did you mean to use
> echo "# Submodules modified: \"$modules\""
I leave $modules outside quotes to let "\n" change to <space> by auto
word splitting.
It actually eats white spaces in the module names. So any suggestion
to handle this case?
To handles module names with spaces, is it ok to display as follows?
Submodules modified: sm1 "sm name with space"
Any good way to only add quoting for names with spaces?
> You can instead just use a literal newline:
> IFS='
> '
> (minus the indentation). And add a literal carriage return if need be
> (is that really needed on Mac OS?), though you may want to enclose that
> in another pair of quotes to avoid it being "optimized" away by some
> editor.
I just guess '\r' is need for Mac OS because i havn't Mac OS environment.
BTW, how to add a literal carriage return?
>
> Cheers,
> Ralf
>
--
Ping Yin
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Theodore Tso @ 2007-11-12 15:20 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4738292E.2020103@op5.se>
On Mon, Nov 12, 2007 at 11:21:34AM +0100, Andreas Ericsson wrote:
>
> git format-patch could probably go in, but skip the others. I've never
> used git cherry in my entire life and it's not, strictly speaking,
> necessary for users to have it. There are other and easier ways to
> find the same information.
How useful it is depends on the project, definitely. The Linux kernel
doesn't have the "what's cooking" emails, and is very fast-moving, so
a day after you submit your patch set via e-mail, and then you do a
pull, and several hundred commits come spilling down from upstream,
git-cherry is incredibly useful to see what was accepted and what
wasn't. :-)
> I'd keep cherry-pick though. It's incredibly useful, and especially
> when a commit ends up on the wrong branch which is something newbies
> are likely to do when they start trying out the topic-branch workflow.
> I still do it sometimes, but hardly ever stop thinking about it since
> it's so easy to fix thanks to cherry-pick.
How often cherry-pick is useful is probably also very project
specific, and depends on how branchy a project happens to be, and how
aggressively patches get merged into the master development line. For
a project that is extremely linear, with few branches, cherry-pick is
less useful; I didn't have any occasion to use it for quite a while,
and certainly not while I was a git beginner.
- Ted
^ permalink raw reply
* Re: [PATCH] tests: git push mirror mode tests V2
From: Andy Whitcroft @ 2007-11-12 15:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl3frxpk.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 09, 2007 at 12:05:43PM -0800, Junio C Hamano wrote:
> Andy Whitcroft <apw@shadowen.org> writes:
>
> > +test_expect_success 'push mirror does not create new branches' '
> > +
> > + mk_repo_pair &&
> > + (
> > + cd master &&
> > + echo one >foo && git add foo && git commit -m one &&
> > + git push --mirror up
> > + ) &&
> > + master_master=$(cd master && git show-ref -s --verify refs/heads/master) &&
> > + mirror_master=$(cd mirror && git show-ref -s --verify refs/heads/master) &&
> > + test "$master_master" = "$mirror_master"
> > +
> > +'
>
> I am quite puzzled by this and many other "does not" in the test
> description. The --mirror option is advertised as
>
> - newly created will be pushed;
> - locally updated will be force pushed;
> - locally deleted will be removed.
>
> which makes sense as we do want these things to happen for
> "mirrors". Indeed the above updates master branch at the master
> repository and makes sure that change is propagated to the
> mirror repository. The description should read "push mirror
> creates new branches" shouldn't it?
Indeed, I think the problem was a miss-understanding of the example I
copied from. I think partly I thought that the message was only
displayed on failure. Which is firstly demonstrably false, and secondly
I am not consistent in applying that false knowledge.
If these are not already fixed up in pu I will check and sort them out.
-apw
^ permalink raw reply
* git config error message
From: Jon Smirl @ 2007-11-12 15:35 UTC (permalink / raw)
To: Git Mailing List
I'm not in a git repo, this error message is misleading.
jonsmirl@terra:~/foo$ git config remote.origin.url
http://git.digispeaker.com/projects/digispeaker-kernel.git
could not lock config file
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jon Smirl @ 2007-11-12 15:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711121412410.4362@racer.site>
On 11/12/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 12 Nov 2007, Jon Smirl wrote:
>
> > I'd like to do this sequence, but I can't figure out how without editing
> > the config file. There doesn't seem to be a simple command to move the
> > origin.
> >
> > git clone linus
> > move origin to digispeaker.git
>
> AKA "git config remote.origin.url <your-digispeaker-url-here>"
There is more to this:
jonsmirl@terra:~/foo$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
ds
clone.....
jonsmirl@terra:~/foo/ds$ git config remote.origin.url
http://git.digispeaker.com/projects/digispeaker-kernel.git
jonsmirl@terra:~/foo/ds$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.master.remote = <nickname>
branch.master.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
jonsmirl@terra:~/foo/ds$
>
> > git pull
>
> Hth,
> Dscho
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Include diff options in the git-log manpage
From: Miklos Vajna @ 2007-11-12 15:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1193929060-6183-2-git-send-email-vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On Thu, Nov 01, 2007 at 03:57:40PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> Recently I wanted to see what git log -M does but actually I was not able to
> find it in the manpage, finally figured out that all the diff options are
> missing from here.
>
> Removing -p as it's already in diff-options.txt.
>
> If this patch OK, then I would like to send a similar patch to
> git-rev-list.txt, too.
>
> Documentation/git-log.txt | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
could somebody please comment this patch? does it look ok?
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show submodule commit summary
From: Jakub Narebski @ 2007-11-12 15:37 UTC (permalink / raw)
To: git
In-Reply-To: <1194877277-31777-1-git-send-email-pkufranky@gmail.com>
Ping Yin wrote:
> ---
> Documentation/git-commit.txt | 10 +++++
> Documentation/git-status.txt | 3 +
> git-commit.sh | 90 ++++++++++++++++++++++++++++++++++++++++--
> 3 files changed, 99 insertions(+), 4 deletions(-)
Shouldn't you also modify Documentation/config.txt ?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS
From: Bill Lear @ 2007-11-12 15:39 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071109232106.GA3435@steel.home>
On Saturday, November 10, 2007 at 00:21:06 (+0100) Alex Riesen writes:
>Bill Lear, Fri, Nov 09, 2007 16:31:39 +0100:
>> I've brought this up before, but I don't recall a resolution to it.
>>
>> We have an NFS-mounted filesystem, and git pull is choking on it.
>>
>> % uname -a
>> Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux
>>
>> % git --version
>> git version 1.5.3.5
>>
>> % git pull
>> remote: Generating pack...
>> remote: Done counting 998 objects.
>> remote: Result has 836 objects.
>> remote: Deltifying 836 objects.
>> remote: 100% (836/836) done
>> Indexing 836 objects...
>> remote: Total 836 (delta 526), reused 688 (delta 380)
>> 100% (836/836) done
>> Resolving 526 deltas...
>> fatal: cannot pread pack file: No such file or directory
>
>Could you please strace it? With strace -ff?
>
>> fatal: index-pack died with error code 128
>> fatal: Fetch failure: git://source/repo
>>
>> I looked through the archives of this list and did not see a final
>> resolution, other than a suspected bug in the OS NFS code.
>
>Strace, just to be on the safe side
Ok, I've done the strace -ff. It has generated 176 strace.out.<pid>
files. I have placed a tarball of these files on my home server:
http://www.zopyra.com/~rael/git/git-trace.tar.bz2
The file strace.out.25526 has, at the very end:
[...]
open("/etc/mtab", O_RDONLY) = 4
fstat64(0x4, 0xffff6810) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0x1000) = 0xfffffffff7ffd000
read(4, "/dev/sda1 / ext3 rw 0 0\nnone /pr"..., 4096) = 503
close(4) = 0
munmap(0xf7ffd000, 4096) = 0
open("/proc/meminfo", O_RDONLY) = 4
fstat64(0x4, 0xffff6c7c) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0x1000) = 0xfffffffff7ffd000
read(4, "MemTotal: 16396892 kB\nMemFre"..., 1024) = 672
close(4) = 0
munmap(0xf7ffd000, 4096) = 0
write(2, "Resolving 551 deltas.\n", 22) = 22
pread64(3, "", 242, 541) = 0
write(2, "fatal: ", 7) = 7
write(2, "cannot pread pack file: Success", 31) = 31
write(2, "\n", 1) = 1
exit_group(128) = ?
Here is the clipped output of running the strace command:
[...]
[ Process PID=25347 runs in 32 bit mode. ]
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
[ Process PID=25347 runs in 64 bit mode. ]
[ Process PID=25349 runs in 32 bit mode. ]
[...]
[ Process PID=25366 runs in 64 bit mode. ]
[ Process PID=25365 runs in 32 bit mode. ]
ptrace: umoven: Input/output error
[ Process PID=25366 runs in 64 bit mode. ]
[ Process PID=25365 runs in 32 bit mode. ]
[...]
[ Process PID=25365 runs in 32 bit mode. ]
[ Process PID=25366 runs in 64 bit mode. ]
ptrace: umoven: Input/output error
[ Process PID=25365 runs in 32 bit mode. ]
[ Process PID=25366 runs in 64 bit mode. ]
[...]
[ Process PID=25385 runs in 32 bit mode. ]
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
[...]
[ Process PID=25385 runs in 64 bit mode. ]
[ Process PID=25482 runs in 32 bit mode. ]
[ Process PID=25396 runs in 64 bit mode. ]
[ Process PID=25524 runs in 32 bit mode. ]
remote: Generating pack...
remote: Done counting 1052 objects.
remote: Result has 882 objects.
remote: Deltifying 882 objects.
100% (882/882) done82) done
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
umovestr: Input/output error
Indexing 882 objects.
100% (882/882) done
Resolving 551 deltas.
remote: Total 882 (delta 551), reused 716 (delta 387)
fatal: cannot pread pack file: Success
fatal: index-pack died with error code 128
[ Process PID=25522 runs in 64 bit mode. ]
Fetch failure: git://source/fusion
Bill
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show submodule commit summary
From: Ping Yin @ 2007-11-12 15:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fh9rv5$g06$1@ger.gmane.org>
On Nov 12, 2007 11:37 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Ping Yin wrote:
>
> > ---
> > Documentation/git-commit.txt | 10 +++++
> > Documentation/git-status.txt | 3 +
> > git-commit.sh | 90 ++++++++++++++++++++++++++++++++++++++++--
> > 3 files changed, 99 insertions(+), 4 deletions(-)
>
> Shouldn't you also modify Documentation/config.txt ?
Oh, I'll supplement later
>
> --
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ping Yin
^ permalink raw reply
* [PATCH] push mirroring update test titles
From: Andy Whitcroft @ 2007-11-12 15:48 UTC (permalink / raw)
To: git, Junio C Hamano
Fix up the test titles which are incorrectly in the negative.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
This probabally should be folded down into the
current tests patch. If you want me to do that
and resubmit, yell at me.
t/t5517-push-mirror.sh | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh
index 0fc6778..ed3fec1 100755
--- a/t/t5517-push-mirror.sh
+++ b/t/t5517-push-mirror.sh
@@ -31,7 +31,7 @@ mk_repo_pair () {
# BRANCH tests
-test_expect_success 'push mirror does not create new branches' '
+test_expect_success 'push mirror creates new branches' '
mk_repo_pair &&
(
@@ -45,7 +45,7 @@ test_expect_success 'push mirror does not create new branches' '
'
-test_expect_success 'push mirror does not update existing branches' '
+test_expect_success 'push mirror updates existing branches' '
mk_repo_pair &&
(
@@ -61,7 +61,7 @@ test_expect_success 'push mirror does not update existing branches' '
'
-test_expect_success 'push mirror does not force update existing branches' '
+test_expect_success 'push mirror force updates existing branches' '
mk_repo_pair &&
(
@@ -79,7 +79,7 @@ test_expect_success 'push mirror does not force update existing branches' '
'
-test_expect_success 'push mirror does not remove branches' '
+test_expect_success 'push mirror removes branches' '
mk_repo_pair &&
(
@@ -97,7 +97,7 @@ test_expect_success 'push mirror does not remove branches' '
'
-test_expect_success 'push mirror does not add, update and remove branches together' '
+test_expect_success 'push mirror adds, updates and removes branches together' '
mk_repo_pair &&
(
@@ -125,7 +125,7 @@ test_expect_success 'push mirror does not add, update and remove branches togeth
# TAG tests
-test_expect_success 'push mirror does not create new tags' '
+test_expect_success 'push mirror creates new tags' '
mk_repo_pair &&
(
@@ -140,7 +140,7 @@ test_expect_success 'push mirror does not create new tags' '
'
-test_expect_success 'push mirror does not update existing tags' '
+test_expect_success 'push mirror updates existing tags' '
mk_repo_pair &&
(
@@ -158,7 +158,7 @@ test_expect_success 'push mirror does not update existing tags' '
'
-test_expect_success 'push mirror does not force update existing tags' '
+test_expect_success 'push mirror force updates existing tags' '
mk_repo_pair &&
(
@@ -179,7 +179,7 @@ test_expect_success 'push mirror does not force update existing tags' '
'
-test_expect_success 'push mirror does not remove tags' '
+test_expect_success 'push mirror removes tags' '
mk_repo_pair &&
(
@@ -197,7 +197,7 @@ test_expect_success 'push mirror does not remove tags' '
'
-test_expect_success 'push mirror does not add, update and remove tags together' '
+test_expect_success 'push mirror adds, updates and removes tags together' '
mk_repo_pair &&
(
^ permalink raw reply related
* Re: [PATCH] status&commit: Teach them to show submodule commit summary
From: Johannes Sixt @ 2007-11-12 15:59 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <1194877277-31777-1-git-send-email-pkufranky@gmail.com>
Ping Yin schrieb:
> git status/commit just treats submodules as ordinary files when reporting status
> changes. However, one may also wonder how submodules change (the commits).
>
> This commit teaches git status/commit to additionally show commit summary of
> user-cared (i.e. checked out) modified submodules since HEAD (or HEAD^ if
> --amend option is on). For submodules deleted or initially added, commit summary
> are not shown.
In general, I like the idea (as I've already pointed out).
But at this time git-commit is about to be made a builtin, and since your
implementation contains a lot of non-portable constructs ($'', >&) and a new
dependency on awk (and, hence, has little chances of being accepted), I
suggest that you stay tuned, and implement this in the forth-coming
builtin-commit.c.
> A configuration variable 'submodule.status' is used to turn this summary
> behaviour on or off (default off). Also --submodule and --no-submodule options
> are added.
There is already 'status.color', I suggest the configuration to become
'status.submoduleSummary'.
-- Hannes
^ permalink raw reply
* [PATCH] git-send-email: show all headers when sending mail
From: David D. Kilzer @ 2007-11-12 16:01 UTC (permalink / raw)
To: gitster; +Cc: git, David D. Kilzer
As a git newbie, it was confusing to set an In-Reply-To header but then
not see it printed when the git-send-email command was run.
This patch prints all headers that would be sent to sendmail or an SMTP
server instead of only printing From, Subject, Cc, To. It also removes
the now-extraneous Date header after the "Log says" line.
Added test to t/t9001-send-email.sh.
Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net>
---
I'd like to see this applied to the maint branch.
git-send-email.perl | 4 ++--
t/t9001-send-email.sh | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 8760cf8..e3ea786 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -573,7 +573,7 @@ X-Mailer: git-send-email $gitversion
if ($quiet) {
printf (($dry_run ? "Dry-" : "")."Sent %s\n", $subject);
} else {
- print (($dry_run ? "Dry-" : "")."OK. Log says:\nDate: $date\n");
+ print (($dry_run ? "Dry-" : "")."OK. Log says:\n");
if ($smtp_server !~ m#^/#) {
print "Server: $smtp_server\n";
print "MAIL FROM:<$raw_from>\n";
@@ -581,7 +581,7 @@ X-Mailer: git-send-email $gitversion
} else {
print "Sendmail: $smtp_server ".join(' ',@sendmail_parameters)."\n";
}
- print "From: $sanitized_sender\nSubject: $subject\nCc: $cc\nTo: $to\n\n";
+ print $header, "\n";
if ($smtp) {
print "Result: ", $smtp->code, ' ',
($smtp->message =~ /\n([^\n]+\n)$/s), "\n";
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 83f9470..fc03e40 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -41,4 +41,42 @@ test_expect_success \
'Verify commandline' \
'diff commandline expected'
+cat >expected-show-all-headers <<\EOF
+0001-Second.patch
+(mbox) Adding cc: A <author@example.com> from line 'From: A <author@example.com>'
+Dry-OK. Log says:
+Server: relay.example.com
+MAIL FROM:<from@example.com>
+RCPT TO:<to@example.com>,<cc@example.com>,<author@example.com>,<bcc@example.com>
+From: Example <from@example.com>
+To: to@example.com
+Cc: cc@example.com, A <author@example.com>
+Subject: [PATCH 1/1] Second.
+Date: Mon, 12 Nov 2007 15:01:19 +0000
+Message-Id: <1194879679-15720-1-git-send-email-from@example.com>
+X-Mailer: git-send-email 1.5.3.5.38.gb33cf-dirty
+In-Reply-To: <unique-message-id@example.com>
+References: <unique-message-id@example.com>
+
+Result: OK
+EOF
+
+replace_header () {
+ EXPECTED=expected-show-all-headers &&
+ ACTUAL=actual-show-all-headers &&
+ REPLACEMENT=`cat ${ACTUAL} | grep "^$1:"` &&
+ if [ ! -z "${REPLACEMENT}" ]; then \
+ cat ${EXPECTED} | sed -e "s/^$1: .*\$/${REPLACEMENT}/" > ${EXPECTED}.$$ && \
+ mv -f ${EXPECTED}.$$ ${EXPECTED}
+ fi
+}
+
+test_expect_success 'Show all headers' '
+ git send-email --dry-run --from="Example <from@example.com>" --to=to@example.com --cc=cc@example.com --bcc=bcc@example.com --in-reply-to="<unique-message-id@example.com>" --smtp-server relay.example.com $patches > actual-show-all-headers &&
+ replace_header "Date" &&
+ replace_header "Message-Id" &&
+ replace_header "X-Mailer" &&
+ diff -u expected-show-all-headers actual-show-all-headers
+'
+
test_done
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] status&commit: Teach them to show submodule commit summary
From: Jakub Narebski @ 2007-11-12 16:12 UTC (permalink / raw)
To: git
In-Reply-To: <4738784F.7010106@viscovery.net>
Johannes Sixt wrote:
>> A configuration variable 'submodule.status' is used to turn this summary
>> behaviour on or off (default off). Also --submodule and --no-submodule options
>> are added.
>
> There is already 'status.color', I suggest the configuration to become
> 'status.submoduleSummary'.
Or status.submodule.summary, although we usually use
section.<variable_sub>.key configuration variables,
e.g. branch.<name>.remote. But we have exception:
color.branch.<slot>
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show submodule commit summary
From: Johannes Schindelin @ 2007-11-12 16:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Ping Yin, Git Mailing List
In-Reply-To: <4738784F.7010106@viscovery.net>
Hi,
On Mon, 12 Nov 2007, Johannes Sixt wrote:
> Ping Yin schrieb:
> > git status/commit just treats submodules as ordinary files when
> > reporting status changes. However, one may also wonder how submodules
> > change (the commits).
> >
> > This commit teaches git status/commit to additionally show commit
> > summary of user-cared (i.e. checked out) modified submodules since
> > HEAD (or HEAD^ if --amend option is on). For submodules deleted or
> > initially added, commit summary are not shown.
>
> In general, I like the idea (as I've already pointed out).
>
> But at this time git-commit is about to be made a builtin, and since
> your implementation contains a lot of non-portable constructs ($'', >&)
> and a new dependency on awk (and, hence, has little chances of being
> accepted), I suggest that you stay tuned, and implement this in the
> forth-coming builtin-commit.c.
I agree.
> > A configuration variable 'submodule.status' is used to turn this
> > summary behaviour on or off (default off). Also --submodule and
> > --no-submodule options are added.
>
> There is already 'status.color', I suggest the configuration to become
> 'status.submoduleSummary'.
You could make this variable even a numeric one. Saying how many lines
you want to have maximally (-1 meaning unlimited).
Ciao,
Dscho
^ 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