* [EGIT PATCH 2/5] Don't crash the decorator update loop when resources are deleted
From: Shawn O. Pearce @ 2008-08-06 3:09 UTC (permalink / raw)
To: Robin Rosenberg, Marek Zawirski; +Cc: git
In-Reply-To: <1217992180-5697-2-git-send-email-spearce@spearce.org>
If a resource is deleted from the workspace we don't need to clear
its GITFOLDERDIRTYSTATEPROPERTY from the item because it is gone.
There won't be anyone else to query for that flag, so the flag is
not relevant anymore. Further trying to call accept() on those
resources throws an exception because Eclipse won't let you touch
a deleted resource.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../internal/decorators/GitResourceDecorator.java | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java
index 6d2f88e..84ad949 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java
@@ -126,6 +126,14 @@ public class GitResourceDecorator extends LabelProvider implements
Iterator<IResource> i = resources.iterator();
m = i.next();
i.remove();
+
+ while (!m.isAccessible()) {
+ if (!i.hasNext())
+ return Status.OK_STATUS;
+ m = i.next();
+ i.remove();
+ }
+
if (resources.size() > 0)
schedule();
}
@@ -188,8 +196,7 @@ public class GitResourceDecorator extends LabelProvider implements
} // End ResCL
void clearDecorationState(IResource r) throws CoreException {
- if (r.isAccessible())
- r.setSessionProperty(GITFOLDERDIRTYSTATEPROPERTY, null);
+ r.setSessionProperty(GITFOLDERDIRTYSTATEPROPERTY, null);
fireLabelProviderChanged(new LabelProviderChangedEvent(this, r));
}
--
1.6.0.rc1.250.g9b5e2
^ permalink raw reply related
* [EGIT PATCH 1/5] Remove the pointless GitProjectData resource change listener
From: Shawn O. Pearce @ 2008-08-06 3:09 UTC (permalink / raw)
To: Robin Rosenberg, Marek Zawirski; +Cc: git
In-Reply-To: <1217992180-5697-1-git-send-email-spearce@spearce.org>
Apparently on any IResourceChangeEvent.POST_CHANGE we just burn some
CPU time and generate some garbage for the GC to clean out later. I
cannot see a reason why this code is still here. My memory says we
did this in the past to notify the resource decorator that it needs
to update, or we used it for our cache tree invalidation.
Since this code has no side effect other than to waste time we can
safely remove it, and cut our project down a little bit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../spearce/egit/core/project/GitProjectData.java | 64 --------------------
1 files changed, 0 insertions(+), 64 deletions(-)
diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/project/GitProjectData.java b/org.spearce.egit.core/src/org/spearce/egit/core/project/GitProjectData.java
index 8754bd1..3d5424c 100644
--- a/org.spearce.egit.core/src/org/spearce/egit/core/project/GitProjectData.java
+++ b/org.spearce.egit.core/src/org/spearce/egit/core/project/GitProjectData.java
@@ -29,8 +29,6 @@ import org.eclipse.core.resources.IProject;
import org.eclipse.core.resources.IResource;
import org.eclipse.core.resources.IResourceChangeEvent;
import org.eclipse.core.resources.IResourceChangeListener;
-import org.eclipse.core.resources.IResourceDelta;
-import org.eclipse.core.resources.IResourceDeltaVisitor;
import org.eclipse.core.resources.ResourcesPlugin;
import org.eclipse.core.runtime.CoreException;
import org.eclipse.core.runtime.Preferences;
@@ -61,10 +59,6 @@ public class GitProjectData {
@SuppressWarnings("synthetic-access")
public void resourceChanged(final IResourceChangeEvent event) {
switch (event.getType()) {
- case IResourceChangeEvent.POST_CHANGE:
- projectsChanged(event.getDelta().getAffectedChildren(
- IResourceDelta.CHANGED));
- break;
case IResourceChangeEvent.PRE_CLOSE:
uncache((IProject) event.getResource());
break;
@@ -182,16 +176,6 @@ public class GitProjectData {
Activator.trace("(GitProjectData) " + m);
}
- private static void projectsChanged(final IResourceDelta[] projDeltas) {
- for (int k = 0; k < projDeltas.length; k++) {
- final IResource r = projDeltas[k].getResource();
- final GitProjectData d = get((IProject) r);
- if (d != null) {
- d.notifyChanged(projDeltas[k]);
- }
- }
- }
-
private synchronized static void cache(final IProject p,
final GitProjectData d) {
projectDataCache.put(p, d);
@@ -380,54 +364,6 @@ public class GitProjectData {
}
}
- private void notifyChanged(final IResourceDelta projDelta) {
-// final Set affectedMappings = new HashSet();
- try {
- projDelta.accept(new IResourceDeltaVisitor() {
- public boolean visit(final IResourceDelta d)
- throws CoreException {
- final int f = d.getFlags();
- IResource res = d.getResource();
- IResource r = res;
- if ((f & IResourceDelta.CONTENT) != 0
- || (f & IResourceDelta.ENCODING) != 0
- || r instanceof IContainer) {
- String s = null;
- RepositoryMapping m = null;
-
- while (r != null) {
- m = getRepositoryMapping(r);
- if (m != null) {
- break;
- }
-
- if (s != null) {
- s = r.getName() + "/" + s;
- } else {
- s = r.getName();
- }
-
- r = r.getParent();
- }
-
- if (m == null) {
- return false;
- } else if (s == null) {
- return true;
- }
- }
- return false;
- }
- });
- } catch (CoreException ce) {
- // We are in deep trouble. This should NOT have happend. Detach
- // our listeners and forget it ever did.
- //
- detachFromWorkspace();
- Activator.logError(CoreText.GitProjectData_notifyChangedFailed, ce);
- }
- }
-
private File propertyFile() {
return new File(getProject()
.getWorkingLocation(Activator.getPluginId()).toFile(),
--
1.6.0.rc1.250.g9b5e2
^ permalink raw reply related
* [EGIT PATCH 0/5] Support linked resources in repositories
From: Shawn O. Pearce @ 2008-08-06 3:09 UTC (permalink / raw)
To: Robin Rosenberg, Marek Zawirski; +Cc: git
Sometimes users need to create links inside of a project to point
back to their Git working directory. This is sort of like a symlink
in POSIX, but its managed at the Eclipse workspace level.
If a resource is contained within a linked directory and that is
also within a Git repository we want to allow Git operations on
that linked resource to operate using the paths of the files as
they are in the repository working directory, and not the path of
the files in the Eclipse workspace.
Shawn O. Pearce (5):
Remove the pointless GitProjectData resource change listener
Don't crash the decorator update loop when resources are deleted
Fix RepositoryMapping.getRepoRelativePath to honor linked resources
Change GitProjectData.getRepositoryMapping to work on linked
resources
Correct getRepositoryMapping callers to use any IResource
.../egit/core/op/ConnectProviderOperation.java | 14 +---
.../org/spearce/egit/core/op/UntrackOperation.java | 4 +-
.../spearce/egit/core/project/GitProjectData.java | 111 ++++++--------------
.../egit/core/project/RepositoryFinder.java | 11 +--
.../egit/core/project/RepositoryMapping.java | 79 ++++++--------
.../egit/ui/internal/actions/CommitAction.java | 2 +-
.../internal/decorators/GitResourceDecorator.java | 11 ++-
7 files changed, 81 insertions(+), 151 deletions(-)
^ permalink raw reply
* [PATCH] [TopGit] Pretty print the help creation commands in Makefile.
From: Russell Steicke @ 2008-08-06 2:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Print "[HELP] cmdname" while compiling the tg-cmdname.txt files.
Signed-off-by: Russell Steicke <russellsteicke@gmail.com>
---
Makefile | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 238d07d..2975f29 100644
--- a/Makefile
+++ b/Makefile
@@ -26,7 +26,9 @@ tg $(commands_out) $(hooks_out): % : %.sh
mv $@+ $@
$(help_out): README
- ./create-help.sh `echo $@ | sed -e 's/tg-//' -e 's/\.txt//'`
+ @CMD=`echo $@ | sed -e 's/tg-//' -e 's/\.txt//'` && \
+ echo '[HELP]' $$CMD && \
+ ./create-help.sh $$CMD
install:: all
install tg "$(bindir)"
--
tg: (e311d15..) t/help2 (depends on: master)
--
Russell Steicke
-- Fortune says:
Today is the first day of the rest of your life.
^ permalink raw reply related
* discussion of git on lwn.net
From: david @ 2008-08-06 2:18 UTC (permalink / raw)
To: git
I suspect that many people will see this anyway, but for those who don't
read lwn there is an article osted today about git (initially pointing at
the git magic site) that is attracting quite a few comments (18 so far)
David Lang
http://lwn.net/Articles/292726/
Git Magic may not be exactly new, but some of us have stumbled across it
later than others. It is a highly readable introduction to git with lots
of examples of how to get things done. "As Arthur C. Clarke observed, any
sufficiently advanced technology is indistinguishable from magic. This is
a great way to approach Git: newbies can ignore its inner workings and
view Git as a gizmo that can amaze friends and infuriate enemies with its
wondrous abilities. Rather than go into details, we provide rough
instructions for particular effects. After repeated use, gradually you
will understand how each trick works, and how to tailor the recipes for
your needs."
^ permalink raw reply
* Re: [PATCH] Makefile: use backticks rather than $() notation to support ancient shells
From: Johannes Schindelin @ 2008-08-06 0:10 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <K5bb057jTokXyOIU_aDE4vMr3jT4DOgSPRcIktfus6QMVq6dszrgGw@cipher.nrlssc.navy.mil>
Hi,
On Tue, 5 Aug 2008, Brandon Casey wrote:
> Otherwise, should we set the SHELL variable to the configured SHELL_PATH
> at some point in the Makefile?
I think that would make more sense, especially since it would catch
wrong SHELL_PATH early.
Maybe we can even have some sanity check that tests if SHELL_PATH groks
$()?
Ciao,
Dscho
^ permalink raw reply
* Re: Not going beyond symbolic links
From: Junio C Hamano @ 2008-08-05 23:57 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Linus Torvalds, Johannes Schindelin, git, Petr Baudis,
Shawn O. Pearce
In-Reply-To: <20080805125422.GX7008@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> writes:
> Obviously, if a symlink points to a directory inside of the repository
> and then you use "git add sym/file", it is definitely a mistake. OTOH,
> let's consider the following situation:
>
> git init
> mkdir newdir
> touch newdir/foo
> git add newdir/foo
> git commit -m 'add foo'
> mv newdir /tmp/
> ln -s /tmp/newdir
> touch newdir/bar
> git add newdir/bar
> git commit -m 'add bar'
> git ls-files
>
> And you can see:
> newdir/bar
> newdir/foo
>
> Git does exactly what I want here!
Now, do this after the above sequence:
git diff
git add . && git ls-files
and tell me what you see. Does it show exactly what you want here?
I've already told you what kind of changes you would need to make if you
really want to claim this is a feature.
^ permalink raw reply
* Re: [PATCH] perl/Makefile: handle paths with spaces in the NO_PERL_MAKEMAKER section
From: Junio C Hamano @ 2008-08-05 23:46 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <osgPH47FO7h-zLUMqwCv-i9BWln2-_AK5T6TI-5mLGFjwAhJ4Bg_lw@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Use double quotes to protect against paths which may contain spaces.
> ...
> + echo ' mkdir -p "$(instdir_SQ)"' >> $@
Is this sufficient? We seem to apply double-sq when writing shell
scriptlet in GIT-BUILD-OPTIONS from the main Makefile, and I suspect you
would need to do something similar.
^ permalink raw reply
* [PATCH] perl/Makefile: handle paths with spaces in the NO_PERL_MAKEMAKER section
From: Brandon Casey @ 2008-08-05 23:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <mLu74vNKfH1vFZlC7N_lRX3WekWReoVjWY42voUDUBUnAGVpDNYWndWqlaHoqVAkxOaCdYV6uDk@cipher.nrlssc.navy.mil>
Use double quotes to protect against paths which may contain spaces.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
perl/Makefile | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/perl/Makefile b/perl/Makefile
index b8547db..e3dd1a5 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -29,11 +29,11 @@ $(makfile): ../GIT-CFLAGS Makefile
'$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
echo ' cp private-Error.pm blib/lib/Error.pm' >> $@
echo install: >> $@
- echo ' mkdir -p $(instdir_SQ)' >> $@
- echo ' $(RM) $(instdir_SQ)/Git.pm; cp Git.pm $(instdir_SQ)' >> $@
- echo ' $(RM) $(instdir_SQ)/Error.pm' >> $@
+ echo ' mkdir -p "$(instdir_SQ)"' >> $@
+ echo ' $(RM) "$(instdir_SQ)/Git.pm"; cp Git.pm "$(instdir_SQ)"' >> $@
+ echo ' $(RM) "$(instdir_SQ)/Error.pm"' >> $@
'$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
- echo ' cp private-Error.pm $(instdir_SQ)/Error.pm' >> $@
+ echo ' cp private-Error.pm "$(instdir_SQ)/Error.pm"' >> $@
echo instlibdir: >> $@
echo ' echo $(instdir_SQ)' >> $@
else
--
1.6.0.rc1.87.g56c9f.dirty
^ permalink raw reply related
* [PATCH] Makefile: use backticks rather than $() notation to support ancient shells
From: Brandon Casey @ 2008-08-05 23:22 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Since make is using /bin/sh to execute shell code, avoid the newish
shell construct $() so older (ancient) shells can execute the shell
code in the Makefile.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
I know that $() is preferred in the main scripts, but the Makefile
is using /bin/sh to execute shell code and there are already a few
places in the Makefile using back-ticks, so it doesn't seem like
going against the flow too much.
Otherwise, should we set the SHELL variable to the configured SHELL_PATH
at some point in the Makefile?
-brandon
Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 608a185..421af24 100644
--- a/Makefile
+++ b/Makefile
@@ -1366,8 +1366,8 @@ endif
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
endif
- bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
- execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
+ bindir=`cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd` && \
+ execdir=`cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd` && \
if test "z$$bindir" != "z$$execdir"; \
then \
ln -f "$$bindir/git$X" "$$execdir/git$X" || \
--
1.6.0.rc1.87.g56c9f.dirty
^ permalink raw reply related
* do without .netrc
From: Jürgen Mangler @ 2008-08-05 23:00 UTC (permalink / raw)
To: git
"git clone http://a:b@donatello.pri.univie.ac.at/repositories/0/Data/"
is not working
also "git clone
http://a@donatello.pri.univie.ac.at/repositories/0/Data/" is not asking
for password. is it supposed to?
it is working without a:b@ part, but ~/.netrc instead
:-(, is it possible without .netrc
git version 1.5.4.3
thanks, regards
Jürgen
^ permalink raw reply
* Re: [PATCH] git-p4: chdir now properly sets PWD environment variable in msysGit
From: Alex Riesen @ 2008-08-05 22:23 UTC (permalink / raw)
To: Robert Blum; +Cc: simon, shausman, marius, hanwen, gitster, git
In-Reply-To: <bad7471c0808011250v569ffaaby9e20a5ba1f971927@mail.gmail.com>
2008/8/1 Robert Blum <rob.blum@gmail.com>:
> P4 on Windows expects the PWD environment variable to be set to the
> current working dir, but os.chdir in python doesn't do that by default
Try just removing it (if you can). It worked for me (in bash of cygwin).
^ permalink raw reply
* Re: [TopGit PATCH 2/2] tg-create.sh: Introduce topgit.subjectprefix config option
From: Petr Baudis @ 2008-08-05 22:18 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git
In-Reply-To: <1217963610-15195-2-git-send-email-bert.wesarg@googlemail.com>
Hi,
On Tue, Aug 05, 2008 at 09:13:30PM +0200, Bert Wesarg wrote:
> Set the topgit.subjectprefix config option to prepend the string to the [PATCH]
> field in the Subject: line of the '.topmsg' file.
>
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
hmm, the patch does not apply as-is because $1 -> $name got changed in
t/fix-subject-line-in-.topmsg which you didn't submit (I *instantly*
knew adding the depends line to the patch will be good idea ;-).
Actually, the line was always meant to be just empty, but putting the
patch name there does no harm. I will change that.
> ---
> README | 7 ++++---
> tg-create.sh | 3 ++-
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/README b/README
> index bd4f17a..f821bab 100644
> --- a/README
> +++ b/README
> @@ -204,9 +204,10 @@ tg create
>
> After `tg create`, you should insert the patch description
> to the '.topmsg' file, which will already contain some
> - pre-filled bits. You can set topgit.to, topgit.cc and topgit.bcc
> - configuration variables in order to have `tg create`
> - add these headers with given default values to '.topmsg'.
> + pre-filled bits. You can set topgit.subjectprefix, topgit.to,
> + topgit.cc and topgit.bcc configuration variables in order to
> + have `tg create` use this subject prefix and add these headers
> + with the given default values to '.topmsg', respectively.
>
> The main task of `tg create` is to set up the topic branch
> base from the dependencies. This may fail due to merge conflicts.
> diff --git a/tg-create.sh b/tg-create.sh
> index 0bf329c..c2b38bf 100644
> --- a/tg-create.sh
> +++ b/tg-create.sh
> @@ -107,7 +107,8 @@ author_addr="${author%> *}>"
> ! header="$(git config topgit.to)" || echo "To: $header"
> ! header="$(git config topgit.cc)" || echo "Cc: $header"
> ! header="$(git config topgit.bcc)" || echo "Bcc: $header"
> - echo "Subject: [PATCH] $name"
> + subject_prefix="$(git config topgit.subjectprefix)" && subject_prefix="$subject_prefix "
> + echo "Subject: [${subject_prefix}PATCH] $name"
> echo
> cat <<EOT
> <patch description>
I have converted this to the ||-form since that's much clearer with
set -e.
Thanks,
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: StGit: kha/{stable,safe,experimental} updated
From: Catalin Marinas @ 2008-08-05 21:33 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Samuel Tardieu
In-Reply-To: <20080801102208.GA29413@diana.vm.bytemark.co.uk>
2008/8/1 Karl Hasselström <kha@treskal.com>:
> On 2008-07-27 09:44:31 +0100, Catalin Marinas wrote:
>
>> 2008/7/25 Karl Hasselström <kha@treskal.com>:
>>
>> > The big update since last time is support (in kha/experimental) for
>> > hidden patches in the new-infrastructure commands and stack log.
>>
>> I'll have a look at the new stack log format (my main worry) this
>> week but the other patches look OK.
>
> Heh. It's _always_ your main worry. But rightly so, since mistakes
> could be costly. Thanks for spending time on this with me.
I'm usually worried about performance but will give it a try with a
Linux kernel and real patches. Have you done any tests to compare it
with my master branch?
Would we even need to prune the stack history? It might get pretty
large after about 1-2 years of usage.
--
Catalin
^ permalink raw reply
* Re: [StGit RFC] Pull request for build/install work
From: Catalin Marinas @ 2008-08-05 21:10 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Daniel White, git
In-Reply-To: <20080804143838.GD12232@diana.vm.bytemark.co.uk>
2008/8/4 Karl Hasselström <kha@treskal.com>:
> On 2008-07-31 16:29:16 +1000, Daniel White wrote:
>
>> Changes are on my experimental branch
>> at git://repo.or.cz/stgit/dwhite.git.
>
> Thanks. Have merged, and will push out sometime soon.
Thanks, both to Daniel and Karl (for merging them).
--
Catalin
^ permalink raw reply
* Re: [StGIT PATCH] Do not insert an empty line before the diffstat info
From: Catalin Marinas @ 2008-08-05 21:09 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Samuel Tardieu, git
In-Reply-To: <20080804142000.GC12232@diana.vm.bytemark.co.uk>
2008/8/4 Karl Hasselström <kha@treskal.com>:
> On 2008-07-31 14:50:10 +0200, Samuel Tardieu wrote:
>
>> To make the format of stg output closer to the plain git one, do not
>> insert an empty line between the "---" separator and the diffstat
>> information.
>
> Thanks, will apply. (IMO it's slightly uglier, but it's better to be
> consistent. And it does save some space.)
Without this change, I could easily spot people posting patches with
StGIT rather than Git :-). Anyway, I'm OK with this patch as well.
Thanks.
--
Catalin
^ permalink raw reply
* Re: [StGit] stg import documentation incorrect.
From: Catalin Marinas @ 2008-08-05 21:07 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jurko Gospodneti?, git
In-Reply-To: <20080804124823.GA12232@diana.vm.bytemark.co.uk>
2008/8/4 Karl Hasselström <kha@treskal.com>:
> Yes, the tutorial is in sore need of a fresh coat of paint.
Now that you mentioned it, should we just replace the wiki tutorial by
a static page generated from Documentation/tutorial.txt?
If no-one feels like writing documentation, I'll have a go at updating
the tutorial.
--
Catalin
^ permalink raw reply
* Re: [StGIT v2 PATCH] Do not mess-up with commit message formatting when sending email
From: Catalin Marinas @ 2008-08-05 20:48 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: kha, git
In-Reply-To: <20080804151913.4269.74254.stgit@dawn.rfc1149.net>
2008/8/4 Samuel Tardieu <sam@rfc1149.net>:
> The short description, which will be used as the email subject,
> gets its leading and trailing blanks removed.
>
> The long description gets its trailing blanks removed as well
> as any leading empty lines. Leading blanks are left untouched
> to preserve the formatting.
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Optimize sha1_object_info for loose objects, not concurrent repacks
From: Shawn O. Pearce @ 2008-08-05 20:18 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20080805200841.GA23121@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
> When dealing with a repository with lots of loose objects, sha1_object_info
> would rescan the packs directory every time an unpacked object was referenced
> before finally giving up and looking for the loose object. This caused a lot
> of extra unnecessary system calls during git pack-objects; the code was
> rereading the entire pack directory once for each loose object file.
>
> This patch looks for a loose object before falling back to rescanning the
> pack directory, rather than the other way around.
>
> Signed-off-by: Steven Grimm <koreth@midwinter.com>
Heh. Cute bug.
ACK.
> diff --git a/sha1_file.c b/sha1_file.c
> index e281c14..32e4664 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1929,11 +1929,18 @@ static int sha1_loose_object_info(const unsigned char *sha1, unsigned long *size
> int sha1_object_info(const unsigned char *sha1, unsigned long *sizep)
> {
> struct pack_entry e;
> + int status;
>
> if (!find_pack_entry(sha1, &e, NULL)) {
> + /* Most likely it's a loose object. */
> + status = sha1_loose_object_info(sha1, sizep);
> + if (status >= 0)
> + return status;
> +
> + /* Not a loose object; someone else may have just packed it. */
> reprepare_packed_git();
> if (!find_pack_entry(sha1, &e, NULL))
> - return sha1_loose_object_info(sha1, sizep);
> + return status;
> }
> return packed_object_info(e.p, e.offset, sizep);
> }
--
Shawn.
^ permalink raw reply
* [PATCH] Optimize sha1_object_info for loose objects, not concurrent repacks
From: Steven Grimm @ 2008-08-05 20:08 UTC (permalink / raw)
To: git
When dealing with a repository with lots of loose objects, sha1_object_info
would rescan the packs directory every time an unpacked object was referenced
before finally giving up and looking for the loose object. This caused a lot
of extra unnecessary system calls during git pack-objects; the code was
rereading the entire pack directory once for each loose object file.
This patch looks for a loose object before falling back to rescanning the
pack directory, rather than the other way around.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
I discovered this by running strace on a pack-objects that was
taking especially long to run; it was making more system calls
to scan the pack directory than to do stuff with the loose
objects, which didn't seem right.
sha1_file.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index e281c14..32e4664 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1929,11 +1929,18 @@ static int sha1_loose_object_info(const unsigned char *sha1, unsigned long *size
int sha1_object_info(const unsigned char *sha1, unsigned long *sizep)
{
struct pack_entry e;
+ int status;
if (!find_pack_entry(sha1, &e, NULL)) {
+ /* Most likely it's a loose object. */
+ status = sha1_loose_object_info(sha1, sizep);
+ if (status >= 0)
+ return status;
+
+ /* Not a loose object; someone else may have just packed it. */
reprepare_packed_git();
if (!find_pack_entry(sha1, &e, NULL))
- return sha1_loose_object_info(sha1, sizep);
+ return status;
}
return packed_object_info(e.p, e.offset, sizep);
}
--
1.6.0.rc1.66.gc78d7
^ permalink raw reply related
* Re: [BUG] git diff-tree --stdin doesn't accept two trees
From: Junio C Hamano @ 2008-08-05 20:07 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080805164839.GA3934@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> I'm trying to use diff-tree --stdin to diff several trees in one go.
> But I just get error messages when I feed it two space-separated trees
> (one commit works fine):
>
> $ echo $(git rev-parse HEAD^{tree}) $(git rev-parse HEAD^^{tree}) | git diff-tree -p --stdin
> error: Object 7bfd9971f77438858e412be0219ec78afb3ca46f not a commit
>
> This is at odds with the documentation:
>
> --stdin::
> When '--stdin' is specified, the command does not take
> <tree-ish> arguments from the command line. Instead, it
> reads either one <commit> or a pair of <tree-ish>
> separated with a single space from its standard input.
>
> I tried reading the code to figure out what's wrong, and as far as I
> can tell the code to do this is there, but seems to be protected by
> logic that aborts everything unless the whole input line is a valid
> commit. Or maybe I'm just confused ...
No, the documentation was made wrong during 1.2.0 timeperiod.
The feature of --stdin to take a commit and its parents on one line was
broken before that to support the common
rev-list --parents $commits... -- $paths... |
diff-tree --stdin -v -p
usage pattern by Porcelains. For diff-tree to talk sensibly about
commits, it needs to see commits, not just trees.
^ permalink raw reply
* Re: Best of open source developer tools
From: Shawn O. Pearce @ 2008-08-05 19:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0808051844550.26154@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> To those who haven't seen it yet,
>
> http://www.infoworld.com/slideshow/2008/08/166-best_of_open_so-3.html
Well, congrats all around on what we have achived these past
few years.
But we still can make Git even easier to use.
OK, back to work everyone. :)
--
Shawn.
^ permalink raw reply
* [TopGit PATCH 2/2] tg-create.sh: Introduce topgit.subjectprefix config option
From: Bert Wesarg @ 2008-08-05 19:13 UTC (permalink / raw)
To: Petr Baudis, Petr Baudis; +Cc: Bert Wesarg, git
In-Reply-To: <1217963610-15195-1-git-send-email-bert.wesarg@googlemail.com>
Set the topgit.subjectprefix config option to prepend the string to the [PATCH]
field in the Subject: line of the '.topmsg' file.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
README | 7 ++++---
tg-create.sh | 3 ++-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/README b/README
index bd4f17a..f821bab 100644
--- a/README
+++ b/README
@@ -204,9 +204,10 @@ tg create
After `tg create`, you should insert the patch description
to the '.topmsg' file, which will already contain some
- pre-filled bits. You can set topgit.to, topgit.cc and topgit.bcc
- configuration variables in order to have `tg create`
- add these headers with given default values to '.topmsg'.
+ pre-filled bits. You can set topgit.subjectprefix, topgit.to,
+ topgit.cc and topgit.bcc configuration variables in order to
+ have `tg create` use this subject prefix and add these headers
+ with the given default values to '.topmsg', respectively.
The main task of `tg create` is to set up the topic branch
base from the dependencies. This may fail due to merge conflicts.
diff --git a/tg-create.sh b/tg-create.sh
index 0bf329c..c2b38bf 100644
--- a/tg-create.sh
+++ b/tg-create.sh
@@ -107,7 +107,8 @@ author_addr="${author%> *}>"
! header="$(git config topgit.to)" || echo "To: $header"
! header="$(git config topgit.cc)" || echo "Cc: $header"
! header="$(git config topgit.bcc)" || echo "Bcc: $header"
- echo "Subject: [PATCH] $name"
+ subject_prefix="$(git config topgit.subjectprefix)" && subject_prefix="$subject_prefix "
+ echo "Subject: [${subject_prefix}PATCH] $name"
echo
cat <<EOT
<patch description>
--
tg: (2fc069d..) t/subject-prefix (depends on: t/fix-subject-line-in-.topmsg)
^ permalink raw reply related
* [TopGit PATCH 1/2] Fix generated Subject: line in .topmsg
From: Bert Wesarg @ 2008-08-05 19:13 UTC (permalink / raw)
To: Petr Baudis, Petr Baudis; +Cc: Bert Wesarg, git
$1 is unset after parsing all arguments, so use $name instead.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
tg-create.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tg-create.sh b/tg-create.sh
index d196e4f..0bf329c 100644
--- a/tg-create.sh
+++ b/tg-create.sh
@@ -107,7 +107,7 @@ author_addr="${author%> *}>"
! header="$(git config topgit.to)" || echo "To: $header"
! header="$(git config topgit.cc)" || echo "Cc: $header"
! header="$(git config topgit.bcc)" || echo "Bcc: $header"
- echo "Subject: [PATCH] $1"
+ echo "Subject: [PATCH] $name"
echo
cat <<EOT
<patch description>
--
tg: (24367cc..) t/fix-subject-line-in-.topmsg (depends on: master)
^ permalink raw reply related
* Re: [PATCH 0/8] bash completion: more porcelain completions
From: Shawn O. Pearce @ 2008-08-05 19:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lee Marlow, git
In-Reply-To: <7vbq07waph.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Lee Marlow <lee.marlow@gmail.com> wrote:
> >> This adds basic long option completion for some common commands that I
> >> use, as well as stash name completion.
> >
> > Entire series is good.
> >
> > Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
> Have you looked at the last one [PATCH 8/8]? I do not seem to have it.
Yes. I just sent it back to you and the list. Hopefully at least
one copy makes it. ;-)
--
Shawn.
^ 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