Profile cover photo
Profile photo
David Karr
David's interests
View all
David's posts

How does git detect that a "rm" and "add" represent a rename?

I was reading through "Ry`s Git Tutorial" and got to section "Rename the Rainbow". In this section, he says to rename a local file that has been previously committed, then do a "git rm" on the old name and "git add" for the new name.

He then says that the "git status" output shows that git detected the rename.

Obviously, I can see that the file has been renamed, but specifically how does git know that exactly? I can see some possible steps it might follow through to see this, but what is the process exactly? This isn`t something I "need to know", but i`m curious about the algorithm used here.

I could use some help with EGit. I've been asking some questions on the Eclipse forum, and also on the Git community. The latter is non-eclipse focused, and the former is basically one person, giving me helpful information, but about once a day (probably several timezones away from me).

Anyway, there is a github project that I've cloned to my workspace. On github I created a fork of that project and then a named branch in that fork for the first set of changes I need to make. I also created a "Remote" in Egit pointing to the fork (push config only so far).

I need to finish configuring my workspace so that I can make changes that will go into the branch on my fork. I don't understand what next steps I need to make. I know in general how to commit and push, I just need to make sure those changes go to the right repo and branch.

Although I'll likely submit a PR for my changes to the original project, the circumstances of the original project are such that I doubt they will ever be merged (authors don't have time to maintain it anymore). In the near future I'm going to be pushing this codebase (with whatever fixes I can make) to another git repository maintained by a foundation.

I could use some advice on some operational aspects of git.  I've been writing code for many years, most of those Java, but like many people, I'm still pretty new to git.  I've used just about every other popular SCM that was ever invented. I'm finding that one of the reasons that git can be hard is that it is so flexible, it's often hard to know the proper strategy for particular tasks.  SVN is generally more limited, but that makes it easier to figure out the required steps.

Anyway, the situation I'm in is that I'm starting to work on the code for a particular github project.  I had originally cloned the "master" (correct term?) to my laptop, and I've made one change in one file.

I'm eventually going to be forking this project and storing it in another git  central repository (the authors of the original project know this).  Nevertheless, I'd like to follow through and create a PR on the original project for the change I made, even though I think it's likely it will never be merged.

I believe at this point I should be creating a fork of the original project, putting my change into that (and verifying it), and creating a PR for that change.

Concerning the original directory on my laptop containing the cloned code, should I simply rename that directory before I clone my forked project?  I would just delete it, but I want to be sure I have the changes I made stored somewhere.

As I described earlier, at a point in the near future, I'm going to be uploading that forked codebase to another git repo as a subproject of a larger project.  What are the implications of the fact that that codebase would have been cloned from a github project, and I'm attempting to upload that as a new project to another git repo?

If it matters, I use Eclipse for most of my work.

Post has attachment
David Karr commented on a post on Blogger.
A few things:

Gradle also keeps the best parts of Ant, being the task dependency model, and all the existing out of the box Ant tasks.

Concerning "allowing people to do custom things" as a negative: The reason Ant was a tangled mess was that there's never been a way to write Ant scripts that weren't a tangled mess.  Gradle provides the ability to define a clean build structure. If there are good ways to structure a Gradle build, don't assume people are going to always screw it up just because they can.  Yes, some people make bad decisions.  That's always going to be true.  Modern software development orgs emphasize "trust and verify".

Concerning the several comments about community plugins vs. "mainstream" plugins: Is there anything wrong with those plugins contributed by the community?  I've used the Cobertura plugin, and it works perfectly fine. Gradle makes it easy to write very functional plugins, in contrast to writing Ant or Maven plugins.

While I'm thinking of that, another advantage of Gradle vs. Maven wrt plugins is that you will often find that in situations where you had needed a Maven plugin, you don't need a Gradle plugin, because it's simple to write a couple of lines of Groovy code.

I don't understand your "Gradle doesn't compile tests" comment.  Any existing unit tests are automatically compiled and run by default.  Adding integration tests is very straightforward.

I'm finding that the option to merge my google+ contacts into my main contacts will cause the ambiguous google+ avatar to be used for the contacts that I have a photograph for. My workaround is simply to not merge the google+ contacts. Is there a better way?

Post has attachment

Post has attachment

Post has attachment
Wait while more posts are being loaded