linux-kernel - Re: git mv (was Re: [git pull] ACPI & Suspend patches for 2.6.29-rc0)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 Jan 2009 13:16:12 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Len Brown <lenb@...nel.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-acpi@...r.kernel.org,
	Linux Power Management List <linux-pm@...ts.osdl.org>
Subject: Re: git mv (was Re: [git pull] ACPI & Suspend patches for
 2.6.29-rc0)

On Fri, 9 Jan 2009, Len Brown wrote:
> 
> I guess using 'git mv' gave me the false expectation
> that git actually tracks moves like other SCMs
> and it would show up that way in the diff -- though
> now that I think about it, I like the comparison
> of the two endpoints that git did even better.

The main reason "git mv" exists at all is just people migrating from other 
places expecting it. It's largely just purely synthetic sugar - it has 
almost no meaning to git long-term.

[ Technically, it _is_ meaningful, in that it obviously not just moves the 
  file in the checked-out copy, but it also moves the index information 
  around. So "git mv" clearly does something, but it's not important in 
  the big picture.

  So using "git mv" is really nothing fundamental - it doesn't really 
  matter to the end result, and if you had done the 'mv' by just applying 
  a patch to delete the old file and create a new one, the actual commit 
  would have been 100% identical. Think of it as a convenience function, 
  and you won't be wrong. ]

> gitk doesn't use --follow by default, and when it is added, the history 
> looks pretty strange.

Heh. That's because "--follow" is a total hack, and doesn't do the nice 
(and pretty complicated) parent rewriting that the real "git log" family 
of operations normally do.

So yeah, "--follow" is broken. It's really a quick hack there for people 
who come from some other SCM to feel more comfy with git. If you come from 
SVN or CVS, you never had proper history, and you never had "gitk" anyway, 
and so "gitk --follow" doesn't really work. But it makes the pure 
_textual_ logs look a bit like CVS/SVN.

I'd love to make --follow work better and integrate more, but I've been so 
successful at never using it myself that I don't much care. And it really 
is not a very natural thing for git to do, so the hackiness is somewhat 
inherent.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/