* Re: Gmail and unwanted line-wrapping
From: Jay Soffian @ 2010-02-07 0:51 UTC (permalink / raw)
To: David Aguilar; +Cc: Sverre Rabbelier, Aaron Crane, git
In-Reply-To: <76718491002061650ge299426s22de5e00b26af108@mail.gmail.com>
On Sat, Feb 6, 2010 at 7:50 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> tls_trust_file /opt/local/share/curl/curl-ca-bundle.crt
Actually you need the curl-ca-bundle port.
j.
^ permalink raw reply
* Using ‘git replace’ to replace blobs
From: Jonathan Nieder @ 2010-02-07 1:10 UTC (permalink / raw)
To: git; +Cc: Christian Couder
I think it is a known problem that ‘git replace’ cannot be used safely
to replace blobs used in the currently checked out commit. The man
page says:
Comparing blobs or trees that have been replaced with
those that replace them will not work properly.
Indeed, in practice it produces problems. [1]
I would like to start to fix this. But the correct semantics are not
obvious to me:
- When writing a tree from an index that includes replaced blobs,
should the result use the original blobs or the replaced ones?
- When reading a tree that includes replaced blobs, should the
resulting cache entries use the original blobs or the replaced
ones?
My hunch is to say both should use the replaced blobs. This way,
replacing a blob in a checked-out index would behave in a more
intuitive way, and git filter-branch would make permanent any
substitutions requested through replaced blob entries.
I have not thought it through completely, though.
Thoughts?
Jonathan
[1] For example,
git init repo
cd repo
echo first > 1.txt
echo second > 2.txt
git add 1.txt 2.txt
git commit -m demonstration
git show --raw
git ls-tree HEAD | awk '
NR == 1 { first = $3 }
NR == 2 { system("git replace " first " " $3) }
'
git status
rm *
git checkout -f
git status
which one would expect to result in a clean tree, produces
Initialized empty Git repository in /tmp/repo/.git/
[master (root-commit) 998cc27] demonstration
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 1.txt
create mode 100644 2.txt
commit 998cc270986f68450f00bda5e5db62f31367ff96
Author: Jonathan Nieder <jrnieder@gmail.com>
Date: Sat Feb 6 18:48:50 2010 -0600
demonstration
:000000 100644 0000000... 9c59e24... A 1.txt
:000000 100644 0000000... e019be0... A 2.txt
# On branch master
nothing to commit (working directory clean)
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
# directory)
#
# modified: 1.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
^ permalink raw reply
* Re: git gc / git repack not removing unused objects?
From: Nicolas Pitre @ 2010-02-07 1:16 UTC (permalink / raw)
To: Jon Nelson; +Cc: git
In-Reply-To: <cccedfc61002060553w464d5d9drd582b3b3c3f35227@mail.gmail.com>
On Sat, 6 Feb 2010, Jon Nelson wrote:
> Last night, the repo size was 153G after removing some commits and
> objects by way of git filter-branch.
> I'm using "du -sh" in the .git directory to determine the disk usage.
>
> Before: 136G
> git repack -dAl
> After: 153G
Why are you using -A instead of -a ?
> Then, just to make sure of some things, I changed nothing and simply
> re-ran "git repack -dAl".
> After: 167G
Could you run 'git count-objects -v' before and after a repack in such
cases as well?
> [pack]
> packsizelimit = 256m
Why are you using this?
> pack.packsizelimit=2M
This is even worse. 150G / 2M per pack = approx 75000 packs.
What you should be aiming for is a _single_ pack for best performances.
A couple packs is common and doesn't make much of a difference. A
hundred packs is getting a bit large. But 75000 packs is totally
insane.
Nicolas
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Jakub Narebski @ 2010-02-07 1:20 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Johannes Schindelin, Johan Herland, Junio C Hamano
In-Reply-To: <cb7bb73a1002061458s5b2c1e7ere83111429473d11c@mail.gmail.com>
On Sat, 6 Feb 2010, Giuseppe Bilotta wrote:
> On Sat, Feb 6, 2010 at 11:14 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sat, 6 Feb 2010, Giuseppe Bilotta wrote:
>>> 2010/2/6 Jakub Narebski <jnareb@gmail.com>:
>>>> On Thu, 4 Feb 2010, Giuseppe Bilotta wrote:
>>
>>>>> + # Notes support. When this feature is enabled, the presence of notes
>>>>> + # for any commit is signaled, and the note content is made available
>>>>> + # in a way appropriate for the current view.
>>>>> + # Set this to '*' to enable all notes namespace, or to a shell-glob
>>>>> + # specification to enable specific namespaces only.
>>>>
>>>> It is not obvious from this description that you can provide _list_ of
>>>> notes namespaces (or list of shell-globs).
>>>
>>> I'm starting to think it might make sense to not have a list here, but
>>> rather a single value only. First of all, multiple refs can be
>>> indicated à la shell with {ref1,ref2,ref3}. Or, we can also use the
>>> intended command-line syntax ref1:ref2:ref3, which would help
>>> consistency. It also makes things easier for project overrides, as per
>>> your subsequent comment:
>>
>> So it is to be single shell-glob / fnmatch (I think) compatible pattern,
>> isn't it?
>
> Sort of. fnmatch doesn't do brace expansion, which is a pity IMO, but
> that's just my personal preference.
Well, fnmatch is what I think git uses for <pattern> e.g. for
git-for-each-ref.
> Colon-separated, fnmatched components is probably the easiest thing to
> implement to have multiple refs. I'll go with whatever is chosen for
> core.
I think that having actual list of patterns in $feature{'notes'}{'default'}
might be more clear; you would still need colon separated (or space
separated) list of patterns in per-repo override in gitweb.notes config
variable.
So it would be
$feature{'notes'}{'default'} = ['commits', '*svn*'];
$feature{'notes'}{'override'} = 1;
but
[gitweb]
notes = commits:*svn*
Note that refs names cannot contain either colon ':' or space ' '
(see git-check-ref-format).
>>>> First, there are '--batch' and '--batch-check' options to git-cat-file.
>>>> With these I think you can get all notes with just single git command,
>>>> although using it is a bit complicated (requires open2 from IPC::Open2
>>>> for bidi communication).
>>>
>>> Hm. The IPC::Open2 doc makes it sound horribly scary, but still doable.
>>
>> It would look something like the following (fragment of my WIP code):
>>
>> use IPC::Open2 qw(open2);
>> use IO::Handle;
>>
>> # ...
>>
>> unless ($object_stdout) {
>> # Open bidi pipe the first time get_object is called.
>> # open2 raises an exception on error, no need to 'or die'.
>> $object_pid =
>> open2($object_stdout, $object_stdin,
>> git_cmd(), 'cat-file', '--batch');
>> }
>> $object_stdin->printflush("$object_id\n") # NB: \n required to avoid deadlocking
>> or die "get_object: cannot write to pipe: $!";
>> my ($sha1, $type, $size) =
>> split ' ', $object_stdout->getline()
>> or die "get_object: cannot read from pipe: $!";
>> die "'$object_id' not found in repository"
>> if $type eq 'missing';
>> $object_stdout->read(my $content, $size);
>> $object_stdout->getline(); # eat trailing newline
>>
>> The above fragment of code is tested that it works. You would probably
>> need to replace dies with something less fatal...
>
> On the other hand, as mentioned by Junio, this approach is not
> future-proof enough for any kind of fan-out schemes.
On the third hand ;-P you propose below a trick to deal with fan-out
schemes, assuming that they use 2-character component breaking.
Also, perhaps "git notes show" should acquire --batch / --batch-check
options, similar to git-cat-file's options of the same name?
>
>>>> Second, if not using 'git cat-file --batch', perhaps it would be easier
>>>> to read each $note_ref tree using 'git ls-tree'/'git ls-tree -r', and
>>>> parse its output to check for which commits/objects there are notes
>>>> available, and only then call 'git show' (or reuse connection to
>>>> 'git cat-file --batch').
>>>>
>>>> The second solution, with a bit more work, could work even in presence
>>>> of fan-out schemes for notes, I think.
>>>
>>> An interesting approach. Without fan-out, git ls-tree -r
>>> refs/notes/whatever [hash ...] gives us the blobs we're interested in.
>>> In case of fan-out schemes, the efficiency of this approach probably
>>> depends on the kind of fan-out we have, and would require some
>>> heavy-duty grepping. A git ls-notes plumbing with a similar syntax and
>>> output would be a nice thing to have.
>>
>> No grepping, just pass '-r' option to 'git-ls-tree', and use
>> parse_ls_tree_line() to parse lines. Then if we have fanout scheme
>> we would get, I guess, something like the following:
>>
>> 100644 blob 23da787d... de/adbeef...
>> 100644 blob bc10f25f... c5/31d986...
>> 100644 blob c9656ece... 24/d93129...
>>
>> Now you only need to s!/!!g on filename to get SHA1 of annotated object
>> (for which is the note).
>
> What worries me is that you're going to get fan-outs when there are
> LOTS of notes, and that's precisely the kind of situation where you
> _don't_ want to go through all the notes to pick the ones you're only
> interested in.
Right. This method would be contrary to the goals of fan-out schemes...
well, we could use 'git ls-tree' without '-r' option, or simply
'git cat-file --batch' to read trees (note that we would get raw,
unformatted tree, which is parseable with Perl, but it is not that easy),
and go down level-by-level.
>
> If we have a guarantee that the fan-outs follow a 2/[2/...] scheme,
> the open2 approach might still be the best way to go, by just trying
> not only namespace:xxxxx...xxx but also namespace:xx/xxxxx etc.
> Horrible, but could still be coalesced in a single call. It mgiht also
> be optimized to stop at the first successfull hit in a namespace.
Nice trick! It seems like quite a good idea... but it would absolutely
require using 'git cat-file --batch' rather than one git-show per try.
>> P.S. We still would want parse_commit_text to parse notes from default
>> namespace. parse_commit / parse_commits output contains notes from
>> default namespace, e.g.:
>>
>> d6bbe7fd52058cdf0e48bec00701ae0f4861dcd3 94ac0c7b30a7dc43d926b0ffbe90892c1e19e5f6
>> tree b9ee8876df81b80b13c6b017be993fff8427cfaf
>> parent 94ac0c7b30a7dc43d926b0ffbe90892c1e19e5f6
>> author Jakub Narebski <jnareb@gmail.com> 1265309578 +0100
>> committer Jakub Narebski <jnareb@gmail.com> 1265309578 +0100
>>
>> This is a commit message
>>
>> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
>>
>> Notes:
>> This is just a note for commit d6bbe7fd52058cdf0e48bec00701ae0f4861dcd3
>>
>> to get commit message lines in $co{'comment'} (as array reference),
>> and notes in $co{'note'} (or $co{'notes'}).
>
> I'm not getting these in the repo I'm testing this. And I think this
> is indeed the behavior of current git next
Errr, I not made myself clear.
I have added a note to a commit, using "git notes edit d6bbe7f". Now if
you take a look at gitweb output for this commit (e.g. 'commit' view for
this commit) using gitweb without your changes, you would see that it
flattened notes at the bottom of the commit message (which I think is
intended result by notes implementation).
If you run the command that parse_commit runs, namely
$ git rev-list --parents --header -z --max-count=1 \
d6bbe7fd52058cdf0e48bec00701ae0f4861dcd3
you would get (up to invisible NUL characters) the output shown above.
From this output I would like to separate commit message from notes
in parse_commit_text subroutine.
I have set neither GIT_NOTES_REF nor core.notesRef.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: A generalization of git notes from blobs to trees - git metadata?
From: Johan Herland @ 2010-02-07 1:36 UTC (permalink / raw)
To: Jon Seymour; +Cc: git
In-Reply-To: <2cfc40321002060532g4d22dd4dx403bf312708e1424@mail.gmail.com>
On Saturday 06 February 2010, Jon Seymour wrote:
> git notes is a nice innovation - well done to all those involved.
Thanks.
> Has consideration ever been given to generalizing the concept to allow
> note (or more correctly - metadata) trees with arbitrary sha1s?
Not sure what you mean here. The note infrastructure allows _any_ SHA1 (not
necessarily the SHA1 of an existing Git object) to be bound to a note
object.
Furthermore, although we currently assume that all note objects are blobs,
someone (who?) has already suggested (as mentioned in the notes TODO list)
that a note object could also be a _tree_ object that can be unpacked/read
to reveal further "sub-notes". Hence, in addition to having multiple notes
refs (e.g. refs/notes/commits:deadbeef, refs/notes/bugs:deadbeef, etc.) to
categorize notes, you could also classify notes _after_ having traversed the
notes tree (e.g. refs/notes/bugs:deadbeef/fixes,
refs/notes/bugs:deadbeef/causes). Note that support for this has not yet
been written, and AFAIK it is also uncertain how such a change would affect
the different use cases for notes (e.g. how to display them in 'git log')
> For example, suppose you had reason to cache the distribution that
> resulted from the build of a particular commit, then it'd be nice to
> be able to do this using a notes like mechanism.
>
> git metadata import foo-1.1.0 dist ~/foo/dist
>
> would create a git tree from the contents of ~/foo/dist and then bind
> it to meta item called dist associated with the sha1 corresponding to
> foo-1.1.0
You can do this already today by simply using 'git tag':
# Prepare an index with the contents of ~/foo/dist
git tag foo-1.1.0-dist $(git write-tree)
I don't see why you'd need to add a new metadata command.
> To retrieve the contents of the previous build, you'd do something like
>
> get metadata export foo-1.1.0 dist /tmp/foo-1.1.0
>
> This would find the metadata tree associated with foo-1.1.0, extract
> the dist subtree from that tree and write it to disk at /tmp/foo-1.1.0
Or, if you use a tag instead:
git --work-tree=/tmp/foo-1.1.0 checkout foo-1.1.0-dist
> I've used build outputs as an example here, but really it needn't be
> limited to that. I can see this facility would be useful for any kind
> of annotation or derived result that is more complex than a single
> text blob. Metadata trees in combination with a name spacing
> technique, could be used to store arbitrary metadata created by an
> arbitrary set of tools to arbitrary SHA1 objects.
I still don't see why this provides anything that isn't already supported by
either using 'git tag', or by implementing support for notes-as-trees in the
notes feature.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Jakub Narebski @ 2010-02-07 1:38 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Johannes Schindelin, Johan Herland, Junio C Hamano
In-Reply-To: <201002070220.36897.jnareb@gmail.com>
On Sun, 7 Feb 2010, Jakub Narebski wrote:
> Right. This method would be contrary to the goals of fan-out schemes...
> well, we could use 'git ls-tree' without '-r' option, or simply
> 'git cat-file --batch' to read trees (note that we would get raw,
> unformatted tree, which is parseable with Perl, but it is not that easy),
> and go down level-by-level.
FYI, here is how you can parse raw tree output from 'git cat-file --batch',
assuming that you have plain-ASCII filenames ('use bytes;' would probably
be needed):
-- 8< --
sub decode_tree {
my $contents = shift;
# ...
while (my @entry = decode_tree_entry($contents)) {
# ...
my $len = tree_entry_len(@entry);
contents = substr($contents, $len);
last unless $contents;
}
# ...
}
sub tree_entry_len {
my ($mode_str, $filename) = @_;
# length of mode string + separator + 20 bytes of SHA-1
# + length of filename (in bytes) + terminating NUL ('\0')
length($mode_str)+1 + length($filename)+1 + 20;
}
sub decode_tree_entry {
my $buf = shift;
$buf =~ s/^([0-7]+) //;
my ($mode_str) = $1;
my ($filename, $sha1_str) = unpack('Z*H[40]', $buf);
return ($mode_str, $filename, $sha1_str);
}
-- >8 --
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Johan Herland @ 2010-02-07 1:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Giuseppe Bilotta, git, Johannes Schindelin, Junio C Hamano
In-Reply-To: <201002070220.36897.jnareb@gmail.com>
On Sunday 07 February 2010, Jakub Narebski wrote:
> On Sat, 6 Feb 2010, Giuseppe Bilotta wrote:
> > On the other hand, as mentioned by Junio, this approach is not
> > future-proof enough for any kind of fan-out schemes.
>
> On the third hand ;-P you propose below a trick to deal with fan-out
> schemes, assuming that they use 2-character component breaking.
The current notes code (as it stands in 'pu') use only 2-character component
breaking, and I don't see any other fanout mechanism being added anytime
soon.
> Also, perhaps "git notes show" should acquire --batch / --batch-check
> options, similar to git-cat-file's options of the same name?
I'd much rather have support for ^{notes} (or similar) in the rev-parse
machinery, so that you could look up deadbeef's notes by passing
"deadbeef^{notes}" to 'git cat-file --batch'.
> > What worries me is that you're going to get fan-outs when there are
> > LOTS of notes, and that's precisely the kind of situation where you
> > _don't_ want to go through all the notes to pick the ones you're only
> > interested in.
>
> Right. This method would be contrary to the goals of fan-out schemes...
> well, we could use 'git ls-tree' without '-r' option, or simply
> 'git cat-file --batch' to read trees (note that we would get raw,
> unformatted tree, which is parseable with Perl, but it is not that easy),
> and go down level-by-level.
IMHO, it's much better/nicer to re-use the notes code for parsing note
trees. See above suggestion on deadbeef^{notes}.
> > If we have a guarantee that the fan-outs follow a 2/[2/...] scheme,
> > the open2 approach might still be the best way to go, by just trying
> > not only namespace:xxxxx...xxx but also namespace:xx/xxxxx etc.
> > Horrible, but could still be coalesced in a single call. It mgiht also
> > be optimized to stop at the first successfull hit in a namespace.
>
> Nice trick! It seems like quite a good idea... but it would absolutely
> require using 'git cat-file --batch' rather than one git-show per try.
Still, I'd still much rather use the notes.c code itself for doing this
since it should always be the fastest (not to mention future-proof) way of
making lookups in the notes tree.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Fwd: how to apply patch?
From: Matt Di Pasquale @ 2010-02-07 2:05 UTC (permalink / raw)
To: git
In-Reply-To: <13f0168a1002061720t93ff6aew3420a41a547549d8@mail.gmail.com>
I have a development version & a production version of my website.
There are a few essential differences between them that I want to
always stay different (like path constants, etc). When I make changes
on the dev version and test it out and they work and am ready to copy
them to the production (www) version, how do i do that without
annihilating the essential differences that i want to keep? I was
thinking of creating a patch or branch or something with the
differences. Then, copy dev to pro, then reapply/rebase the essential
differences to pro that got wiped out. if i rebase though, i want to
be able to rebase again on the next edit.
what's a good way to do this?
My dir structure:
example.com
www # production site
dev # development site
Via DreamHost control panel:
www.example.com points to example.com/www/
dev.example.com points to example.com/dev/
Why don't I just have a branch called dev? Maybe I should... Advice?
(Anyway, it's nice to be able quickly, simultaneously open
corresponding files from both www & dev in textmate.
I guess I could do that with like git show master:www/index.html |
mate or something, but then it opens in a new textmate window. it's
just not the same. I guess there's always the possibility of editing
www/index.html when I actually want to be editing dev/index.html, but
then again, it's also possible to be editing the wrong branch.)
My .git/config file has the following aliases for deployment:
# deploy dev
ddev = !rsync -avi --copy-unsafe-links --exclude='*.DS_Store'
--delay-updates --delete-after --delete-excluded -e ssh
~/Sites/example.com/dev/ acani@acani.com:Sites/example.com/dev/
# deploy www
dpro = !rsync -avi --copy-unsafe-links --exclude='*.DS_Store'
--delay-updates --delete-after --delete-excluded -e ssh
~/Sites/example.com/www/ username@example.com:Sites/example.com/www/
Thanks!
Matt
^ permalink raw reply
* Current stgit asks SMTP password for every patch
From: Pavel Roskin @ 2010-02-07 2:18 UTC (permalink / raw)
To: Alex Chiang; +Cc: git
Hello, Alex!
I was unpleasantly surprised when the current STGit started asking me
for the SMTP password for every patch in the series:
$ stg mail --to minicom ncurses-const..clobber
Checking the validity of the patches ... done
Sending patch "ncurses-const" ... Please enter SMTP password:
done
Sending patch "precision-int" ... Please enter SMTP password:
done
Sending patch "aliasing" ... Please enter SMTP password:
done
Sending patch "clobber" ... Please enter SMTP password:
done
The code in __send_message_smtp() lacks any caching for the smtppassword
variable. The code comes from your commit
89d7ec43e0b25cc6cbc9feb044d7ce7048f224eb
stg mail: Refactor __send_message and friends
Ideally, asking for the password (as well as other verification of the
e-mail credentials) should be done before "Sending patch" is shown, and
before the cover letter if any. That is, it should be in func() in
stgit/commands/mail.py.
But I'll also be fine with a simple-minded password caching in
__send_message_smtp().
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: A generalization of git notes from blobs to trees - git metadata?
From: Junio C Hamano @ 2010-02-07 2:21 UTC (permalink / raw)
To: Johan Herland; +Cc: Jon Seymour, git
In-Reply-To: <201002070236.12711.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> Furthermore, although we currently assume that all note objects are blobs,
> someone (who?) has already suggested (as mentioned in the notes TODO list)
> that a note object could also be a _tree_ object that can be unpacked/read
> to reveal further "sub-notes".
I would advice you not to go there. How would you even _merge_ such a
thing with other notes attached to the same object? What determines the
path in that tree object?
Clueless ones can freely make misguided suggestions without thinking
things through and make things unnecessarily complex without real gain.
You do not have to listen to every one of them.
^ permalink raw reply
* 1.7.0-rc2 tomorrow...
From: Junio C Hamano @ 2010-02-07 2:29 UTC (permalink / raw)
To: Shawn O. Pearce, Eric Wong, Paul Mackerras; +Cc: git
If you have updates meant for 1.7.0 (translations, etc.), please tell me
to pull in the next 18 hours or so.
Thanks.
^ permalink raw reply
* Re: A generalization of git notes from blobs to trees - git metadata?
From: Jon Seymour @ 2010-02-07 3:27 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Junio C Hamano
In-Reply-To: <201002070236.12711.johan@herland.net>
> I still don't see why this provides anything that isn't already supported by
> either using 'git tag', or by implementing support for notes-as-trees in the
> notes feature.
>
The intent of the metadata facility is to associate derivatives of
sha1 with the sha1 itself. If I have calculated a derivative of sha1
in the past, then let me reference that derivative using a metadata
path which I can look up knowing only the sha1 of the input and
nothing more. Yes, I could create tags of the form
${sha1}/metadata-path for all my derived results but really, this
seems an abuse of the tag facility.
Here's another motivating example:
Suppose git-svn wrote the SVN id it was synched with into structured
metadata associated with a commit, instead of into the commit message,
the equivalent of:
echo ${svn-id} | git metadata write-blob ${sha1} svn-id
Which means: for the specified sha1, read a blob from stdin and create
a metadata item with a metadata path called svn-id
To get it out again, you would write:
git metadata read-blob ${sha1} svn-id
Which says, for the given object ${sha1}, read the blob from the
metadata tree at path svn-id and write its contents to stdout.
This would avoid cluttering the commit message with the svn-id, avoid
cluttering the tag space with the info and allow any commit to be
tagged in this way.
Admittedly similar function could be achieved a little more clumsily
now with appropriate use of GIT_NOTES_REF or with note subtrees, but I
share Junio's reservations about trying to generalize notes from
blobs to trees, given way notes are currently used by the rest of
infrastructure.
jon.
^ permalink raw reply
* Re: A generalization of git notes from blobs to trees - git metadata?
From: Jon Seymour @ 2010-02-07 4:32 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Junio C Hamano
In-Reply-To: <2cfc40321002061927m522f0c3aj7d727c47a2f0cb22@mail.gmail.com>
Another use case could be to store the contents of the man and html
trees of git, which are currently published as separate branches.
With the metadata concept, the man and html trees for each release
could be stored as metadata paths (/man, /html) of the associated
commit for each release, providing a trivial way to address and access
these trees.
jon.
On Sun, Feb 7, 2010 at 2:27 PM, Jon Seymour <jon.seymour@gmail.com> wrote:
>> I still don't see why this provides anything that isn't already supported by
>> either using 'git tag', or by implementing support for notes-as-trees in the
>> notes feature.
>>
>
> The intent of the metadata facility is to associate derivatives of
> sha1 with the sha1 itself. If I have calculated a derivative of sha1
> in the past, then let me reference that derivative using a metadata
> path which I can look up knowing only the sha1 of the input and
> nothing more. Yes, I could create tags of the form
> ${sha1}/metadata-path for all my derived results but really, this
> seems an abuse of the tag facility.
>
> Here's another motivating example:
>
> Suppose git-svn wrote the SVN id it was synched with into structured
> metadata associated with a commit, instead of into the commit message,
> the equivalent of:
>
> echo ${svn-id} | git metadata write-blob ${sha1} svn-id
>
> Which means: for the specified sha1, read a blob from stdin and create
> a metadata item with a metadata path called svn-id
>
> To get it out again, you would write:
>
> git metadata read-blob ${sha1} svn-id
>
> Which says, for the given object ${sha1}, read the blob from the
> metadata tree at path svn-id and write its contents to stdout.
>
> This would avoid cluttering the commit message with the svn-id, avoid
> cluttering the tag space with the info and allow any commit to be
> tagged in this way.
>
> Admittedly similar function could be achieved a little more clumsily
> now with appropriate use of GIT_NOTES_REF or with note subtrees, but I
> share Junio's reservations about trying to generalize notes from
> blobs to trees, given way notes are currently used by the rest of
> infrastructure.
>
> jon.
>
^ permalink raw reply
* Re: how to apply patch?
From: Tay Ray Chuan @ 2010-02-07 4:40 UTC (permalink / raw)
To: Matt Di Pasquale; +Cc: git
In-Reply-To: <13f0168a1002061805o5d64c05cy9d8f0190a8f37feb@mail.gmail.com>
Hi,
On Sun, Feb 7, 2010 at 10:05 AM, Matt Di Pasquale
<liveloveprosper@gmail.com> wrote:
> [snip]
> Then, copy dev to pro, then reapply/rebase the essential
> differences to pro that got wiped out. if i rebase though, i want to
> be able to rebase again on the next edit.
> what's a good way to do this?
you could put this in your config:
[remote local]
url = .
fetch = dev
[branch "pro"]
remote = local
rebase = true
When you're wish to incorporate your latest changes in "dev" into
"pro(duction)",
$ git checkout pro #assuming you're not already on "pro"
$ git pull
Repeat ad nauseum.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: git-grep: option parsing conflicts with prefix-dash searches
From: Jeff King @ 2010-02-07 4:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan Engelhardt, git
In-Reply-To: <7v8wb64623.fsf@alter.siamese.dyndns.org>
On Sat, Feb 06, 2010 at 09:39:32AM -0800, Junio C Hamano wrote:
> > I think so. It was the first thing the original poster in this thread
> > tried. It is also something I have tried (and still do, then grumblingly
> > retype "-e pattern"). And it certainly makes sense from a user
> > perspective; it is the same end-of-options signal that most other
> > programs take.
>
> Ok, then let's take that (perhaps before 1.7.0 perhaps after).
Here it is with a commit message and some tests. While it is a minor
change, we are pretty late in the release cycle, so perhaps it is best
to leave it post-1.7.0 just to be on the safe side.
-- >8 --
Subject: [PATCH] accept "git grep -- pattern"
Currently the only way to "quote" a grep pattern that might
begin with a dash is to use "git grep -e pattern". This
works just fine, and is also the way right way to do it on
many traditional grep implemenations.
Some people prefer to use "git grep -- pattern", however, as
"--" is the usual "end of options" marker, and at least GNU
grep and Solaris 10 grep support this. This patch makes that
syntax work.
There is a slight behavior change, in that "git grep -- $X"
used to be interpreted as "grep for -- in $X". However, that
usage is questionable. "--" is usually the end-of-options
marker, so "git grep" was unlike many other greps in
treating it as a literal pattern (e.g., both GNU grep and
Solaris 10 grep will treat "grep --" as missing a pattern).
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-grep.c | 10 ++++++++++
t/t7002-grep.sh | 33 +++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 26d4deb..63d4b95 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -861,6 +861,16 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
PARSE_OPT_STOP_AT_NON_OPTION |
PARSE_OPT_NO_INTERNAL_HELP);
+ /*
+ * skip a -- separator; we know it cannot be
+ * separating revisions from pathnames if
+ * we haven't even had any patterns yet
+ */
+ if (argc > 0 && !opt.pattern_list && !strcmp(argv[0], "--")) {
+ argv++;
+ argc--;
+ }
+
/* First unrecognized non-option token */
if (argc > 0 && !opt.pattern_list) {
append_grep_pattern(&opt, argv[0], "command line", 0,
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index 7144f81..0b583cb 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -434,4 +434,37 @@ test_expect_success 'grep -Fi' '
test_cmp expected actual
'
+test_expect_success 'setup double-dash tests' '
+cat >double-dash <<EOF &&
+--
+->
+other
+EOF
+git add double-dash
+'
+
+cat >expected <<EOF
+double-dash:->
+EOF
+test_expect_success 'grep -- pattern' '
+ git grep -- "->" >actual &&
+ test_cmp expected actual
+'
+test_expect_success 'grep -- pattern -- pathspec' '
+ git grep -- "->" -- double-dash >actual &&
+ test_cmp expected actual
+'
+test_expect_success 'grep -e pattern -- path' '
+ git grep -e "->" -- double-dash >actual &&
+ test_cmp expected actual
+'
+
+cat >expected <<EOF
+double-dash:--
+EOF
+test_expect_success 'grep -e -- -- path' '
+ git grep -e -- -- double-dash >actual &&
+ test_cmp expected actual
+'
+
test_done
--
1.7.0.rc1.58.g769126
^ permalink raw reply related
* Re: A generalization of git notes from blobs to trees - git metadata?
From: Jeff King @ 2010-02-07 5:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, Jon Seymour, git
In-Reply-To: <7v1vgxlr9q.fsf@alter.siamese.dyndns.org>
On Sat, Feb 06, 2010 at 06:21:37PM -0800, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
>
> > Furthermore, although we currently assume that all note objects are blobs,
> > someone (who?) has already suggested (as mentioned in the notes TODO list)
> > that a note object could also be a _tree_ object that can be unpacked/read
> > to reveal further "sub-notes".
>
> I would advice you not to go there. How would you even _merge_ such a
> thing with other notes attached to the same object? What determines the
> path in that tree object?
>
> Clueless ones can freely make misguided suggestions without thinking
> things through and make things unnecessarily complex without real gain.
> You do not have to listen to every one of them.
I think I may have been the one to suggest trees or notes at one point.
But let me clarify that this is not exactly what the OP is proposing in
this thread.
My suggestion was that some use cases may have many key/value pairs of
notes for a single sha1. We basically have two options:
1. store each in a separate notes ref, with each sha1 mapping to
a blob. The note "name" is the name of the ref.
2. store notes in a single notes ref, with each sha1 mapping to a
tree with named sub-notes. The note "name" is the combination of
ref-name and tree entry name.
The advantage of (1) is that notes are not bound tightly to each other.
I can distribute the notes tree for one "name" independent of the
others. The advantage of (2) is that it is faster and smaller. In (1),
each note has a separate index, and we must traverse each note index
separately.
In practice, I would expect to use (1) for logically separate datasets.
For example, automatic bug-tracking notes would go in a different ref
from human annotations. But I would expect to use (2) if I had, say, 5
different pieces of bug tracking information and I wanted an easy way to
refer to them individually.
And a specialized merge for that is straightforward. In the simplest
case, you simply say "notes of this ref are tree-type, or they are
blob-type" and then you have no merge problems. But if you want to get
fancy, you can say that a conflict between "sha1/blob" and
"sha1/tree/key" should automatically "promote" the first one into
"sha1/tree/default" or some other canonical name.
Note that all of this is my pie-in-the-sky "here is what I was thinking
of when I looked at notes a long time ago". I don't care strongly if it
gets implemented or not at this point; I just wanted to add some context
to what Johan had in his notes todo list (or maybe I am wrong, and what
is in his todo list was based on something totally different said by
somebody else, and I have just confused the issue more. :) ).
With respect to the idea of storing an arbitrary tree, I agree it is
probably too complex with respect to merging. In addition, it makes
things like "git log --format=%N" confusing. I think you would do better
to simply store a tree sha1 inside the note blob, and callers who were
interested in the tree contents could then dereference it and examine as
they saw fit. The only caveat is that you need some way of telling git
that the referenced trees are reachable and not to be pruned.
-Peff
^ permalink raw reply
* Re: [PATCH v2] cvsimport: new -R option: generate .git/cvs-revisions mapping
From: Jeff King @ 2010-02-07 5:10 UTC (permalink / raw)
To: Aaron Crane; +Cc: git
In-Reply-To: <bc341e101002061026t2e7fa4cfte9119bf7fc2d2ddc@mail.gmail.com>
On Sat, Feb 06, 2010 at 06:26:24PM +0000, Aaron Crane wrote:
> I believe this revised patch takes account of all his comments. In
> particular, compared to the previous version:
>
> - Tests are included
> - Now works with incremental import
> - The file is always generated as .git/cvs-revisions, rather than
> letting the user pick the name
Thanks, it looks much better.
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: A generalization of git notes from blobs to trees - git metadata?
From: Jon Seymour @ 2010-02-07 5:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johan Herland, git
In-Reply-To: <20100207050255.GA17049@coredump.intra.peff.net>
On Sun, Feb 7, 2010 at 4:02 PM, Jeff King <peff@peff.net> wrote:
> On Sat, Feb 06, 2010 at 06:21:37PM -0800, Junio C Hamano wrote:
>
>> Johan Herland <johan@herland.net> writes:
>>
>> > Furthermore, although we currently assume that all note objects are blobs,
>> > someone (who?) has already suggested (as mentioned in the notes TODO list)
>> > that a note object could also be a _tree_ object that can be unpacked/read
>> > to reveal further "sub-notes".
>>
>> I would advice you not to go there. How would you even _merge_ such a
>> thing with other notes attached to the same object? What determines the
>> path in that tree object?
>>
>> Clueless ones can freely make misguided suggestions without thinking
>> things through and make things unnecessarily complex without real gain.
>> You do not have to listen to every one of them.
>
> I think I may have been the one to suggest trees or notes at one point.
> But let me clarify that this is not exactly what the OP is proposing in
> this thread.
>
> My suggestion was that some use cases may have many key/value pairs of
> notes for a single sha1. We basically have two options:
>
> 1. store each in a separate notes ref, with each sha1 mapping to
> a blob. The note "name" is the name of the ref.
>
> 2. store notes in a single notes ref, with each sha1 mapping to a
> tree with named sub-notes. The note "name" is the combination of
> ref-name and tree entry name.
>
So, of course, options (1) and (2) need not be exclusive. Use Option
(1) for different metadata sets and option (2) to partition individual
datasets.
>
> With respect to the idea of storing an arbitrary tree, I agree it is
> probably too complex with respect to merging. In addition, it makes
> things like "git log --format=%N" confusing. I think you would do better
> to simply store a tree sha1 inside the note blob, and callers who were
> interested in the tree contents could then dereference it and examine as
> they saw fit. The only caveat is that you need some way of telling git
> that the referenced trees are reachable and not to be pruned.
>
As I see it, the existing use of notes is a special instance of a more
general metadata capability in which the metadata is constrained to be
a single blob. If notes continued to be constrained in this way, there
is no reason to change anything with respect to its current userspace
behaviour. That said, most of the plumbing which enabled notes could
be generalized to enable the arbitrary tree case [ which admittedly, I
have yet to sell successfully !]
In one sense, there is a sense in the merge issue doesn't exist. When
the maintainer publishes a tag no-one expects to have to deal with
downstream conflicting definitions of the tag. Likewise, if the
maintainer were to publish the /man and /html metadata trees (per my
previous example) for a release tag, anyone who received
/refs/metadata/doc would expect to receive the metadata trees as
published by the maintainer. Anyone who didn't wouldn't have to pull
/refs/metadata/doc.
I can see there are use cases where multiple parties might want to
contribute metadata and I do not currently have a good solution to
that problem, but that is not to say there isn't one - surely it is
just a question of applying a little intellect creatively?
jon.
^ permalink raw reply
* Re: how to apply patch?
From: Matt Di Pasquale @ 2010-02-07 6:06 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d1002062040x6556b73fvb2a62a85fe21ec9e@mail.gmail.com>
Hi Ray,
Thanks for your response. I don't understand how that will transfer my
latest changes in ./dev into ./www while preserving the fundamental
differences between the 2 directories. Could you please provide some
explanation?
Also, is there an easy way to do something like this with a branch
instead of a remote? Remote doesn't make sense to me conceptually (and
I already have a remote repo setup that I push to from master). Maybe
I should have 2 different branches? One for dev & one for pro. How
would I do that?
Thanks,
-Matt
^ permalink raw reply
* Re: Using ‘git replace’ to replace blobs
From: Christian Couder @ 2010-02-07 6:45 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Nick Edelen, Sam Vilain
In-Reply-To: <20100207011056.GA15307@progeny.tock>
On dimanche 07 février 2010, Jonathan Nieder wrote:
> I think it is a known problem that ‘git replace’ cannot be used safely
> to replace blobs used in the currently checked out commit. The man
> page says:
>
> Comparing blobs or trees that have been replaced with
> those that replace them will not work properly.
>
> Indeed, in practice it produces problems. [1]
>
> I would like to start to fix this.
One way to fix it may be to use a bit in "struct object" that could tell if
any object was replaced or not. I think that in the "Add caching support to
git-daemon" GSoc patches, Nick Edelen did something like that for grafts.
(See http://thread.gmane.org/gmane.comp.version-control.git/127932/)
> But the correct semantics are not
> obvious to me:
>
> - When writing a tree from an index that includes replaced blobs,
> should the result use the original blobs or the replaced ones?
It may depend on why the original blob was replaced in the first place.
I did not think much about this though.
> - When reading a tree that includes replaced blobs, should the
> resulting cache entries use the original blobs or the replaced
> ones?
I think it should depend on whether the global variable read_replace_refs is
set or not.
> My hunch is to say both should use the replaced blobs. This way,
> replacing a blob in a checked-out index would behave in a more
> intuitive way, and git filter-branch would make permanent any
> substitutions requested through replaced blob entries.
It might not always be a good idea to make any substitution permanent.
For example if you use git replace to improve the bisectability of your
commit history you may want to keep the original commits.
I know you are talking about blobs, not commits, but perhaps there are some
similar use cases of replaced blobs.
Thanks for looking at that,
Christian.
^ permalink raw reply
* [PATCH] archive: fix segfault from too long --format parameter
From: Jonathan Nieder @ 2010-02-07 7:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rene Scharfe, Dmitry Potapov, git
‘git archive --format=<string of 25 characters or more>’ overflows a
local buffer, producing a segfault here.
The context: in commit 0f4b377 (git-archive: infer output format from
filename when unspecified, 2009-09-14), the cmd_archive wrapper
learned to produce a format argument for the local or remote archive
machinery in a local buffer, but that code was missing a bounds check.
So add the missing check. As a belt-and-suspenders measure, also use
snprintf to make sure the copy afterwards does not overflow.
Cc: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Cc: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
I noticed this while reading over the archive code. Thoughts?
builtin-archive.c | 4 +++-
t/t5000-tar-tree.sh | 6 ++++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/builtin-archive.c b/builtin-archive.c
index 3fb4136..94db00d 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -107,7 +107,9 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
}
if (format) {
- sprintf(fmt_opt, "--format=%s", format);
+ if (strlen(format) > sizeof(fmt_opt) - sizeof("--format="))
+ die("git archive: format is too long: %.50s", format);
+ snprintf(fmt_opt, sizeof(fmt_opt), "--format=%s", format);
/*
* We have enough room in argv[] to muck it in place,
* because either --format and/or --output must have
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 0037f63..cf114b2 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -174,6 +174,12 @@ test_expect_success \
'
test_expect_success \
+ 'git archive --format=<long nonsense string>' \
+ 'format=abacadabra &&
+ format="${format}${format}${format}zip" &&
+ test_must_fail git archive "--format=$format" HEAD'
+
+test_expect_success \
'git archive --format=zip' \
'git archive --format=zip HEAD >d.zip'
--
1.7.0.rc1
^ permalink raw reply related
* [PATCH] Add a test for a problem in "rebase --whitespace=fix"
From: Björn Gustavsson @ 2010-02-07 8:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The command "git rebase --whitespace=fix HEAD~<N>" is supposed to
only clean up trailing whitespace, and the expectation is that it
cannot fail.
Unfortunately, if one commit adds a blank line at the end of a file
and a subsequent commit adds more non-blank lines after the blank
line, "git apply" (used indirectly by "git rebase") will fail to apply
the patch of the second commit.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
t/t3417-rebase-whitespace-fix.sh | 45 ++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
create mode 100755 t/t3417-rebase-whitespace-fix.sh
diff --git a/t/t3417-rebase-whitespace-fix.sh b/t/t3417-rebase-whitespace-fix.sh
new file mode 100755
index 0000000..55cbce7
--- /dev/null
+++ b/t/t3417-rebase-whitespace-fix.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+test_description='git rebase --whitespace=fix
+
+This test runs git rebase --whitespace=fix and make sure that it works.
+'
+
+. ./test-lib.sh
+
+# prepare initial revision of "file" with a blank line at the end
+cat >file <<EOF
+a
+b
+c
+
+EOF
+
+# expected contents in "file" after rebase
+cat >expect <<EOF
+a
+b
+c
+EOF
+
+# prepare second revision of "file"
+cat >second <<EOF
+a
+b
+c
+
+d
+e
+f
+EOF
+
+test_expect_failure 'blanks line at end of file; extend at end of file' '
+ git commit --allow-empty -m "Initial empty commit" &&
+ git add file && git commit -m first &&
+ mv second file &&
+ git add file && git commit -m second &&
+ git rebase --whitespace=fix HEAD^^ &&
+ git diff --exit-code HEAD^:file expect
+'
+
+test_done
--
1.7.0.rc1.46.g04bf4
^ permalink raw reply related
* Re: A generalization of git notes from blobs to trees - git metadata?
From: Jakub Narebski @ 2010-02-07 9:15 UTC (permalink / raw)
To: Jon Seymour; +Cc: Jeff King, Junio C Hamano, Johan Herland, git
In-Reply-To: <2cfc40321002062136q64f832aesd979c9cb22f3612@mail.gmail.com>
Jon Seymour <jon.seymour@gmail.com> writes:
[cut]
> As I see it, the existing use of notes is a special instance of a more
> general metadata capability in which the metadata is constrained to be
> a single blob. If notes continued to be constrained in this way, there
> is no reason to change anything with respect to its current userspace
> behaviour. That said, most of the plumbing which enabled notes could
> be generalized to enable the arbitrary tree case [ which admittedly, I
> have yet to sell successfully !]
>
> In one sense, there is a sense in the merge issue doesn't exist. When
> the maintainer publishes a tag no-one expects to have to deal with
> downstream conflicting definitions of the tag. Likewise, if the
> maintainer were to publish the /man and /html metadata trees (per my
> previous example) for a release tag, anyone who received
> /refs/metadata/doc would expect to receive the metadata trees as
> published by the maintainer. Anyone who didn't wouldn't have to pull
> /refs/metadata/doc.
>
> I can see there are use cases where multiple parties might want to
> contribute metadata and I do not currently have a good solution to
> that problem, but that is not to say there isn't one - surely it is
> just a question of applying a little intellect creatively?
Are you trying to repeat fail of Apple's / MacOS / HFS+ filesystem
data/resource forks, and Microsoft's Alternate Data Streams in git? :-)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: Die if there are parsing errors in config file
From: Jakub Narebski @ 2010-02-07 9:40 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Otherwise the errors can propagate, and show in damnest places, and
you would spend your time chasing ghosts instead of debugging real
problem (yes, it is from personal experience).
This follows (parts of) advice in `perldoc -f do` documentation.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is fallout from my work on [split] "Gitweb output caching" series.
Before I used `die $@ if $@;' in t/t9503/test_cache_interface.pl, tests
failed for no discernable reason...
So I think the same should be done for the gitweb config file.
gitweb/gitweb.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1f6978a..a5bc359 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -556,6 +556,8 @@ if (-e $GITWEB_CONFIG) {
our $GITWEB_CONFIG_SYSTEM = $ENV{'GITWEB_CONFIG_SYSTEM'} || "++GITWEB_CONFIG_SYSTEM++";
do $GITWEB_CONFIG_SYSTEM if -e $GITWEB_CONFIG_SYSTEM;
}
+# die if there are errors parsing config file
+die $@ if $@;
# Get loadavg of system, to compare against $maxload.
# Currently it requires '/proc/loadavg' present to get loadavg;
^ permalink raw reply related
* Re: A generalization of git notes from blobs to trees - git metadata?
From: Jon Seymour @ 2010-02-07 9:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jeff King, Junio C Hamano, Johan Herland, git
In-Reply-To: <m363699zn4.fsf@localhost.localdomain>
On Sun, Feb 7, 2010 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
> [cut]
>
>> As I see it, the existing use of notes is a special instance of a more
>> general metadata capability in which the metadata is constrained to be
>> a single blob. If notes continued to be constrained in this way, there
>> is no reason to change anything with respect to its current userspace
>> behaviour. That said, most of the plumbing which enabled notes could
>> be generalized to enable the arbitrary tree case [ which admittedly, I
>> have yet to sell successfully !]
>>
>> In one sense, there is a sense in the merge issue doesn't exist. When
>> the maintainer publishes a tag no-one expects to have to deal with
>> downstream conflicting definitions of the tag. Likewise, if the
>> maintainer were to publish the /man and /html metadata trees (per my
>> previous example) for a release tag, anyone who received
>> /refs/metadata/doc would expect to receive the metadata trees as
>> published by the maintainer. Anyone who didn't wouldn't have to pull
>> /refs/metadata/doc.
>>
>> I can see there are use cases where multiple parties might want to
>> contribute metadata and I do not currently have a good solution to
>> that problem, but that is not to say there isn't one - surely it is
>> just a question of applying a little intellect creatively?
>
> Are you trying to repeat fail of Apple's / MacOS / HFS+ filesystem
> data/resource forks, and Microsoft's Alternate Data Streams in git? :-)
>
No I am not. I don't see why a metadata proposal is any more exposed
to subversive payloads than say, use of git merge -s ours [ a
subversive payload could be made reachable from a commit that
otherwise merges in favour of the legitimate source - who would know?
]
Really, I can't see why the rationale that makes a single blob used
for extending a commit message justified can't be used to justify
associating a metadata tree of arbitrary complexity to an arbitrary
sha1 object. What makes maintaining a mapping to a single blob
acceptable but maintaining a mapping to a tree unacceptable? Is there
really any fundamental difference?
jon.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox