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
