* Re: [PATCH 01/10] refs: add "for_each_bisect_ref" function
From: Sverre Rabbelier @ 2009-03-26 16:54 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Michael J Gruber, Christian Couder, Junio C Hamano, git,
John Tapsell
In-Reply-To: <alpine.DEB.1.00.0903261748280.12753@intel-tinevez-2-302>
Heya,
On Thu, Mar 26, 2009 at 17:52, Johannes Schindelin
<Johannes.Schindelin@gmx.de> > From the patch series' titles
(especially when they are cropped due to the
> text window being too small to fit the indented thread), it is not all
> that obvious what you want to achieve with those 10 patches.
<snip>
> Unfortunately, that does not reveal to me, quickly, what is the current
> state of affairs, and what you changed since the last time.
This is exactly what I meant to say, only worded much much better,
thanks Johannes! :)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Question: Is it possible to host a writable git repo over both http and ssh?
From: Shawn O. Pearce @ 2009-03-26 16:57 UTC (permalink / raw)
To: Rogan Dawes, Mike Gaffney; +Cc: Robin Rosenberg, Jeff King, git
In-Reply-To: <49CB4EF1.6050902@dawes.za.net>
Rogan Dawes <lists@dawes.za.net> wrote:
> Robin Rosenberg wrote:
> > torsdag 26 mars 2009 05:56:51 skrev Jeff King <peff@peff.net>:
> >> On Wed, Mar 25, 2009 at 11:55:29PM -0500, Mike Gaffney wrote:
> >>
> >>> I'm actually trying to take what Sean did with gerrit and extract a
> >>> full Java/MinaSSHD based server that doesn't require a real user
> >>> account and is configurable by spring. So yes, I'm using JGit on the
> >>> server.
> >> Ah. In that case, I don't know whether JGit respects all hooks. You
> >> should ask Shawn (Shawn, we are talking about a post-update to run
> >> update-server-info). :)
JGit already has the native code needed for update-server-info.
Look at WalkPushConnection:
line 185-187 calls refWriter.writeInfoRefs() to update the
GIT_DIR/info/refs for dumb transports. We just need to call
that in the end of the receive code.
line 236 calls WalkRemoteObjectDatabase.writeInfoPacks() to
update the GIT_DIR/objects/info/packs file. This needs to
be abstracted out so we can more easily reuse it.
> > Arguably it should. but it doesn't. Then there is a question as to what
> > format those hooks should be. Shell scripts would run into platform
> > issues and jgit based stuff should have as little as possible of that, but
> > a similar mechanism should exist.
Yup, I agree.
At the very least we should suppot doing the update-server-info
logic from pure Java, as it is probably the most common operation
people would want in a post receive hook.
> Maybe support executing scripts via Bean Scripting Framework?
>
> That would allow scripts to be written in any of the supported
> languages, as long as the appropriate interpreter is present.
>
> e.g. BeanShell, Groovy, Jython, etc
>
> See http://jakarta.apache.org/bsf/
>
> If you define an interface for each hook, the scripts could implement
> the interface, and execute that way.
Yes, that is one option. I'd like to get a reasonable binding to
BSF for JGit, but its more of a wish than a real need for me, so
I just don't bother. I think many people who want to script Git
from Python would be reasonably happy with executing that script
through Jython if there was a decent binding.
--
Shawn.
^ permalink raw reply
* "git clone --depth <depth>" producing history with <depth + 1> commits?
From: Sebastian Pipping @ 2009-03-26 17:00 UTC (permalink / raw)
To: git
Hello!
Is "git clone --depth 1 <ropository>" expected to give a history
with 2 commits? "--depth 2" gives 3 commits, "--depth 0" all.
Is that by design or a bug?
Sebastian
^ permalink raw reply
* Re: Reference for git.git release process
From: Shawn O. Pearce @ 2009-03-26 17:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Raman Gupta, git
In-Reply-To: <7v3ad1ufcb.fsf@gitster.siamese.dyndns.org>
jUNio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
> > On Wed, Mar 25, 2009 at 12:30:31PM -0700, Junio C Hamano wrote:
> >
> >> I do not answer "generally" part, but in git.git, I do not publish heads
> >> of individual topic branches. I could, but simply I don't, because that
> >> has been the way I've operated so far, and I am too lazy to change my
> >> configuration.
> >
> > I don't think it is a big problem in practice.
>
> Both times Shawn took over the maintainership from me in October for the
> past few years (and I will ask him to this year, too, although I do not
> know if he is willing to take it again yet), it would have made his life
> (and possibly everybody who had his topic in flight) much easier if they
> were public. Last year I sent him for-each-ref output offline before I
> took off to make it a bit easier on him (my disappearance two years ago
> was unscheduled and I couldn't do that).
So yes, I'd be happy to fill in while you are offline again.
But back to Jeff's point, the bigger issue when you dropped off
all of a sudden wasn't extracting the refs from the `pu` branch
(that was fairly easy, just scan through the merge commits, copy
and paste the branch name, copy and paste the 2nd parent), it was
figuring out what the state of each branch was, and what your final
thoughts on that branch had been before you left.
The newer "what's in" tools in your Meta project make this easier,
along with having the messages archived. The first year I had to
go pull the what's in email from the list archives, and just scan
through the code and form my own opinion in a few cases.
--
Shawn.
^ permalink raw reply
* Re: [PATCH JGIT] Do not read ~/.gitconfig during JUnit tests
From: Shawn O. Pearce @ 2009-03-26 17:27 UTC (permalink / raw)
To: Yann Simon; +Cc: Robin Rosenberg, git
In-Reply-To: <49C8E1E8.5020706@gmail.com>
Yann Simon <yann.simon.fr@gmail.com> wrote:
> Extend the SystemReader interface to add the responsability
> to get the user's global configuration.
> This extension is used in the JUnit tests to provide a
> custom global configuration instance independant
> from ~/.gitconfig.
>
> Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
> ---
> This should close the issue #42.
Thanks.
--
Shawn.
^ permalink raw reply
* problems with multipl hosts access git-cvsserver after a git push
From: Kelly F. Hickel @ 2009-03-26 17:31 UTC (permalink / raw)
To: git
Hi, I'm looking at moving from cvs to git and I'm working on our build
process. There are a few machines where we don't have git and were
hoping to use git-cvsserver to provide read only access for the builds,
but I've run into a bit of a snag.
The build process begins a checkout on all the build machines
simultaneously, it looks as though when this happens have changes have
been pushed, the first cvs pull is updating the database to reflect the
git repo, other cvs clients are blocked and give up after awhile.....
Any thoughts how to "fix" this? I suppose I could just stop doing the
simultaneous pulls for cvs but that's a bigger change than I wanted to
make. The only other idea I've come up with is to run a separate
git-cvsserver for each host that must use cvs (there's only a few), that
way it can't be blocked by another host, but that's kind of clunky to
manage....
cvs checkout: warning: unrecognized response `DBD::SQLite::st execute
failed: database is locked(5) at dbdimp.c line 403 at
/usr/local/bin/git-cvsserver line 3253, <FILELIST> chunk 2.' from cvs
server
cvs checkout: warning: unrecognized response `DBD::SQLite::st execute
failed: database is locked(5) at dbdimp.c line 403 at
/usr/local/bin/git-cvsserver line 3326.' from cvs server
... (message repeated many times with only small variations) ...
cvs checkout: warning: unrecognized response `DBD::SQLite::st execute
failed: database is locked(21) at dbdimp.c line 376 at
/usr/local/bin/git-cvsserver line 3326.' from cvs server
cvs checkout: warning: unrecognized response `DBD::SQLite::st execute
failed: database is locked(21) at dbdimp.c line 376 at
/usr/local/bin/git-cvsserver line 3331.' from cvs server
cvs [checkout aborted]: end of file from server (consult above messages
if any)
Thanks,
--
Kelly F. Hickel
Senior Product Architect
MQSoftware, Inc.
952-345-8677 Office
952-345-8721 Fax
kfh@mqsoftware.com
www.mqsoftware.com
Certified IBM SOA Specialty
Your Full Service Provider for IBM WebSphere
Learn more at www.mqsoftware.com
^ permalink raw reply
* Re: [PATCH 3/8] Documentation: rename docbook-xsl-172 attribute to git-asciidoc-no-roff
From: Michael J Gruber @ 2009-03-26 18:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Chris Johnsen, git
In-Reply-To: <7vocvop6x2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 26.03.2009 17:47:
> Jeff King <peff@peff.net> writes:
>
>> On Tue, Mar 24, 2009 at 02:48:52PM -0500, Chris Johnsen wrote:
>>
>>> I am not opposed to providing more version-specific controls, but I am not
>>> sure which versions are important enough to justify their own variables.
>>> Are you indicating that 1.73 is important enough because it was a "return
>>> to sanity" after 1.72?
>>
>> No, mainly because it is what is shipped in the last version of Debian,
>> which means it is a major enough version that there will be a lot of
>> people using it.
>>
>> But let's just start with adding the tweakable knobs (which your series
>> is already doing), and see in what ways they need to be tweaked for
>> popular platforms before going overboard.
>
> When I was trying out the series yesterday, I was wondering if this is
> something we can autodetect.
>
> Output from "asciidoc --version" is easily machine parsable for giving
> asciidoc7compatible aka ASCIIDOC8, but I couldn't come up with anything
> simpler than probing a few hardcoded paths under /usr/share/sgml; that
> approach is unacceptable because would not work if your stylesheets are in
> somewhere we do not know about. Ideally, we should be able to ask the
> tools we invoke (e.g. xmlto) to get that information.
Maybe run asciidoc/xmlto on a minimal test file and check the output?
"autoconf lite", so to say.
Michael
^ permalink raw reply
* Git for collaborative web development
From: Carlo @ 2009-03-26 18:51 UTC (permalink / raw)
To: git
Hi,
I'm going to work on a web project with a friend. We will host our code on a
server and my idea was to set up a git repository (maybe using gitosis) so that
we could work on our machines and push the changes to the server.
He said that it would be complicated, because if he's going to try some changes
to show me on the fly he just can't. I mean, he would like to work on the code
directly on the server, so that he can change the code, save and I can just
refresh the page from my browser and see what he did.
Using git he should save, commit, add, push... so it's a bit longer.
Is there a nice compromise? Or a better way to use git for such a task or web
development in general?
Thanks for your help,
bye.
^ permalink raw reply
* Re: Git for collaborative web development
From: Sverre Rabbelier @ 2009-03-26 19:18 UTC (permalink / raw)
To: Carlo; +Cc: git
In-Reply-To: <loom.20090326T184207-345@post.gmane.org>
Heya,
On Thu, Mar 26, 2009 at 19:51, Carlo <mr.spoon21@gmail.com> wrote:
> Using git he should save, commit, add, push... so it's a bit longer.
>
> Is there a nice compromise? Or a better way to use git for such a task or web
> development in general?
$ git config alias.tryout "!git branch -f tryout && git checkout
tryout && git add . && git commit -m TryOut && git push shared_repo
tryout"
You can even see the page live if you set the proper attributes ;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Git for collaborative web development
From: Mr.SpOOn @ 2009-03-26 19:41 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0903261218y329562f6uf18613f3f9e15836@mail.gmail.com>
2009/3/26 Sverre Rabbelier <srabbelier@gmail.com>:
> $ git config alias.tryout "!git branch -f tryout && git checkout
> tryout && git add . && git commit -m TryOut && git push shared_repo
> tryout"
That seems cool. I'll take a look to some documentation to understand it :D
Thanks.
^ permalink raw reply
* [JGIT PATCH] Simplify the PackWriter.preparePack() API
From: Shawn O. Pearce @ 2009-03-26 19:42 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Shawn O. Pearce
It has always bothered me that we had two boolean "mode" parameters
as part of the preparePack method call, when most other options were
set by standard setter methods. In all current callers (except the
unit tests) the ignoreMissingUninteresting was always set to true,
and in many of the callers, packthin was false. Moving these to
setters with a reasonable default simplifies callers considerably.
Signed-off-by: Shawn O. Pearce <sop@google.com>
---
.../tst/org/spearce/jgit/lib/PackWriterTest.java | 5 +-
.../src/org/spearce/jgit/lib/PackWriter.java | 78 +++++++++++++-------
.../jgit/transport/BasePackPushConnection.java | 3 +-
.../org/spearce/jgit/transport/BundleWriter.java | 3 +-
.../src/org/spearce/jgit/transport/UploadPack.java | 3 +-
.../spearce/jgit/transport/WalkPushConnection.java | 2 +-
6 files changed, 62 insertions(+), 32 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
index f7139fc..5ebca09 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
@@ -442,8 +442,9 @@ private void createVerifyOpenPack(final Collection<ObjectId> interestings,
final Collection<ObjectId> uninterestings, final boolean thin,
final boolean ignoreMissingUninteresting)
throws MissingObjectException, IOException {
- writer.preparePack(interestings, uninterestings, thin,
- ignoreMissingUninteresting);
+ writer.setThin(thin);
+ writer.setIgnoreMissingUninteresting(ignoreMissingUninteresting);
+ writer.preparePack(interestings, uninterestings);
writer.writePack(cos);
verifyOpenPack(thin);
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
index 601ce71..83506bd 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
@@ -78,7 +78,7 @@
* Typical usage consists of creating instance intended for some pack,
* configuring options, preparing the list of objects by calling
* {@link #preparePack(Iterator)} or
- * {@link #preparePack(Collection, Collection, boolean, boolean)}, and finally
+ * {@link #preparePack(Collection, Collection)}, and finally
* producing the stream with {@link #writePack(OutputStream)}.
* </p>
* <p>
@@ -99,7 +99,7 @@
* Title of {@link ProgressMonitor} task used during counting objects to
* pack.
*
- * @see #preparePack(Collection, Collection, boolean, boolean)
+ * @see #preparePack(Collection, Collection)
*/
public static final String COUNTING_OBJECTS_PROGRESS = "Counting objects";
@@ -196,18 +196,20 @@
private boolean thin;
+ private boolean ignoreMissingUninteresting = true;
+
/**
* Create writer for specified repository.
* <p>
* Objects for packing are specified in {@link #preparePack(Iterator)} or
- * {@link #preparePack(Collection, Collection, boolean, boolean)}.
+ * {@link #preparePack(Collection, Collection)}.
*
* @param repo
* repository where objects are stored.
* @param monitor
* operations progress monitor, used within
* {@link #preparePack(Iterator)},
- * {@link #preparePack(Collection, Collection, boolean, boolean)}
+ * {@link #preparePack(Collection, Collection)}
* , or {@link #writePack(OutputStream)}.
*/
public PackWriter(final Repository repo, final ProgressMonitor monitor) {
@@ -218,15 +220,14 @@ public PackWriter(final Repository repo, final ProgressMonitor monitor) {
* Create writer for specified repository.
* <p>
* Objects for packing are specified in {@link #preparePack(Iterator)} or
- * {@link #preparePack(Collection, Collection, boolean, boolean)}.
+ * {@link #preparePack(Collection, Collection)}.
*
* @param repo
* repository where objects are stored.
* @param imonitor
* operations progress monitor, used within
* {@link #preparePack(Iterator)},
- * {@link #preparePack(Collection, Collection, boolean, boolean)}
- * ;
+ * {@link #preparePack(Collection, Collection)}
* @param wmonitor
* operations progress monitor, used within
* {@link #writePack(OutputStream)}.
@@ -259,7 +260,7 @@ public boolean isReuseDeltas() {
* use it if possible. Normally, only deltas with base to another object
* existing in set of objects to pack will be used. Exception is however
* thin-pack (see
- * {@link #preparePack(Collection, Collection, boolean, boolean)} and
+ * {@link #preparePack(Collection, Collection)} and
* {@link #preparePack(Iterator)}) where base object must exist on other
* side machine.
* <p>
@@ -367,6 +368,45 @@ public void setMaxDeltaDepth(int maxDeltaDepth) {
this.maxDeltaDepth = maxDeltaDepth;
}
+ /** @return true if this writer is producing a thin pack. */
+ public boolean isThin() {
+ return thin;
+ }
+
+ /**
+ * @param packthin
+ * a boolean indicating whether writer may pack objects with
+ * delta base object not within set of objects to pack, but
+ * belonging to party repository (uninteresting/boundary) as
+ * determined by set; this kind of pack is used only for
+ * transport; true - to produce thin pack, false - otherwise.
+ */
+ public void setThin(final boolean packthin) {
+ thin = packthin;
+ }
+
+ /**
+ * @return true to ignore objects that are uninteresting and also not found
+ * on local disk; false to throw a {@link MissingObjectException}
+ * out of {@link #preparePack(Collection, Collection)} if an
+ * uninteresting object is not in the source repository. By default,
+ * true, permitting gracefully ignoring of uninteresting objects.
+ */
+ public boolean isIgnoreMissingUninteresting() {
+ return ignoreMissingUninteresting;
+ }
+
+ /**
+ * @param ignore
+ * true if writer should ignore non existing uninteresting
+ * objects during construction set of objects to pack; false
+ * otherwise - non existing uninteresting objects may cause
+ * {@link MissingObjectException}
+ */
+ public void setIgnoreMissingUninteresting(final boolean ignore) {
+ ignoreMissingUninteresting = ignore;
+ }
+
/**
* Set the pack index file format version this instance will create.
*
@@ -447,28 +487,15 @@ public void preparePack(final Iterator<RevObject> objectsSource)
* @param uninterestingObjects
* collection of objects to be marked as uninteresting (end
* points of graph traversal).
- * @param packthin
- * a boolean indicating whether writer may pack objects with
- * delta base object not within set of objects to pack, but
- * belonging to party repository (uninteresting/boundary) as
- * determined by set; this kind of pack is used only for
- * transport; true - to produce thin pack, false - otherwise.
- * @param ignoreMissingUninteresting
- * true if writer should ignore non existing uninteresting
- * objects during construction set of objects to pack; false
- * otherwise - non existing uninteresting objects may cause
- * {@link MissingObjectException}
* @throws IOException
* when some I/O problem occur during reading objects.
*/
public void preparePack(
final Collection<? extends ObjectId> interestingObjects,
- final Collection<? extends ObjectId> uninterestingObjects,
- final boolean packthin, final boolean ignoreMissingUninteresting)
+ final Collection<? extends ObjectId> uninterestingObjects)
throws IOException {
- this.thin = packthin;
ObjectWalk walker = setUpWalker(interestingObjects,
- uninterestingObjects, ignoreMissingUninteresting);
+ uninterestingObjects);
findObjectsToPack(walker);
}
@@ -502,7 +529,7 @@ public ObjectId computeName() {
* Create an index file to match the pack file just written.
* <p>
* This method can only be invoked after {@link #preparePack(Iterator)} or
- * {@link #preparePack(Collection, Collection, boolean, boolean)} has been
+ * {@link #preparePack(Collection, Collection)} has been
* invoked and completed successfully. Writing a corresponding index is an
* optional feature that not all pack users may require.
*
@@ -760,8 +787,7 @@ private void writeChecksum() throws IOException {
private ObjectWalk setUpWalker(
final Collection<? extends ObjectId> interestingObjects,
- final Collection<? extends ObjectId> uninterestingObjects,
- final boolean ignoreMissingUninteresting)
+ final Collection<? extends ObjectId> uninterestingObjects)
throws MissingObjectException, IOException,
IncorrectObjectTypeException {
final ObjectWalk walker = new ObjectWalk(db);
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackPushConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackPushConnection.java
index a078d7e..dde1d26 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackPushConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackPushConnection.java
@@ -201,7 +201,8 @@ private void writePack(final Map<String, RemoteRefUpdate> refUpdates,
newObjects.add(r.getNewObjectId());
}
- writer.preparePack(newObjects, remoteObjects, thinPack, true);
+ writer.setThin(thinPack);
+ writer.preparePack(newObjects, remoteObjects);
writer.writePack(out);
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BundleWriter.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BundleWriter.java
index a22a31d..8000837 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/BundleWriter.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BundleWriter.java
@@ -166,7 +166,8 @@ public void writeBundle(OutputStream os) throws IOException {
inc.addAll(include.values());
for (final RevCommit r : assume)
exc.add(r.getId());
- packWriter.preparePack(inc, exc, exc.size() > 0, true);
+ packWriter.setThin(exc.size() > 0);
+ packWriter.preparePack(inc, exc);
final Writer w = new OutputStreamWriter(os, Constants.CHARSET);
w.write(TransportBundle.V2_BUNDLE_SIGNATURE);
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java b/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
index 204859c..45d57b3 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/UploadPack.java
@@ -464,7 +464,8 @@ private void sendPack() throws IOException {
final PackWriter pw;
pw = new PackWriter(db, pm, NullProgressMonitor.INSTANCE);
pw.setDeltaBaseAsOffset(options.contains(OPTION_OFS_DELTA));
- pw.preparePack(wantAll, commonBase, thin, true);
+ pw.setThin(thin);
+ pw.preparePack(wantAll, commonBase);
if (options.contains(OPTION_INCLUDE_TAG)) {
for (final Ref r : refs.values()) {
final RevObject o;
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkPushConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkPushConnection.java
index 3246ee6..acdb5b8 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkPushConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkPushConnection.java
@@ -210,7 +210,7 @@ private void sendpack(final List<RemoteRefUpdate> updates,
if (r.getPeeledObjectId() != null)
have.add(r.getPeeledObjectId());
}
- pw.preparePack(need, have, false, true);
+ pw.preparePack(need, have);
// We don't have to continue further if the pack will
// be an empty pack, as the remote has all objects it
--
1.6.2.1.471.g682837
^ permalink raw reply related
* Re: Git for collaborative web development
From: Sverre Rabbelier @ 2009-03-26 19:44 UTC (permalink / raw)
To: Mr.SpOOn; +Cc: git
In-Reply-To: <8f67b6f80903261241s7bbb179bwf5e9fa64f657ca1d@mail.gmail.com>
Heya,
On Thu, Mar 26, 2009 at 20:41, Mr.SpOOn <mr.spoon21@gmail.com> wrote:
> That seems cool. I'll take a look to some documentation to understand it :D
There's probably some typo's and thinko's in there, but you get the
idea. You can use aliases in git to define your own commands. If you
do not prefix the command with a bang it is interpreted as git
command, I use this one to review the changes I made with respect to
origin:
$ git config alias.new "log -C -M --reverse -p origin/master.."
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/2] Add feature release instructions to MaintNotes addendum
From: Junio C Hamano @ 2009-03-26 20:28 UTC (permalink / raw)
To: Raman Gupta; +Cc: Nanako Shiraishi, git
In-Reply-To: <49CB8871.2020605@fastmail.fm>
Raman Gupta <rocketraman@fastmail.fm> writes:
> Nanako Shiraishi wrote:
>> Quoting rocketraman@fastmail.fm:
>>
>>> + - The 'maint' branch is updated to the new release.
>>> +
>>> + $ git checkout maint
>>> + $ git merge master
>>> +
>>> + This is equivalent to deleting maint and recreating it from
>>> + master, but it preserves the maint reflog.
>>
>> After giving a recipe that is better than an alternative, what's
>> the point of describing an inferior alternative as "equivalent",
>> when it is obviously not "equivalent"?
>
> Is this better:
>
> The resulting maint tree is equivalent to deleting maint and
> recreating it from the tip of master, but merging from master
> preserves the maint reflog.
It is unclear what you are trying to explain with these two (in your
original) or three (your rewrite) lines. As an explanation for the two
command sequence, I would expect to see:
"This merges the tip of the master into maint".
But that is literally what the command sequence does, so it goes without
saying.
If there is anything that needs to be said further, I think it is not how
delete-then-recreate is inappropriate (I do not think it is even worth
teaching). But you may want to explain the reason _why_ maint gets this
update from master. I thought the explanation "... is updated to the new
release" already covers that motivation, but if you want to make the
description really novice-friendly, you _could_ say something like:
Now a new release X.Y.Z is out, the 'maint' branch will be used to
manage the fixes to it. The branch used to be used for managing the
fixes to X.Y.(Z-1), and does not have any feature development that
happened between X.Y.(Z-1) and X.Y.Z. Because these changes are
contained in the 'master' branch, we can merge 'master' to 'maint' to
have the latter have them, which prepares it to be used for managing
the fixes to X.Y.Z.
I personally would not want to see somebody who needs the above to be
explained to take over git maintenance after I get hit by a wayward bus,
by the way ;-)
^ permalink raw reply
* Re: [PATCH] format-patch: add arbitrary email headers
From: Junio C Hamano @ 2009-03-26 20:29 UTC (permalink / raw)
To: Michael Hendricks; +Cc: git
In-Reply-To: <20090326164212.GF29569@ginosko.ndrix.org>
Michael Hendricks <michael@ndrix.org> writes:
> Perhaps --add-header is a better name for this argument. That name at
> least makes it clear that headers specified on the command line are
> cumulative. If someone has a use case for --no-extra-headers, they
> can add it later and --add-header retains the same meaning.
Sounds very sane. Thanks.
^ permalink raw reply
* [PATCH 0/2] Make local branches behave like remote branches when --tracked
From: Michael J Gruber @ 2009-03-26 20:53 UTC (permalink / raw)
To: git; +Cc: Daniel Barkalow, Johannes Schindelin, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0903201358440.19665@iabervon.org>
[Sorry it took so long to finish... This is from my "sick bed", I hope
it doesn't show ;)]
This mini series makes local branches behave the same as remote ones
when they are used as --tracked branches. This means differences are
reported by git status and git checkout, and also that the soon to be
released tracking branch short cut (aka BEL) will work.
Michael J Gruber (2):
Test for local branches being followed with --track
Make local branches behave like remote branches when --tracked
remote.c | 9 +++++----
t/t6040-tracking-info.sh | 10 +++++++++-
2 files changed, 14 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH 1/2] Test for local branches being followed with --track
From: Michael J Gruber @ 2009-03-26 20:53 UTC (permalink / raw)
To: git; +Cc: Daniel Barkalow, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1238100805-19619-1-git-send-email-git@drmicha.warpmail.net>
According to the documentation, it is perfectly okay to follow local
branches using the --track option. Introduce a test which checks whether
they behave the same. Currently 1 test fails.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/t6040-tracking-info.sh | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index ba90601..2a2b6b6 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -29,7 +29,9 @@ test_expect_success setup '
git checkout -b b4 origin &&
advance e &&
advance f
- )
+ ) &&
+ git checkout -b follower --track master &&
+ advance g
'
script='s/^..\(b.\)[ 0-9a-f]*\[\([^]]*\)\].*/\1 \2/p'
@@ -56,6 +58,12 @@ test_expect_success 'checkout' '
grep "have 1 and 1 different" actual
'
+test_expect_failure 'checkout with local tracked branch' '
+ git checkout master &&
+ git checkout follower >actual
+ grep "is ahead of" actual
+'
+
test_expect_success 'status' '
(
cd test &&
--
1.6.2.1.507.g0e68d
^ permalink raw reply related
* [PATCH 2/2] Make local branches behave like remote branches when --tracked
From: Michael J Gruber @ 2009-03-26 20:53 UTC (permalink / raw)
To: git; +Cc: Daniel Barkalow, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1238100805-19619-2-git-send-email-git@drmicha.warpmail.net>
This makes sure that local branches, when followed using --track, behave
the same as remote ones (e.g. differences being reported by git status
and git checkout). This fixes 1 known failure.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
remote.c | 9 +++++----
t/t6040-tracking-info.sh | 2 +-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/remote.c b/remote.c
index 2b037f1..5d2d7a1 100644
--- a/remote.c
+++ b/remote.c
@@ -1170,8 +1170,9 @@ struct branch *branch_get(const char *name)
for (i = 0; i < ret->merge_nr; i++) {
ret->merge[i] = xcalloc(1, sizeof(**ret->merge));
ret->merge[i]->src = xstrdup(ret->merge_name[i]);
- remote_find_tracking(ret->remote,
- ret->merge[i]);
+ if(remote_find_tracking(ret->remote,
+ ret->merge[i]) && !strcmp(ret->remote_name, "."))
+ ret->merge[i]->dst = xstrdup(ret->merge_name[i]);
}
}
}
@@ -1449,8 +1450,8 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
return 0;
base = branch->merge[0]->dst;
- if (!prefixcmp(base, "refs/remotes/")) {
- base += strlen("refs/remotes/");
+ if (!prefixcmp(base, "refs/")) {
+ base += strlen("refs/");
}
if (!num_theirs)
strbuf_addf(sb, "Your branch is ahead of '%s' "
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index 2a2b6b6..3d6db4d 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -58,7 +58,7 @@ test_expect_success 'checkout' '
grep "have 1 and 1 different" actual
'
-test_expect_failure 'checkout with local tracked branch' '
+test_expect_success 'checkout with local tracked branch' '
git checkout master &&
git checkout follower >actual
grep "is ahead of" actual
--
1.6.2.1.507.g0e68d
^ permalink raw reply related
* Re: [PATCH 0/2] Make local branches behave like remote branches when --tracked
From: Michael J Gruber @ 2009-03-26 20:57 UTC (permalink / raw)
Cc: git, Daniel Barkalow, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1238100805-19619-1-git-send-email-git@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 26.03.2009 21:53:
> [Sorry it took so long to finish... This is from my "sick bed", I hope
> it doesn't show ;)]
>
> This mini series makes local branches behave the same as remote ones
> when they are used as --tracked branches. This means differences are
> reported by git status and git checkout, and also that the soon to be
> released tracking branch short cut (aka BEL) will work.
>
> Michael J Gruber (2):
> Test for local branches being followed with --track
> Make local branches behave like remote branches when --tracked
>
> remote.c | 9 +++++----
> t/t6040-tracking-info.sh | 10 +++++++++-
> 2 files changed, 14 insertions(+), 5 deletions(-)
>
Sorry, I meant to point out also that 2/2 changes the display format of
the branch: refs/ is removed rather than refs/remotes/, if present. This
makes for unique branch names ready to copy&paste (they were not
necessarily unique before).
Michael
^ permalink raw reply
* [PATCH] Documentation: format-patch --root clarifications
From: Thomas Rast @ 2009-03-26 17:29 UTC (permalink / raw)
To: git; +Cc: Guennadi Liakhovetski, Junio C Hamano, Jeff King
In-Reply-To: <Pine.LNX.4.64.0903231732150.6370@axis700.grange>
Users were confused about the meaning and use of the --root option.
Notably, since 68c2ec7 (format-patch: show patch text for the root
commit, 2009-01-10), --root has nothing to do with showing the patch
text for the root commit any more.
Shorten and clarify the corresponding paragraph in the DESCRIPTION
section, document --root under OPTIONS, and add an explicit note that
root commits are formatted regardless.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Guennadi Liakhovetski wrote:
> On Mon, 23 Mar 2009, Thomas Rast wrote:
>
> > > git-format-patch -1 produces a 0-byte long patch.
> >
> > That is admittedly weird and probably deserves a fix and/or suggestion
> > to use --root.
I finally got around to looking at this again. The 0-byte patch issue
is fixed since 1.6.2 (68c2ec7 mentioned above), so the above no longer
applies. The patch merely tries to make this clearer in the
documentation.
> Yes, I can understand this, still from the high-level PoV, this looks
> inconsistent:
>
> git-format-patch HEAD
>
> never produces anything, which means for me, I'm trying to extract commits
> for a 0-length range.
>
> git-format-patch HEAD^
>
> Usually produces the "current" or the "last" commit - except if you're
> currently on the first commit... But I'm not insisting on this one - maybe
> you're right, it just _does_ look weird.
>
> Just try to forget about the meaning of the command. You are somewhere on
> the commit timeline. You enter "some" command, which usually produces
> exactly one - the most recent commit. So, I would expect this to work
> always when there is at least one commit in the tree.
It's not like this is voodoo, the problem is that you're reading a
different meaning into the observable behaviour than what the revision
walker does.
First, note that rule 1 in the git-format-patch manpage simply states
that specifying a single <commit> is equivalent to specifying the
range '<commit>..', i.e., '<commit>..HEAD'.
With that out of the way, turn to man git-rev-list and note that
'<commit>..HEAD' is another way of spelling '^<commit> HEAD'. Which
means to list all commits that are reachable from HEAD, but not
<commit>. Thus, in *linear* history, 'HEAD^..' always means the
current commit, but that's just a special case. If you're on a merge
commit, 'HEAD^..' only excludes commits reachable from the *first*
parent of the merge, so (unless the merge was trivial) this range
actually contains more than one commit.
And it should become clearer that in order to reach (and thus
include/exclude) anything, both ends of the revision range must
exist. So if there is no parent of the current commit (i.e., it is a
root), you cannot use the HEAD^ syntax.
Admittedly, the special handling of <since> in git-format-patch
differs from all(?) other revision walking commands (log, rev-list,
bundle, fast-export).
Documentation/git-format-patch.txt | 21 ++++++++++++---------
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index c2eb5fa..c105925 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -40,15 +40,11 @@ There are two ways to specify which commits to operate on.
REVISIONS" section in linkgit:git-rev-parse[1]) means the
commits in the specified range.
-A single commit, when interpreted as a <revision range>
-expression, means "everything that leads to that commit", but
-if you write 'git format-patch <commit>', the previous rule
-applies to that command line and you do not get "everything
-since the beginning of the time". If you want to format
-everything since project inception to one commit, say "git
-format-patch \--root <commit>" to make it clear that it is the
-latter case. If you want to format a single commit, you can do
-this with "git format-patch -1 <commit>".
+The first rule takes precedence in the case of a single <commit>. To
+apply the second rule, i.e., format everything since the beginning of
+history up until <commit>, use the '\--root' option: "git format-patch
+\--root <commit>". If you want to format only <commit> itself, you
+can do this with "git format-patch -1 <commit>".
By default, each output file is numbered sequentially from 1, and uses the
first line of the commit message (massaged for pathname safety) as
@@ -182,6 +178,13 @@ not add any suffix.
applied. By default the contents of changes in those files are
encoded in the patch.
+--root::
+ Treat the revision argument as a <revision range>, even if it
+ is just a single commit (that would normally be treated as a
+ <since>). Note that root commits included in the specified
+ range are always formatted as creation patches, independently
+ of this flag.
+
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each message
--
1.6.2.1.558.ge131
^ permalink raw reply related
* [PATCH] gitk: Mark forgotten string for translation
From: Christian Stimming @ 2009-03-26 20:13 UTC (permalink / raw)
To: git, Paul Mackerras
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index a7294a1..9047cc8 100755
--- a/gitk
+++ b/gitk
@@ -6527,7 +6527,7 @@ proc appendrefs {pos ids var} {
}
}
if {[llength $tags] > $maxrefs} {
- $ctext insert $pos "many ([llength $tags])"
+ $ctext insert $pos "[mc "many"] ([llength $tags])"
} else {
set tags [lsort -index 0 -decreasing $tags]
set sep {}
--
1.6.1.rc3.51.g5832d
^ permalink raw reply related
* Re: [PATCH 1/2] init: support --import to add all files and commit right after init
From: Markus Heidelberg @ 2009-03-26 21:23 UTC (permalink / raw)
To: Santi Béjar
Cc: Jeff King, Johannes Schindelin, Nguyễn Thái Ngọc,
git
In-Reply-To: <adf1fd3d0903250549l60e4a2d1j8bd57ba66d24a678@mail.gmail.com>
Santi Béjar, 25.03.2009:
> 2009/3/25 Jeff King <peff@peff.net>:
> > On Wed, Mar 25, 2009 at 01:38:30PM +0100, Johannes Schindelin wrote:
> >
> >> > > +If no message is given, "Initial commit" will be used.
> >> >
> >> > Why a default message and not running the editor?
> >>
> >> Because I would say "Initial commit" anyway.
>
> And I would say "Commit inicial".
And I would describe the current state in a few words.
Invoking an editor is more universal and I don't think the majority
would be contented with "Initial commit".
Markus
^ permalink raw reply
* [EGIT] [PATCH RFC v1 4/5] Do not set .git as a Team ignore pattern
From: Ferry Huberts @ 2009-03-26 21:34 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Robin Rosenberg, Ferry Huberts
In-Reply-To: <cover.1238102327.git.ferry.huberts@pelagic.nl>
The .git ignore pattern is only valid in the context that it matches
a .git directory that is actually a repository.
Signed-off-by: Ferry Huberts <ferry.huberts@pelagic.nl>
---
org.spearce.egit.core/plugin.xml | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/org.spearce.egit.core/plugin.xml b/org.spearce.egit.core/plugin.xml
index 77ecebf..ff24ac7 100644
--- a/org.spearce.egit.core/plugin.xml
+++ b/org.spearce.egit.core/plugin.xml
@@ -11,10 +11,4 @@
id="org.spearce.egit.core.GitProvider">
</repository>
</extension>
- <extension
- point="org.eclipse.team.core.ignore">
- <ignore
- enabled="true"
- pattern=".git"/>
- </extension>
</plugin>
--
1.6.0.6
^ permalink raw reply related
* [EGIT] [PATCH RFC v1 3/5] Optimise ignore evaluation
From: Ferry Huberts @ 2009-03-26 21:34 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Robin Rosenberg, Ferry Huberts
In-Reply-To: <cover.1238102327.git.ferry.huberts@pelagic.nl>
Do not call GitIgnoreData.isIgnored(resource) multiple times when
not needed.
Signed-off-by: Ferry Huberts <ferry.huberts@pelagic.nl>
---
.../org/spearce/egit/core/op/TrackOperation.java | 5 +++--
.../decorators/DecoratableResourceAdapter.java | 9 ++-------
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java b/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java
index 4a4b93c..a64c1dd 100644
--- a/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java
+++ b/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java
@@ -94,14 +94,15 @@ public boolean visit(IResource resource) throws CoreException {
// first. If a resource within a ignored folder is marked
// we ignore it here, i.e. there is no way to unmark it expect
// by explicitly selecting and invoking track on it.
+ boolean ignored = GitIgnoreData.isIgnored(resource);
if (resource.getType() == IResource.FILE) {
Entry entry = index.getEntry(repoPath);
- if (!GitIgnoreData.isIgnored(resource) || ((entry != null) && entry.isAssumedValid())) {
+ if (!ignored || ((entry != null) && entry.isAssumedValid())) {
entry = index.add(rm.getWorkDir(), new File(rm.getWorkDir(), repoPath));
entry.setAssumeValid(false);
}
}
- if (GitIgnoreData.isIgnored(resource))
+ if (ignored)
return false;
} catch (IOException e) {
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/DecoratableResourceAdapter.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/DecoratableResourceAdapter.java
index 4c740d5..7b48fd8 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/DecoratableResourceAdapter.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/DecoratableResourceAdapter.java
@@ -118,7 +118,7 @@ private void extractResourceProperties(TreeWalk treeWalk) {
if (resourceEntry == null)
return;
- if (isIgnored(resourceEntry.getResource())) {
+ if (GitIgnoreData.isIgnored(resourceEntry.getResource())) {
ignored = true;
return;
}
@@ -261,7 +261,7 @@ public boolean shouldBeRecursive() {
private void extractContainerProperties(TreeWalk treeWalk) throws IOException {
- if (isIgnored(resource)) {
+ if (GitIgnoreData.isIgnored(resource)) {
ignored = true;
return;
}
@@ -361,11 +361,6 @@ private static boolean timestampMatches(DirCacheEntry indexEntry,
}
}
- private static boolean isIgnored(IResource resource) {
- // TODO: Also read ignores from .git/info/excludes et al.
- return GitIgnoreData.isIgnored(resource);
- }
-
public String getName() {
return resource.getName();
}
--
1.6.0.6
^ permalink raw reply related
* [EGIT] [PATCH RFC v1 2/5] Enable the ignore handling of the plugin
From: Ferry Huberts @ 2009-03-26 21:34 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Robin Rosenberg, Ferry Huberts
In-Reply-To: <cover.1238102327.git.ferry.huberts@pelagic.nl>
Signed-off-by: Ferry Huberts <ferry.huberts@pelagic.nl>
---
org.spearce.egit.core/META-INF/MANIFEST.MF | 1 +
.../org/spearce/egit/core/op/TrackOperation.java | 6 +++---
.../decorators/DecoratableResourceAdapter.java | 4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/org.spearce.egit.core/META-INF/MANIFEST.MF b/org.spearce.egit.core/META-INF/MANIFEST.MF
index 20df15f..546ea72 100644
--- a/org.spearce.egit.core/META-INF/MANIFEST.MF
+++ b/org.spearce.egit.core/META-INF/MANIFEST.MF
@@ -13,6 +13,7 @@ Require-Bundle: org.eclipse.core.runtime,
org.eclipse.core.filesystem,
org.eclipse.ui
Export-Package: org.spearce.egit.core,
+ org.spearce.egit.core.ignores;x-friends:="org.spearce.egit.ui",
org.spearce.egit.core.internal.storage;x-friends:="org.spearce.egit.ui",
org.spearce.egit.core.internal.util;x-friends:="org.spearce.egit.ui",
org.spearce.egit.core.op,
diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java b/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java
index 29b4344..4a4b93c 100644
--- a/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java
+++ b/org.spearce.egit.core/src/org/spearce/egit/core/op/TrackOperation.java
@@ -24,9 +24,9 @@
import org.eclipse.core.runtime.IAdaptable;
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.core.runtime.NullProgressMonitor;
-import org.eclipse.team.core.Team;
import org.spearce.egit.core.Activator;
import org.spearce.egit.core.CoreText;
+import org.spearce.egit.core.ignores.GitIgnoreData;
import org.spearce.egit.core.project.RepositoryMapping;
import org.spearce.jgit.lib.GitIndex;
import org.spearce.jgit.lib.GitIndex.Entry;
@@ -96,12 +96,12 @@ public boolean visit(IResource resource) throws CoreException {
// by explicitly selecting and invoking track on it.
if (resource.getType() == IResource.FILE) {
Entry entry = index.getEntry(repoPath);
- if (!Team.isIgnoredHint(resource) || entry != null && entry.isAssumedValid()) {
+ if (!GitIgnoreData.isIgnored(resource) || ((entry != null) && entry.isAssumedValid())) {
entry = index.add(rm.getWorkDir(), new File(rm.getWorkDir(), repoPath));
entry.setAssumeValid(false);
}
}
- if (Team.isIgnoredHint(resource))
+ if (GitIgnoreData.isIgnored(resource))
return false;
} catch (IOException e) {
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/DecoratableResourceAdapter.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/DecoratableResourceAdapter.java
index 5c68d5b..4c740d5 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/DecoratableResourceAdapter.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/DecoratableResourceAdapter.java
@@ -22,10 +22,10 @@
import org.eclipse.core.resources.IResource;
import org.eclipse.core.resources.IWorkspaceRoot;
import org.eclipse.jface.preference.IPreferenceStore;
-import org.eclipse.team.core.Team;
import org.spearce.egit.core.AdaptableFileTreeIterator;
import org.spearce.egit.core.ContainerTreeIterator;
import org.spearce.egit.core.ContainerTreeIterator.ResourceEntry;
+import org.spearce.egit.core.ignores.GitIgnoreData;
import org.spearce.egit.core.project.RepositoryMapping;
import org.spearce.egit.ui.Activator;
import org.spearce.egit.ui.UIPreferences;
@@ -363,7 +363,7 @@ private static boolean timestampMatches(DirCacheEntry indexEntry,
private static boolean isIgnored(IResource resource) {
// TODO: Also read ignores from .git/info/excludes et al.
- return Team.isIgnoredHint(resource);
+ return GitIgnoreData.isIgnored(resource);
}
public String getName() {
--
1.6.0.6
^ permalink raw reply related
* [EGIT] [PATCH RFC v1 0/5] Add (static) ignore functionality to EGit
From: Ferry Huberts @ 2009-03-26 21:34 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Robin Rosenberg, Ferry Huberts
This is the first - early - code that adds ignore functionality to EGit.
Currently it reads in all ignore patterns upon workspace startup into an
ignore cache. From this cache the ignore state of a resource is evaluated
in the same fashion as git does.
The code does not yet react to changes in ignore files but I'm planning to add
that soon and I can share a lot of code for that.
I send this code to receive feedback and to give you insight into what I'm
doing with it. I'm new both to EGit programming and Eclipse programming so
there might be things that could be done more elegantly :-)
A few notes:
- The patches are rebased on the current master (e3440623)
- The order of the patches must be re-arranged, but that is rather easy. The
correct order - once finished - would be:
Build up the ignore patterns cache upon workspace startup.
Use the ignore patterns cache to determine ignores
Enable the ignore handling of the plugin
Optimise ignore evaluation
Do not set .git as a Team ignore pattern
- The core.excludesfile code is currently untested, the other code seems to be
in a good state.
- There are a few FIXMEs in the code with questions and tasks. It's a work in
progress and these will disappear.
Ferry Huberts (5):
Build up the ignore patterns cache upon workspace startup.
Enable the ignore handling of the plugin
Optimise ignore evaluation
Do not set .git as a Team ignore pattern
Use the ignore patterns cache to determine ignores
org.spearce.egit.core/META-INF/MANIFEST.MF | 1 +
org.spearce.egit.core/plugin.xml | 6 -
.../src/org/spearce/egit/core/ignores/DType.java | 44 ++
.../src/org/spearce/egit/core/ignores/Exclude.java | 243 +++++++++
.../spearce/egit/core/ignores/GitIgnoreData.java | 180 +++++++
.../org/spearce/egit/core/ignores/IgnoreFile.java | 82 +++
.../egit/core/ignores/IgnoreFileOutside.java | 543 ++++++++++++++++++++
.../egit/core/ignores/IgnoreProjectCache.java | 245 +++++++++
.../egit/core/ignores/IgnoreRepositoryCache.java | 358 +++++++++++++
.../org/spearce/egit/core/op/TrackOperation.java | 7 +-
.../spearce/egit/core/project/GitProjectData.java | 8 +
.../decorators/DecoratableResourceAdapter.java | 11 +-
org.spearce.jgit/META-INF/MANIFEST.MF | 1 +
13 files changed, 1712 insertions(+), 17 deletions(-)
create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/DType.java
create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/Exclude.java
create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/GitIgnoreData.java
create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/IgnoreFile.java
create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/IgnoreFileOutside.java
create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/IgnoreProjectCache.java
create mode 100644 org.spearce.egit.core/src/org/spearce/egit/core/ignores/IgnoreRepositoryCache.java
^ 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