git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Andreas Ericsson <ae@op5.se>
Cc: Gerhard Wiesinger <lists@wiesinger.com>, git@vger.kernel.org
Subject: Re: Metadata and checkin file date
Date: Tue, 27 Apr 2010 14:18:54 -0700 (PDT)	[thread overview]
Message-ID: <m3och4d27t.fsf@localhost.localdomain> (raw)
In-Reply-To: <4BD73F64.1070604@op5.se>

Andreas Ericsson <ae@op5.se> writes:
> On 04/27/2010 09:38 PM, Gerhard Wiesinger wrote:
>> On Tue, 27 Apr 2010, Andreas Ericsson wrote:
>>> On 04/27/2010 07:23 AM, Gerhard Wiesinger wrote:
>>>>
>>>> I'm new to git and I'm looking for the following features:
>>>> 1.) Metadata for
>>>> a.) directory versioning (e.g. add/rm, mv)
>>>
>>> If you're talking about empty directories, that feature doesn't
>>> exist and I can't imagine why you'd want it to. If you'd care to
>>> explain why you want it, I'm sure we can find a different way of
>>> achieving your goal.
>> 
>> Git focuses on content but I think git should also focus on metadata. 
>> For example restructuring source code moves (git mv file1.c file2.c, git 
>> mv dir1 dir2) should be documented also in the repository like e.g. 
>> subversion and commercial SCM like clearcase do. Otherwise we are on 
>> "CVS" level.

"git mv file1.c file2.c" works in practice thanks to heuristic
similarity based rename detection that git uses.  (Note that it might
not work in simplistic tests.)

"git mv dir1 dir2" works via _file_ rename detection, except for one
use case, namely when on one branch one does "git mv dir1 dir2", 
and in other branch one does "git add dir1/file.c" (new file in old
directory name).  See also below.

>> Empty directories is a special case and sometimes you need just 
>> versioned empty directies.
> 
> This has been discussed to death several times before on this mailing
> list. Browse the archives. There haven't been any new arguments the
> last 14 times it came up, so I doubt you'll be able to come up with
> a single good reason to track file renames explicitly.

There are three issues conflated here:

1. Rename tracking.  This is no go.  The only idea that have hint of
   being perhaps possibly accepted is recording resolutions of
   tree-level conflict in git-rerere2 cache.

2. Wholesame directory rename detection.  Possible, there were even
   some proof of concept patches send to git mailing list, but it
   didn't get merged in.  Would need to be resurrected, but this is
   not easy task.

3. Support for versioning empty directories.  Possible, but it would
   require extending index (the staging area one) to be able to hold
   not only files but also directories.  Not very easy.

   Current workaround: empty .gitignore / .keepme files.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

  parent reply	other threads:[~2010-04-27 21:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-27  5:23 Metadata and checkin file date Gerhard Wiesinger
2010-04-27  9:22 ` Andreas Ericsson
2010-04-27 19:38   ` Gerhard Wiesinger
2010-04-27 19:47     ` Andreas Ericsson
2010-04-27 20:00       ` Gerhard Wiesinger
2010-04-27 21:25         ` Jakub Narebski
2010-04-27 21:18       ` Jakub Narebski [this message]
2010-04-27  9:35 ` Jakub Narebski
2010-04-27 19:41   ` Gerhard Wiesinger
2010-04-27 20:55     ` Jakub Narebski

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=m3och4d27t.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=lists@wiesinger.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).