(128,1,'2010-06-14 14:45:09','P',1,'Bleh.  This is going to turn into one very ugly constants file if we start to put every configuration key into it.\n\nI\'d rather pull these into specialized config related classes than start exporting them as part of our Constants class.',NULL,836,3,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Constants.java','AAALu3///nw='),(1282,46,'2010-06-14 15:31:20','P',1,'See my remakrs on patch set 4.','AAALu3///ns=',836,3,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///mc='),(1282,1,'2010-06-14 14:45:09','P',1,'Please refer to my comments on patch set 1, same line, for why I don\'t think this is a sufficient test.',NULL,836,3,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///ns='),(1131,1,'2010-06-14 15:36:59','P',1,'Javadoc should be updated to reflect this new exception.',NULL,836,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///l0='),(1147,1,'2010-06-14 15:36:59','P',1,'Javadoc should be updated to reflect this new exception.',NULL,836,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///l4='),(1300,1,'2010-06-14 15:36:59','P',1,'Even if core.worktree wasn\'t set in the configuration file, it might have been set by the caller of Repository.  We have like 8 forms of our constructor that takes various arguments... one of those is the work tree path, which could have come from an environment variable.',NULL,836,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///l8='),(1291,1,'2010-06-14 15:36:59','P',1,'You can see if its set by doing:\n\n  getConfig().getString(\"core\",null,\"bare\") != null\n\nand then later doing the getBoolean() if that was true.  Maybe  we should put that getString(...) != null into an isSet() method in Config to make this easier to test.',NULL,836,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///mA='),(1323,46,'2010-06-15 15:36:27','P',1,'Done','AAALu3///g0=',836,5,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///f0='),(1323,1,'2010-06-15 14:59:36','P',1,'With all of the logic in the constructor, I wonder if we can simplify this method down to:\n\n  public boolean isBare() {\n    return workDir == null;\n  }',NULL,836,5,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///g0='),(265,1,'2010-06-15 14:59:36','P',1,'I think the better approach here is:\n\n if (workTreeConfig != null) {\n    workDir = fs.resolve(d, workTreeConfig);\n } else if (getConfig().getString(\"core\", null, \"bare\") != null)) {\n    if (getConfig().getBoolean(\"core\", \"bare\", true))\n      workDir = gitDir.getParentFile();\n    else\n      workDir = null;\n } else if (Constants.DOT_GIT.equals(gitDir.getName())) {\n    workDir = gitDir.getParentFile();\n } else {\n    workDir = null;\n }\n\nNo, its not pretty.  None of the \"setup\" code in git-core is sane.  Its a horrible mess that nobody likes to touch, because the algorithm is completely, utterly broken, but users just expect it to keep working like it has been.',NULL,836,5,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///g4='),(261,1,'2010-06-15 14:59:36','P',1,'Style-nit: Please don\'t nest a end-of-line // style comment inside of a method call in the middle of an if conditional.  It just feels so wrong...  I\'d prefer to have this comment in the { } block part of the conditional instead.',NULL,836,5,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///g8='),(265,46,'2010-06-15 15:36:27','P',1,'Thanks a lot for the code.\nI believe it must be !getConfig().getBoolean... See next patch set.','AAALu3///g4=',836,5,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///gA='),(261,46,'2010-06-15 15:36:27','P',1,'Absolutely.','AAALu3///g8=',836,5,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///gM='),(1342,1,'2010-06-15 16:13:25','P',1,'Nak.  I\'d just allow the call.  Its not reasonable for an application to setup a Repository from a bare Git, and then later point it at a working directory.',NULL,836,6,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///eg='),(1156,1,'2010-06-15 16:13:25','P',1,'Why do we throw IOException here and IllegalStateException in getIndexFile()?\n\nCan we at least throw the same type consistently?',NULL,836,6,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///ek='),(1342,46,'2010-06-15 17:51:03','P',1,'Done','AAALu3///eg=',836,6,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///eQ='),(1156,46,'2010-06-15 17:51:03','P',1,'Done','AAALu3///ek=',836,6,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALu3///eU='),(136,1,'2010-06-15 18:07:21','P',1,'Since you set bare like 4 or 5 different times in this test suite, why not pull this into a utility method, so you can just do:\n\n  setBare(gitDir, true);\n\nand have the setBare utility method create the temporary Repository, set the flag and save the config.',NULL,836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///d0='),(75,1,'2010-06-15 18:07:21','P',1,'For places where we are not bare, we should also assert (after the isBare() assert) that getDirectory() and getWorkDir() match what we expect as return values.  Especially since we are asking the Repository class to do some guessing based on what we gave it.',NULL,836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///d4='),(54,1,'2010-06-15 18:07:21','P',1,'I think a better name for this is RepositorySetupWorkDirTest.  Its a test class for the Repository class to test the setup of the work directory.',NULL,836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///d8='),(75,46,'2010-06-15 18:37:35','P',1,'Done','AAALu3///d4=',836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///dc='),(59,46,'2010-06-15 18:37:35','P',1,'Done','AAALu3///eI=',836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///dg='),(57,46,'2010-06-15 18:37:35','P',1,'Done','AAALu3///eM=',836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///dk='),(54,46,'2010-06-15 18:37:35','P',1,'Done','AAALu3///d8=',836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///do='),(220,46,'2010-06-15 18:37:35','P',1,'Done','AAALu3///eA=',836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///dQ='),(190,46,'2010-06-15 18:37:35','P',1,'Oops. Of course. Found a bug already after fixing it...','AAALu3///eE=',836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///dU='),(136,46,'2010-06-15 18:37:35','P',1,'Refactoring this into a method, we would also require the configuration key... Guess this isn\'t worth it.','AAALu3///d0=',836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///dY='),(220,1,'2010-06-15 18:07:21','P',1,'This method should be private, it exists only to support the other methods in this test class.',NULL,836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///eA='),(190,1,'2010-06-15 18:07:21','P',1,'Please only catch the IllegalStateException we are expecting.  Anything else that gets thrown is a test failure.',NULL,836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///eE='),(59,1,'2010-06-15 18:07:21','P',1,'I think the message here on the assert is overkill.  If we have only one assert per test, and the test method name is descriptive of the condition we are looking for, and the test itself is only 2 lines (get the path, call the assert), then its enough to rely on the test name to tell us what sort of condition is failed when the test fails.\n\nIn other words, I would have called this test:\n\n  testIsBare_ArbitraryDirectoryIsBare()\n\nand the one after it:\n\n  testNotBare_HasDotGitNotBare()\n\netc.  FWIW, if you are copying style from another test that uses these test00N_ prefixes, that\'s an old style that was a horrible mistake on my part when I started JGit.  I was trying to mimic the style of the C Git test suite.  It was a bad idea.',NULL,836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///eI='),(57,1,'2010-06-15 18:07:21','P',1,'Don\'t call setUp() or tearDown() in a test case, these are automatically run for you by JUnit.',NULL,836,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTest.java','AAALu3///eM='),(132,1,'2010-06-15 18:51:41','P',1,'I still think a couple of helper methods will make the tests easier to read:\n\n  private void setBare(File gitDir, boolean bare) {\n    Repository repo = new Repository(gitDir, null);\n    repo.getConfig().setBoolean(ConfigConstants.CONFIG_CORE_SECTION,\n        null, ConfigConstants.CONFIG_KEY_BARE, bare);\n    repo.getConfig().save();\n  }\n\n  private void setWorkTree(File gitDir, File workTree) {\n    Repository repo = new Repository(gitDir, null);\n    repo.getConfig().setBoolean(ConfigConstants.CONFIG_CORE_SECTION,\n        null, ConfigConstants.CONFIG_KEY_WORKTREE,\n        workTree.getAbsolutePath());\n    repo.getConfig().save();\n  }\n\nThen the tests are a bit more declarative as they setup their condition to be tested.',NULL,836,8,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositorySetupWorkDirTest.java','AAALu3///c4='),(101,1,'2010-06-15 18:51:41','P',1,'Don\'t use assertTrue(...equals()), use assertEquals instead.',NULL,836,8,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositorySetupWorkDirTest.java','AAALu3///c8='),(71,1,'2010-06-15 18:51:41','P',1,'These should use assertEquals() rather than assertTrue, so that the JUnit report can include the expected and actual values during the test, rather than a vague message.\n\nWe probably also should test the full path, but that\'s liable to fail if we use a different resolve method here in the test than the repository used.  We can probably head that off by just using the canonical paths for compare.  So rewrite this method as:\n\n  File exp = getFile(expected).getCanonicalFile();\n  File act = repo.getDirectory().getCanonicalFile();\n  assertEquals(exp, act);',NULL,836,8,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositorySetupWorkDirTest.java','AAALu3///dE='),(113,1,'2010-06-16 19:06:53','P',1,'Test is redundant with testNotBare_CreateRepositoryFromGitDirOnlyWithBareConfigFalse below',NULL,836,10,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositorySetupWorkDirTest.java','AAALu3///ZE='),(87,1,'2010-06-16 19:06:53','P',1,'Test is redundant with testNotBare_CreateRepositoryFromWorkDirOnly above',NULL,836,10,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositorySetupWorkDirTest.java','AAALu3///ZI='),(71,1,'2010-06-16 19:06:53','P',1,'Test is redundant with testNotBare_CreateRepositoryFromDotGitGitDir above',NULL,836,10,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositorySetupWorkDirTest.java','AAALu3///ZM='),(272,1,'2010-06-14 23:58:17','P',1,'Yikes.  Thanks for fixing this.',NULL,851,1,'org.eclipse.jgit.iplog/src/org/eclipse/jgit/iplog/IpLogGenerator.java','AAALu3///i0='),(287,1,'2010-06-30 16:06:06','P',1,'Alex, I\'m not sure what you are talking about with a BufferedReader filling up.  It doesn\'t make sense in context, this class is about an output stream.\n\nAssuming you meant the BufferedOutputStream we are working with here, its not important that the stream is flushed when this method is run.  During reachedInCoreLimit(), we don\'t care that the underlying stream gets a flush, we just need to start spooling this stuff out of memory before we explode the heap.  So when that method calls switchToOverflow() invoking flush isn\'t worth it, it could cause a partial block (what is left in the last buffer) to be written to the underlying stream, which may be a wasted system call that could have easily been aggregated with subsequent writes to this stream.\n\nDuring doFlush() above, we switch to the overflow stream, then flush it.  So the BufferedOutputStream gets flushed, and the underlying OutputStream that is created by our subclass is also flushed.\n\nYes, the subclass can implement overflow() to return a BufferedOutputStream.  That means we might double-buffer here.  However, its not worth checking to see if the stream is a BufferedOutputStream and special case around it.  BufferedOutputStream stacks well, so long as the wrapping BOS uses a buffer size that is >= the buffer size of the inner BOS, the inner BOS will become a no-op and simply pass through the wrapper\'s byte array to the underlying stream.  The default buffer size in the Sun JDK is 8192 bytes, which is the same size as our block size here.\n\nHowever, the intent is that the subclass\' overflow() method is a raw stream, without buffering, and that we supply buffering since our class is called TemporaryBuffer.  For example our File subclass directly returns the FileOutputStream.  Where it gets more complex is in UploadPackServlet, where the overflow stream is the ServletOutputStream.  Buffering on that is undefined, and it most certainly does not extend BufferedOutputStream.  Some servlet containers buffer that in 1 MiB chunks.  Some don\'t buffer it at all.  Its hard to say what will happen.','AAALwX///vc=',858,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/TemporaryBuffer.java','AAALwX///tc='),(287,3,'2010-06-30 08:46:39','P',1,'When you do the switch here, the overflow won\'t be flushed until the BufferedReader fills up. Does it make sense to do a flush() at his point, prior to returning the BufferedReader, to ensure that this part is done before wrapping the stream?\n\nSecondly, can the result of overflow() ever be a buffered writer (e.g. if we call this twice)? Should we code for that possibility and not wrap a wrapped bufferedoutputstream if that\'s the case? e.g. have something like if (!overflow instanceof BufferedOutputStream) overflow = new BufferedOutputStream(overflow,..)',NULL,858,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/TemporaryBuffer.java','AAALwX///vc='),(822,3,'2010-07-01 19:01:08','P',1,'Why not pull this up inside the try{} block? Then you can push down the declaration of commitId inside the try block as well.',NULL,860,7,'org.eclipse.jgit.junit/src/org/eclipse/jgit/junit/TestRepository.java','AAALwX///m4='),(822,1,'2010-07-01 21:54:04','P',1,'Good point, I could have moved the lookup inside the try and the variable too.  Just failed to notice it here.  I\'m not going to rewrite the series to fix this minor issue, and I don\'t think its worth the time of writing a new commit to fix it either.  Maybe next time someone is here they\'ll realize this stupid mistake and correct it.','AAALwX///m4=',860,7,'org.eclipse.jgit.junit/src/org/eclipse/jgit/junit/TestRepository.java','AAALwX///mA='),(131,1,'2010-07-01 21:54:04','P',1,'Yes, we should release this ObjectInserter.  But that\'s a lot of code to change, and I plan to move most tests to an in-memory repository which won\'t do compression/decompression of data.  Thus we wouldn\'t need to worry about leaking the Inflater handle during the test.\n\nAlso, the tests run in their own JVM, and do so pretty quickly right now.  Leaking Inflaters and waiting for the GC to fix things up with a finalizer isn\'t a big deal.  In fact, the GC might not even bother to run the finalizers, there isn\'t all that much garbage created during the tests that needs finalization, and the JVM might just terminate before its cleaned up.\n\nLong story short, its just not worth it given what we leak, and the amount of code that needs to change in current tests.\n\nNewer tests should however release stuff, yes, just to keep the programming style consistent.','AAALwX///m0=',860,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/merge/SimpleMergeTest.java','AAALwX///l8='),(131,3,'2010-07-01 19:01:08','P',1,'Generally speaking, don\'t we want to put on the \'release\' in the test as well?',NULL,860,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/merge/SimpleMergeTest.java','AAALwX///m0='),(164,1,'2010-07-01 21:54:04','P',1,'Yes, if this path runs multiple times, we release multiple times.  But an ObjectInserter (and an ObjectReader) are required to support using the object again after a release.  That is, the following is completely legal:\n\n  ObjectInserter oi = ....;\n  oi.insert(...);\n  oi.release();\n\n  oi.insert(...);\n  oi.release();\n\n  oi.release();\n  oi.insert(...);\n  oi.release();\n\nSo even a back-to-back release without any use between them is valid.  Its just a minor CPU time waste.','AAALwX///mw=',860,7,'org.eclipse.jgit/src/org/eclipse/jgit/merge/StrategySimpleTwoWayInCore.java','AAALwX///l0='),(164,3,'2010-07-01 19:01:08','P',1,'What happens if this path is called multiple times, and we keep releasing() the inserter? Won\'t that lead to multiple releases being called?',NULL,860,7,'org.eclipse.jgit/src/org/eclipse/jgit/merge/StrategySimpleTwoWayInCore.java','AAALwX///mw='),(50,49,'2010-06-16 21:23:39','P',1,'Done','AAALu3///Yw=',874,5,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparatorTest.java','AAALu3///Yk='),(50,8,'2010-06-16 21:04:13','P',1,'nit-pick: reads better as ...DoesNotExist',NULL,874,5,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparatorTest.java','AAALu3///Yw='),(50,8,'2010-06-16 21:04:13','P',1,'mis-spelled name',NULL,874,5,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitSyncInfoTest.java','AAALu3///Y0='),(50,49,'2010-06-16 21:23:39','P',1,'Done','AAALu3///Y0=',874,5,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitSyncInfoTest.java','AAALu3///Yg='),(13,8,'2010-06-16 21:04:13','P',1,'The plugin itself should not depend on easymock, only the test plugin',NULL,874,5,'org.eclipse.egit.core/META-INF/MANIFEST.MF','AAALu3///Y8='),(13,49,'2010-06-16 21:23:39','P',1,'True, I moved this dependency to org.eclipse.egit.core.test\n\nDone','AAALu3///Y8=',874,5,'org.eclipse.egit.core/META-INF/MANIFEST.MF','AAALu3///Yo='),(13,4,'2010-06-16 21:57:48','P',1,'I think this should be imported via package dependency (2.4 is available in galileo as well) :\n\nImport-Package: org.easymock; version=\"[2.4.0,3.0.0)\"\n\nor do you have a reason to use require-bundle for that ?\n\nwe also need to file a CQ for using that, I will do that.','AAALu3///Yo=',874,5,'org.eclipse.egit.core/META-INF/MANIFEST.MF','AAALvX////8='),(13,49,'2010-06-16 22:13:29','P',1,'No I don\'t have any reasons to have it as a required-bundle. It can be move into Import-Package section.','AAALvX////8=',874,5,'org.eclipse.egit.core/META-INF/MANIFEST.MF','AAALvX///+8='),(200,8,'2010-06-16 21:04:13','P',1,'Why isn\'t ContextMenuHelper used here?',NULL,874,5,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/views/synchronize/SynchronizeViewTest.java','AAALu3///Y4='),(200,49,'2010-06-16 21:23:39','P',1,'Because (as far as I remember) it throws ClassCastException in line 53','AAALu3///Y4=',874,5,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/views/synchronize/SynchronizeViewTest.java','AAALu3///Yc='),(115,49,'2010-06-19 23:56:18','P',1,'s/TrueFalse/ReturnTrue/\n\nDone','AAALwH///6w=',874,7,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparatorTest.java','AAALwH///5Y='),(115,4,'2010-06-19 22:57:16','P',1,'this method name sounds strange, what do you mean with shouldTrueFalse ?',NULL,874,7,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparatorTest.java','AAALwH///6w='),(318,49,'2010-06-19 23:56:18','P',1,'Done','AAALwH///6s=',874,7,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitSyncInfoTest.java','AAALwH///5U='),(318,4,'2010-06-19 22:57:16','P',1,'typo in method name : s/Deletation/Deletion/',NULL,874,7,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitSyncInfoTest.java','AAALwH///6s='),(64,49,'2010-06-19 23:56:18','P',1,'Done','AAALwH///6o=',874,7,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/common/EGitTestCase.java','AAALwH///5Q='),(64,4,'2010-06-19 22:57:16','P',1,'style nit: no braces around single line',NULL,874,7,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/common/EGitTestCase.java','AAALwH///6o='),(55,49,'2010-06-19 23:56:18','P',1,'Done','AAALwH///6k=',874,7,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/common/GitImportRepoWizard.java','AAALwH///5M='),(55,4,'2010-06-19 22:57:16','P',1,'style nit: no braces around single line',NULL,874,7,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/common/GitImportRepoWizard.java','AAALwH///6k='),(236,49,'2010-06-19 23:56:18','P',1,'Done','AAALwH///6g=',874,7,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/views/synchronize/SynchronizeViewTest.java','AAALwH///5I='),(236,4,'2010-06-19 22:57:16','P',1,'style nit: no braces around single line',NULL,874,7,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/views/synchronize/SynchronizeViewTest.java','AAALwH///6g='),(34,49,'2010-06-19 23:56:18','P',0,'@RunWith annotation were moved into EGitTestCase class. This change belongs also to this patch set.','AAALwH///6c=',874,7,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/wizards/clone/GitCloneWizardTest.java','AAALwH///5E='),(34,4,'2010-06-19 22:57:16','P',0,'how is this related to this change ?',NULL,874,7,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/wizards/clone/GitCloneWizardTest.java','AAALwH///6c='),(70,4,'2010-06-19 13:05:14','P',1,'typo: s/by any type/be any type/',NULL,890,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwH///78='),(88,1,'2010-07-02 00:04:53','P',1,'We can try to remove getDirectory() again, but basically the working tree related code explodes.\n\nWhat matters is, getDirectory() is used to tell you where the meta stuff is, like \"index\", \"config\", \"MERGE_HEAD\", \"MERGE_MSG\", \"FETCH_HEAD\".  For most repositories with a working tree, I think you would expect these files to be in .git/, and thus you expect there to be a meta directory to hold them.\n\nRight now I only care about getting a bare repository to run without a local filesystem.  Which means that meta directory being null is OK, we would never check the meta directory.\n\nBut to really do a workspace-in-the-cloud idea, you need to also split all of the meta stuff away from local file IO.  That\'s going to be a bigger task than just splitting the object/ref storage, based on what I was looking at as I did this series.\n\nI\'m open to pushing the refactoring further, but I would prefer to get the basic storage stuff done first.  We still need to get IndexPack done for example, it still requires local filesystem storage.  And the dumb transport fetch client also still mostly assumes local filesystem for the destination.\n\nIf we at least get the basic storage stuff done, we can start to do something slick like a bound-thin-client in EGit.  The working directory is the local filesystem, but the repository branches and objects are remote on a smart, git-aware object server, with recently accessed objects being local.  Then you can do some really slick thin-checkouts from eclipse.org for example, without needing to suck down everything, but still behave like you have it all.  (I\'m envisioning something a bit smarter than just shallow clone.)','AAALwX///jU=',890,6,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///h4='),(88,8,'2010-07-01 23:17:49','P',1,'The general form ought to be a string whose content interpreted by the implementation. Not sure that helps though.','AAALwX///nA=',890,6,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///jU='),(88,1,'2010-07-01 18:35:32','P',1,'No.  I tried to get rid of the concept of a directory on a repository, and it proved nearly impossible to do.\n\nInstead I had to define getDirectory() as being able to return null.','AAALwX///oQ=',890,6,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///nA='),(88,3,'2010-07-01 11:21:04','P',1,'Does this get refactored out at a later stage? Seems odd that an abstract repository would have a file system',NULL,890,6,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///oQ='),(1,4,'2010-06-18 23:49:35','P',1,'missing license header',NULL,892,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/AddConfigEntryDialog.java','AAALwH///80='),(1,4,'2010-06-18 23:49:35','P',1,'missing license header',NULL,892,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/GlobalConfigurationPreferencePage.java','AAALwH///8w='),(21,4,'2010-06-18 23:49:35','P',1,'typo: s/ro/or/',NULL,892,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALwH///8s='),(135,8,'2010-06-29 09:11:01','P',1,'isEmpty is Java6. We require only Java 5',NULL,892,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/AddConfigEntryDialog.java','AAALwX///yo='),(426,49,'2010-06-19 22:31:39','P',1,'Done','AAALwH///7M=',904,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///64='),(410,49,'2010-06-19 22:31:39','P',1,'Done','AAALwH///7Q=',904,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///68='),(402,49,'2010-06-19 22:31:39','P',1,'Done','AAALwH///7U=',904,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///7A='),(426,4,'2010-06-19 22:26:28','P',1,'style nit: no braces around single line',NULL,904,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///7M='),(410,4,'2010-06-19 22:26:28','P',1,'typo: add to members if folder exists in repository',NULL,904,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///7Q='),(402,4,'2010-06-19 22:26:28','P',1,'better: Check if this file exists in repository',NULL,904,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///7U='),(242,49,'2010-06-19 23:21:23','P',1,'Done','AAALwH///6I=',905,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///50='),(277,4,'2010-06-19 23:09:06','P',1,'style nit: no braces around single line',NULL,905,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///58='),(374,49,'2010-06-19 23:21:23','P',1,'Done','AAALwH///6A=',905,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///5o='),(372,49,'2010-06-19 23:21:23','P',1,'Done','AAALwH///6E=',905,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///5s='),(277,49,'2010-06-19 23:21:23','P',1,'Done','AAALwH///58=',905,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///5w='),(374,4,'2010-06-19 23:09:06','P',1,'style nit: no braces here',NULL,905,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///6A='),(372,4,'2010-06-19 23:09:06','P',1,'style nit: no braces around single line\n\ndon\'t put the bug number here, this belongs into the commit message and has no more relevance as soon as the bug is fixed. If somebody wants to understand why this was added he can check the project history (e.g. using git blame) and will find the bug number in the commit message',NULL,905,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///6E='),(242,4,'2010-06-19 23:09:06','P',1,'style nit: no braces around single line\n\ndo not put the bug number here, this belongs into the commit message',NULL,905,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwH///6I='),(30,4,'2010-06-20 21:33:26','d',1,'typo: s/synchornization/synchronization/',NULL,909,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/dto/GitSynchronizeData.java','AAALwH///4g='),(1040,1,'2010-06-30 23:00:03','P',1,'The variable declaration and assignment don\'t all fit on one line.  And when you do put them as one expression, eclipse was line wrapping the getRepository() part to the next line, which I found harder to read.  So, this is what you get.','AAALwX///tA=',914,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///rE='),(1032,1,'2010-06-30 23:00:03','P',1,'We could wrap it in an unmodifiableSet, but I don\'t care enough to bother.\n\nIf a caller finds out they can change this set, and does, and we later start caching it, you can bet that then we\'ll use an unmodifiableSet... and they will crash, and it wasn\'t an API breakage, because we told you its not modifiable.','AAALwX///tE=',914,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///rI='),(1040,3,'2010-06-30 19:54:11','P',1,'Why not in-line the repo declaration, like String name = getFullBranch() above?',NULL,914,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///tA='),(1032,3,'2010-06-30 19:54:11','P',1,'The doc suggests that it returns an unmodifiable collection; but as it is a HashSet, it can be mutated. If we want to enforce this, should we wrap in a Collections.unmodifiableSet?',NULL,914,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///tE='),(61,1,'2010-07-01 21:58:36','P',1,'No.  We want to check the alternates packs first before the local filesystem.\n\nBasically, looking at pack files is faster (no filesystem system calls) and more likely to hit (packs have the bulk of the objects).  So we intentionally examine pack files before we examine the loose objects.\n\nThat\'s why this code is so nasty.  We have to examine all pack files, recursively through alternates, *then* examine the loose objects directory, and recursively go through alternates.\n\nThis particular rule was hard-won on the C git side, and is based on experiences across lots of platforms, including Windows and Mac OS X where filesystem system calls are horribly slow compared to doing two or three binary search steps against an in-memory table held inside of the JVM heap.  :-)','AAALwX///mo=',915,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/FileObjectDatabase.java','AAALwX///lo='),(61,3,'2010-07-01 19:09:45','P',1,'Just as an observation, this will do a full descent of all the alternate handles before checking impl2. Is that desirable? Wouldn\'t it be better to do HasObject1(objectId) || hasObject2(objectId.name() || for(myalternates) hasObject1 || for( myalternates) hasObject2 ?',NULL,915,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/FileObjectDatabase.java','AAALwX///mo='),(448,1,'2010-07-01 21:58:36','P',1,'Crap.  Typo here that I introduced the whitespace.  Arrrrgh.  Thanks for catching it, that\'s just really sloppy of me.','AAALwX///mk=',915,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/FileRepository.java','AAALwX///lg='),(448,3,'2010-07-01 19:09:45','P',1,'Why the whitepsace between \'objectDatabase\' and \'myAlternates\' ?',NULL,915,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/FileRepository.java','AAALwX///mk='),(58,1,'2010-07-01 21:58:36','P',1,'Good point about the constructor being pointless.  Its a bad habit I developed some years ago.  I should stop doing this.','AAALwX///mg=',915,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/ObjectDatabase.java','AAALwX///lc='),(58,3,'2010-07-01 19:09:45','P',1,'This is unnecessary - the class is abstract, so has to be extended for initialisation purposes. And every object gets a default no-arg constructor anyway.',NULL,915,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/ObjectDatabase.java','AAALwX///mg='),(228,4,'2010-06-25 08:52:35','P',1,'trailing blank',NULL,929,2,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewBranchHandlingTest.java','AAALwX///38='),(75,4,'2010-06-25 08:52:35','P',1,'style nit: trailing whitespace',NULL,929,2,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewBranchHandlingTest.java','AAALwX///4A='),(37,4,'2010-06-25 08:52:35','P',1,'(fetch and push tests)',NULL,929,2,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewFetchAndPushTest.java','AAALwX///34='),(40,4,'2010-06-25 08:52:35','P',1,'(repository handling)',NULL,929,2,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewRepoHandlingTest.java','AAALwX///30='),(102,1,'2010-06-25 00:22:52','P',1,'I think your entire logic would be simplified if you could write a method such as:\n\n  static int trimTrailingWhitespace(int ptr, byte[] raw)\n\nand use that to correct ae and be above before you even start the main compare while loop.  Then when the compare is done, you don\'t need to worry about checking for tailing space on the end.\n\nIts not very common to have trailing spaces on the end of lines.  Prefiltering the line to trim it off will be mostly a no-op, or at most, one CR in a CRLF file, so very trivial.  Even if we break out on the first non-space character compare, its probably not a huge hit that we prefiltered ae,be at the start.\n\nLikewise, you can simplify the code with a trimLeadingWhitespace method that prefilters as,bs before the main while loop starts.  Then you know you are looking at a non-whitespace character at the start of the while loop, and only need to skip over whitespace characters after the first non-whitespace.  Which, that code should share a lot of similarity with trimLeadingWhitespace.  Possibly making my performance-nit above not very desirable to implement.',NULL,937,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawTextIgnoreAllWhitespace.java','AAALwX///5E='),(120,1,'2010-06-25 00:22:52','P',1,'Performance-nit: Same nit as above, pull raw[ptr] into a local variable so its not evaluated twice.',NULL,937,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawTextIgnoreAllWhitespace.java','AAALwX///5I='),(94,1,'2010-06-25 00:22:52','P',1,'Performance-nit:  Pull a.content[as] and b.content[bs] into local variables within the body of the while loop so we only evaluate the array index once per position.\n\nBasically, the compiler can\'t prove that a.content[as] wasn\'t modified between the two reads of it, so it\'ll have to read it again.  Since array bounds have to be checked at runtime, we have to recheck as against the array length.  The JIT _might_ be able to avoid the array bound check   Pulling into a local proves to the compiler it can cache the value safely.',NULL,937,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawTextIgnoreAllWhitespace.java','AAALwX///5M='),(76,1,'2010-06-25 00:22:52','P',1,'Style-nit:  In JGit we don\'t put curly braces around single line statements.',NULL,937,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawTextIgnoreAllWhitespace.java','AAALwX///5Q='),(52,1,'2010-06-25 00:22:52','P',1,'Style-nit: No @author tags.',NULL,937,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawTextIgnoreAllWhitespace.java','AAALwX///5U='),(1,1,'2010-06-25 00:22:52','P',1,'Please include the standard JGit copyright header on all new files.',NULL,937,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawCharUtil.java','AAALwX///5c='),(8,1,'2010-06-25 00:22:52','P',1,'Style-nit:  We don\'t include @author tags in JGit.',NULL,937,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawCharUtil.java','AAALwX///5Y='),(108,1,'2010-06-25 17:04:34','P',1,'What about when a is \"foo\" and b is \"f\"?  Wouldn\'t you be breaking out early when bs == be after the first iteration and return true, even though the strings aren\'t actually equal?',NULL,937,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawTextIgnoreAllWhitespace.java','AAALwX///2c='),(111,1,'2010-06-25 17:04:34','P',1,'Move these over to your RawCharUtil class, so we can use them in other subclasses of RawText.',NULL,937,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawTextIgnoreAllWhitespace.java','AAALwX///2g='),(92,1,'2010-06-25 18:46:34','P',1,'I wouldn\'t include this case in testEqualsWithWhitespace.  Do it in the test above, as these two compares don\'t have any whitespace on their lines.',NULL,937,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/RawTextIgnoreAllWhitespaceTest.java','AAALwX///10='),(65,1,'2010-06-25 18:46:34','P',1,'We should also test that foo != f, and f != foo, to make sure we test the end condition when we fall out of the main loop because one of the strings is shorter than the other.',NULL,937,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/RawTextIgnoreAllWhitespaceTest.java','AAALwX///14='),(93,1,'2010-06-25 18:46:34','P',1,'Given that you just trimmed whitespace before the loop, this is going to be redundant.  I think you can remove the trimLeadingWhitespace of as on 84/85 and just let these loops inside the main loop handle that.',NULL,937,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawTextIgnoreAllWhitespace.java','AAALwX///18='),(110,1,'2010-06-25 18:46:34','P',1,'Well, ideally ae - as = 0 and be - bs = 0 here.  That\'s the only way that we know we checked every character.  Thing is, this expression is an odd way to say it.\n\nWouldn\'t\n\n  return as == ae && bs == be;\n\nBe a more direct way  to say that we must have evaluated every character in both ranges?',NULL,937,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawTextIgnoreAllWhitespace.java','AAALwX///2A='),(86,1,'2010-06-28 17:52:21','P',1,'I\'m still having a hard time groking end > start.  The typical pattern is to say start < end, its easier to visualize.\n\nI think we can also drop out a subtraction instruction from the inner loop here if we are a bit smarter about how we handle the bounds:\n\n  int ptr = end - 1;\n  while (start <= ptr && isWhitespace(raw[ptr]))\n    ptr--;\n  return ptr + 1;',NULL,937,5,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawCharUtil.java','AAALwX///1k='),(133,1,'2010-06-25 00:24:28','P',1,'Can you somehow refactor this code so that the db.openBlob(id).getCachedBytes() part isn\'t copy-and-pasted identically between two lines?',NULL,938,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/Diff.java','AAALwX///44='),(96,1,'2010-06-25 00:24:28','P',1,'Please be very careful to not reformat existing code that isn\'t otherwise changing.  Especially for smaller changes like this.',NULL,938,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/Diff.java','AAALwX///48='),(47,1,'2010-06-25 00:24:28','P',1,'This should be squashed into your prior commit.',NULL,938,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawTextIgnoreAllWhitespace.java','AAALwX///40='),(133,1,'2010-06-28 18:02:21','P',1,'Style-nit: Space between if and (',NULL,938,6,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/Diff.java','AAALwX///0M='),(90,8,'2010-06-29 19:10:52','P',1,'This change on its own is fine with me.',NULL,939,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RepositorySelectionPage.java','AAALwX///xQ='),(177,8,'2010-06-29 16:34:23','P',1,'1)Capitalize spelling, i.. File Protocol\n2) No need to expand the abbreviations. Use descriptive\ntooltips, perhaps\n\nLocal repository\n\nFTP\n\nGit native transfer\n\nHTTP (smart or dumb)\n\nSecure HTTP (smart or dumb variant) \n\nSFTP transfer\n\nGit over SSH (also known as git+ssh)',NULL,939,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALwX///xk='),(448,1,'2010-06-30 23:01:43','P',1,'Because later in the series I remove toFile.  I didn\'t want to bother dealing with editing this here, to only remove it later.\n\nI\'m pretty sure that the way I did this series was non-optimal, and that yea, there\'s a case like this where something that should be changed in this commit, wasn\'t, because its gone 3 commits down or whatever.  *sigh*  That\'s what I get for doing some experimental refactoring hacking, and winding up with a 65 commit series.','AAALwX///s0=',949,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///q8='),(448,3,'2010-06-30 19:57:28','P',1,'Why is this objectDatabase not refactored as well? Granted, not everything has a file - is this function scheduled for later deprecation? If so, perhaps having a @deprecated would be a good idea. If not, can we call getObjectDatabase() and do some instanceof check?',NULL,949,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///s0='),(166,3,'2010-07-02 08:33:03','P',1,'You\'ve called it \'frb\' but this is an instance of \'RepositoryBuilder\'. Shouldn\'t this be a FileRepositoryBuilder instead?',NULL,959,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/Main.java','AAALwX///hI='),(166,1,'2010-07-03 00:06:01','P',1,'Thanks, fixed in http://egit.eclipse.org/r/1046','AAALwX///hI=',959,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/Main.java','AAALwX///Zs='),(87,3,'2010-07-02 08:33:03','P',1,'The constructor isn\'t used here - passed to builder, perhaps?',NULL,959,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/T0003_Basic.java','AAALwX///hE='),(87,1,'2010-07-03 00:06:01','P',1,'Thanks, also fixed in 1046.','AAALwX///hE=',959,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/T0003_Basic.java','AAALwX///Zk='),(97,3,'2010-07-02 08:33:03','P',1,'I thought blank lines introduced a paragraph anyway?',NULL,959,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/FileRepository.java','AAALwX///hA='),(97,1,'2010-07-03 00:06:01','P',1,'Eh.  Our style seems to be to include <p> anyway.  Might just be my habit from the dark days of Javadoc where \\n just meant space and <p> was required to get a proper paragraph break.','AAALwX///hA=',959,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/FileRepository.java','AAALwX///Zg='),(69,3,'2010-07-02 08:33:03','P',1,'I don\'t see the difference between this and the BaseRepositoryBuilder at this stage. Should this be abstract? If so, what is the difference? If not, then what\'s the distinction between this and a FileRepositoryBuilder?',NULL,959,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/RepositoryBuilder.java','AAALwX///g8='),(69,1,'2010-07-03 00:06:01','P',1,'BaseRepositoryBuilder is type parameterized by the the type of repository it creates, and the type of the builder itself, to implement all of the chaining methods.  Because of these two type parameters its a horrible thing to use in application level code.\n\nThis class exists to define those type parameters with sane defaults, and prevent application code from needing to care.  But FileRepositoryBuilder wants different values for the same type parameters, but still wants roughly the same logic.  So we throw all of that up in BaseRepositoryBuilder.','AAALwX///g8=',959,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/RepositoryBuilder.java','AAALwX///Zc='),(1022,3,'2010-07-02 08:44:00','P',1,'You added \'and has no working directory\' here but the test is still the same. If the \'has no working directory\' is just a clarification on what it means to be bare, then it would be better to change this to \'if the repository is bare (i.e. it has no working directory)\' so that people don\'t think it\'s a separate condition.',NULL,960,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///gw='),(1022,3,'2010-07-03 07:23:42','P',1,'Done','AAALwX///ZQ=',960,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///X8='),(1022,1,'2010-07-03 00:13:53','P',1,'See my attempt to clean this up in http://egit.eclipse.org/r/1047','AAALwX///gw=',960,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///ZQ='),(2,4,'2010-07-02 22:35:28','P',0,'I think the copyright should change here as in the previous class since your replace the complete class by an interface',NULL,961,1,'org.eclipse.jgit/src/org/eclipse/jgit/events/IndexChangedListener.java','AAALwX///cY='),(64,3,'2010-07-02 08:52:12','P',1,'This seems to be a utility method which doesn\'t otherwise belong in this class. Is the plan to evolve methods to add new ones here? Is there anywhere else we could put it (e.g. a static method on the event class?)',NULL,961,1,'org.eclipse.jgit/src/org/eclipse/jgit/events/ListenerList.java','AAALwX///go='),(2,4,'2010-07-02 22:35:28','P',0,'again this should be your copyright, nothing seems to be left from the original code',NULL,961,1,'org.eclipse.jgit/src/org/eclipse/jgit/events/RefsChangedListener.java','AAALwX///cQ='),(123,1,'2010-07-02 22:21:02','P',1,'Because we don\'t know how to produce their cache key?  What should be the cache key for a repository stored in memory?  Or \"in the cloud\"?  We don\'t know, and we don\'t have a factory method on the Repository class to give us one.\n\nI guess the change here would be to instead add a getRepositoryCacheKey() method to Repository and allow the implementation to override it with the key for this repository, then we can register and close through that key object.','AAALwX///dQ=',962,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/RepositoryCache.java','AAALwX///c8='),(123,8,'2010-07-02 22:15:08','P',1,'Why should not non-file repositories be cached?',NULL,962,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/RepositoryCache.java','AAALwX///dQ='),(275,1,'2010-07-02 22:21:02','P',1,'The only reason we produce FETCH_HEAD is to be compatible with C Git.  The only reason C Git produces FETCH_HEAD is to carry data from `git fetch` into `git merge` during a `git pull`, but it does also act as a handy reference for \"the last thing I got\".  Really the only value for JGit to be writing that file is for the last part, \"the last thing I got\".  We\'ll never need to carry data from our fetch to our merge code through a local file, that\'s nuts.\n\nI think its perfectly OK if we stop writing this file on less-conventional repositories.  If \"the last thing I got\" proves to be really useful there, we could try to update a standard ref called FETCH_HEAD via updateRef().  But again, a lot of this all predates the idea of remote tracking branches being updated during fetch.','AAALwX///dY=',962,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/FetchProcess.java','AAALwX///cg='),(275,8,'2010-07-02 22:15:08','P',1,'I guess there is some thought to following up here. Even if\nthe repo is not file based, shouldn\'t we store FETCH_HEAD\nsome other way?',NULL,962,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/FetchProcess.java','AAALwX///dY='),(119,1,'2010-07-02 22:43:37','P',1,'Experience is this will be a short list.  Single bit errors in the middle of a pack stream for one object.  Not the whole file being damaged, or truncated.  Of course a single bit error in the wrong object can ruin an entire tree of things that depend on it as a delta base.  :-(','AAALwX///cI=',968,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/PackFile.java','AAALwX///b0='),(119,8,'2010-07-02 22:37:29','P',1,'However when that happens, is a short list typical or not? What is the experience, single bit errors corrupt single objects or truncated files with lots of problems?',NULL,968,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/PackFile.java','AAALwX///cI='),(83,1,'2010-07-02 22:57:23','P',1,'Please see the rewrite of this code in http://egit.eclipse.org/r/1035.  I think I already have your concern fixed.','AAALwX///bU=',969,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/ByteArrayWindow.java','AAALwX///a4='),(98,1,'2010-07-02 22:57:23','P',1,'I don\'t think I see the problem.  If the data is truncated, inf.inflate() will return 0.  0 is not > 0, so the loop will break, and the method will return to the caller in PackFile.  The caller checks for inf.finished(), and marks the object corrupt if it returned false.','AAALwX///bs=',969,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/ByteArrayWindow.java','AAALwX///as='),(98,8,'2010-07-02 22:51:49','P',1,'This will hang if the checked data is truncated. See c10e13415705d63e4d5d2487ca6fff1fe1ff10bb for a patc',NULL,969,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/ByteArrayWindow.java','AAALwX///bs='),(83,8,'2010-07-02 22:51:49','P',1,'Add a check for corrupt data. If the compressed data is truncated inflate will return 0 and this loops forever.',NULL,969,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/ByteArrayWindow.java','AAALwX///bU='),(289,8,'2010-07-02 23:54:55','P',1,'-1 An explanatory message here.\n\n-2 Out of memory is not really the problem. This will most certainly lead anyone encountering this problem wrong. I\'d prefer  IllegalArgumentException here,',NULL,973,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/PackFile.java','AAALwX///aQ='),(289,8,'2010-07-05 21:32:01','P',1,'OK','AAALwX///Z8=',973,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/PackFile.java','AAALwX///Sk='),(289,1,'2010-07-02 23:58:40','P',1,'Fixed by killing it in http://egit.eclipse.org/r/1045.  With the streaming stuff fully implemented, the code is unreachable.','AAALwX///aQ=',973,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/PackFile.java','AAALwX///Z8='),(74,2,'2010-06-28 17:18:15','d',0,'This looks fine',NULL,977,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RepositorySelectionPage.java','AAALwX///0o='),(115,11,'2010-07-01 10:07:14','P',1,'We need some arguments to be mentioned right here (much better) or in the commit message (at least).',NULL,977,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RepositorySelectionPage.java','AAALwX///oc='),(252,4,'2010-07-05 16:07:16','d',1,'Done','AAALwX///WM=',977,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RepositorySelectionPage.java','AAALwX///TE='),(252,3,'2010-07-03 20:28:54','P',1,'We shouldn\'t have an ordinal. An ordinal implies some kind of total ordering over all the elements, which we can\'t guarantee. For example, if I want to add a new Protocol \'pigeon\' I\'m going to give it MAX+1 (which is 8 in this case). But if someone else wants to add \'avian\' (also as 8) we now have a clash. It gets worse if the next version of (E/J)Git comes out with \'psychic (8)\' we now have a duplicate (or triplicate).\n\nThe ordinal appears to add no value at all; we can impose a total ordering over the protocol using the lexicographic sorting of the protocol names; instead of using an ArrayList, we can use a TreeMap instead.\n\nLastly, the value of ordinal appears completely unused.',NULL,977,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RepositorySelectionPage.java','AAALwX///WM='),(6,11,'2010-07-06 21:55:37','P',1,'What about conflict markers?',NULL,977,7,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RepositorySelectionPage.java','AAALwX///Jg='),(1,63,'2010-06-29 12:27:10','P',1,'Please add a license header.',NULL,978,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/ActionCommands.java','AAALwX///yY='),(248,63,'2010-06-29 12:27:10','P',1,'Matthias, you can use HandlerUtil.getActivePart(event); instead. Note that null may be returned or you can swap it with getActivePartChecked(ExecutionEvent) instead.',NULL,978,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryActionHandler.java','AAALwX///yM='),(238,63,'2010-06-29 12:27:10','P',1,'Matthias, you can use HandlerUtil.getActiveShell(event); instead. Note that null may be returned or you can swap it with getActiveShellChecked(ExecutionEvent) instead.',NULL,978,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryActionHandler.java','AAALwX///yQ='),(156,63,'2010-06-29 12:27:10','P',1,'If you have an ExecutionEvent, you can do...\n\nHandlerUtil.getCurrentSelection(executionEvent);',NULL,978,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryActionHandler.java','AAALwX///yU='),(69,6,'2010-07-20 07:18:23','P',1,'Here the code from 2b083c3f21a3553b6211c978b744f2259c8fd9ca is missing.',NULL,978,9,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/MergeActionHandler.java','AAALw3///9U='),(74,1,'2010-06-28 23:59:56','P',1,'You should add a test with trailing whitespace differences, to make sure you don\'t ignore trailing whitespaces here.',NULL,979,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/RawTextIgnoreLeadingWhitespaceTest.java','AAALwX///zs='),(74,1,'2010-06-28 23:59:56','P',1,'Add tests with leading whitespace, to make sure it isn\'t ignored by the trailing type.',NULL,979,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/RawTextIgnoreTrailingWhitespaceTest.java','AAALwX///zo='),(74,1,'2010-06-28 23:59:56','P',1,'Add a test with leading whitespace to make sure leading whitespace differences are still reported.',NULL,979,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/RawTextIgnoreWhitespaceChangeTest.java','AAALwX///zk='),(74,73,'2010-06-29 00:20:51','P',1,'That\'s being done by \"     foo\" != \"foo\"','AAALwX///zk=',979,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/RawTextIgnoreWhitespaceChangeTest.java','AAALwX///zU='),(77,73,'2010-06-29 00:11:12','P',1,'Whoops, that was something I left over from testing, and forgot to fix. It also means I forgot to do the hash function correctly...','AAALwX///zw=',979,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawTextIgnoreWhitespaceChange.java','AAALwX///zc='),(77,1,'2010-06-28 23:59:56','P',1,'Why are we bypassing hashing here?  If we can\'t hash, can we avoid the cost of the hashes object altogether and simply not create it?  That may mean you need to *not* extend from RawText here, or you need to expose a method that lets you override the construction of the hashes table and instead returns null.\n\nFWIW, you can probably still hash here.  You just have to collapse multiple spaces into a single one when you compute the hash value.',NULL,979,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawTextIgnoreWhitespaceChange.java','AAALwX///zw='),(624,8,'2010-07-07 21:27:16','P',1,'ok','AAALwX///IQ=',987,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALwX///CI='),(624,1,'2010-07-07 00:35:05','P',1,'Our caller is supposed to try/finally the PackWriter, calling PackWriter release() which will call reader.release().\n\nDoing a release here early as soon as writing is done is just to try and kick out memory that we don\'t need to create an index file.  Tossing it into a try/finally here in writePack is probably pointless, if we fail here, we\'re heading for our caller\'s finally block anyway.','AAALwX///SU=',987,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALwX///IQ='),(624,8,'2010-07-05 21:43:31','P',1,'Why no try/finally here?',NULL,987,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALwX///SU='),(21,46,'2010-07-06 05:27:51','P',1,'No yet all... Needs another round.','AAALwX///Qk=',1007,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/AllRepositoriesViewTests.java','AAALwX///PM='),(21,8,'2010-07-05 22:51:16','P',1,'Didn\'t you fix the bugs?',NULL,1007,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/AllRepositoriesViewTests.java','AAALwX///Qk='),(302,46,'2010-07-06 05:27:51','P',1,'Done','AAALwX///Qg=',1007,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/ConfigureUriPage.java','AAALwX///PI='),(302,8,'2010-07-05 22:51:16','P',1,'no \"-\" here',NULL,1007,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/ConfigureUriPage.java','AAALwX///Qg='),(79,46,'2010-07-06 05:27:51','P',1,'Oops. Thanks for pointing this out.','AAALwX///Qc=',1007,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/tree/PropertyTester.java','AAALwX///PE='),(79,8,'2010-07-05 22:51:16','P',1,'This one. Depends on how you want to define and use \"pushExists\"',NULL,1007,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/tree/PropertyTester.java','AAALwX///Qc='),(7,6,'2010-08-25 09:22:00','P',1,'I think this title is misleading. The change is not only about tests.',NULL,1007,14,'/COMMIT_MSG','AAALyn///z8='),(141,1,'2010-06-30 23:29:51','P',1,'Please don\'t move this line around in the constructor, its not essential to the patch.',NULL,1015,1,'org.eclipse.jgit/src/org/eclipse/jgit/patch/FileHeader.java','AAALwX///q0='),(97,4,'2010-07-01 09:32:55','P',1,'style nit: trailing whitespace',NULL,1020,1,'org.eclipse.egit.doc/help/book.css','AAALwX///oo='),(91,4,'2010-07-01 09:32:55','P',1,'style nit: trailing whitespace',NULL,1020,1,'org.eclipse.egit.doc/help/book.css','AAALwX///os='),(85,4,'2010-07-01 09:32:55','P',1,'style nit: trailing whitespace',NULL,1020,1,'org.eclipse.egit.doc/help/book.css','AAALwX///ow='),(120,73,'2010-07-01 23:35:06','d',1,'Done','AAALwX///kY=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///i0='),(194,73,'2010-07-01 23:51:12','d',1,'Done','AAALwX///kA=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///ic='),(190,73,'2010-07-01 23:48:45','d',1,'Done','AAALwX///kE=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///ig='),(227,73,'2010-07-02 00:03:16','d',1,'Done','AAALwX///js=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///iI='),(128,73,'2010-07-01 23:48:04','d',1,'Done','AAALwX///kM=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///ik='),(221,73,'2010-07-01 23:57:14','d',1,'Done','AAALwX///j0=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///iM='),(123,73,'2010-07-01 23:45:01','d',1,'Done','AAALwX///kU=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///io='),(220,73,'2010-07-01 23:57:13','d',1,'Done','AAALwX///j4=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///iQ='),(215,73,'2010-07-01 23:53:43','d',1,'Done','AAALwX///jk=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///iU='),(198,73,'2010-07-01 23:52:23','d',1,'Done','AAALwX///j8=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///iY='),(221,1,'2010-07-01 22:57:21','P',1,'Only put the list back if its not empty?',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///j0='),(220,1,'2010-07-01 22:57:21','P',1,'remove returns the DiffEntry.  Which eliminates the need for the get on the line above.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///j4='),(198,1,'2010-07-01 22:57:21','P',1,'You can\'t do that.  The Arrays.asList result has a constant length.  Which means on the 3rd item for the same key, you\'ll throw an exception during add().\n\nThis has to be an ArrayList, but you can set its size as 2:\n\n  ArrayList<DiffEntry> tmp = new ArrayList<DiffEntry>(2);\n  tmp.add(old);\n  tmp.add(del);\n  map.put(id, tmp);\n\nOn the next addition when have a 3rd item, the array list will double in capacity to 4 elements, then 8, 16, etc.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///j8='),(98,73,'2010-07-01 23:21:41','d',1,'Done','AAALwX///kI=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///jA='),(215,1,'2010-07-01 22:57:21','P',1,'Make the 100 a constant, but lets call it something specific like EXACT_RENAME.  For various reasons I think we might want the exact rename score to be bigger than any possible similarity score.  It will be easier to tweak that if it has a special constant assigned to it.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///jk='),(92,73,'2010-07-01 23:18:53','d',1,'Done','AAALwX///kc=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///jM='),(227,1,'2010-07-01 22:57:21','P',1,'To make this easier to extend with similarity based matching code, I would just do:\n\n  added = tempAdded\n\nHere, and then above in getEntries() just before you set done, I would do something like:\n\n  entries.addAll(added);\n  entries.addAll(deleted);\n  added = null;\n  deleted = null;\n  done = true;\n  Collections.sort(entries, ...);\n\nThen we can just plug in the similarity pass by invoking a new similarity pass method after the findExactRenames() method is run.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///js='),(194,1,'2010-07-01 22:57:21','P',1,'Hmm.  AbbreviatedObjectId is immutable, and hashable.  Instead of copying to an ObjectId, lets just hash the AbbreviatedObjectId as the key.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///kA='),(92,1,'2010-07-01 22:57:21','P',1,'Style-nit:  Javadoc should be like a git commit message, a short single line sentence on the first line, paragraph break (usually with <p> HTML element) and then the rest of the method description.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///kc='),(190,1,'2010-07-01 22:57:21','P',1,'I think findExactRenames() is a more descriptive name for this method since its only doing the exact case.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///kE='),(98,1,'2010-07-01 22:57:21','P',1,'You should document that this needs to have exactly two tree iterators involved, since 0 and 1 are accessed in the loop.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///kI='),(128,1,'2010-07-01 22:57:21','P',1,'Don\'t test on the ObjectId, use the FileMode.  If its FileMode.MISSING then that side doesn\'t exist.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///kM='),(123,1,'2010-07-01 22:57:21','P',1,'Don\'t abbreviate here.  Create the full ObjectId.\n\nReally what you should do is:\n\n  MutableObjectId idBuf = new MutableObjectId();\n  while (walk.next()) {\n    DiffEntry entry = new DiffEntry();\n\n    tw.getObjectId(idBuf, 0);\n    entry.oldId = AbbreviatedObjectId.fromObjectId(idBuf);\n\n    tw.getObjectId(idBuf, 1);\n    entry.newId = AbbreviatedObjectId.fromObjectId(idBuf);\n  }\n\nThat keeps object allocation down to a minimum by using a locally allocated, but mutable, object id buffer.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///kU='),(120,1,'2010-07-01 22:57:21','P',1,'Error messages need to be externalized strings in JGitText class and the JGitText properties file.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///kY='),(107,73,'2010-07-02 00:03:33','d',1,'Done','AAALwX///kk=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/AbbreviatedObjectId.java','AAALwX///h8='),(93,73,'2010-07-02 00:03:30','d',1,'Done','AAALwX///kQ=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/AbbreviatedObjectId.java','AAALwX///iA='),(80,73,'2010-07-02 00:03:27','d',1,'Done','AAALwX///kw=',1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/AbbreviatedObjectId.java','AAALwX///iE='),(107,1,'2010-07-01 22:57:21','P',1,'Again, reformatting.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/AbbreviatedObjectId.java','AAALwX///kk='),(91,1,'2010-07-01 22:57:21','P',1,'Please also document that the converted id is complete, and thus can be recast back to an ObjectId with no loss.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/AbbreviatedObjectId.java','AAALwX///ko='),(93,1,'2010-07-01 22:57:21','P',1,'Accept AnyObjectId since you are copying the field values.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/AbbreviatedObjectId.java','AAALwX///kQ='),(80,1,'2010-07-01 22:57:21','P',1,'Please avoid reformatting code you aren\'t changing.',NULL,1029,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/AbbreviatedObjectId.java','AAALwX///kw='),(128,1,'2010-07-02 00:17:36','P',1,'Use entry.oldMode and entry.newMode.  They are cheaper to access than calling walk.getFileMode(), which has to do quite a bit of work actually.',NULL,1029,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///ho='),(68,1,'2010-07-02 00:17:36','P',1,'Style-nit: Pointless javadoc blocks should be removed, or made non-pointless.  :-)',NULL,1029,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwX///hs='),(124,1,'2010-07-07 02:40:14','P',1,'Renamed inflate to setInput in Ie93a5bae0e9e637b5e822d56993ce6b562c6ad15','AAALwX///Vc=',1035,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/ByteWindow.java','AAALwX///II='),(124,8,'2010-07-04 21:27:03','P',1,'The implementations doesn\'t actually inflate. Could we have a better name or javadoc to describe why it doesn\'t',NULL,1035,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/ByteWindow.java','AAALwX///Vc='),(71,4,'2010-07-02 22:55:48','P',1,'typo in method name',NULL,1036,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALwX///bc='),(60,4,'2010-07-02 22:55:48','P',1,'typo in method name',NULL,1036,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALwX///bg='),(136,4,'2010-07-02 22:55:48','P',1,'typo in method name',NULL,1036,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALwX///bM='),(112,4,'2010-07-02 22:55:48','P',1,'typo in method name',NULL,1036,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALwX///bQ='),(91,4,'2010-07-02 22:55:48','P',1,'typo in method name',NULL,1036,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALwX///bY='),(60,6,'2010-07-05 12:39:41','d',1,'Done','AAALwX///bg=',1036,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALwX///T4='),(136,6,'2010-07-05 10:51:30','d',1,'Done','AAALwX///bM=',1036,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALwX///UI='),(112,6,'2010-07-05 10:51:27','d',1,'Done','AAALwX///bQ=',1036,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALwX///UM='),(91,6,'2010-07-05 10:51:25','d',1,'Done','AAALwX///bY=',1036,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALwX///UQ='),(71,6,'2010-07-05 10:51:22','d',1,'Done','AAALwX///bc=',1036,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALwX///UU='),(111,4,'2010-07-02 22:55:48','P',1,'message should be externalized',NULL,1036,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///a8='),(100,4,'2010-07-02 22:55:48','P',1,'exception message should be externalized',NULL,1036,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///bA='),(126,1,'2010-07-02 21:33:33','P',1,'If you also do\n\n  tw.setFilter(PathFilter.create(filepath))\n\nYou don\'t need to do anything in the while loop.  Just execute:\n\n  while (tw.next()) {\n    // Already positioned to the file we want to touch.\n    ....\n  }\n\nThe DirCacheBuilderIterator knows how to manage the rest of the entries outside of the space that the PathFilter matches against and ensure they stay unaffected in the resulting DirCache.',NULL,1036,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///ec='),(96,1,'2010-07-02 21:33:33','P',1,'Don\'t lock the DirCache if you are simply reading and unlocking, its sort of a waste of time.  Use read() if all you need is to look at it.\n\nBut, I have to question, why is this block here?  If the file doesn\'t exist in the working tree, and yet we were told to add it, we have nothing to do, don\'t we?  That is `rm foo; git add foo` doesn\'t stage the deletion.  We probably don\'t want to do that here either.',NULL,1036,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///eg='),(126,6,'2010-07-05 12:38:52','d',1,'Done','AAALwX///ec=',1036,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///T8='),(100,6,'2010-07-05 10:58:04','d',1,'This is obsolete because now we do not check this anymore (see comment from Shawn above).','AAALwX///bA=',1036,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///UA='),(111,6,'2010-07-05 10:55:40','d',1,'This is obsolete because I now also accept folders.','AAALwX///a8=',1036,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///UE='),(96,6,'2010-07-05 12:39:14','d',1,'I added this block because I wanted to achieve the same behaviour as what I saw in msysgit: When a file \'foo\' does not exist in HEAD and it is added by calling \'git add foo\' there is an error message \'fatal: pathspec \'foo\' did not match any files\'.\n\nIn the new implementation using PathFilterGroup I do not check this anymore and just do nothing.','AAALwX///eg=',1036,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///Ug='),(136,4,'2010-07-02 22:55:48','P',1,'Returns a command object not a command class',NULL,1036,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAALwX///a0='),(145,1,'2010-07-02 21:33:33','P',1,'Here you call this filepattern, but in AddCommand you call it filepath, and actually treat it as relative to the root of the working directory.\n\nSimilar to merge() I think add() should be just a factory which provides the command, and arguments should be set on the command.  Then we can have addFile(), and addPattern(), which have different behaviors as to how they setup the add request.  Further, we can add multiple things in one call, so that the DirCache only needs to be locked and written once, rather than per file specified in the user interface.',NULL,1036,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAALwX///ek='),(136,6,'2010-07-05 10:50:06','d',1,'This mistake occurs also in the JavaDoc of the other factory methods. I suggest to change that in a subsequent commit.','AAALwX///a0=',1036,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAALwX///Uc='),(145,6,'2010-07-05 10:51:12','d',1,'I removed the parameter here as you suggested.','AAALwX///ek=',1036,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAALwX///UY='),(321,6,'2010-07-08 08:44:32','P',1,'Ok, so we keep it here for now.','AAALwX///K0=',1036,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALwX///HE='),(321,1,'2010-07-06 19:56:05','P',1,'This was probably a mistake in the DirCacheEntry API.  We should overload setLength() to accept a long so application level code doesn\'t have to do this type cast.  Its likely that some day the Git index file format will support files >4 GiB and applications shouldn\'t have to go change their code when that occurs.',NULL,1036,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALwX///K0='),(133,6,'2010-07-08 08:44:32','P',1,'I solved it by using your proposal below.','AAALwX///LE=',1036,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///G0='),(132,6,'2010-07-08 08:44:32','P',1,'Done','AAALwX///LI=',1036,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///G8='),(139,6,'2010-07-08 08:44:32','P',1,'No, this problem still exists. I posted a question on jgit-dev.','AAALwX///LA=',1036,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///Gs='),(140,6,'2010-07-08 08:44:32','P',1,'Done','AAALwX///K8=',1036,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///Gw='),(124,6,'2010-07-08 08:44:32','P',1,'Done','AAALwX///K4=',1036,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///HA='),(124,1,'2010-07-06 19:56:05','P',1,'I don\'t think this will work well if filepatterns is empty.  Should we throw an IllegalStateException during call() if filepatterns.isEmpty() is true?',NULL,1036,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///K4='),(140,1,'2010-07-06 19:56:05','P',1,'IMHO, the length and lastModified should be captured *before* you write the object out to the object database.  That way if a change occurs to the file while we are saving it to the database, the index entry will appear dirty again, which it should be.\n\nAlso, the length, lastModified and FileMode should be available off the FileTreeIterator if the file exists.  Which means you can actually kill that getRawMode(1) test I suggested above, and rely on the cached stat information that was pulled up during the TreeWalk\'s traversal:\n\n  FileTreeIterator f = tw.getTree(1, FileTreeIterator.class);\n  if (f != null) { // the file exists\n    entry.setLength(f.getEntryLength());\n    entry.setLastModified(f.getEntryLastModified());\n    entry.setFileMode(f.getEntryFileMode());\n    entry.setObjectId(ow.writeBlob(file));',NULL,1036,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///K8='),(139,1,'2010-07-06 19:56:05','P',1,'I think it was always returning true due to the nanosecond bug you found and fixed?','AAALwX///NI=',1036,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///LA='),(133,1,'2010-07-06 19:56:05','P',1,'The faster way to implement this is to ask the TreeWalk if the entry exists in tree #1.  We already know in memory whether or not the file exists, we don\'t need to stat it again:\n\n  if (tw.getRawMode(1) != 0) {',NULL,1036,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///LE='),(132,1,'2010-07-06 19:56:05','P',1,'I don\'t understand why this test is necessary.  Is it because the DirCacheBuilder is giving you 3 records for a file with a merge conflict?  Or is something else going on?  If its necessary, I would appreciate some comment to help explain this condition, because it just doesn\'t make sense to me.',NULL,1036,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///LI='),(139,6,'2010-07-06 14:44:36','P',1,'This leads to the fact that during builder.commit the method DirCacheEntry.mightBeRacilyClean() always returns true and then the timestamp is wiped out. Is this really intended?',NULL,1036,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALwX///NI='),(136,6,'2010-07-08 08:43:37','P',1,'Done.\n\nI\'ll fix this in the other factory methods in a subsequent commit.','AAALwX///BQ=',1036,4,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAALwX///AM='),(136,4,'2010-07-07 22:05:15','P',1,'this returns an object not a class:\ns/Returns a command class/Returns a command object/',NULL,1036,4,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAALwX///BQ='),(43,6,'2010-07-08 08:43:37','P',1,'Done','AAALwX///BU=',1036,4,'org.eclipse.jgit/src/org/eclipse/jgit/api/NoFilepatternException.java','AAALwX///AQ='),(43,4,'2010-07-07 22:05:15','P',1,'typo:\ns/doesn\'t/don\'t/',NULL,1036,4,'org.eclipse.jgit/src/org/eclipse/jgit/api/NoFilepatternException.java','AAALwX///BU='),(52,3,'2010-07-02 21:09:57','P',1,'We don\'t need to check in commented code, do we?',NULL,1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/clone/SourceBranchPage.java','AAALwX///fI='),(52,46,'2010-07-05 06:44:13','P',1,'Done','AAALwX///fI=',1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/clone/SourceBranchPage.java','AAALwX///VI='),(141,3,'2010-07-02 21:09:57','P',1,'as above',NULL,1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RefSpecPage.java','AAALwX///e4='),(137,3,'2010-07-02 21:09:57','P',1,'as above',NULL,1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RefSpecPage.java','AAALwX///e8='),(114,3,'2010-07-02 21:09:57','P',1,'Let\'s not check in commented code',NULL,1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RefSpecPage.java','AAALwX///fA='),(141,46,'2010-07-05 06:44:13','P',1,'Done','AAALwX///e4=',1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RefSpecPage.java','AAALwX///U8='),(137,46,'2010-07-05 06:44:13','P',1,'Done','AAALwX///e8=',1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RefSpecPage.java','AAALwX///VA='),(114,46,'2010-07-05 06:44:13','P',1,'Done','AAALwX///fA=',1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RefSpecPage.java','AAALwX///VE='),(656,3,'2010-07-02 21:09:57','P',1,'This looks like a bad reformatting. Was it accidental?',NULL,1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RepositorySelectionPage.java','AAALwX///e0='),(731,3,'2010-07-02 21:09:57','P',1,'Commented code',NULL,1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RepositorySelectionPage.java','AAALwX///es='),(721,3,'2010-07-02 21:09:57','P',1,'Commented code',NULL,1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RepositorySelectionPage.java','AAALwX///ew='),(721,46,'2010-07-05 06:44:13','P',1,'Done','AAALwX///ew=',1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RepositorySelectionPage.java','AAALwX///U0='),(656,46,'2010-07-05 06:44:13','P',1,'Done','AAALwX///e0=',1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RepositorySelectionPage.java','AAALwX///U4='),(731,46,'2010-07-05 06:44:13','P',1,'Done','AAALwX///es=',1037,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/components/RepositorySelectionPage.java','AAALwX///Uw='),(99,11,'2010-07-02 16:30:31','P',1,'Please fix these whitespace errors',NULL,1038,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/common/GitImportRepoWizard.java','AAALwX///fk='),(71,11,'2010-07-02 16:30:31','P',1,'whitespace error',NULL,1038,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/wizards/share/SharingWizardTest.java','AAALwX///fg='),(87,8,'2010-07-03 23:21:19','P',1,'I think Shawn wanted to have fewer event listener collection and we don\'t want globals for this.','AAALwX///XU=',1041,1,'org.eclipse.jgit/src/org/eclipse/jgit/events/ListenerList.java','AAALwX///Vk='),(87,3,'2010-07-03 20:38:58','P',1,'I still think this is the wrong class to be adding the \'addListener\' to, since it will always keep growing. Can we not have a ConfigChangeEvent.addListener(listenerList) instead? That way, to add a new one, you just need to add a new class and not modify this one every time.',NULL,1041,1,'org.eclipse.jgit/src/org/eclipse/jgit/events/ListenerList.java','AAALwX///XU='),(81,3,'2010-07-03 20:42:04','d',1,'Right, but there\'s a difference between \'stuff that is a default constant\' and \'stuff that\'s assigned by parameters passed in the constructor\'. By putting the variable assignment into the field declaration (whether final or otherwise) it helps to declare that that field has a \'default\' value rather than something that gets assigned as a side-effect of the constructor.\n\nI\'m happy with the constant, and if it\'s a stylistic requirement then it\'s just a matter of taste; I thought I\'d explain what my thoughts were.','AAALwX///W8=',1042,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/LargePackedDeltaObject.java','AAALwX///V4='),(81,1,'2010-07-03 17:56:48','P',1,'They aren\'t final, they do change during the object\'s life.  And our style tends to be to initialize in the constructor, not inline in the declaration for non-final fields.\n\nAnyway, I pulled the -1 into a constant to better declare the intent of the value.','AAALwX///Xc=',1042,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/LargePackedDeltaObject.java','AAALwX///W8='),(81,3,'2010-07-03 09:28:38','P',1,'If these are two constant values, why not put them into the variable declaration? e.g. private int type = Constants.OBJ_BAD.',NULL,1042,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/LargePackedDeltaObject.java','AAALwX///Xc='),(975,8,'2010-07-03 09:16:11','P',1,'This leads to the wrong stack trace',NULL,1049,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/IndexPack.java','AAALwX///Xs='),(963,8,'2010-07-03 09:16:11','P',1,'-I\'m sliightly allergic to exceptions without some information.\n-Throw the corrupt stream exception right \n\n(same thing in the \"copies\" of this code',NULL,1049,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/IndexPack.java','AAALwX///Xw='),(951,3,'2010-07-03 20:19:22','P',1,'The argument is called \'keep\' but this is phrased as \'do not discard\' - similarly, there\'s a \'discard\' synonym for \'do not keep\'. Either we should change the var (keep -> discard) or we should change the comment to be \'keep\' and \'do not keep\'',NULL,1049,2,'org.eclipse.jgit/src/org/eclipse/jgit/transport/IndexPack.java','AAALwX///WY='),(417,5,'2010-07-07 13:47:27','P',1,'No idea. I didn\'t originally created this comment. This method was initally created by copying GitIndex.Entry.ismodified() where this comment was introduced.\n\nBut it\'s seems to be that different filesystems have different precisions. Ext3 supports only a precision of seconds. See:  http://www.coderanch.com/t/384700/java/java/File-lastModified-windows-vs-linux. If we come into the situation where we compare timestamps written by different filesystems we may have to deal with it here.','AAALwX///Lo=',1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///Gc='),(400,5,'2010-07-07 13:47:27','P',1,'Got it. Wrote a new version of this check now working only on raw-mode and bit operations. Only  5 lines now (and 8 lines of comment))','AAALwX///I4=',1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///GQ='),(2,5,'2010-07-07 13:47:27','P',0,'Done','AAALwX///MA=',1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///GU='),(422,5,'2010-07-07 13:47:27','P',1,'Done','AAALwX///Iw=',1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///GY='),(396,5,'2010-07-07 13:47:27','P',1,'Yes, it\'s a todo. I\'ll make that clear','AAALwX///L0=',1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///HI='),(387,5,'2010-07-07 13:47:27','P',1,'Done','AAALwX///Is=',1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///HM='),(378,5,'2010-07-07 13:47:27','P',1,'Done','AAALwX///L8=',1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///HQ='),(400,1,'2010-07-06 23:10:32','P',1,'We shouldn\'t ever fully skip the file mode check.  Long story short, we don\'t want to confuse a symlink with a file if the WorkingTreeIterator subclass can actually detect symlinks (and I hope to have that in the future).\n\nThe basis of the checkFilemode flag is only to ignore a difference in the executable bit of the file.  Any other type of difference must be honored as different, even if checkFilemode was false.',NULL,1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///I4='),(387,1,'2010-07-06 23:10:32','P',1,'Style-nit: Unnecessary blank lines here.',NULL,1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///Is='),(422,1,'2010-07-06 23:10:32','P',1,'I think this logic is wrong.  Shouldn\'t it be:\n\n  if (forceContentCheck) {\n    if (fileLastModified == cacheLastModified)\n      return false; // Same time, don\'t check content.\n    else\n      return !getEntryObjectId().equals(entry.getObjectId());\n  } else {\n    // No content check forced, assume dirty if stat differs.\n    return fileLastModified != cacheLastModified;\n  }\n\nBasically, isn\'t the meaning of forceContentCheck that you want to \"refresh the index\", aka update the stat information for a path to match what is in the working directory if the file contents are the same?  Its not to fix the racily clean problem, its to fix paths where the user has touched the file but not actually made changes to its contents.\n\nRacily clean should be handled differently, but also should force a content check.  To handle racily clean, you would check for racily clean condition side of the forceContentCheck block above before testing the file modification times, and do the content check there.\n\nRight now your code is doing content checks on files that are unchanged, and are proven to be unchanged by stat information.  That hurts on a big repository.',NULL,1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///Iw='),(396,4,'2010-07-06 15:58:57','P',1,'is this a TODO ?',NULL,1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///L0='),(378,4,'2010-07-06 15:58:57','P',1,'typo: s/we to/we want to/',NULL,1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///L8='),(417,4,'2010-07-06 15:58:57','P',1,'typo: s/prevision/precision/\n\nWhy does git under windows only store seconds ? In this afternoons debugging session with Stefan I saw ms coming from NTFS.',NULL,1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///Lo='),(2,4,'2010-07-06 15:58:57','P',0,'maybe you want to add your copyright here ?',NULL,1059,2,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///MA='),(410,4,'2010-07-07 21:12:45','d',1,'style nit: pad blanks around operator',NULL,1059,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwX///Cg='),(425,1,'2010-07-16 01:55:08','P',1,'Isn\'t this expression entirely redundant?\n\nIf we remove it we still get the same behavior.  When forceContentCheck is false we fall through to the else below, which compares the values and if != returns true.',NULL,1059,6,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwn////c='),(425,5,'2010-07-16 08:06:58','P',1,'Amazing you find this. Yesterday Matthias and I also saw this duplicate check. I this check propose a new patchset and submit.','AAALwn////c=',1059,6,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALwn///+4='),(33,49,'2010-07-08 15:11:58','P',1,'No I didn\'t want to implement this, I simply forgot to remove this comment.\n\nDone.','AAALwX///Js=',1064,2,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitTestResourceVariantTree.java','AAALwX///BE='),(33,4,'2010-07-07 21:58:29','P',1,'did you want to implement this ?',NULL,1064,2,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitTestResourceVariantTree.java','AAALwX///Js='),(29,4,'2010-07-07 21:58:29','P',1,'[1] says (I am not an expert here hence I may be wrong but the restriction looks pretty strict): \n\nContainers implement the IAdaptable interface; extensions are managed by the platform\'s adapter manager.\n\nSee Also:\nPlatform.getAdapterManager(), IProject, IFolder, IWorkspaceRoot\n\nRestriction:\nThis interface is not intended to be implemented by clients.\n\nRestriction:\nThis interface is not intended to be extended by clients.\n\n[1] http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/IContainer.html',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/resource/GitContainer.java','AAALwX///CM='),(78,4,'2010-07-07 21:58:29','P',1,'should we throw an exception here to prevent that calling non-implemented methods causes trouble elsewhere ?',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/resource/GitContainer.java','AAALwX///CQ='),(35,4,'2010-07-07 21:58:29','P',1,'why package visisibility ? all the rest is public ...',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/resource/GitContainer.java','AAALwX///Jk='),(27,4,'2010-07-07 21:58:29','P',1,'we want javadoc for all public classes/methods',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/resource/GitContainer.java','AAALwX///Jo='),(35,4,'2010-07-07 21:58:29','P',1,'missing javadoc',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/resource/GitFile.java','AAALwX///CY='),(35,4,'2010-07-07 21:58:29','P',1,'this variable name looks weird use project instead',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/resource/GitProject.java','AAALwX///B8='),(35,49,'2010-07-08 15:11:58','P',1,'Done','AAALwX///B8=',1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/resource/GitProject.java','AAALwX///BI='),(494,4,'2010-07-07 21:58:29','P',1,'how does \"L\" associate with FILE ?',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/resource/GitResource.java','AAALwX///B4='),(494,49,'2010-07-08 15:11:58','P',1,'implementation of this method is equivalent with org.eclipse.core.internal.resources.Resource.getTypeString().\n\nTo be Honest I don\'t know how \"L\" is associate with FILE.','AAALwX///B4=',1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/resource/GitResource.java','AAALwX//++k='),(194,4,'2010-07-07 21:58:29','P',1,'I would recommend do not defer handling exceptions to a subsequent patch',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/dto/GitSynchronizeData.java','AAALwX///Bo='),(194,49,'2010-07-15 20:31:51','P',1,'It turns out that getCommit() method isn\'t used any more, so that it would be removed in upcoming change set.','AAALwX///Bo=',1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/dto/GitSynchronizeData.java','AAALwX//+wA='),(37,6,'2010-07-08 12:10:31','P',1,'You could directly return the dstRev. The next three lines don\'t do anything, do they?',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitRemoteResourceVariantTree.java','AAALwX//+/s='),(31,6,'2010-07-08 12:10:31','P',1,'For me the name of the method (\"Base\") is confusing. You use this method in the GitBaseResourceVariantTree and the GitRemoteResourceVariantTree. Why not just call the method getRevCommit?',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitRemoteResourceVariantTree.java','AAALwX//+/w='),(37,49,'2010-07-08 15:11:58','P',1,'Indeed my mistake, I already change it.','AAALwX//+/s=',1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitRemoteResourceVariantTree.java','AAALwX//++c='),(31,49,'2010-07-08 15:11:58','P',1,'Good point.\n\nDone','AAALwX//+/w=',1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitRemoteResourceVariantTree.java','AAALwX//++g='),(27,4,'2010-07-07 21:58:29','P',1,'I think some javadoc would help here',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantByteStore.java','AAALwX///B0='),(27,49,'2010-07-15 20:31:51','P',1,'It seams that this class is useless, therefore it would be removed in next patch set.','AAALwX///B0=',1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantByteStore.java','AAALwX//+wM='),(37,6,'2010-07-08 12:10:31','P',0,'I wonder if we could make maybe use of the org.eclipse.team.core.variants.ThreeWayResourceComparator which does the content comparison and other things.',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparator.java','AAALwX//+/o='),(37,49,'2010-07-15 20:31:51','P',0,'IMHO we can think about that in next iteration, current patch set is big enough.','AAALwX//+/o=',1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparator.java','AAALwX//+wE='),(112,6,'2010-07-08 12:10:31','P',1,'See comment on GitRemoteResourceVariantTree.getBaseRevCommit',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwX//+/k='),(112,49,'2010-07-08 15:11:58','P',1,'Done','AAALwX//+/k=',1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALwX//++U='),(140,4,'2010-07-07 21:58:29','P',1,'is this dead code or a TODO ?',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitSyncInfo.java','AAALwX///Bs='),(111,4,'2010-07-07 21:58:29','P',1,'is this dead code or a TODO ?',NULL,1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitSyncInfo.java','AAALwX///Bw='),(140,49,'2010-07-08 15:11:58','P',1,'This is partially dead code it should be rewritten after API of GitBlobResourceVariant will be stable','AAALwX///Bs=',1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitSyncInfo.java','AAALwX//++M='),(111,49,'2010-07-08 15:11:58','P',1,'This is partially dead code it should be rewritten after API of GitBlobResourceVariant will be stable','AAALwX///Bw=',1064,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitSyncInfo.java','AAALwX//++Q='),(86,4,'2010-07-07 21:58:29','P',0,'missing javadoc',NULL,1064,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitSubscriberParticipant.java','AAALwX///Bg='),(39,4,'2010-07-07 21:58:29','P',0,'that\'s pretty obvious, would be more interesting to document the parameter',NULL,1064,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitSubscriberParticipant.java','AAALwX///Bk='),(39,49,'2010-07-15 20:31:51','P',0,'Done','AAALwX///Bk=',1064,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitSubscriberParticipant.java','AAALwX//+v0='),(86,49,'2010-07-15 20:31:51','P',0,'Done','AAALwX///Bg=',1064,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitSubscriberParticipant.java','AAALwX//+v8='),(139,49,'2010-07-15 20:42:08','P',1,'I don\'t know why this test randomly fails when it is run as part of test suite, but it it is run as single test case it always passes.',NULL,1064,3,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeSubscriberTest.java','AAALwX//+vk='),(107,49,'2010-07-15 20:42:08','P',1,'I don\'t know why this test randomly fails when it is run as part of test suite, but it it is run as single test case it always passes.',NULL,1064,3,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeSubscriberTest.java','AAALwX//+vo='),(196,49,'2010-07-20 17:53:26','P',1,'This is not the case why GitResourceVariantTreeSubscriberTest fails, but of course it is an issue that needs to be fixed\n\nDone','AAALw3///8c=',1064,4,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeTest.java','AAALw3///60='),(309,49,'2010-07-20 17:53:26','P',0,'Done','AAALw3///8o=',1064,4,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeTest.java','AAALw3///6o='),(265,49,'2010-07-20 17:53:26','P',0,'Done','AAALw3///8g=',1064,4,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeTest.java','AAALw3///6s='),(238,49,'2010-07-20 17:53:26','P',1,'Done','AAALw3///8k=',1064,4,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeTest.java','AAALw3///6w='),(196,6,'2010-07-20 11:26:03','P',1,'This input stream is never closed. This even leads to test errors because the project cannot be deleted in tearDown,',NULL,1064,4,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeTest.java','AAALw3///8c='),(265,6,'2010-07-20 11:26:03','P',0,'This input stream is never closed. This even leads to test errors because the project cannot be deleted in tearDown,',NULL,1064,4,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeTest.java','AAALw3///8g='),(238,6,'2010-07-20 11:26:03','P',1,'This input stream is also never closed.',NULL,1064,4,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeTest.java','AAALw3///8k='),(309,6,'2010-07-20 11:26:03','P',0,'This input stream is never closed. This even leads to test errors because the project cannot be deleted in tearDown,',NULL,1064,4,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeTest.java','AAALw3///8o='),(62,6,'2010-07-21 09:45:52','d',1,'This makes a lot of sense.','AAALw3///6k=',1064,4,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariant.java','AAALw3///4U='),(62,49,'2010-07-20 17:53:26','P',1,'I\'ll prefer to make such change in separate patch, since this one is quite big and it would be easier to track such changes.','AAALw3///8U=',1064,4,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariant.java','AAALw3///6k='),(62,6,'2010-07-20 11:26:03','P',1,'This is displayed in the compare editor. I think the blobId does not make sense here. A user does not know what to do woth that. I would like to see the commit id. The commit Id is also diplayed elsewhere in the UI. \n\nThis would still adhere to the javadoc: Return a content identifier that is used to differentiate versions or revisions of the *same* resource.',NULL,1064,4,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariant.java','AAALw3///8U='),(110,6,'2010-07-21 09:46:18','d',1,'Agreed','AAALw3///6g=',1064,4,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparator.java','AAALw3///4Q='),(110,49,'2010-07-20 17:53:26','P',1,'Indeed, I didn\'t spot that earlier, this is same code. But IMHO this should be made by separate patch ;)','AAALw3///8Y=',1064,4,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparator.java','AAALw3///6g='),(110,6,'2010-07-20 11:26:03','P',1,'What\'s the difference here between shouldIncludeLocal() and not?\n\nI would suggest that we always use the workspace version as source. See also my general comments.',NULL,1064,4,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparator.java','AAALw3///8Y='),(62,49,'2010-08-02 12:07:55','P',1,'This is my stupid merge bug :|\n\nDone','AAALxn///9w=',1064,7,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparatorTest.java','AAALxn///9o='),(62,6,'2010-08-02 11:24:24','P',1,'Now I get an error at the next statement: java.lang.IllegalStateException: Repository already exists\n\nCan you use new TestRepository(Repository repository) instead? You have created an instance of FileRepository before.',NULL,1064,7,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparatorTest.java','AAALxn///9w='),(20,6,'2010-08-02 11:24:24','P',0,'Rebase failed, the class does not compile: The types ArrayList, List, Git, RefUpdate, Ref and ObjectId were removed from the list of imports but they are still referenced.',NULL,1064,7,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeTest.java','AAALxn///+A='),(20,49,'2010-08-02 12:07:55','P',0,'Done','AAALxn///+A=',1064,7,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeTest.java','AAALxn///9k='),(69,6,'2010-08-02 11:24:24','P',1,'Now I get an error at the next statement: java.lang.IllegalStateException: Repository already exists\n\nCan you use new TestRepository(Repository repository) instead? You have created an instance of FileRepository before.',NULL,1064,7,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitSyncInfoTest.java','AAALxn///90='),(69,49,'2010-08-02 12:07:55','P',1,'Done','AAALxn///90=',1064,7,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/synchronize/GitSyncInfoTest.java','AAALxn///9g='),(126,6,'2010-08-02 14:24:49','P',1,'You could also use (getComparator().compare(base, remote)) here, then you do not need the id\'s here. This would better encapsulate the responsibility of comparison to the comparator',NULL,1064,8,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitSyncInfo.java','AAALxn///88='),(123,6,'2010-08-02 14:24:49','P',1,'Here you already know that local and base version are equal. So the kind can only be IN_SYNC or INCOMING, right?\n\nif (getComparator().compare(base, remote)) -> IN_SYNC\nelse -> INCOMING',NULL,1064,8,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitSyncInfo.java','AAALxn///9A='),(325,74,'2010-07-07 11:20:39','d',1,'At least on GTK, always the first working set type is selected. So \"Next\" is always enabled.','AAALwX///Hk=',1069,2,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewTest.java','AAALwX///Gk='),(325,46,'2010-07-07 06:39:40','P',1,'This fails for me, as the \"Next\" button is disabled; apparently some item in the tree must be selected to enable the button.',NULL,1069,2,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewTest.java','AAALwX///Hk='),(88,6,'2010-07-07 13:07:25','P',1,'You can use DirCache.getEntryCount() instead or the deprecated GitIndex.',NULL,1074,1,'org.eclipse.egit.core.test/src/org/eclipse/egit/core/test/op/TrackUntrackOperationTest.java','AAALwX///GI='),(13,74,'2010-07-07 14:37:58','P',1,'wouldn\'t it be better to depend on 3.5.0 or do we really rely on bugfixes of the service releases?',NULL,1075,2,'org.eclipse.egit.ui/META-INF/MANIFEST.MF','AAALwX///Eo='),(51,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/FileTreeEntry.java','AAALwX///EM='),(54,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/GitlinkTreeEntry.java','AAALwX///EI='),(58,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexTreeWalker.java','AAALwX///EE='),(629,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///D0='),(602,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///D4='),(571,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///D8='),(689,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///Do='),(676,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///Ds='),(641,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///Dw='),(556,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALwX///EA='),(54,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/SymlinkTreeEntry.java','AAALwX///Dk='),(55,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/TreeEntry.java','AAALwX///Dg='),(52,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Treeish.java','AAALwX///Dc='),(64,2,'2010-07-07 15:41:24','P',1,'Should be \"not performed\" but doesn\'t matter anymore..',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/WorkDirCheckout.java','AAALwX///DU='),(66,2,'2010-07-07 15:41:24','P',1,'Should we point them somewhere else? Our policy at Eclipse is that if you deprecate something, you generally want to point them to use another class...',NULL,1077,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/WorkDirCheckout.java','AAALwX///DY='),(525,1,'2010-07-08 18:25:54','P',1,'This new method should have a unit test.',NULL,1085,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALwX//+8c='),(542,1,'2010-07-08 18:25:54','P',1,'Don\'t initialize this here, it increases the chances that we would forget to set the return value from MyersDiff.\n\nInstead just declare the variable as final, and initialize it in each of the arms below of the conditional statements.  Its only 2 locations, and the compiler can prove that we have set it for each of the different conditions.',NULL,1085,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALwX//+8g='),(542,73,'2010-07-08 18:47:28','P',1,'Done','AAALwX//+8g=',1085,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALwX//+8I='),(541,1,'2010-07-08 18:25:54','P',1,'Instead of \"UTF-8\" use Constants.CHARSET.',NULL,1085,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALwX//+8k='),(537,73,'2010-07-08 18:47:28','P',1,'Done','AAALwX//+8o=',1085,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALwX//+8M='),(537,1,'2010-07-08 18:25:54','P',1,'When can this be thrown?',NULL,1085,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALwX//+8o='),(541,73,'2010-07-08 18:47:28','P',1,'Done','AAALwX//+8k=',1085,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALwX//+8Q='),(528,1,'2010-07-08 18:25:54','P',1,'s/It it/It is/',NULL,1085,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALwX//+8s='),(528,73,'2010-07-08 18:47:28','P',1,'Done','AAALwX//+8s=',1085,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALwX//+8U='),(144,1,'2010-07-08 23:16:13','P',1,'Again, score',NULL,1085,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/DiffFormatterTest.java','AAALwX//+60='),(120,1,'2010-07-08 23:16:13','P',1,'Again, score of 0 for a modify.',NULL,1085,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/DiffFormatterTest.java','AAALwX//+64='),(92,1,'2010-07-08 23:16:13','P',1,'You should also do something like:\n\n  assertEquals(0, fh.getStartOffset());\n  assertEquals(fh.getBuffer().length, fh.getEndOffset());',NULL,1085,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/DiffFormatterTest.java','AAALwX//+68='),(88,1,'2010-07-08 23:16:13','P',1,'A modify should have a score of 0.',NULL,1085,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/DiffFormatterTest.java','AAALwX//+7A='),(544,1,'2010-07-08 23:16:13','P',1,'I think the comment is incomplete for IOException.  Other reasons are we cannot read one of the blobs in order to generate the edit list.  Typically we document those by adding CorruptObjectException and MissingObjectException to the throws clauses, and to the javadoc.  I missed that on the original formatting code when I moved it here.  *sigh*',NULL,1085,3,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALwX//+7M='),(548,1,'2010-07-08 23:16:13','P',1,'Oooh.  Its a PrintStream.  Yuck.  Actually, we don\'t need this to be a PrintStream, everyone is handling their own encoding.  You can write to buf directly.',NULL,1085,3,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALwX//+7Q='),(117,1,'2010-07-08 23:33:49','P',1,'Our resulting FileHeader should have PatchType.BINARY.  It doesn\'t because you aren\'t setting it in this case.',NULL,1085,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/DiffFormatterTest.java','AAALwX//+6g='),(576,1,'2010-07-08 23:33:49','P',1,'Flush isn\'t necessary, its a no-op on a ByteArrayOutputStream.',NULL,1085,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALwX//+6o='),(147,1,'2010-07-08 23:33:49','P',1,'Good catch, thanks for fixing that.',NULL,1085,4,'org.eclipse.jgit/src/org/eclipse/jgit/patch/FileHeader.java','AAALwX//+6k='),(141,4,'2010-07-12 23:16:16','P',1,'Currently branch deletion doesn\'t check if any commits would become unreachable from remaining branches. Setting the force update flag is not a minor thing which should go unnoticed for the user as this may result in data loss (if some commits become unreachable).\n\nAs the corresponding dialog text specifies this fact I think the logic is ok, but this comment should be corrected.',NULL,1087,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/tree/command/DeleteBranchCommand.java','AAALwX//+zQ='),(114,4,'2010-07-12 23:16:16','P',1,'style nit: we don\'t use braces around single line blocks',NULL,1087,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/tree/command/DeleteBranchCommand.java','AAALwX//+zU='),(103,4,'2010-07-12 23:16:16','P',1,'style nit: we don\'t use braces around single line blocks',NULL,1087,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/tree/command/DeleteBranchCommand.java','AAALwX//+zY='),(256,1,'2010-07-12 17:21:48','P',1,'I find this awkward way to phrase the condition.  Elsewhere we talk about the common * 100 / max, so why not do the same here?\n\n  min * 100 / max < renameScore',NULL,1091,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/SimilarityRenameDetector.java','AAALwX//+20='),(317,1,'2010-07-12 17:46:13','P',1,'Style-nit: Break should be on next line.',NULL,1093,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/SimilarityRenameDetector.java','AAALwX//+2c='),(306,1,'2010-07-12 17:46:13','P',1,'You can short-circuit this loop entirely if dirSim == dirMax after the above loop.  This happens when the rename is just a file rename within the same directory, in which case you can just set dirScoreLtr and dirScoreRtl to 100.',NULL,1093,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/SimilarityRenameDetector.java','AAALwX//+2g='),(307,1,'2010-07-12 17:46:13','P',1,'Style-nit: Break should be on next line.',NULL,1093,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/SimilarityRenameDetector.java','AAALwX//+2k='),(266,73,'2010-07-12 18:15:51','P',1,'Would the final score be out of 10000, or just the content score? Since we\'re using 7 bits to hold the score in the matrix, we would have to change the encoding scheme to have the final score be up to 10000. If we leave the final score to be [0,100] I don\'t see how we would be getting any more precision for tie breaking.','AAALwX//+2U=',1093,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/SimilarityRenameDetector.java','AAALwX//+2M='),(302,1,'2010-07-12 17:46:13','P',1,'Style-nit: Break should be on next line.',NULL,1093,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/SimilarityRenameDetector.java','AAALwX//+2o='),(266,1,'2010-07-12 17:46:13','P',1,'I know we talked about this being 90/10, but I wonder if that\'s still a good decision.  Most of the test scores dropped by a good amount.  In git content is (mostly) king.  I wonder if we weakened the content signal too much by making it only 90%.\n\nI just checked the C Git source code, I think they are using under 1% for the name similarity score.\n\nMaybe we compute this as 99%/1%:\n\n  (contentScore * 99 + nameScore * 1) / 100\n\nWhich means we actually have a lot of rounding error.  Since both scores are currently in the [0,100] range maybe we boost them to be in the [0,10000] range.  Combined they still won\'t overflow an int but we can carry some more precision into the final score computation so that a near tie at the content level can be broken by a strong name similarity.\n\nI would modify the SimilarityIndex.score() method to take a base parameter, that is, how many steps the score range should occupy between [0, base].  Then you can pass in 10000 here and make it clear the score is out of 10000 rather than 100 for the content.',NULL,1093,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/SimilarityRenameDetector.java','AAALwX//+2U='),(321,1,'2010-07-12 17:46:13','P',1,'Style-nit: Don\'t create a local variable just to return an expression.  Just return it.',NULL,1093,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/SimilarityRenameDetector.java','AAALwX//+2Y='),(270,1,'2010-07-12 19:41:11','P',1,'Please update your commit message to reflect what you actually did.',NULL,1093,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/SimilarityRenameDetector.java','AAALwX//+1c='),(298,4,'2010-07-12 21:34:29','P',1,'could you shed some light on what Ltr and Rtl postfixes mean ?',NULL,1093,3,'org.eclipse.jgit/src/org/eclipse/jgit/diff/SimilarityRenameDetector.java','AAALwX//+0c='),(370,1,'2010-07-10 01:57:18','P',1,'Can we please keep this file sorted by key name?',NULL,1096,1,'org.eclipse.jgit/resources/org/eclipse/jgit/JGitText.properties','AAALwX//+4I='),(429,1,'2010-07-10 01:57:18','P',1,'Please keep the class sorted by key name.',NULL,1096,1,'org.eclipse.jgit/src/org/eclipse/jgit/JGitText.java','AAALwX//+4E='),(28,4,'2010-07-12 23:30:37','P',1,'This javadoc is a bit sloppy ...',NULL,1117,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/SelectResetTypePage.java','AAALwX//+zI='),(344,1,'2010-07-12 21:37:33','P',1,'We should also test what happens when you ask for it to compute here.  It should return a,b,c,d unmodified since these aren\'t exact renames.',NULL,1123,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/RenameDetectorTest.java','AAALwX//+0I='),(36,1,'2010-07-13 16:33:29','P',1,'Right here, it can never be null, so your change seems pointless to me!',NULL,1127,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/internal/util/ExceptionCollector.java','AAALwX//+yM='),(86,1,'2010-07-13 16:33:29','P',1,'I\'m not sure how statuses can ever be null.  It just should  not be.',NULL,1127,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/internal/util/ExceptionCollector.java','AAALwX//+yQ='),(320,1,'2010-07-16 01:28:27','P',1,'Style-nit:  Our toString style looks more like\n\n  DiffEntry[ADD newName]\n  DiffEntry[COPY oldName -> newName score]\n  DiffEntry[DELETE oldName]\n\netc...  Please match it here.  Of course this is a bit easier, you can do buf.append(type) to get the type part and not have to duplicate the name in both the case label and the string text.',NULL,1130,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALwn////k='),(468,1,'2010-07-16 01:28:27','P',1,'Style-nit: This can be a static method.',NULL,1130,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwn////o='),(516,1,'2010-07-16 01:28:27','P',1,'Style-nit: We don\'t put () around ?: in a return.',NULL,1130,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALwn////s='),(191,5,'2010-07-19 16:02:31','P',0,'You should remove this comment! The content is checked by workspaceIterator.isModified().',NULL,1138,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAALw3///9o='),(296,1,'2010-07-20 03:07:16','P',1,'Should we also delete this rule?  IIRC the only reason we had it was to ensure already smudged entries stayed smudged.  If we change our smudge logic to be length based this no longer makes any sense, and is actually a source of bugs by always selecting modified files as potentially racily clean.',NULL,1142,1,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALw3///9g='),(37,6,'2010-09-07 08:31:19','P',0,'Done','AAALyn///e0=',1144,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/ValidationUtils.java','AAALy3///9o='),(37,8,'2010-08-30 19:12:00','P',0,'Why was this removed?. This function is stiill in use by the another create branch dialog that expects this particular behavior. Please fix.',NULL,1144,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/ValidationUtils.java','AAALyn///e0='),(131,6,'2010-07-20 11:47:10','P',1,'Done','AAALw3///9E=',1147,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALw3///8A='),(144,6,'2010-07-20 11:46:33','P',1,'I think that the block is covering all cases. If the file doesn\'t exist the update flag is set and the file is in the index then the file is not added to the newly created index (this is the else if ).\n\nI added a new test method testAddWithoutParameterUpdate and commented the existing one testAddWithParameterUpdate. They handle the six interesting cases. I do not test the case of \"file exists neither in workdir nor inindex\".','AAALw3///8w=',1147,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALw3///8M='),(144,5,'2010-07-20 08:51:00','P',1,'I think this block here is not covering all cases. E.g. if the file doesn\'t exist, the update flag is set and the file is in the index: that\'s happening when you just delete a tracked file in the work-dir and call \"add -u\". \nYou expect the file to be deleted. But we just add it again.\n\nCheck your if\'s against all possible combinations of \"update flag set\", \"file exists in workdir\", \"file exists in index\" -- these are just 8 cases.',NULL,1147,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALw3///8w='),(131,5,'2010-07-20 08:51:00','P',1,'Why do we add another iterator over the Dircache? We already have one in the Walk and we can reuse him.',NULL,1147,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALw3///9E='),(155,6,'2010-08-02 09:26:28','P',1,'I still do not understand the logic behind these t0 etc. Why is the timestamp here t0? The value of dcIt.getDirCacheEntry().getLastModified() here is the third in the TreeSet<Long> modTimes, but why do I get t0 here?\n\nShouldn\'t the Map lookup in RepositoryTestCase be prefilled with the modTimes?',NULL,1147,5,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/AddCommandTest.java','AAALxn///+I='),(318,44,'2010-07-21 07:45:47','P',1,'I\'ll do a separate change for DirCache.\nI\'ll leave the stuff here as is because GitIndex is deprecated.','AAALw3///7E=',1152,3,'org.eclipse.jgit/src/org/eclipse/jgit/lib/GitIndex.java','AAALw3///4s='),(133,44,'2010-07-21 07:45:47','P',1,'Done','AAALw3///7I=',1152,3,'org.eclipse.jgit/src/org/eclipse/jgit/lib/GitIndex.java','AAALw3///4w='),(318,1,'2010-07-20 15:53:00','P',1,'We should put this retry logic into LockFile too, because DirCache uses that.\n\nWe could either keep this code here, or better, convert the class to use LockFile rather than its own custom logic.  The LockFile stuff is more robust anyway.',NULL,1152,3,'org.eclipse.jgit/src/org/eclipse/jgit/lib/GitIndex.java','AAALw3///7E='),(133,1,'2010-07-20 15:53:00','P',1,'This stuff should be part of the FS class.  Maybe declare:\n\n  /**\n   * Does this file system have problems with atomic renames?\n   *\n   * @return true if the caller should retry a failed rename of a lock file.\n   */\n  public abstract boolean retryFailedLockFileCommit();',NULL,1152,3,'org.eclipse.jgit/src/org/eclipse/jgit/lib/GitIndex.java','AAALw3///7I='),(132,1,'2010-07-20 20:37:29','P',1,'Please see the work I\'m doing in http://egit.eclipse.org/r/1156.  It implements isEntryIgnored() on the FileTreeIterator.','AAALw3///68=',1153,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALw3///5E='),(132,1,'2010-07-20 16:16:58','P',1,'Sadly this wasn\'t quite what I had in mind with the ignore stuff.  But I was too distracted by my other refactoring work to review it in time and it got submitted anyway.\n\nWe\'re ripping through the checkout directory now *twice*.  Once to find .gitignore files and build a table of what needs to be ignored, and again as you traverse it.\n\nWhat I wanted to do was to have the WorkingTreeIterator keep the IgnoreNode for that level within itself.  Then you can just ask:\n\n  tw.getTree(1, WorkingTreeIterator.class).isIgnored())\n\nto determine if the current item is ignored, or not.  By keeping the IgnoreNode inside of the WorkingTreeIterator we already have the full path up to the root through the parent pointers.  And we have fast efficient knowledge of whether or not there is even a .gitignore in this directory.',NULL,1153,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALw3///68='),(114,44,'2010-07-30 09:35:04','P',1,'Now we do...',NULL,1159,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/CommitActionHandler.java','AAALxn////c='),(191,44,'2010-07-30 09:35:04','P',1,'too much TABs',NULL,1159,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/CommitActionHandler.java','AAALxn////Y='),(114,6,'2010-08-02 15:08:33','P',1,'Done','AAALxn////c=',1159,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/CommitActionHandler.java','AAALxn///8I='),(191,6,'2010-08-02 15:08:33','P',1,'Done','AAALxn////Y=',1159,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/CommitActionHandler.java','AAALxn///8M='),(56,2,'2010-08-26 00:34:38','d',1,'We should probably make a prettier dialog for this... it just looks like you get something with a ton of of text... other than that, looks great!',NULL,1160,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/tree/command/RenameBranchCommand.java','AAALyn///so='),(62,1,'2010-07-22 18:10:19','P',1,'Style-nit:  Remove commented out code.',NULL,1161,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RacyGitTests.java','AAALw3///0Q='),(227,1,'2010-07-22 18:10:19','P',1,'Please don\'t use platform encoding in tests.',NULL,1161,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RacyGitTests.java','AAALw3///0U='),(194,1,'2010-07-22 18:10:19','P',1,'Why deleteOnExit?  If you create this file in the trash directory for this test, it will be cleaned up automatically when the test ends.  We also can delete it when the function returns.',NULL,1161,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RacyGitTests.java','AAALw3///0Y='),(227,5,'2010-07-22 22:03:46','P',1,'Done','AAALw3///0U=',1161,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RacyGitTests.java','AAALw3///z0='),(194,5,'2010-07-22 22:03:46','P',1,'I don\'t wanted the file to be in the working-dir (where trash files go) because I inspect the work-dir in my tests. But I choose your other proposal to delete it directly in this method.','AAALw3///0Y=',1161,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RacyGitTests.java','AAALw3///z4='),(62,5,'2010-07-22 22:03:46','P',1,'Done','AAALw3///0Q=',1161,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RacyGitTests.java','AAALw3///z8='),(138,1,'2010-07-22 18:10:19','P',1,'Please only declare variables within the scope they are needed, like inside of the while loop.',NULL,1161,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTestCase.java','AAALw3///0c='),(147,1,'2010-07-22 18:10:19','P',1,'This message index/file is the opposite of what the string actually is.',NULL,1161,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTestCase.java','AAALw3///0g='),(147,5,'2010-07-22 22:03:46','P',1,'Done','AAALw3///0g=',1161,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTestCase.java','AAALw3///zs='),(138,5,'2010-07-22 22:03:46','P',1,'really, that\'s new to me. I have no problems doing so. But I personally never liked used declarations inside loops. No long discussion about style: if it\'s the style we use in jgit - so be it.','AAALw3///0c=',1161,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTestCase.java','AAALw3///zw='),(59,1,'2010-07-22 17:53:15','P',1,'We should test the write functionality by actually reading the file here and making sure the format is what we expect, rather than relying on the read code path.',NULL,1162,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/MergeHeadMsgTest.java','AAALw3///0o='),(59,5,'2010-07-22 22:38:54','P',1,'Done','AAALw3///0o=',1162,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/MergeHeadMsgTest.java','AAALw3///zg='),(1568,1,'2010-07-22 17:53:15','P',1,'We always should be writing an LF after each ID.  Also, the IDs know how to copy themselves out better:\n\n  id.copyTo(fos);\n  id.write(\'\\n\');\n\nBecause of these tiny writes, the FileOutputStream should be a BufferedOutputStream so we can write everything in a single system call, rather than two syscalls per object being merged.',NULL,1162,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALw3///0s='),(1567,1,'2010-07-22 17:53:15','P',1,'Please spell \'\\n\' as \'\\n\'.',NULL,1162,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALw3///0w='),(1567,5,'2010-07-22 22:38:54','P',1,'Done','AAALw3///0w=',1162,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALw3///zc='),(1568,5,'2010-07-22 22:38:54','P',1,'great, since also the last Id gets a \\n I can get rid of some code and one variable here.','AAALw3///0s=',1162,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALw3///zY='),(1482,1,'2010-07-27 18:47:41','P',1,'Hmm.  We must have missed this earlier.  We probably should be a bit more forgiving and use RawParseUtils.decode().  Its possible the commit message is already in UTF-8.  Or that its a local encoding.  RawParseUtils will fall back to the local decoding if its not UTF-8.',NULL,1162,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALxH///2I='),(250,1,'2010-07-22 17:44:33','P',1,'This conflicts with my change I3f8af29066cc5a2132dc4a75c9654d97800f2f18.',NULL,1164,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/PackWriter.java','AAALw3///04='),(7,6,'2010-07-23 07:24:57','P',1,'This is really annoying. There seems to be an encoding problem. I\'\' try to fix that.','AAALw3///zU=',1167,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAALw3///y8='),(7,15,'2010-07-22 22:33:04','P',1,'Unintended change?',NULL,1167,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAALw3///zU='),(92,44,'2010-07-22 14:53:56','P',1,'Done','AAALw3///2s=',1168,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/RepositoriesViewContentProvider.java','AAALw3///2M='),(92,46,'2010-07-22 13:54:08','P',1,'Style: no brackets around single lines',NULL,1168,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/RepositoriesViewContentProvider.java','AAALw3///2s='),(339,1,'2010-07-22 17:37:18','P',1,'We shouldn\'t need to do this by a path string.  A D/F conflict is true for the entire time we are recursed below that path, and the walker knows when we pop out of each level.  Can\'t we do this faster with a boolean variable or a != null test?  I thought the prior iteration of this feature used an AbstractTreeIterator in a field to tell if we were inside of a D/F conflict.',NULL,1169,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/NameConflictTreeWalk.java','AAALw3///1U='),(339,5,'2010-07-22 22:53:28','P',1,'I knew I would get into trouble here. This string handling is sub-optimal. To fix it I need your help.\nWe had a nice implementation which you suggested in http://egit.eclipse.org/r/#patch,sidebyside,825,4,org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheCheckout.java\nSee my latest comment here.\nBasically I couldn\'t find out ALL places where we detect a D/F conflict and all places where we leave a conflicting path. combineDF() is not called for all D/F conflicts (sometimes fastMin() finds something and we don\'t enter combineDF(). When  I added marking a D/F conflict in two more places in fastMin() I saw that we got too many conflicts. I can only guess that popEntriesEqual() is not the only place where we have to clean the state.','AAALw3///1U=',1169,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/NameConflictTreeWalk.java','AAALw3///zE='),(358,1,'2010-07-23 16:56:52','P',1,'Why do we need to introduce equals as part of this change?  And anytime you introduce equals you should also implement hashCode so the object can be used in a HashMap or HashSet.',NULL,1170,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALw3///x4='),(369,1,'2010-07-23 16:56:52','P',1,'Use .equals here.',NULL,1170,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALw3///x8='),(61,73,'2010-07-26 18:52:59','P',1,'It was used in RenameDetectorTest line 570 in the assertAdd method. I needed it to check that the oldId on an ADD is zeroed.','AAALw3///yE=',1170,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALw3///xU='),(358,73,'2010-07-23 18:03:13','P',1,'It\'s being used in RenameDetectorTest on line 484. Basically, I needed a way to assert that the modify I started with was the same as the modify I ended up with, even though the modify was split apart and recombined. AssertSame couldn\'t do that, so I added a .equals and used assertEquals. That being said, since recombined modifys will now have a score associated with them, calling .equals will no longer work. I can remove the method if you wish, or I could keep it an implement hashCode.','AAALw3///x4=',1170,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALw3///xw='),(366,1,'2010-07-23 16:56:52','P',1,'Use .equals here.',NULL,1170,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALw3///yA='),(61,1,'2010-07-23 16:56:52','P',1,'Why is this now public?  I see nobody needs it as part of this change.',NULL,1170,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALw3///yE='),(638,1,'2010-07-23 16:56:52','P',1,'Yes.  Save the similarity score in the deleted node when you broke the pair.  When you recombine them as a modify, set the score to the score from the deleted side.\n\nDiffFormatter should be updated to add a dissimilarity line to the header which shows the inverse of the score when the modify score is non-zero.  So a score of 15 is displayed as 85%.',NULL,1170,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALw3///yI='),(637,1,'2010-07-23 16:56:52','P',1,'This isn\'t really worth a new method.  Its used exactly once.  We might as well just inline it in the call site.',NULL,1170,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALw3///yM='),(371,1,'2010-07-23 16:56:52','P',1,'Same comment as above with entries.  Shifting the arrays down is slow.',NULL,1170,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALw3///yQ='),(339,1,'2010-07-23 16:56:52','P',1,'This is horribly slow when entries is an ArrayList, because you have to shift every later cell down on each split.  Worse you are splitting everything in this particular case.\n\nMake a newEntries that you add items you aren\'t going to break into, and that way you don\'t have to modify and shift down the existing entries array.',NULL,1170,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALw3///yU='),(175,1,'2010-07-23 16:56:52','P',1,'I would call this a breakScore.',NULL,1170,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALw3///yY='),(180,1,'2010-07-27 18:13:43','P',1,'s/DiffEntrys/entries/',NULL,1170,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALxH///20='),(176,1,'2010-07-27 18:13:43','P',1,'\"Breaks apart a DiffEntry into two entries, one DELETE and one ADD.\"',NULL,1170,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALxH///24='),(60,1,'2010-07-27 18:13:43','P',1,'Style-nit: We don\'t use tab in Javadoc',NULL,1170,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALxH///28='),(272,1,'2010-07-27 18:13:43','P',1,'This should only appear if the score isn\'t 0 and isn\'t 100.',NULL,1170,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALxH///2w='),(418,1,'2010-07-27 18:13:43','P',1,'Please drop this reformatting hunk.',NULL,1170,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALxH///2g='),(502,1,'2010-07-27 18:13:43','P',1,'Please drop this reformatting hunk.',NULL,1170,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALxH///2k='),(367,1,'2010-07-27 18:13:43','P',1,'Just use remove here.  Its faster to remove-and-get in one step than it is to get and later do a remove of the same key.',NULL,1170,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALxH///2o='),(336,1,'2010-07-27 18:13:43','P',1,'Non-modify entries should be added back onto newEntries.',NULL,1170,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RenameDetector.java','AAALxH///2s='),(176,73,'2010-07-28 01:06:36','P',1,'I never quite know what to do in situations like that, where programmatic and grammatic correctness are at odds. The missing \'into\', however, was a simple oversight.','AAALxH///1o=',1170,5,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALxH///1c='),(176,1,'2010-07-28 00:43:15','P',1,'I still hate \"DiffEntrys\".  Its bad english.  But DiffEntries is strange because the class isn\'t called DiffEntrie.  Hence the generic term \"entries\" in the proposed text.  Also you are missing some sort of word like \"into\" here.  \"a thing two things\" makes no sense.  \"a thing into two things\" does.',NULL,1170,5,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALxH///1o='),(273,1,'2010-07-28 00:43:15','P',1,'Style-nit:  I prefer:\n\n  if (0 < score && score <= 100)\n\nBecause its easier to see that score is between these bounds.',NULL,1170,5,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALxH///1k='),(272,44,'2010-07-26 08:19:45','P',1,'Done','AAALw3///yg=',1172,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALw3///xo='),(272,1,'2010-07-23 16:25:29','P',1,'Should be final.',NULL,1172,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALw3///yg='),(420,44,'2010-07-26 08:19:45','P',1,'Done','AAALw3///yk=',1172,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/LockFile.java','AAALw3///xg='),(415,44,'2010-07-26 08:19:45','P',1,'Done','AAALw3///yo=',1172,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/LockFile.java','AAALw3///xk='),(420,1,'2010-07-23 16:25:29','P',1,'I would rather have the InterruptedException abort the loop entirely and return false.  So instead organize it as:\n\n  try {\n    for (int i = 0; i < 10; i++)\n  } catch (InterruptedException e) {\n    return false;\n  }\n\nThis way if a worker thread is stuck waiting for a second for a lock file to release and the user hits cancel in the UI, the thread can be interrupted and abort right away rather than keep busy-waiting through the entire period.',NULL,1172,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/LockFile.java','AAALw3///yk='),(415,1,'2010-07-23 16:25:29','P',1,'Style-nit: Braces aren\'t necessary here.',NULL,1172,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/LockFile.java','AAALw3///yo='),(89,44,'2010-07-27 09:40:54','P',1,'Is IOExecption the right one here?',NULL,1178,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/StoredConfig.java','AAALxH////k='),(82,44,'2010-07-27 09:40:54','P',1,'Is IOExecption the right one here? E.g. in case of DB storage.\nA storage exception containing the failure cause could be introduced.',NULL,1178,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/StoredConfig.java','AAALxH////o='),(82,1,'2010-07-27 18:49:57','P',1,'Not really, no, we shouldn\'t use IOException.  But that is the current root of our Exception type hierarchy elsewhere in JGit.  So its what we export here.  :-(','AAALxH////o=',1178,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/StoredConfig.java','AAALxH///2A='),(2,1,'2010-07-27 17:49:36','P',1,'Again, I doubt the Google copyright.',NULL,1179,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/io/EolCanonicalizingInputStreamTest.java','AAALxH///3E='),(2,51,'2010-07-29 14:25:37','P',1,'Done','AAALxH///3E=',1179,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/io/EolCanonicalizingInputStreamTest.java','AAALxH///yw='),(255,1,'2010-07-27 17:49:36','P',1,'This can return a short read.  We should use a loop to try and get the full buffer length or EOF before we enter into the isBinary logic.',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawText.java','AAALxH///30='),(249,1,'2010-07-27 17:49:36','P',1,'Please document that the stream may not be fully read, will be left at an unknown position after consuming an unknown number of bytes, and the caller needs to close it when done.\n\nBecause the stream cannot be easily reset back to the beginning the caller should know that.  Or we need to document with a public constant the amount the stream needs to mark() before calling us if they want to reset.',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawText.java','AAALxH///34='),(255,51,'2010-07-29 14:25:37','P',1,'Done','AAALxH///30=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawText.java','AAALxH///yo='),(249,51,'2010-07-29 14:25:37','P',1,'Done','AAALxH///34=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawText.java','AAALxH///ys='),(133,1,'2010-07-27 17:49:36','P',1,'We\'re going to need a whole lot more options than just autocrlf flag.  Eventually we would also need the complete clean filter configuration so we can run clean filters when computing an ObjectId from the work tree.\n\nWe probably should create a WorkTreeOptions class in this same package, and make this boolean a final package level member that the WorkingTreeIterator can reach into and inspect.  Then later we can add things like the clean filters to WorkTreeOptions and have them easily carry into the child iterators.',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALxH///3I='),(266,1,'2010-07-27 17:49:36','P',1,'Ouch.  We are scanning through EOL conversion files 3x per computation.  Most of them are going to be source code files, which are typically small texts under 64 KiB.  For these we probably should just allocate a byte[] buffer, slurp the entire file into the buffer, and work with the buffer instead of reading the file 3x into the JVM.  Its actually probably worth it to special case for these smaller text files.',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALxH///3M='),(262,1,'2010-07-27 17:49:36','P',1,'I\'d prefer not to negate this.  Above you used the true side to mean \"we are doing EOL conversion\" so to be consistent we should do the same thing here.',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALxH///3Q='),(257,1,'2010-07-27 17:49:36','P',1,'Style-nit: We cuddle else onto the line with the closing }',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALxH///3U='),(262,51,'2010-07-29 14:25:37','P',1,'Done','AAALxH///3Q=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALxH///yc='),(257,51,'2010-07-29 14:25:37','P',1,'Done','AAALxH///3U=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALxH///yg='),(133,51,'2010-07-29 14:25:37','P',1,'I\'ve called it WorkingTreeOptions for closer similarity with WorkingTreeIterator.','AAALxH///3I=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALxH///yk='),(266,51,'2010-07-29 14:25:37','P',1,'Done','AAALxH///3M=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALxX////E='),(58,1,'2010-07-27 17:49:36','P',1,'Style-nit: Instance members should be lowercase.',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///3c='),(88,1,'2010-07-27 17:49:36','P',1,'This comment is pointless.  This is true universally across the board and is why almost every part of JGit uses the read(byte[], int, int) variant whenever possible.  And often times even tries to avoid the InputStream and just work on the object as a complete byte[] (e.g. ObjectLoader\'s getCachedBytes method).',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///3g='),(83,1,'2010-07-27 17:49:36','P',1,'The easier way to implement this method is usually:\n\n  public int read() throws IOException {\n    byte[] b = new byte[1];\n    int r = read(b);\n    return r == 1 ? b[0] & 0xff : -1;\n  }\n\nMost callers these days do bulk IO thorugh read(byte[], int, int) and bypass the single byte read.  Thus this method is usually never used.  And JVMs these days are pretty good at cleaning up locally allocated short-term garbage like that single byte byte array so its not the end of the world that we allocate for the read.',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///3k='),(131,1,'2010-07-27 17:49:36','P',1,'There is no need to call super.close() on InputStream.  It is a no-op method.  Instead you just need to do is.close();',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///3o='),(73,1,'2010-07-27 17:49:36','P',1,'Style-nit: We avoid { on if/for/while/etc. when there is only one statement in the body.',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///3s='),(2,1,'2010-07-27 17:49:36','P',1,'I doubt Google wrote this in 2009.  :-)',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///3w='),(98,1,'2010-07-27 17:49:36','P',1,'Instead of reading only the amount that will fit in the caller\'s buffer, just fill your entire own local buffer.  At worst you need 1 byte of lookahead.  So at worst when you find a \'\\r\' and the local buffer is empty you only need to slide the \'\\r\' to the beginning of the local buffer, fill the rest, and continue your scan.\n\nI think that makes your main loop for read look something like this:\n\n  private final byte[] buf = new byte[8192];\n  private final InputStream in;\n  private int cnt;\n  private int ptr;\n\n  public int read(byte[] bs, int off, int len) throws IOException {\n    if (len == 0)\n      return 0;\n\n    final int startOff = off;\n    final int end = off + len;\n\n    while (off < end) {\n      if (ptr == cnt) {\n        cnt = in.read(buf, 0, buf.length);\n        if (cnt < 1)\n          break;\n        ptr = 0;\n      }\n\n      byte b = buf[ptr++];\n      if (b != \'\\r\') {\n        bs[off++] = b;\n        continue;\n      }\n\n      if (ptr == cnt) {\n        cnt = in.read(buf, 1, buf.length - 1);\n        if (cnt <= 0) {\n          bs[off++] = \'\\r\';\n          break;\n        }\n        buf[0] = \'\\r\';\n        ptr = 1;\n      }\n\n      if (buf[ptr] == \'\\n\') {\n        bs[off++] = \'\\n\';\n        ptr++;\n      } else\n        bs[off++] = \'\\r\';\n    }\n\n    return startOff == off ? -1 : off - startOff;\n  }',NULL,1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///3Y='),(2,51,'2010-07-29 14:25:37','P',1,'Done','AAALxH///3w=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///y0='),(131,51,'2010-07-29 14:25:37','P',1,'Done','AAALxH///3o=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///y4='),(98,51,'2010-07-29 14:25:37','P',1,'Phew! That took me a while to understand; anyway I\'ve implemented it almost as suggested here.','AAALxH///3Y=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///y8='),(88,51,'2010-07-29 14:25:37','P',1,'Done','AAALxH///3g=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///zA='),(83,51,'2010-07-29 14:25:37','P',1,'Done','AAALxH///3k=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///zE='),(73,51,'2010-07-29 14:25:37','P',1,'Done','AAALxH///3s=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///zI='),(58,51,'2010-07-29 14:25:37','P',1,'Done','AAALxH///3c=',1179,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALxH///zM='),(100,51,'2010-08-12 16:18:19','P',1,'Done','AAALyH///zo=',1179,3,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/opt/AbstractTreeIteratorHandler.java','AAALyH///xg='),(100,1,'2010-08-11 23:23:25','P',1,'Why not the default instance?',NULL,1179,3,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/opt/AbstractTreeIteratorHandler.java','AAALyH///zo='),(71,51,'2010-08-12 16:18:19','P',1,'Done','AAALyH///zQ=',1179,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/io/EolCanonicalizingInputStreamTest.java','AAALyH///xc='),(71,1,'2010-08-11 23:23:25','P',1,'Maybe a shorter way to write these inputs is:\n\n  byte[] input = asBytes(\"1\\n\\r2\\n\\r3\");\n\n  private static byte[] asBytes(String in) {\n    return in.getBytes(\"UTF-8\");\n  }',NULL,1179,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/io/EolCanonicalizingInputStreamTest.java','AAALyH///zQ='),(240,51,'2010-08-12 16:18:19','P',1,'Done','AAALyH///zs=',1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawText.java','AAALyH///xY='),(240,1,'2010-08-11 23:23:25','P',1,'You can write this shorter:\n\n  int size = Math.min(raw.length, FIRST_FEW_BYTES);',NULL,1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawText.java','AAALyH///zs='),(119,1,'2010-08-11 23:23:25','P',1,'Style-nit: I would prefer isAutoCrlf() or isAutoCRLF(), but isAutocrlf just looks funny to me.',NULL,1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/lib/CoreConfig.java','AAALyH///0I='),(119,51,'2010-08-12 16:18:19','P',1,'Done','AAALyH///0I=',1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/lib/CoreConfig.java','AAALyH///xU='),(604,51,'2010-08-12 16:18:19','P',1,'Done','AAALyH///zc=',1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALyH///xA='),(602,51,'2010-08-12 16:18:19','P',1,'Done','AAALyH///zg=',1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALyH///xE='),(258,51,'2010-08-12 16:18:19','P',1,'I\'ve extracted two local variables, but it\'s still wrapping.','AAALyH///zU=',1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALyH///xI='),(255,51,'2010-08-12 16:18:19','P',1,'Done','AAALyH///zY=',1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALyH///xM='),(130,51,'2010-08-12 16:18:19','P',1,'Done','AAALyH///zk=',1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALyH///xQ='),(604,1,'2010-08-11 23:23:25','P',1,'Style-nit: This is obtuse.  We don\'t do this anywhere even though it is shorter way to read the code.  I think we would prefer:\n\n  for (;;) {\n    int r = is.read(contentReadBuffer);\n    if (r <= 0)\n      break;\n    length += r;\n  }',NULL,1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALyH///zc='),(602,1,'2010-08-11 23:23:25','P',1,'Style-nit: I think if you drop the final keyword this will all fit on one line.  We would value that over having the final declaration in such a short method.',NULL,1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALyH///zg='),(130,1,'2010-08-11 23:23:25','P',1,'Style-nit: This can all be one line:\n\n  /** Options used to process the working tree. */',NULL,1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALyH///zk='),(258,1,'2010-08-11 23:23:25','P',1,'Style-nit: Can we use a shorter name here and avoid the line wrapping?',NULL,1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALyH///zU='),(255,1,'2010-08-11 23:23:25','P',1,'RawText.isBinary(bytes) is faster.',NULL,1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAALyH///zY='),(99,51,'2010-08-12 16:18:19','P',1,'Done','AAALyH///zw=',1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeOptions.java','AAALyH///w4='),(72,51,'2010-08-12 16:18:19','P',1,'Done','AAALyH///z0=',1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeOptions.java','AAALyH///w8='),(72,1,'2010-08-11 23:23:25','P',1,'Use Config here, we don\'t need the load/store methods.',NULL,1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeOptions.java','AAALyH///z0='),(99,1,'2010-08-11 23:23:25','P',1,'Same comment as in CoreConfig.',NULL,1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeOptions.java','AAALyH///zw='),(131,51,'2010-08-12 16:18:19','P',1,'Done','AAALyH///z8=',1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/util/IO.java','AAALyH///w0='),(131,1,'2010-08-11 23:23:25','P',1,'I bet our sizeHint is mostly accurate.  So lets use that to avoid copying.  But fall back into a copying behavior when its wrong:\n\n  byte[] out = new byte[sizeHint];\n  int pos = 0;\n  while (pos < out.length) {\n    int read = in.read(out, pos, out.length - pos);\n    if (read < 0) {\n      byte[] res = new byte[pos];\n      System.arraycopy(out, 0, res, 0, pos);\n      return res;\n    }\n\n    pos += read;\n  }\n\n  int last = in.read();\n  if (last < 0)\n    return out;\n\n  TemporaryBuffer.Heap tmp = new TemporaryBuffer.Heap(Integer.MAX_VALUE);\n  tmp.write(out);\n  tmp.write(last);\n  tmp.copy(in);\n  return tmp.toByteArray();',NULL,1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/util/IO.java','AAALyH///z8='),(80,51,'2010-08-12 16:18:19','P',1,'Done','AAALyH///z4=',1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALyH///ww='),(80,1,'2010-08-11 23:23:25','P',1,'You need to return single[0] & 0xff.  The result has to be unsigned.',NULL,1179,3,'org.eclipse.jgit/src/org/eclipse/jgit/util/io/EolCanonicalizingInputStream.java','AAALyH///z4='),(301,1,'2010-07-28 18:56:12','P',1,'I would flip the order and release the Inflater first.  That basically cannot fail, while super.close() could still throw some other sort of exception.  I\'ll cherry-pick and make the change.',NULL,1185,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/UnpackedObject.java','AAALxH///yY='),(610,1,'2010-07-28 19:13:57','P',1,'Done','AAALxH///yA=',1188,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackConfig.java','AAALxH///xk='),(64,1,'2010-07-28 19:13:57','P',1,'Done','AAALxH///yU=',1188,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackConfig.java','AAALxH///xo='),(610,79,'2010-07-28 19:03:19','P',1,'What\'s with the // at the end?',NULL,1188,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackConfig.java','AAALxH///yA='),(64,79,'2010-07-28 19:03:19','P',1,'We could change these to the following so that one can also see the value here:\n\nDefault value of deltas reuse option: {@value}',NULL,1188,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackConfig.java','AAALxH///yU='),(236,1,'2010-07-28 19:13:57','P',1,'Done','AAALxH///xw=',1188,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALxH///xg='),(236,79,'2010-07-28 19:03:19','P',1,'@value should work here.',NULL,1188,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALxH///xw='),(105,1,'2010-07-30 14:34:34','P',1,'headSet(Object,boolean) is a Java 6 API.  We need to define cutOff as super.getEntryLastModified() - 1 instead.',NULL,1203,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/treewalk/FileTreeIteratorWithTimeControl.java','AAALxn////E='),(105,6,'2010-07-30 15:56:36','P',1,'Shouldn\'t it be super.getEntryLastModified() + 1 ?\nThen headSet will include the enry with timestamp super.getEntryLastModified()','AAALxn////E=',1203,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/treewalk/FileTreeIteratorWithTimeControl.java','AAALxn///+0='),(162,1,'2010-07-30 14:33:07','P',1,'Shouldn\'t there be length included in the string?',NULL,1204,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RacyGitTests.java','AAALxn////M='),(162,6,'2010-07-30 15:57:05','P',1,'Done','AAALxn////M=',1204,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RacyGitTests.java','AAALxn///+s='),(1621,46,'2010-08-04 08:48:04','P',1,'E is used by SVN','AAALxn///6w=',1210,1,'org.eclipse.egit.ui/plugin.xml','AAALxn///5k='),(1621,6,'2010-08-03 14:01:42','P',1,'Why do we use E here and not M?',NULL,1210,1,'org.eclipse.egit.ui/plugin.xml','AAALxn///6w='),(240,46,'2010-08-03 06:51:05','P',1,'Formatting',NULL,1213,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/CommitMessageArea.java','AAALxn///7M='),(85,4,'2010-08-13 13:33:22','d',1,'typo: s/provider/provide/',NULL,1222,3,'org.eclipse.jgit/src/org/eclipse/jgit/lib/AsyncObjectLoaderQueue.java','AAALyH///sM='),(81,4,'2010-08-13 13:35:31','d',1,'typo: s/provider/provide/',NULL,1222,3,'org.eclipse.jgit/src/org/eclipse/jgit/lib/AsyncObjectSizeQueue.java','AAALyH///sI='),(816,4,'2010-08-13 13:19:09','P',1,'looks like omission of parameter writeMonitor implies that writing can\'t be cancelled anymore hence e.g. long running push can\'t be cancelled, or do I miss something ?',NULL,1224,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALyH///sY='),(816,1,'2010-08-21 01:00:13','P',1,'Yup, you are right, I lost this cancellation check.\n\nI will move it down into PackOutputStream\'s write method, and will have it check every 128 KiB of output.  That way we can actually cancel even in the middle of a massive object that is being reused as-is from the underlying store.','AAALyH///sY=',1224,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALyX///5E='),(109,5,'2010-08-19 13:55:07','P',0,'Done','AAALyH///kw=',1225,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/MergeResult.java','AAALyH///c8='),(224,5,'2010-08-19 13:55:07','P',1,'Done','AAALyH///ko=',1225,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/MergeResult.java','AAALyH///dA='),(221,5,'2010-08-19 13:55:07','P',1,'Done','AAALyH///ks=',1225,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/MergeResult.java','AAALyH///dE='),(143,5,'2010-08-19 13:55:07','P',0,'Done','AAALyH///kk=',1225,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/MergeResult.java','AAALyH///dI='),(143,4,'2010-08-18 11:57:39','P',0,'I think the other members of this class should also be added here, something like \"merge of heads x and y with base z using strategy abc results in 13 conflicts (list of conflicts) and has description blabla\"',NULL,1225,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/MergeResult.java','AAALyH///kk='),(224,4,'2010-08-18 11:57:39','P',1,'style nit: blanks around operator ==',NULL,1225,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/MergeResult.java','AAALyH///ko='),(221,4,'2010-08-18 11:57:39','P',1,'style nit: blanks around operator <',NULL,1225,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/MergeResult.java','AAALyH///ks='),(109,4,'2010-08-18 11:57:39','P',0,'you could simplify this by reusing the other constructor below:\n\n this(newHead, mergedCommits, base, mergeStatus, mergeStrategy, null);',NULL,1225,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/MergeResult.java','AAALyH///kw='),(252,1,'2010-08-19 18:32:23','P',1,'IMHO this is a mess for an application to parse.\n\nFor this high-level of our API we should have this be a lot easier to work with.  Its a ton more code, but application developers would appreciate something cleaner than a Map of int arrays of int arrays. Just saying it is painful.\n\nWe should do a FileConflictInfo object that is the value of this map, so we have Map<String /* path */, FileConflictInfo>.\n\nThe FileConflictInfo can then have a List<ConflictHunk> to describe all of the hunks that are conflicting.\n\nEach ConflictHunk can then provide more detail about the range that is conflicting for each parent that was put in.',NULL,1225,5,'org.eclipse.jgit/src/org/eclipse/jgit/api/MergeResult.java','AAALyH///aY='),(350,6,'2010-08-18 09:13:57','P',1,'You removed the test that merge fails when the index is dirty. Was this on purpose?',NULL,1226,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/MergeCommandTest.java','AAALyH///k8='),(248,6,'2010-08-18 09:13:57','P',1,'This TODO can be removed now.',NULL,1226,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/MergeCommandTest.java','AAALyH///lM='),(166,6,'2010-08-18 09:13:57','P',1,'failingPaths',NULL,1226,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/MergeCommand.java','AAALyH///lE='),(274,6,'2010-08-18 09:13:57','P',1,'At the moment failingPathes can only have one entry, right? The iteration is stopped after the first failure. Do we really need the map? Now the MergeFailureReason is in this Map belonging to one path, but I think that there is in fact only one MergeFailureReason for the whole merge?',NULL,1226,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALyH///lA='),(109,1,'2010-08-23 23:38:31','P',1,'This should be customizable by the caller.  And more interestingly, I\'d love to use this in Gerrit Code Review, and also to implement the recursive variant for multiple merge bases.\n\nThe latter two uses require that we *do not* have a working tree during the merge, and also that we don\'t lockDirCache() above but instead create a new in-core only DirCache.',NULL,1226,5,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALyn///7g='),(93,1,'2010-08-23 23:38:31','P',1,'This isn\'t necessary.  When you need the inserter call getObjectInserter().  Your super class manages allocation and release for you.',NULL,1226,5,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALyn///7k='),(1,1,'2010-08-23 23:38:31','P',1,'Missing copyright header.',NULL,1226,5,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALyn///7o='),(1,1,'2010-08-23 23:38:31','P',1,'Style-nit: Missing copyright header.',NULL,1226,5,'org.eclipse.jgit/src/org/eclipse/jgit/merge/StrategyResolve.java','AAALyn///70='),(17,1,'2010-08-23 23:38:31','P',1,'I think \"resolve\" fits better with the other strategy names we have.',NULL,1226,5,'org.eclipse.jgit/src/org/eclipse/jgit/merge/StrategyResolve.java','AAALyn///7s='),(6,1,'2010-08-23 23:38:31','P',1,'Style-nit: We don\'t use @author tags.  And even if we did, this one isn\'t very useful to the rest of the world.  :-)',NULL,1226,5,'org.eclipse.jgit/src/org/eclipse/jgit/merge/StrategyResolve.java','AAALyn///7w='),(548,2,'2010-08-30 20:44:08','P',1,'Regarding locked DirCache instances, please file a bug for this so we can track it and get to it. Things are good enough at the moment.','AAALyn///zk=',1226,6,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALyn///eA='),(548,5,'2010-08-25 10:16:40','P',1,'Here we accept only locked DirCaches (that\'s a requirement from DirCacheBuilder.commit()). Shawn commented that he would like to use not locked DirCache instances. Not sure how to do that.',NULL,1226,6,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALyn///zk='),(233,74,'2010-09-08 13:27:33','P',1,'Done, good catch','AAALy3///8o=',1229,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/clone/GitCloneWizard.java','AAALy3///5g='),(206,74,'2010-09-08 13:27:33','P',1,'Done, you\'re right, passing the real case makes more sense.','AAALy3///8s=',1229,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/clone/GitCloneWizard.java','AAALy3///5k='),(233,44,'2010-09-07 14:49:42','P',1,'override this method',NULL,1229,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/clone/GitCloneWizard.java','AAALy3///8o='),(206,44,'2010-09-07 14:49:42','P',1,'Is it better to pass e.getCause() to handleError? This brings the real cause on top.',NULL,1229,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/clone/GitCloneWizard.java','AAALy3///8s='),(156,6,'2010-08-04 11:41:25','P',1,'Done','AAALxn///5c=',1230,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTestCase.java','AAALxn///40='),(169,6,'2010-08-04 11:41:25','P',1,'Done','AAALxn///5Y=',1230,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTestCase.java','AAALxn///4w='),(156,6,'2010-08-04 08:56:11','P',1,'typo: constants',NULL,1230,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTestCase.java','AAALxn///5c='),(169,6,'2010-08-04 08:56:11','P',1,'iterate once over ...',NULL,1230,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTestCase.java','AAALxn///5Y='),(70,46,'2010-08-05 07:37:18','P',1,'Done','AAALxn///2I=',1235,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryAction.java','AAALx3////8='),(70,74,'2010-08-04 18:18:24','P',1,'Why do we need a snapshot of the world? Isn\'t it possible to just use getCurrentState() to get the selection?',NULL,1235,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryAction.java','AAALxn///2I='),(191,46,'2010-08-05 07:37:18','P',1,'Done','AAALxn///2E=',1235,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryActionHandler.java','AAALx3////4='),(191,74,'2010-08-04 18:18:24','P',1,'Why do we need a snapshot of the world? Isn\'t it possible to just use getCurrentState() to get the selection?',NULL,1235,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryActionHandler.java','AAALxn///2E='),(781,46,'2010-08-05 07:37:18','P',1,'Done','AAALxn///2A=',1235,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALx3////0='),(781,74,'2010-08-04 18:18:24','P',1,'Seems not to be used anywhere?',NULL,1235,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALxn///2A='),(150,6,'2010-08-05 12:14:15','P',1,'Done','AAALx3////U=',1239,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/ChangeIdUtil.java','AAALx3////M='),(150,46,'2010-08-05 11:50:13','P',1,'explain in javadoc what happens if id exists and replaceExisting is false (quiet failure?) and if id exists and replaceExisting is false (same?)',NULL,1239,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/ChangeIdUtil.java','AAALx3////U='),(70,4,'2010-10-30 23:55:33','P',1,'better use \"Commit Dialog\", we have another one named \"History View\"',NULL,1244,2,'org.eclipse.egit.ui/plugin.properties','AAALzX///k8='),(594,4,'2010-10-30 23:55:33','P',1,'Better use \"Commit Dialog\", this makes clear where the setting will be used',NULL,1244,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALzX///k0='),(450,4,'2010-10-30 23:55:33','P',1,'just use \"Preferences\"',NULL,1244,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALzX///k4='),(140,49,'2010-08-06 16:57:31','P',1,'You have right here, I\'ll reimplement this','AAALx3///7Y=',1247,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelRepository.java','AAALx3///68='),(140,6,'2010-08-06 15:34:50','P',1,'This does not do the right thing. There are outgoing and incoming commits which were created before both srcRev and dstRev.\n\nWhat you want is to get all commits between the common base and srcRev and all commits between common base and dstRev, right?\n\nYou have already determined the base commit in GitBaseResourceVariantTree, so why not have two RevWalks, one from base to srcRev  and one from base to dstRev?',NULL,1247,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelRepository.java','AAALx3///7Y='),(113,6,'2010-08-09 13:26:32','P',1,'This implementation is too complicated and uses too many low level JGit features.\n\nYou can use the API log command instead, once for the incoming and once for the outgoing changes:\n\nGit git = new Git(repo);\nit = git.log().addRange(ancestorCommit, srcRev).call().iterator() \n...',NULL,1247,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelRepository.java','AAALyH///80='),(113,49,'2010-08-09 15:31:50','P',1,'Done','AAALyH///80=',1247,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelRepository.java','AAALyH///8U='),(1624,49,'2010-08-10 17:08:15','P',1,'Done','AAALyH///8A=',1247,5,'org.eclipse.egit.ui/plugin.xml','AAALyH///5Q='),(1583,49,'2010-08-10 17:08:15','P',1,'Done','AAALyH///78=',1247,5,'org.eclipse.egit.ui/plugin.xml','AAALyH///5U='),(1583,6,'2010-08-10 12:37:53','P',1,'whitespace error',NULL,1247,5,'org.eclipse.egit.ui/plugin.xml','AAALyH///78='),(1624,6,'2010-08-10 12:37:53','P',1,'whitespace error',NULL,1247,5,'org.eclipse.egit.ui/plugin.xml','AAALyH///8A='),(190,49,'2010-08-10 17:08:15','P',1,'Done','AAALyH///74=',1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/SynchronizeWithActionHandler.java','AAALyH///5I='),(87,49,'2010-08-10 17:08:15','P',1,'Done','AAALyH///70=',1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/SynchronizeWithActionHandler.java','AAALyH///5M='),(87,6,'2010-08-10 12:37:53','P',1,'please remove outcommented code',NULL,1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/SynchronizeWithActionHandler.java','AAALyH///70='),(190,6,'2010-08-10 12:37:53','P',1,'whitespace error',NULL,1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/SynchronizeWithActionHandler.java','AAALyH///74='),(32,49,'2010-08-10 17:08:15','P',1,'Done','AAALyH///6o=',1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitChangeSetModelProvider.java','AAALyH///4o='),(27,49,'2010-08-10 17:08:15','P',1,'Done','AAALyH///6s=',1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitChangeSetModelProvider.java','AAALyH///4s='),(32,6,'2010-08-10 12:37:53','P',1,'empty JavaDoc',NULL,1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitChangeSetModelProvider.java','AAALyH///6o='),(27,6,'2010-08-10 12:37:53','P',1,'empty JavaDoc',NULL,1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitChangeSetModelProvider.java','AAALyH///6s='),(102,6,'2010-08-11 08:23:56','d',1,'I meant that we should always return null. This has the effect that the compare editor is not opened in three-way-compare mode. When you compare one version with the parent version, a three way compare is completely meaningless.\n\nBut I suggest to do that in a subsequent commit.','AAALyH///5A=',1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelBlob.java','AAALyH///3I='),(107,49,'2010-08-10 17:08:15','P',1,'Done','AAALyH///7s=',1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelBlob.java','AAALyH///48='),(102,49,'2010-08-10 17:08:15','P',1,'Done','AAALyH///7w=',1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelBlob.java','AAALyH///5A='),(107,6,'2010-08-10 12:37:53','P',1,'Shouldn\'t it the other way round? \n\nThe eclipse standard is that the newer version is on the left side.',NULL,1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelBlob.java','AAALyH///7s='),(102,6,'2010-08-10 12:37:53','P',1,'Please return null here because a three way compare is meaningless in this case.',NULL,1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelBlob.java','AAALyH///7w='),(35,49,'2010-08-10 17:08:15','P',1,'Done','AAALyH///6k=',1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelRepository.java','AAALyH///5E='),(35,6,'2010-08-10 12:37:53','P',1,'Whitespace error',NULL,1247,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelRepository.java','AAALyH///6k='),(252,63,'2010-08-20 00:16:40','P',1,'I think I\'d prefer if this section was after the table (instead of at the end) and right-adjusted but am open to what others feel about the layout.',NULL,1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/ConfigurationEditorComponent.java','AAALyH///X4='),(221,63,'2010-08-20 00:16:40','P',1,'Don\'t use \'remove\' in the name of the field if the widget\'s label is actually \'Delete\'.',NULL,1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/ConfigurationEditorComponent.java','AAALyH///YA='),(769,63,'2010-08-20 00:16:40','P',1,'I think this is a bad name because there\'s also an org.eclipse.jface.viewers.LabelProvider.',NULL,1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/ConfigurationEditorComponent.java','AAALyH///Yc='),(205,63,'2010-08-20 00:16:40','P',1,'Don\'t use \'apply\' in the name of the field if the widget\'s label is actually \'Change\'.',NULL,1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/ConfigurationEditorComponent.java','AAALyH///YE='),(820,63,'2010-08-20 00:16:40','P',1,'You created it, you disposed it. This is a resource leak as this font is never disposed.',NULL,1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/ConfigurationEditorComponent.java','AAALyH///YU='),(221,46,'2010-08-20 10:04:25','P',1,'Done','AAALyH///YA=',1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/ConfigurationEditorComponent.java','AAALyX///+0='),(205,46,'2010-08-20 10:04:25','P',1,'Done','AAALyH///YE=',1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/ConfigurationEditorComponent.java','AAALyX///+4='),(820,46,'2010-08-20 10:04:25','P',1,'Done','AAALyH///YU=',1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/ConfigurationEditorComponent.java','AAALyX///+o='),(769,46,'2010-08-20 10:04:25','P',1,'Done','AAALyH///Yc=',1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/ConfigurationEditorComponent.java','AAALyX///+s='),(252,46,'2010-08-20 10:04:25','P',1,'Done','AAALyH///X4=',1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/preferences/ConfigurationEditorComponent.java','AAALyX///+w='),(483,63,'2010-08-20 00:16:40','P',1,'If a TitleAreaDialog is going to be used (which I am not really convinced is necessary in this scenario), please also set a description.\n\nAlso, it feels kind of weird to me to be setting a title of a dialog in a method that\'s meant for the creation of buttons.',NULL,1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/RepositoryPropertySource.java','AAALyH///Xg='),(483,46,'2010-08-20 10:04:25','P',1,'Done','AAALyH///Xg=',1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/RepositoryPropertySource.java','AAALyX///+k='),(1237,63,'2010-08-20 00:16:40','P',1,'It\'s a \'Delete\' button not a \'Remove\' button.',NULL,1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/UIText.java','AAALyH///Xk='),(1237,46,'2010-08-20 10:04:25','P',1,'Done','AAALyH///Xk=',1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/UIText.java','AAALyX///+8='),(752,63,'2010-08-20 00:16:40','P',1,'Please change to \'&New Entry...\'.',NULL,1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyH///Xc='),(764,63,'2010-08-20 00:16:40','P',1,'Needs a colon at the end.',NULL,1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyH///Xo='),(749,63,'2010-08-20 00:16:40','P',1,'Needs a mnemonic and a colon at the end.',NULL,1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyH///Xs='),(759,63,'2010-08-20 00:16:40','P',1,'\'Delete\' button not a \'Remove\' button.',NULL,1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyH///Xw='),(750,63,'2010-08-20 00:16:40','P',1,'Lowercase \'String\' to \'string\'.',NULL,1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyH///XY='),(750,46,'2010-08-20 10:04:25','P',1,'Done','AAALyH///XY=',1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyX///+c='),(749,46,'2010-08-20 10:04:25','P',1,'Done','AAALyH///Xs=',1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyX///+g='),(764,46,'2010-08-20 10:04:25','P',1,'Done','AAALyH///Xo=',1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyX///+Q='),(759,46,'2010-08-20 10:04:25','P',1,'Done','AAALyH///Xw=',1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyX///+U='),(752,46,'2010-08-20 10:04:25','P',1,'Done','AAALyH///Xc=',1250,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyX///+Y='),(60,49,'2010-08-10 19:29:19','P',1,'Yes, indeed.\nDone','AAALyH///6M=',1268,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/dto/GitSynchronizeData.java','AAALyH///4M='),(60,6,'2010-08-10 13:29:52','P',1,'IMHO you can just use \n\nthis.srcRev = ow.parseCommit(srcRef.getObjectId())\n\nand you can use a RevWalk instead of an ObjectWalk.',NULL,1268,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/dto/GitSynchronizeData.java','AAALyH///6M='),(103,49,'2010-08-11 21:20:10','P',1,'Yes I know that it overwrites ... but for some reasons it return false','AAALyH///20=',1269,4,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparator.java','AAALyH///0k='),(103,6,'2010-08-11 12:30:42','P',1,'But AnyObjectId overwrites equals and this should work. \n\nAnyhow, this change does not solve the error I face: I still see for some projects conflicting folders, with their path relative to the git repository and not relative to the workspace.',NULL,1269,4,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantComparator.java','AAALyH///20='),(281,44,'2010-08-10 10:47:29','P',1,'Done','AAALyH///7U=',1272,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAALyH///68='),(255,44,'2010-08-10 10:47:29','P',1,'Done','AAALyH///7Y=',1272,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAALyH///7A='),(232,46,'2010-08-10 10:19:19','P',1,'if (trace) missing?',NULL,1272,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAALyH///7c='),(232,44,'2010-08-10 10:47:29','P',1,'Done','AAALyH///7c=',1272,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAALyH///7E='),(81,46,'2010-08-10 10:19:19','P',1,'This should be final to indicate that it is set in the constructor and not dynamic.',NULL,1272,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAALyH///7g='),(81,44,'2010-08-10 10:47:29','P',1,'Done','AAALyH///7g=',1272,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAALyH///7I='),(281,46,'2010-08-10 10:19:19','P',1,'if (trace) missing?',NULL,1272,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAALyH///7U='),(255,46,'2010-08-10 10:19:19','P',1,'if (trace) missing?',NULL,1272,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAALyH///7Y='),(11,63,'2010-08-28 12:44:40','P',1,'\"unnecessary [what?]\"',NULL,1279,5,'/COMMIT_MSG','AAALyn///kc='),(10,63,'2010-08-28 12:44:40','P',1,'\"were not happy\"\n\n\"This meant Eclipse\"',NULL,1279,5,'/COMMIT_MSG','AAALyn///kg='),(14,63,'2010-08-28 12:44:40','P',1,'scane -> scan',NULL,1279,5,'/COMMIT_MSG','AAALyn///kY='),(313,63,'2010-08-28 12:44:40','P',1,'It seems to me that you may end up adding a repository multiple times if its index changes more than once before the list is processed. Though I suppose this might not technically matter since the projects that will be queued up to be refreshed is stored in a set.',NULL,1279,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/Activator.java','AAALyn///kM='),(202,63,'2010-08-28 12:44:40','P',1,'This listener should be removed when the bundle has been stopped.',NULL,1279,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/Activator.java','AAALyn///kQ='),(220,44,'2010-09-07 15:57:52','P',1,'why is listener needed? RepositoryChangeScanner Job reschedules itself when the workbench window is not active.\nResourceRefreshJob is scheduled by indexChanged Event.',NULL,1279,6,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/Activator.java','AAALy3///8M='),(315,44,'2010-09-07 15:57:52','P',1,'repositoriesChanged will always contain one repo. Pass this repo to triggerRefresh instead of using repositoriesChanged.',NULL,1279,6,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/Activator.java','AAALy3///8Q='),(320,8,'2010-09-13 22:52:58','P',1,'right..... Done','AAALy3///yA=',1279,6,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/Activator.java','AAALy3///tE='),(315,8,'2010-09-13 22:52:58','P',1,'Yes. Any thread may trigger repository events. At the momemnt I\'m not sure if that can happen, but imagine a pull beging performed in the background on one repo while committing in another','AAALy3///x8=',1279,6,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/Activator.java','AAALy3///tg='),(220,8,'2010-09-13 22:52:58','P',1,'Riight.','AAALy3///yM=',1279,6,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/Activator.java','AAALy3///tk='),(315,44,'2010-09-10 16:34:40','P',1,'Is it possible that w threads in parallel enter onIndexChanged? In this case my first comment is wrong and synchronization on repositoriesChanged is needed.','AAALy3///8Q=',1279,6,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/Activator.java','AAALy3///x8='),(320,44,'2010-09-10 16:34:40','P',1,'if triggerRefresh was not called because the Workbench window is inactive \nthe change in repositoriesChanged is lost, right?\nPerhaps it would be easier to do the refresh in any case.\nThe refresh does not conflict with command line git.\nWhen RCS gets inactive due to inactive Workbench window there can only be refreshes triggered by the last RCS run.',NULL,1279,6,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/Activator.java','AAALy3///yA='),(220,44,'2010-09-10 16:34:40','P',1,'Now I understood this. It\'s done to schedule RCS without delay after window activation.','AAALy3///8M=',1279,6,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/Activator.java','AAALy3///yM='),(190,46,'2010-08-11 06:27:14','P',1,'I\'d like to see a comment to the effect that the window may be null during shutdown',NULL,1280,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryActionHandler.java','AAALyH///3Y='),(39,46,'2010-08-11 06:27:14','P',1,'I\'d like to see a comment to the effect that the window may be null during shutdown',NULL,1280,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/ShowHistoryActionHandler.java','AAALyH///3U='),(42,46,'2010-08-11 06:27:14','P',1,'I\'d like to see a comment to the effect that the window may be null during shutdown',NULL,1280,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/ShowRepositoriesViewActionHandler.java','AAALyH///3Q='),(81,1,'2010-08-11 22:54:28','P',1,'Please use our ListenerList instead.',NULL,1281,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Config.java','AAALyH///0c='),(492,1,'2010-08-11 22:54:28','P',1,'This is better named fireConfigChangedEvent().',NULL,1281,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Config.java','AAALyH///0Q='),(1357,1,'2010-08-11 22:54:28','P',1,'This should be our existing ConfigChangedListener.',NULL,1281,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Config.java','AAALyH///0U='),(89,1,'2010-08-11 22:54:28','P',1,'If subclasses are supposed to override this, maybe a method whose default implementation returns true is better.  Then the subclass can override with false if it doesn\'t want to do this, and we\'re not declaring a field.',NULL,1281,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Config.java','AAALyH///0Y='),(25,4,'2010-08-17 11:53:22','P',1,'this assertion seems to be unnecessary (you set it to null one line above)',NULL,1281,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/events/ConfigChangeEventTest.java','AAALyH///nM='),(7,46,'2010-08-19 07:13:44','P',1,'Done','AAALyH///jk=',1281,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/events/ConfigChangeEventTest.java','AAALyH///ec='),(1,46,'2010-08-19 07:13:44','P',1,'Done','AAALyH///jw=',1281,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/events/ConfigChangeEventTest.java','AAALyH///eg='),(18,46,'2010-08-19 07:13:44','P',1,'Done','AAALyH///jg=',1281,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/events/ConfigChangeEventTest.java','AAALyH///eY='),(18,1,'2010-08-18 23:15:05','P',1,'Style-nit: I would put a blank line between the various \"sections\" of this test, just to make it easier to visually see \"oh, this is the setup, the run, and the verify.  and here\'s the next setup, run, verify.\"',NULL,1281,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/events/ConfigChangeEventTest.java','AAALyH///jg='),(7,1,'2010-08-18 23:15:05','P',1,'s/testChangeEventsOnlyOnSave/testFileRepository_ChangeEventsOnlyOnSave/',NULL,1281,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/events/ConfigChangeEventTest.java','AAALyH///jk='),(1,1,'2010-08-18 23:15:05','P',1,'Missing EDL copyright header.',NULL,1281,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/events/ConfigChangeEventTest.java','AAALyH///jw='),(181,1,'2010-08-19 17:46:56','P',1,'No.  Right now a listener stays registered even if you don\'t hang onto the ListenerHandle.  You only need the handle if you want to later remove the listener.\n\nMy point here is, we don\'t ever need to worry about removing the listener.  The FileRepository always wants to know when the Config changes.  So it should just keep the listener registered so long as it itself exists in the JVM.  There\'s no danger of a cycle or anything, the GC will correctly release everything.','AAALyH///eQ=',1281,4,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/FileRepository.java','AAALyH///bA='),(181,46,'2010-08-19 07:13:44','P',1,'Well, if I do configChangeListenerHandle = null, I\'ll have to remove the final from the field, and then I get a compiler error saying that the field is never read. If I do nothing here, I still get the compiler warning (even if the final is there)... But I will have to keep a reference of the handle, right?','AAALyH///jo=',1281,4,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/FileRepository.java','AAALyH///eQ='),(154,46,'2010-08-19 07:13:44','P',1,'Done','AAALyH///js=',1281,4,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/FileRepository.java','AAALyH///eU='),(181,1,'2010-08-18 23:15:05','P',1,'IMHO this is pointless to remove.  There\'s no resource leakage resulting from not removing the forwarding handle from the config listener list.  Just drop the field and don\'t worry about deregistering.',NULL,1281,4,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/FileRepository.java','AAALyH///jo='),(154,1,'2010-08-18 23:15:05','P',1,'Style-nit: Unnecessary blank line.',NULL,1281,4,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/FileRepository.java','AAALyH///js='),(287,44,'2010-08-12 16:27:03','P',1,'Done','AAALyH///xo=',1290,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyH///v8='),(281,44,'2010-08-12 16:27:03','P',1,'Done','AAALyH///xs=',1290,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyH///wA='),(276,44,'2010-08-12 16:27:03','P',1,'Done','AAALyH///xw=',1290,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyH///wE='),(274,44,'2010-08-12 16:27:03','P',1,'Done','AAALyH///x0=',1290,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyH///wI='),(264,44,'2010-08-12 16:27:03','P',1,'Done','AAALyH///x4=',1290,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyH///wM='),(264,44,'2010-08-12 16:27:03','P',1,'Done','AAALyH///yA=',1290,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyH///wQ='),(274,1,'2010-08-12 15:10:31','P',1,'Style-nit:  I would prefer this to be:\n\n  return !workingTreeIterator.isEntryIgnored();',NULL,1290,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyH///x0='),(264,1,'2010-08-12 15:10:31','P',1,'I agree with Chris, please move this to the treewalk.filter package as its own top-level class.  You\'ll need to add an int argument to the constructor so the caller can pass the index of the WORKDIR tree into the filter.\n\nAlso, a better name might be NotIgnoredFilter since it selects entries that are not ignored.','AAALyH///yA=',1290,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyH///x4='),(287,1,'2010-08-12 15:10:31','P',1,'This filter is immutable once created, so clone can simply return this.',NULL,1290,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyH///xo='),(281,1,'2010-08-12 15:10:31','P',1,'This should be false, not true.  We don\'t have to dive into a subtree in order to properly evaluate the ignored status of any given entry.',NULL,1290,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyH///xs='),(276,1,'2010-08-12 15:10:31','P',1,'Style-nit: We don\'t usually put the else here.  Just end the block, fall through and return:\n\n  if (workingTreeIterator != null) {\n  ...\n  }\n  return true;',NULL,1290,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyH///xw='),(264,2,'2010-08-12 14:43:29','P',1,'Can you move this to a public class in the \'org.eclipse.jgit.treewalk.filter\' package? This may be useful for other clients.',NULL,1290,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyH///yA='),(115,1,'2010-08-12 17:26:16','P',1,'objId within the tag is always null, which will cause the tag code below to always NPE because we can\'t open the object specified by the null ObjectId...\n\nYou need to use HEAD if the caller hasn\'t set the id, and you need a setter to allow the caller to set an id if they choose to tag something other than HEAD.',NULL,1293,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///t8='),(112,1,'2010-08-12 17:26:16','P',1,'You also need to setAuthor().  The ObjectInserter formatting code will NPE if author is null in the Tag.',NULL,1293,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///tw='),(123,1,'2010-08-12 17:26:16','P',1,'Don\'t bother setting the id.  Just use tagId below instead of newTag.getTagId().',NULL,1293,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///uA='),(136,1,'2010-08-12 17:26:16','P',1,'Style-nit: We don\'t put braces around a case block unless the case block is allocating local variables.',NULL,1293,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///uE='),(95,1,'2010-08-12 17:26:16','P',1,'We return a RevTag not a Tag.',NULL,1293,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///ug='),(139,1,'2010-08-12 17:26:16','P',1,'What are we falling through from?',NULL,1293,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///uI='),(96,1,'2010-08-12 17:26:16','P',1,'Document ConcurrentRefUpdateException?',NULL,1293,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///uk='),(179,1,'2010-08-12 17:26:16','P',1,'Please don\'t leave a TODO if we can avoid it.',NULL,1293,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///uM='),(103,1,'2010-08-12 17:26:16','P',1,'Style-nit: Subsequent lines get indented another level IIRC.\n\nBut do we really throw UnmergedPathException?  Or WrongRepositoryStateException?',NULL,1293,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///uo='),(175,1,'2010-08-12 17:26:16','P',1,'An empty message is OK.',NULL,1293,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///uQ='),(225,1,'2010-08-12 17:26:16','P',1,'Actually I would do the reverse and have setSigned(boolean).',NULL,1293,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///uY='),(52,1,'2010-08-18 23:26:49','P',1,'Please also add a test for when you use setId() to tag something that is not HEAD.',NULL,1293,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/TagCommandTest.java','AAALyH///jE='),(202,1,'2010-08-18 23:26:49','P',1,'We really should validate that the expression Constants.R_TAGS + name will pass Repository.isValidRefName().  If it doesn\'t we should fail-fast either here during setName(), or during processOptions() above.\n\nI\'m pretty sure that updateRef() will blindly do whatever you tell it, and we are relying on callers to check that the name is reasonable.',NULL,1293,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///jI='),(192,1,'2010-08-18 23:26:49','P',1,'We should explain in a message that signed isn\'t supported.',NULL,1293,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///jM='),(156,1,'2010-08-18 23:26:49','P',1,'These args aren\'t right for the message.  Shouldn\'t we be recording refName here instead of Constants.HEAD?  And is newTag.toString() the right thing to embed as {1} in the message?  (I\'m not sure, I don\'t know exactly what this message text says.)\n\nAlso I think this is supposed to be a ConcurrentRefUpdateException.',NULL,1293,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///jQ='),(122,1,'2010-08-18 23:26:49','P',1,'This should only fail if id == null.',NULL,1293,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyH///jY='),(96,15,'2010-08-21 20:27:53','P',1,'Misleading comment',NULL,1293,5,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/TagCommandTest.java','AAALyX///0s='),(84,15,'2010-08-21 20:27:53','P',1,'Misleading comment',NULL,1293,5,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/TagCommandTest.java','AAALyX///0w='),(330,4,'2010-08-21 21:46:18','P',1,'Signing isn\'t supported on tag operations yet.\n\nI think we want to implement this ...',NULL,1293,5,'org.eclipse.jgit/resources/org/eclipse/jgit/JGitText.properties','AAALyX///0g='),(146,4,'2010-08-21 21:46:18','P',1,'copy&paste error: s/execution of commit command/execution of tag command/',NULL,1293,5,'org.eclipse.jgit/resources/org/eclipse/jgit/JGitText.properties','AAALyX///0k='),(343,4,'2010-08-21 21:46:18','P',1,'avoid slang which might confuse users:\n\nTag on repository without HEAD is currently not supported',NULL,1293,5,'org.eclipse.jgit/resources/org/eclipse/jgit/JGitText.properties','AAALyX///0Y='),(274,4,'2010-08-21 21:46:18','P',1,'I think setting forceUpdate on not yet existing tag is also valid\n\ns/replaces/may replace/',NULL,1293,5,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyX///0M='),(243,4,'2010-08-21 21:46:18','P',1,'if signed == true we could fail fast throwing an UnsupportedOperationException here until we implement signed tags',NULL,1293,5,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyX///0Q='),(221,4,'2010-08-21 21:46:18','P',1,'that\'s wrong, should be:\n\n return message;',NULL,1293,5,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyX///0U='),(91,1,'2010-08-25 02:38:12','P',1,'Insanely long lines.  Our Eclipse code style formatter knows the line length.  Please apply it to this file.  I know you aren\'t coding for JGit in NetBeans... :-)',NULL,1293,7,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/TagCommandTest.java','AAALyn///0w='),(218,1,'2010-08-25 02:38:12','P',1,'No getters for author, objectId, forceUpdate, or signed.  Should we do getters for everything?  Or nothing at all?  CommitCommand tends to do getters for each field, though its missing for setAll().',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///00='),(146,1,'2010-08-25 02:38:12','P',1,'Pass in revWalk here to update() so we can reuse the revision pool you already have.',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///04='),(136,1,'2010-08-25 02:38:12','P',1,'This isn\'t necessary.  format() and inserter.insert(newTag) do this indirectly.',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///08='),(135,1,'2010-08-25 02:38:12','P',1,'inserter.insert(newTag) is a newer short form of this.',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///1A='),(193,1,'2010-08-25 02:38:12','P',1,'if (signed) is enough.  We try not to compare boolean variables to boolean constants.',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///1c='),(129,1,'2010-08-25 02:38:12','P',1,'This doesn\'t compile.  You need to pass a RevObject, or know the object type.  Since the caller only gave you an ObjectId, you may need to open that and get the type off the ObjectLoader.',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///1E='),(79,1,'2010-08-25 02:38:12','P',1,'s/author/tagger/',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///1g='),(127,1,'2010-08-25 02:38:12','P',1,'IIRC resolve can return null here, and setObjectId won\'t check.  We\'ll later crash hard.  Check the result of resolve() and if its null use the NoHeadException.  At which point you can probably just remove getRef() above and just do the resolve HEAD^{commit}, if that fails for any reason we throw NoHeadException.',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///1I='),(77,1,'2010-08-25 02:38:12','P',1,'Use \"\" instead.  But actually this isn\'t necessary.  TagBuilder will now correctly accept a null message.',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///1k='),(107,1,'2010-08-25 02:38:12','P',1,'Line is too long, please line-wrap it.',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///1M='),(254,1,'2010-08-25 02:38:12','P',1,'s/Author/Tagger/',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///1Q='),(245,1,'2010-08-25 02:38:12','P',1,'Extra blank line.',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///1U='),(235,1,'2010-08-25 02:38:12','P',1,'s/parameter -a/parameter -s/',NULL,1293,7,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///1Y='),(139,1,'2010-08-26 18:46:56','P',1,'I hate to a nit, but can we use either tagId or newTag.getTagId() consistently here?  You use one form right here, and the other form 3 lines below when you setNewObjectId().  It would be nice if we just used tagId.',NULL,1293,8,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///qc='),(191,1,'2010-08-26 18:46:56','P',1,'Is this really an internal exception?  If the caller gave us a tag name that we won\'t accept as a reference name that is rather different than us encountering a form of repository corruption they cannot recover from easily.  The caller just needs to correct their input.\n\nI\'m thinking about the EGit UI case here.  If the UI just passes through the tag name entered by the user, runs call(), we need to throw something that tells the UI it should backup and let the user correct their input.  But if we got a valid tag name and crash because something goes wrong deep inside of the ObjectInserter, that\'s a totally different kind of error for the EGit UI to present to the human.',NULL,1293,8,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///qU='),(243,1,'2010-08-26 18:46:56','P',1,'Nope, still wrong on the docs:\n\n /**\n  * If set to true the Tag command creates a signed tag.\n  * This corresponds to the -s parameter on the command line.',NULL,1293,8,'org.eclipse.jgit/src/org/eclipse/jgit/api/TagCommand.java','AAALyn///qY='),(38,2,'2010-08-12 16:51:32','P',1,'It looks like everything here should just be static methods.\n\nHow about a static final class with a synchronize method with the arguments currently in the constructor?',NULL,1294,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitModelSynchronize.java','AAALyH///vY='),(81,49,'2010-08-12 17:36:22','P',1,'Done','AAALyH///u8=',1294,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitModelSynchronize.java','AAALyH///t0='),(39,49,'2010-08-12 17:36:22','P',1,'Done','AAALyH///u4=',1294,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitModelSynchronize.java','AAALyH///t4='),(103,49,'2010-08-12 17:36:22','P',1,'Done','AAALyH///vA=',1294,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitModelSynchronize.java','AAALyH///tk='),(96,49,'2010-08-12 17:36:22','P',1,'Done','AAALyH///u0=',1294,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitModelSynchronize.java','AAALyH///to='),(96,74,'2010-08-12 17:11:56','P',1,'I think this could be generified with <ResourceMapping>',NULL,1294,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitModelSynchronize.java','AAALyH///u0='),(39,74,'2010-08-12 17:11:56','P',1,'I suggest to move this to the end of the class as this is the less interesting part of the class.',NULL,1294,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitModelSynchronize.java','AAALyH///u4='),(81,74,'2010-08-12 17:11:56','P',1,'Just use Platform.getWorkbench()....getActivePage(), This would help to get rid of all these warnings. Could even be part of UIUtils.',NULL,1294,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitModelSynchronize.java','AAALyH///u8='),(103,74,'2010-08-12 17:11:56','P',1,'I think we could lay this out as constant. And why don\'t you push it into the isMappedToProvider? Seems we only want to check this for our provider.',NULL,1294,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitModelSynchronize.java','AAALyH///vA='),(82,4,'2010-08-16 22:29:17','P',1,'typo: s/projectm/project/',NULL,1303,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/FileDiff.java','AAALyH///oo='),(246,1,'2010-08-18 23:41:12','P',1,'To be safe you also need an inserter.flush() and inserter.release().  I think I\'m going to cherry-pick this onto master and fix it myself.',NULL,1315,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RepositoryTestCase.java','AAALyH///ig='),(227,4,'2010-08-16 23:12:32','P',1,'why defer logging the exception ?',NULL,1318,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/RepositoriesViewLabelProvider.java','AAALyH///oE='),(163,4,'2010-08-16 23:12:32','P',1,'style nit: no braces around single line block',NULL,1318,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/RepositoriesViewLabelProvider.java','AAALyH///oI='),(126,81,'2010-08-19 14:40:14','P',1,'Alternatively, I can just use the SEEN flag like everything else.  I was pretty sure the depth flagging covers it correctly, but I had to think about it for a long time as well, and I\'m still not positive I\'m right, so all in all that\'s probably a sign that it should just be done a simpler way.','AAALyH///fs=',1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyH///ck='),(144,1,'2010-08-19 02:16:03','P',1,'Style-nit: We don\'t bother with else continue at the end of a loop.  Just let it occur normally.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyH///f0='),(134,1,'2010-08-19 02:16:03','P',1,'Style-nit: Parens aren\'t necessary here.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyH///f8='),(126,1,'2010-08-19 02:16:03','P',1,'Normally we use the SEEN flag to prevent commits from entering pending twice.  You don\'t do that here.  As far as I can tell, using the depth provides the same effect, but it took me a long time to think about.\n\nSince this deviates from our more typical pattern of relying on a flag to track \"have we processed this already\", please provide a short proof of why we don\'t need a flag here to prevent duplicates and stuff it in a comment so future readers don\'t have to expend as many brain cells I just did over whether or not this works.  (Its easier to verify a proof than it is to derive one on the fly...)',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyH///fs='),(110,1,'2010-08-19 02:16:03','P',1,'This actually parses right away.  If the object is already parsed, you are parsing it all over again.  Yuck.  You should guard this:\n\n  if ((c.flags & PARSED) == 0)\n    c.parseHeaders(walk);',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyH///gA='),(72,1,'2010-08-19 02:16:03','P',1,'This constructor shouldn\'t be public.\n\nAlso, style-nit: Line too long/wrapped incorrectly.\n\nAlso, this can only be used with a DepthWalk, which has getters for depth and compareMode.  Instead of taking a RevWalk here take a DepthWalk and get the depth and compareMode from it.  You can then downcast the DepthWalk to a RevWalk since a DepthWalk should always be a RevWalk given how your only caller inside of PendingGenerator invokes you.  :-)',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyH///gc='),(106,1,'2010-08-19 02:16:03','P',1,'I would just downcast right away:\n\n  final DepthWalk.Commit c = (DepthWalk.Commit)pending.next();',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyH///gE='),(99,1,'2010-08-19 02:16:03','P',1,'I would probably implement this the other way around.  Since pending is \"this\" (well, the backing store) we should do:\n\n  pending.shareFreeList(q);\n\nto mirror the intent of the caller of invoking this.shareFreeList(q).\n\nIts a subtle issue about how we are discarding a potentially large free list from the bottom of the stack by pushing down an empty free list from the top of the stack.  Weird, I know.  But at least mirror the caller\'s intent.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyH///gI='),(58,1,'2010-08-19 02:16:03','P',1,'Don\'t bother with this as a field.  pending.outputType() is fast enough for your own outputType method.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyH///gM='),(82,1,'2010-08-19 02:16:03','P',1,'You can simplify a lot of your setup:\n\n  pending = new FIFORevQueue(s);\n  pending.outputType = 0;\n\nWould replace the shareFreeList() as well as this loop to suck out the current generator.  But we should fix our outputType because it might have been tagged as SORT_COMMIT_TIME_DESC.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyH///gQ='),(55,1,'2010-08-19 02:16:03','P',1,'This class shouldn\'t be public.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyH///gY='),(100,1,'2010-08-19 02:16:03','P',1,'If you do keep the getter, I\'m not sure we should endorse the setter as part of our public API yet.  I\'d rather keep it package level.  Why would a client need to edit the depth of a commit?',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthWalk.java','AAALyH///fc='),(86,1,'2010-08-19 02:16:03','P',1,'For insane reasons we often allow package level visibility to these sorts of fields and edit them directly, rather than using getters/setters.  It removes the need for the JIT to try to inline the getter/setter logic, which means we perform better even when the JIT can\'t inline the getter cross-classes.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthWalk.java','AAALyH///fg='),(209,1,'2010-08-19 02:16:03','P',1,'Like above I think this comment isn\'t useful enough to stay.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthWalk.java','AAALyH///gg='),(148,1,'2010-08-19 02:16:03','P',1,'I think this comment is overkill.  Its sort of implied that we would use our own Commit type.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthWalk.java','AAALyH///gk='),(131,1,'2010-08-19 02:16:03','P',1,'Style-nit: We always put /** on a line by itself, starting the documentation on the next line.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthWalk.java','AAALyH///go='),(138,1,'2010-08-19 02:16:03','P',1,'Style-nit: We indent wrapped lines another level.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthWalk.java','AAALyH///gs='),(974,1,'2010-08-19 02:16:03','P',1,'Really long line, this should be line wrapped, which probably implies you should use {} here due to the statement being longer than one line.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALyH///fo='),(387,81,'2010-08-19 14:40:14','P',1,'Gaah, guess who\'s been using C++ too much lately... :(','AAALyH///g0=',1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyH///cg='),(666,81,'2010-08-19 14:40:14','P',1,'Yeah, but it\'s kind of tricky.  Imagine that you already have a shallow clone with a depth of 1, and you want to do a new fetch with depth=2.  You want to avoid the commits that you already have, but then unshallow the old boundary commits and start sending stuff below those again.  I wasn\'t quite clear on the best way to handle that, so I basically just copped out and sent the whole tree.  \n\nThis can probably be solved somehow by adding all of the parents of the client\'s shallow commits back into the generator as interesting so that they\'ll be picked up again, but right now the DepthGenerator doesn\'t do anything with uninteresting commits.  I\'m not sure I completely understand the logic that would need to be used for those, especially in conjunction with the depth tagging stuff--can you provide any insight?','AAALyH///hA=',1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyH///cQ='),(387,1,'2010-08-19 02:16:03','P',1,'This will never be true, because you are doing reference equality on two temporarily allocated strings.\n\nInstead you need to say c.equals(o).  But that only works on current master.  So rebase this patch to pick up that fix.  But that point you can simplify the loop:\n\n  if (!remoteShallowCommits.contains(o))\n    packOut.writeString(\"shallow \" + o.name());',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyH///g0='),(375,1,'2010-08-19 02:16:03','P',1,'Style-nit: Avoid the local variable here so we can have a shorter loop:\n\n  for (RevCommit want : wantCommits)\n    depthWalk.markStart(depthWalk.parseCommit(want));',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyH///g4='),(371,1,'2010-08-19 02:16:03','P',1,'Style-nit: Line is too long, we prefer lines to be <80 characters given a tab stop setting of 4.\n\nAlso for performance reasons please try to use the same ObjectReader that the walk member is using.  There may be caching involved that would improve the shallow computation here.  Yes, sorry, that does mean you need that other constructor in your DepthWalk.RevWalk class.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyH///g8='),(182,1,'2010-08-19 02:16:03','P',1,'Style-nit: We don\'t initialize to 0/null/false because the JVM does that implicitly for you.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyH///gw='),(666,1,'2010-08-19 02:16:03','P',1,'IIRC the shallow protocol still does common ancestor negotiation because its useful to limit what we send.  So we should still pass commonBase through to the PackWriter.\n\nIn particular the client is very likely to have our current refs, and the objects reachable from those.  If they haven\'t changed at the boundary, we don\'t want to resend those blobs.  The only way to avoid that is to pass through commonBase, as those should be part of the commonBase due to the standard have exchange above.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyH///hA='),(665,1,'2010-08-19 02:16:03','P',1,'Style-nit: Space between if and (.  Also like above, we don\'t use curly braces on simple conditionals like this one.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyH///hE='),(437,1,'2010-08-19 02:16:03','P',1,'Style-nit: I don\'t really see a good reason to throw a blank line here.  If anywhere it would make more sense to put it after the new advertiseCapability(OPTION_SHALLOW) above given how big that capability set is.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyH///hI='),(361,1,'2010-08-19 02:16:03','P',1,'Style-nit: We don\'t use unnecessary curly braces.',NULL,1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyH///hM='),(666,1,'2010-08-19 19:24:52','P',1,'I think its easier than you think.\n\nWhen using DepthWalk.ObjectWalk we need some additional state.  The client has already told us its old shallow boundary, and we know the new shallow boundary.  What you want to do is  color every object in the have (aka commonBase / uninterestingObjects) list up to but not including the old shallow boundary with the flag UNINTERESTING.\n\nTo do this, we can add a new flag, UNSHALLOW, at the old shallow boundary.  In DepthGenerator as you loop through the parents of a commit do something like this:\n\n  if (c.has(UNSHALLOW))\n    p.add(UNSHALLOW);\n\n  if (c.has(UNINTERESTING)) {\n    if (p.has(UNSHALLOW))\n      c.add(BOUNDARY);\n    else\n      p.add(UNINTERESTING);\n  }\n\nThis block replaces the standard walker.carryFlagsImpl logic with something more specific.  We only carry UNINTERESTING up until the edge, and then we cut over to carrying UNSHALLOW instead.\n\nNow we shouldn\'t output every UNINTERESTING commit, not all of them are relevant.  Instead the produce logic (after deciding depth as that\'s cheap) is something like:\n\n  if (produce)\n    produce = c.has(UNINTERESTING) ? c.has(BOUNDARY) : false;\n\nBasically what I am doing here is coloring everything up to the boundary as UNINTERESTING, and we don\'t normally produce that.  But when we find a commit that was UNINTERESTING and has a parent that is UNSHALLOW, that commit is on the boundary edge.  The client has it, the server has it, but the client doesn\'t have its parents.  This is an excellent point to return the UNINTERESTING commit to PackWriter so it can use these trees and blobs as delta bases for the returned pack.\n\nAbove in the carrying logic it may seem odd that we add BOUNDARY to \"c\" when we are looking at \"p\", but its the right thing to do.  We can only tag a given commit as BOUNDARY once we discover its parent is at the edge.\n\nTo do all of this you need 2 extra flags in your DepthWalk.ObjectWalk.  You can allocate these using newFlag(\"BOUNDARY\"), newFlag(\"UNSHALLOW\").  Unfortunately you also need the unshallow set from UploadPack to be pushed down through here, and the whole thing is getting very specialized to the shallow clone case.  But I think that\'s OK, this stuff is really only useful for the shallow clone logic.','AAALyH///cQ=',1320,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyH///ZY='),(67,1,'2010-08-31 01:48:49','P',1,'You\'re right.  I wasn\'t defining the term UNSHALLOW correctly, which lead to me misunderstanding a lot of the implementation.\n\nI\'ll have to re-read this entire patch set in light of this new explanation.  Thanks.','AAALyn///jI=',1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyn///aA='),(67,81,'2010-08-28 23:37:08','P',1,'I think we may be defining this term differently, and that\'s leading to many/most of your concerns.\n\nI\'m using \'unshallow\' in the same sense that the git pack protocol does--a commit which the client DOES have, but which it used to have marked as shallow (which means \'this commit claims to have parents, but pretend that it doesn\'t because we didn\'t download them\'.)  If we\'re deepening the tree, the client needs to remove the marking on these commits, since afterward it will have their parents just like any other commit.\n\nThus, these commits represent the last commit in the chain that the client has.  Anything beyond this which still passes the depth test is a new commit which must be sent to the client.  Since the client has all UNSHALLOW commits, they should be marked as UNINTERESTING as well, which is normally carried to all ancestors.  This is based on the assumption that if we have a commit, we always have its parents.  But in this case, that is not true, so we need to get rid of the UNINTERESTING flag on these ancestor commits, to tell the rest of the machinery that they need to be sent across.  To accomplish that, I carry the REINTERESTING flag to every commit below an UNSHALLOW commit, to denote that even though it\'s marked as UNINTERESTING, it\'s really lying.\n\nDoes that clear anything up?  Or are there still corner cases in the algorithm if it\'s done this way?','AAALyn///lw=',1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyn///jI='),(102,1,'2010-08-28 02:51:04','P',1,'Hmmph.  Almost makes sense.\n\nCommits that pass this test are the branch heads the client wants, and which are at depth 0.  I\'m a little concerned there may be a corner case here though.  What happens if the client only wants a new branch and that new branch is pointing at a commit that has UNSHALLOW set?  We\'ll wind up up with an  empty pending queue and process nothing at all.  Which means the client WON\'T get the commit it asked us for, and it\'ll crash out, because it doesn\'t have that yet (that\'s why it asked to unshallow it).\n\nWe may just have to make this test:\n\n  if ((c.flags & RevWalk.UNINTERESTING) == 0)\n\nto work around that corner condition.  However we would then be pushing in UNSHALLOW commits that aren\'t actually start points.  This is a bug in DepthWalk.ObjectWalk\'s markUnshallow method.  It shouldn\'t call markStart().\n\nHowever we do also need uninteresting commits to be iterated.  The client may have given us a commit in common that we both have and that wasn\'t wanted by the client (because he already has it).\n\nAnd, uh, this is all far harder than I thought.  I might try poking at it more tomorrow to see if I can better distill down the conditions involved and how we can express them internally.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyn///k8='),(168,1,'2010-08-28 02:51:04','P',1,'I think this is really:\n\n  if (produce)\n    produce = c.has(UNINTERESTING) ? c.has(BOUNDARY) : false;',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyn///lg='),(156,1,'2010-08-28 02:51:04','P',1,'I think your logic is incorrect here.  I still think we want what I  proposed in patch set 1\'s comments:\n\n  if (c.has(UNSHALLOW))\n    p.add(UNSHALLOW);\n  if (c.has(UNINTERESTING)) {\n    if (p.has(UNSHALLOW))\n      c.add(BOUNDARY);\n    else\n      p.add(UNINTERESTING);\n  }\n\nWith renaming your REINTERESTING flag to be BOUNDARY.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyn///lk='),(153,1,'2010-08-28 02:51:04','P',1,'\"everything below us, including us is new\".  When you unshallow something the client doesn\'t have it yet.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyn///lo='),(92,1,'2010-08-28 02:51:04','P',1,'Can we allocate this flag also as part of the DepthWalk?  The reason is, if a walk gets reset and runs again we\'d allocate yet another flag.  Do that enough times and walk suddenly stops working, because there are no free flags.\n\nExplicitly releasing the flag is hard from a generator, there isn\'t an API to have the walk tell the generator that the walk is being reset.  So the easiest thing may be to just allocate this at the same time as the UNSHALLOW flag in the individual walk classes.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyn///ls='),(67,1,'2010-08-28 02:51:04','P',1,'This documentation isn\'t correct.\n\nIf UNSHALLOW is on the commits the client doesn\'t have, but will have when we are done transmitting, these cannot be marked UNINTERESTING.  Really its the first descendant of an UNSHALLOW commit that should be marked UNINTERESTING (any commit whose parent is UNSHALLOW should be UNINTERESTING).',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthGenerator.java','AAALyn///lw='),(173,1,'2010-08-28 02:51:04','P',1,'We shouldn\'t call markStart here.  See my comments in the setup for DepthGenerator for why.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthWalk.java','AAALyn///ks='),(161,1,'2010-08-28 02:51:04','P',1,'Javadoc?  Why would a caller want to do this?',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthWalk.java','AAALyn///l0='),(168,1,'2010-08-28 02:51:04','P',1,'Style-nit: Continuation line should be indented one more level.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthWalk.java','AAALyn///l4='),(73,1,'2010-08-28 02:51:04','P',1,'Shouldn\'t this be a static class?',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthWalk.java','AAALyn///l8='),(78,1,'2010-08-28 02:51:04','P',1,'We typically don\'t expose fields to the public, just to our own package.  I know I argued to expose this more than private, but I really just meant package/default access, not public.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/DepthWalk.java','AAALyn///mA='),(1079,1,'2010-08-28 02:51:04','P',1,'This is a critical exception.  If we don\'t have something that we are unshallowing, we cannot continue.  That means you can simplify your code by removing the try/catch here and make it more like the very simple interestingObjects loop above.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALyn///lA='),(1084,1,'2010-08-28 02:51:04','P',1,'This downcast is unnecessary if you declare the walker variable to be of the correct type above.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALyn///lE='),(1050,1,'2010-08-28 02:51:04','P',1,'Declare this DepthWalk.ObjectWalk and then you don\'t need to downcast below.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALyn///lI='),(1053,1,'2010-08-28 02:51:04','P',1,'These two sort lines are pointless.  DepthWalk doesn\'t honor them.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALyn///lM='),(402,1,'2010-08-28 02:51:04','P',1,'Style-nit: We indent between the \"*\" and the first part of the text with spaces.  Here you used tabs in this block.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALyn///lQ='),(393,1,'2010-08-28 02:51:04','P',1,'Style-nit: Blank line before @param tag.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALyn///lU='),(402,1,'2010-10-28 18:52:29','P',1,'Still have a style-nit here (use spaces instead of tabs for indent inside of javadoc comment).','AAALyn///lQ=',1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALzX///p8='),(393,1,'2010-10-28 18:52:29','P',1,'Still have a style-nit here (blank line before @param)','AAALyn///lU=',1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALzX///qA='),(392,1,'2010-08-28 02:51:04','P',1,'This is sadly going to force us to keep the bulk of this revision pool alive longer than we need to.\n\nCan we instead do:\n\n  unshallowCommits.add(walk.lookupCommit(c));\n\nThis way what we hold onto is a pointer into the main pool we already are retaining long-term.  Or maybe better, since these two collections don\'t actually have to be RevCommits we can just declare them ObjectId and use:\n\n  unshallowCommits.add(c.copy));\n\nto shed the entire pool overhead.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyn///lc='),(697,1,'2010-08-28 02:51:04','P',1,'Style-nit: Space after if',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALyn///lY='),(698,1,'2010-10-28 18:52:29','P',1,'I think I would prefer passing the other shallow stuff through a new method.  That is:\n\n  if (depth > 0)\n    pw.setShallowPack(depth, unshallowCommits);\n  pw.preparePack(pm, wantAll, commonBase);',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALzX///qE='),(449,1,'2010-10-28 18:52:29','P',1,'Style-nit: Please insert a blank line after your new block (and before the \"want\" test).',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALzX///qI='),(445,1,'2010-10-28 18:52:29','P',1,'Style-nit: Please insert a blank line here between the two command test blocks.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALzX///qM='),(392,1,'2010-10-28 18:52:29','P',1,'We still need to do what I suggested earlier to shed the revision pool memory usage:\n\n  unshallowCommits.add(c.copy())','AAALyn///lc=',1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALzX///qQ='),(387,1,'2010-10-28 18:52:29','P',1,'Style-nit: We don\'t need {} around this statement.',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALzX///qU='),(385,1,'2010-10-28 18:52:29','P',1,'This should be c.getDepth()',NULL,1320,3,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALzX///qY='),(129,51,'2010-08-19 12:40:46','d',1,'Done','AAALyH///j8=',1324,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/T0001_PersonIdent.java','AAALyH///ds='),(129,1,'2010-08-18 19:15:29','P',1,'I agree with the tests for PersonIdent.  But we also need these same tests for RawParseUtils.parsePersonIdent().  That constructor is used for RevCommit\'s getAuthor() method, which is probably what most display tools will be relying on.  And I\'m reasonably certain we aren\'t testing for the multiple author case there, even if it does work.',NULL,1324,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/T0001_PersonIdent.java','AAALyH///j8='),(199,51,'2010-08-19 13:35:58','d',1,'Done','AAALyH///j4=',1324,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/PersonIdent.java','AAALyH///dM='),(199,1,'2010-08-18 19:15:29','P',1,'This constructor should be taken out back and put out of its misery.\n\nI wonder if we shouldn\'t instead write it as:\n\n  PersonIdent self = RawParseUtils.parsePersonIdent(Constants.encode(\"author \" + in), 7);\n  ... copy fields from self to this ...\n\nThat way we only have a single routine to parse the canonical formatting.  This constructor should be infrequently used, so dropping to UTF-8 byte[] and then upconverting back to String shouldn\'t be a major performance hit in exchange for having just one implementation to test and maintain.',NULL,1324,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/PersonIdent.java','AAALyH///j4='),(1046,1,'2010-08-19 18:26:25','P',1,'Style-nit: Private constructor in a static utility class is always last.  So move lastIndexOfTrim() above here.',NULL,1324,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALyH///a0='),(1051,1,'2010-08-19 18:26:25','P',1,'Style-nit: We don\'t use curly braces around simple loops.',NULL,1324,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALyH///a4='),(701,1,'2010-08-19 18:26:25','P',1,'Why do we need to trim this?  Whatever is between < and > should be taken as-is as the email.  Do you have an example of a malformed commit where the email contains leading or trailing whitespace near the <>\'s and it needs to be discarded?  Even if that exists, I\'d almost still be tempted to say that is the proper text of the address, and we should preserve that text in the parsing.',NULL,1324,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALyH///ag='),(670,1,'2010-08-19 18:26:25','P',0,'Thanks for fixing the Javadoc here.  Line 681 returning null when there was no \"<\" on the line totally contradicted the documentation.  :-)',NULL,1324,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALyH///as='),(705,1,'2010-08-19 18:26:25','P',1,'No.  When parsing a commit (for example) the array raw contains the entire message.  The tail of the array is the end of the message and has nothing to do with the author or committer line you are trying to parse right now.\n\nThis is why we use emailE above to try to find the termination point within the current line.  nextLF() returns the position of either the \'>\' or the \'\\n\', whichever occurs first.  And then we try to look only in that range of [nameB, emailE).',NULL,1324,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALyH///aw='),(1051,51,'2010-08-20 13:10:32','P',1,'Done','AAALyH///a4=',1324,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALyH///Y8='),(1046,51,'2010-08-20 13:10:32','P',1,'Done','AAALyH///a0=',1324,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALyH///ZA='),(705,51,'2010-08-20 13:10:32','P',1,'What an ugly bug. Interestingly, no test has detected that. I\'ll add assertions to RevCommitParseTest.','AAALyH///aw=',1324,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALyH///ZE='),(701,51,'2010-08-20 13:10:32','P',1,'I think I\'ve taken that from old PersonIdent code, anyway I agree that we shouldn\'t trim here. Also name is currently right-trimmed, I will change that to preserve spaces as well (except of the 1-space separator)','AAALyH///ag=',1324,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALyH///ZI='),(7,1,'2010-08-25 17:01:55','P',1,'Style-nit: We try to be more present-tense in a commit message.  \"Fix parsing of multiple authors in PersonIdent\" perhaps?',NULL,1324,4,'/COMMIT_MSG','AAALyn///xY='),(81,51,'2010-08-26 10:47:43','P',1,'Done','AAALyn///xM=',1324,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/RawParseUtils_ParsePersonIdentTest.java','AAALyn///r0='),(125,51,'2010-08-26 10:47:43','P',1,'Done','AAALyn///xQ=',1324,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/RawParseUtils_ParsePersonIdentTest.java','AAALyn///rw='),(81,1,'2010-08-25 17:01:55','P',1,'I wouldn\'t call this a legal case.  Maybe move it to a new testParsePersonIdent_fuzzyCases() ?',NULL,1324,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/RawParseUtils_ParsePersonIdentTest.java','AAALyn///xM='),(125,1,'2010-08-25 17:01:55','P',1,'Since nameB is now unused, maybe you can drop it and clarify the code above?  Everyone is passing 0 anyway for it, we probably should have just hard-coded it to to begin with.',NULL,1324,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/RawParseUtils_ParsePersonIdentTest.java','AAALyn///xQ='),(315,51,'2010-08-26 10:47:43','P',1,'Done','AAALyX///8k=',1324,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Commit.java','AAALyn///rs='),(315,1,'2010-08-25 17:01:55','P',1,'I realized that having this duplication here in Commit and in RevCommit was silly, so Commit had all of its parsing code removed and the class was renamed to CommitBuilder.\n\nSo please rebase onto current master and drop this particular edit, you don\'t need it anymore.',NULL,1324,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Commit.java','AAALyX///8k='),(200,51,'2010-08-26 10:47:43','P',1,'Done','AAALyX///8g=',1324,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/PersonIdent.java','AAALyn///ro='),(200,1,'2010-08-25 17:01:55','P',1,'I would prefer {@link RawParseUtils#parsePersonIdent(String)} here so that actual HTML documentation provides a jump to the replacement method\'s documentation.',NULL,1324,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/PersonIdent.java','AAALyX///8g='),(149,51,'2010-08-26 10:47:43','P',1,'Done','AAALyn///xc=',1324,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Tag.java','AAALyn///rk='),(149,1,'2010-08-25 17:01:55','P',1,'Same as with Commit, this class no longer exists in master.',NULL,1324,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Tag.java','AAALyn///xc='),(706,51,'2010-08-26 10:47:43','P',1,'If we have passed condition on line 693, we know that raw[emailE - 1] is \'>\'. raw[emailE] may be LF, so nextLF(raw, emailE) will go too far (to the next LF).\n\nRegarding the suggested loop, the code doesn\'t look simpler to me than what the patch contains now, on the other hand it\'s not as tolerant regarding \"junk\" after the author email. I\'ve added another test case to RawParseUtils_ParsePersonIdentTest.testParsePersonIdent_fuzzyCases() illustrating a possible problem.','AAALyn///w8=',1324,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALyn///rg='),(706,1,'2010-08-25 17:01:55','P',1,'Why emailE - 1?  emailE must be \'>\' according to your condition on line 693, or its raw.length.  nextLF will return raw.length if you pass it raw.length.  So I don\'t think you need to subtract 1.\n\nActually, the more that I think about this, maybe we can say instead:\n\n  int timeBegin = emailE;\n  do {\n    int e = nextLF(raw, timeBegin, \'>\');\n    if (e < raw.length && raw[e - 1] == \'>\')\n      timeBegin = e;\n    else\n      break;\n  } while (true);\n\nThat way we only scan the string once going forwards, rather than scanning from the end backwards.  Then you can leave the old time parsing code alone and just update its starting point to be timeBegin.',NULL,1324,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALyn///w8='),(4,1,'2010-08-19 02:19:59','P',1,'FWIW I don\'t see a reason to add a copyright header for a negative delta.  But whatever.  This sort of tiny (or negative!) change is why we have that trailing line \"and other copyright owners\".  Trivial edits with new copyright lines will eventually result in 100 lines worth of copyright headers with no surviving code due to small bug fixes, etc. over the years.  Yuck.',NULL,1331,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Tag.java','AAALyH///fU='),(382,1,'2010-08-19 02:21:34','P',1,'Nak.  Needs to be:\n\n  if (tag.getTagger() != null) {\n    w.write(\"tagger \");\n    w.write(tag.getTagger().toExternalString());\n    w.write(\'\\n\');\n  }\n\nThat is we only produce the \"tagger\" header line if there is an identity that will appear on it.  We never should create an empty header line.\n\nI\'ll fix it during cherry-pick.',NULL,1333,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/ObjectInserter.java','AAALyH///fA='),(64,1,'2010-08-19 17:32:40','P',1,'Nak.  We try not to use args4j like this.  In particular \"--\" is handled specially by CmdLineParser (in pgm.opt) on line 125.  It never makes it into args4j.\n\nThis should be @Argument(index = 1)',NULL,1334,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/LsTree.java','AAALyH///bY='),(82,1,'2010-08-19 17:44:36','P',1,'Do not do single byte IO.  Most of our ObjectStream implementations perform very poorly.  Allocate a new byte[4096] or new byte[8192] and do IO in larger units.\n\nAlso the size is well known (outputStream.getSize()).  It is good to be paranoid, so double check that the total number of bytes output matches the size of the stream.  If they differ, complain, loudly with a die.',NULL,1335,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/CatFile.java','AAALyH///bI='),(79,1,'2010-08-19 17:44:36','P',1,'Use db.open(objectId, typeCode) instead.',NULL,1335,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/CatFile.java','AAALyH///bM='),(61,1,'2010-08-19 17:44:36','P',1,'Since we\'re mucking about with this, lets just define:\n\n  public enum ObjectType {\n    COMMIT(Constants.OBJ_COMMIT, Constants.TYPE_COMMIT),\n    TREE(...),\n    BLOB(...),\n    TAG(...)\n\n    public int getPackType() {\n      return packType;\n    }\n\n    public String getTypeString() {\n      return typeName;\n    }\n\n    public static ObjectType forPackType(int type) {...}\n    public static ObjectType forTypeString(String type) {...}\n  }\n\nand declare this as part of our public API.  While we are at it we can add getObjectType() to ObjectLoader, ObjectStream, and RevObject should an application prefer to use the type-safe enum variant.  We should also implement overload forms of the open(ObjectId,int) method to be open(ObjectId,ObjectType).  Our current typing code was before we supported Java 5 and had  access to enums.  The enums are a bit cleaner to work with, so we might as well just start supporting it.  IMHO that should all be in its own change, before you add CatFile.\n\nThen you can just use ObjectType here for your parameter.',NULL,1335,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/CatFile.java','AAALyH///bQ='),(1016,4,'2010-08-19 23:28:19','P',1,'Why removing null check for headId ? Is there a guarantee that db can always resolve HEAD ?\n\nFindBugs complains that currentHeadId is never written, I suspect inside this if block currentHeadId should be set to headId then the TODO comment would make sense',NULL,1346,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/GitHistoryPage.java','AAALyH///Yo='),(61,1,'2010-08-23 14:39:12','P',1,'You shouldn\'t do this.  I can\'t promise you that parsing the body of another RevWalk\'s RevCommit with a new RevWalk will continue to work in the future.\n\nIf you need to ensure the buffer is parsed, you should be passing around the RevWalk that created the RevCommit you passed around, and call parseBody() on that.\n\nparseBody() knows whether or not the buffer is loaded.  Its essentially a no-op if the buffer is already loaded.  Therefore you don\'t need the rc.getRawBuffer() conditional check around it.\n\nI know we don\'t promise that getRawBuffer() implies the other things are accessible.  That is, just because getRawBuffer() returns non-null does not imply that getFullMessage() or getAuthorIdent() will work.  Only parseBody() promises that.',NULL,1350,3,'org.eclipse.egit.core/src/org/eclipse/egit/core/internal/storage/CommitFileRevision.java','AAALyn///9U='),(168,63,'2010-08-20 18:14:56','P',1,'It seems like an NPE can occur here. In GitModelCommit\'s constructors, there is a code path where the \'baseCommit\' field is set to \'null\'.',NULL,1357,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyX///7c='),(181,63,'2010-08-20 18:14:56','P',1,'It seems like an NPE can occur here. In GitModelCommit\'s constructors, there is a code path where the \'baseCommit\' field is set to \'null\'.',NULL,1357,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyX///7Y='),(170,63,'2010-08-20 19:17:48','P',1,'This seems off. If the other model\'s base commit is \'null\', we only check if we ourselves has a base commit is \'null\'? The locations and/or remote commits of the two models may still differ from each other, no?\n\nThe location, remote commit, and base commit are all taken consideration in the hashCode() implementation so it seems to me that all three should also should be factored into the implementation of equals(Object).',NULL,1357,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyX///7I='),(194,49,'2010-08-20 23:48:52','P',1,'Good hint! Thank you! ;)','AAALyX///6E=',1357,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyX///5s='),(179,49,'2010-08-20 23:48:52','P',1,'We already had short discussion about common ancestors on jgit-dev list and according to this[1] Shawn\'s answer getting fist common ancestor is the best solution.\n\nIn case of naming strategy for variants. Team framework used to use \'local\', \'base\', and \'remote\' names for variants where \'local\' determinate locally stored file version. In case of git the \'local\' in some cases can be version from branch that isn\'t current HEAD, even more we could exclude locally made changes from synchronization result. Therefore I\'ve decided to use \'ancestor\', \'base\' and \'remote\' names.\n\n1. http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg00435.html','AAALyX///6c=',1357,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyX///5w='),(179,8,'2010-08-20 23:00:42','P',1,'Technically we could have different merge bases, since the common ancestor cannot always be determined unambigiously in the case of so called criss-cross merges. Typically we would probably use the same algorithm in both cases though. but considereing all exotic use cases Git users come up with...\n\nWe could perhaps declare that different bases are impoossible here. I\'m not familiar enough with the synchronization model.\n\nShawn?\n\nBTW, Isn\'t the term base and common ancestor supposed to be synonyms? I.e. we determine the merge base by trying to find a common ancessor from the local and remote commits. I.e. \"base\" here could probably be better described as local (or our when remote is called their).',NULL,1357,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyX///6c='),(194,8,'2010-08-20 23:00:42','P',1,'commit hashcodes are pretty well distributed so you could just xor them if you want something faster.',NULL,1357,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyX///6E='),(10,49,'2010-08-22 21:42:25','P',1,'Thank you Shawn for this information, I\'ll re-implement this change exactly the way you describe it ;)','AAALyX///1U=',1358,2,'/COMMIT_MSG','AAALyn////k='),(10,1,'2010-08-21 01:28:34','P',1,'I disagree.  The correct thing to do is compare the commit graphs in left-right mode.  This isn\'t directly supported in JGit with a thing called \"left-right mode\", you have to do configure it yourself in the application level.\n\nCreate two RevFlag instances from a RevWalk, call them LOCAL and REMOTE.\n\nparseCommit() the current branch, and add the LOCAL flag to it.  markStart() that commit.\n\nparseCommit() the matching remote branch, and add the REMOTE flag to it.  markStart() that commit.\n\nStep the RevWalk until you get back a commit that contains both LOCAL and REMOTE on it.  That is your common merge base.  But more importantly, as you stepped it looking for this point you built up a list of commits.  If you store those commits into two lists based on which flags they have (only LOCAL ones go into the \"outgoing list\" and only REMOTE ones go into the \"incoming list\"), you get a very accurate representation of what is about to sync.\n\nAs for finding the matching remote branch, that typically comes from the repository configuration.  Get the Config, find the variables branch.${currentBranchName}.remote and branch.${currentBranchName}.merge.  The first tells you which remote configuration block you need to examine.  The second tells you the branch name in that remote.  You\'ll then need to examine the remote.${remoteName}.fetch RefSpecs to find the one that matches the branch.merge value, so you can map that to the local reference name.  That local reference name is what you need to resolve in order to parse that remote branch\'s commit.',NULL,1358,2,'/COMMIT_MSG','AAALyX///1U='),(237,49,'2010-08-22 21:42:25','P',1,'I want to find parent of \'actual\' commit so that I can find objects that was changed by \'actual\' commit. In most cases there would be only a one commit, but in case of merge commits I want get merge ancestor so that changes in merge commit can be properly described in SyncView.','AAALyX///1Y=',1358,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyn////M='),(237,49,'2010-08-22 21:42:25','P',1,'Actually in some cases \'base\' isn\'t always same as \'our\'. Because in Git Model we are comparing commit vs. commit. This means that most comparisons will be done \'our\' vs \'our\' commit (that are commit that was made by user in theirs topic branch) or \'their\' vs \'their\' (in this case that are commits that comes from remote repository). There would be only one commit that can be described as \'our\' vs \'their\', this will be a common ancestor commit.\n\nBut this is only my humble opinion ...','AAALyX///1E=',1358,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyn////Q='),(245,49,'2010-08-22 21:42:25','P',1,'I\'ll fix this, thanks for pointing this out ;)','AAALyX///1c=',1358,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyn////U='),(237,6,'2010-08-23 14:07:19','P',1,'I still do not understand why we need any ancestor in the GitModel. An ancestor is used by the synchronize framework to calculate the entries for the three way compare. But in GitModel we just compare to the parent, don\'t we? I still would say that we should return null in GitModelBlob.getAncestor (javadoc: Returns null if this input has no ancestor or in the two-way compare case.)\n\nWhen there is more than one parent things of course get more complicated. But returning any ancestor commit is definitely wrong.','AAALyn////M=',1358,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyn///+E='),(245,1,'2010-08-21 01:28:34','P',1,'Parsing zeroId will always throw an exception.',NULL,1358,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyX///1c='),(237,8,'2010-08-21 13:52:39','P',1,'Us this the terminology confusion I commented on in a previous commit?. I.e. \"base\" here is niot the merge base, but trather \"our\"?','AAALyX///1Y=',1358,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyX///1E='),(237,1,'2010-08-21 01:28:34','P',1,'This is uh, pointless.\n\nThe merge base of a commit and its parents is going to be one of the parents.\n\nWhat were you actually trying to do?',NULL,1358,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALyX///1Y='),(121,49,'2010-08-26 19:55:02','P',1,'OK, I solve this problem. tw.carry(allFlags) is required when we want to mark all commits with given flag','AAALyn///wc=',1358,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelRepository.java','AAALyn///po='),(121,49,'2010-08-25 21:31:19','P',1,'Shawn, could you please look at this \"left-right mode\" implementation?\n\nI don\'t know why it returns only one RevCommit that have local flag and one with remote flag.',NULL,1358,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelRepository.java','AAALyn///wc='),(145,49,'2010-08-27 14:50:45','P',1,'Damn, I miss this ...\n\nDone','AAALyn///m8=',1358,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelRepository.java','AAALyn///m0='),(145,6,'2010-08-27 14:40:16','P',1,'Now I get an incoming decorator for my local change and an outgoing decorator for my remote change.',NULL,1358,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelRepository.java','AAALyn///m8='),(87,49,'2010-08-20 23:52:36','P',1,'We prefer have single statement if\'s without brackets.',NULL,1360,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitFolderResourceVariant.java','AAALyX///5g='),(69,49,'2010-08-20 23:52:36','P',1,'We prefer have single statement if\'s without brackets.',NULL,1360,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALyX///5c='),(113,49,'2010-08-20 23:52:36','P',1,'We prefer have single statement if\'s without brackets.',NULL,1360,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALyX///5U='),(99,49,'2010-08-20 23:52:36','P',1,'We prefer have single statement if\'s without brackets.',NULL,1360,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTree.java','AAALyX///5Y='),(107,6,'2010-08-24 06:58:58','d',1,'Thanks, I had already supposed that there must be an easier solution but I did not figure it out myself.','AAALyn///8w=',1371,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALyn///4Y='),(107,1,'2010-08-23 15:38:14','P',1,'Why do we need this?\n\nWhy not just add an EmptyTreeIterator to the TreeWalk in slot 0 inside of EGit?  Then you are comparing the initial commit to the empty tree, and everything magically falls out as added?\n\nIts what I do inside of Gerrit Code Review for initial commits.  And it means I don\'t have to muck around with special corner cases like this inside of JGit.',NULL,1371,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffEntry.java','AAALyn///8w='),(195,46,'2010-08-23 15:30:11','P',1,'Text.getText() never returns null',NULL,1376,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/sharing/ExistingOrNewPage.java','AAALyn///88='),(269,46,'2010-08-25 07:03:44','P',1,'Done','AAALyn///2k=',1393,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryActionHandler.java','AAALyn///0c='),(264,46,'2010-08-25 07:03:44','P',1,'Done','AAALyn///2o=',1393,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryActionHandler.java','AAALyn///0g='),(261,46,'2010-08-25 07:03:44','P',1,'Done','AAALyn///2s=',1393,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryActionHandler.java','AAALyn///0k='),(269,63,'2010-08-24 17:55:50','P',1,'I think you can get by with calling HandlerUtil\'s getVariable(String, ExecutionEvent) method with ISources.ACTIVE_EDITOR_INPUT_NAME as the first parameter.',NULL,1393,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryActionHandler.java','AAALyn///2k='),(264,63,'2010-08-24 17:55:50','P',1,'Please don\'t downcast. I\'m pretty sure this will result in a CCE in 4.x.\n\nUse HandlerUtil\'s getCurrentSelection(ExecutionEvent) method instead.',NULL,1393,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryActionHandler.java','AAALyn///2o='),(261,63,'2010-08-24 17:55:50','P',1,'Please don\'t downcast. I\'m pretty sure this will result in a CCE in 4.x.\n\nUse HandlerUtil\'s getActiveMenuSelection(ExecutionEvent) method instead.',NULL,1393,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/RepositoryActionHandler.java','AAALyn///2s='),(238,2,'2010-08-26 00:13:40','P',1,'We should probably use ObjectLoader.STREAM_THRESHOLD to make this a little bit mysterious when looking at the code... keep it all in one place.',NULL,1401,3,'org.eclipse.jgit/src/org/eclipse/jgit/revwalk/RevWalk.java','AAALyn///t4='),(627,2,'2010-08-26 00:15:48','P',1,'This is essentially duplicated code in the above format(...) in the future we should find a way to collapse the code...',NULL,1402,3,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALyn///ts='),(41,2,'2010-08-26 17:17:45','d',1,'We don\'t need source for this plug-in, right? We should just remove it.',NULL,1405,3,'org.eclipse.egit.source-feature/feature.xml','AAALyn///q4='),(12,4,'2010-09-27 20:21:41','P',1,'style nit: here you use camel case, all other trace switches are all lowercase, we should decide for one of the choices and use that consistently.',NULL,1421,2,'org.eclipse.egit.ui/.options','AAALy3///Ts='),(10,8,'2010-08-26 18:59:42','P',1,'Does  4.0.0 work?',NULL,1430,1,'org.eclipse.jgit.test/META-INF/MANIFEST.MF','AAALyn///qg='),(7,1,'2010-08-26 22:56:02','P',1,'Good, at least you spelled spelling correctly!',NULL,1436,1,'/COMMIT_MSG','AAALyn///oo='),(7,49,'2010-08-30 21:57:29','P',1,'Done','AAALyn///fU=',1437,2,'/COMMIT_MSG','AAALyn///ck='),(7,8,'2010-08-30 18:03:27','P',1,'Refer to the revreted commit using words rather than hex digits. That may\nbe a challenge but the subject line does need the precision. Since we\nsometimes rebase maybe we should refer to change id\'s instead.',NULL,1437,2,'/COMMIT_MSG','AAALyn///fU='),(17,4,'2010-08-29 22:01:44','d',1,'Done','AAALyn///jQ=',1442,1,'org.eclipse.jgit.packaging/org.eclipse.jgit.source.feature/.project','AAALyn///iE='),(17,1,'2010-08-28 18:33:29','P',1,'Given that robin reverted his \"hide maven output\" changes, do we still want this filteredResources block?',NULL,1442,1,'org.eclipse.jgit.packaging/org.eclipse.jgit.source.feature/.project','AAALyn///jk='),(17,8,'2010-08-28 20:04:04','P',1,'Since it is not compatible with 3.5, we cannot have it.','AAALyn///jk=',1442,1,'org.eclipse.jgit.packaging/org.eclipse.jgit.source.feature/.project','AAALyn///jQ='),(35,4,'2010-08-29 22:02:19','d',1,'Done','AAALyn///jY=',1442,1,'org.eclipse.jgit.packaging/org.eclipse.jgit.source.feature/edl-v10.html','AAALyn///h4='),(20,4,'2010-08-29 22:02:06','d',1,'Done','AAALyn///jc=',1442,1,'org.eclipse.jgit.packaging/org.eclipse.jgit.source.feature/edl-v10.html','AAALyn///h8='),(14,4,'2010-08-29 22:02:01','d',1,'Done','AAALyn///jg=',1442,1,'org.eclipse.jgit.packaging/org.eclipse.jgit.source.feature/edl-v10.html','AAALyn///iA='),(20,1,'2010-08-28 18:33:29','P',1,'Tab after space.',NULL,1442,1,'org.eclipse.jgit.packaging/org.eclipse.jgit.source.feature/edl-v10.html','AAALyn///jc='),(14,1,'2010-08-28 18:33:29','P',1,'Trailing space.',NULL,1442,1,'org.eclipse.jgit.packaging/org.eclipse.jgit.source.feature/edl-v10.html','AAALyn///jg='),(35,1,'2010-08-28 18:33:29','P',1,'Trailing space on most of these lines.',NULL,1442,1,'org.eclipse.jgit.packaging/org.eclipse.jgit.source.feature/edl-v10.html','AAALyn///jY='),(133,51,'2010-08-30 13:42:08','d',1,'I just understood that newInCore() should never be read-only.','AAALyn///i0=',1446,1,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///f8='),(133,8,'2010-08-29 14:22:26','P',1,'Make this an addition in a sepatate commit so we can review thiis flaga and derived changes separately.',NULL,1446,1,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///i0='),(949,51,'2010-08-30 13:42:31','d',1,'Done','AAALyn///iw=',1446,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALyn///f4='),(949,8,'2010-08-29 14:22:26','P',1,'Why would we need to lock if it is read-only?',NULL,1446,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALyn///iw='),(15,1,'2010-08-31 00:45:21','P',1,'A new unit test for version 3 formatted index files would also be nice.',NULL,1446,2,'/COMMIT_MSG','AAALyn///ac='),(15,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///ac=',1446,2,'/COMMIT_MSG','AAALyn///YU='),(306,1,'2010-08-31 00:45:21','P',1,'Style-nit: Please try to avoid reformatting lines you haven\'t modified.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///b0='),(249,1,'2010-08-31 00:45:21','P',1,'I assume this flag won\'t be in the final version of the patch when we have writing support?',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///b4='),(412,1,'2010-08-31 00:45:21','P',1,'Its OK to ignore an extension whose name is fully upper-case.  That still holds true in version 3, doesn\'t it?  So we should be OK to just ignore the EXT_RESOLVE_UNDO entry for now, and add support for it later on.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///bc='),(402,1,'2010-08-31 00:45:21','P',1,'Style-nit: Unnecessary reformatting.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///bg='),(607,1,'2010-08-31 00:45:21','P',1,'Style-nit: Unnecessary reformatting.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///bI='),(378,1,'2010-08-31 00:45:21','P',1,'The whole line is still shorter without the local temporary variable, and then we don\'t even need the curly brackets.  So basically, uh, use the older layout for this line of code.  :-)',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///bk='),(489,1,'2010-08-31 00:45:21','P',1,'Style-nit: Unnecessary reformatting.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///bM='),(376,1,'2010-08-31 00:45:21','P',1,'Please use our MutableInteger class instead.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///bo='),(454,1,'2010-08-31 00:45:21','P',1,'Style-nit: Unnecessary reformatting.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///bQ='),(363,1,'2010-08-31 00:45:21','P',1,'Style-nit: Unnecessary reformatting.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///bs='),(442,1,'2010-08-31 00:45:21','P',1,'Style-nit: Unnecessary reformatting.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///bU='),(367,1,'2010-08-31 00:45:21','P',1,'Style-nit: Unnecessary reformatting.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///bw='),(432,1,'2010-08-31 00:45:21','P',1,'Style-nit: Unnecessary reformatting.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///bY='),(412,1,'2010-08-31 18:41:22','P',1,'Its not a performance optimization, but its categorized as one.  The reason being that they didn\'t want to completely break every existing Git implementation from being able to read a newer style index.  I don\'t claim to understand what they did, I\'m just saying what it is.  The \"standards\" say any extension named with 4 capitals is an optional extension that can be safely skipped.  All other extensions must be rejected without further processing.  \'REUC\' is in the former category.','AAALyn///Zg=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///VU='),(249,51,'2010-08-31 12:12:17','P',1,'I\'ve added writing support now and skipped this flag, however I\'m not sure if this is OK regarding RESOLVE_UNDO.','AAALyn///b4=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///YQ='),(363,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///bs=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///Z0='),(306,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///b0=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///Z4='),(432,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///bY=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///Zc='),(412,51,'2010-08-31 12:12:17','P',1,'Is RESOLVE_UNDO definitely a performance optimization?','AAALyn///bc=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///Zg='),(402,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///bg=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///Zk='),(607,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///bI=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///ZM='),(376,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///bo=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///Zo='),(489,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///bM=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///ZQ='),(378,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///bk=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///Zs='),(454,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///bQ=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///ZU='),(367,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///bw=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///Zw='),(442,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///bU=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///ZY='),(426,1,'2010-08-31 00:45:21','P',1,'The bit is either set or not, so != 0 is a faster test here.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///a0='),(116,1,'2010-08-31 00:45:21','P',1,'This collides with the UPDATE_NEEDED flag below.  As far as I can tel they sit in the same bit slot.  Perhaps a change before this one to correct our definition of UPDATE_NEEDED would be a good idea.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///a4='),(617,1,'2010-08-31 00:45:21','P',1,'Please do similar to what we do with ASSUME_VALID and UPDATE_NEEDED by checking the specific byte that this flag appears in and avoiding the decode to uint16.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///a8='),(117,1,'2010-08-31 00:45:21','P',1,'I\'m not sure these end-of-line comments provide us anything of value.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///ak='),(616,1,'2010-08-31 00:45:21','P',1,'I\'m not sure we should expose this as a public member yet.  I doubt callers really need it, so lets start with it as package private.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///ao='),(634,1,'2010-08-31 00:45:21','P',1,'I would prefer:\n\n  if (isExtended())\n   return NB.decodeUInt16(info, infoOffset + P_FLAGS2) << 16;\n  else\n    return 0;',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///as='),(435,1,'2010-08-31 00:45:21','P',1,'The bit is either set or not, so != 0 is a faster test here.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///aw='),(144,1,'2010-08-31 00:45:21','P',1,'Seems we use this only once.  Wouldn\'t it be easier to just do if (isExtended()) below?\n\nAside: And oh, the guy who came up with this format should be taken out back and shot.  Conditionally adding 2 bytes to an index record only based on a bit buried deep inside of the record?  Stupid.  Records are *still* padded out to an 8 byte alignment.  That padding wastes more than the 2 bytes would.  For many records, I\'d bet we could fit the 2 additional bytes into the padding.  *sigh*',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///bA='),(138,1,'2010-08-31 00:45:21','P',1,'Style-nit: Unnecessary reformatting.  This line used to indent with tabs, now its using spaces.',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///bE='),(426,1,'2010-08-31 18:41:22','P',1,'Its faster to compare to 0 because the JVM has opcodes specifically for that.  Comparing to a constant value like 0x40000000 requires using additional instructions to load that large integer from the constant pool onto the stack, and then compare to that integer.\n\nWhen you turn around and JIT this bytecode, most processors can perform a compare-to-zero-and-conditional-jump pretty efficiently, its a very common idiom.  Comparing to a larger value like 0x40000000 still requires pushing that value into a register from the instruction stream, then doing the compare.  So assuming everything JITs out nicely, comparing to 0 should still be a full clock cycle faster than not.\n\nOf course in all of this I\'m assuming the compiler isn\'t smart enough to realize that the mask involved in the preceding & operator contains only a single bit set, and that therefore the result of the & operation is either going to be 0 or != 0, and that therefore it can optimize out the equality test to be a compare with zero instead of compare with the constant.  It may be that the compiler and-or-JIT is smart enough to figure that out, in which case my rule is pointless.  (FWIW, I just checked, the Sun javac can\'t do this optimization even when compiling with -O.)\n\nAnyway, even ignoring all of that, our coding style when comparing a single bit is to use != 0, not the constant itself a second time.  We only use the constant when the & mask contains more than one bit and we need to test that a specific bit pattern remains, e.g. the way we test in FileMode.\n\n:-)','AAALyn///Y8=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///VY='),(616,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///ao=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///Y0='),(435,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///aw=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///Y4='),(426,51,'2010-08-31 12:12:17','P',1,'Hm, \"faster\" ... :) OK.','AAALyn///a0=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///Y8='),(634,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///as=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///Ys='),(617,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///a8=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///Yw='),(116,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///a4=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///YY='),(144,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///bA=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///ZA='),(138,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///bE=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///ZE='),(117,51,'2010-08-31 12:12:17','P',1,'Done','AAALyn///ak=',1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///ZI='),(948,1,'2010-08-31 00:45:21','P',1,'I assume we\'ll drop this new variant in the when you add write support?',NULL,1446,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALyn///ag='),(190,1,'2010-08-31 19:08:18','P',1,'Actually the count was 7.',NULL,1446,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/dircache/DirCacheCGitCompatabilityTest.java','AAALyn///U0='),(187,1,'2010-08-31 19:08:18','P',1,'Style-nit: This all fits on one line.',NULL,1446,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/dircache/DirCacheCGitCompatabilityTest.java','AAALyn///U4='),(185,1,'2010-08-31 19:08:18','P',1,'Actually the file name is \"gitgit.index.v3.skipWorkTree\"',NULL,1446,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/dircache/DirCacheCGitCompatabilityTest.java','AAALyn///U8='),(212,1,'2010-08-31 19:08:18','P',1,'Style-nit: Line too long.',NULL,1446,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/dircache/DirCacheCGitCompatabilityTest.java','AAALyn///Uo='),(207,1,'2010-08-31 19:08:18','P',1,'Typically we use assertEquals(Arrays.equals(expectedBytes, indexBytes));',NULL,1446,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/dircache/DirCacheCGitCompatabilityTest.java','AAALyn///Us='),(198,1,'2010-08-31 19:08:18','P',1,'These last 3 files aren\'t in the index.',NULL,1446,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/dircache/DirCacheCGitCompatabilityTest.java','AAALyn///Uw='),(352,1,'2010-08-31 18:47:54','P',1,'Style-nit: Curly braces aren\'t necessary.',NULL,1446,3,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///VI='),(337,1,'2010-08-31 18:47:54','P',1,'Style-nit: Curly braces aren\'t necessary here.',NULL,1446,3,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCache.java','AAALyn///VM='),(158,1,'2010-08-31 18:47:54','P',1,'Style-nit: We cuddle the else onto the line with the closing }',NULL,1446,3,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheEntry.java','AAALyn///VE='),(195,1,'2010-08-31 00:50:12','P',1,'Instead of mucking with the TreeWalk API, we can do this through a TreeFilter:\n\n  class SkipWorkTreeFilter {\n    private final int treeIdx;\n\n    SkipWorkTreeFilter(int treeIdx) {\n      this.treeIdx = treeIdx;\n    }\n\n    boolean include(TreeWalk walker) {\n      DirCacheIterator i = walker.getTree(treeIdx);\n      if (i == null)\n        return true;\n\n      DirCacheEntry e = i.getDirCacheEntry();\n      return e == null || !e.isSkipWorkTree();\n    }\n  }\n\nCallers who want work tree skipping can just and this filter in with any other filters they are running on the TreeWalk.',NULL,1447,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheIterator.java','AAALyn///aU='),(195,1,'2010-08-31 19:30:24','P',1,'I still don\'t think this belongs on the iterators.  I think it belongs as a TreeFilter, and callers who are using a DirCache during a walk should be dropping in the skip filter of they don\'t want to see the currently skipped paths.\n\nI\'m really thinking about cases like AddCommand or Merge which need to see the path no matter what, because they may need to un-skip the entry from the index if the working tree actually has that same location.  Or at the least error out.\n\nMeanwhile other cases like doing a status actually want to skip those paths.  Or do they?  Even on status, what should happen if I create foo/bar.txt when foo/bar.txt is marked as skipped in the index?  Shouldn\'t we highlight this case to the user?\n\nSo blindly skipping a path because one iterator has it tagged as skipped doesn\'t seem quite right.  If the caller really does want to ignore that record, they can easily do so if we provide them with a TreeFilter that can perform the skipping.  And then its their job to add it into the filter graph, just like its their job to add in TreeFilter.ANY_DIFF if they want a difference across the trees.','AAALyn///YI=',1447,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheIterator.java','AAALyn///UM='),(195,51,'2010-08-31 12:18:27','P',1,'I though about that, but from my understanding TreeFilters are in the responsibility of the API user, while it\'s the responsibility of the DirCacheIterator to decide what is relevant for the TreeWalk. I guess that in almost every case one will use DirCacheIterator(DirCache dc) constructor, so from API user\'s perspective current solution seems to be easier and safer.','AAALyn///aU=',1447,2,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheIterator.java','AAALyn///YI='),(525,51,'2010-09-01 14:28:10','P',1,'Done','AAALyn///UQ=',1447,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/AbstractTreeIterator.java','AAALyn///QY='),(525,1,'2010-08-31 19:31:39','P',1,'Style-nit: Trailing space.',NULL,1447,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/AbstractTreeIterator.java','AAALyn///UQ='),(536,51,'2010-09-01 14:28:10','P',1,'Done','AAALyn///UU=',1447,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/TreeWalk.java','AAALyn///QU='),(536,1,'2010-08-31 19:31:39','P',1,'I wouldn\'t rename this variable as part of this change.  You don\'t reference it any new code.  So as bad as the name might be, I don\'t see a compelling motivation to change these lines as part of this commit.\n\nWe really try to avoid editing lines we don\'t have to.  If you were actually using t as a parameter to isSkipCurrentEntry() then I might be willing to accept a rename of it as part of the same commit.  But since you don\'t need it, it doesn\'t make sense.',NULL,1447,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/TreeWalk.java','AAALyn///UU='),(166,1,'2010-09-01 22:18:20','P',1,'Also we really should apply the skipping / not ignored logic before ANY_DIFF, not after.  That way we don\'t look at paths that we aren\'t supposed to even care about.','AAALyn///PM=',1447,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyn///Ow='),(166,1,'2010-09-01 22:16:52','P',1,'s/1/INDEX/ ?',NULL,1447,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyn///PM='),(162,1,'2010-09-01 22:16:52','P',0,'I have to say I find this line amusing.  At least the class is deprecated and should die...  :-)',NULL,1447,4,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALyn///PQ='),(90,1,'2010-09-01 22:16:52','P',1,'We should also have a toString so printing a filter graph is semi-useful:\n\n  @Override\n  public String toString() {\n    return \"SkipWorkTree(\" + treeIdx + \")\";\n  }\n\nToday I wished we had it in the NotIgnoredFilter.  (I\'m writing up a change to add a toString() there right now...)',NULL,1447,4,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/filter/SkipWorkTreeFilter.java','AAALyn///PA='),(2,1,'2010-09-01 22:16:52','P',1,'Google owns me^Hmy work on JGit.',NULL,1447,4,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/filter/SkipWorkTreeFilter.java','AAALyn///PI='),(839,1,'2010-08-30 21:36:26','P',1,'Can we have a unit test to verify this works correctly?  I\'m especially concerned about regressions in the future so it would be nice if we have a test case that shows proper quoting.',NULL,1452,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Config.java','AAALyn///cw='),(11,46,'2010-09-01 07:18:08','P',1,'Done','AAALyn///WM=',1452,4,'/COMMIT_MSG','AAALyn///Q4='),(11,1,'2010-08-31 18:13:20','P',1,'Typo on invalid (you have \"inavlid\").',NULL,1452,4,'/COMMIT_MSG','AAALyn///WM='),(47,46,'2010-09-01 07:18:08','P',1,'Done','AAALyn///WI=',1452,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/ConfigTest.java','AAALyn///Q0='),(52,46,'2010-09-01 07:18:08','P',1,'Done','AAALyn///WE=',1452,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/ConfigTest.java','AAALyn///Qw='),(52,1,'2010-08-31 18:13:20','P',1,'If you look atRepositoryTestCase we flat out assert a very specific formatting for the entire file.  So for this we would say:\n\n  String exp = \"[testsection \\\"testsubsection\\\"]\\n\\ttestname=testvalue\\n\";\n  assertEquals(exp, config.toText());',NULL,1452,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/ConfigTest.java','AAALyn///WE='),(47,1,'2010-08-31 18:13:20','P',1,'Unfortunately the other tests are in a class called RepositoryConfigTest.  (Historical reasons.)\n\nI would support the idea of renaming that test class to ConfigTest, and then adding this new method to it.',NULL,1452,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/ConfigTest.java','AAALyn///WI='),(51,74,'2010-08-30 10:01:48','P',1,'I wonder if we should push this to Repository.isValidRefName as JGit would suffer from the same problem when using it pragmatically.',NULL,1453,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/ValidationUtils.java','AAALyn///g8='),(1055,1,'2010-08-30 21:34:34','P',1,'Nak.  \" is a valid name in a ref:\n\n  $ git check-ref-format \'refs/heads/foo\"bar\' && echo $?\n  0',NULL,1454,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/Repository.java','AAALyn///c4='),(81,44,'2010-08-30 14:41:38','P',1,'Done','AAALyn///gg=',1456,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/push/PushResultTable.java','AAALyn///f0='),(192,44,'2010-08-30 14:41:38','P',1,'Done','AAALyn///gQ=',1456,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/push/PushResultTable.java','AAALyn///fg='),(190,44,'2010-08-30 14:41:38','P',1,'Done','AAALyn///gM=',1456,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/push/PushResultTable.java','AAALyn///fk='),(188,44,'2010-08-30 14:41:38','P',1,'Done','AAALyn///gY=',1456,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/push/PushResultTable.java','AAALyn///fo='),(172,44,'2010-08-30 14:41:38','P',1,'Done','AAALyn///gc=',1456,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/push/PushResultTable.java','AAALyn///fs='),(93,44,'2010-08-30 14:41:38','P',1,'Done','AAALyn///gk=',1456,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/push/PushResultTable.java','AAALyn///fw='),(172,63,'2010-08-30 12:40:36','P',1,'Use StringBuilder instead.',NULL,1456,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/push/PushResultTable.java','AAALyn///gc='),(81,63,'2010-08-30 12:40:36','P',1,'Does this work on Windows? I\'m wondering if it would be more appropriate to use Text.DELIMITER instead.',NULL,1456,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/push/PushResultTable.java','AAALyn///gg='),(93,63,'2010-08-30 12:40:36','P',1,'Since images are being used now, these fields should be removed as they are no longer of any use.',NULL,1456,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/push/PushResultTable.java','AAALyn///gk='),(190,63,'2010-08-30 12:40:36','P',1,'If we trim trailing newlines, then wouldn\'t we get something like the following? It feels to me like there should be some additional division between the listing of the different repositories\' results.\n\nRepository XXX\n\nMessage\nRepository XXX\n\nMessage',NULL,1456,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/push/PushResultTable.java','AAALyn///gM='),(192,63,'2010-08-30 12:40:36','P',1,'I got some trailing whitespace here after a failed push because there were no additional messages. Do we need to trim again or is this intentional?',NULL,1456,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/push/PushResultTable.java','AAALyn///gQ='),(188,63,'2010-08-30 12:40:36','P',1,'Use StringBuilder instead.',NULL,1456,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/push/PushResultTable.java','AAALyn///gY='),(158,1,'2010-08-31 18:20:11','P',1,'Style-nit: The curly braces aren\'t necessary.\n\nI\'m going to cherry-pick this directly onto master, its a simple bug fix that I don\'t want to be held up on the DIRC version 3 code.',NULL,1466,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALyn///V8='),(86,74,'2010-09-01 22:20:09','P',1,'Would be cool if you can refactor this into a RepositoriesToggleBranchHierarchy.TOGGLE_STATE constant',NULL,1467,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/RepositoriesViewContentProvider.java','AAALyn///Ok='),(85,74,'2010-09-01 22:20:09','P',1,'Would be cool if you can refactor this into a RepositoriesToggleBranchHierarchy.ID constant',NULL,1467,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/RepositoriesViewContentProvider.java','AAALyn///Oo='),(65,4,'2010-08-31 20:43:13','d',1,'use org.eclipse.jgit.lib.Constants.CHARACTER_ENCODING instead',NULL,1476,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/blame/CopyModifiedSearchStrategyTest.java','AAALyn///Tk='),(120,4,'2010-08-31 20:49:19','d',1,'this looks like an uncorrelated change hence should probably go in a separate change',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/AddCommand.java','AAALyn///Tg='),(114,4,'2010-08-31 20:52:38','d',1,'typo in method name s/assing/assign/',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BlameCommand.java','AAALyn///TU='),(97,4,'2010-08-31 20:51:18','d',1,'user facing strings need to be externalized',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BlameCommand.java','AAALyn///TY='),(53,84,'2010-09-26 18:54:39','d',1,'Done','AAALyn///RU=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/BlameEntry.java','AAALy3///WI='),(88,8,'2010-12-30 14:09:20','P',1,'Avoid one multiply:int result = (guilty ? 1231 : 1237);;',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/BlameEntry.java','AAALyn///CY='),(53,1,'2010-09-01 00:17:00','P',1,'Please.  :-)  This shouldn\'t have public fields, but it should have public accessors.  Its OK for the fields to be package-access though, we do that in revwalk all of the time.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/BlameEntry.java','AAALyn///RU='),(53,84,'2010-09-26 21:57:52','d',1,'Done','AAALyn///Sg=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/CommonChunk.java','AAALy3///U8='),(53,1,'2010-09-01 00:17:00','P',1,'I wonder if this shouldn\'t just extend Edit and be a REPLACE of equal sizes on either side.  Might be too much of an abuse of an existing class.\n\nIf its not going to extend Edit, it should smell just like it.  getBeginA(), getBeginB() rather than getAstart().',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/CommonChunk.java','AAALyn///Sg='),(129,1,'2010-09-01 00:17:00','P',1,'This is going to be slow as snot.\n\nWhat you need to do here is use SimilarityIndex from the diff package.  Its not public, so you\'ll need to either use RenameDetector, or make SimilarityIndex public.  The latter might be better.\n\nCreate a SimilarityIndex for the current origin.  Then for each path the TreeWalk is providing you, create a SimilarityIndex and score it against the origin\'s SimilarityIndex.  If the score is over the threshold then its common enough to consider as a candidate.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/CopyModifiedSearchStrategy.java','AAALyn///Sc='),(73,1,'2010-09-01 00:17:00','P',1,'Should be configurable.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/CopyModifiedSearchStrategy.java','AAALyn///SI='),(69,1,'2010-09-01 00:17:00','P',1,'This score should be configurable.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/CopyModifiedSearchStrategy.java','AAALyn///SM='),(84,1,'2010-09-01 00:17:00','P',1,'You shouldn\'t cross pools like this.  That BlameWalk object I was talking about in the interface definition clearly needs a RevWalk too, so that classes like this can ensure the parents are parsed under the same revision pool as the source commit.\n\nWe\'ve already allocated the objects and setup pointers to the parents, we might as well just parse in-place and keep going rather than trying to create and destroy pools all of the time.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/CopyModifiedSearchStrategy.java','AAALyn///So='),(137,1,'2010-09-01 00:17:00','P',1,'Instead of doing this, maybe extend Origin class with a private static inner class here that has an additional score field.  For each path that scores above the threshold, create an instance of this subclass, put the score into it, and push that into a collection.\n\nIf we want a cap on the number of items we keep in the collection (I think here you want the two highest scoring paths yes?) then just use a TreeSet with a custom Comparator that knows how to look at that score field.  If the size of the set after adding the new Origin is larger than the threshold, remove the smallest item from the set.  Usually I hate using JRE collections classes in performance critical code, but here its a TreeSet of just 2-3 items.  Its not that bad.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/CopyModifiedSearchStrategy.java','AAALyn///SQ='),(106,1,'2010-09-01 00:17:00','P',1,'The better way to handle this section of code is:\n\n  while (treeWalk.next()) {\n    switch (treeWalk.getRawMode(0) & FileMode.TYPE_MASK) {\n    case TYPE_MISSING:\n    case TYPE_TREE:\n    case TYPE_GITLINK:\n      continue;\n    }\n\nThat also lets you avoid the isSubtree test above.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/CopyModifiedSearchStrategy.java','AAALyn///SU='),(133,1,'2010-09-01 00:17:00','P',1,'Ick.  Boxing integers on a custom list type?  Nak.  Boxing is expensive so we try to avoid it in these performance critical sections.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/CopyModifiedSearchStrategy.java','AAALyn///SY='),(57,84,'2010-09-26 19:19:42','d',1,'I\'ve kept this as a package-private representation of the diff algorithm required; LineDiffAdaptor can convert a now-standard diff algorithm to one that\'s used here.','AAALyn///Sk=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/IDiff.java','AAALy3///WE='),(57,1,'2010-09-01 00:17:00','P',1,'This should obviously be dropped.  If we\'re going to keep an abstract diff interface it should be in our diff package, not blame.  :-)',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/IDiff.java','AAALyn///Sk='),(58,84,'2010-09-26 22:17:00','d',1,'Done','AAALyn///S0=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/IOriginSearchStrategy.java','AAALy3///U4='),(58,1,'2010-09-01 00:17:00','P',1,'Since every Origin should be from the same Repository, and we are blaming a single file at hopefully high speed, we should actually be using a single ObjectReader for things like looking up the scapegoats.\n\nI think we should have a single object that represents the BlameWalk that carries the Repository and ObjectReader around to the various classes that need them.  So for the strategies we should be passing through the BlameWalk and the Origin, and the strategy can use the BlameWalk\'s ObjectReader to perform its reading work.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/IOriginSearchStrategy.java','AAALyn///S0='),(118,8,'2010-12-30 14:09:20','P',1,'@return doc doesn\'t match the description.\njavadocs need to be fixed up before merging to master',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Origin.java','AAAL0n///YI='),(71,84,'2010-09-26 21:53:23','d',1,'Done','AAALyn///Rw=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Origin.java','AAALy3///VA='),(103,84,'2010-09-26 21:52:53','d',1,'Done','AAALyn///TA=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Origin.java','AAALy3///VE='),(130,84,'2010-09-26 21:52:49','d',1,'Done','AAALyn///S8=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Origin.java','AAALy3///VI='),(184,8,'2010-12-30 14:09:20','P',1,'Strange, the \"else\" part is after the whole thing, though I see the general pattern that leads to this it is still quite tricky to read.\n\nif (filename == null)\n    return other.filename == null;\nelse\n    return filename.equals(other.filename)',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Origin.java','AAALyn///CI='),(181,8,'2010-12-30 14:09:20','P',1,'I think the whole if/else can be handled using just AnyObjectId here',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Origin.java','AAALyn///CQ='),(162,8,'2010-12-30 14:09:20','P',1,'just add or xor git object hashCodes into the hash since they are well distributed.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Origin.java','AAALyn///CU='),(71,1,'2010-09-01 00:17:00','P',1,'Please call this path.  Elsewhere in the diff package (e.g. DiffEntry) that\'s what we call it.  Likewise with TreeWalk.forPath().',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Origin.java','AAALyn///Rw='),(130,1,'2010-09-01 00:17:00','P',1,'Try to use getCachedBytes(int).  Assuming you can promise you won\'t edit it.  :-)',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Origin.java','AAALyn///S8='),(103,1,'2010-09-01 00:17:00','P',1,'This needs to use TreeWalk.forPath().  And translating IOException to a RuntimeException is bad.  :-)\n\nBut actually, this should be set in the constructor as a final field.  It appears to be known by anyone who constructs an origin, and its a performance sensitive thing to be able to respond with the ObjectId of the content.  (See OriginWalk findLastSameCommit.)',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Origin.java','AAALyn///TA='),(157,84,'2010-09-26 19:47:53','d',1,'Done','AAALyn///SA=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/OriginWalk.java','AAALy3///V0='),(167,84,'2010-09-26 19:47:52','d',1,'Done','AAALyn///R8=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/OriginWalk.java','AAALy3///V4='),(243,84,'2010-09-26 19:25:56','d',1,'Done','AAALyn///SE=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/OriginWalk.java','AAALy3///V8='),(229,84,'2010-09-26 19:23:19','d',1,'Done','AAALyn///Rk=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/OriginWalk.java','AAALy3///WA='),(209,1,'2010-09-01 00:17:00','P',1,'Should use TreeWalk.forPath().',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/OriginWalk.java','AAALyn///R0='),(202,1,'2010-09-01 00:17:00','P',1,'You shouldn\'t do this.  You can\'t start a RevCommit into a different pool than it was parsed out of.\n\nYou should be using the internal RevWalk of this class.  Just reset it, enqueue the start, and then run.\n\nBut this makes no sense.  Near as I can tell the walk is only used to parse other commits.  Its not actually used for a traversal.  So marking a starting point, or setting its sorting to TOPO is pointless.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/OriginWalk.java','AAALyn///R4='),(167,1,'2010-09-01 00:17:00','P',1,'Instead of implementing Iterator I\'d do what we do in RevWalk where next() returns null at end, and the Iterator returned by iterator() buffers by one in order to implement hasNext().',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/OriginWalk.java','AAALyn///R8='),(229,1,'2010-09-01 00:17:00','P',1,'Why do we need to expose this?',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/OriginWalk.java','AAALyn///Rk='),(239,1,'2010-09-01 00:17:00','P',1,'Why do we need to expose this?',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/OriginWalk.java','AAALyn///Ro='),(223,1,'2010-09-01 00:17:00','P',1,'I get what this method is doing.  Its a short-cut to try and skip through a chain of commits which haven\'t modified the file.  But its implementation is obtuse.  I wonder if we can\'t just leverage RevWalk to do it for us:\n\n  rw.markStart(origin.commit);\n  rw.setTreeFilter(TreeFilter.ANY_DIFF);\n  RevCommit r = rw.next();\n  rw.reset();\n  return r;\n\nIf that isn\'t fast enough to skip through the chain, we should try to fix RevWalk.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/OriginWalk.java','AAALyn///Rs='),(157,1,'2010-09-01 00:17:00','P',1,'I don\'t think we should use a copy here.  We should follow what RevWalk does which is to iterate exactly once, and provide an Iterator API only to provide a brain-dead simple use case.  If you need multiple traversals you should buffer the results yourself.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/OriginWalk.java','AAALyn///SA='),(243,1,'2010-09-01 00:17:00','P',1,'Since this owns a RevWalk, it needs a release() method that can release the contained RevWalk.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/OriginWalk.java','AAALyn///SE='),(63,84,'2010-09-26 22:35:39','d',1,'Done','AAALyn///TE=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Range.java','AAALy3///U0='),(63,1,'2010-09-01 00:17:00','P',1,'Elsewhere in JGit we often speak of ranges in terms of [start, end) and not [start, start + length).  Its probably a fair amount of code change to modify the semantics here, but I wonder if we shouldn\'t anyway.  Our Edit class for example in diff package uses [start, end) semantics.  And that\'s what we use in RawParseUtils for pretty much every parse function.  Etc.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Range.java','AAALyn///TE='),(64,84,'2010-09-26 20:11:46','d',1,'Done','AAALyn///S4=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/SameNameOriginSearchStrategy.java','AAALy3///Vs='),(56,84,'2010-09-26 20:01:04','d',1,'Done','AAALyn///Sw=',1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/SameNameOriginSearchStrategy.java','AAALy3///Vw='),(64,1,'2010-09-01 00:17:00','P',1,'Should use TreeWalk.forPath().',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/SameNameOriginSearchStrategy.java','AAALyn///S4='),(56,1,'2010-09-01 00:17:00','P',1,'This should have an instance singleton that we can use, rather than making callers create their own instance.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/SameNameOriginSearchStrategy.java','AAALyn///Sw='),(60,1,'2010-09-01 00:17:00','P',1,'If this is true (and I suspect it is) we need to clearly document that the owners of that code are OK with us relicensing to BSD.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Scoreboard.java','AAALyn///Rc='),(57,1,'2010-09-01 00:17:00','P',1,'This might be the main data structure, but its a horrible entry point.  We should make this package-private and wrap it up in a BlameWalk class or something easier to guess upon.  I just read almost every other class in this package wondering where the main driver was.  :-(',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Scoreboard.java','AAALyn///Rg='),(78,1,'2010-09-01 00:17:00','P',1,'We should also support taking in a starting and ending line number.  Callers might only need us to blame a particular region.  (Aka the -L flag on the command line.)  If we know the region we should be able to reduce the space we are initially pushing into the queue and terminate sooner.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Scoreboard.java','AAALyn///RM='),(99,1,'2010-09-01 00:17:00','P',1,'I know this is a tall order, but I want this incremental.\n\nThat is, we should have two public APIs here:\n\n  /**\n   * Fully blame a file and return the list sorted by lines.\n   * This method blocks until all lines have been covered.\n   */\n  List<BlameEntry> getBlame() {\n    List<BlameEntry> r = new ArrayList<BlameEntry>();\n    for (;;) {\n      List<BlameEntry> step = getNextBlame();\n      if (step == null)\n        break;\n      r.addAll(step);\n    }\n    Collections.sort(r, new Comparator<BlameEntry>(){\n      public int compare(BlameEntry a, BlameEntry b) {\n        return a.range.start - b.range.start;\n      }\n    });\n    return r;\n  }\n\n  /**\n   * Compute the blame for one portion of the file.\n   *\n   * This method returns as soon as one or more regions can be\n   * proven to be the responsibility of a particular origin (commit).\n   * The regions can be any part of the starting file, but will never\n   * overlap with a region previously returned, or that will be in on\n   * a future call.\n   */\n  List<BlameEntry> getNextBlame();\n\nThat way EGit can implement an incremental blame view like git gui does, and users can watch it fill in.  Obviously we\'ll run getNextBlame() on a background worker thread, but as soon as a block is ready we can forward it to the UI thread for painting.\n\nSince we have to have a queue anyway to keep track of the regions we have pushed off onto our parent, we can easily return back from getNextBlame() with the regions we couldn\'t blame onto the parent and that the current commit needs to take responsibility for.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Scoreboard.java','AAALyn///RQ='),(304,1,'2010-09-01 00:17:00','P',1,'Uh, yea, OK.  So my major problem here is the scoreboard and the OriginWalk are too disconnected from each other.\n\nOriginWalk is doing this nasty linearization of all Origins.  Which then leads to this sort of crap.  Its horrifically confusing.\n\nIMHO, OriginWalk should just be folded outright into this class.  The code should actually get a lot simpler because you stop trying to linearize the different origins.',NULL,1476,1,'org.eclipse.jgit/src/org/eclipse/jgit/blame/Scoreboard.java','AAALyn///RY='),(167,8,'2010-09-02 06:46:57','P',1,'This is not correct. Encodings can be resource specific. See GitDocument#populate and refactor the code for reuse here. Hopefully that code is better.\n\nTry this in JGit to find a couple of files with their own encodings:\n\ngrep ^encoding */.settings/org.eclipse.*',NULL,1479,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAALyn///Nc='),(151,8,'2010-09-02 06:46:57','P',1,'Format using Shift.Ctrl-F',NULL,1479,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAALyn///Ng='),(167,6,'2010-09-02 09:18:26','P',1,'That code in GitDocument#populate is in priciple way better. I missed to take into account encoding on file level. \n\nHowever, it still had a bug (if (charset != null)) and did not work for file encoding different.\n\nI fixed that bug and refactored it for reuse.','AAALyn///Nc=',1479,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAALyn///NI='),(151,6,'2010-09-02 09:18:26','P',1,'Done','AAALyn///Ng=',1479,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAALyn///NM='),(199,2,'2010-09-02 19:37:14','P',1,'Can you use ConfigConstants? And add streamfilethreshold to there too?',NULL,1494,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/WindowCacheConfig.java','AAALyn///Ic='),(199,1,'2010-09-02 19:38:59','P',1,'I hate ConfigConstants.  And none of the other constants here use it...  :-)','AAALyn///Ic=',1494,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/WindowCacheConfig.java','AAALyn///IQ='),(137,1,'2010-09-06 15:57:09','P',1,'Missing checkCallable();',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+80='),(282,1,'2010-09-06 15:57:09','P',1,'Missing checkCallable();',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+88='),(182,1,'2010-09-06 15:57:09','P',1,'Should support remote here too.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+8c='),(178,1,'2010-09-06 15:57:09','P',1,'Not an internal exception.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+8g='),(174,1,'2010-09-06 15:57:09','P',1,'Not an internal exception.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+8k='),(132,1,'2010-09-06 15:57:09','P',1,'You need to document that oldBranchName == null causes the current branch to be renamed.  This is really obtuse and nobody is going to know to do that.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+8o='),(320,1,'2010-09-06 15:57:09','P',1,'Missing checkCallable();',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+8s='),(185,1,'2010-09-06 15:57:09','P',1,'Need to handle LOCK_FAILURE, IO_FAILURE, REJECTED.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+8U='),(263,1,'2010-09-06 15:57:09','P',1,'Missing checkCallable();',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+8w='),(98,1,'2010-09-06 15:57:09','P',1,'This doesn\'t make sense.  We don\'t care about HEAD, unless HEAD is the branch being renamed.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+90='),(301,1,'2010-09-06 15:57:09','P',1,'You should overload this too:\n\n  public BranchCommand setObjectId(AnyObjectId id) {\n    checkCallable();\n    this.id = id.name();\n    return this;\n  }',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9A='),(206,1,'2010-09-06 15:57:09','P',1,'I\'m not sure suffixed is the right word for inserting a prefix.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9c='),(228,1,'2010-09-06 15:57:09','P',1,'You need to lookup the Ref after you\'ve updated or created it, because the Ref that is cached in the refUpdate is stale.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9E='),(157,1,'2010-09-06 15:57:09','P',1,'You also need to handle other types like LOCK_FAILURE, IO_FAILURE and REJECTED_CURRENT_BRANCH.\n\nYes, even though above you checked for what should be the REJECTED_CURRENT_BRANCH case, another thread might have changed HEAD in the meantime and JGit is going to check again during the delete invocation.  You need to handle that here.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9g='),(225,1,'2010-09-06 15:57:09','P',1,'You need to handle a lot more.  LOCK_FAILURE, IO_FAILURE.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9I='),(160,1,'2010-09-06 15:57:09','P',1,'I don\'t think this is necessarily an error.  The caller asked us to remove it.  Its gone.  If they really demand that we error out on this, maybe we have an optional flag that they should set:\n\n  setFailDeleteIfNotExisting()\n\nOr we should expose a Result type to the caller that they can examine, with two different results:\n\n  DELETED\n  DID_NOT_EXIST\n\nMost callers are just happy that the thing they asked to remove is in fact removed, and don\'t care how that happened.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9k='),(219,1,'2010-09-06 15:57:09','P',1,'Yes',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9M='),(111,1,'2010-09-06 15:57:09','P',1,'Do not assign null here.  The compiler should (correctly) error and refuse to compile the class if the try block below does not assign a value before return.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9o='),(214,1,'2010-09-06 15:57:09','P',1,'Also not an internal exception.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9Q='),(150,1,'2010-09-06 15:57:09','P',1,'Yes.  You cannot delete the branch that HEAD has checked out right now.  The caller should instead detached HEAD, or checkout a different branch first.  This is probably a new top-level exception type for us, I can\'t think of an existing error type that makes sense to use.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9s='),(211,1,'2010-09-06 15:57:09','P',1,'This isn\'t an internal exception.  It should be a proper top-level API error that callers should check for and expect.  Don\'t we already have one for TagCommand?  There we throw InvalidTagNameException.  So we need InvalidBranchNameException.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9U='),(148,1,'2010-09-06 15:57:09','P',1,'You shouldn\'t need to resolve HEAD to delete a branch that isn\'t HEAD.',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9w='),(208,1,'2010-09-06 15:57:09','P',1,'If remote is true, should we use R_REMOTES instead?',NULL,1497,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALyn//+9Y='),(50,1,'2010-09-06 16:40:12','P',1,'Yes, many of these tests should produce identical results under MyersDiff.  We should take your Diff abstraction idea and abstract both implementations, then do a common base test suite that provides most of these tests and use two subclasses to drive them for each implementation.\n\nBut a few of these, especially testEdit_NoUniqueMiddleSideA and B variants are specific to the current implementation of PatienceDiff not having a fallback.  MyersDiff shouldn\'t have the same results here.  And neither would a PatienceDiff that had an actual fallback for the degenerate case these represent.','AAALyn//+8I=',1499,6,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/PatienceDiffTest.java','AAALyn//+7Q='),(50,5,'2010-09-06 16:20:30','P',1,'A lot of these testcases make also sense for MyersDiff, right? If we would have the abstraction for DiffAlgorithms we could reuse. But I know: some of the test\'s are specific to PatienceDiff.',NULL,1499,6,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/PatienceDiffTest.java','AAALyn//+8I='),(154,1,'2010-09-06 16:40:12','P',1,'The diff() method is recursive.  When we recurse on the left and right halves, both halves are required to each produce at least one Edit result.\n\nRather than doing:\n\n  EditList r = new EditList();\n  r.addAll(diff(... before half ...));\n  r.addAll(diff(... after half ...));\n  return r;\n\nAnd having this nasty continuous recopying of data from one result list to another as we pop back up the call stack, we insert the edits in-place into the diff instance.  That way the list isn\'t copied on each recursive invocation.\n\nI can\'t say I\'ve optimized the code as well as we can do yet, but I was trying to avoid memory allocations and excessive copying inside the main loop.','AAALyn//+8M=',1499,6,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiff.java','AAALyn//+7I='),(105,1,'2010-09-06 16:40:12','P',1,'Yup, agree fully.  I\'ll work up a DiffAlgorithm abstraction as a predecessor of this change and post it for review soon.','AAALyn//+8Y=',1499,6,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiff.java','AAALyn//+7M='),(154,5,'2010-09-06 16:20:30','P',1,'Why do we have this field? I don\'t see any use of this field anymore if only diff() would return such an EditList',NULL,1499,6,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiff.java','AAALyn//+8M='),(105,5,'2010-09-06 16:20:30','P',1,'Super small diff algorithm. I like it.\n\nBut a more general question: I guess that in the end we want to configure which diff algorithm to use. It would be nice to have a silver bullet fitting all situations ... but that\'s not so likely, or? Even a patience diff sometimes wants to fall back to other diffs.\n\nSo, isn\'t it time for a DiffAlgorithm abstraction? Some common superclass of PatienceDiff and MyersDiff? And e.g. PatienceDiff would get an DiffAlgorithm as constructor parameter so it knows to which algorithm to fall back to?',NULL,1499,6,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiff.java','AAALyn//+8Y='),(163,5,'2010-09-06 16:20:30','P',1,'If we want that this core algorithm stays maintainable we should add at least documentation for the three main entrypoints scanA, scanB and match. I know they are not public ... but I had a hard time understanding',NULL,1499,6,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiffIndex.java','AAALyn//++I='),(134,5,'2010-09-06 16:20:30','P',1,'Shouldn\'t the first parameter be called \'b\'. That would be more symmetric to scanA().',NULL,1499,6,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiffIndex.java','AAALyn//++U='),(163,1,'2010-09-06 16:40:12','P',1,'OK, will document.','AAALyn//++I=',1499,6,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiffIndex.java','AAALyn//+7A='),(134,1,'2010-09-06 16:40:12','P',1,'Good point, thanks.  I\'ll rename it.','AAALyn//++U=',1499,6,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiffIndex.java','AAALyn//+7E='),(158,5,'2010-09-02 21:21:11','P',1,'Yes, Myers does use the term distance - but not for the length of regions. It is used in the context of \"edit distances\". One reason more not to call it distance here.','AAALyn///KI=',1501,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/Edit.java','AAALyn///JY='),(158,1,'2010-09-02 18:20:24','P',1,'It may be that the Myers paper uses distance, but that\'s not where I got it from.  I like Christian\'s wording better.  I\'ll amend the comment.','AAALyn///Mc=',1501,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/Edit.java','AAALyn///KI='),(128,1,'2010-09-02 18:20:24','P',1,'Right.  Because isEmpty() is declared final, it should be able to be inlined by the complier and later by the JIT without any larger analysis work being required.  Since the expression is so trivial, it should be a really good candidate for the inlining.  4 loads and 2 compares is bordering on the cost of the method call enter/exit, so it really should inline.\n\nBut, in reality, I wasn\'t thinking too much about performance here.  I just selected the expression and did Refactor > Extract Method in Eclipse and moved on.  The getType() method isn\'t very fast to begin with.  Its coded more for readability than it is for speed.  I think there may be some redundant compares occurring for some code paths.  If I cared a lot about the performance of this function I would probably redo how some of these compares occur.\n\nI did the extraction of the method because I was planning on using isEmpty() inside patience diff.  But I later concluded that was foolish.  The place I wanted it was part of the critical path of patience diff, but I proved to myself that at that point in the code isEmpty() is always false.  Therefore the call was unnecessary and I backed out of it.  But I forgot to undo this refactoring.','AAALyn///Ms=',1501,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/Edit.java','AAALyn///KM='),(158,8,'2010-09-02 12:56:47','P',1,'I think distance is the term used in the paper that describes our diff algorithm','AAALyn///Mo=',1501,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/Edit.java','AAALyn///Mc='),(163,5,'2010-09-02 12:09:45','P',1,'see getLengthA comment',NULL,1501,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/Edit.java','AAALyn///Mk='),(158,5,'2010-09-02 12:09:45','P',1,'Why not stick to the term \'length\'. Something like \'return the length of the region in A\' is for me easier to understand then introducing \'distance\'.',NULL,1501,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/Edit.java','AAALyn///Mo='),(128,5,'2010-09-02 12:09:45','P',1,'Surprising to me you suggest this. I guess you spent this method call because you know for sure the call comes for free because of inlining. Right?',NULL,1501,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/Edit.java','AAALyn///Ms='),(183,5,'2010-09-02 13:41:36','P',1,'Somehow odd to ask the comparator and not the object itself about the size.',NULL,1502,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/MyersDiffPerformanceTest.java','AAALyn///MM='),(57,5,'2010-09-02 21:59:02','P',1,'Ok, I got your two arguments of performance and default implementations. Having interfaces for Sequence and DiffComparator would allow us to have single classes which implement both (like standard java where equals and hash are in every (model) class). This would help writing smaller tests - but in real code we would really want seperate implementations for Sequence and DiffComparator. So, runtime-performance argument beats smaller-tests - I am fine with the abstract class.','AAALyn///Jc=',1502,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffComparator.java','AAALyn///Hc='),(58,5,'2010-09-02 21:59:02','P',1,'I agree, hash and equivalence are tied so strongly together that they have to be implemented in the same class. Maybe it\'s just the class name which disturbed me: a comparator which offers functionalities working on a single object (not comparing two objects). But since hashes may be needed for efficient equivalence calculation I am convinced.','AAALyn///JI=',1502,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffComparator.java','AAALyn///Ho='),(57,1,'2010-09-02 19:15:26','P',1,'Interfaces are slower to perform virtual dispatch than classes, because their virtual function tables are more complicated to layout.  Yes some of the JVMs have gotten better about it, but they still have to pay some penalties that don\'t exist with an abstract base class.\n\nMy other rationale is I want to add some default behavior to this class later.  Like in the patience diff patch I add reduceCommonStartEnd().  It has a default implementation based upon equals() but will later be replaced for the RawTextComparator with something that is more tightly tied to the representation.\n\nMaking the comparator an abstract class means we can later shift other logic into this class to support diff algorithms, and once we do that comparator implementors have a choice of using our naive equals() based approaches, or doing something even faster with their own sequence models, if they can support it.','AAALyn///MI=',1502,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffComparator.java','AAALyn///Jc='),(58,1,'2010-09-02 19:15:26','P',1,'I\'ll agree with you that size() seems misplaced.  It probably is.  I can bring back Sequence and put size on it.\n\nBut hash() is part of the equivalence function.  The hash computed by ignore trailing whitespace is different than the hash computed by the default ignore-nothing.  If two items in the sequence are equal by the equals() function, their hashes must also be equal.  Putting hash() on the model starts to make it much harder to ensure this remains true.\n\nI also didn\'t want to enforce the requirement that the hash be pre-computed by the sequence model.  Instead I wanted to allow the equivalence function to handle the hash.  If it caches the hashes in the model (like RawText does), great.  But I think in the case of patience diff I might be able to only get the hash once for each line.  That means the implementor might be able to avoid keeping the hashes, and perhaps more importantly, avoid computing them for the long common header/footers that often exist on files.\n\nSo I don\'t think we should move hash.','AAALyn///MU=',1502,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffComparator.java','AAALyn///JI='),(57,5,'2010-09-02 13:41:36','P',1,'Any reason for not using an interface?',NULL,1502,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffComparator.java','AAALyn///MI='),(58,5,'2010-09-02 13:41:36','P',1,'Isn\'t this class doing more then a comparator? This class tells us about sizes and hashes - things which have nothing to do with comparision. I don\'t expect them in a comparator.\n\nI agree that we need a Comparator concept (also because of the auto-CRLF stuff). But shouldn\'t we leave aspects which belong to one Diff-able object in a seperate class/interface? Something which was previously called Sequence.\n\nSomething like\n\nabstract class DiffComparator<S extends Sequence> {\n  public abstract boolean equals(S a, int ai, S b, int bi);\n}\n\nabstract class Sequence {\n  public abstract int size();\n  public abstract int hash(int ptr);\n}',NULL,1502,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffComparator.java','AAALyn///MU='),(105,1,'2010-09-06 20:44:13','P',1,'We currently do use the hashes collection, the RawTextComparator implementations reach inside and read it directly.  But I see your point.\n\nI think removing it is going to be a bit more work than I\'d like to squash into this refactoring change, so I\'d like to actually defer it until after we have PatienceDiff in.  Some of the optimizations I\'d like to do is to avoid computing the hashes for the ranges we don\'t care about (basically do it after common header/footer elimination... aka step 1 of patience diff).','AAALyn///Cg=',1502,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawText.java','AAALy3////4='),(105,5,'2010-09-06 21:31:13','P',1,'I agree, let\'s defer that until we have patience diff in.\n\nOne comment about avoiding calculating unneeded hashes: I think that diff algorithms know what hashes they\'ll need and they should trigger the calculation, right?','AAALy3////4=',1502,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawText.java','AAALy3////k='),(105,1,'2010-09-06 22:43:02','P',1,'Yes.  The diff implementation knows the hashes it needs.\n\nActually what I\'m planning on doing is removing the hashes collection altogether from the RawText object and making the diff implementation cache it.  Then RawTextComparator\'s hash method stops looking inside of RawText.hashes and instead computes the hash on the fly.\n\nFor PatienceDiff this means we\'ll hash the lines after we\'ve narrowed the file down by skipping common headers and footers, and then we\'ll keep those hash arrays throughout the execution of the diff.\n\nFor MyersDiff, I think its the same thing.  Only right now its probably not doing the common header/footer elimination.\n\nLonger term, I might be changing PatienceDiff to actually construct the hashes table by assigning a unique int to each unique line.  Doing so by hashing both A and B into a single hashtable, and if its the first occurrence of that element, assign it a new unique value.  This way later on we can do compares during the recursive steps by just int equality and bypass the DiffComparator altogether.','AAALy3////k=',1502,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawText.java','AAALy3////Q='),(105,5,'2010-09-04 08:33:01','P',1,'We accept a comparator here which we don\'t store but only once\nuse in this Constructor. We use it only to fill hashes ... which is\nagain not used anymore, or? Why don\'t we skip the comparator and remove hashes and computeHashes?',NULL,1502,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawText.java','AAALyn///Cg='),(65,1,'2010-09-06 20:44:13','P',1,'Good point.  I\'ll drop the last sentence.','AAALyn///Ck=',1502,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/SequenceComparator.java','AAALy3////8='),(65,5,'2010-09-04 08:33:01','P',1,'Why do we have this comment here: it is explicitly permissible to do something but callers should be smart enough not to do it. Do we really want to save one if in the implementations? If it brings huge performance gains I could unterstand, but not if it is e.g. not measurable in our tests',NULL,1502,4,'org.eclipse.jgit/src/org/eclipse/jgit/diff/SequenceComparator.java','AAALyn///Ck='),(1,46,'2010-09-02 15:33:58','P',1,'I did it again... Sorry.','AAALyn///Lk=',1504,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/prefpages/TraceConfigurationPageTest.java','AAALyn///K4='),(1,2,'2010-09-02 15:25:50','P',1,'Add a license header please...',NULL,1504,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/prefpages/TraceConfigurationPageTest.java','AAALyn///Lk='),(85,46,'2010-09-02 15:33:58','P',1,'No. I\'ll create a separate change.','AAALyn///Lo=',1504,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewBranchHandlingTest.java','AAALyn///Kw='),(85,2,'2010-09-02 15:25:50','P',1,'Is this related to this change?',NULL,1504,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewBranchHandlingTest.java','AAALyn///Lo='),(159,4,'2010-09-06 23:11:24','P',1,'this fails on Mac since there preferences are under Eclipse > Preferences ..., see [1] how to fix that.\n\n[1] http://egit.eclipse.org/r/#patch,unified,1520,2,org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/prefpages/configuration/GlobalConfigurationPageTest.java',NULL,1504,2,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/prefpages/TraceConfigurationPageTest.java','AAALy3///+4='),(159,74,'2010-09-06 23:15:32','P',1,'Please use API for this, see http://egit.eclipse.org/r/#patch,sidebyside,1530,2,org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/prefpages/configuration/GlobalConfigurationPageTest.java','AAALy3///+4=',1504,2,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/prefpages/TraceConfigurationPageTest.java','AAALy3///+s='),(182,1,'2010-09-02 22:19:39','P',1,'This is actually a horrible input for PatienceDiff, and the result is D (length of the edit script) is always exactly 1... a full replace.\n\nThe problem stems from PatienceDiff needing to locate a unique common point within each segment.  The generated input is segments of single characters, which wind up repeating and being not-unique anymore.  This is a corner case that PatienceDiff falls down on.  Consequently MyersDiff produces actual edits and PatienceDiff doesn\'t.\n\nI\'ll try to come up with a better input.',NULL,1505,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/MyersDiffPerformanceTest.java','AAALyn///HE='),(170,1,'2010-09-02 22:19:39','P',1,'Myers promises to run in O(N * D), where N is the sum of the lengths of A and B, and D is the size of the minimum edit script.  I don\'t think this is true for the current PatienceDiff implementation.\n\nIn particular there is a sorting step during each recursion.  But if I\'m thinking it through correctly, PatienceDiff\'s running time should be bounded by the size of the inputs, around O(A log A + B log B + D) =~ O(N log N + D).  That matches with a variation of Myers\' algorithm that uses suffix trees.\n\nI _think_ O(N log N + D) is going to be faster than O(N * D), but if N is really big, log N could easily exceed D.  :-)',NULL,1505,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/MyersDiffPerformanceTest.java','AAALyn///HI='),(65,1,'2010-09-02 22:19:39','P',1,'Should we rename the class to DiffPerformanceTest?',NULL,1505,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/MyersDiffPerformanceTest.java','AAALyn///HM='),(252,5,'2010-09-08 12:47:34','P',1,'Oops, sorry. You are right. I approved this comment - so the println should be out. I\'ll do it',NULL,1505,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/DiffPerformanceTest.java','AAALy3///58='),(252,5,'2010-09-08 12:41:57','P',1,'Yes, you are right, these line shouldn\'t be in. But this println is already commented with \"to be removed\". Currently we really want this output in our local versions because we are very interested in those values during performance optimizations. But in the end these lines should be removed.','AAALy3///9Y=',1505,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/DiffPerformanceTest.java','AAALy3///6E='),(252,15,'2010-09-07 10:31:46','P',1,'Forgotten debug call?',NULL,1505,4,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/DiffPerformanceTest.java','AAALy3///9Y='),(181,5,'2010-09-25 21:57:29','P',1,'Yes I have: the measured runtime behaviour of HistogramDiff doesn\'t match our expectations. The error message looks frightening - but in fact it tells very explicitly what went wrong.\n\nHere is what is happing: In testHistogram() you told the testFramework to feed example-texts of different sizes (beginning with 10.000 up to 1.280.000) to HistogramDiff. For each run we measure how much CPUTime is used to calculate the diff. With that we calculate different \"performance indexes\". The index \"perf1\" is perf1=cpuTime/(N*D) and perf2=cpuTime/(N*D*D). We are not interested in the actual values of this indexes - but a algorithm which is expected to have a runtime behaviour of O(N*D) the index perf1 should be quite constant. And for O(N*D) algorithms perf2 should be constant.\"quite constant\" means: max(perfX)/min(perfX) must be less a given constant.\n\nYou said in testHistogram() that HistogramDiff should behave like a O(N*D) algorithm (because you check for perf1()) and that max/min should not be more than 15 (maxfactor). But perf1() decreases!!!! with longer texts. Means: the algorithms behaves with our test data better then a O(N*D) algorithm. Hhmmm, good result, but can it be true? I am sure we depend on N - but is the number of differences really influencing our performance so much?\n\nWhat we can do is to increasing the accepted factor (maxfactor) to more than 20 ... or calculate a different performance index (e.g. t/(n*log(d))) and see whether we have like that kind of algorithm.','AAALy3///Wo=',1505,12,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/DiffPerformanceTest.java','AAALy3///Wg='),(181,1,'2010-09-25 02:16:43','P',1,'This test is failing:\n\njunit.framework.AssertionFailedError: minimun and maximum of performance-index t/(N*D) differed too much. Measured factor of 20.26732580423589 (maxFactor=15). Perfdata=<[testHistogram 10000 bytes took 2879800 ns. N=20000, D=18, time/(N*D):8E0, time/(N*D^2):4.44E-1, testHistogram 20000 bytes took 8130200 ns. N=40000, D=36, time/(N*D):5.65E0, time/(N*D^2):1.57E-1, testHistogram 40000 bytes took 18798500 ns. N=80000, D=70, time/(N*D):3.36E0, time/(N*D^2):4.8E-2, testHistogram 80000 bytes took 48076800 ns. N=160000, D=143, time/(N*D):2.1E0, time/(N*D^2):1.47E-2, testHistogram 160000 bytes took 96502500 ns. N=320000, D=287, time/(N*D):1.05E0, time/(N*D^2):3.66E-3, testHistogram 320000 bytes took 257217700 ns. N=640000, D=574, time/(N*D):7E-1, time/(N*D^2):1.22E-3, testHistogram 640000 bytes took 780854428 ns. N=1280000, D=1148, time/(N*D):5.31E-1, time/(N*D^2):4.63E-4, testHistogram 1280000 bytes took 2317911000 ns. N=2560000, D=2294, time/(N*D):3.95E-1, time/(N*D^2):1.72E-4]>\n\nand I don\'t know why. Christian, do you have any ideas?',NULL,1505,12,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/DiffPerformanceTest.java','AAALy3///Wo='),(181,1,'2010-10-09 06:08:13','P',1,'Thanks for that explanation.\n\nThe algorithm is absolutely O(N*D)... worst case, which is what big-O notation means.  :-)  In the worst case the input consists of N unique elements, and the difference between A and B is B inserts a new element between each element of A.  This means we\'ll have an edit list of D = N/2, and HistogramDiff splits and recurses D times, with each recursion looking at N-2 elements from the higher level.\n\nThis doesn\'t happen often fortunately.  Even in our contrived DiffTestDataGenerator we don\'t see this sort of input.  In the contrived test data we have a number of unique elements that can be hashed and located efficiently (since they are just primitive char).  Because there is no fallback, we only match on the common low-occurrence elements, which are quickly found in the hashtable.  Because there are so few of these, D is practically constant, and our run time during this test probably behaves more like O(N) time.\n\nThe more that I think about it, the more that I\'m uncertain we should even have this test.  We don\'t really change MyersDiff that often.  Testing for algorithm correctness is sufficient.  If we are really meddling with the algorithm, we should be running it against real data sets like linux-2.6.git to see if there is a performance difference on real-world inputs, not contrived cases.  Our DiffAlgorithm implementations are designed to run well on human written source code.  They are designed to run no worse than O(N * D) on all inputs.  The latter I\'m willing to prove theoretically rather than rely on a benchmark.  The former can only be well established by periodically running the tests over some real-world corpuses that people actually care about.\n\nSo I think I\'ll try to write a new test program similar to TextHashFunctions, but to exercise our DiffAlgorithms instead of line-level hash routines.','AAALy3///Wg=',1505,12,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/DiffPerformanceTest.java','AAALy3//+9E='),(12,4,'2010-09-03 00:07:40','P',1,'s/does the user/users/',NULL,1507,1,'/COMMIT_MSG','AAALyn///Gc='),(11,4,'2010-09-03 00:07:40','P',1,'s/checked button/checked filter toggle button/',NULL,1507,1,'/COMMIT_MSG','AAALyn///Gg='),(26,4,'2010-09-03 00:07:40','P',1,'File the bug and put a link here',NULL,1507,1,'/COMMIT_MSG','AAALyn///GQ='),(20,4,'2010-09-03 00:07:40','P',1,'start a new paragraph here',NULL,1507,1,'/COMMIT_MSG','AAALyn///GU='),(18,4,'2010-09-03 00:07:40','P',1,'this sentence is broken',NULL,1507,1,'/COMMIT_MSG','AAALyn///GY='),(307,6,'2010-09-06 08:57:32','P',1,'Typo: Muti',NULL,1507,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/UIText.java','AAALyn//+/w='),(109,6,'2010-09-06 08:57:32','P',1,'Typo: Muti',NULL,1507,5,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyn//+/s='),(110,49,'2010-09-04 18:15:32','d',1,'Done','AAALyn///BU=',1512,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeSubscriber.java','AAALyn///BE='),(110,74,'2010-09-04 17:19:32','P',1,'Please don\'t leave commented code in the code base',NULL,1512,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariantTreeSubscriber.java','AAALyn///BU='),(11,49,'2010-09-06 21:25:45','P',1,'Done','AAALyn//+/E=',1512,2,'/COMMIT_MSG','AAALy3////w='),(11,6,'2010-09-06 11:26:25','P',1,'Typo: ...SyncInfo class  which uses...',NULL,1512,2,'/COMMIT_MSG','AAALyn//+/E='),(17,6,'2010-09-09 12:13:09','P',1,'the user instead of used',NULL,1512,4,'/COMMIT_MSG','AAALy3///1M='),(14,6,'2010-09-09 12:13:09','P',1,'determines instead of determinate',NULL,1512,4,'/COMMIT_MSG','AAALy3///1Q='),(11,6,'2010-09-09 12:13:09','P',1,'determine instead of determinate',NULL,1512,4,'/COMMIT_MSG','AAALy3///1U='),(17,49,'2010-09-09 18:21:50','P',1,'Thank you ;)\n\nDone','AAALy3///1M=',1512,4,'/COMMIT_MSG','AAALy3///zQ='),(14,49,'2010-09-09 18:21:50','P',1,'Thank you ;)\n\nDone','AAALy3///1Q=',1512,4,'/COMMIT_MSG','AAALy3///zU='),(11,49,'2010-09-09 18:21:50','P',1,'Thank you ;)\n\nDone','AAALy3///1U=',1512,4,'/COMMIT_MSG','AAALy3///zY='),(77,6,'2010-09-09 12:13:09','P',1,'I think we should also exclude the Java workspace model: org.eclipse.jdt.ui.modelProvider. It also operates on the local workspace.\n\nWhat do you think about returning only GitChangeSetModelProvider if !gsd.shouldIncludeLocal() and not filtering out a predefined list?',NULL,1512,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitModelSynchronizeParticipant.java','AAALy3///1Y='),(77,49,'2010-09-09 18:21:50','P',1,'Yes, returning only GitChangeSerModelProvider when !gsd.shouldIncludeLocal()  seams to be reasonable.','AAALy3///1Y=',1512,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/GitModelSynchronizeParticipant.java','AAALy3///zM='),(149,74,'2010-09-04 15:43:59','P',1,'Done','AAALyn///DY=',1514,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/SelectSynchronizeResourceDialog.java','AAALyn///B8='),(147,74,'2010-09-04 15:43:59','P',1,'Done','AAALyn///DU=',1514,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/SelectSynchronizeResourceDialog.java','AAALyn///CA='),(126,74,'2010-09-04 15:43:59','P',1,'Done','AAALyn///DQ=',1514,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/SelectSynchronizeResourceDialog.java','AAALyn///CE='),(126,49,'2010-09-03 23:15:29','P',1,'Actually Benjamin has already fixed an typo in SyncRepoEntity and I don\'t see any reasons why fixing this typo should be made in a separate commit.','AAALyn///Fs=',1514,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/SelectSynchronizeResourceDialog.java','AAALyn///DQ='),(147,49,'2010-09-03 23:15:29','P',1,'In my humble opinion we should break for if we find first occurrence of DEFAULT_REMOTE_NAME. I did not really get why we should iterate more and finding next one.',NULL,1514,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/SelectSynchronizeResourceDialog.java','AAALyn///DU='),(149,49,'2010-09-03 23:15:29','P',1,'fix code convention issue - we don\'t use brackets if there is only a single statement inside if, else, for and while',NULL,1514,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/SelectSynchronizeResourceDialog.java','AAALyn///DY='),(149,4,'2010-09-03 09:44:22','P',1,'wouldn\'t it be better to also return the first entry instead of empty string in case there are multiple entries but none named \"origin\" ?',NULL,1514,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/SelectSynchronizeResourceDialog.java','AAALyn///F0='),(126,4,'2010-09-03 09:44:22','P',1,'the method name is scrambled\n\ns/setDefautlValue/setDefaultValue/',NULL,1514,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/SelectSynchronizeResourceDialog.java','AAALyn///F4='),(149,6,'2010-09-03 09:48:32','P',1,'I also thought about this but I think that no: If there is no obvious choice that user should be made aware of the fact that a decision has to be made.','AAALyn///F0=',1514,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/SelectSynchronizeResourceDialog.java','AAALyn///Fo='),(126,6,'2010-09-03 09:48:32','P',1,'But it had been scrambled already before. I would say that that should be fixed in another commit.','AAALyn///F4=',1514,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/SelectSynchronizeResourceDialog.java','AAALyn///Fs='),(142,4,'2010-09-08 20:15:45','d',1,'Done','AAALyn///As=',1514,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/SelectSynchronizeResourceDialog.java','AAALy3///4U='),(142,49,'2010-09-04 20:08:19','P',1,'Those brackets can be also removed and default repo name can be returned immediately.',NULL,1514,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/SelectSynchronizeResourceDialog.java','AAALyn///As='),(96,74,'2010-09-04 16:42:45','P',1,'Done, even though using AbbreviatedObjectId is a little more expensive as we need to acquire a ObjectReader for every commit. We can\'t cache it as the labelprovider is used for several repositories in the sync view.','AAALyn///Fg=',1515,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/mapping/GitChangeSetLabelProvider.java','AAALyn///Bs='),(96,4,'2010-09-03 10:00:41','P',1,'would be better to use AbbreviatedObjectId which can ensure that abbreviated IDs are unique within the repo',NULL,1515,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/mapping/GitChangeSetLabelProvider.java','AAALyn///Fg='),(862,74,'2010-09-04 16:46:33','P',1,'Done','AAALyn///FY=',1516,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyn///Bg='),(862,4,'2010-09-03 11:14:28','P',1,'key is mangled\ns/Chnages/Changes/',NULL,1516,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyn///FY='),(129,1,'2010-09-03 14:22:12','P',1,'Obviously we don\'t want to remove these tests.  This is temporary just to make it easier to understand the performance impacts of changes made to PatienceDiff.',NULL,1523,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/DiffPerformanceTest.java','AAALyn///E8='),(444,1,'2010-09-03 14:22:12','P',1,'FWIW, I tried caching the results of isUnique in a record.  Once we know a record is unique within a particular index segment, it will remain unique for the rest of the recursive steps that contain the record, because each step is splitting the index in half (or even smaller).\n\nThe caching worked by shifting the element position up 1 bit and OR\'ing in 1 as soon as we found the element was unique.  The start of the method then became:\n\n  if ((rec & 1) != 0)\n   return true;\n\nThis turned out to be slower on every system I tried it on, but I suspect its artificial due to the type of Sequence being used by the performance test.  equals() on that char[] based sequence used by the test is insanely fast.  equals() on a larger line input like RawText uses is a lot slower.  We should revisit this caching concept by testing on a more common input.',NULL,1523,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiff.java','AAALyn///E0='),(320,1,'2010-09-03 14:22:12','P',1,'This split function should be combined with its sibling, splitIndexB.  Its a massive amount of complex code that is duplicated between the two.',NULL,1523,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiff.java','AAALyn///E4='),(440,1,'2010-09-03 14:22:12','P',1,'Right now I suspect this is why we are losing so badly to MyersDiff.  Sorting the lines is O(N log N).  MyersDiff is able to run in O(N) time.  Switching this to being a hashtable and trying to get O(N) construction time may help things considerably.',NULL,1523,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiff.java','AAALyn///Es='),(240,1,'2010-09-03 14:22:12','P',1,'Once we know that an item is a match point that isn\'t contained within another match point, its going to be a match point in any recursive step we run.\n\nI tried caching the Edit here indexed by bOf(rec), so that on recursive steps we didn\'t need to redo the stretching of a match to determine its total length.  Unfortunately that proved to be slower than not caching at all.  Like the isUnique() caching below I think this is being caused by the input sequence having too cheap of an equals() method.\n\nFWIW, I tried caching in a HashMap<Integer,Edit>, and also in a sorted list of Edit (sorted by startB).  The latter seemed like a good idea because the match list is already sorted, so we could merge-join the two lists together in this loop.  I suspect the caching was slower because of the amount of memory being allocated to track the Edit instances.\n\nSo then I went and removed use of Edit for region and index throughout the code, so that we didn\'t do memory allocations at all.  That was even slower than using the Edit instances, as apparently pushing 8 ints onto the call stack during each frame activation was slower than allocating the two objects and pushing only those two references onto the stack.  Yuck.',NULL,1523,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiff.java','AAALyn///Ew='),(9,6,'2010-09-06 11:51:43','P',1,'Typo: NotIgnoredFilter',NULL,1535,1,'/COMMIT_MSG','AAALyn//++8='),(9,49,'2010-09-06 11:57:31','d',1,'Done','AAALyn//++8=',1535,1,'/COMMIT_MSG','AAALyn//++w='),(97,4,'2010-09-06 16:13:48','d',1,'typo s/childen/children/',NULL,1537,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyn//+7g='),(95,4,'2010-09-06 16:13:27','d',1,'typo s/Resoource/Resource/',NULL,1537,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyn//+7k='),(93,4,'2010-09-06 16:13:17','d',1,'typo s/Resoource/Resource/',NULL,1537,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyn//+7o='),(91,4,'2010-09-06 16:13:13','d',1,'typo s/Resoource/Resource/',NULL,1537,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyn//+7s='),(89,4,'2010-09-06 16:12:27','d',1,'typo s/childen/children/',NULL,1537,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAALyn//+7w='),(70,4,'2010-09-07 23:21:54','P',1,'first ? probably you meant second ...',NULL,1547,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffAlgorithm.java','AAALy3///+k='),(70,1,'2010-09-10 22:09:40','P',1,'Done','AAALy3///+k=',1547,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffAlgorithm.java','AAALy3///wo='),(229,1,'2010-09-08 04:58:02','P',1,'Missing checkCallable()',NULL,1550,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/FetchCommand.java','AAALy3///7c='),(208,1,'2010-09-08 04:58:02','P',1,'Missing checkCallable()',NULL,1550,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/FetchCommand.java','AAALy3///7g='),(190,1,'2010-09-08 04:58:02','P',1,'Missing checkCallable()',NULL,1550,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/FetchCommand.java','AAALy3///7k='),(165,1,'2010-09-08 04:58:02','P',1,'Missing checkCallable()',NULL,1550,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/FetchCommand.java','AAALy3///7o='),(148,1,'2010-09-08 04:58:02','P',1,'Missing checkCallable()',NULL,1550,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/FetchCommand.java','AAALy3///7s='),(99,1,'2010-09-08 04:58:02','P',1,'s/RevTag/FetchResult/ and s/tag/fetch/',NULL,1550,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/FetchCommand.java','AAALy3///7U='),(143,1,'2010-09-08 04:58:02','P',1,'Style-nit: Trailing whitespace.\n\nFWIW, this is caused by setting Eclipse to format automatically during save.  The formatter seems to run sometimes after the remove trailing whitespace stuff, which causes the two to fight over how this line should be formatted.  Its been driving me crazy since you configured Eclipse to format modified lines on save.',NULL,1550,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/FetchCommand.java','AAALy3///7w='),(246,1,'2010-09-08 04:58:02','P',1,'Missing checkCallable().  We also should have a variant that takes Collection too.',NULL,1550,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/FetchCommand.java','AAALy3///7Y='),(89,1,'2010-09-09 01:42:46','P',1,'Don\'t just assertNotNull here.  You have the proper commit and tag objects above (well, you threw away the tag).  Assert that the values read from db are equal to the values you created in db2.  That covers both the not-null did-it-create and also the did it copy as expected tests in one statement.',NULL,1550,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/FetchCommandTest.java','AAALy3///20='),(164,1,'2010-09-09 01:42:46','P',1,'Style-nit: Trailing whitespace.',NULL,1550,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAALy3///24='),(85,1,'2010-09-10 18:16:18','P',1,'Don\'t use assertTrue(equals()).  Use assertEquals() like JUnit wants you to.  It works now that we fixed .equals() on RevObject.  :-)',NULL,1550,5,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/FetchCommandTest.java','AAALy3///yg='),(269,1,'2010-09-08 05:37:11','P',1,'This is duplicated with Log.  We should share the code.',NULL,1557,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/Show.java','AAALy3///6k='),(246,1,'2010-09-08 05:37:11','P',1,'This is duplicated with LsTree.  We should share the code.',NULL,1557,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/Show.java','AAALy3///6o='),(171,1,'2010-09-08 05:37:11','P',1,'This first part of the try block is all duplicated with Log.  It would be nice if that wasn\'t the case.',NULL,1557,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/Show.java','AAALy3///6s='),(92,1,'2010-09-08 05:37:11','P',1,'This sucks.  Log, Diff, and now Show all have the same option block.  I wish I knew of a way to not duplicate this and still get the options supported by args4j.',NULL,1557,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/Show.java','AAALy3///6w='),(17,6,'2010-09-08 13:59:20','P',1,'Please add Bugs 300282 and 320263',NULL,1559,2,'/COMMIT_MSG','AAALy3///5M='),(78,46,'2010-09-09 07:18:10','P',1,'Now it\'s StyledText, because we want to have the same font as in the message viewer.','AAALy3///4o=',1562,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/CommitFileDiffViewer.java','AAALy3///2g='),(76,46,'2010-09-09 07:18:10','P',1,'Done','AAALy3///4s=',1562,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/CommitFileDiffViewer.java','AAALy3///2k='),(78,74,'2010-09-08 16:46:31','P',1,'Why TextViewer? new Text(sash, SWT.MULTI | SWT.READ_ONLY) should be sufficent',NULL,1562,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/CommitFileDiffViewer.java','AAALy3///4o='),(76,74,'2010-09-08 16:46:31','P',1,'Instead of abusing a SashForm, wouldn\'t it be better to use a StackLayout for this usecase?',NULL,1562,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/CommitFileDiffViewer.java','AAALy3///4s='),(87,2,'2010-09-30 14:49:54','P',1,'We may want to have a utility method in the future that returns all refs that aren\'t symbolic, but for now this is fine...',NULL,1563,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/tree/BranchHierarchyNode.java','AAALy3///PQ='),(60,74,'2010-09-08 21:22:13','P',1,'Would it be fair to say 3.5.2 regarding bugfixes?',NULL,1566,1,'README','AAALy3///3k='),(70,84,'2010-09-10 19:59:04','P',1,'Done','AAALy3///ys=',1575,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///xk='),(67,84,'2010-09-10 19:59:04','P',1,'I was reading http://www.ietf.org/rfc/rfc2396.txt and it\'s the first non-deprecated example in section 1.3. ;)','AAALy3///y0=',1575,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///xo='),(71,84,'2010-09-10 19:59:04','P',1,'It accepts these hilarities with or without my original patch applied, so it\'s no worse than it is before.  I\'m not volunteering for making it more restrictive.\n\npublic void testRelativeURL() {\n  new URIish(\"http://../example.com/bar.git\");\n  new URIish(\"http://example..com/bar.git\");\n  new URIish(\"http://example.com/../bar.git\");\n  new URIish(\"http://example.com/foo/../bar.git\");\n}','AAALy3///yo=',1575,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///xs='),(67,1,'2010-09-10 04:01:30','P',1,'gopher?  Seriously?  Why not http?  :-)',NULL,1575,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///y0='),(71,1,'2010-09-10 04:01:30','P',1,'Do we want to promote this pattern?  This seems to allow \"http://example.com/../foo\" which is nonsense as a URL.\n\nI wonder if we don\'t just need a different URL pattern altogether for this, similar to the SCP_URI special case we have.  Maybe a new pattern that we test before SCP_URI and FULL_URI that looks like:\n\n  PATH_URI = \"(?:[A-Za-z]:\"  // optional drive-letter\n    + \"|\\.|\\.\\.)?\" // or optional relative path indicator\n    + \"(/.+)$\"\n\nThat\'s just off the top of my head while distracted by other things going on in the room around me, so don\'t hold me to this being the correct pattern or anything, but I think its possible to recognize a local file path that isn\'t like a URL before trying the FULL_URI variant and without allowing \"http://example.com/../foo\".',NULL,1575,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///yo='),(70,1,'2010-09-10 04:01:30','P',1,'Style-nit: We put the + at the start of the line, not at the end.',NULL,1575,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///ys='),(9,49,'2010-09-13 20:03:35','P',1,'Done','AAALy3///uk=',1578,2,'/COMMIT_MSG','AAALy3///tc='),(9,6,'2010-09-13 12:40:03','P',1,'...was cleaned up...  ...was extracted',NULL,1578,2,'/COMMIT_MSG','AAALy3///uk='),(53,49,'2010-09-13 20:03:35','P',1,'Indeed, I was experimenting with direction parameter and because of that both elements were merge together.','AAALy3///uo=',1578,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALy3///tY='),(53,6,'2010-09-13 12:40:03','P',1,'Why was this line moved? I seems to belong to the parameter \"direction\".',NULL,1578,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelCommit.java','AAALy3///uo='),(182,49,'2010-09-13 20:03:35','P',1,'Done','AAALy3///uw=',1578,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelObjectContainer.java','AAALy3///tQ='),(168,49,'2010-09-13 20:03:35','P',1,'Done','AAALy3///us=',1578,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelObjectContainer.java','AAALy3///tU='),(168,6,'2010-09-13 12:40:03','P',1,'This TODO can be removed with this commit.',NULL,1578,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelObjectContainer.java','AAALy3///us='),(182,6,'2010-09-13 12:40:03','P',1,'This TODO can be removed with this commit.',NULL,1578,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/model/GitModelObjectContainer.java','AAALy3///uw='),(62,1,'2010-09-10 22:05:32','P',1,'This 3 args-per-commit syntax is obtuse.  I would prefer to be a bit more declarative within the test, at the expense of slightly more framework to implement the test.\n\nEither inline the assertions for c, b, a in the test, or setup something that lets you describe the values, e.g.:\n\n  private TestList expected;\n\n  expected.row(c).lane(0).parent(b);\n  expected.row(b).lane(0).parent(a);\n  expected.row(a).lane(0);\n  assertCommitList(pcl);',NULL,1580,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/revplot/PlotCommitListTest.java','AAALy3///w0='),(56,1,'2010-09-10 22:05:32','P',1,'parseCommit or lookupCommit is the better way to do this.  Its dangerous to use createCommit directly because you might create two different RevCommits with the same ObjectId within the walker pool.  That will confuse flags later during the traversal algorithm.',NULL,1580,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/revplot/PlotCommitListTest.java','AAALy3///w4='),(50,1,'2010-09-10 22:05:32','P',1,'testLinear',NULL,1580,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/revplot/PlotCommitListTest.java','AAALy3///w8='),(62,5,'2010-09-12 19:22:24','P',1,'I agree, I\'ll propose something like you suggested.','AAALy3///w0=',1580,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/revplot/PlotCommitListTest.java','AAALy3///wE='),(56,5,'2010-09-12 19:22:24','P',1,'Done','AAALy3///w4=',1580,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/revplot/PlotCommitListTest.java','AAALy3///wI='),(50,5,'2010-09-12 19:22:24','P',1,'Done','AAALy3///w8=',1580,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/revplot/PlotCommitListTest.java','AAALy3///wM='),(142,1,'2010-09-10 22:05:32','P',1,'That\'s a bug.  We shouldn\'t do that.\n\nWhen we markStart the commits they are tagged with the SEEN flag.  That should prevent them from being added back into the pending queue when they are encountered as a parent of a commit that was popped from pending.  If that isn\'t working, its certainly a bug inside of the walker.',NULL,1580,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/revplot/PlotCommitListTest.java','AAALy3///ww='),(174,5,'2010-09-12 19:22:24','P',1,'I\'ll add a comment here.','AAALy3///xA=',1580,1,'org.eclipse.jgit/src/org/eclipse/jgit/revplot/PlotCommitList.java','AAALy3///v0='),(156,5,'2010-09-12 19:22:24','P',1,'Yes, thats right. I want to make sure that in the end all commits are positioned. Previously that was not always true - we repaired unpositioned children only when they occured for parents with one child where the child had only one parent (us).\nI\'ll add a comment describing that better.','AAALy3///xI=',1580,1,'org.eclipse.jgit/src/org/eclipse/jgit/revplot/PlotCommitList.java','AAALy3///v4='),(152,5,'2010-09-12 19:22:24','P',1,'just removed the incomplete sentence','AAALy3///xM=',1580,1,'org.eclipse.jgit/src/org/eclipse/jgit/revplot/PlotCommitList.java','AAALy3///v8='),(148,5,'2010-09-12 19:22:24','P',1,'Done','AAALy3///xE=',1580,1,'org.eclipse.jgit/src/org/eclipse/jgit/revplot/PlotCommitList.java','AAALy3///wA='),(174,1,'2010-09-10 22:05:32','P',1,'I don\'t understand the point of the reservedLane concept. Can you better describe either in a comment or the commit message what we are trying to do here?',NULL,1580,1,'org.eclipse.jgit/src/org/eclipse/jgit/revplot/PlotCommitList.java','AAALy3///xA='),(148,1,'2010-09-10 22:05:32','P',1,'Typo on the name, should be reservedLane.',NULL,1580,1,'org.eclipse.jgit/src/org/eclipse/jgit/revplot/PlotCommitList.java','AAALy3///xE='),(156,1,'2010-09-10 22:05:32','P',1,'I\'m not sure I understand what we are doing here.  The child doesn\'t yet have a lane, so we allocate one for it.  Then we immediately recycle that lane and make it free again?\n\nThis is because the lane terminates here, right?  Can we describe that in a comment here?',NULL,1580,1,'org.eclipse.jgit/src/org/eclipse/jgit/revplot/PlotCommitList.java','AAALy3///xI='),(152,1,'2010-09-10 22:05:32','P',1,'Incomplete sentence here.  \"They\" ?',NULL,1580,1,'org.eclipse.jgit/src/org/eclipse/jgit/revplot/PlotCommitList.java','AAALy3///xM='),(18,5,'2010-09-16 22:16:57','P',1,'\'nad\'? That\'s a typo, or?',NULL,1585,1,'/COMMIT_MSG','AAALy3///o8='),(58,5,'2010-09-16 22:16:57','P',1,'One thing surprised me: I was expecting a HashedSequence would also be responsible for triggering hash calculation for certain elements. A getter for the hashCode of element x which would look up if we have the hashCode already and if not trigger calculation. This lazy way of calculation hashes may reduce our resource demand on huge contents. Maybe, on huge contents we switch to a diff which only needs the hashes for a certain window on the Sequence. Ok, ok, that\'s far away in the moment - but a HashedSequence which really only a dumb store will prevent us to do so.',NULL,1585,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/HashedSequence.java','AAALy3///o0='),(63,5,'2010-09-16 22:16:57','P',1,'If I understand correctly HashedSequence does not only add a cache of hashes to Sequence, but also offers the funtionality to work only on a subset of the original sequence. By having an offset here we will ignore some prefix of the original Sequence. Correct? Then you should document.',NULL,1585,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/HashedSequence.java','AAALy3///o4='),(58,1,'2010-09-16 22:51:12','P',1,'There is no point in trying to lazily compute a hash code for a each element.  The way that any diff function works, we will need to examine the hash code of each element at least once before the function is complete.  Therefore we need each code at least once, and therefore we can do it all faster by *not* being lazy about it.  Being lazy requires checking to see if the code has been computed yet, per element.  That\'s expensive.\n\nIf you look at the PatienceDiffIndex code, it loops through every element in the region of both sequences and gets their hash code.  No sense in lazily computing that.\n\nWe can avoid hash computation for common header/footers by looking for those common header/footer elements and skipping over them.  But that only works because the start and end of a sequence we easily defined (0 and size()-1), and we can work under the assumption that it is common for the header and footer to not change for at least one element in either direction, due to file copyright headers often being unchanged, and due to most edits appearing more in the middle of a file rather than at the exact end of it.\n\nBut that still leaves us with the entire mid section, where we have to compute everything.','AAALy3///o0=',1585,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/HashedSequence.java','AAALy3///oY='),(51,5,'2010-09-16 22:16:57','P',1,'Maybe now I understand better why we have the begin field in the HashedSequence. I was expecting a HashedSequenceComparator to do one thing: provide a fast equals() and hash() by using the knowledge that the Sequences have hashes with them. But additionally we do some index translation with offset. Isn\'t the Subsequence focusing on index translation. Maybe we could always use Subsequences for index translation and remove that aspect from this class.',NULL,1585,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/HashedSequenceComparator.java','AAALy3///og='),(51,1,'2010-09-16 22:51:12','P',1,'I didn\'t do that because it would require PatienceDiff to perform a translation on every Edit it creates to translate from the HashedSequence wrapping the Subsequence space into the original space.\n\nUsing the original element indexes meant I didn\'t have to do the translation on the Edit.\n\nBut maybe you are right.  Maybe we should be doing the translation on the Edit at the end.  The Edit list is shorter than the element list.  So deferring the translation means we can save operations (by not translating on each hash call), and its probably more clear.\n\nI\'ll rework this.  Thanks.','AAALy3///og=',1585,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/HashedSequenceComparator.java','AAALy3///oQ='),(166,1,'2010-09-16 01:08:50','P',1,'Not every ref points to a commit.  For example in the jgit repository itself the ref refs/tags/spearce-gpg-pub points to a blob.  :-)\n\nThis should be wrapped in a try/catch to catch IncorrectObjectTypeException and ignore the error.',NULL,1587,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/RevWalkTextBuiltin.java','AAALy3///qE='),(165,1,'2010-09-16 01:08:50','P',1,'I would prefer to say:\n\n  if (oid == null)\n    oid = a.getObjectId();\n\nover using the ?: operator below.',NULL,1587,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/RevWalkTextBuiltin.java','AAALy3///qI='),(76,1,'2010-09-17 14:20:05','P',1,'I\'m kind of on the fence about this.\n\nAll of the other changes in PackFile make sense, when we run out of memory and cannot complete the allocation we can still try to limp along and process the object as a stream.  But increasing our default to 50 MiB seems high if the JVM heap default is only 64 MiB on a system.  :-)\n\nI really wish I had a better method for handling random access to the delta base, but the pack file format doesn\'t allow us to do random access to a whole object, and neither does the loose object format.  I tried setting compression to 0 when we stream a delta back out as a loose object to cache it, but zlib still inserts these headers every 64k to denote its a stored literal block.  Since the headers can appear at any length (it depends on the buffer size of the deflater, which is defined down inside of the C code and is not visible to Java), its very hard to do random access within the file even if compression is disabled.\n\nWe could implement our own object cache on disk, where we deflate the file as individual small segments, so we can do random access and inflate only near the target.  But then we have to write our own cache management for this area on disk, and native Git won\'t know to clean it up during `git gc`.\n\nIts a tough problem and I don\'t have a good solution yet.  *sigh*  But this change is probably better than what we have right now.',NULL,1610,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/WindowCacheConfig.java','AAALy3///nE='),(313,6,'2010-09-17 14:27:55','P',1,'Done','AAALy3///nM=',1613,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/storage/file/T0003_Basic.java','AAALy3///m4='),(313,1,'2010-09-17 14:12:47','P',1,'I think we can just drop this test method.\n\ntest006_readCaseInsensitive in TestConfig already does the same thing, and doesn\'t require this OS specific test for the value being asserted.',NULL,1613,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/storage/file/T0003_Basic.java','AAALy3///nM='),(74,1,'2010-09-20 21:09:46','P',1,'This test is too difficult to read as written.  Look at IgnoreNodeTest as an example of an easier to read test case.  Don\'t be afraid of using instance members inside of the test to help you manage state required to use a DSL to setup the test environment in a more readable way.',NULL,1614,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/attributes/AttributesQueryTest.java','AAALy3///gw='),(122,1,'2010-09-20 21:09:46','P',1,'I would prefer to have a lot of smaller specific test cases, over chaining a large number of them into a single common input string.  Its hard to figure out what the rules we care about are from a particular assertion when the input is so complex.\n\nDo a lot of little tests for parsing:  testParse_EmptyInput().  testParse_TrailingWhitespace().  testParse_MultipleLinesSamePattern().  testParse_IgnoreComment().  testParse_IgnoreConflictMarkers().  Etc.',NULL,1614,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/attributes/AttributesTest.java','AAALy3///g0='),(79,1,'2010-09-20 21:09:46','P',1,'I think the current state of the art is to do something like:\n\n  int hc = key.hashCode();\n  hc *= 31;\n  hc += value.hashCode();\n  return hc;\n\nBut actually for an attribute there aren\'t too many that can can be multi-valued, are there?  So just using the key\'s hashCode as our own hashCode might be sufficient here.',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/Attribute.java','AAALy3///hk='),(68,1,'2010-09-20 21:09:46','P',1,'We prefer to write:\n\n  if (obj instanceof Attribute) {\n    Attribute other = (Attribute)obj;\n    ...\n  }\n  return false;\n\nas this does both the null test and the type test at the same time.  It also permits us to compare a subclass according to our current semantics.',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/Attribute.java','AAALy3///ho='),(210,1,'2010-09-20 21:09:46','P',1,'If the pattern isn\'t valid, we should treat the entry as though it were a comment line... not throw an exception.',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/Attributes.java','AAALy3///g4='),(247,1,'2010-09-20 21:09:46','P',1,'This expression can be hard to read.  I\'d rather break it out as:\n\n  if (\'0\' <= ch && ch <= \'9\')\n    continue;\n  if (\'a\' <= ch && ch <= \'z\')\n    continue;\n  if (\'A\' <= ch && ch <= \'Z\')\n    continue;\n  ...\n  return false;\n\nOr use a table to check the validity:\n\n  static boolean validChars[128];\n\n  static {\n    for (char c = \'0\'; c <= \'9\'; c++)\n      validChars[c] = true;\n    validChars[\'-\'] = true;\n    ...\n  }\n\n  if (ch > 127 || !vaildChars[ch])\n    return false;',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/Attributes.java','AAALy3///g8='),(146,1,'2010-09-20 21:09:46','P',1,'Have you put any thought into editing an Attributes?  What might our edit API look like?  I can\'t say I\'m proud of the Config API for this, its a difficult thing to edit a human written file...',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/Attributes.java','AAALy3///gs='),(187,1,'2010-09-20 21:09:46','P',1,'Since the <<<, === and >>> cases can only happen at the start of a line shouldn\'t we test for these before we do the splitting into tokens?  That is, can\'t we do:\n\n  static Entry parseEntry(String line) {\n    line = line.trim();\n    if (line.startsWith(\"#\")\n        || line.startsWith(\"<<<<<<<\")\n        || line.startsWith(\"========\")\n        || line.startsWith(\">>>>>>>>\")\n      return null;',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/Attributes.java','AAALy3///hA='),(176,1,'2010-09-20 21:09:46','P',1,'FWIW we try not to use split in our lower-level parsing routines.  We instead prefer to do loop through the characters ourselves, as it avoids the allocation of the String[], as well as the internal Pattern and Matcher objects needed to perform the regex search during the split.',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/Attributes.java','AAALy3///hE='),(181,1,'2010-09-20 21:09:46','P',1,'Isn\'t this trim unnecessary?  Wouldn\'t the prior trim call have already removed everything it can?',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/Attributes.java','AAALy3///hI='),(124,1,'2010-09-20 21:09:46','P',1,'Config parses a String.  I don\'t think its unreasonable to have all of an attributes file as a single String object.  So maybe we should parse(String) here rather than a Reader.',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/Attributes.java','AAALy3///hM='),(91,1,'2010-09-20 21:09:46','P',1,'Given its name and existence in a public API, I wouldn\'t expect the Set to be modified by the method.  But it is.  Different name perhaps?  Or maybe you should be copying the set inside of the method and altering the copy?',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/Attributes.java','AAALy3///hQ='),(63,1,'2010-09-20 21:09:46','P',1,'I would rather have this be an Entry class that is abstract, with two subclasses:  TextLine (any string) and AttrLine (an attribute declaration).  That way we don\'t play as many instanceof games below.',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/Attributes.java','AAALy3///hU='),(49,1,'2010-09-20 21:09:46','P',1,'I know Javadoc was omitted to get a basic draft uploaded, but I\'d like some to help understand the purpose of this interface and how collect should behave.',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/AttributesCollector.java','AAALy3///hY='),(76,1,'2010-09-20 21:09:46','P',1,'What is the distinction between id and value?',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/AttributeValue.java','AAALy3///hc='),(69,1,'2010-09-20 21:09:46','P',1,'Please include a translation text here indicating that attribute value cannot be null.',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/attributes/AttributeValue.java','AAALy3///hg='),(56,1,'2010-09-20 21:09:46','P',1,'I wonder if we shouldn\'t call this equals().  StringUtils has an equalsIgnoreCase(String,String) that almost mirrors String.equalsIgnoreCase(String).',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/CompareUtils.java','AAALy3///hs='),(57,1,'2010-09-20 21:09:46','P',1,'Style-nit: Parens on the LHS of || aren\'t necessary.',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/CompareUtils.java','AAALy3///hw='),(1057,1,'2010-09-20 21:09:46','P',1,'PathUtils class maybe?  I\'m not convinced these should be in RawParseUtils.  RawParseUtils is typically working on byte[] and often providing a higher level value from that (e.g. an int, String or PersonIdent).',NULL,1614,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/RawParseUtils.java','AAALy3///h0='),(86,1,'2010-09-20 21:19:54','P',1,'None of this should be in FileTreeIterator.  It all should be implementable in WorkingTreeIterator.\n\nBut attributes are harder than gitignore.  For attributes we also need to pay attention to the CanonicalTreeParser side of the house during checkout.  Because during checkout we need to use the gitattributes file from the repository to determine CRLF status of a file as we create or update it in the working tree.\n\nGiven that, maybe we should implement attribute support using an AbstractTreeIterator that wraps another AbstractTreeIterator.  It can peek at the underlying AbstractTreeIterator to see if there is a gitattributes present, and if so it would setup an Attributes to represent the current attributes.  Peeking shouldn\'t be very expensive because \".gitattributes\" is very likely to occur very early in a sorted list, and is actually not likely to exist.  So we probably only need to examine the first path of the wrapped iterator to prove its after \".gitattributes\" and thus don\'t need attribute support... or it is \".gitattributes\", we load it, and back(1) to undo.  That\'s all reasonably cheap.\n\nThen checkout client code that needs to care about attributes from a particular location (e.g. working tree or repository) can wrap the iterator with this AttributeIterator type and later query for attributes as necessary.\n\nBecause TreeWalk manages iterators by creating a new iterator when it dives into a tree, and discards an iterator when it exits, we don\'t need to manage the stack ourselves.  Attribute collections from a nested subtree will automatically fall out of scope when the TreeWalk throws away the AttributeIterator.\n\nThis also opens the door for some potential optimization of an Attributes object.  If we are in an AttributeIterator we might want to sort the entries by path name so we can merge join them against the underlying iterator\'s own names during next() and back(), reducing the amount of work we need to perform during a particular attribute query from the caller.  Likewise we might be able to be told by our caller that we only care about the \"text\" and \"crlf\" attributes, and discard any other rules that aren\'t relevant.',NULL,1615,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/FileTreeIterator.java','AAALy3///gk='),(9,1,'2010-09-21 14:14:09','P',1,'cherry-pick can be implemented using merge.  :-)\n\nLets say we want to cherry-pick commit C, whose parent is B, and we want to apply it on top of Q:\n\n  o----- B ----- C\n   \\\n    o--o--o-- Q\n\n* Set the \"ours\" side to be Q.\n* Set the \"theirs\" side to be C.\n* Fix the merge base to be C^1, that is B.\n\nWhere there is a B-C difference, it shows up as an edit made by \"them\" and is applied by the merge as a \"theirs\" side edit.  Where there is a B-Q difference, it shows up as an edit made by \"us\" and shows up as an \"ours\" side edit.  Providing that these edits aren\'t conflicting, the merge will complete cleanly.','AAALy3///fs=',1629,1,'/COMMIT_MSG','AAALy3///fc='),(9,5,'2010-09-21 11:31:10','P',1,'I am not sure about cherry-picking. That\'s I think a different\r\nstory from merge. With merge you have two states A and B and the merge result consists parts from A, parts from B and conflicts. A cherry pick is AFAIK different. There you take the diff of one commit (what lines are changed by this single commit) and try to apply this change on some other state. You have to solve problems like \"Where in the target state do I have to add this change. Line numbers are not sufficient - you have to find the common lines (the context) listed in the diff)\". Problems which a merge algorithm doesn\'t care about.',NULL,1629,1,'/COMMIT_MSG','AAALy3///fs='),(71,1,'2010-09-20 22:49:43','P',1,'Style-nit: Trailing space at end of line.',NULL,1629,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeStrategy.java','AAALy3///gc='),(71,4,'2010-09-19 21:03:59','d',1,'style nit: trailing whitespace',NULL,1629,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeStrategy.java','AAALy3///jE='),(224,5,'2010-09-21 07:33:56','P',1,'It\'s not only this method, but also mergeImpl() which looks similar enough to be reused.','AAALy3///gY=',1629,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMergerInCore.java','AAALy3///f4='),(224,1,'2010-09-20 22:49:43','P',1,'This code is complex enough that it should be shared with ResolveMerger somehow.',NULL,1629,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMergerInCore.java','AAALy3///gY='),(2,1,'2010-09-20 22:49:43','P',1,'Please also include the standard line:\n\n * and other copyright owners as documented in the project\'s IP log.\n\nBecause we don\'t always update the copyright headers when an edit is made to the file after it is added to the repository.  The foundation requires us to have this line to alert readers that the above copyright notices might not be sufficient to fully document the current owners of the file.',NULL,1629,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/StrategyResolveInCore.java','AAALy3///gU='),(150,86,'2010-09-22 17:55:55','P',1,'that is correct, the idea was not to touch working folder and index at all','AAALy3///cs=',1629,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///b0='),(190,86,'2010-09-22 17:55:55','P',1,'good point.','AAALy3///co=',1629,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///b4='),(423,86,'2010-09-22 17:55:55','P',1,'failingPathes indicate only paths that failed abnormally (not because of a conflict) but rather because of dirty index or working folder, so it looks not applicable to inCore.\nFor conflict failures their is unmergedPathes list which we do update.','AAALy3///cM=',1629,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///b8='),(469,5,'2010-09-22 20:57:57','P',1,'I don\'t think you have missed something - I guess it\'s no so easy with standard java. But Shawn provided a class TemporaryBuffer.LocalFile which may be helpful. You may also decide to leave this optimization for the next proposal and stay with this temporary file for now.','AAALy3///cA=',1629,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///bo='),(423,5,'2010-09-22 20:57:57','P',1,'I agree!','AAALy3///b8=',1629,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///bs='),(469,86,'2010-09-22 17:55:55','P',1,'I\'ve actually looked at this option and tried to see if I can use some kind of pipes for this but couldn\'t find a good and simple solution (but frankly I don\'t have any experience with java and the available modules, so there must be something I missed). \nGoing that route though will make the code different enough that it may require a split into a different class.','AAALy3///cI=',1629,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///cA='),(469,5,'2010-09-22 17:14:55','P',1,'Is there no way we can get rid of using temporary files here. In memory would fit better in case of inCore, or? Both, this MergeFormatter and also later the ObjectInserter are not bound to files but just to Input/Outputstreams.',NULL,1629,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///cI='),(423,5,'2010-09-22 17:14:55','P',1,'We are not fillining the failingpathes list in case of \"incore\". Therefore we will not be able to report why a incore merge failed.',NULL,1629,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///cM='),(190,5,'2010-09-22 17:14:55','P',1,'because you skip cleanUp() in case of inCore the attribute modifiedFiles may still be filled wrongly. When the incore-merge fails for whatever reason should clean the modifiedFiles list. Maybe it is better to modifiy cleanup() to do only that in case of an incore.',NULL,1629,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///co='),(425,5,'2010-09-22 17:14:55','P',1,'Only two additional if\'s in the mainloop (one here and one in mergeimpl()). Great, from my point of view we can spent that.',NULL,1629,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///cQ='),(150,5,'2010-09-22 17:14:55','P',1,'just for my understanding: \'incore\' not only mean that we will ignore the workingdir - but we will also not update any index, right? The incore version of the Dircache is not supposed to ever be persisted.\nI do see that we will use DirCache.writeTree() in the end (which I think is permitted even on a incore DirCache) to write to the object database our merge result - but the index itself is not updated. Correct?',NULL,1629,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///cs='),(136,5,'2010-09-22 17:14:55','P',1,'style: unnecessary empty line',NULL,1629,3,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///cw='),(267,5,'2010-09-24 13:13:27','P',1,'style-nit: wrong indention on the previous two lines',NULL,1629,4,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///Yk='),(268,5,'2010-09-24 13:13:27','P',1,'style-nit: please remove trailing whitespaces',NULL,1629,4,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///Ys='),(257,5,'2010-09-24 13:13:27','P',1,'style-nit: please use tabs here for indention',NULL,1629,4,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAALy3///Yw='),(9,2,'2010-09-21 23:59:24','P',1,'Should be \"which promises\", just throw out \"we know\"','AAALy3///eo=',1638,1,'/COMMIT_MSG','AAALy3///eA='),(9,5,'2010-09-21 22:56:03','P',1,'s/know/now/',NULL,1638,1,'/COMMIT_MSG','AAALy3///eo='),(104,4,'2010-09-23 16:49:56','d',1,'is that a good idea',NULL,1642,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/EditList.java','AAALy3///aU='),(217,5,'2010-09-21 22:54:17','P',1,'this @see can be removed now',NULL,1645,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALy3///eg='),(217,1,'2010-09-21 22:55:17','P',1,'Done','AAALy3///eg=',1645,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/DiffFormatter.java','AAALy3///eY='),(177,1,'2010-09-22 04:10:58','P',1,'This is wrong.  We need to account for the fact that another element within the region spanned by lcs might be unique even though the original element that caused us to create the region is now not unique.',NULL,1647,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiffIndex.java','AAALy3///dI='),(10,4,'2010-09-24 12:43:37','d',1,'typo: s/to/too/',NULL,1657,1,'/COMMIT_MSG','AAALy3///ZU='),(7,4,'2010-09-24 12:43:24','d',1,'should be more specific, e.g.:\n\nFix ui tests accessing history view too early.',NULL,1657,1,'/COMMIT_MSG','AAALy3///ZY='),(252,4,'2010-09-24 12:44:17','d',0,'why do we keep commented out code here ?',NULL,1657,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/test/history/HistoryViewTest.java','AAALy3///ZM='),(176,4,'2010-09-24 12:43:56','d',1,'style nit: whitespace error, some more below',NULL,1657,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/test/history/HistoryViewTest.java','AAALy3///ZQ='),(22,74,'2010-09-24 12:45:45','d',1,'typo',NULL,1657,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/JobFamilies.java','AAALy3///ZE='),(22,4,'2010-09-24 12:44:57','d',1,'typo: s/jib/job/',NULL,1657,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/JobFamilies.java','AAALy3///ZI='),(9,4,'2010-09-27 20:35:20','P',1,'typo: s/should protected/should be protected/',NULL,1665,1,'/COMMIT_MSG','AAALy3///TY='),(8,5,'2010-11-10 15:44:57','P',1,'This class has been removed','AAALy3///Ss=',1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/Credentials.java','AAAL0H///7U='),(1,4,'2010-09-28 07:50:00','P',1,'missing license header',NULL,1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/Credentials.java','AAALy3///Sg='),(8,4,'2010-09-28 07:50:00','P',1,'I don\'t understand the purpose of this class, all the methods defined here are already defined on java.lang.Object',NULL,1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/Credentials.java','AAALy3///Ss='),(1,5,'2010-11-10 15:44:57','P',1,'Done','AAALy3///Sc=',1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/CredentialsProvider.java','AAAL0H///7Q='),(1,4,'2010-09-28 07:50:00','P',1,'missing license header',NULL,1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/CredentialsProvider.java','AAALy3///Sc='),(109,5,'2010-11-10 15:44:57','P',1,'Done','AAALy3///GQ=',1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/HttpAuthMethod.java','AAAL0H///7c='),(113,5,'2010-11-10 15:44:57','P',1,'This has been reworked and simplified completely.','AAALy3///GM=',1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/HttpAuthMethod.java','AAAL0H///7Y='),(113,1,'2010-10-06 17:23:04','P',1,'I agree, the downcast here is ugly.\n\nA more clean solution is to have the provider be a callback that we ask for data from:\n\n  c = credentialsProvider.getCredentials(uri, \"Username\", \"Password\");\n  username = c.get(0);\n  passsword = c.get(1);\n\nOr something like that.  The idea being that the protocol here provides prompts to the provider letting it know what it needs, and the provider returns that data in the credentials object.\n\nTo be safe we probably don\'t want to pass in username/password as strings, but instead have a prompt type object that is abstract, with two concrete instances for USERNAME and PASSWORD that are standard singletons.  LIkewise we could do a PASSPHRASE standard singleton to decrypt an SSH key.',NULL,1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/HttpAuthMethod.java','AAALy3///GM='),(109,1,'2010-10-06 17:23:04','P',1,'Don\'t initialize to null.  Let the compiler require us to ensure the values are initialized in every branch below.',NULL,1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/HttpAuthMethod.java','AAALy3///GQ='),(113,4,'2010-09-28 07:50:00','P',1,'this downcasting looks ugly',NULL,1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/HttpAuthMethod.java','AAALy3///So='),(565,5,'2010-11-10 15:44:57','P',1,'Done','AAALy3///GI=',1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/Transport.java','AAAL0H///7M='),(565,1,'2010-10-06 17:23:04','P',1,'We would prefer this to be private and use the getter.',NULL,1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/Transport.java','AAALy3///GI='),(1,5,'2010-11-10 15:44:57','P',1,'This class has been removed','AAALy3///Sk=',1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UsernamePasswordCredentials.java','AAAL0H///7I='),(1,4,'2010-09-28 07:50:00','P',1,'missing license header',NULL,1671,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UsernamePasswordCredentials.java','AAALy3///Sk='),(69,1,'2010-11-10 19:52:27','P',1,'Style-nit: Unnecessary blank line.',NULL,1671,2,'org.eclipse.jgit/src/org/eclipse/jgit/errors/UnsupportedCredentialType.java','AAAL0H///58='),(101,1,'2010-11-10 19:52:27','P',1,'Doesn\'t this interface limit us to prompting twice for input?  That is, if the caller knows it needs both USERNAME and PASSWORD (think HTTP basic auth) we have to ask the provider twice.  So the provider has to open a dialog and ask for username, close that dialog, return the value, then open another to ask for password.  Ick.\n\nWhat about this interface instead:\n\n  public abstract Map<CredentialType, Object> getCredentials(URIish uri, CredentialType... types);\n\nThen we can ask for either one value, or multiple values, at one time.\n\nBut this still isn\'t completely flexible.  We can\'t use this interface to ask for an SSH key passphrase for example, because we cannot extend the CredentialType enumeration with a new value.\n\nI have a different alternative idea.  I\'ll try uploading a replacement patch set with it for comments.',NULL,1671,2,'org.eclipse.jgit/src/org/eclipse/jgit/transport/CredentialsProvider.java','AAAL0H///6A='),(95,1,'2010-11-10 19:52:27','P',1,'Style-nit: Trailing whitespace.',NULL,1671,2,'org.eclipse.jgit/src/org/eclipse/jgit/transport/CredentialsProvider.java','AAAL0H///6E='),(90,1,'2010-11-10 19:52:27','P',1,'Style-nit: Trailing whitespace.',NULL,1671,2,'org.eclipse.jgit/src/org/eclipse/jgit/transport/CredentialsProvider.java','AAAL0H///6I='),(177,4,'2010-10-03 21:17:10','P',1,'style nit: trailing whitespace',NULL,1672,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAALy3///Lg='),(218,4,'2010-10-03 21:17:10','P',1,'typo: s/fetch/push/',NULL,1672,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PushCommand.java','AAALy3///Lc='),(173,4,'2010-10-03 21:17:10','P',1,'typo: s/fetch/push/',NULL,1672,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PushCommand.java','AAALy3///LU='),(272,4,'2010-10-03 21:17:10','P',1,'could be simplified:\nCollections.addAll(refsSpecs, specs);',NULL,1672,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PushCommand.java','AAALy3///LY='),(242,6,'2010-09-30 13:48:30','d',1,'Whitespace error',NULL,1677,2,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/synchronize/SynchronizeViewTest.java','AAALy3///Qg='),(241,49,'2010-09-30 17:48:07','P',1,'Done','AAALy3///QY=',1677,3,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/synchronize/SynchronizeViewTest.java','AAALy3///QM='),(241,6,'2010-09-30 13:57:02','P',1,'Whitespace error',NULL,1677,3,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/synchronize/SynchronizeViewTest.java','AAALy3///QY='),(607,46,'2010-09-30 13:29:40','P',1,'Done','AAALy3///RQ=',1678,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/CreateTagDialog.java','AAALy3///Q0='),(483,46,'2010-09-30 13:29:40','P',1,'Done','AAALy3///RI=',1678,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/CreateTagDialog.java','AAALy3///Q4='),(270,46,'2010-09-30 13:29:40','P',1,'Done. Good point, thanks.','AAALy3///RM=',1678,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/CreateTagDialog.java','AAALy3///Q8='),(483,63,'2010-09-30 13:17:25','P',1,'I believe we are on 3.5 now, correct? You can just call ArrayContentProvider.getInstance() instead then.',NULL,1678,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/CreateTagDialog.java','AAALy3///RI='),(270,63,'2010-09-30 13:17:25','P',1,'It is generally better to use asyncExec(Runnable) instead of syncExec(Runnable). The work is being done asynchronously on a separate thread anyway so I see no hard requirement for this table population to be done immediately.\n\nPlease do change the code to not use Display.getDefault() (you can swap with getShell().getDisplay()) though.',NULL,1678,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/CreateTagDialog.java','AAALy3///RM='),(607,63,'2010-09-30 13:17:25','P',1,'Technically speaking, this isn\'t mandatory because an ArrayContentProvider actually takes both an array and a java.util.Collection. If you look at the implementation, we will call toArray() for you. So really, it is up to you if you want to call toArray() now or later, I just thought I would point it out for your information (about how ArrayContentProvider works).',NULL,1678,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/CreateTagDialog.java','AAALy3///RQ='),(456,44,'2010-10-13 09:44:13','P',1,'Retrieving the commit list may block the UI. Use PlatformUI.getWorkbench().getProgressService().busyCursorWhile to call getRevCommits outside the UI thread.',NULL,1678,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/CreateTagDialog.java','AAALzH////E='),(456,46,'2010-10-13 10:45:43','P',1,'Done','AAALzH////E=',1678,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/CreateTagDialog.java','AAALzH///+s='),(104,2,'2010-09-30 14:52:19','P',1,'Couldn\'t we move this logic up with branchName == null?',NULL,1679,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/RepositoriesViewLabelProvider.java','AAALy3///O4='),(104,46,'2010-09-30 14:57:18','P',1,'Almost. But when we are on a local branch, we don\'t need to resolve.','AAALy3///O4=',1679,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/RepositoriesViewLabelProvider.java','AAALy3///Og='),(9,6,'2010-09-30 15:06:45','P',1,'duplicate \"be\"',NULL,1680,1,'/COMMIT_MSG','AAALy3///OY='),(638,89,'2010-10-07 08:53:17','d',1,'You are right. Exception was thrown because of call of ProgressMonitor.update() from several threads. How about such solution: http://egit.eclipse.org/r/#change,1708','AAALy3///HU=',1681,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALy3///E0='),(638,1,'2010-10-06 16:36:22','P',1,'We can\'t do this.  By setting the executor you are always disabling threaded delta computation.  Why does this fix the error?\n\nIs the problem that we are doing writes from a delta thread in order to update the progress stream, and then later we try to write to the pipe from a different thread to write the pack?  If that is the problem than the correct fix is to modify PackWriter to ensure that the progress messages are written from the \"main\" thread rather than from one of the background delta threads.',NULL,1681,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/UploadPack.java','AAALy3///HU='),(65,6,'2010-09-30 14:49:52','P',1,'Done','AAALy3///Qo=',1683,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariant.java','AAALy3///PU='),(65,49,'2010-09-30 13:47:40','P',1,'Can\'t we here just abbreviate commit ID eg:\nrevCommit.abbreviate(7).name() + \"...\"\n?',NULL,1683,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/synchronize/GitResourceVariant.java','AAALy3///Qo='),(1,6,'2010-09-30 15:12:48','P',1,'Done','AAALy3///Ow=',1684,1,'0001-Make-Synchronize-available-on-current-branch.patch','AAALy3///OQ='),(1,2,'2010-09-30 14:54:49','P',1,'Remove this please.',NULL,1684,1,'0001-Make-Synchronize-available-on-current-branch.patch','AAALy3///Ow='),(76,46,'2010-09-30 14:06:12','P',1,'Whitespace',NULL,1687,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/test/Eclipse.java','AAALy3///P0='),(73,46,'2010-09-30 14:06:12','P',1,'Whitespace',NULL,1687,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/test/Eclipse.java','AAALy3///P4='),(88,63,'2010-09-30 14:36:53','P',1,'You may be able to just get around this extra code by executing the command (IWorkbenchCommandConstants.WINDOW_PREFERENCES) via the IHandlerService. Otherwise, you can also pop it up using the PreferencesUtil class\'s static methods.',NULL,1687,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/test/Eclipse.java','AAALy3///Pg='),(85,46,'2010-09-30 14:06:12','P',1,'Do we really need to switch the perspective?',NULL,1687,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/test/Eclipse.java','AAALy3///Pw='),(464,5,'2010-10-06 15:40:10','P',1,'I just copied the proposed test from bug: 315571. But you are right, the name is not ok. I fixed it.','AAALy3///Lo=',1690,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/transport/URIishTest.java','AAALy3///IE='),(464,11,'2010-10-01 19:39:09','P',1,'Please provide more specific method name. It seems to me this should fail due to extra \':\' between hostname and the path, right?',NULL,1690,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/transport/URIishTest.java','AAALy3///Lo='),(131,4,'2010-10-06 16:35:26','d',1,'typo: s/the the/for the/',NULL,1690,2,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///Hc='),(213,4,'2010-10-06 16:37:35','d',1,'incomplete sentence',NULL,1690,2,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///HI='),(212,4,'2010-10-06 16:37:10','d',1,'typo: s/cut of/cut off/',NULL,1690,2,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///HM='),(140,4,'2010-10-06 16:36:01','d',1,'typo: s/an relative/a relative/',NULL,1690,2,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///HY='),(139,4,'2010-10-07 22:41:33','P',1,'typo: s/an relative/a relative/',NULL,1690,3,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///B4='),(139,5,'2010-10-08 05:10:06','P',1,'Done','AAALy3///B4=',1690,3,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///BA='),(96,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///KQ=',1696,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/PullCommandTest.java','AAALy3///I4='),(74,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///KU=',1696,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/PullCommandTest.java','AAALy3///I8='),(3,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///KY=',1696,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/PullCommandTest.java','AAALy3///JA='),(96,4,'2010-10-05 19:50:38','P',1,'should be renamed to testPullConflict',NULL,1696,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/PullCommandTest.java','AAALy3///KQ='),(74,4,'2010-10-05 19:50:38','P',1,'I think this should be renamed to testPullFastForward',NULL,1696,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/PullCommandTest.java','AAALy3///KU='),(3,4,'2010-10-05 19:50:38','P',1,'style nit: usually we don\'t have a blank line here',NULL,1696,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/PullCommandTest.java','AAALy3///KY='),(59,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///KE=',1696,1,'org.eclipse.jgit/resources/org/eclipse/jgit/JGitText.properties','AAALy3///I0='),(59,4,'2010-10-05 19:50:38','P',1,'I am not a native English speaker, but \"pull on\" sounds like this is borrowed from German, I would rather expect something like \"pull into\"',NULL,1696,1,'org.eclipse.jgit/resources/org/eclipse/jgit/JGitText.properties','AAALy3///KE='),(3,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///Jk=',1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/errors/CanceledException.java','AAALy3///IY='),(3,4,'2010-10-05 19:50:38','P',1,'style nit: avoid this empty line',NULL,1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/errors/CanceledException.java','AAALy3///Jk='),(4,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///Jg=',1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/errors/DetachedHeadException.java','AAALy3///IU='),(4,4,'2010-10-05 19:50:38','P',1,'style nit: avoid this empty line',NULL,1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/errors/DetachedHeadException.java','AAALy3///Jg='),(4,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///Jc=',1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/errors/InvalidConfigurationException.java','AAALy3///IQ='),(4,4,'2010-10-05 19:50:38','P',1,'style nit: avoid this empty line',NULL,1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/errors/InvalidConfigurationException.java','AAALy3///Jc='),(153,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///J8=',1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Ig='),(142,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///KA=',1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Ik='),(103,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///Js=',1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Io='),(73,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///KI=',1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Is='),(3,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///KM=',1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Iw='),(153,4,'2010-10-05 19:50:38','P',1,'I think this comment doesn\'t add any value',NULL,1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///J8='),(165,5,'2010-10-05 23:43:37','P',1,'The pull configuration talks only about the name of the remote repo and the branch name on that remote repository. It doesn\'t mention any name of a local (remote tracking) branch. \n\nImagine that a configuration like this\n\n[remote \"eclipse\"]\n        url = git://egit.eclipse.org/jgit.git\n        fetch = +refs/heads/*:refs/heads/fromEclipse/*\n[branch \"master\"]\n        remote = eclipse\n        merge = refs/heads/master\n\nWe want finally to merge refs/heads/fromEclipse/master into master. But thats hard to find out if you only look at the pull configuration. And you also don\'t want to parse the fetch configuration. But the fetch command tells us which remote branch went into which local branch. Thats why we have this here.','AAALy3///Jw=',1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///JI='),(103,4,'2010-10-05 19:50:38','P',1,'missing javadoc',NULL,1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Js='),(165,4,'2010-10-05 19:50:38','P',1,'I don\'t understand this logic, I think the full ref for the remote tracking branch can be completely determined from the name of the remote branch and the pull configuration. Why should we need to observe which branch gets updated ?',NULL,1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Jw='),(142,4,'2010-10-05 19:50:38','P',1,'it may also happen that this branch is configured for \"pull --rebase\" instead of the default, in that case we should show a different error message explaining that rebase isn\'t yet supported',NULL,1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///KA='),(73,4,'2010-10-05 19:50:38','P',1,'add a link to the git reference documentation for this command',NULL,1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///KI='),(3,4,'2010-10-05 19:50:38','P',1,'style nit: avoid this blank line',NULL,1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///KM='),(3,46,'2010-10-06 07:41:18','P',1,'Done','AAALy3///Jo=',1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullResult.java','AAALy3///Ic='),(3,4,'2010-10-05 19:50:38','P',1,'style nit: avoid this empty line',NULL,1696,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullResult.java','AAALy3///Jo='),(226,46,'2010-10-07 09:42:25','P',1,'Done','AAALy3///Fg=',1696,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Ek='),(192,46,'2010-10-07 09:42:25','P',1,'Done','AAALy3///Fk=',1696,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Eo='),(131,46,'2010-10-07 09:42:25','P',1,'Done','AAALy3///Fo=',1696,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Es='),(128,46,'2010-10-07 09:42:25','P',1,'Absolutely. But these additional parameters are out of scope for the moment.','AAALy3///Fs=',1696,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Ew='),(226,1,'2010-10-06 18:25:22','P',1,'This won\'t quite create the correct merge message.  During a pull we want to know the URI of the remote, and the remote branch name, not the local tracking branch name.',NULL,1696,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Fg='),(192,1,'2010-10-06 18:25:22','P',1,'Instead of this loop, you just want:\n\n  Ref r = fetchRes.getAdvertisedRef(remoteBranchName);\n  if (r == null)\n    r = fetchRes.getAdvertisedRef(R_HEADS + remoteBranchName);\n\nThen you can use r.getObjectId() to tell you what the object is.',NULL,1696,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Fk='),(131,1,'2010-10-06 18:25:22','P',1,'Instead of reading the branch name twice from HEAD, read it once with getFullBranch() and trim it yourself if it starts with R_HEADS.',NULL,1696,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Fo='),(128,1,'2010-10-06 18:25:22','P',1,'Sure we can.  You just can\'t use branch configuration to do it.  Instead the caller must give us options like a remote name or URI, and optionally a remote branch as well.  These override the configuration defaults.',NULL,1696,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALy3///Fs='),(80,63,'2010-10-05 11:54:40','d',1,'You can just use EditorsUI.DEFAULT_TEXT_EDITOR_ID.',NULL,1697,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/EgitUiEditorUtils.java','AAALy3///Kw='),(78,46,'2010-10-14 07:09:37','P',1,'Done','AAALzH///6w=',1697,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/command/OpenInTextEditorHandler.java','AAALzH///6E='),(78,4,'2010-10-13 22:07:25','P',1,'style nit: avoid braces around single line block',NULL,1697,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/command/OpenInTextEditorHandler.java','AAALzH///6w='),(121,5,'2010-10-07 07:39:27','P',1,'Done','AAALy3///Ho=',1700,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///E8='),(108,5,'2010-10-07 07:39:27','P',1,'previously we had some special constructs for scheme://host/~username/path . This is not needed anymore. So I will remove the \'~username\' reference from this javadoc.\n\nI\'ll also reword the part saying that a host \'contains\' user/pwd,... etc.','AAALy3///Hs=',1700,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///FA='),(98,5,'2010-10-07 07:39:27','P',1,'Done','AAALy3///Hw=',1700,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///FE='),(121,4,'2010-10-06 16:28:05','P',1,'typo: s/a SCP URI\'s/SCP URI\'s/',NULL,1700,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///Ho='),(108,4,'2010-10-06 16:28:05','P',1,'- why \"and ~username\" ?\n- I think semantically it doesn\'t make much sense to say that a host may contain user/password and port.',NULL,1700,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///Hs='),(98,4,'2010-10-06 16:28:05','P',1,'typo: s/parts/paths/',NULL,1700,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/URIish.java','AAALy3///Hw='),(9,5,'2010-10-07 11:50:47','P',1,'Done','AAALy3///G8=',1701,1,'/COMMIT_MSG','AAALy3///EU='),(9,4,'2010-10-06 16:42:32','P',1,'that\'s not completely true if we accept relative paths',NULL,1701,1,'/COMMIT_MSG','AAALy3///G8='),(11,5,'2010-10-08 05:09:30','P',1,'changed \'lead\' to \'led\'. But \'to\' to \'too\', really?','AAALy3///CA=',1702,2,'/COMMIT_MSG','AAALy3///A8='),(11,4,'2010-10-07 22:34:58','P',1,'typos: s/to/too/  s/lead/led/',NULL,1702,2,'/COMMIT_MSG','AAALy3///CA='),(15,1,'2010-10-06 17:34:18','P',1,'Please rebase one change on top of the other, so that the Exception is properly defined before its used in either place.',NULL,1704,1,'/COMMIT_MSG','AAALy3///F4='),(123,5,'2010-10-07 12:49:39','P',1,'If we implement each mode in his own class (BranchDelete, BranchCreate,...) then we don\'t need the Mode enum anymore. I hope we can also get rid of this options map. Why not store the options simply in plain attributes?',NULL,1704,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALy3///D0='),(152,5,'2010-10-07 12:49:39','P',1,'I also think so. If git porcelain commands have different modes which don\'t even share common paramenters (like create vs. list) they should go into different commands implemented in seperate classes.','AAALy3///F0=',1704,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALy3///D4='),(210,5,'2010-10-07 12:49:39','P',1,'that\'s not really a commit message, or? No commit get\'s this message. I suggest reflogMessage.',NULL,1704,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALy3///Dw='),(152,1,'2010-10-06 17:34:18','P',1,'This is hideous.  What about having branchList(), branchCreate(), branchRename(), branchDelete() methods on Git that create different command objects for each operation?\n\nI think callers can handle typing branchCreate() vs. branch().setCreate(...)',NULL,1704,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/BranchCommand.java','AAALy3///F0='),(78,46,'2010-10-08 12:10:05','P',1,'Done','AAALy3///DE=',1704,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/BranchCommandTest.java','AAALy3///AA='),(135,5,'2010-10-07 22:07:12','P',1,'It\'s not needed to create the localRepository. As this test is subclass\nof RepositoryTestCase all tests automatically have access to a test repo. Just call getRepository() to get access to it.',NULL,1704,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/BranchCommandTest.java','AAALy3///C8='),(84,5,'2010-10-07 22:07:12','P',1,'Why don\'t you use writeTrashFile(filename, data)? A single call does what your 4 lines do. This comment is applicable a lot of times in this File.',NULL,1704,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/BranchCommandTest.java','AAALy3///DA='),(78,5,'2010-10-07 22:07:12','P',1,'Why do you create this file? It\'s not added to the initial commit.',NULL,1704,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/BranchCommandTest.java','AAALy3///DE='),(113,5,'2010-10-07 22:07:12','P',1,'shouldn\'t we delete those commented out lines?',NULL,1704,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/BranchCommandTest.java','AAALy3///DI='),(135,46,'2010-10-08 12:10:05','P',1,'This is actually a third Repository (the first one is not connected to a remote repo and for some tests we need one that has remote tracking branches)','AAALy3///C8=',1704,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/BranchCommandTest.java','AAALy3//+/0='),(113,46,'2010-10-08 12:10:05','P',1,'Done','AAALy3///DI=',1704,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/BranchCommandTest.java','AAALy3//+/4='),(84,46,'2010-10-08 12:10:05','P',1,'Done','AAALy3///DA=',1704,3,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/BranchCommandTest.java','AAALy3//+/8='),(251,1,'2010-10-08 02:01:26','P',1,'I would prefer to trim the length of R_REMOTES off first, and then split.  That way you only need to split twice to get remote name and branch name, and we don\'t have this odd constant here.',NULL,1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CreateBranchCommand.java','AAALy3///BI='),(136,1,'2010-10-08 02:01:26','P',1,'If you are taking a String, use repo.resolve(String) to convert it to an ObjectId.  This guess work here is repeating only some of that logic, poorly, and fails on things like abbreviations.\n\nIts OK to have the special case to see if its a remote branch, but that\'s probably something like:\n\n  Ref ref = repo.getRef(R_REMOTES + startPoint);\n  ObjectId id;\n  if (ref != null) {\n    ... its a remote tracking branch, setup tracking ...\n    id = ref.getObjectId();\n  } else {\n    ... anything else cannot be tracked automatically ...\n    id = repo.resolve(startPoint);\n  }',NULL,1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CreateBranchCommand.java','AAALy3///BM='),(348,1,'2010-10-08 02:01:26','P',1,'Why do we have this method?  We don\'t do this for any other command object type.',NULL,1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CreateBranchCommand.java','AAALy3///BQ='),(98,1,'2010-10-08 02:01:26','P',1,'Maybe SET_UPSTREAM ?',NULL,1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CreateBranchCommand.java','AAALy3///BU='),(83,1,'2010-10-08 02:01:26','P',1,'typo on set-upstream',NULL,1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CreateBranchCommand.java','AAALy3///BY='),(315,5,'2010-10-07 22:07:12','P',1,'We should accept by also RevCommits as starting point. Same as in MergeCommand.include(..) - we have to accept Strings as well as higher-level objects.\n\nImagine you create the first branch with this command (which would return a RevCommit) and then you want to create a second branch with the first branch as starting point. We already have the object of right type in hand, but we are forced to convert it to a String and then this class will convert back the String to a RevCommit.',NULL,1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CreateBranchCommand.java','AAALy3///Cs='),(98,46,'2010-10-08 12:10:05','P',1,'Done','AAALy3///BU=',1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CreateBranchCommand.java','AAALy3//+/s='),(83,46,'2010-10-08 12:10:05','P',1,'Done','AAALy3///BY=',1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CreateBranchCommand.java','AAALy3//+/w='),(251,46,'2010-10-08 12:10:05','P',1,'See remark above about upstream config when a local branch is the start point.','AAALy3///BI=',1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CreateBranchCommand.java','AAALy3//++0='),(136,46,'2010-10-08 12:10:05','P',1,'It seems that upstream config is also possible if you are based on a local branch, in which case branch.<name>.remote is set to \".\". Am I wrong?','AAALy3///BM=',1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CreateBranchCommand.java','AAALy3//++4='),(348,46,'2010-10-08 12:10:05','P',1,'Done','AAALy3///BQ=',1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CreateBranchCommand.java','AAALy3//++s='),(315,46,'2010-10-08 12:10:05','P',1,'Done','AAALy3///Cs=',1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CreateBranchCommand.java','AAALy3//++w='),(190,5,'2010-10-07 22:07:12','P',1,'You don\'t have a setMode() here as the command does. On command line if you want to delete a remote tracking branch you have to specify \'-r\', otherwise the operation is prohibited.\n\nBut I am not sure whether I really want this feature in our API. I think it is ok to delete remote tracking branches without given the mode.',NULL,1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/DeleteBranchCommand.java','AAALy3///Co='),(73,5,'2010-10-07 22:07:12','P',1,'You don\'t return a List<Ref> because this would return Refs which are deleted already, right?',NULL,1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/DeleteBranchCommand.java','AAALy3///Cw='),(190,46,'2010-10-08 12:10:05','P',1,'Documented the behavior.','AAALy3///Co=',1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/DeleteBranchCommand.java','AAALy3//++k='),(73,46,'2010-10-08 12:10:05','P',1,'Exactly.','AAALy3///Cw=',1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/DeleteBranchCommand.java','AAALy3//++o='),(1,5,'2010-10-07 22:07:12','P',1,'Missing copyright header',NULL,1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/errors/CannotDeleteCurrentBranchException.java','AAALy3///Cg='),(1,46,'2010-10-08 12:10:05','P',1,'Done','AAALy3///Cg=',1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/errors/CannotDeleteCurrentBranchException.java','AAALy3//++Y='),(188,5,'2010-10-07 22:07:12','P',1,'you didn\'t wanted to change these comment, or?',NULL,1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAALy3///DM='),(183,5,'2010-10-07 22:07:12','P',1,'Trailing whitespace error! Make sure you have our standard jgit preferences active which would delete such whitespaces.',NULL,1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAALy3///DQ='),(188,46,'2010-10-08 12:10:05','P',1,'Done','AAALy3///DM=',1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAALy3//++c='),(183,46,'2010-10-08 12:10:05','P',1,'Done','AAALy3///DQ=',1704,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAALy3//++g='),(114,1,'2010-10-08 01:47:41','P',1,'This isn\'t very useful, because we\'ll only get progress updates when the tasks terminate.  That\'s going to happen about once per core on the server.  If we have 2 cores, we\'ll get an update just before its done saying \"50%\" and then almost immediately another update saying \"100%\"... but it may have taken an hour to reach that point while the threads worked.  :-(\n\nWe need to increment the counter, and set a signal that makes the main thread wake up and update the progress monitor based on the increments that were made to the counter since the last time it observed the counter.',NULL,1707,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/DeltaTask.java','AAALy3///Bs='),(114,1,'2010-10-14 19:00:40','P',1,'Well, normally a ProgressMonitor is *not* thread-safe.  Callers who need one to be are responsible for ensuring that is true.\n\nEGit supplies a thread-safe ProgressMonitor, but only because its invoking JGit from a worker thread and wants the updates visible to the UI thread.  So EGit is responsible for supplying a thread-safe ProgressMonitor to JGit when it calls JGit.\n\nHowever within JGit we assume the ProgressMonitor is \"owned\" by the thread that it is given to.  If that thread then spawns its own helper threads, that spawn site is responsible for making the supplied ProgressMonitor thread-safe.  To do that we wrap it in the ThreadSafeProgressMonitor. Unfortunately it seems that isn\'t compatible with the PipeOutputStream so we need to arrange for a different use of the ThreadSafeProgressMonitor.\n\nI would prefer rewriting ThreadSafeProgressMonitor to use a different API definition and behavior, than to rewrite the pipe stream code.  We can\'t ensure callers won\'t give us the stock J2SE pipe stream types... and if they do we would have this bug you are reporting.  And there is currently only 1 caller in JGit (PackWriter, for threaded delta search).\n\n\nMaybe instead the ThreadSafeProgressMonitor remembers what thread allocated it, and only pushes updates to the underlying ProgressMonitor if they are being made by the allocation thread.  If they are made by a different thread, then the updates are pushed into an update queue that the allocation thread must spin-out through a new public method.\n\nWe\'d have to change some of the logic in PackWriter so that we spin out the update queue of the ThreadSafeProgressMonitor if the tasks are running on background threads.  That gets somewhat ugly because we can\'t easily determine when to stop spinning the queue because the threads are all completed.  One way to do that would be to also associate a worker count-down into the ThreadSafeProgressMonitor.  Use two new APIs to tell it when a worker starts, and when a worker ends.  PackWriter can tell it how many tasks its about to start, and then have each task use a finally block to tell the ThreadSafeProgressMonitor when the task is terminating.  The spin-out method would stop spinning the update queue when the active task count drops to 0.','AAALzH///3o=',1707,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/DeltaTask.java','AAALzH///3M='),(114,89,'2010-10-14 15:07:26','P',1,'But in this case we should do this change everywhere ProgressMonitor associated with PipedInput/OutputStream is used from several threads. Maybe we need piped streams that do not check that writing/reading threads are alive?','AAALy3///Bs=',1707,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/DeltaTask.java','AAALzH///3o='),(801,1,'2010-10-08 01:47:41','P',1,'Like I said in the DeltaTask code, this is too late.  We want the progress updates to occur as the tasks complete some work units, so the user knows we are working and about how far we are through the object set.',NULL,1707,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/PackWriter.java','AAALy3///Bo='),(86,89,'2010-10-20 07:14:58','P',1,'It seems we should call pm.endWorker() here, not pm.endTask().\nWith pm.endWorker() my test is not fail any more.',NULL,1707,2,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/DeltaTask.java','AAALzX///5g='),(86,1,'2010-10-26 18:15:10','P',1,'Done','AAALzX///5g=',1707,2,'org.eclipse.jgit/src/org/eclipse/jgit/storage/pack/DeltaTask.java','AAALzX///vQ='),(185,1,'2010-10-11 18:45:17','P',1,'If you want to wonder about a bad corner case, this is it.  This condition is technically impossible to have happen in PatienceDiff.  We never should be in a recursive step with an EMPTY region.  Its not an issue to ignore the EMPTY block, but this used to throw ISE because it cannot happen if the implementation works correctly.\n\nHistogramDiff has the same thing.  Only its perfectly happy over the same input data to throw ISE on EMPTY (as it never throws ISE).  That tells me PatienceDiff is potentially broken in some other way if it needs this break statement here.',NULL,1720,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/PatienceDiff.java','AAALy3//+6c='),(384,1,'2010-10-11 19:42:12','P',1,'Yes, min/max are because of N and not running time.  I\'ll rename these fields to clarify that.','AAALy3//+7c=',1721,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/debug/DiffAlgorithms.java','AAALy3//+54='),(363,1,'2010-10-11 19:42:12','P',1,'Done','AAALy3//+7g=',1721,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/debug/DiffAlgorithms.java','AAALy3//+58='),(281,1,'2010-10-11 19:42:12','P',1,'Done','AAALy3//+7I=',1721,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/debug/DiffAlgorithms.java','AAALy3//+6A='),(146,1,'2010-10-11 19:42:12','P',1,'Done','AAALy3//+7Q=',1721,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/debug/DiffAlgorithms.java','AAALy3//+6E='),(140,1,'2010-10-11 19:42:12','P',1,'Done','AAALy3//+7M=',1721,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/debug/DiffAlgorithms.java','AAALy3//+6I='),(384,5,'2010-10-11 11:43:35','P',1,'min and max are mini-/maximal because of N, not because of the runtime. Right?',NULL,1721,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/debug/DiffAlgorithms.java','AAALy3//+7c='),(363,5,'2010-10-11 11:43:35','P',1,'shouldn\'t this method be called \'included\' ? I wrongly thought \"include()\" would include something somewhere.',NULL,1721,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/debug/DiffAlgorithms.java','AAALy3//+7g='),(281,5,'2010-10-11 11:43:35','P',1,'This prints as strange heading for the last two columns. I thought the columns titled with \"N=\" string will contain something related to N.\nHere my suggestion:\n\n		out.format(\"Compared bytes per file: min N=%d, max N=%d\\n\", minN,\n				maxN);\n		out.format(\"%-25s %12s ( %12s %12s )\\n\", //\n				\"Algorithm\", \"Time (ns)\", \"Time(ns) on\", \"Time(ns) on\");\n		out.format(\"%-25s %12s ( %12s %12s )\\n\", //\n				\"\", \"\", \"smallest file\", \"biggest file\");\n		out.println(\"-----------------------------------------------------\");',NULL,1721,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/debug/DiffAlgorithms.java','AAALy3//+7I='),(140,5,'2010-10-11 11:43:35','P',1,'I suggest \"Maximum size in KiB to scan per file revision\". I was mislead in believing thats a limit on the whole testcase: when DiffAlgorithms has diffed int total that amount of  bytes he\'ll stop.',NULL,1721,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/debug/DiffAlgorithms.java','AAALy3//+7M='),(146,5,'2010-10-11 11:43:35','P',1,'That\'s a limit on the number of comparisons you\'ll do. If if the repo contains only 1 file we can reach this limit. I suggest \"Number of file revisions to be compared\"',NULL,1721,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/debug/DiffAlgorithms.java','AAALy3//+7Q='),(335,1,'2010-10-14 20:21:22','P',1,'Its impossible for basePath to be on a different file system than tmp.  Above we construct tmp to be a temporary file in the same directory as the file named by basePath.  No system that I know of permits a single directory to have its file contents spread across different file systems such that a rename within that directory would fail.\n\nIts sufficient here to assume that all files in the same directory are part of the same filesystem, and that we can rename safely from a unique temporary file name in that directory to a stable name within the same directory.  If that fails, its either because the stable name already exists (made at the same time by another thread or process perhaps?) OR the filesystem is utter crap and we can\'t work with it.  In the former case we\'ll just retry to read the file made by the other process, and probably succeed at using it.  In the latter case, well, the filesystem is utter crap.  If I can\'t rename a file in the same directory, I can\'t provide most of the data safety rules that Git normally provides.  Users should get a better filesystem.','AAALzH///8Y=',1724,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/LargeDeltaBaseInputStream.java','AAALzH///24='),(135,1,'2010-10-14 20:21:22','P',1,'No, it isn\'t worth enforcing that this be a power of 2.  Its just suggested.  I\'m not going to bother with this check.','AAALzH///8c=',1724,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/LargeDeltaBaseInputStream.java','AAALzH///28='),(135,3,'2010-10-13 20:20:46','P',1,'Worth putting a check with an exception if the block size isn\'t a power of 2? Probably very JIT friendly.\n\nif(desiredBlockSize & desiredBlockSize-1 != 0 )\n  throw new IllegalArgumentException(\"Invalid block size\")',NULL,1724,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/LargeDeltaBaseInputStream.java','AAALzH///8c='),(335,3,'2010-10-13 20:20:46','P',1,'Note that if basePath is on a different filing system (or drive, in Windows, I guess) then the rename operation may fail. We could try a copy if the rename fails. We could read and write the bits to the basePath (or basePath+\"~\" or similar)',NULL,1724,3,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/LargeDeltaBaseInputStream.java','AAALzH///8Y='),(8,5,'2010-10-11 08:24:31','P',1,'Shouldn\'t it be called \"Pull current branch\", \"Pull to current branch\" or \"Pull into current branch\"',NULL,1725,1,'/COMMIT_MSG','AAALy3//+7w='),(7,5,'2010-10-11 12:14:56','P',1,'Now, as I see the resulting menu, it looks strange to me that a lot of other actions look like \"<Action> ....\" but only for Pull we have a full sentence. Especially because the latter part \"into current branch\" bring benefit. A pull will always merge into the current HEAD.\nSo in my eyes \"Pull ...\" would be a better solution.',NULL,1725,3,'/COMMIT_MSG','AAALy3//+68='),(70,46,'2010-10-12 15:37:37','P',1,'Done','AAALy3//+4Y=',1725,4,'org.eclipse.egit.core/src/org/eclipse/egit/core/op/PullOperation.java','AAALy3//+4A='),(70,44,'2010-10-12 14:37:59','P',1,'You can use Activator.error to create an error status.',NULL,1725,4,'org.eclipse.egit.core/src/org/eclipse/egit/core/op/PullOperation.java','AAALy3//+4Y='),(96,46,'2010-10-12 15:37:37','P',1,'Done','AAALy3//+4Q=',1725,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/PullFromUpstreamActionHandler.java','AAALy3//+34='),(40,46,'2010-10-12 15:37:37','P',1,'Moved canMerge() to RepositoryActionHandler','AAALy3//+4U=',1725,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/PullFromUpstreamActionHandler.java','AAALy3//+38='),(96,44,'2010-10-12 14:37:59','P',1,'In case of error the Job framework already sends an error popup and logs the error.',NULL,1725,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/PullFromUpstreamActionHandler.java','AAALy3//+4Q='),(40,44,'2010-10-12 14:37:59','P',1,'Don\'t derice from MergeActionHandler. Extract canMerge to a utility class instead.',NULL,1725,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/PullFromUpstreamActionHandler.java','AAALy3//+4U='),(201,46,'2010-10-12 15:37:37','P',1,'Done','AAALy3//+4M=',1725,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/merge/MergeResultDialog.java','AAALy3//+30='),(201,44,'2010-10-12 14:37:59','P',1,'remove TODO',NULL,1725,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/merge/MergeResultDialog.java','AAALy3//+4M='),(60,46,'2010-10-12 15:37:37','P',1,'It did cause problems, and I had to adjust the other dialogs in order to fix these problems, but I think it is still a better solution than trying to re-implement the result display from scratch.','AAALy3//+4I=',1725,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/pull/PullResultDialog.java','AAALy3//+3w='),(60,44,'2010-10-12 14:37:59','P',1,'Don\'t know if if this reuse of dialogs might cause problems.',NULL,1725,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/pull/PullResultDialog.java','AAALy3//+4I='),(181,1,'2010-10-12 19:21:39','P',1,'Unrelated to this change, but why does this take refs/heads/foo instead of foo?\n\nI expected the command to take \"foo\" and prefix that with R_HEADS for me.  Unless I setRemote(true), in which case it would prefix with R_REMOTES.',NULL,1727,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/DeleteBranchCommand.java','AAALy3//+14='),(340,46,'2010-10-12 15:52:53','P',1,'Done','AAALy3//+3o=',1728,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewBranchHandlingTest.java','AAALy3//+3E='),(274,46,'2010-10-12 15:52:53','P',1,'Done','AAALy3//+3s=',1728,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewBranchHandlingTest.java','AAALy3//+3I='),(267,44,'2010-10-12 15:25:51','P',1,'rest done to false is missing',NULL,1728,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewBranchHandlingTest.java','AAALy3//+3k='),(267,46,'2010-10-12 15:52:53','P',1,'Done','AAALy3//+3k=',1728,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewBranchHandlingTest.java','AAALy3//+3M='),(340,44,'2010-10-12 15:25:51','P',1,'White space error',NULL,1728,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewBranchHandlingTest.java','AAALy3//+3o='),(274,44,'2010-10-12 15:25:51','P',1,'You can use AtomicBoolean for done. Easier to handle and includes synschronization.',NULL,1728,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/view/repositories/GitRepositoriesViewBranchHandlingTest.java','AAALy3//+3s='),(95,1,'2010-10-12 19:31:00','P',1,'The final commit is what is returned when there are multiple commits, right?  So maybe instead say the new HEAD is returned.  What happens if one succeeds and another fails, does the whole command stop, or is HEAD partially updated?',NULL,1734,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALy3//+1c='),(101,1,'2010-10-12 19:31:00','P',1,'Don\'t initialize to null.\n\n  RevWalk revWalk = new RevWalk(repo);\n  try {\n  } finally {\n    revWalk.release();\n  }',NULL,1734,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALy3//+1g='),(143,1,'2010-10-12 19:31:00','P',1,'The loop just stopped.  Shouldn\'t we continue looking at the next commit in the commits collection?',NULL,1734,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALy3//+1Q='),(131,1,'2010-10-12 19:31:00','P',1,'Ugh.  Can we do something to improve the name of setWorkingTreeIt?  Maybe call it setWorkingTreeIterator?\n\nI don\'t know if you have heard, but there is this fancy editor for Java called Eclipse.  You can use Ctrl-Space to ask it to complete aLengthyMethodNameThatIsTooLongToTypeButIsVeryDescriptiveOfItsPurpose, which means using abbreviations isn\'t necessary.  :-)',NULL,1734,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALy3//+1U='),(126,1,'2010-10-12 19:31:00','P',1,'This is faster:\n\n  revWalk.parseHeaders(srcCommit.getParent(0))',NULL,1734,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALy3//+1Y='),(126,5,'2010-10-13 09:32:00','P',1,'I\'ll do. That this line was wrong costed me an hour during development. I only looked up the srcParent RevCommit and when I later set the base of the merge to srcParent.getTree() the base was set to null. Everything succeeded afterwards but of course the merge result was buggy.','AAALy3//+1Y=',1734,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzH////0='),(101,5,'2010-10-13 09:32:00','P',1,'Done','AAALy3//+1g=',1734,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzH////4='),(95,5,'2010-10-13 09:32:00','P',1,'Regarding failure handling. This command should stop after the first failing cherry-pick. HEAD will then point to the result of the last successful cherry-pick. But you are right, how do I then report the overall success of this command. \n\nMy proposal: I\'ll return a RevCommit which points to new HEAD only if all cherry-picks where succesfull. Otherwise null is returned. Additionally I add a getSuccesfullyCherryPickedRefs() to publish a list of all successful cherry-picks.','AAALy3//+1c=',1734,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzH////8='),(143,5,'2010-10-13 09:32:00','P',1,'Done','AAALy3//+1Q=',1734,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzH////Q='),(131,5,'2010-10-13 09:32:00','P',1,'Heard about that editor :-) Of course I can change that. Farewell ugly name! Had some long debugging sessions together and now its time to go.','AAALy3//+1U=',1734,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzH////w='),(96,1,'2010-10-15 00:52:36','P',1,'Style-nit: Constructors should appear before instance methods.',NULL,1734,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzX///+0='),(96,5,'2010-10-15 14:41:21','P',1,'Done','AAALzX///+0=',1734,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzX///+c='),(157,1,'2010-10-15 00:52:36','P',1,'Thanks for fixing; this is better.',NULL,1734,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzX///+k='),(140,1,'2010-10-15 00:52:36','P',1,'You missed changing this:\n\n  revWalk.parseHeaders(srcCommit.getParent(0))',NULL,1734,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzX///+o='),(138,1,'2010-10-15 00:52:36','P',1,'FWIW, there is a use case for cherry-picking commits with more than one parent.  Its called reverting (or replaying) a merge.  In those cases the caller needs to tell us what parent to compare against as an input argument.\n\nI don\'t know how you will implement revert, but keep in mind we will want to come back here and optionally support a different parent when there are more than 1 parents involved.',NULL,1734,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzX///+s='),(124,1,'2010-10-15 00:52:36','P',1,'lookupCommit assumes the thing is a commit.  That should be true, but someone may have manually done something in the repository to make HEAD be a non-commit.\n\nYou should use parseCommit here and take the parsing hit in order to ensure the new parent is actually a commit.  Otherwise we might create a corrupt object where a parent points to something that isn\'t a commit if HEAD was mangled externally.',NULL,1734,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzX///+w='),(140,5,'2010-10-15 14:41:21','P',1,'Done','AAALzX///+o=',1734,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzX///90='),(124,5,'2010-10-15 14:41:21','P',1,'Done','AAALzX///+w=',1734,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzX///94='),(138,5,'2010-10-15 14:41:21','P',1,'got it.','AAALzX///+s=',1734,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/CherryPickCommand.java','AAALzX///9w='),(46,1,'2010-10-15 00:52:36','P',1,'I think this isn\'t the best class name for this meaning of an error.  Maybe call it MulitpleParentsNotSupportedException?',NULL,1734,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/errors/InvalidCherryPickCommit.java','AAALzX///+4='),(46,5,'2010-10-15 14:41:21','P',1,'Done','AAALzX///+4=',1734,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/errors/InvalidCherryPickCommit.java','AAALzX///98='),(3,4,'2010-10-13 21:43:34','P',1,'we want egit to work with java 1.5 and eclipse 3.5.2',NULL,1736,1,'org.eclipse.egit.fetchfactory/.classpath','AAALzH///8I='),(4,4,'2010-10-13 21:43:34','P',1,'we want egit to work with java 1.5 and eclipse 3.5.2',NULL,1736,1,'org.eclipse.egit.fetchfactory/.settings/org.eclipse.jdt.core.prefs','AAALzH///8E='),(4,4,'2010-10-13 21:43:34','P',1,'style nit: trailing whitespace, leave out the blank line',NULL,1736,1,'org.eclipse.egit.fetchfactory/build.properties','AAALzH////o='),(6,3,'2010-10-13 18:16:11','P',1,'Trailing white space again',NULL,1736,1,'org.eclipse.egit.fetchfactory/build.properties','AAALzH///9E='),(8,4,'2010-10-13 21:43:34','P',1,'in general we want egit to work with java 1.5 and eclipse 3.5.2',NULL,1736,1,'org.eclipse.egit.fetchfactory/META-INF/MANIFEST.MF','AAALzH///8A='),(8,17,'2010-10-13 18:58:12','P',1,'Actually, it needs to be 3.7M3 because of a change that went into PDE build just today. Thanks for bringing it up. I need to figure out the correct number.','AAALzH///9M=',1736,1,'org.eclipse.egit.fetchfactory/META-INF/MANIFEST.MF','AAALzH///8k='),(8,3,'2010-10-13 18:16:11','P',1,'Does this need 3.6.1 or can it run with 3.6.0?',NULL,1736,1,'org.eclipse.egit.fetchfactory/META-INF/MANIFEST.MF','AAALzH///9M='),(4,4,'2010-10-13 21:43:34','P',1,'style nit: trailing whitespace, usually we don\'t have a blank line here, look at plugin.properties of other egit bundles',NULL,1736,1,'org.eclipse.egit.fetchfactory/OSGI-INF/l10n/bundle.properties','AAALzH////s='),(5,3,'2010-10-13 18:16:11','P',1,'Trailing whitespace here',NULL,1736,1,'org.eclipse.egit.fetchfactory/OSGI-INF/l10n/bundle.properties','AAALzH///9I='),(4,4,'2010-10-13 21:43:34','P',1,'style nit: trailing whitespace and unusual blank line',NULL,1736,1,'org.eclipse.egit.fetchfactory/plugin.xml','AAALzH///78='),(5,4,'2010-10-13 21:43:34','P',1,'style nit: leave out blank line, stick to a fixed license header',NULL,1736,1,'org.eclipse.egit.fetchfactory/pom.xml','AAALzH///74='),(31,17,'2010-10-13 18:58:12','P',1,'Copied it from the other POMs. Not sure. I\'m not an expert on this subject.','AAALzH///9A=',1736,1,'org.eclipse.egit.fetchfactory/pom.xml','AAALzH///8o='),(31,3,'2010-10-13 18:16:11','P',1,'TYCHO-168 was marked fixed for 0.7.0 - do we still need it here?',NULL,1736,1,'org.eclipse.egit.fetchfactory/pom.xml','AAALzH///9A='),(41,4,'2010-10-13 21:43:34','P',1,'it\'s not excplicitly stated if the generated script relies on native git command line or if it\'s using jgit.',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///68='),(22,4,'2010-10-13 21:43:34','P',1,'typo: s/An <code>/A <code>/',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///70='),(29,4,'2010-10-13 21:43:34','P',1,'missing period to end the sentence',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7A='),(226,4,'2010-10-13 21:43:34','P',1,'style nit: no braces around single line block',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7c='),(375,4,'2010-10-13 21:43:34','P',1,'style nit: inconsistent camel case : repoSpecificEntry',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7E='),(90,4,'2010-10-13 21:43:34','P',1,'style nit: we don\'t use braces around single line blocks',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7g='),(358,4,'2010-10-13 21:43:34','P',1,'style nit: avoid braces around single line block',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7I='),(71,4,'2010-10-13 21:43:34','P',1,'could we use \"gitRepository\" instead? same question for next property',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7k='),(307,4,'2010-10-13 21:43:34','P',1,'style nit: avoid braces around single line block\n\nmore of these below',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7M='),(65,4,'2010-10-13 21:43:34','P',1,'could we use \"repository\" to make this less cryptic ?',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7o='),(243,4,'2010-10-13 21:43:34','P',1,'inconsistent javadoc, tagName is missing\n\nI think it would make sense to describe the meaning of the parameters here (at least I don\'t understand what\'s going on here).',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7Q='),(55,4,'2010-10-13 21:43:34','P',1,'why do we need two constants with the same value?',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7s='),(269,4,'2010-10-13 21:43:34','P',1,'HEAD is a symbolic link pointing to the tip of the currently checked out branch. \"master\" is the default branch similar to trunk in SVN but this is just convention, so probably this should be explicitly specified.','AAALzH///8s=',1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7U='),(52,4,'2010-10-13 21:43:34','P',1,'style nit: unnecessary blank line',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7w='),(239,4,'2010-10-13 21:43:34','P',1,'typo: s/an/a/',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///7Y='),(269,3,'2010-10-13 18:16:11','P',1,'This looks as if it were copied from the CVS one. Does HEAD make sense in a Git checkout anyway? The idea (behind CVS) was to not write out the \'default\' one for everything that needed doing e.g. default to HEAD. Should Git default to \'master\' here instead?',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///84='),(229,3,'2010-10-13 18:16:11','P',1,'Why do we need to do this? This will get rid of common characters, like - _ . which may be perfectly valid as characters in a URL.',NULL,1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///88='),(269,17,'2010-10-13 18:58:12','P',1,'Yeah. It should likely be \"master\". But I\'m not an expert on that topic. Git also uses the term \"HEAD\" which doesn\'t help with reducing confusion on my side. ;)','AAALzH///84=',1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///8s='),(229,17,'2010-10-13 18:58:12','P',1,'That\'s for storing on the local disc. We need to get rid of any chars that could cause issues if they are contained in folder names. Another option would be to use a hash of the URL. But that would make them unreadable in case someone wants to look at the cloned repos.','AAALzH///88=',1736,1,'org.eclipse.egit.fetchfactory/src/org/eclipse/egit/fetchfactory/internal/GITFetchTaskFactory.java','AAALzH///8w='),(169,1,'2010-10-15 00:43:42','P',1,'This call is identical to the one before it on line 164.  Which means its pointless, if the call above returned null, we should get null again here.  I think you meant to test a different key here, but you tested CONFIG_KEY_MERGE again.',NULL,1747,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALzX////A='),(230,1,'2010-10-15 00:43:42','P',1,'FWIW, FetchCommand should always produce FetchResult, unless there was a network error that prevented communication from occurring.  Even if no objects were obtained, there should still be the advertised refs.  If the ref ISN\'T found its an error and you should stop immediately, not fall back on a stale tracking branch that is guessed by naming convention.',NULL,1747,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALzX////E='),(160,1,'2010-10-15 00:43:42','P',1,'Please declare this closer to where it is first initialized.',NULL,1747,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALzX////I='),(188,1,'2010-10-15 00:43:42','P',1,'This comment is wrong.',NULL,1747,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALzX////M='),(160,46,'2010-10-19 06:57:53','P',1,'Done','AAALzX////I=',1747,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALzX///7c='),(230,46,'2010-10-19 06:57:53','P',1,'Done','AAALzX////E=',1747,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALzX///7M='),(188,46,'2010-10-19 06:57:53','P',1,'Done','AAALzX////M=',1747,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALzX///7U='),(169,46,'2010-10-19 06:57:53','P',1,'Duh. Yes, of course. Done. Thanks for pointing it out.','AAALzX////A=',1747,1,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALzX///7Y='),(187,1,'2010-10-28 16:16:11','P',1,'Since we need this twice, maybe we should do:\n\n  final boolean isRemote = !remote.equals(\".\");',NULL,1747,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/PullCommand.java','AAALzX///q4='),(100,46,'2010-10-14 14:08:38','P',1,'Whitespace',NULL,1748,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/test/TestUtil.java','AAALzH///40='),(100,44,'2010-10-14 14:14:59','d',1,'Done','AAALzH///40=',1748,1,'org.eclipse.egit.ui.test/src/org/eclipse/egit/ui/test/TestUtil.java','AAALzH///4I='),(36,44,'2010-10-14 14:16:42','d',1,'Done','AAALzH///4Q=',1748,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/JobFamilies.java','AAALzH///4E='),(36,46,'2010-10-14 14:08:38','P',1,'Unnecessary empty lines',NULL,1748,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/JobFamilies.java','AAALzH///4Q='),(38,4,'2010-10-15 08:48:17','P',1,'exception handling missing, please fix that',NULL,1753,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/repository/tree/command/OpenHistoryCommand.java','AAALzX///+Q='),(7,5,'2010-10-17 22:20:24','P',1,'Done','AAALzX///9g=',1755,1,'/COMMIT_MSG','AAALzX///80='),(7,1,'2010-10-15 19:46:13','P',1,'Typo, you meant DirCacheCheckout.',NULL,1755,1,'/COMMIT_MSG','AAALzX///9g='),(40,4,'2010-10-21 21:42:24','d',1,'typo: s/compare_more/compare_mode/',NULL,1766,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/UIPreferences.java','AAALzX///4A='),(118,4,'2010-10-19 22:11:47','P',1,'I don\'t like the idea to use a SNAPSHOT version',NULL,1770,2,'org.eclipse.jgit.console/pom.xml','AAALzX///60='),(321,1,'2010-10-23 19:00:48','P',1,'OK, but I wouldn\'t call it implicit.  Perhaps this on RefDatabase?\n\n  /**\n   * Get the additional reference-like entities from the repository.\n   *\n   * The result list includes non-ref items such as MERGE_HEAD,\n   * and FETCH_RESULT cast to be refs.\n   */\n  List<Ref> getAdditionalRefs()','AAALzX///2I=',1772,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/RefDirectory.java','AAALzX///14='),(321,5,'2010-10-23 11:55:59','P',1,'Then we are near to a solution. Beeing compatible with C Git is a\nvalid argument for me. I was just not aware about \'git for-each-ref\'\nfunctionality regarding ORIG_HEAD, FETCH_HEAD or\nMERGE_HEAD. Just for being compatible I agree that\nrepo.getAllRefs() should not return the implicit ref-like things\nORIG_HEAD, FETCH_HEAD and MERGE_HEAD (only HEAD\nwill be returned by getAllRefs()).\nMy suggestion: if we would add a \'getImplictRefsNames()\' or even\nonly expose a \'public static String[] implicitRefsNames\' to the\nRefsDatabase my problem is solved.','AAALzX///2Y=',1772,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/RefDirectory.java','AAALzX///2I='),(321,1,'2010-10-23 07:30:19','P',1,'OK, I don\'t have a good answer for you as to why repo.getRef(\"FETCH_HEAD\") works but repo.getAllRefs().containsKey(\"FETCH_HEAD\") should return false.\n\nI can try to justify myself by saying that FETCH_HEAD isn\'t really a ref, and thus isn\'t returned by getAllRefs().  And getRef() just takes its input relative to $GIT_DIR and tries to treat the thing you named as a ref... if it smells enough like a ref to be read as a ref, it is, even if it isn\'t really a ref.  My justification for this getRef() behavior is that it is what is needed to be compatible with C Git, in case someone does something like:\n\n  echo somesha1 >.git/MY_NAME\n  jgit log MY_NAME\n\nI can also try to justify my position by saying that C Git\'s implementation of `git for-each-ref` does not report ORIG_HEAD, FETCH_HEAD or MERGE_HEAD.  JGit\'s getAllRefs() method is our internal API equivalent to `git for-each-ref`.  If we want to behave the same way under the same repository state, we shouldn\'t report those names.\n\nBut it sounds like you disagree with me.  The current behavior is all rooted around mirroring C Git behavior around the same concepts.  I\'m not going to try and say C Git is correct, though I\'m sure that if you ask this sort of stuff over on the C Git list you will get a whole bunch of people trying to justify the way it its, and the real reason is really \"it just is, that\'s just how it evolved over the years, we didn\'t design this stuff, it just got patched and patched and patched and uh... it is the way it it is\".\n\nAs far as adding ORIG_HEAD goes, same deal as above.  `git for-each-ref` doesn\'t recognize ORIG_HEAD, and so getAllRefs() doesn\'t either.  But at least ORIG_HEAD is more like a proper ref... its not like FETCH_HEAD or MERGE_HEAD, because it doesn\'t carry additional data in it.  (Though it has been proposed to add more data onto the end of the file for use during rebase and bisect.)','AAALzX///3U=',1772,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/RefDirectory.java','AAALzX///2Y='),(321,5,'2010-10-21 22:05:48','P',1,'ok, I understand that argument.\n\nOn the other hand: JGit is writing these files! If we write them we should allow applications to read them from us. If for example an IDE integration like EGit wants to show all available refs to their end-users should it really hard-code this list of MERGE_HEAD, ORIG_HEAD, FETCH_HEAD?\nIf this would be strange internal refs with no real-world use case I can understand. But an EGit user might really want to compare to ORIG_HEAD or to fetch a change from gerrit and then rebase current branch on FETCH_HEAD.\nWhats about having an option to getRefs() telling to report also these special refs.','AAALzX///4Y=',1772,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/RefDirectory.java','AAALzX///38='),(321,1,'2010-10-22 00:48:48','P',1,'Repository.readMergeHeads() will return you the content from MERGE_HEAD, or null if the file isn\'t present.  When there is more than one item in the resulting list the UI probably should have a notion of this and offer the user a way to deal with the 2nd, 3rd, etc. items.  Its a UI wart that C Git accepts MERGE_HEAD and always assumes the 1st item.\n\nWe don\'t have a reader for FETCH_HEAD, that\'s true.  We should implement one.  But again here, FETCH_HEAD may have multiple results, and the UI might want to be smarter about how it uses the information that is contained in FETCH_HEAD.  That is, if I say \"cherry-pick FETCH_HEAD\" I might want an option to include the URL and branch that I cherry-picked this from, similar to the way `git pull` works.  And even better, if I say \"merge FETCH_HEAD\" I should be offered a default merge message similar to the way pull would have done it... and that needs the URL and branch data from FETCH_HEAD, data that wouldn\'t normally be available in a Ref object.\n\nSince the two data objects (FETCH_HEAD and MERGE_HEAD) contain different information beyond what a simple Ref is, I think its reasonable to say that these are *not* treated as a Ref and aren\'t returned by default in the Ref collections that an application can access.  If you do want this data, you should inquire for it against Repository... and we already have one of those accessors implemented, we just need FETCH_HEAD to re-create the FetchResult object that the prior fetch() call would have created in-memory anyway.\n\nIf an application Just Doesn\'t Care (tm), it can always do:\n\n  Map<String, Ref> all = repo.getAllRefs();\n  Ref r =  repo.getRef(\"MERGE_HEAD\");\n  if (r != null)\n    r.put(\"MERGE_HEAD\", r);\n  r = repo.getRef(\"FETCH_HEAD\");\n  if (r != null)\n    r.put(\"FETCH_HEAD\", r);\n\nbut my argument above is, applications that want to support these two names in a way that is more sophisticated than simply taking a users-specified revision string and passing it into Repository.resolve(String) should be using other APIs that provide the full richness of the data they are accessing, rather than trying to shoe-horn the data into the rather limited Ref interface.','AAALzX///38=',1772,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/RefDirectory.java','AAALzX///3c='),(321,5,'2010-10-22 13:31:02','P',1,'I agree that FETCH_HEAD and MERGE_HEAD are not really refs because they \npoint potentially to a set of objects and not to a single one. Since there \nare valid use-cases using these ref\'ish objects like refs (e.g. fetching a \nchangeset from gerrit with the commands gerrit publishes) we should support \nusing this ref-like objects as refs as native git does. And yes, we	 \nsupport that already because you can call repo.getRef(\"FETCH_HEAD\") already.\nNothing to be done here. I\'ll only propose a good getter for FETCH_HEAD \nlike for MERGE_HEAD.\n\nOnly one thing is where I disagree: I still think it is responsibility of \nJGit to tell which refs it accept. Let\'s talk Java:\n\nif (repo.getRef(\"FETCH_HEAD\")!=null)\n	assert(repo.getAllRefs().containsKey(\"FETCH_HEAD\"));\n\nCurrently this assert might fail and that looks strange to me. If the \nRefDatabase accepts FETCH_HEAD and returns a single ref then why shouldn\'t \nit be exposed it when asking for all refs? \n\nBy the way: adding ORIG_HEAD to the RefsDatabase is ok, or? We are\nworking on rebase and I would like to offer users the possibility to compare\nwith ORIG_HEAD.','AAALzX///3c=',1772,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/RefDirectory.java','AAALzX///3U='),(321,1,'2010-10-21 17:49:26','P',1,'NAK.  These must not show up in protocol advertisements, etc.  If an application needs them it should read them.\n\nBesides both files are *not* standard ref format.  They can contain more than one ref.  And in FETCH_HEAD\'s case, they also have URL data and branch data.  The fact that they can work like a ref is a bug in the C Git implementation that only looks at the first 40 bytes of a \"ref like file\" to see if it is a SHA-1.  In hindsight we might never have permitted these files to be \"ref like\" by having a stricter ref file parser.',NULL,1772,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/RefDirectory.java','AAALzX///4Y='),(189,5,'2010-10-24 22:42:36','P',1,'Done','AAALzX///1A=',1772,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/RefDatabase.java','AAALzX///00='),(189,1,'2010-10-24 17:08:53','P',1,'This should throw IOException just like getRefs() above does.  We should throw on things like permission denied to read a file that we can see exists.',NULL,1772,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/RefDatabase.java','AAALzX///1A='),(315,1,'2010-10-24 17:08:53','P',1,'I\'m not sure we should eat these exceptions.',NULL,1772,2,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/RefDirectory.java','AAALzX///08='),(315,5,'2010-10-24 22:42:36','P',1,'Done','AAALzX///08=',1772,2,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/RefDirectory.java','AAALzX///0w='),(148,44,'2010-10-21 15:45:38','P',1,'I get this blank on saving!!!',NULL,1779,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALzX///4g='),(182,1,'2010-10-21 17:58:39','P',1,'Doesn\'t AndTreeFilter take a List also?  If so can\'t we make a temporary list here and put the three default items in, then the one conditional user filter?\n\nIf the user filter is a path filter (and it probably is) its faster if its first in the list.  Paths are very cheap to evaluate and they rule out most of the project\'s files.',NULL,1779,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALzX///4I='),(148,1,'2010-10-21 17:53:53','P',1,'Bug in Eclipse.\n\nThe formatter insists on putting a space at the end of a blank Javadoc line.  The formatter runs after the remove trailing space on a blank line during save.\n\nYou can coax it into removing that space by deleting it manually, saving the file, then doing undo right away.  Yes, its crap.  But I don\'t have the time or the energy to debug this part of Eclipse and patch it.','AAALzX///4g=',1779,1,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALzX///4Q='),(176,5,'2010-10-25 08:59:33','P',1,'It\'s a minor thing: But if you add an initial capacity of 4 we save 6 slots (default capacity is 10)',NULL,1779,2,'org.eclipse.jgit/src/org/eclipse/jgit/lib/IndexDiff.java','AAALzX///0I='),(329,44,'2010-10-25 09:00:21','P',1,'Done','AAALzX///3M=',1780,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/CommitActionHandler.java','AAALzX///0A='),(329,5,'2010-10-22 13:54:36','P',1,'is anybody removing these indexDiffs from the cache? If this RepositoryActionHandler is some longliving instance we might consume more memory then needed. After the commitdialog is gone we don\'t need that cache anymore, or? Forget this comment if the CommitActionHandler is instantiated newly for every event.',NULL,1780,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/actions/CommitActionHandler.java','AAALzX///3M='),(276,90,'2010-10-26 09:20:22','d',1,'Proposed a new patch.','AAALzX///zE=',1782,1,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheCheckout.java','AAALzX///wg='),(276,5,'2010-10-25 16:24:10','P',1,'You are right, we can improve performance here. But maybe in a little bit different way as you suggested.\n\nThis looks like a small change but could be very bad regarding\nperformance. Your change will force us to read every single bit of every file in the working tree. The problem is \"m.idEqual(f)\" which triggers the computation of sha-1 on the content of the file in the working tree. I would like to avoid computing the id if it is not necessary. E.g. if the last-modification time of the file is the same as we have in the index we know that the file is the same as in the index and for this one we already know the id.\n\nLook at how WorkingTreeIterator.isModified() is used at the end of processEntry(AbstractTreeIterator h, AbstractTreeIterator m, DirCacheBuildIterator i, WorkingTreeIterator f) to see how we could better decide when to overwrite the file or not.',NULL,1782,1,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheCheckout.java','AAALzX///zE='),(39,11,'2010-10-23 06:53:50','P',1,'This one is a white-space-only change, right?',NULL,1783,2,'org.eclipse.egit.core/pom.xml','AAALzX///2g='),(206,4,'2010-10-23 21:58:03','d',1,'ok, but this doesn\'t work it throws\n\nException in thread \"main\" java.util.IllegalFormatPrecisionException: 8\n	at java.util.Formatter$FormatSpecifier.checkInteger(Formatter.java:2892)\n	at java.util.Formatter$FormatSpecifier.<init>(Formatter.java:2643)\n	at java.util.Formatter.parse(Formatter.java:2480)\n	at java.util.Formatter.format(Formatter.java:2414)\n	at java.util.Formatter.format(Formatter.java:2367)\n	at java.lang.String.format(String.java:2769)\n	at Test.main(Test.java:9)\n\n%08x does the trick see section \"Flags\" in\nhttp://download.oracle.com/javase/1.5.0/docs/api/java/util/Formatter.html#syntax','AAALzX///1k=',1785,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/HttpAuthMethod.java','AAALzX///1c='),(206,1,'2010-10-23 21:23:56','P',1,'IIRC nc needs to be 0 padded to 8 digits.  Which is what I was trying to do with 8.8x.',NULL,1785,1,'org.eclipse.jgit/src/org/eclipse/jgit/transport/HttpAuthMethod.java','AAALzX///1k='),(1,46,'2010-10-27 11:52:15','P',1,'Done','AAALzX///uk=',1801,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/merge/GitMergeEditorInput.java','AAALzX///uA='),(1,4,'2010-10-26 22:43:33','P',1,'missing license header',NULL,1801,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/merge/GitMergeEditorInput.java','AAALzX///uk='),(1,46,'2010-10-27 11:52:15','P',1,'Done','AAALzX///ug=',1801,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/merge/MergeModeDialog.java','AAALzX///t8='),(1,4,'2010-10-26 22:43:33','P',1,'missing license header',NULL,1801,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/merge/MergeModeDialog.java','AAALzX///ug='),(2007,46,'2010-10-28 10:55:13','P',1,'Done','AAALzX///tw=',1801,3,'org.eclipse.egit.ui/plugin.xml','AAALzX///s8='),(2007,4,'2010-10-27 15:03:37','P',1,'really ? this looks like a copy&paste mistake. I would expect MergeToolActionHandler here.',NULL,1801,3,'org.eclipse.egit.ui/plugin.xml','AAALzX///tw='),(805,1,'2010-10-27 14:57:32','P',1,'Makes sense. It does mean we can\'t cache these.  But that\'s better than an infinite loop.  :-)',NULL,1804,1,'org.eclipse.jgit/src/org/eclipse/jgit/storage/file/RefDirectory.java','AAALzX///to='),(14,5,'2010-10-28 19:44:08','P',1,'Done','AAALzX///so=',1809,1,'/COMMIT_MSG','AAALzX///po='),(12,5,'2010-10-28 19:44:08','P',1,'typo, i fixed this','AAALzX///ss=',1809,1,'/COMMIT_MSG','AAALzX///ps='),(9,5,'2010-10-28 19:44:08','P',1,'Done','AAALzX///sk=',1809,1,'/COMMIT_MSG','AAALzX///pw='),(9,1,'2010-10-28 14:21:11','P',1,'Style-nit: You should add:\n\n  Bug: 328551\n\nto the footer before the Change-Id line.',NULL,1809,1,'/COMMIT_MSG','AAALzX///sk='),(14,1,'2010-10-28 14:21:11','P',1,'Style-nit:  I would put a blank line before here to separate the two paragraphs (what the issue is, and then what the fix is).',NULL,1809,1,'/COMMIT_MSG','AAALzX///so='),(12,1,'2010-10-28 14:21:11','P',1,'What commit is this?  I can\'t find it in the JGit project.',NULL,1809,1,'/COMMIT_MSG','AAALzX///ss='),(68,79,'2010-10-29 11:05:00','P',1,'Done','AAALzX///rA=',1810,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/merge/MergeMessageFormatterTest.java','AAALzX///os='),(65,79,'2010-10-29 11:05:00','P',1,'Done','AAALzX///rE=',1810,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/merge/MergeMessageFormatterTest.java','AAALzX///ow='),(68,1,'2010-10-28 16:09:32','P',1,'Style-nit: Insert a blank line right here.',NULL,1810,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/merge/MergeMessageFormatterTest.java','AAALzX///rA='),(65,1,'2010-10-28 16:09:32','P',1,'Style-nit: Insert a blank line right here.',NULL,1810,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/merge/MergeMessageFormatterTest.java','AAALzX///rE='),(142,79,'2010-10-29 11:05:00','P',1,'Yeah, I looked first on Ref if there\'s already a method for this and didn\'t find it so I implemented it myself.\n\nSo should I refactor Ref to be an abstract class? Or introduce an \"AbstractRef\"? (No, that would be ugly for the static method, i.e. AbstractRef.shortenRefName) Or a utility class called Refs a la Guava? Meh.','AAALzX///rU=',1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///og='),(124,79,'2010-10-29 11:05:00','P',1,'Done','AAALzX///rM=',1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///ok='),(67,79,'2010-10-29 11:34:21','P',1,'In MergeCommand, the following Ref is created for an include as above:\n\nnew ObjectIdRef.Unpeeled(Storage.LOOSE, name, commit.copy())\n\nThe problem is, how can MergeMessageFormatter distinguish this case from the case where just a SHA1 was specified to be merged?\n\nAFAICS, EGit can\'t yet merge a commit directly, only a branch. I don\'t know what the Ref is going to be for a SHA1-referenced commit.','AAALzX///oo=',1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///oM='),(67,79,'2010-10-29 11:05:00','P',1,'I just saw that PullCommand does the following:\n\n		merge.include(\"branch \\\'\" + remoteBranchName + \"\\\' of \" + remoteUri,\n				commitToMerge);\n\nSo we already get the right remote URI from the Ref, I have to check if this case is handled properly in MergeMessageFormatter.','AAALzX///rY=',1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///oo='),(104,79,'2010-10-29 11:05:00','P',1,'Done','AAALzX///rI=',1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///qc='),(76,79,'2010-10-29 11:05:00','P',1,'Done','AAALzX///rg=',1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///qg='),(83,79,'2010-10-29 11:05:00','P',1,'As far as I could see, C Git also puts the full SHA-1, therefore I went with that. For example, see the message of b54410085b89845b2a76340ee09b75189f18107d in the egit repository.','AAALzX///rc=',1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///qw='),(83,1,'2010-10-28 16:09:32','P',1,'If ref.getName() is a commit SHA-1 do we want to abbreviate it here instead of putting the full 40 digits?  Since this is the summary line and the full 40 digits is available in the parent pointer anyway, it might make the message cleaner to read if we just abbreviate it at 7 digits.\n\nDoing the abbreviation will require you to pass in the current ObjectReader to the constructor of the formatter.',NULL,1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///rc='),(76,1,'2010-10-28 16:09:32','P',1,'Style-nit: We don\'t use { } around the statements when there is only one statement being nested.\n\nI would also put a blank line before each else if to make the code more readable:\n\n  if (ref.getName().startsWith(Constants.R_HEADS))\n    branches.add(...);\n\n  else if (ref.getName().startsWith(Constants.R_REMOTES))\n    remoteBranches.add(...);',NULL,1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///rg='),(104,1,'2010-10-28 16:09:32','P',1,'Instead of testing that the short name is master... I would test the full name:\n\n  if (target.getName().equals(Constants.R_HEADS + Constants.MASTER))\n\nThat way we don\'t accidentally use the \"merge into master format\" if someone manages to make us merge into a branch called \"refs/mynames/master\".',NULL,1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///rI='),(124,1,'2010-10-28 16:09:32','P',1,'Not a bad idea.  It might be worth moving this and the join(Collection<String>, String) above.',NULL,1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///rM='),(142,1,'2010-10-28 16:09:32','P',1,'Yup.  Repository.shortenRefName().  Unfortunately its not static, even though it doesn\'t use any local state.  You might want to consider refactoring that method to be static first so you can reuse it here.\n\nActually, I\'m inclined to say it should move to Ref (which is hard because Ref is an interface and not an abstract class) and be both static and an instance member:\n\n  public static String shortenRefName(String refName);\n\n  public String getShortName() {\n    return shortenRefName(getName());\n  }',NULL,1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///rU='),(67,1,'2010-10-28 16:09:32','P',1,'C Git also takes in the URIish so that during a pull we can include the URL that was given on the command line when performing the merge.\n\nIf we are merging a remote tracking branch, I wonder if we should also infer the URL from the configuration file.  IIRC git gui does that when it generates a merge using a local tracking branch.',NULL,1810,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzX///rY='),(129,1,'2010-11-05 21:28:10','P',1,'Lets just make Repository.shortenRefName static, and use that instead of getShortName above.',NULL,1810,2,'org.eclipse.jgit/src/org/eclipse/jgit/merge/MergeMessageFormatter.java','AAALzn///5g='),(74,1,'2010-10-29 22:58:22','P',1,'We might need a #ifdef around these lines, not every platform has nsec available.  When its not supported, we need to fill with 0.',NULL,1815,1,'jgitnative/lstat.c','AAALzX///mc='),(106,1,'2010-10-29 22:58:22','P',1,'Probably fine, but ENOENT or ENOTDIR are likely failures, failures we may wish to make more obvious to the Java code.\n\nSo we should make those more easily detectable than relying on checking the translated platform error string.',NULL,1815,1,'jgitnative/lstat.c','AAALzX///mg='),(106,4,'2010-10-30 00:04:13','P',1,'yeah, will throw specific exceptions here','AAALzX///mg=',1815,1,'jgitnative/lstat.c','AAALzX///mM='),(74,4,'2010-10-30 00:04:13','P',1,'yup, I\'ll add an #ifdef\n\nmacosx, x86_64 fills that with 0 \n\nNot sure which platforms we want to support here. \nI would say at least:\n- macosx, x86_64\n- linux, x86 and x86_64\n- windows, x86 and x86_64\n\nAny other ? The challenge will be to setup the central\nbuild for all the platforms.','AAALzX///mc=',1815,1,'jgitnative/lstat.c','AAALzX///mQ='),(84,4,'2010-10-28 22:33:11','P',1,'these printf calls will be removed',NULL,1815,1,'jgitnative/lstat.c','AAALzX///pU='),(90,1,'2010-10-29 22:58:22','P',1,'Should we use java.io.File here and have the wrapper unpack to String with getAbsolutePath()?',NULL,1815,1,'org.eclipse.jgit.macosx_x86_64/src/org/eclipse/jgit/util/fs/os/NativeFSAccess.java','AAALzX///mo='),(90,4,'2010-10-30 00:04:13','P',1,'good idea, I will do that','AAALzX///mo=',1815,1,'org.eclipse.jgit.macosx_x86_64/src/org/eclipse/jgit/util/fs/os/NativeFSAccess.java','AAALzX///mU='),(53,4,'2010-10-28 22:33:11','P',1,'will be removed',NULL,1815,1,'org.eclipse.jgit.macosx_x86_64/src/org/eclipse/jgit/util/fs/os/NativeFSAccess.java','AAALzX///pQ='),(65,4,'2010-10-30 00:04:13','P',1,'ok, that\'s better, I also didn\'t like reflection, I was too tired looking at the manifests to spot a better solution ;-)','AAALzX///mk=',1815,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAALzX///mI='),(65,1,'2010-10-29 22:58:22','P',1,'FWIW, this stuff should go in the static initializer of the class.\n\nWe should also use an interface to bridge the two together, that is the NativeFSAccess should extend the abstract FSAccess class and implement the abstract virtual methods that are defined.  That way at runtime we are only dispatching through the abstract method rather than through reflection.',NULL,1815,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAALzX///mk='),(106,4,'2010-11-19 23:39:28','P',1,'yeah','AAALzn///2o=',1815,2,'jgitnative/lstat.c','AAALz3////s='),(98,4,'2010-11-19 23:39:28','P',1,'Done','AAALzn///2s=',1815,2,'jgitnative/lstat.c','AAALz3////w='),(106,1,'2010-11-08 21:39:54','P',1,'That will be an API change, in a public API.  But we should do it once we can drop support for Java 6.  Which is years away from now.',NULL,1815,2,'jgitnative/lstat.c','AAALzn///2o='),(98,1,'2010-11-08 21:39:54','P',1,'We should also special case EACCES here.  Not being able to access part of the directory path is a reasonable failure that we can expect to happen, and should translate into a useful error message for the end user.\n\nBut other errors like EFAULT, EIO, ELOOP, ENAMETOOLONG all seem like things we can say \"should never happen\", and if they do, tossing up the generic LStatException is probably fine.',NULL,1815,2,'jgitnative/lstat.c','AAALzn///2s='),(77,4,'2010-11-19 23:39:28','P',1,'Done','AAALzn///2g=',1815,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/fs/FSAccessTest.java','AAAL0H///1c='),(79,4,'2010-11-19 23:39:28','P',1,'Done','AAALzn///2c=',1815,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/fs/FSAccessTest.java','AAAL0n///+A='),(68,4,'2010-11-19 23:39:28','P',1,'Done','AAALzn///2k=',1815,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/fs/FSAccessTest.java','AAAL0n///+E='),(93,4,'2010-11-19 23:39:28','P',1,'this was pure coincidence, I also like the answer :-)','AAALzn///2Y=',1815,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/fs/FSAccessTest.java','AAAL0n///98='),(79,1,'2010-11-08 21:39:54','P',1,'Depends on the operating system, doesn\'t it?  On Win32 we probably will be setting all of these to 0 (except mode) because there isn\'t a sane concept of device or inode there, nor is there a great way to say the \"group\" or \"user\" of a file, since they use ACLs as their only access control system.\n\nHowever, you could expose a package-only visible native method that tells you the *type* of the JNI support that is loaded (e.g. isPOSIX() method) and have the unit test probe that before making these assertions.  That way on Win32 we can assert that these are in fact 0.',NULL,1815,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/fs/FSAccessTest.java','AAALzn///2c='),(77,1,'2010-11-08 21:39:54','P',1,'I don\'t think that is true.  It should only be true if the file was created and never written to, e.g. by the creat(2) system call.  I think its legal for close(2) to update the mtime of a file after it was opened for writing, where the open call set the ctime.  So I don\'t think we should rely on this assumption in our unit test.\n\nHowever, we should be able to rely on mtime being >= ctime.',NULL,1815,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/fs/FSAccessTest.java','AAALzn///2g='),(68,1,'2010-11-08 21:39:54','P',1,'This is going to suck, but we need to test both implementations.  If the native implementation doesn\'t load, we should abort the test with a failure.\n\nWe can use a system property to disable the native implementation test.  Developers who are trying to build JGit and can\'t run the native implementation on their platform would just need to define the system property on the Maven command line to bypass it.  So something like:\n\n  public void test_lstat_native() throws Exception {\n    if (!Boolean.valueOf(\"org.eclipse.jgit.fs.native\"))\n      return;\n\n    FSAccess native = new FSAccessNative();\n    ...somehow assert native has native JNI loaded...\n    do_lstat(native);  \n  }\n\n  public void test_lstat_java() throws Exception {\n    do_lstat(new FSAccessJava());\n  }\n\n  private void do_lstat(FSAccess imp) throws Exception {\n    ... this test method ...\n  }',NULL,1815,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/fs/FSAccessTest.java','AAALzn///2k='),(93,1,'2010-11-08 21:39:54','P',1,'Haha.  I love how you defined the text to fit a particular answer.  :-)',NULL,1815,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/util/fs/FSAccessTest.java','AAALzn///2Y='),(8,4,'2010-11-19 23:39:28','P',1,'we don\'t need this line',NULL,1815,2,'org.eclipse.jgit/META-INF/MANIFEST.MF','AAALzn///3g='),(67,4,'2010-11-19 23:39:28','P',1,'Done','AAALzn///3Q=',1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAALz3////Q='),(90,4,'2010-11-19 23:39:28','P',1,'Done','AAALzn///3M=',1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAALz3///+0='),(84,4,'2010-11-19 23:39:28','P',1,'Done','AAALzn///3U=',1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAALz3///+4='),(90,1,'2010-11-08 21:39:54','P',1,'Please document that lstat() returns data about a symbolic link and not the target of the link.',NULL,1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAALzn///3M='),(67,1,'2010-11-08 21:39:54','P',1,'We should store the exceptions that were thrown in a static member, and make it accessible so GUIs can help a user resolve a native library load failure:\n\n  private static Throwable nativeLoadError;\n\n  public static Throwable getNativeImplementationLoadException() {\n    return nativeLoadError;\n  }\n\nThat resolves the problem you have here about logging to System.out.println() when it doesn\'t load.  :-)',NULL,1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAALzn///3Q='),(84,1,'2010-11-08 21:39:54','P',1,'Make this an abstract member and return true in FSAccessNative and false in FSAccessJava.',NULL,1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAALzn///3U='),(18,4,'2010-11-19 23:39:28','P',1,'Done','AAALzn///24=',1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessJava.java','AAALz3///+c='),(1,4,'2010-11-19 23:39:28','P',1,'Done','AAALzn///28=',1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessJava.java','AAALz3///+Y='),(18,1,'2010-11-08 21:39:54','P',1,'Don\'t truncate the length.  The lstatNative API needs to supply the length as a 64 bit value.  Which means you may need to use an int[11] and split the 64 bit value into two segments, and put it back together in Java.  Or make the members of the LStat object package accessible and populate them directly inside of the JNI code.  (I say this never having written JNI code... but it must be possible to freeze an object\'s location in memory and then populate its fields via some sort of set int or set long JNI operation.)',NULL,1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessJava.java','AAALzn///24='),(1,1,'2010-11-08 21:39:54','P',1,'Missing copyright header.',NULL,1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessJava.java','AAALzn///28='),(62,4,'2010-11-19 23:39:28','P',1,'Done','AAALzn///3E=',1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessNative.java','AAALz3///+Q='),(52,4,'2010-11-19 23:39:28','P',1,'Done','AAALzn///3I=',1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessNative.java','AAALz3///+U='),(96,1,'2010-11-08 21:39:54','P',1,'I wonder if we can get away with getPath() here instead of getAbsolutePath().  If the application was given a relative path into the java.io.File object, its relative to the JVM\'s current working directory, which cannot be changed.  That can be easily passed down into the native layer, can\'t it?\n\nThe advantage would be that in some applications we might be able to avoid VFS traversal up to the root, and then traversal back down on every file we lstat() in the working directory.  For C Git this actually makes a performance difference on Linux, even though the VFS on Linux is incredibly fast.',NULL,1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessNative.java','AAALzn///3A='),(62,1,'2010-11-08 21:39:54','P',1,'Should this be package visible only?',NULL,1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessNative.java','AAALzn///3E='),(52,1,'2010-11-08 21:39:54','P',1,'Drop this static ctor?',NULL,1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessNative.java','AAALzn///3I='),(67,1,'2010-11-08 21:39:54','P',1,'Style-nit: Unnecessary blank line.',NULL,1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/LStat.java','AAALzn///20='),(145,1,'2010-11-08 21:39:54','P',1,'This should be a long.',NULL,1815,2,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/LStat.java','AAALzn///2w='),(130,4,'2010-11-24 23:21:59','P',1,'missed to throw the exception :-(',NULL,1815,4,'jgitnative/lstat.c','AAAL0n///1g='),(92,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///40=',1815,4,'jgitnative/lstat.c','AAAL0n///3E='),(91,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///44=',1815,4,'jgitnative/lstat.c','AAAL0n///3I='),(92,1,'2010-11-23 23:22:31','P',1,'This expression is wrong.  You want the upper 32 bits here, but only if st_size is > 4:\n\n  if (sizeof(finfo.st_size) == 8)\n    elems[10] = (jint) (finfo.st_size >> 32);\n  else\n    elems[10] = 0;',NULL,1815,4,'jgitnative/lstat.c','AAAL0n///40='),(91,1,'2010-11-23 23:22:31','P',1,'This shouldn\'t require a cast to long.  Casting to jint should cast to a 32 bit value, which will truncate the upper bits (if any) and leave you with the low 32.  So this is just:\n\n  elems[9] = (jint) finfo.st_size;',NULL,1815,4,'jgitnative/lstat.c','AAAL0n///44='),(73,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///5Y=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/AccessDeniedException.java','AAAL0n///24='),(50,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///5c=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/AccessDeniedException.java','AAAL0n///28='),(49,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///5g=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/AccessDeniedException.java','AAAL0n///3A='),(50,1,'2010-11-23 23:22:31','P',1,'I would reword this and say, \"as soon as Java 7 is our minimum supported platform\".',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/AccessDeniedException.java','AAAL0n///5c='),(49,1,'2010-11-23 23:22:31','P',1,'Style-nit: Trailing whitespace.',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/AccessDeniedException.java','AAAL0n///5g='),(73,1,'2010-11-23 23:22:31','P',1,'Should we localize this?',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/AccessDeniedException.java','AAAL0n///5Y='),(57,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///5s=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAAL0n///20='),(96,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///5k=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAAL0n///2s='),(72,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///5o=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAAL0n///2w='),(96,1,'2010-11-23 23:22:31','P',1,'Style-nit: Trailing space.',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAAL0n///5k='),(72,1,'2010-11-23 23:22:31','P',1,'Style-nit: Braces aren\'t necessary here.',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAAL0n///5o='),(57,1,'2010-11-23 23:22:31','P',1,'Minor style-nit:  I prefer these to be one line:\n\n  /** The only instance of FSAccess. */',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccess.java','AAAL0n///5s='),(74,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///48=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessJava.java','AAAL0n///2o='),(74,1,'2010-11-23 23:22:31','P',1,'Isn\'t this behavior different from the native ENOENT case?  When the file doesn\'t exist:\n\nIn FSAccessJava you are returning an apparently valid LStat with the mode REGULAR_FILE, but -1 for lastModified and file length.\n\nIn FSAccessNative I think you are throwing NoSuchFileException.\n\nThe Java code needs to trap that, doesn\'t it?\n\n  long sz = file.length();\n  if (sz < 0)\n    throw new NoSuchFileExeption(file);\n\n  return new LStat(file.lastModified(), mode, sz);',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessJava.java','AAAL0n///48='),(103,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///5U=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessNative.java','AAAL0n///14='),(103,1,'2010-11-23 23:22:31','P',1,'Should we localize this string?',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessNative.java','AAAL0n///5U='),(55,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///5M=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/LStat.java','AAAL0n///10='),(102,4,'2010-11-24 23:21:59','P',1,'Done.\n\nThe compiler prevents the second cast saying that is unnecessary.','AAAL0n///5Q=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/LStat.java','AAAL0n///1w='),(55,1,'2010-11-23 23:22:31','P',1,'We probably need to slap \"Fix this before 2038\" warning here, and update that bug about JGit 2038 issues.  See RevCommit for an example of the warning I put on it.\n\nDirCacheEntry probably also needs a warning for its P_MTIME slot.  We can add that later.',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/LStat.java','AAAL0n///5M='),(102,1,'2010-11-23 23:22:31','P',1,'This is going to overflow as its all computed as an int.  Also, the precedence of + and << isn\'t that widely known, so we prefer to wrap with () here to make the order of operations clear to everyone.\n\nSo instead:\n\n  size = ((long)rawlstat[9]) + (((long)rawlstat[10]) << 32);\n\nFWIW, given that almost everywhere else we use big endian ordering, its weird to see the high 32 bits of the size occur later in the array than the low 32 bits.',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/LStat.java','AAAL0n///5Q='),(73,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///5E=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/NoSuchFileException.java','AAAL0n///1o='),(50,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///5I=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/NoSuchFileException.java','AAAL0n///1s='),(73,1,'2010-11-23 23:22:31','P',1,'Translate this?',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/NoSuchFileException.java','AAAL0n///5E='),(50,1,'2010-11-23 23:22:31','P',1,'\"As soon as Java 7 is our minimum supported platform\".',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/NoSuchFileException.java','AAAL0n///5I='),(50,4,'2010-11-24 23:21:59','P',1,'Done','AAAL0n///5A=',1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/NotDirectoryException.java','AAAL0n///1k='),(50,1,'2010-11-23 23:22:31','P',1,'\"As soon as Java 7 is our minimum supported platform\".',NULL,1815,4,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/NotDirectoryException.java','AAAL0n///5A='),(101,4,'2010-11-25 23:45:04','P',1,'Done','AAAL0n///zQ=',1815,7,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessNative.java','AAAL0n///w8='),(101,1,'2010-11-25 17:52:55','P',1,'I\'m still not sure we need the absolute path here to go into the native layer.  From what I understand of the JRE, you can\'t change the current working directory, so it should be OK to use a relative path as returned by getPath().  Which avoids unnecessary VFS traversals on some systems.\n\nBut whatever.  We can optimize later if its worth it.  This is at least going to ensure an accurate path is passed into the native code.',NULL,1815,7,'org.eclipse.jgit/src/org/eclipse/jgit/util/fs/FSAccessNative.java','AAAL0n///zQ='),(52,4,'2010-12-14 11:41:04','d',1,'style nit: trailing whitespace',NULL,1815,9,'libjgit_native/src/init.c','AAAL1n///9g='),(103,4,'2010-12-14 11:42:06','d',1,'style nit: trailing whitespace',NULL,1815,9,'libjgit_native/src/lstat.c','AAAL1n///9c='),(530,79,'2010-10-31 16:32:07','P',1,'I just thought \"explicit is better than implicit\". No problem, I\'ll silence it.','AAALzX///nw=',1823,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/TemporaryBuffer.java','AAALzX///ko='),(530,4,'2010-10-30 00:07:45','P',1,'you may silence the erring analyzer by adding another filter to the exclude filters','AAALzX///nw=',1823,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/TemporaryBuffer.java','AAALzX///mA='),(530,1,'2010-10-29 14:43:05','P',1,'This is stupid.  The code analyzer is wrong.\n\nThese variables are required to be initialized to 0 by the JRE.  We don\'t initialize them ourselves.',NULL,1823,1,'org.eclipse.jgit/src/org/eclipse/jgit/util/TemporaryBuffer.java','AAALzX///nw='),(14,46,'2010-11-02 10:20:46','P',1,'Done','AAALzX///lE=',1825,1,'/COMMIT_MSG','AAALzn///9s='),(14,4,'2010-10-30 22:20:20','P',1,'looks like this is a separate change',NULL,1825,1,'/COMMIT_MSG','AAALzX///lE='),(152,46,'2010-11-02 10:20:46','P',0,'Done','AAALzX///lI=',1825,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAALzn///9k='),(166,46,'2010-11-02 10:20:46','P',1,'Done','AAALzX///lM=',1825,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAALzn///9o='),(152,4,'2010-10-30 22:20:20','P',0,'incomplete sentence',NULL,1825,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAALzX///lI='),(166,4,'2010-10-30 22:20:20','P',1,'redundant \"to\": s/repoPath to/repoPath/',NULL,1825,1,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAALzX///lM='),(14,4,'2010-11-01 22:43:07','P',1,'better use version range [0.10,0.11)',NULL,1826,2,'org.eclipse.egit.relengtools/META-INF/MANIFEST.MF','AAALzn////8='),(447,4,'2010-11-01 22:43:07','P',1,'style nit (see also other occurrences): we don\'t use curly braces around single line blocks',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/BuildNotesPage.java','AAALzn////0='),(438,4,'2010-11-01 22:43:07','P',1,'commented out code, why do we need that ?',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/BuildNotesPage.java','AAALzn////4='),(37,4,'2010-11-01 22:43:07','P',1,'this hardcodes against Bugzilla, shouldn\'t the class name reflect that ?\n\nmissing JavaDoc for public class',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/GetBugsOperation.java','AAALzn////s='),(77,4,'2010-11-01 22:43:07','P',1,'commented out code, why do we need to commit that ?',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/GetBugsOperation.java','AAALzn////w='),(42,4,'2010-11-01 22:43:07','P',1,'I do not understand this sentence',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/MapContentDocument.java','AAALzn////o='),(194,4,'2010-11-01 22:43:07','P',1,'something is wrong in this sentence, maybe you meant s/when to/when two/ ?',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/MapEntry.java','AAALzn////c='),(108,4,'2010-11-01 22:43:07','P',1,'why is parsing called init ?',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/MapEntry.java','AAALzn////g='),(89,4,'2010-11-01 22:43:07','P',1,'either add comment or remove it completely',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/MapEntry.java','AAALzn////k='),(314,4,'2010-11-01 22:43:07','P',1,'how does this relate to git ?',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/MapEntry.java','AAALzn////U='),(234,4,'2010-11-01 22:43:07','P',1,'that sounds strange in the context of a piece of git related coding',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/MapEntry.java','AAALzn////Y='),(160,4,'2010-11-01 22:43:07','P',1,'commented out code ?',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/MapFile.java','AAALzn////M='),(33,4,'2010-11-01 22:43:07','P',1,'missing javadoc',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/MapFile.java','AAALzn////Q='),(205,4,'2010-11-01 22:43:07','P',1,'below you claim that you handle these operations',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/MapProject.java','AAALzn////A='),(191,4,'2010-11-01 22:43:07','P',1,'typo: s/Listner/Listener/',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/MapProject.java','AAALzn////E='),(148,4,'2010-11-01 22:43:07','P',1,'de facto this is an empty implementation, why this commented out code ?',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/MapProject.java','AAALzn////I='),(44,4,'2010-11-01 22:43:07','P',1,'missing javadoc',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/MapProjectSelectionPage.java','AAALzn///+8='),(27,4,'2010-11-01 22:43:07','P',1,'same question here',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/Messages.java','AAALzn///+0='),(23,4,'2010-11-01 22:43:07','P',1,'anything missing here or should this comment simply be deleted?',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/Messages.java','AAALzn///+4='),(179,4,'2010-11-01 22:43:07','P',1,'you could use a char literal instead of a String',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/OrderedMap.java','AAALzn///+w='),(182,4,'2010-11-01 22:43:07','P',1,'commented out code',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/ReleaseWizard.java','AAALzn///+c='),(164,4,'2010-11-01 22:43:07','P',1,'commented out code',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/ReleaseWizard.java','AAALzn///+g='),(143,4,'2010-11-01 22:43:07','P',1,'commented out code',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/ReleaseWizard.java','AAALzn///+k='),(77,4,'2010-11-01 22:43:07','P',1,'is that intended ?',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/ReleaseWizard.java','AAALzn///+o='),(30,4,'2010-11-01 22:43:07','P',1,'missing javadoc',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/ReleaseWizard.java','AAALzn///+s='),(197,4,'2010-11-01 22:43:07','P',1,'commented out code',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/ReleaseWizard.java','AAALzn///+Y='),(28,4,'2010-11-01 22:43:07','P',1,'missing javadoc',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/RepoCheck.java','AAALzn///+U='),(40,4,'2010-11-01 22:43:07','P',1,'missing javadoc\n\nis this a test class ? If yes class and package name should reflect that',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/ShowInfoHandler.java','AAALzn///+M='),(1,4,'2010-11-01 22:43:07','P',1,'missing license header',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/ShowInfoHandler.java','AAALzn///+Q='),(26,4,'2010-11-01 22:43:07','P',1,'missing javadoc',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/TagAndReleaseHandler.java','AAALzn///+I='),(83,4,'2010-11-01 22:43:07','P',1,'missing javadoc',NULL,1826,2,'org.eclipse.egit.relengtools/src/org/eclipse/egit/relengtools/internal/TagPage.java','AAALzn///+E='),(80,1,'2010-11-01 21:09:33','P',1,'Done','AAALzX///lU=',1829,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/HistogramDiffTest.java','AAALzX///kM='),(80,5,'2010-10-30 15:45:47','P',1,'That is not an INSERT of \"njD\" but an insert of \"jTn\", right?',NULL,1829,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/HistogramDiffTest.java','AAALzX///ls='),(80,4,'2010-10-30 22:04:55','P',1,'yeah, should be jTn',NULL,1829,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/diff/HistogramDiffTest.java','AAALzX///lU='),(126,1,'2010-11-01 21:09:33','P',1,'Comment fixed.','AAALzX///lo=',1829,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/HistogramDiffIndex.java','AAALzX///kI='),(126,5,'2010-10-30 15:45:47','P',1,'Sorry, I don\'t understand this comment. What is in recIdx?',NULL,1829,1,'org.eclipse.jgit/src/org/eclipse/jgit/diff/HistogramDiffIndex.java','AAALzX///lo='),(9,1,'2010-11-01 21:10:05','P',1,'Done','AAALzX///lc=',1830,1,'/COMMIT_MSG','AAALzX///j0='),(9,4,'2010-10-30 21:58:04','P',1,'typo s/evaulate/evaluate/',NULL,1830,1,'/COMMIT_MSG','AAALzX///lc='),(67,5,'2010-11-12 23:23:12','P',1,'I can\'t imagine the reason for this commit? There is no content yet available. Is it only to create a master branch. The first real commit will create this branch and there will no sideeffects anymore by this commit. I would just remove this line.',NULL,1832,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java','AAAL0H///x8='),(111,5,'2010-11-12 23:23:12','P',1,'We should at least once test that we are switching to a branch which not pointing to the current head. One check where you switch from test to master and check that the content has changed afterwards.',NULL,1832,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java','AAAL0H///xk='),(82,5,'2010-11-12 23:23:12','P',1,'I am not sure whether you have created what you wanted. You have three commits and two branches (master and test) which both point to the last commit. Thats what you wanted?\n\nI would have expected something like:\n\n	protected void setUp() throws Exception {\n		super.setUp();\n		git = new Git(db);\n\n		// commit something\n		writeTrashFile(\"Test.txt\", \"Hello world\");\n		git.add().addFilepattern(\"Test.txt\").call();\n		initialCommit = git.commit().setMessage(\"Initial commit\").call();\n\n		// create a master branch and switch to it\n		git.branchCreate().setName(\"test\").call();\n		RefUpdate rup = db.updateRef(Constants.HEAD);\n		rup.link(\"refs/heads/test\");\n\n		// commit something on the test branch\n		writeTrashFile(\"Test.txt\", \"Some change\");\n		git.add().addFilepattern(\"Test.txt\").call();\n		secondCommit = git.commit().setMessage(\"Second commit\").call();\n	}',NULL,1832,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java','AAAL0H///xo='),(72,5,'2010-11-12 23:23:12','P',1,'The master branch is already created by the previous commit. And that branch already points exactly to that commit you are creating the branch and do a refupdate. Just skip the next 5 lines.',NULL,1832,2,'org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java','AAAL0H///xs='),(132,5,'2010-11-12 23:23:12','P',1,'You don\'t need the two getId() calls. What you get back from getTree is already sufficient.',NULL,1832,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/CheckoutCommand.java','AAAL0H///xc='),(65,5,'2010-11-12 23:23:12','P',1,'currently checking out only pathes is not supported.',NULL,1832,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/CheckoutCommand.java','AAAL0H///xg='),(120,5,'2010-11-18 11:03:02','P',1,'this will lead to reflog\'s like: \"checkout: moving from HEAD\". We want to deref headRef to get to the branch name HEAD points to. Something like headRef.getTarget().getName(). Maybe we have to take care that headRef.getTarget() is not null.',NULL,1832,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CheckoutCommand.java','AAAL0n////8='),(252,5,'2010-11-18 11:03:02','P',1,'Thats hard to understand. You accept a parameter called \"startPoint\" but you will always set the class attribute \"startPoint\" to null. If we would call the parameter startCommit instead of startPoint the code would look clearer.\n\nI guess the same comment is also true for some other commands. I\'ll check and fix them also.',NULL,1832,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CheckoutCommand.java','AAAL0X///94='),(111,5,'2010-11-18 11:03:02','P',1,'Don\'t you want to call setUpstreamMode() only when upstreamMode is different from null? Either we give a DefaultValue to upstreamMode or we don\'t call it if it is null.',NULL,1832,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/CheckoutCommand.java','AAAL0X///98='),(51,94,'2010-11-01 21:04:48','P',1,'Javadocs for my mouse to hover on:\n\n	/**\n	 * A Git note about the commit referenced by <code>noteOn</code>.\n	 * \n	 * @param noteOn\n	 *            the commit which is referenced by this note\n	 * @param noteData\n	 *            the actual note data contained in this note\n	 */',NULL,1833,1,'org.eclipse.jgit/src/org/eclipse/jgit/notes/Note.java','AAALzX///kA='),(70,94,'2010-11-01 21:04:48','P',1,'Is there a missing word right here? \"...caller because loading...\"',NULL,1833,1,'org.eclipse.jgit/src/org/eclipse/jgit/notes/NoteMap.java','AAALzX///kE='),(189,1,'2010-11-04 19:49:39','P',1,'IIRC, yes, its still needed here.\n\nFor stupid historical reasons a TreeWalk starts with an empty tree iterator in the first slot.  We don\'t want that here, so we have to throw it away with a reset() call.\n\nI keep meaning to change TreeWalk to remove that initial empty tree, but I haven\'t had a chance to yet.  The initial empty tree was to help ObjectWalk, but it turns out ObjectWalk no longer uses TreeWalk (it uses the CanonicalTreeParser directly for performance reasons) and the initial empty tree is *never* useful.  Everyone has to reset to discard it.  So we should just drop it from the initial object.','AAALzn///8o=',1833,2,'org.eclipse.jgit/src/org/eclipse/jgit/notes/NoteMap.java','AAALzn///8g='),(189,9,'2010-11-04 14:54:32','P',1,'Is reset() needed here?\nThe javadoc of TreeWalk says that reset() is only necessary if the same TreeWalk object is to be reused again. Here it is used only once.',NULL,1833,2,'org.eclipse.jgit/src/org/eclipse/jgit/notes/NoteMap.java','AAALzn///8o='),(110,1,'2010-11-12 20:05:30','P',1,'OK, I\'ll try to write unit tests for this today, and upload a new patch set.','AAAL0H///1o=',1851,4,'org.eclipse.jgit/src/org/eclipse/jgit/notes/LeafBucket.java','AAAL0H///0I='),(110,94,'2010-11-11 19:08:59','P',1,'This part looked kind of funny to me, but I haven\'t had time to write a test that covers this part.',NULL,1851,4,'org.eclipse.jgit/src/org/eclipse/jgit/notes/LeafBucket.java','AAAL0H///1o='),(110,1,'2010-11-12 22:05:52','P',1,'Done.  Unit tests added.  This code is correct as written, because the unit tests say it is... :-)','AAAL0H///0I=',1851,4,'org.eclipse.jgit/src/org/eclipse/jgit/notes/LeafBucket.java','AAAL0H///y0='),(144,94,'2010-11-12 22:29:31','P',1,'About the millionth time someone has had to write this :-(',NULL,1852,5,'org.eclipse.jgit/src/org/eclipse/jgit/notes/FanoutBucket.java','AAAL0H///yk='),(140,9,'2010-11-07 20:20:00','P',1,'Done','AAALzn///5s=',1857,1,'org.eclipse.jgit.pgm/resources/org/eclipse/jgit/pgm/CLIText.properties','AAALzn///4s='),(140,1,'2010-11-05 21:19:33','P',1,'Style-nit: Trailing whitespace.',NULL,1857,1,'org.eclipse.jgit.pgm/resources/org/eclipse/jgit/pgm/CLIText.properties','AAALzn///5s='),(67,9,'2010-11-07 20:20:00','P',1,'Done','AAALzn///5o=',1857,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/Add.java','AAALzn///4o='),(67,1,'2010-11-05 21:19:33','P',1,'Style-nit: We don\'t put {} around a single statement.',NULL,1857,1,'org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/Add.java','AAALzn///5o='),(47,1,'2010-11-08 20:27:20','P',1,'In the past we have worked around this in FindBugs by instead defining the code to be:\n\n  new StringBuilder(str.length()).append(str).toString();\n\nOr whatever it needs to be.  The end result is 1 allocation more (the temporary StringBuilder), but that can be stack allocated in some cases on some modern Java 6 runtimes.  I probably would have preferred changing the code here over defining the exception in the FindBugs configuration file.',NULL,1861,2,'org.eclipse.jgit/findBugs/FindBugsExcludeFilter.xml','AAALzn///3c='),(401,46,'2010-11-09 17:16:28','P',1,'Done','AAALz3////c=',1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H////c='),(400,46,'2010-11-09 17:16:28','P',1,'Done','AAALz3////Y=',1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H////g='),(164,46,'2010-11-09 17:16:28','P',1,'Ok, it took me some discussion with Christian, but we hope that we understood this correctly.','AAALz3////I=',1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H////I='),(373,46,'2010-11-09 17:16:28','P',1,'Done','AAALz3////U=',1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H////k='),(311,46,'2010-11-09 17:16:28','P',1,'Done','AAALz3////E=',1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H////o='),(471,46,'2010-11-09 17:16:28','P',1,'Done','AAALz3////k=',1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H////Q='),(310,46,'2010-11-09 17:16:28','P',1,'Done','AAALz3////A=',1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H////s='),(464,46,'2010-11-09 17:16:28','P',1,'Done','AAALz3////g=',1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H////U='),(157,46,'2010-11-09 17:16:28','P',1,'Done','AAALz3////M=',1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H////w='),(440,46,'2010-11-09 17:16:28','P',1,'Done','AAALz3////o=',1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H////Y='),(310,1,'2010-11-08 23:22:57','P',1,'This isn\'t necessary, new FileOutputStream(file) will create the file if it doesn\'t exist yet.',NULL,1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAALz3////A='),(401,1,'2010-11-08 23:22:57','P',1,'We should be checking the OK codes, and using default for the errors.  Just in case RefUpdate starts to return a different failure code in the future, we shouldn\'t assume its a successful update.',NULL,1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAALz3////c='),(311,1,'2010-11-08 23:22:57','P',1,'FWIW we prefer the style:\n\n  FileOutputStream fos = new FileOutputStream(file);\n  try {\n    fos.write(content.getBytes(\"UTF-8\"));\n  } finally {\n    fos.close();\n  }',NULL,1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAALz3////E='),(464,1,'2010-11-08 23:22:57','P',1,'Style-nit: This overload of setUpstream should be next to the other variant of setUpstream.',NULL,1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAALz3////g='),(164,1,'2010-11-08 23:22:57','P',1,'Why are we using rebase-apply?  Dumping to patch files and back is pretty ugly.  I think we should instead be targeting the rebase interactive style of temporary data.  We can churn through most of the work directly inside of the JVM without writing temporary state, until we hit a conflict and need to stop for resolution.  That removes most of the performance disadvantage of the rebase interactive temporary format.\n\nActually, that format should be faster because we aren\'t dumping the diff of each commit out to disk, and reading it back in.\n\nIf we _really_ want to test what happens when you apply this series of patches to another branch, we shouldn\'t be doing that through rebase.  I know Junio C Hamano argues that is a use for rebase, but in practice nobody uses it like that, they rebase once and keep the result if it was successful.  The rebase interactive script is a better way to do that.',NULL,1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAALz3////I='),(471,1,'2010-11-08 23:22:57','P',1,'Why not use the RevWalk we allocated in our constructor?',NULL,1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAALz3////k='),(157,1,'2010-11-08 23:22:57','P',1,'This is horrible as its O(N) insertion (we have to slide the array down each time).  Instead use either a LinkedList, or append to the array and then use Collections.reverse() to flip it around after the walk is complete.',NULL,1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAALz3////M='),(440,1,'2010-11-08 23:22:57','P',1,'We would never do multiple actions at once.  So make this an enum that selects the operation mode, e.g.:\n\n  enum Operation {\n    BEGIN, CONTINUE, SKIP, ABORT;\n  }\n\nand have the individual set methods assign the enum field accordingly.',NULL,1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAALz3////o='),(373,1,'2010-11-08 23:22:57','P',1,'Maybe instead you can use:\n\n  RawParseUtils.decode(IO.readFully(new File(directory, fileName));',NULL,1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAALz3////U='),(400,1,'2010-11-08 23:22:57','P',1,'We know what we read head to above on line 391 with the parseCommit call.  If HEAD isn\'t that when the update occurs, we\'re screwed, as someone else has updated HEAD behind our backs.  Add in:\n\n  refUpdate.setExpectedOldObjectId(head);\n\nAlso we have a RevWalk on hand, pass that to forceUpdate() so it doesn\'t need to allocate its own revision pool.',NULL,1864,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAALz3////Y='),(285,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///9M=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///70='),(279,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///9E=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///74='),(276,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///9Q=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///78='),(389,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///9c=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///7o='),(413,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///9k=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///7s='),(410,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///9g=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///7w='),(179,1,'2010-11-10 02:18:13','P',1,'You should add a TODO for yourself here, we later want to avoid doing the cherryPick() if the first parent of commitToPick is the current HEAD.  Instead we should fast-forward to commitToPick, so that the branch isn\'t modified.\n\nC Git does this to avoid unnecessary object rewriting, which is really useful when you are using Gerrit Code Review as your upstream review system and you accidentally `git rebase -i HEAD~toofarback`.  So long as none of those commits are modified, they keep the same SHA-1 and Gerrit doesn\'t know you \"rebased\".',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///80='),(223,1,'2010-11-10 02:18:13','P',1,'We try to avoid StringTokenizer.  I would just parse the line by hand.  And even then, we don\'t actually need to decode up into String data to parse this, its simple enough to load the entire todo-list into memory as a byte[] and use RawParseUtils to scan through the byte[] and process that into an in-memory representation:\n\n  static enum Operation {\n    PICK;  // later add SQUASH, EDIT, etc.\n  }\n\n  static class Step {\n    Operation operation;\n    ObjectId commit;\n    byte[] shortMessage;\n  }\n\n  List<Step> todo;\n\n  List<Step> loadSteps() {\n    byte[] buf = IO.readFully(new File(rebaseDir, \"git-rebase-todo\"));\n    int ptr = 0;\n    ArrayList<Step> r = new ArrayList<Step>();\n    while (ptr < buf.length) {\n      ...\n    }\n    return r;\n  }',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///84='),(215,1,'2010-11-10 02:18:13','P',1,'You shouldn\'t open a writer on top of the same file you are reading.  The writer may have just truncated the file, making it impossible to read later sections of the same file.  This is one reason we use LockFile in a lot of the code, because it writes to a temporary file alongside of the original, and then does a rename during commit.',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///88='),(268,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///9U=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///8A='),(258,46,'2010-11-10 13:57:36','P',1,'Actually, the opposite is true: the test never returned true... In any case, the intention here was to skip those commits that bring changes that have already been included... Obviously, this is not the right thing to do here, so I removed it.','AAAL0H///9Y=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///8E='),(245,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///9I=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///8I='),(223,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///84=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///8M='),(179,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///80=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///8o='),(215,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///88=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///8Q='),(120,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///9o=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///8s='),(204,46,'2010-11-10 13:57:36','P',1,'Done','AAAL0H///9A=',1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///8U='),(204,1,'2010-11-10 02:18:13','P',1,'We shouldn\'t assume encoding is platform encoding, but instead use UTF-8 explicitly like we did above.\n\nAlso, this commit list doesn\'t change between steps, unless we modify it.  Ideally we would keep the list as an instance member and flush it to the \"git-rebase-todo\" file only when call() is complete and the rebase is *not* successful.  That way we aren\'t updating the file on each commit, but instead are updating only once when we are returning control to the caller.',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///9A='),(389,1,'2010-11-10 02:18:13','P',1,'If I recall listFiles() can return null if you can\'t read the directory, but you can stat it to determine it is a directory.  (E.g. x but no r bit.)\n\nThus we prefer something like:\n\n  File[] children = fileOrFolder.listFiles();\n  if (children != null) {\n    for (File child : children)\n      deleteRecursive(child);\n  }\n\nAnd since listFiles() returns null when the fileOrFolder is not a directory, you an also skip the isDirectory() test.',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///9c='),(279,1,'2010-11-10 02:18:13','P',1,'This reader needs to be released.  Or alternatively, use the reader from your current walk:\n\n  reader = walk.getObjectReader();',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///9E='),(410,1,'2010-11-10 02:18:13','P',1,'FWIW the .getId() calls here are unnecessary.  You should be able to pass the RevTree returned by getTree() directly to the DirCacheCheckout constructor.',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///9g='),(245,1,'2010-11-10 02:18:13','P',1,'Unfortunately this will fail when HEAD is detached.  When HEAD is detached this method returns the 40 digit hex SHA-1.  C Git in the same case puts \"detached HEAD\" into the head-name file.\n\nIt can also return null.  Which will NPE later on when you fill the head-name file.\n\nI think the only safe thing to do is:\n\n  Ref head = repo.getRef(Constants.HEAD);\n  if (head == null || head.getObjectId() == null)\n    throw new RefNotFoundException(...);\n\n  String headName;\n  if (head.isSymbolic())\n    headName = head.getTarget().getName();\n  else\n    headName = \"detached HEAD\";\n\n  ObjectId headId = head.getObjectId();\n\nIts perhaps longer, but it gives you direct access to the various states that are involved.',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///9I='),(413,1,'2010-11-10 02:18:13','P',1,'There isn\'t any value in doing walk.release() until the finally block of call(), when you also monitor.endTask().  The temporary resources used by the RevWalk\'s internal ObjectReader is generally pretty light-weight and might as well stick around for the duration of the call.',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///9k='),(285,1,'2010-11-10 02:18:13','P',1,'Aren\'t we missing an LF here?  getShortMessage() IIRC doesn\'t include the LF.',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///9M='),(120,1,'2010-11-10 02:18:13','P',1,'This is a bit too magic for our style.  It works because the statement is actually pulled into the constructor after super(repo) is called, and thus repo in the super class is already defined.  But its funny to read it like that.\n\nI would prefer to do this inside of the constructor, similar to now the RevWalk is allocated inside of the constructor.',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///9o='),(276,1,'2010-11-10 02:18:13','P',1,'We don\'t use FileWriter because the encoding can be platform-specific.  Instead use FileOuputStream and enforce use of UTF-8 by wrapping it in an OutputStreamWriter, or by doing sb.toString().getBytes(\"UTF-8\") below.',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///9Q='),(268,1,'2010-11-10 02:18:13','P',1,'Why is this commented out?',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///9U='),(258,1,'2010-11-10 02:18:13','P',1,'Hmm.  Isn\'t this always true?  commit is reachable from headCommit, that\'s how we found it and included it into the result from LogCommand.  Thus its always merged into headCommit, and thus this expression is always true.  So aren\'t you always falling out with cherryPickList empty?',NULL,1864,3,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0H///9Y='),(257,5,'2010-11-22 15:04:06','P',1,'style-nit: need an empty line',NULL,1864,8,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAAL0n///9c='),(248,5,'2010-11-22 15:04:06','P',1,'style-nit: extra space',NULL,1864,8,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAAL0n///9g='),(247,5,'2010-11-22 15:04:06','P',1,'s/bebase/rebase/',NULL,1864,8,'org.eclipse.jgit/src/org/eclipse/jgit/api/Git.java','AAAL0n///9Y='),(564,5,'2010-11-22 15:04:06','P',1,'we should have a test for an unknown upstream',NULL,1864,8,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0n///9A='),(438,5,'2010-11-22 15:04:06','P',1,'This should be a JGitInternalException since it has nothing to do with IO',NULL,1864,8,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0n///9E='),(373,5,'2010-11-22 15:04:06','P',1,'can we create a test for  being in a wrong state?',NULL,1864,8,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0n///9I='),(363,5,'2010-11-22 15:04:06','P',1,'s/sate/state/',NULL,1864,8,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0n///9M='),(301,5,'2010-11-22 15:04:06','P',1,'we don\'t have a test for detached HEAD. But this is a valid use-case when working with the gerrit UI. We should have a test for this case.',NULL,1864,8,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0n///9Q='),(224,5,'2010-11-22 15:04:06','P',1,'we don\'t have a test for this status. shouldn\'t we add one?',NULL,1864,8,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0n///9U='),(132,2,'2010-11-22 15:50:38','P',1,'shouldn\'t \'rebase-merge\' be a constant somewhere?',NULL,1864,9,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0n///8s='),(242,1,'2010-11-08 23:28:32','P',1,'DirCacheEditor might have been easier here:\n\n  DirCacheEditor edit = dirc.editor();\n  edit.add(new DirCacheEditor.DeletePath(path));\n  edit.commit();\n\n:-)',NULL,1867,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/IndexDiffTest.java','AAALz3///+w='),(13,4,'2010-11-09 23:23:50','d',1,'typo: s/affedted/affected/',NULL,1868,1,'/COMMIT_MSG','AAAL0H///+I='),(61,1,'2010-11-08 21:51:25','P',1,'I\'m not sure I\'m happy with this.  The current file is neatly organized, one string name per line.  The new formatting is 3 lines per string.  Ugh.\n\nI just undo the code formatter on save.  So my fingers now do \"Ctrl-S Ctrl-Z\" when editing this file.',NULL,1869,1,'org.eclipse.jgit/src/org/eclipse/jgit/JGitText.java','AAALzn///2Q='),(33,5,'2010-11-09 22:11:08','P',1,'Don\'t you want a text with at least one parameter? Don\'t you want to print which pathes couldn\'t be deleted?',NULL,1872,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/coretext.properties','AAAL0H///+w='),(33,44,'2010-11-10 09:16:13','d',1,'Done','AAAL0H///+w=',1872,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/coretext.properties','AAAL0H///8Y='),(206,2,'2010-11-10 16:17:04','P',1,'Can we move this to a utility method somewhere?',NULL,1872,2,'org.eclipse.egit.core/src/org/eclipse/egit/core/op/BranchOperation.java','AAAL0H///6w='),(277,5,'2010-11-10 21:54:03','P',1,'Hmmm, why shouldn\'t we be here for an subtree path? This method is only called from prescanOneTree() (when we ignore HEAD during clone or reset operations). There we create a non-recursive treewalk for merge, index and worktree and jump for every path into this method. In the clone use-case worktree and index should be empty, right? But during a reset it is likely that we are here because e.g. the worktree contains a folder for that path.\n\nNow the good news: keep() tests for null values and therefore will not lead to an NPE.\nAnd the bad news: f.isModified() doesn\'t test for null values and will NPE. So, I would guess this check is ok and needed.\n\nI think we really need tests here. DirCacheCheckout.prescanTwoTrees is well tested. But prescanOneTree is not. I try to create some tests which improve test coverage.','AAAL0H///6Q=',1877,1,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheCheckout.java','AAAL0H///5o='),(277,1,'2010-11-10 18:15:07','P',1,'I don\'t think this is the solution.  From what I know of how this code works, we shouldn\'t be here for a directory name.  If we are and i.getDirCacheEntry() == null, we would execute the else case below and call keep(null), which should also then NPE, or NPE very late downstream when the new index contains an empty slot.\n\nI think the better question is, why are we looking at a subtree here in \"i\" and in this code path?',NULL,1877,1,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheCheckout.java','AAAL0H///6Q='),(232,2,'2010-11-11 16:58:47','P',1,'If null is a valid argument to DirCacheCheckout, can we document this?\n\nI\'ll open a bug.',NULL,1887,1,'org.eclipse.egit.core/src/org/eclipse/egit/core/op/CloneOperation.java','AAAL0H///2Q='),(160,1,'2010-11-12 16:50:03','P',1,'getId() here isn\'t necessary, RevTree is an ObjectId.',NULL,1888,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/DirCacheCheckoutTest.java','AAAL0H///0k='),(160,5,'2010-11-12 22:37:26','P',1,'Done','AAAL0H///0k=',1888,1,'org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/DirCacheCheckoutTest.java','AAAL0H///yo='),(341,1,'2010-11-12 16:50:03','P',1,'Why isn\'t this expression changed to be:\n\n  if (!file.delete() && file.exists())\n\n?  If the file doesn\'t delete and doesn\'t exist, why shouldn\'t we fall through to the else case below for isSamePrefix() removeEmptyParents?  If the file deletion failed because its already gone, then the parent might be empty and we might be able to remove it.',NULL,1888,1,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheCheckout.java','AAAL0H///0o='),(338,1,'2010-11-12 16:50:03','P',1,'The classic way to write this loop is:\n\n for (int i = removed.size() - 1; i >= 0; i--) {\n   String r = removed.get(i);\n\nThat way you save a subtraction operation during each iteration.  And that form is what most C programmers use to go backwards (because they want to save the subtraction), so its what most people reading a backwards loop expect to see.\n\nThis form I had never seen before, it took me a while to process the loop condition and conclude it was correct.  :-(',NULL,1888,1,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheCheckout.java','AAAL0H///0w='),(338,5,'2010-11-12 22:37:26','P',1,'I fully agree. I can\'t explain why that kind of loop went in. I\'ll repair it.','AAAL0H///0w=',1888,1,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheCheckout.java','AAAL0H///yg='),(341,5,'2010-11-12 22:37:26','P',1,'Done','AAAL0H///0o=',1888,1,'org.eclipse.jgit/src/org/eclipse/jgit/dircache/DirCacheCheckout.java','AAAL0H///yY='),(105,2,'2010-11-12 21:27:29','P',1,'I\'ll file a new changeset for that then. It makes sense.','AAAL0H///zo=',1896,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAAL0H///zg='),(105,1,'2010-11-12 21:22:25','P',1,'If you added this to the CoreConfig object in JGit, you can instead do:\n\n  repository.getConfig().get(CoreConfig.KEY).getFileMode()\n\nand have it use a cached CoreConfig instance, which itself has cached the value of core.filemode.  Doing this allows the cached value to be evicted and rebuilt when any property in the configuration file changes, or if the underlying config file on disk is modified.  That makes EGit more responsive to updates.\n\nAlso, isn\'t:\n\n  Boolean.valueOf(exprOfTypePrimitiveBoolean).booleanValue())\n\nKind of pointless?  You are casting boolean to Boolean, and then casting back.  Uh.  WTF?',NULL,1896,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAAL0H///zo='),(105,8,'2010-11-13 11:32:03','P',1,'This was done in mindless-drone-mode :)  I just moved the code to a place where it wouldn\'t be called very often.','AAAL0H///zo=',1896,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/decorators/DecoratableResourceAdapter.java','AAAL0X////8='),(10,1,'2010-11-15 18:31:22','P',1,'s/withi/within/',NULL,1905,1,'/COMMIT_MSG','AAAL0X///9o='),(183,1,'2010-11-15 18:31:22','P',1,'This should be p.now, not reading the clock.  I think your intent was to read the clock at the start of the entire iteration, and then use that single timestamp for all subdirectories.  Here you are updating the clock within each subdirectory as the TreeWalk recurses into them, but then you aren\'t updating it when we pop back out and evaluate another file in the parent directory.  That\'s somewhat inconsistent timestamp behavior.',NULL,1905,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL0X///9g='),(634,1,'2010-11-15 18:31:22','P',1,'Style-nit: Line wrapping here is very ugly.',NULL,1905,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL0X///9k='),(79,15,'2010-11-16 21:45:29','P',1,'Spellcheckable\n\nOr is this a pun ;-) ?',NULL,1924,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/SpellchecableMessageArea.java','AAAL0n////A='),(79,49,'2010-11-16 22:14:43','P',1,'No, this is a typo;)\n\nDone','AAAL0n////A=',1924,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/dialogs/SpellchecableMessageArea.java','AAAL0n///+4='),(227,5,'2010-11-19 08:24:10','P',0,'this method is replaced by IteratorState.initializeDigestAndReadBuffer() right? Why is the replacing method so much smaller? Don\'t we needed the if statement which i see here? This method even initialized a potentially present parent, the new method doesn\'t do. That\'s correct?',NULL,1926,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL0n///+U='),(227,1,'2010-11-19 23:54:36','P',0,'The replacing method doesn\'t need to initialize the parent, or copy the fields down from it because the IteratorState object is shared between the parent and all subiterators that are created from it.  So we only have to initialize once, and there is no copy down from the parent.\n\nThus, the code is simpler, but may be a bit slower for very flat trees, but may be a bit faster for deeper trees.  Java trees are very deep, and are very likely to be processed by JGit (due to its embedding in Eclipse), so the fact that we may be a bit faster for deeper trees (due to less copying and recursing during setup of the digest and buffer) means this simpler code is probably better anyway.  :-)','AAAL0n///+U=',1926,1,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL0n///9s='),(645,8,'2010-12-20 00:00:12','P',1,'why?','AAAL1n///7I=',1927,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL13///3w='),(220,1,'2010-12-20 16:34:56','P',1,'Adding the iterator to the state object isn\'t worthwhile.  The state object is shared across all levels of the directory structure, while the iterator changes with each enter/exit of a subdirectory.  Thus holding onto the per-directory iterator within the shared state isn\'t useful.\n\nBesides, state.walk.getTree(state.dirCacheTree) isn\'t actually that expensive.  Aside from the field references above (which should JIT out pretty easily since they are package visible fields) the getTree() method is just an array access, two field accesses, and a reference compare.  Its not that expensive.','AAAL1n///7M=',1927,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL13///zc='),(645,1,'2010-12-20 16:34:56','P',1,'I think Philipp is right.  We have a problem here.  This method is called from isModified() when a content compare is needed because the file entry is stat dirty.  But its recursing back into isModified() via getEntryObjectId().\n\nA quick scan of the code suggests we may infinite loop here until we blow the stack due to too many levels of recursion.  Even if we address the issue of avoiding the infinite recursion, once we are here we kind of know we need to scan the working tree file and should avoid the DirCacheEntry.','AAAL13///3w=',1927,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL13///zY='),(645,100,'2010-12-15 11:36:31','P',1,'I think this is a place where reusing the cached ID is not expected (what getEntryObjectId does). Maybe a flag is required to force reading from the filesystem.',NULL,1927,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL1n///7I='),(220,100,'2010-12-15 11:36:31','P',1,'Maybe the iterator could also be added to the state object once it has been retrieved from the TreeWalk.',NULL,1927,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL1n///7M='),(645,5,'2010-12-31 15:36:31','P',1,'One source of the problem is that WorkingTreeIterator.isModified() is \ndoing much. Why should we ever want a content comparison in the idBuffer() method? If we detect by metadata comparison that we cannot reuse the index-entry id we want to simply compute the content-id() on the file-content (and don\'t compare it with the content of the index entry).\nI suggest that we introduce a new comparison method on WorkingTreeIterator which compares only the metadata of the entry and a index entry. That method will be reused in the isModified() method and will be called from idBuffer(). \n\nAll this will remove the infinite recursion problem. I\'ll post such a proposal and rebase this change on it.','AAAL13///zY=',1927,3,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL2X///yo='),(225,8,'2011-01-15 20:28:48','P',1,'git status updates the index stat data if it has to read the content to determine if there is a change or not. The same goes for git diff. The result is that the next time git can figure out there is no change just by looking at the stat data. If your do not update the index, you have to\nread the content again. It can be a separate change though since it\nmay require more care with how the dircache instance is handled.','AAAL2n///5g=',1927,5,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL2n///5E='),(225,5,'2011-01-14 16:21:54','P',1,'ouch, how did this came in. Regarding when to return the idBuffer you are of course right ... - I\'ll propose a fix for that now.\n\nRegarding the index update: When the index is updated is currently not in the scope of this change. We are never under the hood updating the index. Do you know when \'git status/diff\' update the index? I could imagine that it definitely make sense to correct the smudged status of index entries when during a walk get real info about whether a file is dirty or not.','AAAL2n///6I=',1927,5,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL2n///5g='),(225,8,'2011-01-14 15:24:32','P',1,'Should we not return the buffer if compareMetadata returns EQUAL?\n\nWhat I also see is that we never update the index, like git status/diff does. When should that take place?',NULL,1927,5,'org.eclipse.jgit/src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java','AAAL2n///6I='),(12,46,'2010-11-24 08:22:20','P',1,'Please add signed-off.',NULL,1928,2,'/COMMIT_MSG','AAAL0n///4Q='),(308,46,'2010-11-24 08:22:20','P',1,'There seems to be a minor formatting issue (missing tab). Please make sure to format with the formatter settings checked into the project.',NULL,1928,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAAL0n///4k='),(309,46,'2010-11-24 08:22:20','P',1,'For code readability, I\'d prefer to import IWorkbenchAction and get rid of the \"ActionFactory.\" prefix',NULL,1928,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAAL0n///4o='),(800,46,'2010-11-24 08:22:20','P',1,'See above (import IWorkbenchAction)',NULL,1928,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/GitHistoryPage.java','AAAL0n///4c='),(114,46,'2010-11-24 08:22:20','P',1,'Please import IWorkbenchAction and get rid of the \"ActionFactory.\" prefix. This will also shorten the line somewhat.',NULL,1928,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/GitHistoryPage.java','AAAL0n///4g='),(1272,46,'2010-11-24 08:22:20','P',1,'Please import IWorkbenchAction (see above).',NULL,1928,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/GitHistoryPage.java','AAAL0n///4U='),(1273,46,'2010-11-24 08:22:20','P',1,'A tab seems to be missing. Please format with the code formatter settings checked into the project.',NULL,1928,2,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/GitHistoryPage.java','AAAL0n///4Y='),(378,6,'2010-11-30 10:52:36','d',1,'Hi Dariusz, I do not agree that the version in index does not exist if there are no staged changes. In this case the version in index is just the same as the version in the HEAD. So the only question is about the label we show. In \"Compare with index\" we show the label \"Index\". The user can see from the decorators that there are no staged changes.\n\nBut the main problem here is that now the wrong input is used on the right side: If null is returned here, the method getRight of GitLocalCompareInput returns a new input using \"baseCommit\". But I observe that baseCommit and ancestorCommit both point the the first parent of HEAD, and as a consequence the right side does not contain the content of the latest commit but of its parent.','AAAL0n///pQ=',1930,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAAL0n///ng='),(397,49,'2010-11-29 22:42:07','P',1,'I\'ll rename it (or remove it) when we agree on what we should show in right hand side editor in compare view, wen we are comparing locally changed file that doesn\'t have staged changes.','AAAL0n///rQ=',1930,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAAL0n///pM='),(378,49,'2010-11-29 22:42:07','P',1,'In my humble opinion this is proper behavior. When you have locally changed file (and you didn\'t stage any changes for it before) it should compare against latest commit not version in cache/index, because it does \"not exists\".\n\nThe behavior that you proposed can be miss leading for end user.','AAAL0n///rM=',1930,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAAL0n///pQ='),(116,49,'2010-11-29 22:42:07','P',1,'Done','AAAL0n///rU=',1930,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAAL0n///pY='),(378,6,'2010-11-29 14:27:08','P',1,'This code does not work if a file is checked-in and is changed in the working dir, but not in the index. Then the method isCachedEntry  returns false and as a consequence later on the comparison is done with the base commit, which is the parent of head.\n\nIf a file is in head and has no staged changes then it **is** in the index and GitFileRevision.inIndex(db, gitPath) returns a meaningful value. We should do the same here as in CompareWithIndexActionHandler. There the method getHeadTypedElement does a check if the file exists in the index. If not, it returns a GitCompareFileRevisionEditorInput.EmptyTypedElement with the text \"{0} not in index\", if yes, it uses GitFileRevision.inIndex.',NULL,1930,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAAL0n///rM='),(397,6,'2010-11-29 14:27:08','P',1,'The method name does not describe what the method it is doing. \n\nIn general it simply compares if the entries of two different trees are equal, right? But don\'t you just want to know there is an entry in the index for this file? Why do you have to check if the entry in the index  is different from the entry in head?',NULL,1930,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAAL0n///rQ='),(116,6,'2010-11-29 14:27:08','P',1,'Unintended reformatting',NULL,1930,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/CompareUtils.java','AAAL0n///rU='),(745,49,'2010-11-29 22:42:07','P',1,'Done','AAAL0n///rI=',1930,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAAL0n///pU='),(745,6,'2010-11-29 14:27:08','P',1,'In Compare With Index and the corresponding compare edior we use the term \"Index\", in the node of the synchronize view we use \"Staged\".\n\nTo be consistent I would say that we should use \"staged version\" here.',NULL,1930,3,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/uitext.properties','AAAL0n///rI='),(51,6,'2010-12-02 09:59:56','P',1,'This returns the parent of the HEAD commit but not the HEAD commit.',NULL,1930,4,'org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/synchronize/compare/GitCacheCompareInput.java','AAAL0n///g4='),(456,4,'2010-11-24 15:35:52','P',1,'style-nit: as this is a constant this should probably be all upper case : EMPTY_TEXT',NULL,1939,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAAL0n///3Q='),(463,1,'2010-11-27 01:51:38','d',1,'In general we try to avoid parens unless they are required to force a particular order of evaluation, or there are less common operators involved whose precedence is not well known (e.g. combining | or + and >> in the same expression).','AAAL0n///xw=',1939,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAAL0n///tM='),(456,5,'2010-11-25 22:43:37','P',1,'Its now a constant in the RawText class itself','AAAL0n///yc=',1939,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAAL0n///x0='),(456,5,'2010-11-25 22:43:37','P',1,'Done','AAAL0n///3Q=',1939,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAAL0n///x4='),(463,5,'2010-11-25 22:43:37','P',1,'that rule is new to me. I thought the parens together with the ? operator are ok. But ok - I\'ll removed them','AAAL0n///yg=',1939,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAAL0n///xw='),(456,1,'2010-11-25 18:05:07','P',1,'I agree with Matthias, this should be EMPTY_TEXT.\n\nAlso, Gerrit Code Review defines an EMPTY_TEXT constant itself.  Maybe put this in RawText as a public static final constant so I can drop the one in Gerrit?  (My point here is, some applications probably also need the empty text the same way you need it here, so it should be a standard constant we export.)',NULL,1939,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAAL0n///yc='),(463,1,'2010-11-25 18:05:07','P',1,'Style-nit: Parens aren\'t necessary around the conditional.',NULL,1939,1,'org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java','AAAL0n///yg='),(79,5,'2010-12-02 12:18:14','P',1,'Done','AAAL0n///tQ=',1939,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawText.java','AAAL0n///gg='),(79,1,'2010-11-27 01:51:52','P',1,'Style-nit: Constants should be declared before instance members, and public constants before private constants.  So this should be the first declaration in the class.',NULL,1939,2,'org.eclipse.jgit/src/org/eclipse/jgit/diff/RawText.java','AAAL0n///tQ='),(465,46,'2010-11-26 07:31:41','P',1,'Done','AAAL0n///yU=',1940,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0n///wk='),(465,1,'2010-11-25 18:07:08','P',1,'Nak.  This strips everything after the first line.  That\'s not what we want, is it?\n\nTo trim the trailing LF(s), use:\n\n  int end = content.length;\n  while (0 < end && content[end - 1] == \'\\n\')\n    end--;\n  return RawParseUtils.decode(content, 0, end);',NULL,1940,2,'org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java','AAAL0n///yU='),(24,46,'2010-11-25 09:20:40','P',1,'Done','AAAL0n///1A=',1942,1,'/COMMIT_MSG','AAAL0n///0E='),(13,46,'2010-11-25 09:20:40','P',1,'Done','AAAL0n///1E=',1942,1,'/COMMIT_MSG','AAAL0n///0I='),(24,4,'2010-11-24 23:41:10','P',1,'you should mention that these problems will be fixed in subsequent changes',NULL,1942,1,'/COMMIT_MSG','AAAL0n///1A='),(13,4,'2010-11-24 23:41:10','P',1,'add a blank line here for better readability.',NULL,1942,1,'/COMMIT_MSG','AAAL0n///1E='),