* Re: [RFC PATCH] builtin-blame: Reencode commit messages according to git-log rules.
From: Junio C Hamano @ 2008-10-21 7:34 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <1224537879-13000-1-git-send-email-angavrilov@gmail.com>
I think this makes sense. We'd want a testcase for the new feature before
applying the patch, though.
^ permalink raw reply
* Re: Archiving tags/branches?
From: Jakub Narebski @ 2008-10-21 8:15 UTC (permalink / raw)
To: Pete Harlan; +Cc: Johan Herland, git, SZEDER Gabor
In-Reply-To: <48FD55BF.1020207@pcharlan.com>
On Tue, 21 Oct 2008 06:08, Pete Harlan napisał:
> Jakub Narebski wrote:
>> Pete Harlan <pgit@pcharlan.com> writes:
>>> Johan Herland wrote:
>>>
>>> Using a secondary repo solely to overcome a flat tag/branch namespace
>>> feels hackish. Perhaps git will benefit someday from work in this area,
>>> but until I come up with a patch your suggestion should work fine. Just
>>> knowing I didn't overlook an existing feature helps a lot.
>>
>> I don't quite understand what you mean by _flat_ namespace for tags
>> and branches.
>>
>> First, it is not unusual to have hierarchical branch names, at least
>> for short-term topic branches. For example in git.git history (and in
>> "What's cooking..." announcements on git mailing list) you can find
>> branch names such as rs/alloc-ref, nd/narrow, tr/workflow-doc.
>> Additionally remote-tracking branch names have inherently hierarchical
>> names: refs/remotes/<remote>/<remote branch>. While tag names usually
>> are of the type x.y.z, it is not mandated by some technological
>> limitation.
>
> What I mean by "flat" is that "/" is just another character as far as
> what git exposes to the user. Regardless of any semantics the user
> chooses to assign to it, and regardless of what advantage git makes use
> of "/" internally, unless I can do something like:
>
> % git tag --ls
> sometag
> someothertag
> releases/
> % git tag --ls releases/
> releases/2008/
> releases/2007/
> % git tag --ls releases/2008
> releases/2008/r3.14
> %
Actually you can have kind of second and third examples; "git tag -l"
takes optional <pattern> argument, so you can do the folowing without
any new features:
# git tag -l 'releases/2008/*'
releases/2008/r3.14
(the quotes are to protect wildcard characters against expansion by
shell)
> "/" is just like any another character in a tag or branch.
>
> (The above notional --ls modifier is probably very easy to write, and if
> I do so it may address all of my woes. Subversion's branching/tagging
> can be organized pretty much exactly like this, and importing into git
> such a repository is what initially led me to ask about organizing tags
> and branches.)
Hmmm... it looks like what you are complaining is not the fact that
tags have flat namespace, but the fact that recursive mode is the
default behavior (something like "ls -R" or "git ls-tree -r").
> What I'm usually likely to want from a "list tags" command is to see the
> most recent few tags, not (say) all 226 tags in git.git. I'll probably
> write a little alias that does that, but even then when looking at the
> whole list it would be nice to have the option to navigate it
> hierarchically. (Or in some other manner, and/or possibly with a
> configurable directory separator.)
So you would want some '--local' / '--non-recursive' option to listing
all tags (for git-tag) and branches (for git-branch).
As to the "most recent few tags":
$ git for-each-ref --format='%(refname)' --sort=-taggerdate --count=10 refs/tags/
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Archiving tags/branches?
From: Pete Harlan @ 2008-10-21 9:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johan Herland, git, SZEDER Gabor
In-Reply-To: <200810211015.27257.jnareb@gmail.com>
Jakub Narebski wrote:
> > (The above notional --ls modifier is probably very easy to write, and if
> > I do so it may address all of my woes. Subversion's branching/tagging
> > can be organized pretty much exactly like this, and importing into git
> > such a repository is what initially led me to ask about organizing tags
> > and branches.)
>
> Hmmm... it looks like what you are complaining is not the fact that
> tags have flat namespace, but the fact that recursive mode is the
> default behavior (something like "ls -R" or "git ls-tree -r").
>
Yes, though I hope it didn't sound like I was complaining, just trying
to understand how people manage these things. (And "recursive" mode
being the only mode is precisely what flattens the namespace.)
> > What I'm usually likely to want from a "list tags" command is to see the
> > most recent few tags, not (say) all 226 tags in git.git. I'll probably
> > write a little alias that does that, but even then when looking at the
> > whole list it would be nice to have the option to navigate it
> > hierarchically. (Or in some other manner, and/or possibly with a
> > configurable directory separator.)
>
> So you would want some '--local' / '--non-recursive' option to listing
> all tags (for git-tag) and branches (for git-branch).
>
>
Sure, though I hadn't thought of it in those terms.
> As to the "most recent few tags":
> $ git for-each-ref --format='%(refname)' --sort=-taggerdate --count=10 refs/tags/
>
>
Well that's pretty slick, thanks :) I have aliased that to "lt", and
"lb" to:
for-each-ref --format='%(refname:short)' --sort=-authordate --count=8
refs/heads/
(which seems less useful, but it was useful as homework...)
Thanks again,
--Pete
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Michael J Gruber @ 2008-10-21 9:49 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Peter Harris, git
In-Reply-To: <48FCB6B8.6090708@xiplink.com>
Marc Branchaud venit, vidit, dixit 10/20/08 18:50:
> Thanks for the explicit instructions, but I think I'm still missing
> something. Here's exactly what I'm trying, just to make sure I'm not
> doing something odd.
>
> First I set up the remote in the main repo:
>
> main/$ git remote add -f ThingOne git://thing/ThingOne.git
> main/$ git merge -s ours --no-commit ThingOne/master
> main/$ git read-tree --prefix=thing-one/ -u ThingOne/master
> main/$ git commit -m "Adding ThingOne"
>
> Then I make a clone, fetch main's refs to ThingOne, and try to pull in
> changes from ThingOne by using those refs:
>
> $ git clone /path/to/main clone
> $ cd clone
> clone/$ git config remote.origin.fetch \
> '+refs/remotes/ThingOne/*:refs/remotes/ThingOne/*'
If you want to fetch main's local branches also, use option "--add" here
so that you don't override the default fetch refspec (forgot last time,
sorry).
> clone/$ git fetch
> From /path/to/main/
> * [new branch] ThingOne/master -> ThingOne/master
>
> clone/$ git pull -s subtree git://thing/ThingOne.git ThingOne/master
> fatal: Couldn't find remote ref ThingOne/master
because on ThingOne there is no such ref.
> The config & fetch commands indeed add a
> .git/refs/remotes/ThingOne/master file to the clone, but I'm missing the
> magic words for how to use that ref.
I thought you wanted to avoid pulling directly from ThingOne to clone?
If you pull directly you might as well set up the same remote config as
on main: for the correct pull line you need to know the same info as for
the correct remote config.
git fetch
git merge -s subtree remotes/ThingOne/master
should do the trick. If that works you can set up things so that pulling
from origin (pulling when you're in your integration branch) does that
merge automatically, using branch.integrationbranch.remote=origin,
branch.integrationbranch.merge=remotes/ThingOne/master (untested ;) ).
To be clear: The idea here is that main decides which ThingOne branch to
store in remotes/ThingOne/master and where to get it from; clones always
pull that one.
> Also:
>
> Michael J Gruber wrote:
>>> And actually, git's remote functionality feels a bit crippled if clones
>>> can't make some use of the origin's remotes. Is there a reason for
>>> keeping remote definitions out of a clone?
>> Say A and B are working on a project C. Then, typically, A is interested
>> in B's work on C, i.e. some of B's local branches, but not on B's remote
>> tracking branches: A tracks a "central" C already, just like B does,
>> and remote tracking branches don't carry any "value adding" by the
>> cloner, they're just a local unmodified copy of the remote.
>
> I can appreciate that, but the approach leads to two consequences that I
> suggest should be avoidable:
>
> 1. A and B both have to set up the references to C themselves. A can't
> just piggyback on whatever B has already set up. (This is the impetus
> for my original message.)
>
> 2. Suppose B is just a repository that's being shared between A and D --
> i.e. there's no B entity doing any work directly in B. In this case if
> A (or D) wants to change B's reference to C (say, to track a new branch
> in C), they can't: B has to be changed directly, and nothing can be done
> in a clone to accomplish this.
>
> I admit I'm picking at nits here -- obviously someone is able to access
> the B repo and do whatever needs doing. I just feel that there are some
> situations where you want the origin's remotes in your clone, and some
> where you don't, and git should let you decide.
Well, it let's you decide: It tracks local branches by default, and
using additional "git config" you can track remotes as well. You can
also use the "--mirror" option to "git clone" or "git remote add", but
that has other side effects.
Cheers,
Michael
^ permalink raw reply
* [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Charles Bailey @ 2008-10-21 10:13 UTC (permalink / raw)
To: git; +Cc: Jeff King, William Pursell, Junio C Hamano, Theodore Ts'o
In-Reply-To: <1224583999-26279-2-git-send-email-charles@hashpling.org>
This option stops git mergetool from aborting at the first failed merge.
This allows some additional use patterns. Merge conflicts can now be
previewed one at time and merges can also be skipped so that they can be
performed in a later pass.
There is also a mergetool.keepGoing configuration variable covering the
same behaviour.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
Documentation/config.txt | 4 +++
Documentation/git-mergetool.txt | 12 +++++++++-
git-mergetool.sh | 46 ++++++++++++++++++++++++++++++--------
3 files changed, 51 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b4e4ee4..789c88a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -976,6 +976,10 @@ mergetool.keepBackup::
is set to `false` then this file is not preserved. Defaults to
`true` (i.e. keep the backup files).
+mergetool.keepGoing::
+ Continue to attempt resolution of remaining conflicted files even
+ after a merge has failed or been aborted.
+
mergetool.prompt::
Prompt before each invocation of the merge resolution program.
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6d6bfe0..15466f3 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -7,7 +7,8 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
SYNOPSIS
--------
-'git mergetool' [--tool=<tool>] [-n|--no-prompt|--prompt] [<file>]...
+'git mergetool' [--tool=<tool>] [-n|--no-prompt|--prompt]
+ [-k|--keep-going|--no-keep-going] [<file>]...
DESCRIPTION
-----------
@@ -69,6 +70,15 @@ success of the resolution after the custom tool has exited.
This is the default behaviour; the option is provided to
override any configuration settings.
+-k or --keep-going::
+ Continue to attempt resolution of remaining conflicted files
+ even after a merge has failed or been aborted.
+
+--no-keep-going::
+ Abort the conflict resolution attempt if any single conflict
+ resolution fails or is aborted. This is the default behaviour;
+ the option is provided to override any configuration settings.
+
Author
------
Written by Theodore Y Ts'o <tytso@mit.edu>
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 8bc5366..c1e2de9 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,8 @@
# at the discretion of Junio C Hamano.
#
-USAGE='[--tool=tool] [-n|--no-prompt|--prompt] [file to merge] ...'
+USAGE='[--tool=tool] [-n|--no-prompt|--prompt]
+[-k|--keep-going|--no-keep-going] [file to merge] ...'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
. git-sh-setup
@@ -70,16 +71,16 @@ resolve_symlink_merge () {
git checkout-index -f --stage=2 -- "$MERGED"
git add -- "$MERGED"
cleanup_temp_files --save-backup
- return
+ return 0
;;
[rR]*)
git checkout-index -f --stage=3 -- "$MERGED"
git add -- "$MERGED"
cleanup_temp_files --save-backup
- return
+ return 0
;;
[aA]*)
- exit 1
+ return 1
;;
esac
done
@@ -97,15 +98,15 @@ resolve_deleted_merge () {
[mMcC]*)
git add -- "$MERGED"
cleanup_temp_files --save-backup
- return
+ return 0
;;
[dD]*)
git rm -- "$MERGED" > /dev/null
cleanup_temp_files
- return
+ return 0
;;
[aA]*)
- exit 1
+ return 1
;;
esac
done
@@ -137,7 +138,7 @@ merge_file () {
else
echo "$MERGED: file does not need merging"
fi
- exit 1
+ return 1
fi
ext="$$$(expr "$MERGED" : '.*\(\.[^/]*\)$')"
@@ -269,7 +270,8 @@ merge_file () {
if test "$status" -ne 0; then
echo "merge of $MERGED failed" 1>&2
mv -- "$BACKUP" "$MERGED"
- exit 1
+ cleanup_temp_files
+ return 1
fi
if test "$merge_keep_backup" = "true"; then
@@ -280,9 +282,11 @@ merge_file () {
git add -- "$MERGED"
cleanup_temp_files
+ return 0
}
prompt=$(git config --bool mergetool.prompt || echo true)
+keep_going=$(git config --bool mergetool.keepGoing || echo false)
while test $# != 0
do
@@ -305,6 +309,12 @@ do
--prompt)
prompt=true
;;
+ -k|--keep-going)
+ keep_going=true
+ ;;
+ --no-keep-going)
+ keep_going=false
+ ;;
--)
break
;;
@@ -409,6 +419,7 @@ else
fi
fi
+rollup_status=0
if test $# -eq 0 ; then
files=`git ls-files -u | sed -e 's/^[^ ]* //' | sort -u`
@@ -424,12 +435,27 @@ if test $# -eq 0 ; then
do
printf "\n"
merge_file "$i" < /dev/tty > /dev/tty
+ if test $? -ne 0; then
+ if test "$keep_going" = true; then
+ rollup_status=1
+ else
+ exit 1
+ fi
+ fi
done
else
while test $# -gt 0; do
printf "\n"
merge_file "$1"
+ if test $? -ne 0; then
+ if test "$keep_going" = true; then
+ rollup_status=1
+ else
+ exit 1
+ fi
+ fi
shift
done
fi
-exit 0
+
+exit $rollup_status
--
1.6.0.2.534.g5ab59
^ permalink raw reply related
* [PATCH 1/3] Fix some tab/space inconsistencies in git-mergetool.sh
From: Charles Bailey @ 2008-10-21 10:13 UTC (permalink / raw)
To: git; +Cc: Jeff King, William Pursell, Junio C Hamano, Theodore Ts'o
git-mergetool.sh mostly uses 8 space tabs and 4 spaces per indent. This
change corrects this in a part of the file affect by a later commit in
this patch series. diff -w considers this change is to be a null change.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
git-mergetool.sh | 38 +++++++++++++++++++-------------------
1 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 94187c3..e2da5fc 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -401,25 +401,25 @@ fi
if test $# -eq 0 ; then
- files=`git ls-files -u | sed -e 's/^[^ ]* //' | sort -u`
- if test -z "$files" ; then
- echo "No files need merging"
- exit 0
- fi
- echo Merging the files: "$files"
- git ls-files -u |
- sed -e 's/^[^ ]* //' |
- sort -u |
- while IFS= read i
- do
- printf "\n"
- merge_file "$i" < /dev/tty > /dev/tty
- done
+ files=`git ls-files -u | sed -e 's/^[^ ]* //' | sort -u`
+ if test -z "$files" ; then
+ echo "No files need merging"
+ exit 0
+ fi
+ echo Merging the files: "$files"
+ git ls-files -u |
+ sed -e 's/^[^ ]* //' |
+ sort -u |
+ while IFS= read i
+ do
+ printf "\n"
+ merge_file "$i" < /dev/tty > /dev/tty
+ done
else
- while test $# -gt 0; do
- printf "\n"
- merge_file "$1"
- shift
- done
+ while test $# -gt 0; do
+ printf "\n"
+ merge_file "$1"
+ shift
+ done
fi
exit 0
--
1.6.0.2.534.g5ab59
^ permalink raw reply related
* [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: Charles Bailey @ 2008-10-21 10:13 UTC (permalink / raw)
To: git; +Cc: Jeff King, William Pursell, Junio C Hamano, Theodore Ts'o
In-Reply-To: <1224583999-26279-1-git-send-email-charles@hashpling.org>
This option lets git mergetool invoke the conflict resolution program
without waiting for a user response each time.
Also added a mergetool.prompt (default true) configuration variable
controlling the same behaviour.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
Documentation/config.txt | 3 +++
Documentation/git-mergetool.txt | 11 ++++++++++-
git-mergetool.sh | 16 +++++++++++++---
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 29369d0..b4e4ee4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -976,6 +976,9 @@ mergetool.keepBackup::
is set to `false` then this file is not preserved. Defaults to
`true` (i.e. keep the backup files).
+mergetool.prompt::
+ Prompt before each invocation of the merge resolution program.
+
pack.window::
The size of the window used by linkgit:git-pack-objects[1] when no
window size is given on the command line. Defaults to 10.
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index e0b2703..6d6bfe0 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -7,7 +7,7 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
SYNOPSIS
--------
-'git mergetool' [--tool=<tool>] [<file>]...
+'git mergetool' [--tool=<tool>] [-n|--no-prompt|--prompt] [<file>]...
DESCRIPTION
-----------
@@ -60,6 +60,15 @@ variable `mergetool.<tool>.trustExitCode` can be set to `true`.
Otherwise, 'git-mergetool' will prompt the user to indicate the
success of the resolution after the custom tool has exited.
+-n or --no-prompt::
+ Don't prompt before each invocation of the merge resolution
+ program.
+
+--prompt::
+ Prompt before each invocation of the merge resolution program.
+ This is the default behaviour; the option is provided to
+ override any configuration settings.
+
Author
------
Written by Theodore Y Ts'o <tytso@mit.edu>
diff --git a/git-mergetool.sh b/git-mergetool.sh
index e2da5fc..8bc5366 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,7 @@
# at the discretion of Junio C Hamano.
#
-USAGE='[--tool=tool] [file to merge] ...'
+USAGE='[--tool=tool] [-n|--no-prompt|--prompt] [file to merge] ...'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
. git-sh-setup
@@ -176,8 +176,10 @@ merge_file () {
echo "Normal merge conflict for '$MERGED':"
describe_file "$local_mode" "local" "$LOCAL"
describe_file "$remote_mode" "remote" "$REMOTE"
- printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
- read ans
+ if "$prompt" = true; then
+ printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
+ read ans
+ fi
case "$merge_tool" in
kdiff3)
@@ -280,6 +282,8 @@ merge_file () {
cleanup_temp_files
}
+prompt=$(git config --bool mergetool.prompt || echo true)
+
while test $# != 0
do
case "$1" in
@@ -295,6 +299,12 @@ do
shift ;;
esac
;;
+ -n|--no-prompt)
+ prompt=false
+ ;;
+ --prompt)
+ prompt=true
+ ;;
--)
break
;;
--
1.6.0.2.534.g5ab59
^ permalink raw reply related
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Leo Razoumov @ 2008-10-21 10:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vzlkz2jv7.fsf@gitster.siamese.dyndns.org>
On 10/20/08, Junio C Hamano <gitster@pobox.com> wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> >>...
>
> >>
> >> builtin-fetch--tool.c | 2 --
> >> builtin-fetch.c | 2 --
> >> 2 files changed, 0 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
> >> index 7460ab7..5d0b95f 100644
> >> --- a/builtin-fetch--tool.c
> >> +++ b/builtin-fetch--tool.c
> >> @@ -160,8 +160,6 @@ static int append_fetch_head(FILE *fp,
> >> for (i = remote_len - 1; remote[i] == '/' && 0 <= i; i--)
> >> ;
> >> remote_len = i + 1;
> >> - if (4 < i && !strncmp(".git", remote + i - 3, 4))
> >> - remote_len = i - 3;
> >>
> >> note_len = 0;
> >> if (*what) {
> >> diff --git a/builtin-fetch.c b/builtin-fetch.c
> >> index ee93d3a..28123a5 100644
> >> --- a/builtin-fetch.c
> >> +++ b/builtin-fetch.c
> >> @@ -348,8 +348,6 @@ static int store_updated_refs(const char *url,
> >> const char *remote_name,
> >> for (i = url_len - 1; url[i] == '/' && 0 <= i; i--)
> >> ;
> >> url_len = i + 1;
> >> - if (4 < i && !strncmp(".git", url + i - 3, 4))
> >> - url_len = i - 3;
> >>
> >
> > Will this still play nicely with
> >
> > git clone foo.git
> >
> > ?
>
>
> I think it would.
>
> As far as I can tell, the only thing the patch changes is to disable the
> long established "repository name clean-up" feature in the autogenerated
> merge messages (iow, input to "fmt-merge-msg").
Even though the old behavior is "long established", it introduces
unnecessary ambiguity. If I have two repos
(1) Foo #private repo where I do my daily work
(2) Foo.git #exported public repo
the current behavior makes git messages confuse the repos.
--Leo--
^ permalink raw reply
* Re: [RFC PATCH] commit: Warn about encodings unsupported by iconv.
From: Alexander Gavrilov @ 2008-10-21 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Paul Mackerras
In-Reply-To: <7vmygy233r.fsf@gitster.siamese.dyndns.org>
On Tue, Oct 21, 2008 at 4:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Alexander Gavrilov <angavrilov@gmail.com> writes:
>
>> diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
>> index 0453425..7f325a3 100644
>> --- a/builtin-commit-tree.c
>> +++ b/builtin-commit-tree.c
>> @@ -45,6 +45,28 @@ static const char commit_utf8_warn[] =
>> "You may want to amend it after fixing the message, or set the config\n"
>> "variable i18n.commitencoding to the encoding your project uses.\n";
>>
>> +static const char commit_bad_encoding_warn[] =
>> +"Warning: commit encoding '%s' is not supported.\n"
>> +"You may want to change the value of the i18n.commitencoding config\n"
>> +"variable, and redo the commit. Use 'iconv --list' to see the list of\n"
>> +"available encoding names.\n";
>> +
>> +static void verify_commit_encoding(const char *text, const char *encoding)
>> +{
>> + if (is_encoding_utf8(encoding)) {
>> + if (!is_utf8(text))
>> + fprintf(stderr, commit_utf8_warn);
>> + }
>> +#ifndef NO_ICONV
>> + else {
>> + char *conv = reencode_string("", "utf-8", encoding);
>> + if (!conv)
>> + fprintf(stderr, commit_bad_encoding_warn, encoding);
>> + free(conv);
>> + }
>> +#endif
>> +}
>> +
> It just marks it with the encoding header. Wouldn't that mean that it
> should be possible for you to create a commit with its message encoded in
> KOI-8, and mark the resulting commit as encoded as such, on a host that is
> incapable of actually transcoding from KOI-8 to utf-8? IOW, your being
> able to encode from i18n.commitencoding to utf-8 does not have much to do
> with the validity of the configuration variable.
It may be possible to check for reencode_string("", encoding,
encoding). IConv should be able to do the identity conversion for any
valid encoding. I checked with the iconv command-line executable on my
system, and it correctly errors out on invalid names, and agrees to do
the conversion for valid ones.
> It would clarify the issues to think about what this new code would do on
> a host without iconv, if you do not have the above #ifndef/#endif pair.
> The replacement reencode_string() implementation always returns NULL, so
> the code will always warn.
>
> I am guessing that the reason you added #ifndef/#endif is because what the
> warning message says is incorrect.
>
> * "is not supported" is not correct. "is not supported HERE" may be.
>
> * "is not supported" (nor "is not supported HERE") does not matter. It
> is log-reading side that does the re-encoding, not the commit
> generating side.
The trouble is, by the time it gets to the "log-reading" side, it may
be too late to do anything, because the commits have already been
created, hashed and pushed out somewhere. And the originating side
won't notice because they would actually expect to get the messages
without conversion from their git-log. It may be amended somewhat if
gitk insists on receiving all data from git-log in utf-8 unless
explicitly told otherwise; on the other hand it may make people think
that the problem is in gitk...
> * what you would really want to say is "might be incorrectly spelled",
> but your problem is that you do not have a direct way to check that.
>
> Another reason of your "#ifndef/#endif" would be that there is no way to
> squelch the warning message after seeing it on a NO_ICONV platform.
>
> But that suggests that the "#ifndef/#endif" is not a good way to squelch
> the message. What would you do, after seeing the warning message and
> examining the situation, you know KOI-8 is a valid encoding name, your
> editor is recording what you type in the commit log message in KOI-8, you
> know you set i18n.commitencoding to KOI-8, and you know somehow your
> system is incapable of reencode_string("", "utf-8" "KOI-8")? There is no
> way to squelch the message.
A bit of a problem is that unless git implements its own encoding
alias table, the only authority on valid encoding names is iconv. So
checking would still involve running reencode_string, or looking at
iconv --list, possibly on another machine.
> So perhaps you would need some "state" variable that says "I know this
> i18n.commitencoding configuration is valid" if you go this route? But the
> reason for "I know" would be either (1) because we earlier tried
> reencode_string() and it resulted in an Ok return, or (2) because the user
> verified that the configuration is valid, even though on this particular
> system it cannot be encoded to utf-8. IOW, the latter one would be
> "because the user tells us so" --- which would be the same as trusting
> i18n.commitencoding from the beginning. I dunno.
Maybe if the option is called something like i18n.brokenIconv, people
would understand that it should not be enabled in normal
circumstances? It can also be used to tell GUI tools that git-log
cannot be trusted to do the conversion properly -- perhaps being
enabled system-wide by make install if NO_ICONV is set.
> I actually have an alternative approach to suggest.
>
> How about adding a new i18n.commit-reencode-logmessage option (boolean),
> and when it is set, we actually re-encode from i18n.commitencoding to
> "utf-8" before creating the commit object (and obviously we do not store
> "encoding" header in the resulting commit)? When the conversion fails, we
> know it failed, so the warning you added does make sense in that context.
This option changes the way data is actually processed before storing,
so it probably cannot be turned on by default -- while the check is
nearly useless _unless_ it is turned on by default.
Alexander
^ permalink raw reply
* Re: [PATCH 3/3] Add -k/--keep-going option to mergetool
From: Jeff King @ 2008-10-21 11:12 UTC (permalink / raw)
To: Charles Bailey; +Cc: git, William Pursell, Junio C Hamano, Theodore Ts'o
In-Reply-To: <1224583999-26279-3-git-send-email-charles@hashpling.org>
On Tue, Oct 21, 2008 at 11:13:19AM +0100, Charles Bailey wrote:
> This option stops git mergetool from aborting at the first failed merge.
> This allows some additional use patterns. Merge conflicts can now be
> previewed one at time and merges can also be skipped so that they can be
> performed in a later pass.
All 3 patches look good to me, and match what I expected from our
earlier discussion. But I am not too familiar with mergetool, so take my
approval with a grain of salt. :)
-Peff
^ permalink raw reply
* Re: [PATCH, RFC] diff: add option to show context between close chunks
From: Jeff King @ 2008-10-21 11:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, René Scharfe, Git Mailing List,
Davide Libenzi
In-Reply-To: <7vskqqzajy.fsf@gitster.siamese.dyndns.org>
On Tue, Oct 21, 2008 at 12:12:17AM -0700, Junio C Hamano wrote:
> Yeah. René wanted this for _human consumption_, not mechanical patch
> application, so "hardcoding" literally there in the very low level of the
> diff callchain is not quite right (it would affect format-patch which is
> primarily for mechanical application).
>
> I guess you could make the hardcoded value 1 for everybody else and 0 for
> format-patch.
I see your reasoning, but at the same time, a large portion of patches I
read are from format-patch (and René even said that he was trying to
save the user from the "apply then diff just to look at the patch"
annoyance). And I have personally, as a patch submitter, created some
format-patch output sent to the git list with -U5 to combine hunks and
make it more readable for reviewers.
Not to mention that I sometimes apply or post the output of "git diff".
To me that it implies that either:
- the increased chance of conflict is not a problem in practice, and we
should have the option on by default everywhere
- it is a problem, in which case we should ask the user to turn on the
feature manually instead of second-guessing how they will use the
resulting patch (which they might not even know, since they are
making assumptions about how other people might use the patch, and
they must decide for their situation between shipping something that
is more readable but slightly more conflict prone, or as easy to
apply as possible)
-Peff
^ permalink raw reply
* git command to read
From: Paul Mackerras @ 2008-10-21 11:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio,
Is there a command in git at the moment that will read commit IDs on
standard input and print the contents of each commit on standard
output (without waiting for EOF on stdin)?
I tried git rev-list --stdin --no-walk --header, but it seems to
collect all the IDs from stdin and eliminate duplicates before
outputting anything, which is not what I want. What I want is a
process that I can run from gitk where I can write IDs to its stdin
whenever gitk needs to know the contents of some commits, and know
that those contents will be turning up on the pipe from its stdout in
a timely fashion, without having to start a new process each time. Is
there a way to do that currently?
The reason I want this is to reduce gitk's memory usage. At present
it reads all the commits into memory, which takes about 160MB on the
current kernel tree just to store the contents of all the commits
(since Tcl stores strings internally as 2 bytes/character). Instead I
plan to make gitk keep a cache of commits and read in commits as
needed from an external process. When doing a search, we may need to
read in nearly all the commits, and we'll need to do it quickly.
Thanks,
Paul.
^ permalink raw reply
* Re: git command to read
From: Jeff King @ 2008-10-21 11:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <18685.47909.354146.487700@cargo.ozlabs.ibm.com>
On Tue, Oct 21, 2008 at 10:21:09PM +1100, Paul Mackerras wrote:
> Is there a command in git at the moment that will read commit IDs on
> standard input and print the contents of each commit on standard
> output (without waiting for EOF on stdin)?
How about:
git cat-file --batch
?
Unfortunately it just dumps the raw commit information instead of
allowing the usual formatting, but perhaps that is sufficient (you asked
for "contents").
-Peff
^ permalink raw reply
* Re: [PATCH 7/7] gitk: Explicitly position popup windows.
From: Paul Mackerras @ 2008-10-21 11:41 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <1223449540-20457-8-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> For some reason, on Windows all transient windows are placed
> in the upper left corner of the screen. Thus, it is necessary
> to explicitly position the windows using the tk::PlaceWindow
> function.
Hmmm, this is not part of the official Tk API as far as I can see, and
having to call tk::PlaceWindow on every window we create is a bit
gross. What exactly does it do, and what effect will this change have
on Linux? Are you sure there isn't some other way to fix the problem?
Paul.
^ permalink raw reply
* Re: [PATCH 2/7] gitk: Allow forcing branch creation if it already exists.
From: Paul Mackerras @ 2008-10-21 11:38 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <1223449540-20457-3-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> If gitk knows that the branch the user tries to create exists,
> it should ask whether it should overwrite it. This way the user
> can either decide to choose a new name, or move the head while
> preserving the reflog.
Applied, thanks.
Paul.
^ permalink raw reply
* Re: [PATCH 4/7] gitk: Fix file list context menu for merge commits.
From: Paul Mackerras @ 2008-10-21 11:39 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <1223449540-20457-5-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> Currently it displays an ugly error box, because the
> treediffs array is not filled for such commits. This
> is clearly unacceptable.
Applied, thanks, with a better patch description, one that actually
described the remedial action. :)
Paul.
^ permalink raw reply
* Re: [PATCH 1/7] gitk: Enhance UI popup and accelerator handling.
From: Paul Mackerras @ 2008-10-21 11:35 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <1223449540-20457-2-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> - Popups are supposed to be marked transient, otherwise
> the WM creates them in strange places. Besides, at
> least under kwin, transients are automatically kept
> above their parent.
> - Accelerators for menu items should be listed directly
> on the items, to make them more discoverable.
> - Some more accelerators are added, e.g. F4 for Edit View.
> - Finally, dialogs can now be accepted or dismissed using
> the Return and Escape keys.
Could you rebase this and split it into 3 patches, one each for the
transient popups, accelerators, and return/escape key bindings?
Thanks,
Paul.
^ permalink raw reply
* Re: git command to read
From: Paul Mackerras @ 2008-10-21 11:45 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20081021112521.GC17363@coredump.intra.peff.net>
Jeff King writes:
> On Tue, Oct 21, 2008 at 10:21:09PM +1100, Paul Mackerras wrote:
>
> > Is there a command in git at the moment that will read commit IDs on
> > standard input and print the contents of each commit on standard
> > output (without waiting for EOF on stdin)?
>
> How about:
>
> git cat-file --batch
>
> ?
>
> Unfortunately it just dumps the raw commit information instead of
> allowing the usual formatting, but perhaps that is sufficient (you asked
> for "contents").
Ah, thank you, that looks like just what I want. :)
Paul.
^ permalink raw reply
* Re: [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: Andreas Ericsson @ 2008-10-21 11:49 UTC (permalink / raw)
To: Charles Bailey
Cc: git, Jeff King, William Pursell, Junio C Hamano,
Theodore Ts'o
In-Reply-To: <1224583999-26279-2-git-send-email-charles@hashpling.org>
Charles Bailey wrote:
> This option lets git mergetool invoke the conflict resolution program
> without waiting for a user response each time.
>
> Also added a mergetool.prompt (default true) configuration variable
> controlling the same behaviour.
>
> Signed-off-by: Charles Bailey <charles@hashpling.org>
> ---
> Documentation/config.txt | 3 +++
> Documentation/git-mergetool.txt | 11 ++++++++++-
> git-mergetool.sh | 16 +++++++++++++---
> 3 files changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 29369d0..b4e4ee4 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -976,6 +976,9 @@ mergetool.keepBackup::
> is set to `false` then this file is not preserved. Defaults to
> `true` (i.e. keep the backup files).
>
> +mergetool.prompt::
> + Prompt before each invocation of the merge resolution program.
> +
> pack.window::
> The size of the window used by linkgit:git-pack-objects[1] when no
> window size is given on the command line. Defaults to 10.
> diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
> index e0b2703..6d6bfe0 100644
> --- a/Documentation/git-mergetool.txt
> +++ b/Documentation/git-mergetool.txt
> @@ -7,7 +7,7 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
>
> SYNOPSIS
> --------
> -'git mergetool' [--tool=<tool>] [<file>]...
> +'git mergetool' [--tool=<tool>] [-n|--no-prompt|--prompt] [<file>]...
>
> DESCRIPTION
> -----------
> @@ -60,6 +60,15 @@ variable `mergetool.<tool>.trustExitCode` can be set to `true`.
> Otherwise, 'git-mergetool' will prompt the user to indicate the
> success of the resolution after the custom tool has exited.
>
> +-n or --no-prompt::
> + Don't prompt before each invocation of the merge resolution
> + program.
> +
There is discussion already about "-n should be for dry-run!" and git's
inconsistencies in such matters. Wouldn't -y ("assume yes on prompt")
be better?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git command to read
From: Alexander Gavrilov @ 2008-10-21 12:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <18685.49368.557513.727997@cargo.ozlabs.ibm.com>
On Tue, Oct 21, 2008 at 3:45 PM, Paul Mackerras <paulus@samba.org> wrote:
> Jeff King writes:
>
>> On Tue, Oct 21, 2008 at 10:21:09PM +1100, Paul Mackerras wrote:
>>
>> > Is there a command in git at the moment that will read commit IDs on
>> > standard input and print the contents of each commit on standard
>> > output (without waiting for EOF on stdin)?
>>
>> How about:
>>
>> git cat-file --batch
>>
>> ?
>>
>> Unfortunately it just dumps the raw commit information instead of
>> allowing the usual formatting, but perhaps that is sufficient (you asked
>> for "contents").
>
> Ah, thank you, that looks like just what I want. :)
Since cat-file does not perform any encoding conversion, you'll have
to process the encoding headers manually though.
Alexander
^ permalink raw reply
* Re: [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: Charles Bailey @ 2008-10-21 12:26 UTC (permalink / raw)
To: Andreas Ericsson
Cc: git, Jeff King, William Pursell, Junio C Hamano,
Theodore Ts'o
In-Reply-To: <48FDC1CA.2080800@op5.se>
On Tue, Oct 21, 2008 at 01:49:30PM +0200, Andreas Ericsson wrote:
>
> There is discussion already about "-n should be for dry-run!" and git's
> inconsistencies in such matters. Wouldn't -y ("assume yes on prompt")
> be better?
>
I must have missed this discussion. I've just had a very quick look at
a handful of basic modifying git commands (merge, pull, commit,
checkout, reset, revert) and only found 'add' that used -n as
--dry-run.
That said, I've no real objections to -y if that makes for a better
consensus.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [PATCH 7/7] gitk: Explicitly position popup windows.
From: Alexander Gavrilov @ 2008-10-21 12:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18685.49152.25344.398737@cargo.ozlabs.ibm.com>
On Tue, Oct 21, 2008 at 3:41 PM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>
>> For some reason, on Windows all transient windows are placed
>> in the upper left corner of the screen. Thus, it is necessary
>> to explicitly position the windows using the tk::PlaceWindow
>> function.
>
> Hmmm, this is not part of the official Tk API as far as I can see, and
> having to call tk::PlaceWindow on every window we create is a bit
> gross. What exactly does it do, and what effect will this change have
> on Linux? Are you sure there isn't some other way to fix the problem?
It is just a convenient helper function that can explicitly compute
and set the window position in a number of ways. It is used in Tk's
dialog implementations. If you don't like using an unofficial
function, I can pull out the relevant ~8 lines of code as a separate
function in gitk.
http://objectmix.com/tcl/390381-tile-dialog-boxes-not-transient-parent-under-windows.html
http://wiki.tcl.tk/1254
Alexander
^ permalink raw reply
* Re: [PATCH 2/2] rm: loosen safety valve for empty files
From: Jeff King @ 2008-10-21 13:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4p361x1f.fsf@gitster.siamese.dyndns.org>
On Mon, Oct 20, 2008 at 07:50:36PM -0700, Junio C Hamano wrote:
> in addition to what you are trying to fix here with "git rm". With such a
> change, your "git rm empty" code can also distinguish between an empty
> blob the user wanted to add _as the final contents_, and a path that has
> been marked with "add -N", and behave differently (the former would not
> require -f while the latter would).
Your reasoning makes sense.
> As an interim measure, I suspect your patch is an improvement from the
> current state of affairs, but the above test will then break when an
> improvement to "git add -N" implementation outlined above materializes.
Yeah, I actually considered writing it as "git add -N", but I thought it
better that the person who changes the behavior breaks the test, reads
the commit message, and decides then what the best behavior is.
But if you are comfortable saying now "this is what the behavior
_should_ be", then I think the test modifications you proposed make
sense (and after reading your discussion above, I think the behavior you
propose is reasonable).
> So how about changing the test to explicitly check that a path that was
> added by "git add -N" can be removed, and either (1) not check about an
> empty blob that was explicitly added by the user, or (2) check that an
> empty blob that was explicitly added by the user cannot be "git rm"'ed
> without -f, with expect_failure?
Patch below. I tried to expand the commit message to explain the
situation to the future developer who extends intent-to-add, but please
mark up if anything seems unclear.
-- >8 --
rm: loosen safety valve for empty files
If a file is different between the working tree copy, the
index, and the HEAD, then we do not allow it to be deleted
without --force.
However, this is overly tight in the face of "git add
--intent-to-add":
$ git add --intent-to-add file
$ : oops, I don't actually want to stage that yet
$ git rm --cached file
error: 'empty' has staged content different from both the
file and the HEAD (use -f to force removal)
$ git rm -f --cached file
Unfortunately, there is currently no way to distinguish
between an empty file that has been added and an "intent to
add" file. The ideal behavior would be to disallow the
former while allowing the latter.
This patch loosens the safety valve to allow the deletion
only if we are deleting the cached entry and the cached
content is empty. This covers the intent-to-add situation,
and assumes there is little harm in not protecting users who
have legitimately added an empty file. In many cases,
the file will still be empty, in which case the safety valve
does not trigger anyway (since the content remains untouched
in the working tree). Otherwise, we do remove the fact that
no content was staged, but given that the content is by
definition empty, it is not terribly difficult for a user to
recreate it.
However, we still document the desired behavior in the form
of two tests. One checks the correct removal of an
intent-to-add file. The other checks that we still disallow
removal of empty files, but is marked as expect_failure to
indicate this compromise. If the intent-to-add feature is
ever extended to differentiate between normal empty files
and intent-to-add files, then the safety valve can be
re-tightened.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-rm.c | 3 ++-
cache.h | 1 +
read-cache.c | 2 +-
t/t3600-rm.sh | 13 +++++++++++++
4 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/builtin-rm.c b/builtin-rm.c
index e06640c..b7126e3 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -79,7 +79,8 @@ static int check_local_mod(unsigned char *head, int index_only)
|| hashcmp(ce->sha1, sha1))
staged_changes = 1;
- if (local_changes && staged_changes)
+ if (local_changes && staged_changes &&
+ !(index_only && is_empty_blob_sha1(ce->sha1)))
errs = error("'%s' has staged content different "
"from both the file and the HEAD\n"
"(use -f to force removal)", name);
diff --git a/cache.h b/cache.h
index cdbeb48..b0edbf9 100644
--- a/cache.h
+++ b/cache.h
@@ -519,6 +519,7 @@ static inline void hashclr(unsigned char *hash)
{
memset(hash, 0, 20);
}
+extern int is_empty_blob_sha1(const unsigned char *sha1);
int git_mkstemp(char *path, size_t n, const char *template);
diff --git a/read-cache.c b/read-cache.c
index fdb41b8..2c45086 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -160,7 +160,7 @@ static int ce_modified_check_fs(struct cache_entry *ce, struct stat *st)
return 0;
}
-static int is_empty_blob_sha1(const unsigned char *sha1)
+int is_empty_blob_sha1(const unsigned char *sha1)
{
static const unsigned char empty_blob_sha1[20] = {
0xe6,0x9d,0xe2,0x9b,0xb2,0xd1,0xd6,0x43,0x4b,0x8b,
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 66aca99..5b4d6f7 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -187,6 +187,19 @@ test_expect_success 'but with -f it should work.' '
test_must_fail git ls-files --error-unmatch baz
'
+test_expect_failure 'refuse to remove cached empty file with modifications' '
+ touch empty &&
+ git add empty &&
+ echo content >empty &&
+ test_must_fail git rm --cached empty
+'
+
+test_expect_success 'remove intent-to-add file without --force' '
+ echo content >intent-to-add &&
+ git add -N intent-to-add
+ git rm --cached intent-to-add
+'
+
test_expect_success 'Recursive test setup' '
mkdir -p frotz &&
echo qfwfq >frotz/nitfol &&
--
1.6.0.2.808.gf6cf2
^ permalink raw reply related
* [PATCH] git-remote: list branches in vertical lists
From: Johannes Sixt @ 2008-10-21 14:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
From: Johannes Sixt <johannes.sixt@telecom.at>
Previously, branches were listed on a single line in each section. But
if there are many branches, then horizontal, line-wrapped lists are very
inconvenient to scan for a human. This makes the lists vertical, i.e one
branch per line is printed.
This does mean that users' scripts must be updated because the output
format changed, but the result is friendlier to the eye *and* easier to
parse.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Documentation/user-manual.txt | 4 +++-
builtin-remote.c | 11 +++++------
t/t5505-remote.sh | 14 +++++++++-----
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 08d1310..645d752 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -4356,7 +4356,9 @@ $ git remote show example # get details
* remote example
URL: git://example.com/project.git
Tracked remote branches
- master next ...
+ master
+ next
+ ...
$ git fetch example # update branches from example
$ git branch -r # list all remote branches
-----------------------------------------------
diff --git a/builtin-remote.c b/builtin-remote.c
index 90a4e35..1b1697b 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -416,10 +416,9 @@ static void show_list(const char *title, struct string_list *list,
return;
printf(title, list->nr > 1 ? "es" : "", extra_arg);
- printf("\n ");
- for (i = 0; i < list->nr; i++)
- printf("%s%s", i ? " " : "", list->items[i].string);
printf("\n");
+ for (i = 0; i < list->nr; i++)
+ printf(" %s\n", list->items[i].string);
}
static int get_remote_ref_states(const char *name,
@@ -515,17 +514,17 @@ static int show(int argc, const char **argv)
show_list(" Tracked remote branch%s", &states.tracked, "");
if (states.remote->push_refspec_nr) {
- printf(" Local branch%s pushed with 'git push'\n ",
+ printf(" Local branch%s pushed with 'git push'\n",
states.remote->push_refspec_nr > 1 ?
"es" : "");
for (i = 0; i < states.remote->push_refspec_nr; i++) {
struct refspec *spec = states.remote->push + i;
- printf(" %s%s%s%s", spec->force ? "+" : "",
+ printf(" %s%s%s%s\n",
+ spec->force ? "+" : "",
abbrev_branch(spec->src),
spec->dst ? ":" : "",
spec->dst ? abbrev_branch(spec->dst) : "");
}
- printf("\n");
}
/* NEEDSWORK: free remote */
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index e5137dc..e6cf2c7 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -28,7 +28,7 @@ tokens_match () {
}
check_remote_track () {
- actual=$(git remote show "$1" | sed -n -e '$p') &&
+ actual=$(git remote show "$1" | sed -e '1,/Tracked/d') &&
shift &&
tokens_match "$*" "$actual"
}
@@ -118,9 +118,11 @@ cat > test/expect << EOF
New remote branch (next fetch will store in remotes/origin)
master
Tracked remote branches
- side master
+ side
+ master
Local branches pushed with 'git push'
- master:upstream +refs/tags/lastbackup
+ master:upstream
+ +refs/tags/lastbackup
EOF
test_expect_success 'show' '
@@ -147,9 +149,11 @@ cat > test/expect << EOF
Remote branch merged with 'git pull' while on branch master
master
Tracked remote branches
- master side
+ master
+ side
Local branches pushed with 'git push'
- master:upstream +refs/tags/lastbackup
+ master:upstream
+ +refs/tags/lastbackup
EOF
test_expect_success 'show -n' '
--
1.6.0.2.1573.gdf533
^ permalink raw reply related
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Nguyen Thai Ngoc Duy @ 2008-10-21 14:57 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0810202110380.26244@xanadu.home>
On 10/21/08, Nicolas Pitre <nico@cam.org> wrote:
> Before commit d0b92a3f6e it was possible to run 'git index-pack'
> directly in the .git/objects/pack/ directory. Restore that ability.
I am sorry I did not catch this in the first place. While the fix
should be fine for "git index-pack". I wonder what can happen for
other setup_*_gently()'s consumers. Other commands may be affected too
(e.g. running "git apply" or "git bundle" from inside .git). Maybe we
should let setup_*_gently() do read-only stuff only and let its
consumers to handle cwd. I recall Jeff has plan about worktree setup
rework, though could not find the thread. Will think more of it
tomorrow.
--
Duy
^ 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