* Re: [RFC/PATCH] lockfile: show absolute filename in unable_to_lock_message.
From: Johannes Sixt @ 2010-01-06 18:50 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1262797288-23004-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy schrieb:
> - 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));
Since these are merely informative, wouldn't it be more suitable to use
make_nonrelative_path()?
-- Hannes
^ 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 18:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyen Thai Ngoc Duy, Johannes Schindelin, Git Mailing List,
Shawn O. Pearce, Paul Mackerras, Heiko Voigt, Lars Hjemli,
Avery Pennarun
In-Reply-To: <7vljgbw21x.fsf@alter.siamese.dyndns.org>
Am 06.01.2010 18:55, schrieb Junio C Hamano:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> 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.
>
> You could show output separately if you want, but I think that is a
> separate issue.
>
> I was envisioning that the "git status" in submodule will be run with its
> recent --porcelain option, and "git status" or "git commit" would read it
> to postprocess and incorporate into its own output.
And i thought about printing just one line for each dirty submodule that
contains uncommitted and/or new files. I did not intend to list every
file, for the same reason a "git diff --submodule" only shows the first
line of the commit messages, not the actual differences of all changed
files in the submodule. I am not against being able to show all files
too, but i really would want to have an option to get a short output for
git gui and gitk.
^ permalink raw reply
* Re: gc.auto bug in 1.6.5.7
From: Brandon Casey @ 2010-01-06 18:31 UTC (permalink / raw)
To: Jon Nelson; +Cc: git
In-Reply-To: <cccedfc61001060959h72a07eb6g78f2ca231867df63@mail.gmail.com>
Jon Nelson wrote:
> It would appear that there is a bug in git, at least as of 1.6.5.7, in
> the gc command.
> When gc.auto is non-zero, it appears to consider packfiles as "loose"
> - this conflicts with pack.packSizeLimit, insofar as I have
> pack.packSizeLimit set to 2M (which appears to work). If gc.auto is,
> say, 50 - once I exceed 50 2MB packs then gc --auto repacks *every
> single time* it is run. This is unexpected, at least.
There is also a gc.autopacklimit which controls auto-gc'ing based on
the number of packs. The default is 50 and it does not consider the
pack.packSizeLimit setting when deciding whether or not to auto-gc.
It can be raised, or it can be disabled by setting it to zero.
The ideal number of packs is one, but if you limit the size of packs
to be very small, then you will quickly grow the number of packs.
Perhaps autogc should only count packs that are much smaller than
pack.packSizeLimit? Looks like there is already a comment in
builtin-gc.c suggesting something similar.
-brandon
^ 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 18:22 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: <7vljgbw21x.fsf@alter.siamese.dyndns.org>
On 1/7/10, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> > 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.
>
>
> You could show output separately if you want, but I think that is a
> separate issue.
>
> I was envisioning that the "git status" in submodule will be run with its
> recent --porcelain option, and "git status" or "git commit" would read it
> to postprocess and incorporate into its own output.
Nice option! I had to call a few "git diff" for that just because I
did not catch up with recent Git development :-(
--
Duy
^ 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 18:20 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: <7vbph7181x.fsf@alter.siamese.dyndns.org>
Am 06.01.2010 18:01, schrieb Junio C Hamano:
> 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?
Basically yes. But i also would like to teach "git diff" (when diffing
against the working directory of the superproject) to show these
submodule states too so that git gui and gitk will display them.
^ permalink raw reply
* Re: [PATCH v2] Makefile: make ppc/sha1ppc.o depend on GIT-CFLAGS
From: Nicolas Pitre @ 2010-01-06 18:17 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git, Nanako Shiraishi
In-Reply-To: <20100106063759.GA882@progeny.tock>
On Wed, 6 Jan 2010, Jonathan Nieder wrote:
> The %.o: %.S pattern rule should depend on GIT-CFLAGS to avoid
> trouble when ALL_CFLAGS changes.
>
> The pattern only applies to one file (ppc/sha1ppc.S) and that
> file does not use any #ifdefs, so leaving the dependency out is
> probably harmless. Nevertheless, it is safer to include the
> dependency in case future code's behavior does depend on the
> build flags.
Is the PPC SHA1 code still needed? Is it actually ever used?
We have block-sha1/* which is already about just as fast if not faster
on most targets. So I'd simply remove the ppc directory and its content
which is the only remaining platform specific assembly code in the
source tree.
Nicolas
^ permalink raw reply
* Re: [RFC/PATCH] commit: make the error message on unmerged entries user-friendly.
From: Junio C Hamano @ 2010-01-06 18:15 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqtyuz86ny.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> 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.
I tend to disagree. The user-manual, as it currently stands, is an
introductory document that covers the concepts and the surface of git.
It's purpose is not to replace the main manual, but to give the necessary
foundation _before_ people read the 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
This message was exactly what I was getting at. The message in the
parentheses is what I called "advice". As I was suggesting to share the
advice messages used by commands that deal with mergy situations (like the
one you added in your patch), looking at existing examples to find the
best one and using that in other places would be the most effective
approach. That one line we see above is concise and does mention "rm" as
well. Why not use it?
>> I think we should consolidate them all.
>
> Right, although "commit" is definitely the most important (dumb users
> don't need "git merge").
Your "dumb users" don't get the unmerged error from commit, either, if
they don't need "git merge".
^ permalink raw reply
* gc.auto bug in 1.6.5.7
From: Jon Nelson @ 2010-01-06 17:59 UTC (permalink / raw)
To: git
It would appear that there is a bug in git, at least as of 1.6.5.7, in
the gc command.
When gc.auto is non-zero, it appears to consider packfiles as "loose"
- this conflicts with pack.packSizeLimit, insofar as I have
pack.packSizeLimit set to 2M (which appears to work). If gc.auto is,
say, 50 - once I exceed 50 2MB packs then gc --auto repacks *every
single time* it is run. This is unexpected, at least.
--
Jon
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Junio C Hamano @ 2010-01-06 17:55 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jens Lehmann, Johannes Schindelin, Git Mailing List,
Shawn O. Pearce, Paul Mackerras, Heiko Voigt, Lars Hjemli,
Avery Pennarun
In-Reply-To: <fcaeb9bf1001060923m6559f00bp794bb5fdd4af704c@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 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.
You could show output separately if you want, but I think that is a
separate issue.
I was envisioning that the "git status" in submodule will be run with its
recent --porcelain option, and "git status" or "git commit" would read it
to postprocess and incorporate into its own output.
^ 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
* 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: 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: [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: 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: 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
* [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: 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
* 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: [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: 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
* 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
* [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
* 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
* 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: [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
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