Re: detecting rename->commit->modify->commit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sitaram Chamarty wrote:
http://www.markshuttleworth.com/archives/123#comment-118655

Here is the comment from the thread, my comment on it is below:

> This is a very strong point for renaming, but it is not necessarily an universal one.

> Here is one example of the issue: one developer renaming a directory in his branch, and another adding a file to the original directory in his branch. What happens at the merge ? > - Bazaar renames the directory and puts the new file in the _renamed_ directory. > - Git renames the directory with its files, but keeps the old directory too and adds the new file there.

> Bazaar’s behavior certainly is better for C. However it is not universally better.

> For example in Java you cannot rename a file without changing its contents. So, moving a file to a directory different from where its author put it will almost certainly break the build.

> The bottom line is, both behaviors can seem valid or broken, depending on the case. Neither is perfect. At the very abstract level file renames are _not_ a first-class operation. This is especially apparent in a language like Java.

> Content movement is the first class operation. Things like moving functions, etc. The question is how one can handle that and whether the current strategy has a path for improvement. It could be > argued that once you commit yourself to explicitly tracking file renames, you are giving up a slew of opportunities for handling the more general cases.

> One thing is for certain, a 100% ideal solution is impossible. It would have to be aware of the target programming language _and_ the build environment.

And my comment is that in this example, about Java, I think that manually fixing the package name in the file (after noticing the build is broken) is easy. On the other hand, if the other developer changed one of the renamed file, then manually merging the change in the file in the old location to the file in the new location is not so easy: you first need to discover that this happened, then merge the two files (and you still need to fix the package name).

ittay

--
Ittay Dror <ittayd@xxxxxxxxxx>
Tikal <http://www.tikalk.com>
Tikal Project <http://tikal.sourceforge.net>

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux