Description Thomas Wolf 2020-02-03 14:56:54 EST

Before https://git.eclipse.org/r/#/c/151352/ , setCloneAllBranches() and setBranchesToClone() could be used independently and the settings active on call() would determine what would be done. So

  cloneCommand.setCloneAllBranches(true);
  cloneCommand.setBranchesToClone(/* some list of refs */);

would clone all branches. So would

  cloneCommand.setBranchesToClone(/* some list of refs */);
  cloneCommand.setCloneAllBranches(true);

.

Since https://git.eclipse.org/r/#/c/151352/ , the last one called wins, so only the second sequence will give a wildcard fetch refspec.

This is not just a theoretical problem. EGit uses the first sequence and expects it to clone all branches and give a fetch spec +refs/heads/*:refs/remotes/origin/*, but since that commit, it gets a series of fetch specs without wildcards and thus won't pick up new upstream branches. See org.eclipse.egit.core.op.CloneOperation.

Now I'll grant that what EGit is doing there (and in the branch selection dialog in the clone wizard) is a bit shady; the dialog should have a "Clone all branches" checkbox and EGit perhaps shouldn't set both.

But since EGit might not be the only client affected, I think it's better to restore the old behavior: all of setCloneAllBranches(), setMirror(), and setBranchesToClone() can be set or reset independently, and what to do is determined only when call() is executed: mirror > cloneAll > specific branches, if none are set, use cloneAll = true.

Also note that the javadoc of setCloneAllBranches() promises it wouldn't have an effect if setCloneAllBranches(true) had been called...

Moreover, the current implementation also allows

  cloneCommand.setMirror(true);
  cloneCommand.setBare(false);

resulting in a non-bare mirror repo.