* [PATCH] Define a version of lstat(2) specially for copy operation
From: Alex Riesen @ 2009-03-17 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Jeff King, layer, git
In-Reply-To: <7v63i7ridk.fsf@gitster.siamese.dyndns.org>
So that Cygwin port can continue work around its supporting
library and get access to its faked file attributes.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Junio C Hamano, Tue, Mar 17, 2009 21:42:31 +0100:
> But isn't this something shops that do deploy Cygwin version of git want
> to see fixed, so that they can have a site-wide policy implemented in the
Frankly, I doubt they know or care.
> hooks copied from templates? I think we could pass mode 0 to copy_files()
> and have the function special case it (and allow a platform specific
> copy_files() implementated by Cygwin). lstat() in the copy_templates_1()
> codepath is primarily done to see if we need to descend into a directory
> or symlink() and our use of st.st_mode to pass to copy_files() is a no
> cost side effect on platforms with x-bit support.
And I don't think that the platform broken in so many ways deserves
that kind of treatement. Maybe this patch is enough. Will test it
tomorrow, when I get to mine so much hated Windows system.
> >> access(..., X_OK), not lstat(). We don't play games with access(), do we?
> > access(..., X_OK) will return -1.
>
> That codepath would also need to be fixed if Cygwin wants to use hooks, I
> would guess.
I hope not. In the reply to Johannes' example I was referring to the
copied file, the one which was created with open(..., O_CREAT..., 0666),
0666 being there because of our lstat stub.
builtin-init-db.c | 2 +-
git-compat-util.h | 5 +++++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index ee3911f..f3f781b 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -66,7 +66,7 @@ static void copy_templates_1(char *path, int baselen,
else
exists = 1;
- if (lstat(template, &st_template))
+ if (lstat_for_copy(template, &st_template))
die("cannot stat template %s", template);
if (S_ISDIR(st_template.st_mode)) {
diff --git a/git-compat-util.h b/git-compat-util.h
index 878d83d..4c23478 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,11 +85,16 @@
#undef _XOPEN_SOURCE
#include <grp.h>
#define _XOPEN_SOURCE 600
+static inline int lstat_for_copy(const char *file_name, struct stat *buf)
+{
+ return lstat(file_name, buf);
+}
#include "compat/cygwin.h"
#else
#undef _ALL_SOURCE /* AIX 5.3L defines a struct list with _ALL_SOURCE. */
#include <grp.h>
#define _ALL_SOURCE 1
+#define lstat_for_copy lstat
#endif
#else /* __MINGW32__ */
/* pull in Windows compatibility stuff */
--
1.6.2.1.171.g3422
^ permalink raw reply related
* Re: [PATCH] builtin-tag.c: remove global variable to use the callback data of git-config.
From: Johannes Schindelin @ 2009-03-17 22:27 UTC (permalink / raw)
To: Carlos Rica; +Cc: gitster, git
In-Reply-To: <1b46aba20903171057r4fb4697eo3b8abc62a45fe858@mail.gmail.com>
Hi,
On Tue, 17 Mar 2009, Carlos Rica wrote:
> On Tue, Mar 17, 2009 at 4:47 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> > On Tue, 17 Mar 2009, Carlos Rica wrote:
> >> @@ -164,11 +162,10 @@ static int do_sign(struct strbuf *buffer)
> >> int len;
> >> int i, j;
> >>
> >> - if (!*signingkey) {
> >> - if (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),
> >> - sizeof(signingkey)) > sizeof(signingkey) - 1)
> >> - return error("committer info too long.");
> >> - bracket = strchr(signingkey, '>');
> >> + if (!signingkey->buf[0]) {
> >
> > It is probably better to ask for !signingkey->len (think of trying to
> > understand the code in 6 months from now).
>
> I was in doubt here. By avoiding the use of signingkey->len I was
> trying to say that you cannot rely in such field if we touch the
> buffer directly, as it happens below:
>
> bracket = strchr(signingkey->buf, '>');
> if (bracket)
> bracket[1] = '\0';
Oh, I missed that. It should read
if (bracket)
strbuf_setlen(signingkey, bracket + 1 - signingkey->buf);
instead.
Ciao,
Dscho
^ permalink raw reply
* Re: Ability to edit message from git rebase --interactive.
From: Johannes Schindelin @ 2009-03-17 22:31 UTC (permalink / raw)
To: Olivier Goffart; +Cc: git
In-Reply-To: <200903171953.23650.ogoffart@kde.org>
Hi,
On Tue, 17 Mar 2009, Olivier Goffart wrote:
> I use git in a workflow in wich we often need to edit the message logs
> of some commits. The way we do it is using git rebase -i and choose
> edit. But then you need to do git commit --amend and git rebase
> --continue, which is error prone and add more useless steps.
>
> The attached patch add a new keyword to git rebase interactive to just
> edit the message log.
>
> I was told on IRC that this has been discussed already not so long ago,
> and looking on the archive[1], all i seen was bikesheeding . Here is a
> patch :-)
Unfortunately, the implementation is not the problem, but picking the best
name. The first letter "m" will be taken in a short while by the "merge"
command for "rebase -i -p", so "message" is out, sadly.
But the "rephrase" command will be part of the "rebase -i -p" series when
I will finally be able to submit it.
Ciao,
Dscho
^ permalink raw reply
* Re: push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)
From: Johannes Schindelin @ 2009-03-17 22:53 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Junio C Hamano
In-Reply-To: <20090318063053.6117@nanako3.lavabit.com>
Hi,
On Wed, 18 Mar 2009, Nanako Shiraishi wrote:
> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Sat, 14 Mar 2009, Junio C Hamano wrote:
> >
> >> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit
> >> - New config push.default to decide default behavior for push
> >>
> >> Replaced the old series with the first step to allow a smooth
> >> transition. Some might argue that this should not give any warning
> >> but just give users this new configuration to play with first, and
> >> after we know we are going to switch default some day, start the
> >> warning.
> >
> > IIRC Steffen posted a patch series earlier, where he initialized
> > remote.origin.push upon clone (I am not sure if he provided a
> > corresponding patch for checkout --track), but personally, I think
> > that would be nicer than having a push.default.
>
> Isn't recent trend to avoid such inconsistency between behavior in an
> existing repository and behavior in a newly created repository? For
> example, Jeff calls such inconsistency in
>
> http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100433
>
> as "this breaks in my repo, but when I make a test repo it works". Junio
> even called it 'madness' (^_^;)
My point is that it is _not_ an inconsistency.
It has a default setting. One that already is well established. Push the
matching refs.
But you can override it by setting the config variable. Which is also
well established.
The only thing Steffen's patches would have changed would be to set the
default differently now.
Which is not that much of a 'madness'.
Especially if you think about changing the default, which _will_ make for
angry users ("why did you change the default? I _liked_ it! Please
revert _now_!").
Ciao,
Dscho
^ permalink raw reply
* Re: [JGIT PATCH 3/4] Cap the number of open files in the WindowCache
From: Robin Rosenberg @ 2009-03-17 22:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1237252570-8596-4-git-send-email-spearce@spearce.org>
tisdag 17 mars 2009 02:16:09 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> If we detect a file open failure while opening a pack we halve
> the number of permitted open files and try again, until we reach
> a lower bound of 16 open files. Needing to go lower may indicate
> a file descriptor leak in the host application.
...
> + TRY_OPEN: for (;;) {
> + try {
> + openFileCount++;
> + releaseMemory();
> + runClearedWindowQueue();
> + wp.openCount = 1;
> + wp.cacheOpen();
> + break;
> + } catch (IOException ioe) {
> + openFileCount--;
> + if ("Too many open files".equals(ioe.getMessage())
> + && maxFileCount > 16) {
The output of getMessage isn't that simple to interpret. Here it is filename+" (Too many files open)",
and on other platforms it is probably something else. This goes for the message part of most exceptions
thrown from platform specific code like file i/o socket i/o etc. The type of exception is a FileNotFoundException,
btw.
I wonder whether your code works on any platform.
^ permalink raw reply
* Re: [JGIT PATCH 3/4] Cap the number of open files in the WindowCache
From: Shawn O. Pearce @ 2009-03-17 23:08 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200903172359.32595.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> tisdag 17 mars 2009 02:16:09 skrev "Shawn O. Pearce" <spearce@spearce.org>:
>
> > If we detect a file open failure while opening a pack we halve
> > the number of permitted open files and try again, [...]
>
> The output of getMessage isn't that simple to interpret. Here it is filename+" (Too many files open)",
> and on other platforms it is probably something else. This goes for the message part of most exceptions
> thrown from platform specific code like file i/o socket i/o etc. The type of exception is a FileNotFoundException,
> btw.
>
> I wonder whether your code works on any platform.
Arrrgh.
OK. Maybe scrap that part of the patch then?
Its too bad they don't have a specific type of exception for this,
nor do they have a way to hold onto file descriptors under a type
like a SoftReference where the runtime can whack them if you have
too many.
I guess that's why Hadoop HBase just tells you to up your fd ulimit
to 32767. :-)
--
Shawn.
^ permalink raw reply
* [PATCH] git config: clarify bool types
From: Felipe Contreras @ 2009-03-17 23:13 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano, Felipe Contreras
The value is what it is, the --bool and --bool-or-int options don't
specify the value type, just how it is interpreted. For example: a value
of '1' can be interpreted as 'true'.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
This applies on top of the 'next' branch.
builtin-config.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index 1a3baa1..c3a0176 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
OPT_GROUP("Type"),
- OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
+ OPT_BIT(0, "bool", &types, "value is intepreted as bool (\"true\" or \"false\")", TYPE_BOOL),
OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
- OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
+ OPT_BIT(0, "bool-or-int", &types, "value is interpreted either as bool or int", TYPE_BOOL_OR_INT),
OPT_GROUP("Other"),
OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
OPT_END(),
--
1.6.2.313.g33352
^ permalink raw reply related
* Re: Local clone checks out wrong branch based on remote HEAD
From: Junio C Hamano @ 2009-03-17 23:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Tom Preston-Werner, git
In-Reply-To: <alpine.LNX.1.00.0903171530160.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> ... I think there's also been discussion of a
> protocol extension to transmit the information, although I don't know
> where that ended up.
You can find them in the list of threads posted nearby.
The first round's protocol extension was not quite backward compatible
but in a benign way, in that it did not break anything but induced a
harmless warning from older ls-remote. The second round did not have such
flaw but it got a "Yuck".
From: Jeff King <peff@peff.net>
Date: Mon, 1 Dec 2008 12:44:15 -0500
Message-ID: <20081201174414.GA22185@coredump.intra.peff.net>
Subject: Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
I somehow feel that the "Yuck" was addressed not to the patches but to the
problem the patch needs to address.
We could resurrect it if somebody is interested.
^ permalink raw reply
* Re: [PATCH] contrib/difftool: use a separate config namespace for difftool commands
From: Junio C Hamano @ 2009-03-17 23:42 UTC (permalink / raw)
To: markus.heidelberg; +Cc: David Aguilar, Jay Soffian, git
In-Reply-To: <200903172054.46063.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> David Aguilar, 10.03.2009:
>> On 0, Jay Soffian <jaysoffian@gmail.com> wrote:
>> > On Mon, Mar 9, 2009 at 5:12 AM, David Aguilar <davvid@gmail.com> wrote:
>> > > contrib/difftool/git-difftool | 6 +++---
>> >
>> > Aside, (for Junio I guess...), what's the reason this command is in
>> > contrib, and by what criteria might it graduate to being installed
>> > with the rest of the git commands?
>> >
>> > j.
>>
>> My thoughts (also for Junio, I guess..):
>>
>> If y'all feel that it can live with the rest of the git
>> commands then that would be great =)
>
> I'd like to see it as a general git tool, too.
> Maybe it can even share some common functionality with git-mergetool.
The code was copied and pasted very heavily, and I think (IIRC) the author
was a bit too ashamed to have it outside contrib/ before it is properly
refactored or something like that. Which I happen to agree with, by the
way.
^ permalink raw reply
* Re: push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)
From: Junio C Hamano @ 2009-03-17 23:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0903172350270.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 18 Mar 2009, Nanako Shiraishi wrote:
>
>> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>
>> > On Sat, 14 Mar 2009, Junio C Hamano wrote:
>> >
>> >> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit
>> >> - New config push.default to decide default behavior for push
>> >>
>> >> Replaced the old series with the first step to allow a smooth
>> >> transition. Some might argue that this should not give any warning
>> >> but just give users this new configuration to play with first, and
>> >> after we know we are going to switch default some day, start the
>> >> warning.
>> >
>> > IIRC Steffen posted a patch series earlier, where he initialized
>> > remote.origin.push upon clone (I am not sure if he provided a
>> > corresponding patch for checkout --track), but personally, I think
>> > that would be nicer than having a push.default.
>>
>> Isn't recent trend to avoid such inconsistency between behavior in an
>> existing repository and behavior in a newly created repository? For
>> example, Jeff calls such inconsistency in
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100433
>>
>> as "this breaks in my repo, but when I make a test repo it works". Junio
>> even called it 'madness' (^_^;)
>
> My point is that it is _not_ an inconsistency.
>
> It has a default setting. One that already is well established. Push the
> matching refs.
>
> But you can override it by setting the config variable. Which is also
> well established.
>
> The only thing Steffen's patches would have changed would be to set the
> default differently now.
>
> Which is not that much of a 'madness'.
>
> Especially if you think about changing the default, which _will_ make for
> angry users ("why did you change the default? I _liked_ it! Please
> revert _now_!").
I cloned my old project to my new machine with a recent git and it behaves
differently. Why did you change the default "git clone" creates, without
telling me?
Sounds like a huge inconsistency to me.
^ permalink raw reply
* Re: [JGIT PATCH 3/4] Cap the number of open files in the WindowCache
From: Robin Rosenberg @ 2009-03-18 0:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090317230803.GA23521@spearce.org>
onsdag 18 mars 2009 00:08:03 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> > tisdag 17 mars 2009 02:16:09 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> >
> > > If we detect a file open failure while opening a pack we halve
> > > the number of permitted open files and try again, [...]
> >
> > The output of getMessage isn't that simple to interpret. Here it is filename+" (Too many files open)",
> > and on other platforms it is probably something else. This goes for the message part of most exceptions
> > thrown from platform specific code like file i/o socket i/o etc. The type of exception is a FileNotFoundException,
> > btw.
> >
> > I wonder whether your code works on any platform.
>
> Arrrgh.
>
> OK. Maybe scrap that part of the patch then?
Yes, I think so, inless you want to try something as ugly as getMessage().toLower().indexof("(too many")? Not
sure what it looks like in Windows or OSX. We know from the JDK source it's filename + "(" + reason +")" and
the problem here is the reason part.
> Its too bad they don't have a specific type of exception for this,
FileNotFoundException is a little more specific. Maybe in combinatikon with a file.exists() and file.canRead test...
(thinking loud now)
> nor do they have a way to hold onto file descriptors under a type
> like a SoftReference where the runtime can whack them if you have
> too many.
The problem is that it's not connected to file descriptors but to memory. Doing a GC on filenotfoundexception
(here) could help here if one uses soft reference, or one could prune the cache manually. The parameter
could also be a
>
> I guess that's why Hadoop HBase just tells you to up your fd ulimit
> to 32767. :-)
Yeah, with gigabytes of memory that might not consume too much resources anyway.
-- robin
^ permalink raw reply
* Re: fetch and pull
From: Jeff King @ 2009-03-18 0:37 UTC (permalink / raw)
To: John Dlugosz; +Cc: git, Junio C Hamano
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A3FC0A5@EXCHANGE.trad.tradestation.com>
On Tue, Mar 17, 2009 at 12:44:31PM -0400, John Dlugosz wrote:
> > > You checkout master before updating it?
> >
> > You cannot merge/rebase a branch unless it is checked out.
> >
> Sure you can.
> git rebase upstream topic
This literally does a "checkout" behind the scenes, so it is still
manipulating your working tree. It is basically the equivalent of:
git checkout topic && git rebase upstream
The actual rebasing happens on a detached HEAD, but you will find at the
end of such a rebase that you are now on the branch "topic".
-Peff
^ permalink raw reply
* Re: push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)
From: Johannes Schindelin @ 2009-03-18 0:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vab7jpv93.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 17 Mar 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 18 Mar 2009, Nanako Shiraishi wrote:
> >
> >> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >>
> >> > On Sat, 14 Mar 2009, Junio C Hamano wrote:
> >> >
> >> >> * fg/push-default (Wed Mar 11 23:01:45 2009 +0100) 1 commit
> >> >> - New config push.default to decide default behavior for push
> >> >>
> >> >> Replaced the old series with the first step to allow a smooth
> >> >> transition. Some might argue that this should not give any warning
> >> >> but just give users this new configuration to play with first, and
> >> >> after we know we are going to switch default some day, start the
> >> >> warning.
> >> >
> >> > IIRC Steffen posted a patch series earlier, where he initialized
> >> > remote.origin.push upon clone (I am not sure if he provided a
> >> > corresponding patch for checkout --track), but personally, I think
> >> > that would be nicer than having a push.default.
> >>
> >> Isn't recent trend to avoid such inconsistency between behavior in an
> >> existing repository and behavior in a newly created repository? For
> >> example, Jeff calls such inconsistency in
> >>
> >> http://thread.gmane.org/gmane.comp.version-control.git/100339/focus=100433
> >>
> >> as "this breaks in my repo, but when I make a test repo it works".
> >> Junio even called it 'madness' (^_^;)
> >
> > My point is that it is _not_ an inconsistency.
> >
> > It has a default setting. One that already is well established.
> > Push the matching refs.
> >
> > But you can override it by setting the config variable. Which is also
> > well established.
> >
> > The only thing Steffen's patches would have changed would be to set
> > the default differently now.
> >
> > Which is not that much of a 'madness'.
> >
> > Especially if you think about changing the default, which _will_ make
> > for angry users ("why did you change the default? I _liked_ it!
> > Please revert _now_!").
>
> I cloned my old project to my new machine with a recent git and it
> behaves differently. Why did you change the default "git clone"
> creates, without telling me?
>
> Sounds like a huge inconsistency to me.
Okay, I'll bite.
In my git.git clone on one machine, I have remote.orcz.push = master. I
cloned it. There, "git push" does something different.
Inconsistent right there, correct? Without any change to git.git.
Assume push.default goes in.
Nothing changes in my scenario. Inconsistency right there.
Ciao,
Dscho
^ permalink raw reply
* [EGIT PATCH 01/25] Use generics for collections in commit dialog and import page
From: Robin Rosenberg @ 2009-03-18 0:40 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
A little cleaner and fewer warnings.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../ui/internal/clone/GitProjectsImportPage.java | 16 ++++++++--------
.../egit/ui/internal/dialogs/CommitDialog.java | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/clone/GitProjectsImportPage.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/clone/GitProjectsImportPage.java
index ece585a..5d82edc 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/clone/GitProjectsImportPage.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/clone/GitProjectsImportPage.java
@@ -508,7 +508,7 @@ public void run(IProgressMonitor monitor) {
UIText.WizardProjectsImportPage_SearchingMessage,
100);
selectedProjects = new ProjectRecord[0];
- Collection files = new ArrayList();
+ Collection<File> files = new ArrayList<File>();
monitor.worked(10);
if (directory.isDirectory()) {
@@ -516,14 +516,14 @@ public void run(IProgressMonitor monitor) {
null, monitor)) {
return;
}
- Iterator filesIterator = files.iterator();
+ Iterator<File> filesIterator = files.iterator();
selectedProjects = new ProjectRecord[files.size()];
int index = 0;
monitor.worked(50);
monitor
.subTask(UIText.WizardProjectsImportPage_ProcessingMessage);
while (filesIterator.hasNext()) {
- File file = (File) filesIterator.next();
+ File file = filesIterator.next();
selectedProjects[index] = new ProjectRecord(file);
index++;
}
@@ -562,8 +562,8 @@ setMessage(UIText.WizardProjectsImportPage_projectsInWorkspace,
* The monitor to report to
* @return boolean <code>true</code> if the operation was completed.
*/
- private boolean collectProjectFilesFromDirectory(Collection files,
- File directory, Set directoriesVisited, IProgressMonitor monitor) {
+ private boolean collectProjectFilesFromDirectory(Collection<File> files,
+ File directory, Set<String> directoriesVisited, IProgressMonitor monitor) {
if (monitor.isCanceled()) {
return false;
@@ -577,7 +577,7 @@ private boolean collectProjectFilesFromDirectory(Collection files,
// Initialize recursion guard for recursive symbolic links
if (directoriesVisited == null) {
- directoriesVisited = new HashSet();
+ directoriesVisited = new HashSet<String>();
try {
directoriesVisited.add(directory.getCanonicalPath());
} catch (IOException exception) {
@@ -759,13 +759,13 @@ public CheckboxTreeViewer getProjectsList() {
* workspace
*/
public ProjectRecord[] getValidProjects() {
- List validProjects = new ArrayList();
+ List<ProjectRecord> validProjects = new ArrayList<ProjectRecord>();
for (int i = 0; i < selectedProjects.length; i++) {
if (!isProjectInWorkspace(selectedProjects[i].getProjectName())) {
validProjects.add(selectedProjects[i]);
}
}
- return (ProjectRecord[]) validProjects
+ return validProjects
.toArray(new ProjectRecord[validProjects.size()]);
}
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/CommitDialog.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/CommitDialog.java
index b69a4ba..e6bd02d 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/CommitDialog.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/dialogs/CommitDialog.java
@@ -366,7 +366,7 @@ public void handleEvent(Event arg0) {
}
try {
ArrayList<GitIndex> changedIndexes = new ArrayList<GitIndex>();
- for (Iterator<Object> it = sel.iterator(); it.hasNext();) {
+ for (Iterator<?> it = sel.iterator(); it.hasNext();) {
CommitItem commitItem = (CommitItem) it.next();
IProject project = commitItem.file.getProject();
--
1.6.1.285.g35d8b
^ permalink raw reply related
* Re: Ability to edit message from git rebase --interactive.
From: Jeff King @ 2009-03-18 0:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Olivier Goffart, git
In-Reply-To: <alpine.DEB.1.00.0903172329480.10279@pacific.mpi-cbg.de>
On Tue, Mar 17, 2009 at 11:31:19PM +0100, Johannes Schindelin wrote:
> > I was told on IRC that this has been discussed already not so long ago,
> > and looking on the archive[1], all i seen was bikesheeding . Here is a
> > patch :-)
>
> Unfortunately, the implementation is not the problem, but picking the best
> name. The first letter "m" will be taken in a short while by the "merge"
> command for "rebase -i -p", so "message" is out, sadly.
>
> But the "rephrase" command will be part of the "rebase -i -p" series when
> I will finally be able to submit it.
Also, I thought the general plan was to add such features to the
git-sequencer work which will (hopefully) eventually replace "rebase
-i". Dscho, can you give a brief update on how that is coming? Are
rebase patches worth thinking about?
-Peff
^ permalink raw reply
* Re: Local clone checks out wrong branch based on remote HEAD
From: Jeff King @ 2009-03-18 0:54 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: git
In-Reply-To: <b97024a40903171219k8841508p774d9dc4295a09bc@mail.gmail.com>
On Tue, Mar 17, 2009 at 12:19:35PM -0700, Tom Preston-Werner wrote:
> After cloning this with a standard `git clone`, the refs are:
>
> [11:48][tom@solid:~/dev/sandbox/site(release)]$ git branch -r -v
> origin/HEAD a52528a Fixed some routing problems
> origin/release a52528a Fixed some routing problems
> origin/trunk a52528a Fixed some routing problems
>
> And the checked out branch is 'release' instead of 'trunk' as I would expect:
As others have explained, this is because the information is lacking at
the client and we are forced to make a guess. There is a heuristic in
the guess to prefer "master" if it is an option. I suppose we could make
a similar exception for "trunk", which might make sense to people
working with SVN repositories.
OTOH, I am not sure I want to open the can of worms that is writing an
exhaustive list of heuristics that will work for everybody. Fixing the
protocol itself would probably be easier. :)
Here is what such a heuristic would look like, though (on top of next
and totally untested):
---
diff --git a/remote.c b/remote.c
index 76b1bbd..99d2281 100644
--- a/remote.c
+++ b/remote.c
@@ -1529,11 +1529,18 @@ struct ref *guess_remote_head(const struct ref *head,
if (head->symref)
return copy_ref(find_ref_by_name(refs, head->symref));
- /* If refs/heads/master could be right, it is. */
+ /* We heuristically prefer certain names */
if (!all) {
- r = find_ref_by_name(refs, "refs/heads/master");
- if (r && !hashcmp(r->old_sha1, head->old_sha1))
- return copy_ref(r);
+ const char *rules[] = {
+ "refs/heads/master",
+ "refs/heads/trunk",
+ };
+ int i;
+ for (i = 0; i < ARRAY_SIZE(rules); i++) {
+ r = find_ref_by_name(refs, rules[i]);
+ if (r && !hashcmp(r->old_sha1, head->old_sha1))
+ return copy_ref(r);
+ }
}
/* Look for another ref that points there */
^ permalink raw reply related
* Re: Ability to edit message from git rebase --interactive.
From: Johannes Schindelin @ 2009-03-18 0:58 UTC (permalink / raw)
To: Jeff King; +Cc: Olivier Goffart, git
In-Reply-To: <20090318004056.GB25454@coredump.intra.peff.net>
Hi,
On Tue, 17 Mar 2009, Jeff King wrote:
> On Tue, Mar 17, 2009 at 11:31:19PM +0100, Johannes Schindelin wrote:
>
> > > I was told on IRC that this has been discussed already not so long ago,
> > > and looking on the archive[1], all i seen was bikesheeding . Here is a
> > > patch :-)
> >
> > Unfortunately, the implementation is not the problem, but picking the best
> > name. The first letter "m" will be taken in a short while by the "merge"
> > command for "rebase -i -p", so "message" is out, sadly.
> >
> > But the "rephrase" command will be part of the "rebase -i -p" series when
> > I will finally be able to submit it.
>
> Also, I thought the general plan was to add such features to the
> git-sequencer work which will (hopefully) eventually replace "rebase
> -i". Dscho, can you give a brief update on how that is coming? Are
> rebase patches worth thinking about?
IMHO rebase -i is the important part. The user interface needs some
serious overhaul, which I am in the slow process of doing. The sequencer
then has to follow suit.
As it stands, I think sequencer is not good enough yet to replace rebase
-i (all my comments about that are public, except the heads-up I sent
Stephan in private).
To be frank, 'rebase -i -p' support, as it is in git.git is not good
enough at all. That's why I was working on that, and I am close to
finishing it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-tag.c: remove global variable to use the callback data of git-config.
From: Carlos Rica @ 2009-03-18 0:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <alpine.DEB.1.00.0903172326250.10279@pacific.mpi-cbg.de>
On Tue, Mar 17, 2009 at 11:27 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 17 Mar 2009, Carlos Rica wrote:
>
>> On Tue, Mar 17, 2009 at 4:47 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > Hi,
>> > On Tue, 17 Mar 2009, Carlos Rica wrote:
>> >> @@ -164,11 +162,10 @@ static int do_sign(struct strbuf *buffer)
>> >> int len;
>> >> int i, j;
>> >>
>> >> - if (!*signingkey) {
>> >> - if (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),
>> >> - sizeof(signingkey)) > sizeof(signingkey) - 1)
>> >> - return error("committer info too long.");
>> >> - bracket = strchr(signingkey, '>');
>> >> + if (!signingkey->buf[0]) {
>> >
>> > It is probably better to ask for !signingkey->len (think of trying to
>> > understand the code in 6 months from now).
>>
>> I was in doubt here. By avoiding the use of signingkey->len I was
>> trying to say that you cannot rely in such field if we touch the
>> buffer directly, as it happens below:
>>
>> bracket = strchr(signingkey->buf, '>');
>> if (bracket)
>> bracket[1] = '\0';
>
> Oh, I missed that. It should read
>
> if (bracket)
> strbuf_setlen(signingkey, bracket + 1 - signingkey->buf);
>
> instead.
I agree! That's much better. Thanks Dscho and Junio.
Tell me if you need me to resend the patch with both changes.
^ permalink raw reply
* Re: push.default, was Re: What's cooking in git.git (Mar 2009, #04; Sat, 14)
From: Junio C Hamano @ 2009-03-18 1:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0903180138210.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> In my git.git clone on one machine, I have remote.orcz.push = master. I
> cloned it. There, "git push" does something different.
>
> Inconsistent right there, correct? Without any change to git.git.
You must be smoking something potent. It's a nonsense argument and you
know it.
In your git.git clone on one machine, you have some setting.
You cloned it to one machine some time ago. It behave differently and
that is something that has always been true, and you know it. Repository
configuration is private.
You clone it to another today. Now the new clone, without any
configuration, will behave differently from the other clone, that you
haven't done any funny configuration.
That's inconsistent.
^ permalink raw reply
* Re: Ability to edit message from git rebase --interactive.
From: Junio C Hamano @ 2009-03-18 1:06 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Olivier Goffart, git
In-Reply-To: <20090318004056.GB25454@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Mar 17, 2009 at 11:31:19PM +0100, Johannes Schindelin wrote:
>
>> > I was told on IRC that this has been discussed already not so long ago,
>> > and looking on the archive[1], all i seen was bikesheeding . Here is a
>> > patch :-)
>>
>> Unfortunately, the implementation is not the problem, but picking the best
>> name. The first letter "m" will be taken in a short while by the "merge"
>> command for "rebase -i -p", so "message" is out, sadly.
>>
>> But the "rephrase" command will be part of the "rebase -i -p" series when
>> I will finally be able to submit it.
>
> Also, I thought the general plan was to add such features to the
> git-sequencer work which will (hopefully) eventually replace "rebase
> -i". Dscho, can you give a brief update on how that is coming? Are
> rebase patches worth thinking about?
I am not quite sure what rephrase is buying us. Do we also want to
introduce retree that allows you to muck with the tree object recorded
without giving you a chance to clobber the commit log message?
^ permalink raw reply
* Re: [PATCH] git config: clarify bool types
From: Junio C Hamano @ 2009-03-18 1:13 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Johannes Schindelin
In-Reply-To: <1237331631-29822-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> The value is what it is, the --bool and --bool-or-int options don't
> specify the value type, just how it is interpreted. For example: a value
> of '1' can be interpreted as 'true'.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>
> This applies on top of the 'next' branch.
>
> builtin-config.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-config.c b/builtin-config.c
> index 1a3baa1..c3a0176 100644
> --- a/builtin-config.c
> +++ b/builtin-config.c
> @@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
> OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
> OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
> OPT_GROUP("Type"),
> - OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
> + OPT_BIT(0, "bool", &types, "value is intepreted as bool (\"true\" or \"false\")", TYPE_BOOL),
I'd rater see it say something like:
Output the value as boolean (true or false)
so that it is consistent with others you can see in the context.
E.g. get-color explains it to order the command to "find the color".
"Interpret" is fine too. The point is not about the choice of verb but
use of imperative mood.
^ permalink raw reply
* Re: Suggested Workflow Question
From: Marcel M. Cary @ 2009-03-18 1:27 UTC (permalink / raw)
To: Roger Garvin; +Cc: git@vger.kernel.org
In-Reply-To: <loom.20090317T175010-470@post.gmane.org>
Roger Garvin wrote:
> I work for a small company with about 15 developers who work concurrently on
> about 10+ projects both in new development and support.
> We do custom software for manufacturing and production systems. Part of our
> contracts with our customers is a perpetual single use license of the source
> code at each facility.
> So we have a copy of the source on our office server, and another copy at each
> customer site. When we had only 5 developers it was easier to handle. Now that
> we are growing we need a source control system and I have been looking heavily
> into Git. Our old workflow does not seem that it will fit well with Git
> however, but I feel that I need a distributed system to keep track of the office
> version and the on-site versions of our source since development is taking place
> on both.
> (Some customers also have separate development, and testing versions on their
> servers as well.)
>
> I have created git repositories on a couple of our project source directories as
> test beds. Right now (second day) I am the only one who is actually using git.
> Everyone else is simply accessing the files on the server as they have always
> done, and I am making the commits when I see signifigant changes.
>
> My question is really a request for modified workflow ideas. My plan was to
> have a master repository in our office server with clones at each customer site,
> and multiple branches for test, QA, and production versions of the source.
> Since most of these customers have closed networks, we would rely on people
> traveling onsite, or emailing patches to get any updates back into our office
> repository.
>
> Thank you for any assistance for this revision control newb.
>
> Roger Garvin
The workflow elements you mention so far sound sane to me:
* a repository in your office
* repositories at customer sites
* emailing patches when direct connections are not possible
* test and dev branches for each customer
I presume there will also be a production branch in customer
repositories on which you arrange production releases... or maybe you
just tag your test branch when it passes?
When you send patches via email, keep in mind that you'll have to convey
which branch they belong on "out of band", for example after the commit
message and above the diffstat.
There was an interesting discussion about maintaining per-client code on
different branches recently, but I can't find it.
I've found Git to be very flexible. Maybe you could start by emulating
your current workflow and refine it as you go? If you find you don't
know how code travels currently... well, maybe you can just let your
team pass patches around until patterns emerge.
Marcel
^ permalink raw reply
* [JGIT PATCH 3/4 v2] Cap the number of open files in the WindowCache
From: Shawn O. Pearce @ 2009-03-18 1:36 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200903180109.40074.robin.rosenberg.lists@dewire.com>
The default WindowCache configuration is:
packedGitLimit: 10 MB
packedGitWindowSize: 8 KB
10 MB / 8 KB allows up to 1280 windows permitted in the WindowCache
at any given time. If every window came from a unique pack file, we
need 1280 file descriptors just for the resources in the WindowCache.
For most applications this is way beyond the hard limit configured
for the host JVM, causing java.io.IOException("Too many open files")
from possibly any part of JGit or the host application.
Specifically, I ran into this problem in Gerrit Code Review, where we
commonly see hundreds of very small pack files spread over hundreds
of Git repositories, all accessed from a persistent JVM that is also
hosting an SSH daemon and a web server. The aggressive caching of
windows in the WindowCache and of Repository objects in Gerrit's
own RepositoryCache caused us to retain far too many tiny pack files.
We now set the limit at 128 open files, assuming this is a reasonable
limit for most applications using the library. Git repositories tend
to be in the handful of packs/repository (e.g. <10 packs/repository)
and applications using JGit tend to access only a handful of Git
repositories at a time (e.g. <10 repositories/JVM).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> onsdag 18 mars 2009 00:08:03 skrev "Shawn O. Pearce" <spearce@spearce.org>:
> > Arrrgh.
> >
> > OK. Maybe scrap that part of the patch then?
> Yes, I think so
Scrapped the ugly test for getMessage() when the open fails.
So we no longer try to reduce fd usage on failure.
.../src/org/spearce/jgit/lib/WindowCache.java | 26 +++++++++++++++++++-
.../org/spearce/jgit/lib/WindowCacheConfig.java | 20 +++++++++++++++
2 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
index ba1124a..f755dad 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
@@ -54,6 +54,8 @@ private static final int bits(int newSize) {
return Integer.numberOfTrailingZeros(newSize);
}
+ private static int maxFileCount;
+
private static int maxByteCount;
private static int windowSize;
@@ -70,10 +72,13 @@ private static final int bits(int newSize) {
private static ByteWindow lruTail;
+ private static int openFileCount;
+
private static int openByteCount;
static {
final WindowCacheConfig c = new WindowCacheConfig();
+ maxFileCount = c.getPackedGitOpenFiles();
maxByteCount = c.getPackedGitLimit();
windowSizeShift = bits(c.getPackedGitWindowSize());
windowSize = 1 << windowSizeShift;
@@ -133,6 +138,13 @@ private static synchronized void reconfigureImpl(final WindowCacheConfig cfg) {
boolean prune = false;
boolean evictAll = false;
+ if (maxFileCount < cfg.getPackedGitOpenFiles())
+ maxFileCount = cfg.getPackedGitOpenFiles();
+ else if (maxFileCount > cfg.getPackedGitOpenFiles()) {
+ maxFileCount = cfg.getPackedGitOpenFiles();
+ prune = true;
+ }
+
if (maxByteCount < cfg.getPackedGitLimit()) {
maxByteCount = cfg.getPackedGitLimit();
} else if (maxByteCount > cfg.getPackedGitLimit()) {
@@ -230,15 +242,21 @@ private static synchronized final void getImpl(final WindowCursor curs,
if (wp.openCount == 0) {
try {
+ openFileCount++;
+ releaseMemory();
+ runClearedWindowQueue();
wp.openCount = 1;
wp.cacheOpen();
} catch (IOException ioe) {
+ openFileCount--;
wp.openCount = 0;
throw ioe;
} catch (RuntimeException ioe) {
+ openFileCount--;
wp.openCount = 0;
throw ioe;
} catch (Error ioe) {
+ openFileCount--;
wp.openCount = 0;
throw ioe;
} finally {
@@ -278,6 +296,7 @@ private static synchronized final void getImpl(final WindowCursor curs,
static synchronized void markLoaded(final ByteWindow w) {
if (--w.provider.openCount == 0) {
+ openFileCount--;
w.provider.cacheClose();
}
}
@@ -291,13 +310,17 @@ private static void makeMostRecent(ByteWindow<?> e) {
private static void releaseMemory() {
ByteWindow<?> e = lruTail;
- while (openByteCount > maxByteCount && e != null) {
+ while (isOverLimit() && e != null) {
final ByteWindow<?> p = e.lruPrev;
clear(e);
e = p;
}
}
+ private static boolean isOverLimit() {
+ return openByteCount > maxByteCount || openFileCount > maxFileCount;
+ }
+
/**
* Remove all windows associated with a specific provider.
* <p>
@@ -341,6 +364,7 @@ private static void clear(final ByteWindow<?> e) {
private static void unlinkSize(final ByteWindow<?> e) {
if (e.sizeActive) {
if (--e.provider.openCount == 0) {
+ openFileCount--;
e.provider.cacheClose();
}
openByteCount -= e.size;
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCacheConfig.java b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCacheConfig.java
index b4c4638..d906a7c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCacheConfig.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCacheConfig.java
@@ -45,6 +45,8 @@
/** 1024 {@link #KB} (number of bytes in one mebibyte/megabyte) */
public static final int MB = 1024 * KB;
+ private int packedGitOpenFiles;
+
private int packedGitLimit;
private int packedGitWindowSize;
@@ -55,6 +57,7 @@
/** Create a default configuration. */
public WindowCacheConfig() {
+ packedGitOpenFiles = 128;
packedGitLimit = 10 * MB;
packedGitWindowSize = 8 * KB;
packedGitMMAP = false;
@@ -62,6 +65,23 @@ public WindowCacheConfig() {
}
/**
+ * @return maximum number of streams to open at a time. Open packs count
+ * against the process limits. <b>Default is 128.</b>
+ */
+ public int getPackedGitOpenFiles() {
+ return packedGitOpenFiles;
+ }
+
+ /**
+ * @param fdLimit
+ * maximum number of streams to open at a time. Open packs count
+ * against the process limits
+ */
+ public void setPackedGitOpenFiles(final int fdLimit) {
+ packedGitOpenFiles = fdLimit;
+ }
+
+ /**
* @return maximum number bytes of heap memory to dedicate to caching pack
* file data. <b>Default is 10 MB.</b>
*/
--
1.6.2.1.286.g8173
^ permalink raw reply related
* [JGIT PATCH 00/12] Improve test coverage in revwalk
From: Shawn O. Pearce @ 2009-03-18 1:40 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
Most of these patches are to improve the test coverage within the
revwalk package.
The last commit points out what I feared, which is that a RevWalk
with a PathFilter applied doesn't produce the same results that
git-core would produce in the same situation. We're either missing
some functions necessary to implement it, or we flat out produce
a wrong graph in some cases.
The tests are commented out because JUnit doesn't have a notion of
"known broken". But I did leave in TODO comments. I'd like to
apply the test, and then work later to improve it, but I'm open
to suggestions.
Shawn O. Pearce (12):
Fix copyright year in revwalk test file headers
Mark non-overridable methods of RevObject final
Change RevWalkTestCase to use RevCommit, not ObjectId
Test that RevFilter.MERGE_BASE cannot use a TreeFilter
Add unit tests for DateRevQueue
Add unit tests for FIFORevQueue
Add unit tests for LIFORevQueue
Add unit tests for AbstractRevQueue.EMPTY_QUEUE
Add tests for basic RevObject methods related to type, flags
Add tests for ObjectWalk
Add some basic logic tests for TreeFilter on RevWalk
Implement git-core t/t6012-rev-list-simplify test case
.../jgit/revwalk/AlwaysEmptyRevQueueTest.java | 63 +++++++
.../org/spearce/jgit/revwalk/DateRevQueueTest.java | 118 ++++++++++++
.../org/spearce/jgit/revwalk/FIFORevQueueTest.java | 81 +++++++++
.../org/spearce/jgit/revwalk/LIFORevQueueTest.java | 69 +++++++
.../org/spearce/jgit/revwalk/ObjectWalkTest.java | 190 ++++++++++++++++++++
.../org/spearce/jgit/revwalk/RevFlagSetTest.java | 2 +-
.../org/spearce/jgit/revwalk/RevObjectTest.java | 171 ++++++++++++++++++
.../org/spearce/jgit/revwalk/RevQueueTestCase.java | 85 +++++++++
.../org/spearce/jgit/revwalk/RevWalkCullTest.java | 30 ++--
.../spearce/jgit/revwalk/RevWalkFilterTest.java | 93 +++++-----
.../spearce/jgit/revwalk/RevWalkMergeBaseTest.java | 64 ++++---
.../jgit/revwalk/RevWalkPathFilter1Test.java | 176 ++++++++++++++++++
.../jgit/revwalk/RevWalkPathFilter6012Test.java | 162 +++++++++++++++++
.../org/spearce/jgit/revwalk/RevWalkSortTest.java | 66 ++++----
.../org/spearce/jgit/revwalk/RevWalkTestCase.java | 110 ++++++++++--
.../org/spearce/jgit/revwalk/AbstractRevQueue.java | 2 +-
.../org/spearce/jgit/revwalk/BlockRevQueue.java | 2 +-
.../src/org/spearce/jgit/revwalk/RevObject.java | 20 +-
18 files changed, 1353 insertions(+), 151 deletions(-)
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/AlwaysEmptyRevQueueTest.java
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/DateRevQueueTest.java
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/FIFORevQueueTest.java
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/LIFORevQueueTest.java
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/ObjectWalkTest.java
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevObjectTest.java
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevQueueTestCase.java
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkPathFilter1Test.java
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkPathFilter6012Test.java
^ permalink raw reply
* [JGIT PATCH 01/12] Fix copyright year in revwalk test file headers
From: Shawn O. Pearce @ 2009-03-18 1:40 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1237340451-31562-1-git-send-email-spearce@spearce.org>
These were all created in 2009, not 2008.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../org/spearce/jgit/revwalk/RevFlagSetTest.java | 2 +-
.../org/spearce/jgit/revwalk/RevWalkCullTest.java | 2 +-
.../spearce/jgit/revwalk/RevWalkFilterTest.java | 2 +-
.../spearce/jgit/revwalk/RevWalkMergeBaseTest.java | 2 +-
.../org/spearce/jgit/revwalk/RevWalkSortTest.java | 2 +-
.../org/spearce/jgit/revwalk/RevWalkTestCase.java | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevFlagSetTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevFlagSetTest.java
index 76f3cbb..ff02d64 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevFlagSetTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevFlagSetTest.java
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2008, Google Inc.
+ * Copyright (C) 2009, Google Inc.
*
* All rights reserved.
*
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkCullTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkCullTest.java
index 93bd645..e734273 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkCullTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkCullTest.java
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2008, Google Inc.
+ * Copyright (C) 2009, Google Inc.
*
* All rights reserved.
*
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkFilterTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkFilterTest.java
index cf2975d..d079bdc 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkFilterTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkFilterTest.java
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2008, Google Inc.
+ * Copyright (C) 2009, Google Inc.
*
* All rights reserved.
*
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkMergeBaseTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkMergeBaseTest.java
index b05e774..cec4e3f 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkMergeBaseTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkMergeBaseTest.java
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2008, Google Inc.
+ * Copyright (C) 2009, Google Inc.
*
* All rights reserved.
*
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkSortTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkSortTest.java
index 6f2eedc..3ed1565 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkSortTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkSortTest.java
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2008, Google Inc.
+ * Copyright (C) 2009, Google Inc.
*
* All rights reserved.
*
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkTestCase.java b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkTestCase.java
index bd696dd..a477be9 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkTestCase.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevWalkTestCase.java
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2008, Google Inc.
+ * Copyright (C) 2009, Google Inc.
*
* All rights reserved.
*
--
1.6.2.1.286.g8173
^ permalink raw reply related
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