All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
Date: Tue, 25 Apr 2006 19:36:30 +0200	[thread overview]
Message-ID: <e2lmm3$rts$1@sea.gmane.org> (raw)
In-Reply-To: Pine.LNX.4.64.0604251004410.3701@g5.osdl.org

Linus Torvalds wrote:

> On Tue, 25 Apr 2006, Jakub Narebski wrote:
>> 
>> The generic commit links "related" which is fsck-able at least and "note"
>> which is not. It is idea somewhat on the level of providing _extended
>> attributes_ in VFS in Linux kernel, IMVHO.
> 
> And nobody actually uses extended attributes either, do they?

Fedora's SELinux does use them, IIRC.

Well, people do use X-* headers in mail (sean's example), and some of them
got promoted from X-* to ordinary mail header status.

> Plus it's _not_ fsck'able, since the thing doesn't even have any valid
> semantics. You guys can't even agree on whether the object must exist or
> not.

Erm, further on we did agree 
  http://permalink.gmane.org/gmane.comp.version-control.git/19142
  (Message-Id: <7vmzeax9gj.fsf@assigned-by-dhcp.cox.net>). 
"related" links means that object must exist. "note" is what name says, just
note and doesn't even need to point to object.

> For exactly the same reason, git should not track it when a developer says
> "I think this commit is related to that commit". It's not hard data, that
> has hard and clear semantics.
> 
> Once you start adding data that has no clear semantics, you're screwed. At
> that point, it's a "track guesses" game, not a "track contents" game.

Well, the best example, i.e. remembering cherry picking has well defined
semantic (added when cherry-picking, used when merging, object does need
not to exist) but not well defined form. Currently the convention for
free-form is used, which has its advantages and disadvantages as pointed
out by Junio.


[somewhat unrelated note]
> Git tracks contents, and the well-defined history of how those contents
> came to be. Git does NOT track "additional notes" left by the developer
> that have weak semantics. Git does not track when a developer says "I
> renamed a file".

But I'd like Git to remember when I corrected false positives in "rename"
detection during merge, and added undetected automatically renames/file
contents copying and/or moving. Whether it would be done by saving the
information in commit header, commit free-for, or somewhere else...

-- 
Jakub Narebski
Warsaw, Poland

  reply	other threads:[~2006-04-25 17:36 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-25  3:54 [RFC] [PATCH 0/5] Implement 'prior' commit object links Sam Vilain
2006-04-25  4:31 ` [PATCH 1/5] add 'prior' link in commit structure Sam Vilain
2006-04-25  5:18   ` Junio C Hamano
2006-04-25  4:31 ` [PATCH 2/5] git-merge-base: follow 'prior' links to find merge bases Sam Vilain
2006-04-25  5:19   ` Junio C Hamano
2006-04-25  4:31 ` [PATCH 5/5] git-commit: add --prior to set prior link Sam Vilain
2006-04-25  4:31 ` [PATCH 3/5] commit.c: parse 'prior' link Sam Vilain
2006-04-25  4:31 ` [PATCH 4/5] git-commit-tree: add support for prior Sam Vilain
2006-04-25  4:34 ` [RFC] [PATCH 0/5] Implement 'prior' commit object links Sam Vilain
2006-04-25  5:16 ` Junio C Hamano
2006-04-25 23:19   ` Sam Vilain
2006-04-26  5:06     ` Jakub Narebski
2006-04-26  5:22       ` Jakub Narebski
2006-04-26  5:36         ` [OT] " Junio C Hamano
2006-04-26  6:35           ` Jakub Narebski
2006-04-26  6:50             ` Junio C Hamano
2006-04-26  7:22               ` Jakub Narebski
2006-04-26  7:50                 ` Junio C Hamano
2006-04-26  8:44                   ` Jakub Narebski
2006-04-26  9:21                     ` Junio C Hamano
2006-04-26  9:28                   ` Jakub Narebski
2006-04-26  6:51       ` Sam Vilain
2006-04-25  6:44 ` [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas) Jakub Narebski
2006-04-25  7:29   ` Junio C Hamano
2006-04-25  7:43     ` Jakub Narebski
2006-04-25  8:34       ` sean
2006-04-25  8:34         ` sean
2006-04-25  8:57         ` sean
2006-04-25  8:57           ` sean
2006-04-25  9:10             ` Jakub Narebski
2006-04-25  9:58               ` Junio C Hamano
2006-04-25 10:08                 ` Jakub Narebski
2006-04-29 14:59                   ` Jakub Narebski
2006-04-25 15:21     ` Linus Torvalds
2006-04-25 15:40       ` Linus Torvalds
2006-04-25 16:17         ` sean
2006-04-25 16:17           ` sean
2006-04-25 17:04             ` Linus Torvalds
2006-04-26 11:25             ` Andreas Ericsson
2006-04-26 12:01               ` Jakub Narebski
2006-04-25 16:27         ` Jakub Narebski
2006-04-25 17:11           ` Linus Torvalds
2006-04-25 17:36             ` Jakub Narebski [this message]
2006-04-25 17:57               ` Linus Torvalds
2006-04-25 18:06                 ` Linus Torvalds
2006-04-25 18:24                   ` Jakub Narebski
2006-04-25 17:52             ` sean
2006-04-25 17:52               ` sean
2006-04-25 18:08                 ` Linus Torvalds
2006-04-25 18:14                   ` sean
2006-04-25 18:14                     ` sean
2006-04-25 18:26                       ` Linus Torvalds
2006-04-25 18:41                         ` Jakub Narebski
2006-04-25 18:52                           ` Linus Torvalds
2006-04-25 19:00                             ` Jakub Narebski
2006-04-25 22:17                               ` Jason Riedy
2006-04-25 18:45                         ` sean
2006-04-25 18:45                           ` sean
2006-04-25 19:00                             ` Linus Torvalds
2006-04-25 19:18                               ` Junio C Hamano
2006-04-25 19:34                                 ` Linus Torvalds
2006-04-25 19:51                                   ` Junio C Hamano
2006-04-25 19:58                                     ` Linus Torvalds
2006-04-26 12:42                                 ` Jakub Narebski
2006-04-25 19:00                         ` Junio C Hamano
2006-04-25 19:09                           ` Linus Torvalds
2006-04-25 18:34                       ` Jakub Narebski
2006-04-25 23:18     ` Sam Vilain
2006-04-25 15:10 ` [RFC] [PATCH 0/5] Implement 'prior' commit object links 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

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

  git send-email \
    --in-reply-to='e2lmm3$rts$1@sea.gmane.org' \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.