git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ittay Dror <ittayd@tikalk.com>
To: Sitaram Chamarty <sitaramc@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: detecting rename->commit->modify->commit
Date: Thu, 01 May 2008 21:58:14 +0300	[thread overview]
Message-ID: <481A12C6.6060900@tikalk.com> (raw)
In-Reply-To: <2e24e5b90805010939g182de387i59722605ff93d72e@mail.gmail.com>

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@tikalk.com>
Tikal <http://www.tikalk.com>
Tikal Project <http://tikal.sourceforge.net>

      reply	other threads:[~2008-05-01 18:59 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-01 14:10 detecting rename->commit->modify->commit Ittay Dror
2008-05-01 14:45 ` Jeff King
2008-05-01 15:08   ` Ittay Dror
2008-05-01 15:20     ` Jeff King
2008-05-01 15:30       ` Ittay Dror
2008-05-01 15:38         ` Jeff King
2008-05-01 15:47         ` Jakub Narebski
2008-05-01 20:39       ` Teemu Likonen
2008-05-01 23:09         ` Jeff King
2008-05-02  2:06         ` Sitaram Chamarty
2008-05-02  2:38           ` Junio C Hamano
2008-05-02 16:59             ` Sitaram Chamarty
2008-05-01 15:24     ` Ittay Dror
2008-05-01 15:28       ` Jeff King
2008-05-01 14:54 ` Ittay Dror
2008-05-01 15:09   ` Jeff King
2008-05-01 15:20     ` Ittay Dror
2008-05-01 15:30     ` David Tweed
2008-05-01 15:27   ` Avery Pennarun
2008-05-01 15:34     ` Jeff King
2008-05-01 15:50       ` Avery Pennarun
2008-05-01 16:48         ` Jeff King
2008-05-01 19:45           ` Avery Pennarun
2008-05-01 22:42             ` Jeff King
2008-05-01 19:12       ` Steven Grimm
2008-05-01 23:14         ` Jeff King
2008-05-03 17:56           ` merge renamed files/directories? (was: Re: detecting rename->commit->modify->commit) Ittay Dror
2008-05-03 18:11             ` Avery Pennarun
2008-05-04  6:08               ` merge renamed files/directories? Ittay Dror
2008-05-04  9:34                 ` Jakub Narebski
2008-05-05 16:40                 ` Avery Pennarun
2008-05-05 21:49                   ` Robin Rosenberg
2008-05-05 22:20                     ` Linus Torvalds
2008-05-05 23:07                       ` Steven Grimm
2008-05-06  0:29                         ` Linus Torvalds
2008-05-06  0:40                           ` Linus Torvalds
2008-05-06 15:47                           ` Theodore Tso
2008-05-06 16:10                             ` Linus Torvalds
2008-05-06 16:15                               ` Linus Torvalds
2008-05-06 16:32                               ` Ittay Dror
2008-05-06 16:39                                 ` Linus Torvalds
2008-05-06  1:38                       ` Avery Pennarun
2008-05-06  1:46                         ` Shawn O. Pearce
2008-05-06  1:58                           ` Avery Pennarun
2008-05-06  2:12                             ` Shawn O. Pearce
2008-05-06  2:19                         ` Linus Torvalds
2008-05-08 18:17           ` detecting rename->commit->modify->commit Jeff King
2008-05-01 16:39   ` Sitaram Chamarty
2008-05-01 18:58     ` Ittay Dror [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=481A12C6.6060900@tikalk.com \
    --to=ittayd@tikalk.com \
    --cc=git@vger.kernel.org \
    --cc=sitaramc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).