* Re: metastore
From: martin f krafft @ 2007-10-02 21:42 UTC (permalink / raw)
To: git
Cc: david, David Kastrup, David Härdeman, Daniel Barkalow,
Johannes Schindelin, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz
In-Reply-To: <Pine.LNX.4.64.0710021351400.24697@asgard.lang.hm>
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
also sprach david@lang.hm <david@lang.hm> [2007.10.02.2154 +0100]:
>> How could there be a conflict if you can't make local changes
>> because you can't represent the attributes locally/natively?
>
> you merge two uptream branches that disagree about the attributes
You win. :)
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"mein gott, selbst ein huhn kann debian installieren, wenn du genug
koerner auf die enter-taste legst."
-- thomas koehler in de.alt.sysadmin.recovery
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore
From: David Härdeman @ 2007-10-02 21:15 UTC (permalink / raw)
To: David Kastrup
Cc: martin f krafft, git, Daniel Barkalow, Johannes Schindelin,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz
In-Reply-To: <85lkalz3iv.fsf@lola.goethe.zz>
On Tue, Oct 02, 2007 at 10:04:56PM +0200, David Kastrup wrote:
>David Härdeman <david@hardeman.nu> writes:
>
>> On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
>>>also sprach David Härdeman <david@hardeman.nu> [2007.09.19.2016 +0100]:
>>>> But I agree, if any changes were made to git, I'd advocate adding
>>>> arbitrary attributes to files (much like xattrs) in name=value
>>>> pairs, then any extended metadata could be stored in those
>>>> attributes and external scripts/tools could use them in some way
>>>> that makes sense...and also make sure to only update them when it
>>>> makes sense.
>>>
>>>So where would those metdata be stored in your opinion?
>>
>> I'm not sufficiently versed in the internals of git to have an
>> informed opinion :)
>
>I think we have something like a length count for file names in index
>and/or tree. We could just put the (sorted) attributes after a NUL
>byte in the file name and include them in the count. It would also
>make those artificially longer file names work more or less when
>sorting them for deltification.
Or perhaps the index format could be extended to include a new field for
value=name pairs instead of overloading the name field.
But as I said, I have no idea how feasible it would be to change git to
support another arbitrary length field in the index/tree file.
>However, this requires implementing _policies_: it must be possible to
>specify per repository exactly what will and what won't get tracked,
>or one will get conflicts that are not necessary or appropriate.
I think the opposite approach would be better. Let git provide
set/get/delete attribute operations and leave it at that. Then external
programs can do what they want with that data and add/remove/modify tags
as necessary (and also include the smarts to not, e.g. remove the
permissions on all files if the git repo is checked out to a FAT fs).
--
David Härdeman
^ permalink raw reply
* Re: git-svn merge helper
From: Björn Steinbrink @ 2007-10-02 21:14 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Benoit SIGOURE, git
In-Reply-To: <8c5c35580710010113v7d4ad14bt129b7cb12d8f4fb8@mail.gmail.com>
On 2007.10.01 10:13:45 +0200, Lars Hjemli wrote:
> On 10/1/07, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
> > On Oct 1, 2007, at 4:50 AM, Björn Steinbrink wrote:
> > > Then how does that work? The manpage explicitly says that I should not
> > > use git-{pull,merge} on branches I want to dcommit from. And a trivial
> > > test immediately got the expected effect of git-svn trying to
> > > commit to
> > > trunk instead of the branch.
> >
> > Ah, yes, you're right. Well, this will work the day we can pass an
> > option to git-svn dcommit to tell it where the commit must be sent.
> >
>
> This is fixed in the latest version of git-svn (yet to be released).
> There is no need for an extra option, git-svn dcommit now handles
> merges between subversion branches correctly.
Thanks, but there's still a case that fails.
One common pattern in SVN is to have the feature branch following the
trunk. In git terms, that would mean that the feature branch is
continually rebased onto the HEAD of the HEAD AFAICT (although SVN of
course cannot represent that). The problem with that is, that git
doesn't create a merge commit in that case and git-svn gets confused
again.
git checkout mybranch
git merge master # Creates a merge commit
git checkout master
git merge mybranch # Does just fast forward
Is there anyway to force a merge commit or some other work around?
Thanks,
Björn
^ permalink raw reply
* Re: git clone questions relating to cpio
From: Reece Dunn @ 2007-10-02 21:09 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200710012342.37352.johan@herland.net>
On 01/10/2007, Johan Herland <johan@herland.net> wrote:
> On Monday 01 October 2007, Reece Dunn wrote:
> > Hi,
> >
> > I am running a Linux From Scratch 6.2 system that does not have cpio
> > installed on it. This means that I can't clone a local repository
> > unless I install cpio. Is it possible to use a fallback method if cpio
> > is not present, as there is no NO_CPIO option on make like there is
> > for OpenSSH, cURL and expat?
>
> Using "file://" when specifying the source repo will force git-clone to use
> the git protocol, instead of doing a copy/hardlink.
>
> I.e. change "git clone foo bar" to "git clone file://foo bar" in order to
> prevent git-clone from calling cpio.
Thanks for the tip.
> However, grepping for cpio in the git source tree reveals a couple of uses
> in git-merge, so you might bump into problems there...
Looks like I'll need to install cpio, then (also allowing me to take
advantage of the fast local clones via hardlinks).
Do you know if cpio is listed anywhere in required dependencies?
> > Also, I have an external USB hardrive that is mounted onto the virtual
> > filesystem. Will clones from the USB harddrive (or a USB flash drive
> > that is mounted) result in a copy being performed, not a hardlink?
>
> Hardlinks are impossible across filesystems. If you're cloning to a
> different filesystem git will _have_ to make a full copy.
Exactly. I was asking this to clarify cpio (and therefore git)
behaviour in this situation.
> > Ideally, the hard linking for local clones should be optional.
>
> <quote src="git-clone(1)">...</quote>
Indeed, they are. Thanks for the info.
> And as I said above, you can use "file://" to force the "git aware"
> transport mechanism, which bypasses the whole local copy/hardlink issue
> entirely.
Sure.
> > What if I want to move a repository because, for example, I have imported
> > a CVS repository and now want to push it to a new bare repository?
>
> Even if you were to use hardlinks, cloning a repo followed by deleting the
> original will be safe (as long as you don't supply '--shared' to
> git-clone). That's the beauty of hardlinks.
That is good to know.
> I also think it's fairly safe to just 'mv' the whole repository to its new
> location.
This also works, as long as you are not moving between a bare and
standard repository.
> Have fun! :)
Will do :)
Thanks,
- Reece
^ permalink raw reply
* Re: merging .gitignore
From: Pierre Habouzit @ 2007-10-02 21:07 UTC (permalink / raw)
To: martin f krafft; +Cc: git, Andy Parkins, Johannes Schindelin
In-Reply-To: <20071002205618.GA19097@lapse.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 858 bytes --]
On Tue, Oct 02, 2007 at 08:56:18PM +0000, martin f krafft wrote:
> also sprach Pierre Habouzit <madcoder@debian.org> [2007.10.02.2147 +0100]:
> > (a*)
> > / \
> > (ab*) (ac*)
> > \ /
> > ????
>
> (a*, ab*, ac*)
Definitely not. a* -> ab* is making a?* unignored for any value of ?
except b. So adding a* is definitely invalid.
So your final merge is definitely invalid. I'd say that it's likely
that the final merge is (ab*, ac*) but on the left branch the ab* could
have been chosen because the programmer added a thing named ac.c, so the
merge would still have (probably little but still some) chances to be invalid.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: Johannes Schindelin @ 2007-10-02 21:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, Carl Worth, Barry Fishman, git
In-Reply-To: <7vfy0tl4fd.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 2 Oct 2007, Junio C Hamano wrote:
> The discussion between Johannes and I was about picking what default is
> _reasonable_; Johannes made it sound like branches are norm and tags are
> oddball. I was merely pointing out that it won't be so cut-and-dried.
Actually, I had Carl Worth in mind when I asked the (rhetorical) question
what is meant by "master:blub". And I think Carl agrees that he would
expect it to create a new branch.
However, as I hope I made clear that I do not think that a DWIMery would
do good here. IOW I vote for keeping the existing behaviour (otherwise
you'd have seen a patch from me, too).
Ciao,
Dscho
^ permalink raw reply
* Re: merging .gitignore
From: Pierre Habouzit @ 2007-10-02 21:02 UTC (permalink / raw)
To: martin f krafft, git, Andy Parkins, Johannes Schindelin
In-Reply-To: <20071002204748.GA19710@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 2290 bytes --]
On Tue, Oct 02, 2007 at 08:47:48PM +0000, Pierre Habouzit wrote:
> On mar, oct 02, 2007 at 08:13:18 +0000, Pierre Habouzit wrote:
> > Ancestor: (aa*, aaa, bbb)
> > Left child: (aa*, bbb) <-- remove aaa because aa* covers it
> > Right child: (aaa, aabcd, bbb, cc*) <-- remove aa* and be explicit
> >
> > The proper result is probably: (aaa, aabcd, bbb, cc*) but is in fact a
> > case of conflict, because the "left" child could have used the fact that
> > aa* was present and hide say a aaXXX that the right child did not had,
> > and the merge would be wrong.
>
> Okay this example blows, I believe this one is better:
>
> (a*)
> / \
> (ab*) (ac*)
> \ /
> ????
>
> gitignore are subsets of the set of words. if S is the ancestor set,
> S1 and S2 the left and right sets. let Δ1 and Δ2 be S1 \ S and S2 \ S
I meant S \ S1 and S \ S2 in fact here ...
> respectively. I think there is a conflict if
> Δ1 n Δ2 != 0 and (Δ1 is not a subset of Δ2) and (Δ2 is not a subset of Δ1)
>
> If the condition holds, then I believe that the "merged" .gitignore
> would be: (S1 u S2) \ (Δ1 u Δ2)
after some more thoughts, as basically merging the complementary of
the sets I talk about here should yield the same "conflicts" (as it's
the dual problem), I suppose that the same restrictions should be
checked wrt the "added" deltas between S -> S1 (aka S1 \ S for real this
time) and S -> S2 (aka S2 \ S).
so if Δ(0,n) is Sn \ S and Δ(n, 0) is S \ Sn, it would mean that if:
{ Δ(0,1) n Δ(0,2) == 0 || ∃ i ∋ (1,2), Δ(0,i) ⊆ Δ(0, 3 - i) }
&& { Δ(1,0) n Δ(2,0) == 0 || ∃ i ∋ (1,2), Δ(i,0) ⊆ Δ(3 - i, 0) }
Then the correct merge (without conflicts) would be:
(S u Δ(1,0) u Δ(2,0)) \ (Δ(0,1) u Δ(0,2)) aka S + what was added -
what was removed.
in fact, I think that wrt the sets usual operations, there is a
conflict if the expression I just wrote does not commutes wrt the \ or
sth very similar.
Anyway, I'm going pretty off topic here, so I'll shut up now :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: Daniel Barkalow @ 2007-10-02 21:02 UTC (permalink / raw)
To: David Härdeman
Cc: martin f krafft, git, Johannes Schindelin, Thomas Harning Jr.,
Francis Moreau, Nicolas Vilz
In-Reply-To: <20071002195816.GA6759@hardeman.nu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1796 bytes --]
On Tue, 2 Oct 2007, David Härdeman wrote:
> On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
> >also sprach David Härdeman <david@hardeman.nu> [2007.09.19.2016 +0100]:
> > > But I agree, if any changes were made to git, I'd advocate adding
> > > arbitrary attributes to files (much like xattrs) in name=value
> > > pairs, then any extended metadata could be stored in those
> > > attributes and external scripts/tools could use them in some way
> > > that makes sense...and also make sure to only update them when it
> > > makes sense.
> >
> >So where would those metdata be stored in your opinion?
>
> I'm not sufficiently versed in the internals of git to have an informed
> opinion :)
My theory was that we would provide an API for getting the "current state"
listing with all of the filenames and matching contents, and leave it up
to metastore to put things in the filesystem; in the other direction,
metastore would build up this state, and we'd store it.
People who are using this in practice would set a config option to
delegate the "working tree" filesystem I/O to metastore, while other
people could interact with the state as files describing the state, and
could therefore specify operations that are impossible or prohibited on
the filesystems that their development is done on.
(This would effectively be like giving people a convenient way of setting
attributes on entries in a tar file, such that they can edit it to
represent a stste that they can't necessarily create in their own
filesystems, and version controlling that; but more convenient, since the
file contents are represented as file contents and the attributes are
plain text in a listing of some sort)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: Barry Fishman @ 2007-10-02 19:54 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0710021834470.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 2 Oct 2007, Barry Fishman wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > Well, if the OP had used "git push <bla> master" instead of "...
>> > master:master", it would have worked. I am unaware of any tutorial
>> > that suggests the latter, only of tutorials that suggest the former.
>>
>> I did recheck the tutorials, and did not find the code I was
>> using. So there was nothing incorrect in the documentation.
>
> Good. Just for my curiousity: where in the documentation did you look for
> help? (We might want to advertise "git push <nick> <branch>" more loudly
> there.)
I'm not sure, but I think I got the idea from:
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
which does a fetch while in the bare repository rather than a push into
it:
$ mkdir /pub/my-repo.git
$ cd /pub/my-repo.git
$ git --bare init --shared
$ git --bare fetch /home/alice/myproject master:master
That series of commands works.
>> If there isn't an initial master branch, then shouldn't "git branch" be
>> able to create one.
>
> Why? I really do not see the point in creating a branch which is named
> different than "master", when you have nothing to begin with.
You are right, of course. I was just following a line of thought, not
implying that creating such a branch was ever reasonable to do.
>> This command creates an empty git repository - basically a .git directory
>> with subdirectories for objects, refs/heads, refs/tags, and template
>> files. An initial HEAD file references the refs/heads/master branch
>> which is created with the first commit.
>
> How about "Your first commit will create the master branch" instead of the
> last sentence?
Yes. Less wobbly than how I worded it.
--
Barry Fishman
^ permalink raw reply
* Re: Problems setting up bare repository (git 1.5.3.3)
From: Johannes Schindelin @ 2007-10-02 20:59 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Carl Worth, Barry Fishman, git
In-Reply-To: <BAYC1-PASMTP05AB6AE16E90C15710819EAEAE0@CEZ.ICE>
Hi,
On Tue, 2 Oct 2007, Sean wrote:
> On Tue, 02 Oct 2007 11:23:39 -0700
> Junio C Hamano <gitster@pobox.com> wrote:
>
> > If your push were "next~27^2:frotz", it becomes even less clear. It
> > may be that I am pushing out the tip of a topic branch I usually do
> > not push out, so it would be easier for some specific person to build
> > on top of. Or maybe I am marking that place as a lightweight tag.
> > They are equally likely.
>
> But you could pick a reasonable default in assuming that a new branch is
> desired with the above example. If someone wants to push a tag, they
> can create the tag locally, and then push it.
And if someone wants to push a branch, they can create the branch locally,
and then push it. (Your last sentence with s/tag/branch/g applied.)
Ciao,
Dscho
^ permalink raw reply
* Re: merging .gitignore
From: martin f krafft @ 2007-10-02 20:56 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit, Andy Parkins, Johannes Schindelin
In-Reply-To: <20071002204748.GA19710@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
also sprach Pierre Habouzit <madcoder@debian.org> [2007.10.02.2147 +0100]:
> (a*)
> / \
> (ab*) (ac*)
> \ /
> ????
(a*, ab*, ac*)
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"once ... in the wilds of afghanistan, i lost my corkscrew, and we
were forced to live on nothing but food and water for days."
-- w. c. fields, "my little chickadee"
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore
From: david @ 2007-10-02 20:54 UTC (permalink / raw)
To: martin f krafft
Cc: David Kastrup, David Härdeman, git, Daniel Barkalow,
Johannes Schindelin, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz
In-Reply-To: <20071002203941.GA18008@lapse.madduck.net>
On Tue, 2 Oct 2007, martin f krafft wrote:
> also sprach david@lang.hm <david@lang.hm> [2007.10.02.2129 +0100]:
>> 1. you do want to be able to manipulate them
>>
>> 1a. how do you reconcile a conflict during a merge?
>
> How could there be a conflict if you can't make local changes
> because you can't represent the attributes locally/natively?
you merge two uptream branches that disagree about the attributes
>> 2. git is a series of snapshots, what does it mean to 'stay unchanged'?
>
> In simple terms, let (content,A,B) be an object with content
> "content" and extended attributes A,B, and B cannot be represented
> locally, but a new object is committed with a change to attribute
> A (content2,A2), then the result is (content2,A2,B), as B simply
> comes from the (corresponding object of the) parent.
>
> Or am I totally misunderstanding?
it's very possible that I am misunderstanding, but do we really want to
have to go back to the parent to duplicate things when creating a new
commit?
and aren't you supposed to be able to have more then one parent? if you
do, which one would you use?
David Lang
^ permalink raw reply
* Re: [PATCH] Change "refs/" references to symbolic constants
From: Jeff King @ 2007-10-02 20:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vsl4tjo28.fsf@gitster.siamese.dyndns.org>
On Tue, Oct 02, 2007 at 12:47:59PM -0700, Junio C Hamano wrote:
> - it makes typo harder to make and easier to spot
> (e.g. "refs/head/");
>
> - it makes miscount harder to make and easier to spot (e.g.
> what is this magic constant 11? Is it strlen("refs/heads/")?);
>
> - it makes reviewing the resulting code, and more importantly,
> future patches on the resulting code, easier.
> [...]
> It however actively hurts on the third count. These long
Yes, I find some of the substitutions more readable, but some are a bit
less readable. The parts of the patch I found the _most_ improved are
the ones that get rid of a memcmp in favor of a prefixcmp (i.e.,
removing the count entirely).
Perhaps a better quest would be to eliminate all of those counts
entirely with code that is obviously correct. I think it is much more
readable to replace:
url = xmalloc(strlen(repo->base) + 64);
sprintf(url, "%s/objects/pack/pack-%s.idx", repo->base, hex);
with something like:
strbuf_init(&url);
strbuf_addf(&url, "%s/objects/pack/pack-%s.idx", repo->base, hex);
which has the same number of lines, but no magic numbers at all. Or
since most of the uses of things like PATH_OBJECTS are more or less the
same, maybe something like:
mkpath_object(&url, "pack/pack-%s.idx", hex);
i.e., rather than fiddling with string constants, wrap them
functionally.
> constants in CAPITAL_LETTERS_WITH_UNDERSCORE shout too loudly to
Part of the problem is also that they're long. Perhaps REFS_HEADS, while
being less unique in the C namespace, would look better?
-Peff
^ permalink raw reply
* Re: merging .gitignore
From: Pierre Habouzit @ 2007-10-02 20:47 UTC (permalink / raw)
To: martin f krafft, git, Andy Parkins, Johannes Schindelin
In-Reply-To: <20071002201318.GD16776@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]
On mar, oct 02, 2007 at 08:13:18 +0000, Pierre Habouzit wrote:
> Ancestor: (aa*, aaa, bbb)
> Left child: (aa*, bbb) <-- remove aaa because aa* covers it
> Right child: (aaa, aabcd, bbb, cc*) <-- remove aa* and be explicit
>
> The proper result is probably: (aaa, aabcd, bbb, cc*) but is in fact a
> case of conflict, because the "left" child could have used the fact that
> aa* was present and hide say a aaXXX that the right child did not had,
> and the merge would be wrong.
Okay this example blows, I believe this one is better:
(a*)
/ \
(ab*) (ac*)
\ /
????
gitignore are subsets of the set of words. if S is the ancestor set,
S1 and S2 the left and right sets. let Δ1 and Δ2 be S1 \ S and S2 \ S
respectively. I think there is a conflict if
Δ1 n Δ2 != 0 and (Δ1 is not a subset of Δ2) and (Δ2 is not a subset of Δ1)
If the condition holds, then I believe that the "merged" .gitignore
would be: (S1 u S2) \ (Δ1 u Δ2)
Though, don't take my word for it, I've only sketched this on a small
piece of paper, and have no rigorous proof.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore
From: martin f krafft @ 2007-10-02 20:39 UTC (permalink / raw)
To: david, David Kastrup, David Härdeman, git, Daniel Barkalow
In-Reply-To: <Pine.LNX.4.64.0710021327371.24697@asgard.lang.hm>
[-- Attachment #1: Type: text/plain, Size: 963 bytes --]
also sprach david@lang.hm <david@lang.hm> [2007.10.02.2129 +0100]:
> 1. you do want to be able to manipulate them
>
> 1a. how do you reconcile a conflict during a merge?
How could there be a conflict if you can't make local changes
because you can't represent the attributes locally/natively?
> 2. git is a series of snapshots, what does it mean to 'stay unchanged'?
In simple terms, let (content,A,B) be an object with content
"content" and extended attributes A,B, and B cannot be represented
locally, but a new object is committed with a change to attribute
A (content2,A2), then the result is (content2,A2,B), as B simply
comes from the (corresponding object of the) parent.
Or am I totally misunderstanding?
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
when compared to windoze, unix is an operating system.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore
From: david @ 2007-10-02 20:29 UTC (permalink / raw)
To: martin f krafft
Cc: David Kastrup, David Härdeman, git, Daniel Barkalow,
Johannes Schindelin, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz
In-Reply-To: <20071002202333.GB16010@lapse.madduck.net>
On Tue, 2 Oct 2007, martin f krafft wrote:
> also sprach david@lang.hm <david@lang.hm> [2007.10.02.2118 +0100]:
>> the problem with this is dealing with the attributes outside of git
>> (especially when the filesystem can't store the attributes nativly,
>> specificly including things like owners when not running as root)
>
> In which case you should not be able to manipulate them (as you
> could not test the result) and any commits could not affect them,
> meaning they'd just stay unchanged.
two problems with this
1. you do want to be able to manipulate them
1a. how do you reconcile a conflict during a merge?
2. git is a series of snapshots, what does it mean to 'stay unchanged'?
David Lang
^ permalink raw reply
* Re: metastore
From: martin f krafft @ 2007-10-02 20:23 UTC (permalink / raw)
To: david, David Kastrup, David Härdeman, git, Daniel Barkalow
In-Reply-To: <Pine.LNX.4.64.0710021314370.24697@asgard.lang.hm>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
also sprach david@lang.hm <david@lang.hm> [2007.10.02.2118 +0100]:
> the problem with this is dealing with the attributes outside of git
> (especially when the filesystem can't store the attributes nativly,
> specificly including things like owners when not running as root)
In which case you should not be able to manipulate them (as you
could not test the result) and any commits could not affect them,
meaning they'd just stay unchanged.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
the unix philosophy basically involves
giving you enough rope to hang yourself.
and then some more, just to be sure.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: merging .gitignore
From: martin f krafft @ 2007-10-02 20:20 UTC (permalink / raw)
To: Junio C Hamano, git, Andy Parkins, Johannes Schindelin
In-Reply-To: <7vodfhjnpe.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
also sprach Junio C Hamano <gitster@pobox.com> [2007.10.02.2055 +0100]:
> Perhaps you can use the existing union merge there.
Many thanks for the pointer, I did not even have time to look at
gitattributes.txt yet...
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"self-denial is the shining sore
on the leprous body of christianity."
-- oscar wilde
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore
From: david @ 2007-10-02 20:18 UTC (permalink / raw)
To: David Kastrup
Cc: David Härdeman, martin f krafft, git, Daniel Barkalow,
Johannes Schindelin, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz
In-Reply-To: <85lkalz3iv.fsf@lola.goethe.zz>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1461 bytes --]
On Tue, 2 Oct 2007, David Kastrup wrote:
> David Härdeman <david@hardeman.nu> writes:
>
>> On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
>>> also sprach David Härdeman <david@hardeman.nu> [2007.09.19.2016 +0100]:
>>>> But I agree, if any changes were made to git, I'd advocate adding
>>>> arbitrary attributes to files (much like xattrs) in name=value
>>>> pairs, then any extended metadata could be stored in those
>>>> attributes and external scripts/tools could use them in some way
>>>> that makes sense...and also make sure to only update them when it
>>>> makes sense.
>>>
>>> So where would those metdata be stored in your opinion?
>>
>> I'm not sufficiently versed in the internals of git to have an
>> informed opinion :)
>
> I think we have something like a length count for file names in index
> and/or tree. We could just put the (sorted) attributes after a NUL
> byte in the file name and include them in the count. It would also
> make those artificially longer file names work more or less when
> sorting them for deltification.
the problem with this is dealing with the attributes outside of git
(especially when the filesystem can't store the attributes nativly,
specificly including things like owners when not running as root)
this is one of the reasons for talking about useing a seperate file for
the attributes (the other being the ability to minimize the impact to
git-core of tracking attributes)
David Lang
^ permalink raw reply
* [PATCH] Fix typo in config.txt
From: Johannes Schindelin @ 2007-10-02 20:14 UTC (permalink / raw)
To: gitster, git
There was an 'l' (ell) instead of a '1' (one) in one of the gitlinks.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/config.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 328487b..6b2fc82 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -599,7 +599,7 @@ merge.summary::
merge.tool::
Controls which merge resolution program is used by
- gitlink:git-mergetool[l]. Valid values are: "kdiff3", "tkdiff",
+ gitlink:git-mergetool[1]. Valid values are: "kdiff3", "tkdiff",
"meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and "opendiff".
merge.verbosity::
--
1.5.3.3.1147.g47f44
^ permalink raw reply related
* Re: merging .gitignore
From: Pierre Habouzit @ 2007-10-02 20:13 UTC (permalink / raw)
To: martin f krafft; +Cc: git, Andy Parkins, Johannes Schindelin
In-Reply-To: <20071002195148.GA14171@lapse.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]
On Tue, Oct 02, 2007 at 07:51:48PM +0000, martin f krafft wrote:
> Well, with gitignore I am ready to say that merges should be
> resolved in an additive way. Remember that I am talking about an
> intergration branch, and if feature branches A and B used to ignore
> .o files, and now B suddenly does not ignore them anymore, the only
> real reason I can think of is that it was rewritten in a languages
> other than C*. So then you *still* want to ignore .o files in the
> integration branch.
>
> Basically I am saying that it should be
>
> cat $gitignore_files | sort -u
Except that this would not work, just take that example (for the sake
of conciseness I put lines as members of a set):
Common ancestor content: (bar, foo, quux)
Left child: (bar, baz, foo, quux)
Right child: (bar, quux)
This one is a conflict, and if you apply your method, the merge always
"works" (as in has no cases where it fails) and would yield a result
like:
(bar, baz, foo, quux) whereas it's probably (bar, baz, quux) that
would be the proper one (aka left branch added a new ignore `baz` and
the right one removed it).
The proper way for gitignore is probably to work on the sets
operations, like diff does with lines, but without taking ordering into
account. What gets harder is when your lists are:
Ancestor: (aa*, aaa, bbb)
Left child: (aa*, bbb) <-- remove aaa because aa* covers it
Right child: (aaa, aabcd, bbb, cc*) <-- remove aa* and be explicit
The proper result is probably: (aaa, aabcd, bbb, cc*) but is in fact a
case of conflict, because the "left" child could have used the fact that
aa* was present and hide say a aaXXX that the right child did not had,
and the merge would be wrong.
Of course, .gitignore aren't _that_ important and if you ignore one
less file, or one too many, git will continue to behave properly, but
well, merge implementations aren't _that_ trivial.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore
From: David Kastrup @ 2007-10-02 20:04 UTC (permalink / raw)
To: David Härdeman
Cc: martin f krafft, git, Daniel Barkalow, Johannes Schindelin,
Thomas Harning Jr., Francis Moreau, Nicolas Vilz
In-Reply-To: <20071002195816.GA6759@hardeman.nu>
David Härdeman <david@hardeman.nu> writes:
> On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
>>also sprach David Härdeman <david@hardeman.nu> [2007.09.19.2016 +0100]:
>>> But I agree, if any changes were made to git, I'd advocate adding
>>> arbitrary attributes to files (much like xattrs) in name=value
>>> pairs, then any extended metadata could be stored in those
>>> attributes and external scripts/tools could use them in some way
>>> that makes sense...and also make sure to only update them when it
>>> makes sense.
>>
>>So where would those metdata be stored in your opinion?
>
> I'm not sufficiently versed in the internals of git to have an
> informed opinion :)
I think we have something like a length count for file names in index
and/or tree. We could just put the (sorted) attributes after a NUL
byte in the file name and include them in the count. It would also
make those artificially longer file names work more or less when
sorting them for deltification.
However, this requires implementing _policies_: it must be possible to
specify per repository exactly what will and what won't get tracked,
or one will get conflicts that are not necessary or appropriate.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: David Kastrup @ 2007-10-02 18:44 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071002173941.GA7187@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Oct 02, 2007 at 06:31:18PM +0200, David Kastrup wrote:
>
>> This does not actually require an actual merge _sort_ AFAICS: do the
>> "sort file.hashed" step using qsort. The comparison step does not
>> actually need to produce merged output, but merely advances through
>> two hash arrays and generates statistics.
>
> Right, that's why I used "merge" in quotes.
>
>> This should already beat the pants off the current implementation,
>> even when the hash array is sparse, simply because our inner loop
>> then has perfect hash coherence.
>
> Yes, I hope so. We'll see. :)
>
>> Getting rid of this outer O(n^2) remains an interesting challenge,
>> though. One way would be the following: fill a _single_ array with
>> entries containing _both_ hash and file number. Sort this, and
>> then gather the statistics of hash runs by making a single pass
>> through. That reduces the O(n^2) behavior to only those parts with
>> actual hash collisions.
>
> Interesting. Care to take a stab at implementing it?
I actually have worked through the last night on the day job, have
urgent stuff piling up in my freelance work queue, and the next thing
I need to finish for git is some smart stuff for delta packing.
So it's unlikely I'll get to _that_ anytime soon. However, I had a
hilarious idea on the way home that kept me rather amused (perhaps my
programmer's humour is affected by sleep deprivation).
I was annoyed at needing double the space because of having to keep
score of both hash and file number. So I came up with a rather cute
manner to avoid this: first do all files in isolation with full
precision, but store the resulting list of hash as difference to the
last value. When merging the data of 2^k and 2^k (or somewhat less)
files, we multiply the values by two (this will not carry except for
utterly improbable cases or very small data sets which we can do
differently) and add one bit of identification. When we have just a
single sequence remaining, undeltafying will tell us about collisions
in the high bits, and the affected files in the low bits.
Of course, using a merge-like algorithm means that we temporarily need
double space anyway. Which takes some of the fun.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: David Härdeman @ 2007-10-02 19:58 UTC (permalink / raw)
To: martin f krafft
Cc: git, Daniel Barkalow, Johannes Schindelin, Thomas Harning Jr.,
Francis Moreau, Nicolas Vilz
In-Reply-To: <20071002195301.GB14171@lapse.madduck.net>
On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
>also sprach David Härdeman <david@hardeman.nu> [2007.09.19.2016 +0100]:
>> But I agree, if any changes were made to git, I'd advocate adding
>> arbitrary attributes to files (much like xattrs) in name=value
>> pairs, then any extended metadata could be stored in those
>> attributes and external scripts/tools could use them in some way
>> that makes sense...and also make sure to only update them when it
>> makes sense.
>
>So where would those metdata be stored in your opinion?
I'm not sufficiently versed in the internals of git to have an informed
opinion :)
--
David Härdeman
^ permalink raw reply
* Re: merging .gitignore
From: Junio C Hamano @ 2007-10-02 19:55 UTC (permalink / raw)
To: martin f krafft; +Cc: git, Andy Parkins, Johannes Schindelin
In-Reply-To: <20071002195148.GA14171@lapse.madduck.net>
martin f krafft <madduck@madduck.net> writes:
> Basically I am saying that it should be
>
> cat $gitignore_files | sort -u
>
> and obviously, this is something for a specific merge driver, as
> Johannes suggested.
Perhaps you can use the existing union merge there.
^ 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