* Re: [PATCH 2/3] grep: Fix two memory leaks
From: Dan McGee @ 2010-01-30 15:45 UTC (permalink / raw)
To: git
In-Reply-To: <1264866178-12048-1-git-send-email-dpmcgee@gmail.com>
On Sat, Jan 30, 2010 at 9:42 AM, Dan McGee <dpmcgee@gmail.com> wrote:
> We duplicate the grep_opt structure when using grep threads, but didn't
> later free either the patterns attached to this new structure or the
> structure itself.
>
> Signed-off-by: Dan McGee <dpmcgee@gmail.com>
> ---
> Found these with valgrind.
Ignore the misleading numbers in the subject, there isn't more to see
here...whoops.
-Dan
^ permalink raw reply
* [PATCH] rebase: don't invoke the pager for each commit summary
From: Markus Heidelberg @ 2010-01-30 16:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Stephen Boyd, Markus Heidelberg
This regression was introduced by commit 0aa958d (rebase: replace
antiquated sed invocation, 2010-01-24), which changed the invocation of
"git rev-list | sed" to "git log".
It can be reproduced by something like this:
$ git rebase -s recursive origin/master
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
git-rebase.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index b5d9178..fb4fef7 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -86,7 +86,7 @@ continue_merge () {
fi
fi
test -z "$GIT_QUIET" &&
- git log --format=%s -1 "$cmt"
+ GIT_PAGER='' git log --format=%s -1 "$cmt"
prev_head=`git rev-parse HEAD^0`
# save the resulting commit so we can read-tree on it later
--
1.7.0.rc0.71.g95b6e
^ permalink raw reply related
* Re: v1.7.0-rc0 shows lots of "unable to find <sha1>" on git-stash
From: Jonathan del Strother @ 2010-01-30 16:36 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4B643DEF.8010809@web.de>
On 30 January 2010 14:10, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 30.01.2010 14:23, schrieb Jonathan del Strother:
>> On 30 January 2010 12:31, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>>> I assume you have one or more submodules, maybe even with untracked
>>> or yet uncommitted modified files in your tree? If so, what does git
>>> status say in the superproject and in the submodule(s)?
>>
>> Yep, I have 10 submodules. However, they're all completely clean with
>> no tracked or untracked changes shown in git status. Anything else I
>> can investigate?
>
> The change in behavior my patch introduced is that "git status" is
> called inside each submodule. So i would expect getting the same
> errors when using this command:
> git submodule foreach git status -s
>
> It should just show
> Entering '<submodule 1>'
> Entering '<submodule 2>'
> Entering '<submodule 3>'
> Entering '<submodule 4>'
> Entering '<submodule 5>'
> Entering '<submodule 6>'
> Entering '<submodule 7>'
> Entering '<submodule 8>'
> Entering '<submodule 9>'
> Entering '<submodule 10>'
> when the submodules are not dirty. What do you get?
>
Correct - I just get that output.
^ permalink raw reply
* Re: [PATCH] rebase: don't invoke the pager for each commit summary
From: Johannes Schindelin @ 2010-01-30 16:47 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: Junio C Hamano, git, Stephen Boyd
In-Reply-To: <1264868617-18547-1-git-send-email-markus.heidelberg@web.de>
Hi,
On Sat, 30 Jan 2010, Markus Heidelberg wrote:
> diff --git a/git-rebase.sh b/git-rebase.sh
> index b5d9178..fb4fef7 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -86,7 +86,7 @@ continue_merge () {
> fi
> fi
> test -z "$GIT_QUIET" &&
> - git log --format=%s -1 "$cmt"
> + GIT_PAGER='' git log --format=%s -1 "$cmt"
Would it not be better 'git --no-pager log [...]'?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] run-command.c: fix build warnings on Ubuntu
From: Markus Heidelberg @ 2010-01-30 16:43 UTC (permalink / raw)
To: Michael Wookey; +Cc: Git Mailing List
In-Reply-To: <d2e97e801001291438k21a652cakb05ec34fc8bee227@mail.gmail.com>
Michael Wookey, 2010-01-29:
> Building git on Ubuntu 9.10 warns that the return value of write(2)
> isn't checked.
>
> GCC details:
>
> $ gcc --version
> gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
>
> Silence the warnings by reading (but not making use of) the return value
> of write(2).
Since a few weeks I get several warnings about fwrite(), currently 28
times this:
warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
gcc (Gentoo 4.3.4 p1.0, pie-10.1.5) 4.3.4
Not sure if it should be muted, that are really many places.
Markus
^ permalink raw reply
* Re: [PATCH] rebase: don't invoke the pager for each commit summary
From: Markus Heidelberg @ 2010-01-30 16:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Stephen Boyd
In-Reply-To: <alpine.DEB.1.00.1001301746200.4985@pacific.mpi-cbg.de>
Johannes Schindelin, 2010-01-30:
> Hi,
>
> On Sat, 30 Jan 2010, Markus Heidelberg wrote:
>
> > diff --git a/git-rebase.sh b/git-rebase.sh
> > index b5d9178..fb4fef7 100755
> > --- a/git-rebase.sh
> > +++ b/git-rebase.sh
> > @@ -86,7 +86,7 @@ continue_merge () {
> > fi
> > fi
> > test -z "$GIT_QUIET" &&
> > - git log --format=%s -1 "$cmt"
> > + GIT_PAGER='' git log --format=%s -1 "$cmt"
>
> Would it not be better 'git --no-pager log [...]'?
That was my initial fix, but then I found this in line 519:
GIT_PAGER='' git diff --stat --summary "$mb" "$onto"
and decided to keep consistency.
Don't know.
Markus
^ permalink raw reply
* Re: [PATCH] rebase: don't invoke the pager for each commit summary
From: Markus Heidelberg @ 2010-01-30 16:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Stephen Boyd
In-Reply-To: <201001301746.13620.markus.heidelberg@web.de>
Markus Heidelberg, 2010-01-30:
> Johannes Schindelin, 2010-01-30:
> > Date: Sat, 30 Jan 2010 17:47:11 +0100 (CET)
> Date: Sat, 30 Jan 2010 17:46:13 +0100
You should adjust your clock :)
Markus
^ permalink raw reply
* FEATURE REQUEST: Allow SSH style URLS (with extra colon)
From: Jari Aalto @ 2010-01-30 16:57 UTC (permalink / raw)
To: git
According to git-clone[1] the SSH protocol is specied as:
ssh://[user@]host.xz[:port]/path
It woudl be nice if the ":" were allowed, so that the familiar SSH style
patch notation could be used, making the spec:
ssh://[user@]host.xz[:[port]]/path
An example:
ssh://foo@examplecom:/path
|
Allowed
Jari
[1] http://www.kernel.org/pub/software/scm/git/docs/git-clone.html
^ permalink raw reply
* Re: [RFH] rpm packaging failure
From: Junio C Hamano @ 2010-01-30 17:10 UTC (permalink / raw)
To: Todd Zullinger; +Cc: git, Johan Herland, Sverre Rabbelier
In-Reply-To: <20100130151921.GM29188@inocybe.localdomain>
Todd Zullinger <tmz@pobox.com> writes:
> Junio C Hamano wrote:
>> Here is an attempt to fix it, but help is very appreciated, as I don't
>> know what the accepted way is to ship Python modules is in the RPM world.
>
> Perhaps this will work well. I only tested it on Fedora 10, but I
> believe it should work on RHEL/CentOS and most other rpm-based
> distros. We may well want to package the python bits in a subpackage,
> much as the perl modules are. Anyone have thoughts on that?
Thanks.
The files that are problematic are only infrastructure bits to support
"remote helpers written in Python" (which we don't ship at all yet).
Once we start shipping real remote helpers, separating Python bits out
into its own package would make a lot of sense. People who want to use
foreign scm helpers that happen to be written in Python would need it, and
all others don't.
But I suspect that a safer alternative at least for 1.7.0 would be to
leave these files out altogether. As I understand the current state, it
is an unused but required package dependency on Python, a downside without
an upside. Is it Ok with "remote helpers in Python" folks (I think Sverre
and Johan are principal parties), or did I miss some reason that these
need to be installed/installable, perhaps to support third party packages
that already exist?
And if the removal is the way to go for 1.7.0, is the following an Ok
approach to do that removal (this is asking an RPM help again to Todd)?
git.spec.in | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index ab224f7..ec3451a 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -112,6 +112,7 @@ rm -rf $RPM_BUILD_ROOT
make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" DESTDIR=$RPM_BUILD_ROOT \
%{path_settings} \
INSTALLDIRS=vendor install %{!?_without_docs: install-doc}
+rm -fr $RPM_BUILD_ROOT%{_libdir}/python*
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
@@ -190,6 +191,9 @@ rm -rf $RPM_BUILD_ROOT
# No files for you!
%changelog
+* Sat Jan 30 2010 Junio C Hamano <gitster@pobox.com>
+- We don't ship Python bits until a real foreign scm interface comes.
+
* Mon Feb 04 2009 David J. Mellor <dmellor@whistlingcat.com>
- fixed broken git help -w after renaming the git-core package to git.
^ permalink raw reply related
* Re: FEATURE REQUEST: Allow SSH style URLS (with extra colon)
From: Ilari Liusvaara @ 2010-01-30 17:27 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <87tyu3cyy3.fsf@jondo.cante.net>
On Sat, Jan 30, 2010 at 06:57:56PM +0200, Jari Aalto wrote:
>
> According to git-clone[1] the SSH protocol is specied as:
>
> ssh://[user@]host.xz[:port]/path
>
> It woudl be nice if the ":" were allowed, so that the familiar SSH style
> patch notation could be used, making the spec:
>
> ssh://[user@]host.xz[:[port]]/path
>
> An example:
>
> ssh://foo@examplecom:/path
> |
> Allowed
>
I would use:
ssh://[user@]host.xz[:port][:]/path
Since empty port isn't allowed, this grammar is uniquely parseable,
and would allow specifying port too (if you don't need to specify
it, you could just use the scp syntax)[1].
[1] Of course 'ssh://[user@]host.xz[:port]/~/path' works too..
-Ilari
^ permalink raw reply
* Re: [PATCH] Make NO_PTHREADS the sole thread configuration variable
From: Junio C Hamano @ 2010-01-30 17:43 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <1264814539-27209-1-git-send-email-dpmcgee@gmail.com>
Dan McGee <dpmcgee@gmail.com> writes:
> When the first piece of threaded code was introduced in commit 8ecce684, it
> came with its own THREADED_DELTA_SEARCH Makefile option. Since this time,
> more threaded code has come into the codebase and a NO_PTHREADS option has
> also been added. Get rid of the original option as the newer, more generic
> option covers everything we need.
The patch is a good change but only in the "if it were like this from day
one, things would have been much simpler" sense. It is a breakage to
existing users with customized THREADED_DELTA_SEARCH in their config.mak
files, isn't it?
If we take only the part of your patch that applies to Makefile, but
exclude the first hunk (description of THREADED_DELTA_SEARCH) and the last
hunk (the necessary part to keep THREADED_DELTA_SEARCH working), and
instead add something like:
ifndef NO_PTHREADS
THREADED_DELTA_SEARCH = YesPlease
endif
immediately before we include config.mak, would that be a workable
solution to:
(1) keep existing users happy;
(2) remove the redundant logic to compute the default for two Make
variables; and
(3) keep control over use of threading in general _and_ use of
threading in delta computation?
^ permalink raw reply
* Re: My use case
From: tytso @ 2010-01-30 17:48 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-CC0A6E.00541330012010@news.gmane.org>
On Sat, Jan 30, 2010 at 12:54:13AM -0800, Ron Garret wrote:
> Don't forget, I'm integrating this *into* the IDE, not just using it
> *for* the IDE. So I want to just have a context menu on each code
> window with "SNAPSHOT" and "ROLLBACK" items that Just Work. The casual
> user won't even know that there's git behind the scenes.
This is a workflow question, I suppose, but I find things work much
better if you can get the user to give you explicit commit boundaries
so that (a) bisect works, and (b) they can describe what each commit
does, and (c) so they can more easily move specific bug fixes or
features between different release branches. The free-form hacking
more may be nice, and very "LISP-like", but there are some real
advantages to having explicitly describable and documented commits.
Best regards,
- Ted
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-30 18:25 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-B18EFA.22250929012010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
>> Also it would be nicer (just a personal preference) if a picture that
>> forks only one branch forks it upwards, like this:
>>
>> o---o
>> /
>> ---o---o---o
>>
>> not downwards, like this:
>>
>> ---o---o---o
>> \
>> o---o
>
> Just out of curiosity, why does this matter to you?
Imagine you pick up the whole assembly and let it fall (gravity works from
top to bottom of the sheet of paper it is printed on, not from above down
to the face of paper it is printed on)? Which one looks more stable and
would land on the floor as-is?
The top one, of course. It sits better when printed, and especially so
when it is presented as an illustration that comes before a paragraph,
which is a more-or-less rectangular-looking block of text; at least it
looks that way to me.
Didn't I say it is just a "personal preference"? ;-)
^ permalink raw reply
* Re: My use case
From: Ron Garret @ 2010-01-30 18:29 UTC (permalink / raw)
To: git
In-Reply-To: <20100130174844.GD788@thunk.org>
In article <20100130174844.GD788@thunk.org>, tytso@mit.edu wrote:
> On Sat, Jan 30, 2010 at 12:54:13AM -0800, Ron Garret wrote:
> > Don't forget, I'm integrating this *into* the IDE, not just using it
> > *for* the IDE. So I want to just have a context menu on each code
> > window with "SNAPSHOT" and "ROLLBACK" items that Just Work. The casual
> > user won't even know that there's git behind the scenes.
>
> This is a workflow question, I suppose, but I find things work much
> better if you can get the user to give you explicit commit boundaries
> so that (a) bisect works, and (b) they can describe what each commit
> does, and (c) so they can more easily move specific bug fixes or
> features between different release branches. The free-form hacking
> more may be nice, and very "LISP-like", but there are some real
> advantages to having explicitly describable and documented commits.
You are absolutely right. That is another reason why having the
individual files tracked separately from the main project would be a
good thing if I can get it to work. (It would be kind of like having a
git-stash on a per-file basis.)
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-30 18:40 UTC (permalink / raw)
To: git
In-Reply-To: <20100130085957.GA20112@coredump.intra.peff.net>
In article <20100130085957.GA20112@coredump.intra.peff.net>,
Jeff King <peff@peff.net> wrote:
> I can't think of an improved message that
> would make the situation clear without adding a bunch of annoying
> text.
In situations like that a pointer to the docs, or a keyword to search on
is often sufficient.
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Junio C Hamano @ 2010-01-30 19:02 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-4F99DE.16184529012010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
>> > > If I do a git reset --hard then I get the old version, but I lose my
>> > > HEAD pointer so that git diff doesn't give me what I want any more.
I think it would be helpful to point out one issue that may hurt you (and
anybody who thinks "git update --tree" without --index is a good idea).
Keeping the index and HEAD in sync but matching the work tree files to
that of a different commit has one major downside. To git, a work tree
file that does not exist in the index is a yet-to-be-added-untracked file
(that is how and why "rm --cached file" works, for example). It won't
participate in the diff output (other than being treated as "no such file
in the work tree version").
Suppose that you used to have a path in older revision, but not in the
current revision. You remove everything from the work tree and replace it
with the files in the older revision, and you do not touch HEAD nor index.
"git diff -R" appears to show "what changed since that older version and
the latest", because it compares what is in the index relative to what is
in the work tree. Nice.
Not quite. Since the index does not know that path you recently removed,
you won't see that path. If you run "git ls-files" for a list of files
known to git, it wouldn't be shown either.
Your original "git checkout master^" is a valid and probably the optimal
way to get a checkout of a older revision (which you could feed to your
running Lisp interpreter, in addition to being able to run "less" and
"make" on them). Exactly because the index is updated to that of the
older version, you won't lose the sight of the path that you removed in a
later version, and you can review the change with "git diff -R master".
I think this is an XY problem that comes from your wanting to use "git
diff" (compare work tree with index) instead of "git diff $commit", and
that was because you wanted to use "HEAD" as a name of a commit. If you
used a branch name you originally came from, none of this desire to "keep
index intact" or "keep HEAD intact" would have been necessary.
But this is all tangent; I think you now know more about git to improve
your IDE integration, without fighting with git but instead taking
advantage of it.
^ permalink raw reply
* Re: My use case
From: Junio C Hamano @ 2010-01-30 19:07 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-A58BC7.10295430012010@news.gmane.org>
Ron Garret <ron1@flownet.com> writes:
> You are absolutely right. That is another reason why having the
> individual files tracked separately from the main project would be a
> good thing if I can get it to work. (It would be kind of like having a
> git-stash on a per-file basis.)
When you have more than one functions defined in a file, and the
interactive Lisp development cycle works primarily on s-exp basis, not
necessarily constrained by file boundaries, don't you want even finer
grained control than "stash per-file"?
I don't think of a good solution myself, but I find your "finer than whole
tree" an interesting topic.
^ permalink raw reply
* Re: My use case
From: Ron Garret @ 2010-01-30 19:19 UTC (permalink / raw)
To: git
In-Reply-To: <7vtyu3o1hq.fsf@alter.siamese.dyndns.org>
In article <7vtyu3o1hq.fsf@alter.siamese.dyndns.org>,
Junio C Hamano <gitster@pobox.com> wrote:
> Ron Garret <ron1@flownet.com> writes:
>
> > You are absolutely right. That is another reason why having the
> > individual files tracked separately from the main project would be a
> > good thing if I can get it to work. (It would be kind of like having a
> > git-stash on a per-file basis.)
>
> When you have more than one functions defined in a file, and the
> interactive Lisp development cycle works primarily on s-exp basis, not
> necessarily constrained by file boundaries, don't you want even finer
> grained control than "stash per-file"?
>
> I don't think of a good solution myself, but I find your "finer than whole
> tree" an interesting topic.
You're reading my mind. My long-term vision for this thing is indeed a
revision control system based on S-expressions, not files. (I
personally think the whole concept of files is fundamentally broken, but
that's a whole 'nuther kettle of lobster.) Unfortunately, that opens up
a Pandora's box of ancillary issues, which would be seriously off-topic
here. If you're interested we can talk about it off-line (or we can do
it here if you think it's not too much of a tangent).
rg
^ permalink raw reply
* Re: master^ is not a local branch -- huh?!?
From: Ron Garret @ 2010-01-30 19:24 UTC (permalink / raw)
To: git
In-Reply-To: <7veil7pgb2.fsf@alter.siamese.dyndns.org>
In article <7veil7pgb2.fsf@alter.siamese.dyndns.org>,
Junio C Hamano <gitster@pobox.com> wrote:
> Ron Garret <ron1@flownet.com> writes:
>
> >> > > If I do a git reset --hard then I get the old version, but I lose my
> >> > > HEAD pointer so that git diff doesn't give me what I want any more.
>
> I think it would be helpful to point out one issue that may hurt you (and
> anybody who thinks "git update --tree" without --index is a good idea).
>
> Keeping the index and HEAD in sync but matching the work tree files to
> that of a different commit has one major downside. To git, a work tree
> file that does not exist in the index is a yet-to-be-added-untracked file
> (that is how and why "rm --cached file" works, for example). It won't
> participate in the diff output (other than being treated as "no such file
> in the work tree version").
>
> Suppose that you used to have a path in older revision, but not in the
> current revision. You remove everything from the work tree and replace it
> with the files in the older revision, and you do not touch HEAD nor index.
> "git diff -R" appears to show "what changed since that older version and
> the latest", because it compares what is in the index relative to what is
> in the work tree. Nice.
>
> Not quite. Since the index does not know that path you recently removed,
> you won't see that path. If you run "git ls-files" for a list of files
> known to git, it wouldn't be shown either.
>
> Your original "git checkout master^" is a valid and probably the optimal
> way to get a checkout of a older revision (which you could feed to your
> running Lisp interpreter, in addition to being able to run "less" and
> "make" on them). Exactly because the index is updated to that of the
> older version, you won't lose the sight of the path that you removed in a
> later version, and you can review the change with "git diff -R master".
>
> I think this is an XY problem that comes from your wanting to use "git
> diff" (compare work tree with index) instead of "git diff $commit", and
> that was because you wanted to use "HEAD" as a name of a commit. If you
> used a branch name you originally came from, none of this desire to "keep
> index intact" or "keep HEAD intact" would have been necessary.
That's a very good point.
> But this is all tangent; I think you now know more about git to improve
> your IDE integration, without fighting with git but instead taking
> advantage of it.
I hope so :-)
Thanks to everyone who responded in this thread. It's been very
educational. I am very impressed at how supportive this community is to
a newcomer like me.
rg
^ permalink raw reply
* Re: [RFH] rpm packaging failure
From: Todd Zullinger @ 2010-01-30 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johan Herland, Sverre Rabbelier
In-Reply-To: <7vsk9nsemh.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]
Junio C Hamano wrote:
> The files that are problematic are only infrastructure bits to
> support "remote helpers written in Python" (which we don't ship at
> all yet).
Ahh, I hadn't followed along closely enough to know that nothing which
used these files was installed.
> And if the removal is the way to go for 1.7.0, is the following an
> Ok approach to do that removal (this is asking an RPM help again to
> Todd)?
Not shipping them if they aren't yet used/needed for anything other
than folks working on remote helpers seems reasonable and the rm in
the spec file should do the trick nicely. But I have to wonder why
even bother installing them via make install if folks packaging via
rpms, debs, etc. will all have to manually remove these files?
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have never let my schooling interfere with my education.
-- Mark Twain (1835-1910)
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: v1.7.0-rc0 shows lots of "unable to find <sha1>" on git-stash
From: Junio C Hamano @ 2010-01-30 20:01 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Jens Lehmann, Git Mailing List
In-Reply-To: <57518fd11001300836v7f21a8a9qc09953d9091a4513@mail.gmail.com>
Please try this.
The thing is that "add -u" internally runs "diff-files" equivalent, but
the code to check the submodule freshness doesn't reset the GIT_INDEX_FILE
exported from the caller and tries to use that even when checking the
submodule repository.
diff --git a/submodule.c b/submodule.c
index ca0527f..8bd0a30 100644
--- a/submodule.c
+++ b/submodule.c
@@ -126,7 +126,7 @@ int is_submodule_modified(const char *path)
"--porcelain",
NULL,
};
- char *env[3];
+ char *env[4];
struct strbuf buf = STRBUF_INIT;
strbuf_addf(&buf, "%s/.git/", path);
@@ -142,7 +142,9 @@ int is_submodule_modified(const char *path)
env[0] = strbuf_detach(&buf, NULL);
strbuf_addf(&buf, "GIT_DIR=%s/.git", path);
env[1] = strbuf_detach(&buf, NULL);
- env[2] = NULL;
+ strbuf_addf(&buf, "GIT_INDEX_FILE=");
+ env[2] = strbuf_detach(&buf, NULL);
+ env[3] = NULL;
memset(&cp, 0, sizeof(cp));
cp.argv = argv;
@@ -161,6 +163,7 @@ int is_submodule_modified(const char *path)
free(env[0]);
free(env[1]);
+ free(env[2]);
strbuf_release(&buf);
return len != 0;
}
^ permalink raw reply related
* Re: v1.7.0-rc0 shows lots of "unable to find <sha1>" on git-stash
From: Junio C Hamano @ 2010-01-30 20:25 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Jens Lehmann, Git Mailing List
In-Reply-To: <7v8wbfnyz9.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Please try this.
oops, but with this, too.
> diff --git a/submodule.c b/submodule.c
> index ca0527f..8bd0a30 100644
> --- a/submodule.c
> +++ b/submodule.c
> ...
> @@ -142,7 +142,9 @@ int is_submodule_modified(const char *path)
> env[0] = strbuf_detach(&buf, NULL);
> strbuf_addf(&buf, "GIT_DIR=%s/.git", path);
> env[1] = strbuf_detach(&buf, NULL);
> - env[2] = NULL;
> + strbuf_addf(&buf, "GIT_INDEX_FILE=");
This should be:
strbuf_addf(&buf, "GIT_INDEX_FILE");
> + env[2] = strbuf_detach(&buf, NULL);
> + env[3] = NULL;
>
> memset(&cp, 0, sizeof(cp));
> cp.argv = argv;
^ permalink raw reply
* [PATCH] is_submodule_modified(): fix breakage with external GIT_INDEX_FILE
From: Junio C Hamano @ 2010-01-30 20:30 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Jens Lehmann, Git Mailing List
In-Reply-To: <7vvdejmjaj.fsf@alter.siamese.dyndns.org>
Even when the environment was given for the top-level process, checking
in the submodule work tree should use the index file associated with the
work tree of the submodule. Do not export it to the environment.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This seems to pass all the tests, so I'm inclined to push it out as
a part of 1.7.0-rc1. There might be some other enviroment variables
we shouldn't be leaking out to the submodule environment, but that can
be spotted and fixed in later patches before the final.
submodule.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/submodule.c b/submodule.c
index ca0527f..6f7c210 100644
--- a/submodule.c
+++ b/submodule.c
@@ -126,7 +126,7 @@ int is_submodule_modified(const char *path)
"--porcelain",
NULL,
};
- char *env[3];
+ char *env[4];
struct strbuf buf = STRBUF_INIT;
strbuf_addf(&buf, "%s/.git/", path);
@@ -142,7 +142,9 @@ int is_submodule_modified(const char *path)
env[0] = strbuf_detach(&buf, NULL);
strbuf_addf(&buf, "GIT_DIR=%s/.git", path);
env[1] = strbuf_detach(&buf, NULL);
- env[2] = NULL;
+ strbuf_addf(&buf, "GIT_INDEX_FILE");
+ env[2] = strbuf_detach(&buf, NULL);
+ env[3] = NULL;
memset(&cp, 0, sizeof(cp));
cp.argv = argv;
@@ -161,6 +163,7 @@ int is_submodule_modified(const char *path)
free(env[0]);
free(env[1]);
+ free(env[2]);
strbuf_release(&buf);
return len != 0;
}
--
1.7.0.rc1.141.gbc8ce
^ permalink raw reply related
* Re: v1.7.0-rc0 shows lots of "unable to find <sha1>" on git-stash
From: Jens Lehmann @ 2010-01-30 20:44 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <57518fd11001300836v7f21a8a9qc09953d9091a4513@mail.gmail.com>
Am 30.01.2010 17:36, schrieb Jonathan del Strother:
> On 30 January 2010 14:10, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Am 30.01.2010 14:23, schrieb Jonathan del Strother:
>>> On 30 January 2010 12:31, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>>>> I assume you have one or more submodules, maybe even with untracked
>>>> or yet uncommitted modified files in your tree? If so, what does git
>>>> status say in the superproject and in the submodule(s)?
>>>
>>> Yep, I have 10 submodules. However, they're all completely clean with
>>> no tracked or untracked changes shown in git status. Anything else I
>>> can investigate?
>>
>> The change in behavior my patch introduced is that "git status" is
>> called inside each submodule. So i would expect getting the same
>> errors when using this command:
>> git submodule foreach git status -s
>>
>> It should just show
>> Entering '<submodule 1>'
>> Entering '<submodule 2>'
>> Entering '<submodule 3>'
>> Entering '<submodule 4>'
>> Entering '<submodule 5>'
>> Entering '<submodule 6>'
>> Entering '<submodule 7>'
>> Entering '<submodule 8>'
>> Entering '<submodule 9>'
>> Entering '<submodule 10>'
>> when the submodules are not dirty. What do you get?
>>
>
> Correct - I just get that output.
Hm, so nothing unusual there. I really wonder what is the problem here,
as calling "git status" inside the submodules works fine when issued via
"git submodule foreach", but not when done via run_command()!?
So i would like to ask some more questions:
- Under what operating system and on what filesystem is this happening?
- Is there anything unusual about your repo (e.g. using GIT_WORK_TREE
or having the object database somewhere else that in .git in the
superproject or any of the submodules)?
- You are just issuing a "git stash" to stash some changes in the
superproject when that happens, right?
- The hashes that show up as "unable to find" are reachable via "git
show" in the superproject, not in the submodules, right?
- Do these hashes have any relation to the contents you are stashing?
- The following patch should suppress (but not solve) this problem when
applied to a version of git that contains
4d34477f4c5dbebc55aa1362fd705440590a85f1 (git diff: Don't test
submodule dirtiness with --ignore-submodules), e.g. current next.
Could you please verify that?
---8<---
diff --git a/git-stash.sh b/git-stash.sh
index 3a0685f..e9b47b4 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -105,7 +105,7 @@ create_stash () {
w_tree=$(GIT_INDEX_FILE="$TMP-index" git write-tree) ||
die "Cannot save the current worktree state"
- git diff-tree -p HEAD $w_tree > "$TMP-patch" &&
+ git diff-tree --ignore-submodules -p HEAD $w_tree > "$TMP-patch"
test -s "$TMP-patch" ||
die "No changes selected"
^ permalink raw reply related
* Re: FEATURE REQUEST: Allow SSH style URLS (with extra colon)
From: Petr Baudis @ 2010-01-30 22:21 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <87tyu3cyy3.fsf@jondo.cante.net>
On Sat, Jan 30, 2010 at 06:57:56PM +0200, Jari Aalto wrote:
>
> According to git-clone[1] the SSH protocol is specied as:
>
> ssh://[user@]host.xz[:port]/path
>
> It woudl be nice if the ":" were allowed, so that the familiar SSH style
> patch notation could be used, making the spec:
>
> ssh://[user@]host.xz[:[port]]/path
>
> An example:
>
> ssh://foo@examplecom:/path
> |
> Allowed
But that's not an URL anymore. If you want to use ssh pathspec, write it
as a pathspec, not an URL. Just foo@example.com:/path works fine. ;-)
Petr "Pasky" Baudis
^ 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