Skip to content

Fix for issue 31#34

Merged
WtfJoke merged 1 commit intortcTo:developfrom
ljhaywar:issue31
Jul 10, 2015
Merged

Fix for issue 31#34
WtfJoke merged 1 commit intortcTo:developfrom
ljhaywar:issue31

Conversation

@ljhaywar
Copy link
Copy Markdown
Contributor

@ljhaywar ljhaywar commented Jul 7, 2015

I finally have a pull request -- woo hoo! Two concerns:

  1. I did not reuse my existing commits as I wasn't sure how to do that--I manually made the changes in my new branch. For future reference, is there a way to apply existing commits to a branch?
  2. I didn't have time to test that the changes work with the current Develop branch. I've been working completely in my own fork, so I know the changes work there.

@WtfJoke
Copy link
Copy Markdown
Member

WtfJoke commented Jul 7, 2015

Haha awesome! 💯 🙌

  1. Im not sure if its possible. I could imagine, that its possible to merge this newly created branch (in this case this issue31) to your develop stream as well (as long you havent implemented/merged it already like now).
  2. Thats ok. I'm going to recheck it.

@WtfJoke
Copy link
Copy Markdown
Member

WtfJoke commented Jul 10, 2015

Im currently reviewing your changes. Can you give me some details why git rm is used?
If I change from Hello to hello --> hello will be new and as far as I get the code this file will be deleted? Shouldnt be the new file somehow used? Or am I missing a bigger point?

@ljhaywar
Copy link
Copy Markdown
Contributor Author

I'm using core.ignorecase set to false, so when the capitalization of file names change, git will have 2 copies of the file--one in the new capitalization and one in the old capitalization.

newFileInGit and baseFileInGit are for the newly added file. file is a file in the git tree. The "gir rm" is removing the file in the git file tree with the old capitalization. Does that make sense?

@WtfJoke
Copy link
Copy Markdown
Member

WtfJoke commented Jul 10, 2015

Yeah that helped me, thank you.
However Im really surprised how this rm command result in a rename?! 😲 😳

So this is how it works:

  1. Rename + git add -A happens (Was myFile goes to MyFile)
  2. git status shows --> new file: MyFile
  3. Move into directory of changed file and execute --> git ls-tree --name-only HEAD --> shows the previous filename eg. myFile
  4. If MyFile.toLower (filename from git status / disk) = myFile.toLower (from git ls-tree) and MyFile != myFile then execute: git rm --cached myFile

For some reason this results in a rename 😄 Do you know details, why its like that?^^

EDIT: I'll write some tests and will run them also on a linux machine.

@WtfJoke WtfJoke merged commit c0741d7 into rtcTo:develop Jul 10, 2015
@WtfJoke
Copy link
Copy Markdown
Member

WtfJoke commented Jul 10, 2015

Instead of git ls-tree --name-only HEAD I used the shorter command git ls-files (linux has problems referencing to HEAD in the first command).

Just in case you want to update that on your part as well.

I merged your pr with these two commits 8f4c3e8 / b0877e5. Thank you again for changes/enhancements 👍

PS: In order that you get higher on the toplist of the contributors 💸 💰 , you need to add your ibm mail address on your github-profile. So that github knows it was you (aka your user) who did that, currently its just a girl named Lauren, who did those commits 😜

@ljhaywar
Copy link
Copy Markdown
Contributor Author

git rm is not renaming -- it's removing. When the code detects there is a new file added to Git, it checks to see if there is another file with the same characters but different capitalization. If it finds one, it removes it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants