git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Petr Baudis <pasky@suse.cz>
Cc: git@vger.kernel.org
Subject: Re: [ANNOUNCE] Git wiki
Date: Fri, 05 May 2006 12:49:59 -0700	[thread overview]
Message-ID: <7vr738w8t4.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20060505185445.GD27689@pasky.or.cz> (Petr Baudis's message of "Fri, 5 May 2006 20:54:45 +0200")

Petr Baudis <pasky@suse.cz> writes:

> I doubt this in fact happens that often (to a degree the automatic
> rename detection would catch). And if it happens, then the user has to
> tell Git - I have never heard that _this_ would be any problem in other
> version control systems.

It does not become an issue only because users accept it as a
fact of life.  When Linus was moving most of the contents in
rev-list.c to create a new revision.c, I already had some tweaks
to rev-list.c published before he sent me a patch for the code
movement, and I am sure he needed to re-roll the patch by
merging the change I did to rev-list.c back into his revision.c
file.  No SCM may handle that automatically, and no user
accustomed to existing SCM (including git) expect that to work
automatically.  But that does not necessarily mean a tool that
notices it and tells user what is going on is a bad thing.

However it is a different story to try recording "what is going on"
whether it comes from the tool's guess or directly from the user.

Having a way to affect the inprecise "guess" the tool makes when
that guesswork is needed might make sense.  If you (think you)
know arch/i386/foo.h was copied to create arch/x86-64/foo.h but
the detector does not detect it and seeing a creation patch for
arch/x86-64/foo.h frustrates you, you may want to have a way to
explicitly say "compare arch/i386/foo.h with arch/x86-64/foo.h
in that commit -- I want to examine the change needed to adjust
foo to x86-64 architecture".

But we have "git diff v2.6.14:arch/i386/foo.h v2.6.14:arch/x86-64/foo.h"
for that ;-).

> Then the automated renames detection will miss it given that the other
> accumulated differences are large enough, and the suggested workarounds
> _are_ precisely walking the commit chain.

The HEAD may _not_ have anything to do with v1.3.0 in which case
you would get nothing from walking the ancestry.

> If you use persistent file ids, you never miss it _AND_ you DO NOT WALK
> THE COMMIT CHAIN! You still just match file ids in the two trees.

It is unworkable.

Which one should inherit the persistent id of the old
rev-list.c?  New rev-list.c, or revision.c that has most of the
old contents split out?

Oh, and did you know there was a different revision.h that is
not related to the current revision.h in the history of git?
Should its persistent id have any relation with the persistent
id of the current revision.h?  When would you decide to make the
id inherited and when not to?  If I remove revision.h by mistake
in a commit and resurrect it in the next commit, should it get
the same id back?  If I forget to tell the tool that those two
"disappeared and then reappeared" are related and should get the
same persistent id when I make the resurrection commit, and keep
piling other commits on top, do I have to rewind the ancestry
chain all the way to correct the mistake?

  parent reply	other threads:[~2006-05-05 19:50 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05  0:56 [ANNOUNCE] Git wiki linux
2006-05-05  6:22 ` Fredrik Kuivinen
2006-05-05  6:26   ` Jakub Narebski
2006-05-05  9:23   ` Petr Baudis
2006-05-05  9:51     ` Junio C Hamano
2006-05-05 16:40       ` Petr Baudis
2006-05-05 16:47       ` Jakub Narebski
2006-05-05 18:49         ` Jakub Narebski
2006-05-05 16:36 ` Petr Baudis
2006-05-05 17:48   ` Linus Torvalds
2006-05-05 19:04     ` Dave Jones
2006-05-05 18:15 ` Petr Baudis
2006-05-05 18:20   ` Petr Baudis
2006-05-05 18:27   ` Jakub Narebski
2006-05-05 18:31   ` Linus Torvalds
2006-05-05 18:54     ` Petr Baudis
2006-05-05 19:39       ` Jakub Narebski
2006-05-06 13:37         ` Jakub Narebski
2006-05-05 19:49       ` Junio C Hamano [this message]
2006-05-06  6:53         ` Martin Langhoff
2006-05-06  7:14           ` Junio C Hamano
2006-05-06  7:33           ` Jakub Narebski
2006-05-06  7:41             ` Junio C Hamano
2006-05-06 12:46               ` Bertrand Jacquin
2006-05-05 20:45   ` Olivier Galibert
  -- strict thread matches above, loose matches on Subject: below --
2006-05-02 23:25 Petr Baudis
2006-05-02 23:33 ` Junio C Hamano
2006-05-03  8:39   ` Paolo Ciarrocchi
2006-05-03  9:00     ` Petr Baudis
2006-05-03  9:13       ` Paolo Ciarrocchi
2006-05-03 13:41         ` Nicolas Pitre
2006-05-03 14:29           ` Shawn Pearce
2006-05-03 15:01             ` Andreas Ericsson
2006-05-03 15:24               ` Paolo Ciarrocchi
2006-05-03 15:30                 ` Jakub Narebski
2006-05-03 15:30               ` Linus Torvalds
2006-05-03 15:39                 ` Paolo Ciarrocchi
2006-05-03 16:06                   ` Linus Torvalds
2006-05-03 16:17                     ` Jakub Narebski
2006-05-03 16:19                       ` Paolo Ciarrocchi
2006-05-03 16:46                         ` Jakub Narebski
2006-05-03 19:21                       ` David Lang
2006-05-03 19:30                         ` Petr Baudis
2006-05-03 19:46                           ` David Lang
2006-05-03 20:07                             ` Petr Baudis
2006-05-04  0:53                           ` Daniel Barkalow
2006-05-03 16:47                 ` Theodore Tso
2006-05-03 17:06                   ` Linus Torvalds
2006-05-03 17:15                     ` Theodore Tso
2006-05-03 17:40                       ` Linus Torvalds
2006-05-03 22:39                     ` Sam Ravnborg
2006-05-03 22:46                       ` Petr Baudis
2006-05-03 22:50                         ` Joel Becker
2006-05-03 23:05                           ` Petr Baudis
2006-05-03 18:04                   ` Daniel Barkalow
     [not found]                   ` <20060503144522.7b5b7ba5.seanlkml@sympatico.ca>
2006-05-03 18:45                     ` sean
2006-05-03 20:58                 ` Junio C Hamano
2006-05-03 21:01                   ` Junio C Hamano
2006-05-03 22:13                   ` Linus Torvalds

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=7vr738w8t4.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=pasky@suse.cz \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).