* Re: [PATCH v2 0/5] Makefile: fix generation of assembler listings
From: Linus Torvalds @ 2010-01-06 9:07 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <20100106080216.GA7298@progeny.tock>
On Wed, 6 Jan 2010, Jonathan Nieder wrote:
>
> Patch 1 fixes a problem I noticed when tweaking the Makefile to
> automatically generate dependencies for the %.o targets. The problem
> is that the dependencies for the corresponding %.s (code listing)
> targets are not included in the Makefile at all, automatically or not.
Patches 1-3 (which were the ones I was cc'd on) look sane to me. Having
real dependencies might be prettier, but I agree that since a *.s file is
only generated on demand (and useful mainly to see code generation), just
forcing the build makes sense.
Linus
^ permalink raw reply
* Re: cmake, was Re: submodules' shortcomings
From: Johannes Schindelin @ 2010-01-06 9:24 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Git Mailing List
In-Reply-To: <3af572ac1001051717u7757f0dep9392fbb7b02cbbca@mail.gmail.com>
Hi,
On Wed, 6 Jan 2010, Pau Garcia i Quiles wrote:
> On Wed, Jan 6, 2010 at 12:06 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Tue, 5 Jan 2010, Pau Garcia i Quiles wrote:
> >
> >> For instance, I'd like to have a 'cmake' repository where I store all
> >> the FindBlah.cmake modules, so that I can share them from every
> >> repository, and not worry about users changing and committing in the
> >> main project instead of the submodule.
> >
> > ... which reminds me... it was you who wanted to provide a working
> > recipe to compile and install CMake on msysGit, right?
>
> Right
>
> > What happened in the meantime?
>
> What happened is I was very busy until November. Now I've got some free
> time.
>
> At this moment, what stops me from beginning this project is a simple
> question: is it worth my time?
Well, I thought you wanted to show that CMake is superior to what we have
right now, and for me as msysGit maintainer, that implies that CMake
actually works within msysGit.
Now, I do not think that it is hard to get CMake to compile in msysGit,
but then, I just lost access to the last Windows computer, so I cannot do
that myself.
As Miles said, it is up to you to decide whether it is so complicated, or
whether CMake is likely not to convince, that the time balance turns out
positive or negative.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC 0/2] Lazily generate header dependencies
From: Johannes Schindelin @ 2010-01-06 9:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Jonathan Nieder, Johannes Sixt,
Git Mailing List
In-Reply-To: <7vwrzwnirz.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 5 Jan 2010, Junio C Hamano wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
> > Junio, could you tell us what happened to this thread?
> >
> > Makefile improvements. No discussion.
>
> I was mildly interested in the series, but after this:
>
> http://thread.gmane.org/gmane.comp.version-control.git/133872/focus=133911
>
> the progress seems to have stopped.
Like I said yesterday, I do not want to spend time chasing old threads.
But if you spend just two more minutes to summarize what came out of that
thread (two well spent minutes in the global time balance, if you ask me),
I will gladly comment.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC 0/2] Lazily generate header dependencies
From: Jonathan Nieder @ 2010-01-06 9:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Nanako Shiraishi, Johannes Sixt, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.1001061024400.11013@intel-tinevez-2-302>
Hi,
Johannes Schindelin wrote:
> On Tue, 5 Jan 2010, Junio C Hamano wrote:
>> I was mildly interested in the series, but after this:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/133872/focus=133911
>>
>> the progress seems to have stopped.
>
> Like I said yesterday, I do not want to spend time chasing old threads.
> But if you spend just two more minutes to summarize what came out of that
> thread (two well spent minutes in the global time balance, if you ask me),
> I will gladly comment.
I received some feedback (a suggestion to tuck the makefile snippets in
a separate directory and a follow-up suggestion to make the list of
directories needed for this more maintainable) but have not sent an updated
patch yet. Hopefully tomorrow I will have more to comment on.
Apologies again for the long silence,
Jonathan
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Nanako Shiraishi @ 2010-01-06 10:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskal5c11.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com> writes:
> These need a bit more work to go forward. Help and follow-up are
> appreciated.
>
> * jc/checkout-merge-base (2009-11-20) 2 commits
> Users of "rebase -i" might want to teach this to the command.
> Volunteers?
Let me try. I'll let others to contribute documentation updates.
-- >8 --
Subject: [PATCH] Fix rebase --onto A...B and teach the same to interactive rebase
Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
---
git-rebase--interactive.sh | 21 +++++++++++-
git-rebase.sh | 4 +-
t/t3415-rebase-onto-threedots.sh | 68 ++++++++++++++++++++++++++++++++++++++
3 files changed, 90 insertions(+), 3 deletions(-)
create mode 100755 t/t3415-rebase-onto-threedots.sh
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 23ded48..d42cc4f 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -482,6 +482,25 @@ get_saved_options () {
test -f "$DOTEST"/rebase-root && REBASE_ROOT=t
}
+LF='
+'
+parse_onto () {
+ if expr "$1" : '.*\.\.\.' >/dev/null &&
+ left=${1%...*} right=${1#*...} &&
+ : ${left:=HEAD} ${right:=HEAD} &&
+ onto=$(git merge-base "$left" "$right")
+ then
+ case "$onto" in
+ ?*"$LF"?* | '')
+ exit 1 ;;
+ esac
+ echo "$onto"
+ exit 0
+ else
+ git rev-parse --verify "$1^0"
+ fi
+}
+
while test $# != 0
do
case "$1" in
@@ -589,7 +608,7 @@ first and then run 'git rebase --continue' again."
;;
--onto)
shift
- ONTO=$(git rev-parse --verify "$1") ||
+ ONTO=$(parse_onto "$1") ||
die "Does not point to a valid commit: $1"
;;
--)
diff --git a/git-rebase.sh b/git-rebase.sh
index 6503113..43c62c0 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -419,8 +419,8 @@ fi
# Make sure the branch to rebase onto is valid.
onto_name=${newbase-"$upstream_name"}
-if left=$(expr "$onto_name" : '\(.*\)\.\.\.') &&
- right=$(expr "$onto_name" : '\.\.\.\(.*\)$') &&
+if expr "$onto_name" : '.*\.\.\.' >/dev/null &&
+ left=${onto_name%...*} right=${onto_name#*...} &&
: ${left:=HEAD} ${right:=HEAD} &&
onto=$(git merge-base "$left" "$right")
then
diff --git a/t/t3415-rebase-onto-threedots.sh b/t/t3415-rebase-onto-threedots.sh
new file mode 100755
index 0000000..c243243
--- /dev/null
+++ b/t/t3415-rebase-onto-threedots.sh
@@ -0,0 +1,68 @@
+#!/bin/sh
+
+test_description='git rebase --onto A...B'
+
+. ./test-lib.sh
+. "$TEST_DIRECTORY/lib-rebase.sh"
+
+# F---G G'
+# / --> /
+# A---B---C---D---E A---B---C---D---E
+
+test_expect_success setup '
+ test_commit A &&
+ test_commit B &&
+ test_commit C &&
+ git branch topic &&
+ test_commit D &&
+ test_commit E &&
+ git checkout topic &&
+ test_commit F &&
+ test_commit G
+'
+
+test_expect_success 'rebase --onto A...B' '
+ git reset --hard &&
+ git checkout topic &&
+ git reset --hard G &&
+
+ git rebase --onto master...topic HEAD^ &&
+ git rev-parse HEAD^ >actual &&
+ git rev-parse C^0 >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'rebase --onto A...' '
+ git reset --hard &&
+ git checkout topic &&
+ git reset --hard G &&
+
+ git rebase --onto master... HEAD^ &&
+ git rev-parse HEAD^ >actual &&
+ git rev-parse C^0 >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'rebase -i --onto A...B' '
+ git reset --hard &&
+ git checkout topic &&
+ git reset --hard G &&
+ set_fake_editor &&
+ EXPECT_COUNT=1 git rebase -i --onto master...topic HEAD^ &&
+ git rev-parse HEAD^ >actual &&
+ git rev-parse C^0 >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'rebase -i --onto A...' '
+ git reset --hard &&
+ git checkout topic &&
+ git reset --hard G &&
+ set_fake_editor &&
+ EXPECT_COUNT=1 git rebase -i --onto master... HEAD^ &&
+ git rev-parse HEAD^ >actual &&
+ git rev-parse C^0 >expect &&
+ test_cmp expect actual
+'
+
+test_done
--
1.6.6
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: git-cherry-pick problem - directory not touched by commit is marked "added by us"
From: Hakim Cassimally @ 2010-01-06 11:28 UTC (permalink / raw)
To: git, Sam Vilain
In-Reply-To: <1262727434.22597.8.camel@denix>
2010/1/5 Sam Vilain <sam@vilain.net>:
> On Tue, 2010-01-05 at 12:33 +0000, Hakim Cassimally wrote:
>> I got into a bit of trouble with a git-cherry-pick last night, and
>> though mugwump
>> and others on #git helped me as far as a workaround,
> Yes, that was me. I'm very confused by the bug, too.
>
> [...]
>> WHAT HAPPENS
>> ============
>>
>> When I'm in (stable), and try to cherry-pick the change from (experimental),
>> git thinks that I'm making a massive number of changes in a directory that
>> wasn't touched by the relevant commit.
> [...]
>> (stable) $ git --version
>> git version 1.6.6
>> # I tried previously on 1.6.0.4 but upgraded in case it helped
>>
>> (stable) $ git status
>> # On branch stable
>> # nothing to commit (working directory clean)
>>
>> (stable) $ git show --stat 301afce1
>> commit 301afce1c78380276d208077ef4ec76b469c1024
>> Author: osfameron <...>
>> Date: Wed Dec 23 23:45:20 2009 +0000
>>
>> Proof of concept for import module (parse Excel)
>>
>> bin/upload_module.pl | 142
>> ++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 142 insertions(+), 0 deletions(-)
>>
>> (stable) $ git whatchanged -1 301afce1
>> commit 301afce1c78380276d208077ef4ec76b469c1024
>> Author: osfameron <...>
>> Date: Wed Dec 23 23:45:20 2009 +0000
>>
>> Proof of concept for import module (parse Excel)
>>
>> :000000 100644 0000000... c90e261... A bin/upload_module.pl
>
> So by here, we know that the commit only affects that single file. No
> funny stuff like mode changes of other files.
>
>> (stable) $ git cherry-pick 301afce1
>> Finished one cherry-pick.
>> www/client/css/admin.css: needs merge
>> <...snip>
>> www/client/css/admin.css: unmerged
>> (8e7cd850bf40d1a921b1f62ce0945abd374fa55d)
>> <...snip>
>> ...
>> error: Error building trees
>
> Then, wham, these files want to be changed. What is the diff-tree
> inside revert/cherry-pick doing differently to the one in log?
> Hakim, one more useful thing in this situation would be to show the
> state of these files in the index;
>
> git ls-files -s -u
$ git ls-files -s -u www/client/css/admin.css # only staged/unmerged
100755 8e7cd850bf40d1a921b1f62ce0945abd374fa55d 2
www/client/css/admin.css
(i.e. when run after the failed cherry-pick)
> Also take the 'git ls-tree -r HEAD', 'git ls-tree -r 301afce1' and 'git
> ls-tree -r 301afce1^' output, and grep for the files in question. The
> answer (or at least a bug triage) should be in the output of those
> commands.
$ git ls-tree HEAD | grep www/client/css/admin.css
100755 blob 8e7cd850bf40d1a921b1f62ce0945abd374fa55d
www/client/css/admin.css
There's no entry in git ls-tree 301afce1 or 301afce1^1 though. I'd
guess that's significant, but I don't know what answer it suggests...
(However the file exists in both (stable) and (experimental)...
and is identical in both).
> You can reproduce exactly the merge by making a new branch at the
> position where you were attempting to land the cherry pick before, and
> checking that branch out.
I actually did
$ cd ..
$ git clone repo/ repo_backup_4Jan
beforehand, so this should also be an exact reproduction, I think?
> One last test, would be to check that it happens on a clean clone of the
> repository. I don't think that you're hitting any repository-local
> behaviour (eg, the ability to mark certain files as "always ignore") but
> you never know. These commands are all being run on the same working
> copy, right?
And see above, should be an entirely clean clone.
Thanks for the suggestions!
Hakim / osfameron
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Johannes Schindelin @ 2010-01-06 11:29 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20100106191825.6117@nanako3.lavabit.com>
Hi,
On Wed, 6 Jan 2010, Nanako Shiraishi wrote:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 23ded48..d42cc4f 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -482,6 +482,25 @@ get_saved_options () {
> test -f "$DOTEST"/rebase-root && REBASE_ROOT=t
> }
>
> +LF='
> +'
> +parse_onto () {
> + if expr "$1" : '.*\.\.\.' >/dev/null &&
> + left=${1%...*} right=${1#*...} &&
> + : ${left:=HEAD} ${right:=HEAD} &&
> + onto=$(git merge-base "$left" "$right")
> + then
> + case "$onto" in
> + ?*"$LF"?* | '')
> + exit 1 ;;
> + esac
> + echo "$onto"
> + exit 0
> + else
> + git rev-parse --verify "$1^0"
> + fi
> +}
It might be easier to understand like this:
case "$1" in
*...*)
left=${1%...*} &&
right=${1#*...} &&
onto="$(git merge-base "${left:-HEAD}" "${right:-HEAD}")" &&
test ! -z "$onto" &&
echo "$onto"
;;
*)
git rev-parse --verify "$1^0"
;;
esac
Besides, why do you change the "$1" to "$1^0"?
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 6503113..43c62c0 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
I would separate the patches. rebase.sh and rebase--interactive.sh are
fundamentally different.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH v3 5/6] transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
From: Jeff King @ 2010-01-06 12:04 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Shawn O. Pearce, Daniel Barkalow, Junio C Hamano
In-Reply-To: <20100105180113.6e0572dc.rctay89@gmail.com>
On Tue, Jan 05, 2010 at 06:01:13PM +0800, Tay Ray Chuan wrote:
> > It seems like this should be checking for REF_STATUS_NONE explicitly
> > instead of trying to enumerate the reasons we might not have tried to
> > push. Shouldn't helpers _only_ be pushing REF_STATUS_NONE refs?
> >
> > I think right now the two cases are equivalent, since non-ff and
> > uptodate are the only two states set before the helper is invoked. But
> > we have discussed in the past (and I still have a patch floating around
> > for) a REF_STATUS_REWIND which would treat strict rewinds differently
> > (silently ignoring them instead of making an error). Explicitly checking
> > REF_STATUS_NONE future-proofs against new states being added.
>
> I'm not really sure if this is true (ie. that if status is not non-ff
> or uptodate, then it is REF_STATUS_NONE), but we could step around this
Well, consider it this way. If it's _not_ REF_STATUS_NONE, then what is
it, and what does it mean to be overwriting it?
Maybe I am misunderstanding the problem the patch is addressing, but the
point of these REF_STATUS feels was to act as a small state machine.
Everything starts as NONE, and then:
- we compare locally against remote refs. We may transition:
NONE -> UPTODATE
NONE -> REJECT_NONFASTFORWARD
NONE -> REJECT_NODELETE
- we send the push list
NONE -> EXPECTING_REPORT (if the remote supports individual status)
NONE -> OK (otherwise)
- we get back status responses
EXPECTING_REPORT -> OK
EXPECTING_REPORT -> REMOTE_REJECT
I haven't looked closely at the new transport helper code, but I would
think it should stick more or less to those transitions. The exception
would be that some transports don't necessarily handle EXPECTING_REPORT
in the same way, and may transition directly from NONE to
OK/REMOTE_REJECT.
So offhand, I would say that your list should also probably include
REJECT_NODELETE. However, I think that status is just for old servers
which didn't support the delete-refs protocol extension. So presumably
that is none of the new helpers, as they all post-date the addition of
that feature by quite a few years.
> by introducing a property, say, ref->should_push, that is set to 1,
> after all the vetting has been carried out and just before we talk to
> the server.
I'd rather not introduce new state. The point of the status flag was to
encapsulate all of that information, and a new state variable just seems
like introducing extra complexity. If we are not in the NONE state, I
don't see why we would tell the helper about a ref at all.
-Peff
^ permalink raw reply
* Re: [PATCH] bash completion: add space between branch name and status flags
From: Roman Fietze @ 2010-01-06 11:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nanako Shiraishi, Junio C Hamano, git
In-Reply-To: <20091230145751.GE6914@spearce.org>
Hello Shawn,
On Wednesday 30 December 2009 15:57:51 Shawn O. Pearce wrote:
> ... but Roman Fietze didn't send
> a revised patch, so it got dropped
Sorry about that, but our Notes "spam filter" has been eating
important mail again.
I'l check the version as proposed by you as soon as I'm back.
Roman
--
Roman Fietze Telemotive AG Büro Mühlhausen
Breitwiesen 73347 Mühlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* Re: [PATCH v3 2/6] t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
From: Jeff King @ 2010-01-06 12:05 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Shawn O. Pearce, Daniel Barkalow, Junio C Hamano
In-Reply-To: <20100105180132.e573fff2.rctay89@gmail.com>
On Tue, Jan 05, 2010 at 06:01:32PM +0800, Tay Ray Chuan wrote:
> > I don't understand what you're testing here. If it's not matched, then
> > how is it a non-fast-forward? Isn't it simply unmatched?
>
> Let me rephrase this as:
>
> Some refs can only be matched to a remote ref with an explicit
> refspec. When such a ref is a non-fast-forward of its remote ref,
> test that pushing them (with the explicit refspec specified) fails
> with a non-fast-foward-type error.
Thanks, that makes sense to me now.
-Peff
^ permalink raw reply
* Re: "git add -i" with path gives "Argument list too long"
From: Jeff King @ 2010-01-06 12:19 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, git
In-Reply-To: <AAABEE5B-0419-4344-86E2-7EB550CCFC01@wincent.com>
On Tue, Jan 05, 2010 at 01:34:32PM +0100, Wincent Colaiuta wrote:
> >but note that the pathspecs given to ls-files and the path limiters
> >given to diff are not quite the same. So "git add -i '*.c'" will
> >currently find "subdir/foo.c", but would not with the above patch. Is
> >that what you meant when you said "recurse into directories"?
>
> In my relative ignorance of the finer details here, I meant that I
> would want "diff-index" to give us the exact same set of blobs as we
> get from "ls-files", so as to fix the error without modifying the
> user visible behavior.
>
> As I said, I personally wouldn't be impacted by the change in
> behavior that your patch produces, but maybe others might.
I also don't care about the globbing feature, though I suppose some
people do. However, I'm not sure add's behavior is all that sensible
now. Interactive add respects the globs, but regular add does not.
Worse, it seems that it notes that the pathspec is a wildcard and does
not even flag an error for failing to find any files. For example:
$ git init
$ echo content >foo.c
$ mkdir subdir && echo content >subdir/bar.c
$ git add .
$ echo change >foo.c && echo change >subdir/bar.c
$ git diff --name-only
foo.c
subdir/bar.c
$ git add foobar ;# should barf, and does
fatal: pathspec 'foobar' did not match any files
$ git add '*.c' ;# does not barf, but does not respect wildcard
$ git diff --name-only
foo.c
subdir/bar.c
$ yes | git add -p '*.c' ;# respects glob
$ git diff --name-only ;# empty
So it's an consistency that should probably be fixed. And of course it
is tempting to fix it by disabling the globs for the interactive case,
which would not involve writing any new code. ;) But I don't think it is
a good idea to punish people by taking away their feature in the name of
consistency.
-Peff
^ permalink raw reply
* Re: Trouble with 'make prefix=/usr info'
From: Craig Moore @ 2010-01-06 12:32 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B310054.4060900@drmicha.warpmail.net>
2009/12/22 Michael J Gruber <git@drmicha.warpmail.net>:
> Craig Moore venit, vidit, dixit 22.12.2009 17:14:
>> 2009/12/22 Michael J Gruber <git@drmicha.warpmail.net>:
>>> Craig Moore venit, vidit, dixit 22.12.2009 16:50:
>>>> Hi,
>>>>
>>>> I'm getting the following error when I make the info target:
>>>>
>>>> $ make prefix=/usr info
>>>> make -C Documentation info
>>>> make[1]: Entering directory `/local/software/git-1.6.5.7/Documentation'
>>>> make[2]: Entering directory `/local/software/git-1.6.5.7'
>>>> make[2]: `GIT-VERSION-FILE' is up to date.
>>>> make[2]: Leaving directory `/local/software/git-1.6.5.7'
>>>> DB2TEXI user-manual.texi
>>>> Usage: jw [<options>] <sgml_file>
>>>> where <options> are:
>>>> -f|--frontend <frontend>: Specify the frontend (source format)
>>>> (default is docbook)
>>>> -b|--backend <backend>: Specify the backend (destination format)
>>>> (default is html)
>>>> -c|--cat <file>: Specify an extra SGML open catalog
>>>> -n|--nostd: Do not use the standard SGML open catalogs
>>>> -d|--dsl <file>|default|none: Specify an alternate style sheet
>>>> (default is to use the default stylesheet)
>>>> -l|--dcl <file>: Specify an alternate SGML declaration
>>>> (usual ones like xml.dcl get detected
>>>> automatically)
>>>> -s|--sgmlbase <path>: Change base directory for SGML distribution
>>>> (usually /usr/share/sgml)
>>>> -p|--parser <program>: Specify the parser if several are installed
>>>> (jade or openjade)
>>>> -o|--output <directory>: Set output directory
>>>> -u|--nochunks: Output only one big file
>>>> (overrides the stylesheet settings)
>>>> -i|--include <section>: Specify a SGML marked section to include
>>>> (should be marked as "ignore" in the SGML text)
>>>> -w|--warning <warning_type>|list: Control warnings or display the allowed
>>>> warning types
>>>> -e|--errors <error_type>|list: Control errors or display the allowed error types
>>>> -h|--help: Print this help message and exit
>>>> -V <variable[=value]>: Set a variable
>>>> -v|--version: Print the version and exit
>>>> make[1]: *** [user-manual.texi] Error 1
>>>> make[1]: Leaving directory `/local/software/git-1.6.5.7/Documentation'
>>>> make: *** [info] Error 2
>>>>
>>>> I can see that the error is likely related to the fact that it enters the
>>>> Documentation directing, then exits the Documentation directory, and then tries
>>>> to build the user-manual.texi file in the root directory (however, that file is
>>>> in the Documentation directory, which it just left). I've tried to track down
>>>> and change where it exits the Documentation directory, but I've had no success.
>>>>
>>>> I would appreciate any recommendations you might have. I've already been able to
>>>> install git, but I couldn't install the 'info' target because of this error.
>>>
>>> Does it work without prefix?
>>> Also, you may want to cd into Documentation and try to make there.
>>>
>>> Michael
>>>
>>>
>>
>> Hey Michael,
>>
>> Here is what happens when I run it inside the Documentation directory
>> (without the prefix):
>>
>> user@server: /local/software/git-1.6.5.7/Documentation
>> $ make info
>> SUBDIR ../
>> make[1]: `GIT-VERSION-FILE' is up to date.
>> DB2TEXI user-manual.texi
>> Usage: jw [<options>] <sgml_file>
>> where <options> are:
>> -f|--frontend <frontend>: Specify the frontend (source format)
>> (default is docbook)
>> -b|--backend <backend>: Specify the backend (destination format)
>> (default is html)
>> -c|--cat <file>: Specify an extra SGML open catalog
>> -n|--nostd: Do not use the standard SGML open catalogs
>> -d|--dsl <file>|default|none: Specify an alternate style sheet
>> (default is to use the default stylesheet)
>> -l|--dcl <file>: Specify an alternate SGML declaration
>> (usual ones like xml.dcl get detected
>> automatically)
>> -s|--sgmlbase <path>: Change base directory for SGML distribution
>> (usually /usr/share/sgml)
>> -p|--parser <program>: Specify the parser if several are installed
>> (jade or openjade)
>> -o|--output <directory>: Set output directory
>> -u|--nochunks: Output only one big file
>> (overrides the stylesheet settings)
>> -i|--include <section>: Specify a SGML marked section to include
>> (should be marked as "ignore" in the SGML text)
>> -w|--warning <warning_type>|list: Control warnings or display the
>> allowed warning types
>> -e|--errors <error_type>|list: Control errors or display the allowed
>> error types
>> -h|--help: Print this help message and exit
>> -V <variable[=value]>: Set a variable
>> -v|--version: Print the version and exit
>> make: *** [user-manual.texi] Error 1
>>
>> The first thing it does is go to the directory above, weird.
>>
>> Craig
>
> I think it only looks like that. SUBDIR processing is finished at that
> point, and the DB2TEXI line is where user-manual.texi is actually being
> processed, and that's what's causing the error. Did you set the texinfo
> processor in the Makefile or using variables?
>
> V=1 make info
>
> will show you the exact commands being executed.
>
> Michael
>
Michael, thanks for your reply, and happy 2010. I'm back in the
office, and here's what is returned when I execute the command:
================================
$ V=1 make info
make -C Documentation info
make[1]: Entering directory `/local/software/git-1.6.5.7/Documentation'
make -C ../ GIT-VERSION-FILE
make[2]: Entering directory `/local/software/git-1.6.5.7'
make[2]: `GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory `/local/software/git-1.6.5.7'
rm -f user-manual.texi+ user-manual.texi && \
docbook2x-texi user-manual.xml --encoding=UTF-8 --to-stdout
>user-manual.texi++ && \
/usr/bin/perl fix-texi.perl <user-manual.texi++ >user-manual.texi+ && \
rm user-manual.texi++ && \
mv user-manual.texi+ user-manual.texi
Usage: jw [<options>] <sgml_file>
where <options> are:
-f|--frontend <frontend>: Specify the frontend (source format)
(default is docbook)
-b|--backend <backend>: Specify the backend (destination format)
(default is html)
-c|--cat <file>: Specify an extra SGML open catalog
-n|--nostd: Do not use the standard SGML open catalogs
-d|--dsl <file>|default|none: Specify an alternate style sheet
(default is to use the default stylesheet)
-l|--dcl <file>: Specify an alternate SGML declaration
(usual ones like xml.dcl get detected
automatically)
-s|--sgmlbase <path>: Change base directory for SGML distribution
(usually /usr/share/sgml)
-p|--parser <program>: Specify the parser if several are installed
(jade or openjade)
-o|--output <directory>: Set output directory
-u|--nochunks: Output only one big file
(overrides the stylesheet settings)
-i|--include <section>: Specify a SGML marked section to include
(should be marked as "ignore" in the SGML text)
-w|--warning <warning_type>|list: Control warnings or display the
allowed warning types
-e|--errors <error_type>|list: Control errors or display the allowed
error types
-h|--help: Print this help message and exit
-V <variable[=value]>: Set a variable
-v|--version: Print the version and exit
make[1]: *** [user-manual.texi] Error 1
make[1]: Leaving directory `/local/software/git-1.6.5.7/Documentation'
make: *** [info] Error 2
================================
I've isolated the problem, and its coming from this command:
================================
$ docbook2x-texi user-manual.xml --encoding=UTF-8 --to-stdout
>user-manual.texi++
Usage: jw [<options>] <sgml_file>
where <options> are:
-f|--frontend <frontend>: Specify the frontend (source format)
(default is docbook)
-b|--backend <backend>: Specify the backend (destination format)
(default is html)
-c|--cat <file>: Specify an extra SGML open catalog
-n|--nostd: Do not use the standard SGML open catalogs
-d|--dsl <file>|default|none: Specify an alternate style sheet
(default is to use the default stylesheet)
-l|--dcl <file>: Specify an alternate SGML declaration
(usual ones like xml.dcl get detected
automatically)
-s|--sgmlbase <path>: Change base directory for SGML distribution
(usually /usr/share/sgml)
-p|--parser <program>: Specify the parser if several are installed
(jade or openjade)
-o|--output <directory>: Set output directory
-u|--nochunks: Output only one big file
(overrides the stylesheet settings)
-i|--include <section>: Specify a SGML marked section to include
(should be marked as "ignore" in the SGML text)
-w|--warning <warning_type>|list: Control warnings or display the
allowed warning types
-e|--errors <error_type>|list: Control errors or display the allowed
error types
-h|--help: Print this help message and exit
-V <variable[=value]>: Set a variable
-v|--version: Print the version and exit
$ docbook2x-texi --version
DocBook-utils version 0.6.14 (jw version 1.1)
================================
As you can see, I'm using DocBook-utils version 0.6.14 (jw version
1.1), and it doesn't list '--encoding=UTF-8 --to-stdout' in its
options list. I'm guessing I've got the wrong version or type
installed? Is there another which I should be using?
Thanks for your help,
Craig
^ permalink raw reply
* [RFC/PATCH] commit: make the error message on unmerged entries user-friendly.
From: Matthieu Moy @ 2010-01-06 13:10 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
The error message used to look like this:
$ git commit
foo.txt: needs merge
foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
error: Error building trees
The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
option to make the output more consistant with the other porcelain
commands, and catch the error in return, to stop with a clean error
message. The next lines were displayed by a call to cache_tree_update(),
which is not reached anymore if we noticed the conflict.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
As usual, I try to have error messages point to the solution, not just
the origin of the problem.
Two questions:
* Did anyone actually use the 3 "file: unmerged (sha1)" lines?
* Do you like my new message?
Thanks,
builtin-commit.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 3dfcd77..d491a01 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -235,6 +235,18 @@ static void create_base_index(void)
exit(128); /* We've already reported the error, finish dying */
}
+static void refresh_cache_or_die(int refresh_flags)
+{
+ /*
+ * refresh_flags contains REFRESH_QUIET, so the only errors
+ * are for unmerged entries.
+ */
+ if(refresh_cache(refresh_flags | REFRESH_IN_PORCELAIN))
+ die("Commit is not possible because you have unmerged files.\n"
+ "Please, resolve the conflicts listed above, and then mark them\n"
+ "as resolved with 'git add <filename>', or use 'git commit -a'.");
+}
+
static char *prepare_index(int argc, const char **argv, const char *prefix, int is_status)
{
int fd;
@@ -274,7 +286,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
if (all || (also && pathspec && *pathspec)) {
int fd = hold_locked_index(&index_lock, 1);
add_files_to_cache(also ? prefix : NULL, pathspec, 0);
- refresh_cache(refresh_flags);
+ refresh_cache_or_die(refresh_flags);
if (write_cache(fd, active_cache, active_nr) ||
close_lock_file(&index_lock))
die("unable to write new_index file");
@@ -293,7 +305,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
*/
if (!pathspec || !*pathspec) {
fd = hold_locked_index(&index_lock, 1);
- refresh_cache(refresh_flags);
+ refresh_cache_or_die(refresh_flags);
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(&index_lock))
die("unable to write new_index file");
--
1.6.6.76.gd6b23.dirty
^ permalink raw reply related
* GIT_DIR=. for hooks?
From: Michael J Gruber @ 2010-01-06 13:55 UTC (permalink / raw)
To: Git Mailing List
Hi there,
as it seems hooks (at least post-receive) are called with a $PWD in the
.git dir and GIT_DIR=. exported.
Now, that leads to problems when, say, diffing between the index and the
worktree ("Don't do that!", I know). Without cd'ing around, the worktree
is not found, and after "cd ..", the git-dir is not found.
I can unset GIT_DIR or set WORK_TREE, of course, but I'm wondering
whether GIT_DIR=. is a sane setting at all: a git-dir in $PWD is always
found, and when cd'ing away that setting does not help either.
Michael
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Jens Lehmann @ 2010-01-06 14:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Git Mailing List, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <7vbph8oxg0.fsf@alter.siamese.dyndns.org>
Am 06.01.2010 02:04, schrieb Junio C Hamano:
> After all we _were_ in agreement. We both think the user should be told
> about untracked files in submodule directory when inspecting the status to
> make a commit in the superproject.
Thanks. So i'll take a closer look at the diff core (but i suspect i'll
need some time until i can come up with some patches because i don't know
this part of git very well).
^ permalink raw reply
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Junio C Hamano @ 2010-01-06 16:58 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B444FF9.1000004@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
>> Doesn't "checkout --conflict=merge" use the same ll_merge() machinery?
>
> It does, without setting up .gitattributes, either (IIUC), which is a bug IMO.
I don't think there is any bug there; git_checkattr() that is used by
git_path_check_merge() autoinitializes the attribute machinery.
However, I think you need this fix for "checkout -m" to work as intended,
if your custom merge driver has recursive attribute set to 'binary' or
something:
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 64f3a11..50f5079 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -167,7 +167,7 @@ static int checkout_merged(int pos, struct checkout *state)
fill_mm(active_cache[pos+2]->sha1, &theirs);
status = ll_merge(&result_buf, path, &ancestor,
- &ours, "ours", &theirs, "theirs", 1);
+ &ours, "ours", &theirs, "theirs", 0);
free(ancestor.ptr);
free(ours.ptr);
free(theirs.ptr);
I don't know why I decided to pass "1" to ll_merge() there; it doesn't
make any sense and looks like an untested bug to me.
The ll_merge() call jc/cache-unmerge topic adds for "rerere forget"
doesn't share this problem.
^ permalink raw reply related
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Junio C Hamano @ 2010-01-06 17:01 UTC (permalink / raw)
To: Jens Lehmann
Cc: Johannes Schindelin, Git Mailing List, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <4B4498BC.5040400@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Am 06.01.2010 02:04, schrieb Junio C Hamano:
>> After all we _were_ in agreement. We both think the user should be told
>> about untracked files in submodule directory when inspecting the status to
>> make a commit in the superproject.
>
> Thanks. So i'll take a closer look at the diff core (but i suspect i'll
> need some time until i can come up with some patches because i don't know
> this part of git very well).
I don't see a direct connection between "the user should be told about
untracked in the submodule before committing" and diffcore. It is just
the matter of "git status" and "git commit" running another instance of
"git status" via run_command() interface in the submodule directory, no?
^ permalink raw reply
* Re: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: Junio C Hamano @ 2010-01-06 17:04 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Adam Megacz, git
In-Reply-To: <20100106073806.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Adam Megacz <adam@megacz.com>
>
>> Perhaps a preference (off by default) demanding that they be set
>> explicitly when "git commit -m" is used?
>
> Sverre pointed out why this won't work.
>
>> Some people care more than others about the metadata; this is for the
>> folks to whom it matters a lot.
>
> So the only workable solution is to check your commits with "git show
> -s" until you become confident that you configured your new box
> correctly. Some people unfortunately don't care enough to do so, but it
> is for the people to whom it matters.
Traditionally, we've only had a minimal sanity check (e.g. to barf when
the name is empty, or something silly like that) and tried to come up with
a reasonable name/email given the available system information.
The approach may have been Ok 10 years ago, back when `whoami`@`hostname`,
at least on systems that were competently maintained, gave a reasonable
mail address for most people, but I don't think it is adequate anymore to
majority of people, especially the ones who work on Open Source projects
as individuals, whose desired public identities are often tied to their
email account at their ISPs or mailbox providers (like gmail), and there
is no way for us to guess what it is from `whoami` nor `hostname` [*1*].
So I don't think anybody minds if we refuse to work if we are going to end
up using a name that we didn't get from an explicit end user configuration
(i.e. GIT_*_EMAIL and GIT_*_NAME environment and user.* configuration
variables).
[Footnote]
*1* Inside corporate environments, `whoami`@`hostname -f` might still be a
reasonable and usable default, though.
^ permalink raw reply
* [RFC/PATCH] lockfile: show absolute filename in unable_to_lock_message.
From: Matthieu Moy @ 2010-01-06 17:01 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
When calling a git command from a subdirectory and a file locking fails,
the user will get a path relative to the root of the worktree, which is
invalid from the place where the command is ran. Make it easy for the
user to know which file it is.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
I'm writting this because I just got the situation with students:
- Sir, we broke our repository (git commit interrupted violently).
- See, the error message tells you what to do.
- But sir, where is .git/index.lock, we can't find it.
This patch would have solved their problem. OTOH, an absolute path can
be rather long and painfull to read/cut-and-paste. I've tried to show
a path relative to where the command was ran (like
"../../.git/index.lock"), but that's really a painfull to implement
(one has to provide a prefix argument to all the calls to
unable_to_lock_*, and even with this, I didn't find the simple way to
make the relative path (probably exists somewhere in Git since 'git
status' does this). Then I gave up :-(.
lockfile.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 6851fa5..e31cbc7 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -164,9 +164,10 @@ static char *unable_to_lock_message(const char *path, int err)
"If no other git process is currently running, this probably means a\n"
"git process crashed in this repository earlier. Make sure no other git\n"
"process is running and remove the file manually to continue.",
- path, strerror(err));
+ make_absolute_path(path), strerror(err));
} else
- strbuf_addf(&buf, "Unable to create '%s.lock': %s", path, strerror(err));
+ strbuf_addf(&buf, "Unable to create '%s.lock': %s",
+ make_absolute_path(path), strerror(err));
return strbuf_detach(&buf, NULL);
}
--
1.6.6.76.gd6b23.dirty
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Junio C Hamano @ 2010-01-06 17:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4B445312.9090507@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Junio C Hamano schrieb:
>> (1) Does "Windows style path" here mean what $(pwd) returns as opposed to
>> what is in $PWD?
>
> Yes. $PWD is of the form /c/foo/bar; pwd is a function in test-lib.sh
> that ensures it returns the form c:/foo/bar.
>
>> (2) The patch reads like this:
>> ...
>> Does "strips everything past the second dq" mean "drops '/hexdump'"?
> Yes.
>
>> If so, would this also work (I am not suggesting to change it, just
>> ...
> It would work, too, but it would depend on very bogus behavior of the
> MSYS bash.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Junio C Hamano @ 2010-01-06 17:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.1001061219180.11013@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It might be easier to understand like this:
>
> case "$1" in
> *...*)
> left=${1%...*} &&
> right=${1#*...} &&
> onto="$(git merge-base "${left:-HEAD}" "${right:-HEAD}")" &&
> test ! -z "$onto" &&
> echo "$onto"
> ;;
> *)
> git rev-parse --verify "$1^0"
> ;;
> esac
Double-semicolons should be indented one level deeper.
I think your version may be slightly better (avoids one "expr"), but it
actually was much harder to read your cascade of && that implicitly exits
with non-zero status in the first case arm than the explicit exit status
given by the original patch.
As far as I can tell, both versions inherit the same bug from me when the
user gave us A...B pair that has more than one merge bases. I think you
need to give --all to merge-base and resurrect the "did we get more than
one" test from her patch.
> Besides, why do you change the "$1" to "$1^0"?
Isn't it a bugfix?
Earlier code wouldn't have caught "--onto $blob_id" as an error, but this
will do so---I actually think it is a good change.
>> diff --git a/git-rebase.sh b/git-rebase.sh
>> index 6503113..43c62c0 100755
>> --- a/git-rebase.sh
>> +++ b/git-rebase.sh
>
> I would separate the patches. rebase.sh and rebase--interactive.sh are
> fundamentally different.
I too think splitting into two patches would make sense in this case. The
patch to git-rebase.sh seems to be a bugfix in the left/right computation;
I am kind of surprised that I haven't triggered it myself so far.
Thanks.
^ permalink raw reply
* Re: [RFC/PATCH] commit: make the error message on unmerged entries user-friendly.
From: Junio C Hamano @ 2010-01-06 17:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1262783414-23101-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> The error message used to look like this:
>
> $ git commit
> foo.txt: needs merge
> foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
> foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
> foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
> error: Error building trees
>
> The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
> option to make the output more consistant with the other porcelain
> commands, and catch the error in return, to stop with a clean error
> message. The next lines were displayed by a call to cache_tree_update(),
> which is not reached anymore if we noticed the conflict.
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> As usual, I try to have error messages point to the solution, not just
> the origin of the problem.
Seems to be a sensible approach to me.
> Two questions:
>
> * Did anyone actually use the 3 "file: unmerged (sha1)" lines?
I don't think anybody does these days, and even if the question were about
the historical practice, I doubt anybody used "git merge-file" using these
blob object names to come up with a resolution. Besides, if they really
want to, they can ask "ls-files -u" for that information themselves.
> * Do you like my new message?
That would have been much easier to answer if you wrote "Here is an error
message produced with this patch" in the proposed commit log message. I
haven't applied nor read your patch carefully, but I imagine you would say
something like this?
With this patch, the error looks like this:
$ git commit
U foo.txt
fatal: Commit is not possible because you have unmerged files.
Please, resolve the conflicts listed above, and then mark them
as resolved with 'git add <filename>', or use 'git commit -a'
Do I like it? Hmmm.
- "Please, ", especially with the comma, looks superfluous;
- Some people consider "please resolve the conflicts" to mean the whole
process of "fix them up in the work tree, and mark them resolved in the
index", and others consider it to mean only the first step to "fix them
up in the work tree". I happen to be in the former camp, and to me
",and then mark them as..., add <filename>'," look superfluous because
of that.
I however think it is more helpful to new people who benefit from this
advice message if we spell out these two steps. Unfortunately, for
that purpose, the description of the latter "mark them resolved in the
index" step you have looks inadequate; e.g. sometimes it needs to be
done with "git rm <filename>".
The need to give this advice on how to resolve conflicts is shared among
commands like 'git merge', 'git cherry-pick', and 'git status', to name a
few. I think we should consolidate them all.
- Decide if we go one-step (i.e. just say "resolve conflicts" and nothing
else) or two-step (i.e. say "Fix them up in the work tree" and "mark
them resolved in the index") approach; I am leaning toward the latter.
- Decide the exact language used. I think "Fix them up in the work tree"
is passably okay, but "Mark them resolved in the index" needs to be
made more concrete, and "git add <filename>" is not quite it, I am
afraid.
- Omit issuing the advisory message when advice.resolveConflict is set to
false.
- Perhaps have a common helper function to do this from the commands that
need to give the advice.
Thanks.
^ permalink raw reply
* Re: GIT_DIR=. for hooks?
From: Junio C Hamano @ 2010-01-06 17:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4B44965F.8040803@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> I can unset GIT_DIR or set WORK_TREE, of course,
That is not just an acceptable but _the_ right way to write hooks that
touch the files in the work tree. In earlier versions of git, a git-dir
in $PWD was not found without GIT_DIR=. and hooks are supposed to work
across versions of git, so this behaviour got stuck.
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Nguyen Thai Ngoc Duy @ 2010-01-06 17:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jens Lehmann, Johannes Schindelin, Git Mailing List,
Shawn O. Pearce, Paul Mackerras, Heiko Voigt, Lars Hjemli,
Avery Pennarun
In-Reply-To: <7vbph7181x.fsf@alter.siamese.dyndns.org>
On 1/7/10, Junio C Hamano <gitster@pobox.com> wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>
> > Am 06.01.2010 02:04, schrieb Junio C Hamano:
> >> After all we _were_ in agreement. We both think the user should be told
> >> about untracked files in submodule directory when inspecting the status to
> >> make a commit in the superproject.
> >
> > Thanks. So i'll take a closer look at the diff core (but i suspect i'll
> > need some time until i can come up with some patches because i don't know
> > this part of git very well).
>
>
> I don't see a direct connection between "the user should be told about
> untracked in the submodule before committing" and diffcore. It is just
> the matter of "git status" and "git commit" running another instance of
> "git status" via run_command() interface in the submodule directory, no?
You would need to rewrite file paths so that files in submodules are
also relative to the same directory as files in supermodule (I tried
to do that with GIT_WORK_TREE and needed to change a bit). Or you
could show each "git status" output separately, which does not look as
nice as the former in my opinion.
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH] commit: make the error message on unmerged entries user-friendly.
From: Matthieu Moy @ 2010-01-06 17:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veim3yx5o.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> Two questions:
>>
>> * Did anyone actually use the 3 "file: unmerged (sha1)" lines?
>
> I don't think anybody does these days, and even if the question were about
> the historical practice, I doubt anybody used "git merge-file" using these
> blob object names to come up with a resolution. Besides, if they really
> want to, they can ask "ls-files -u" for that information themselves.
OK, that's what I thought, but 'wanted to be sure.
>I imagine you would say
> something like this?
>
> With this patch, the error looks like this:
>
> $ git commit
> U foo.txt
> fatal: Commit is not possible because you have unmerged files.
> Please, resolve the conflicts listed above, and then mark them
> as resolved with 'git add <filename>', or use 'git commit -a'
Yes, sorry for not making it more explicit.
> Do I like it? Hmmm.
>
> - "Please, ", especially with the comma, looks superfluous;
I wouldn't call it mandatory, but it doesn't harm, and
$ grep -i -n -e '"Please' *.c
builtin-commit.c:246: "Please, resolve the conflicts listed above, and then mark them\n"
builtin-commit.c:698: "Please supply the message using either -m or -F option.\n");
builtin-help.c:209: "Please consider using 'man.<tool>.cmd' instead.",
builtin-help.c:221: "Please consider using 'man.<tool>.path' instead.",
builtin-remote.c:1124: "Please choose one explicitly with:");
builtin-tag.c:321: "Please supply the message using either -m or -F option.\n");
merge-recursive.c:1191: "Please, commit your changes or stash them before you can merge.";
setup.c:241: warning("Please upgrade Git");
> - Some people consider "please resolve the conflicts" to mean the whole
> process of "fix them up in the work tree, and mark them resolved in the
> index", and others consider it to mean only the first step to "fix them
> up in the work tree". I happen to be in the former camp, and to me
> ",and then mark them as..., add <filename>'," look superfluous because
> of that.
>
> I however think it is more helpful to new people who benefit from this
> advice message if we spell out these two steps.
Yes. Someone having "resolved" (i.e. removed markers), and trying to
commit should get a hint on the commands he can use to achieve this
goal.
> Unfortunately, for that purpose, the description of the latter
> "mark them resolved in the index" step you have looks inadequate;
> e.g. sometimes it needs to be done with "git rm <filename>".
Maybe "sometimes", but to me, that's sufficiently rare to be omited
here (I don't think I ever used 'git rm' to resolve a conflict). The
user manual says this:
,----
| Each time you resolve the conflicts in a file and update the index:
|
| $ git add file.txt
|
| the different stages of that file will be "collapsed", after which git
| diff will (by default) no longer show diffs for that file.
`----
and I don't think it makes sense to try to be more exhaustive here
than in the user-manual.
> The need to give this advice on how to resolve conflicts is shared among
> commands like 'git merge', 'git cherry-pick', and 'git status', to name a
> few.
Not sure 'status' needs anything more. It already says
# Unmerged paths:
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: foo.txt
and the big difference between 'git status' and the others is that
it's legitimate to run it while resolving conflicts, while calling
'git merge' or 'git commit' can be done only by mistake.
It's not serious to eat 3 or 4 lines of the screen to display a
message to tell the user he shouldn't have done this, but it'd be
disturbing to eat more than 1 line for a common case.
> I think we should consolidate them all.
Right, although "commit" is definitely the most important (dumb users
don't need "git merge").
> - Decide if we go one-step (i.e. just say "resolve conflicts" and nothing
> else) or two-step (i.e. say "Fix them up in the work tree" and "mark
> them resolved in the index") approach; I am leaning toward the latter.
Meetoo.
> - Decide the exact language used. I think "Fix them up in the work tree"
> is passably okay, but "Mark them resolved in the index" needs to be
> made more concrete, and "git add <filename>" is not quite it, I am
> afraid.
See above. To me, pointing to "git commit -a" and "git add" is
sufficient.
Pointing to "git commit -a" is also important to me, because Git
newbies may have been told to always use "git commit" with "-a"
(common use-case: "I have to use Git, I know SVN and I don't want to
learn anything new").
> - Omit issuing the advisory message when advice.resolveConflict is set to
> false.
Sensible, yes.
> - Perhaps have a common helper function to do this from the commands that
> need to give the advice.
Probably not, because the advice will be different:
git merge => please resolve and commit before you can merge
git commit => please resolve before you can commit
...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ 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