Ah... so the clean option is actually smarter than I thought -- it does exactly what I said!
Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 Everything else... well, I don't understand why it does so much, let's leave it at that :) D. On Wed, Feb 17, 2016 at 10:05 PM, Uwe Schindler <u...@thetaphi.de> wrote: > That's what it does with that option on ASF: > > Started by upstream project "Lucene-Solr-NightlyTests-5.x" build number 1100 > originally caused by: > Started by timer > [EnvInject] - Loading node environment variables. > Building remotely on lucene in workspace > /home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x >> git rev-parse --is-inside-work-tree # timeout=10 > Fetching changes from the remote Git repository >> git config remote.origin.url git://git.apache.org/lucene-solr.git # >> timeout=10 > Cleaning workspace >> git rev-parse --verify HEAD # timeout=10 > Resetting working tree >> git reset --hard # timeout=10 >> git clean -fdx # timeout=10 > Fetching upstream changes from git://git.apache.org/lucene-solr.git >> git --version # timeout=10 >> git -c core.askpass=true fetch --tags --progress >> git://git.apache.org/lucene-solr.git +refs/heads/*:refs/remotes/origin/* >> git rev-parse refs/remotes/origin/branch_5x^{commit} # timeout=10 >> git rev-parse refs/remotes/origin/origin/branch_5x^{commit} # timeout=10 > Checking out Revision 56d426f814c090443b20e90f81969f5c060ca490 > (refs/remotes/origin/branch_5x) >> git config core.sparsecheckout # timeout=10 >> git checkout -f 56d426f814c090443b20e90f81969f5c060ca490 >> git rev-list 56d426f814c090443b20e90f81969f5c060ca490 # timeout=10 > No emails were triggered. > [lucene] $ > /home/jenkins/jenkins-slave/tools/hudson.tasks.Ant_AntInstallation/ant-1.8.2/bin/ant > -file build.xml -Dversion.suffix=1090 prepare-release-no-sign > > This is so horrible that I don't want to see it. :) > > I use my local git only with a GUI, that's fine to me. > > The issue here was just a misunderstanding, wrong terms used by non-git > fanatic people. To me a reset of working copy is what I want to have. If > that's a git clean with crazy parameters I don't care. It should just reset > to what I expect from the term 'reset'. > > Uwe > > Am 17. Februar 2016 21:56:23 MEZ, schrieb Dawid Weiss > <dawid.we...@gmail.com>: >>> >>> This is how it looks like (attached screenshot). This option was >>> missing. >>> Now all is fine. >>> No need to discuss about git commands! >> >> >> Fine, Uwe -- I was just mislead by your comment concerning "git >> reset", that's all. The Jenkins option has nothing to do with git >> reset, it very likely wipes the entire build folder and either clones >> from the remote anew or (smarter) clones from another local clone of >> that remote repository. >> >> I admit there's something I don't understand in your heated replies -- >> you always want to understand every detail of Java code yet you're so >> openly against trying to understand anything git-related. Why? It's >> interesting, why resist it with such ferocity? >> >> Dawid >> >> P.S. For example, there is a huge performance difference between >> what >> Jenkins (above) probably does and my two git commands that result in >> exactly the same output, but I'll leave the explanation since you >> probably won't be interested anyway :) >> >> ________________________________ >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > -- > Uwe Schindler > H.-H.-Meier-Allee 63, 28213 Bremen > http://www.thetaphi.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org