* [PATCH 0/4] Another round of the --track patches
From: Federico Mena Quintero @ 2007-10-02 23:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3axbvbto.fsf@gitster.siamese.dyndns.org>
On Tue, 2007-09-18 at 15:38 -0700, Junio C Hamano wrote:
> Federico Mena Quintero <federico@novell.com> writes:
> > - retrieve data from the remote branch. Set the
> > + retrieve data from the remote branch, otherwise you'll have to
> > + use "git pull <url>" explicitly. Set the
> > branch.autosetupmerge configuration variable to true if you
> > want git-checkout and git-branch to always behave as if
> > '--track' were given.
>
> Hmph.
>
> I'd rather make them consistent by dropping the not-so-correct
> "otherwise" phrase from all three copies. It is not "otherwise
> you'll have to", but "instead you can".
Sure, I've added better wording now.
> I am inclined to suggest rewording the message like this, and
> make this condition an error (i.e. "exit 1"):
[snip]
I like that message much better, and it's nice that it gives you the
snippet to put in your config file. This is in patch 4/4.
Thanks for the review; I hope this can make it in now ;)
Federico
^ permalink raw reply
* Re: git-svn merge helper
From: Björn Steinbrink @ 2007-10-02 22:38 UTC (permalink / raw)
To: Steven Walter; +Cc: git
In-Reply-To: <20071002220458.GA21038@dervierte>
On 2007.10.02 18:04:58 -0400, Steven Walter wrote:
> On Tue, Oct 02, 2007 at 11:14:00PM +0200, Björn Steinbrink wrote:
> > 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?
>
> When I want to do something like this, I go about it one of two ways.
> The first option is to simply rebase mybranch onto master. Since my
> feature branches are not usually published, there is no problem
> rewinding them. That may not be an option for you, however.
Unfortunately not, the branch in question is required to be in the SVN
repository.
> The other option is to have a "build" branch. By example:
>
> git checkout build
> git reset --hard master
> git merge mybranch
> make
>
> In that way, I have branch with the latest changes from head and the
> changes from mybranch together. The downside to this method is that you
> may have to repeated resolve merges. Despite the downsides, I find
> these two methods to work quite well.
Thanks, but it makes no difference here, it stil results in a fast
forward. This is a small test case which exhibits the behaviour and
matches my current workflow with git-svn (except for the dcommits):
git init
echo Hi > file1; git add file1; git commit -m file1
git checkout -b branch
echo Hi > file2; git add file2; git commit -m file2
git checkout master
echo Hi > file3; git add file3; git commit -m file3
git checkout branch
git merge master
# Then I'd normally do the following which causes a fast forward
#git checkout master
#git merge branch
# Now I tried this, which also results in a fast-forward:
git checkout -b merge
git reset --hard master
git merge branch
Anything I'm missing?
Thanks,
Björn
^ permalink raw reply
* [PATCH] for-each-ref: fix %(numparent) and %(parent)
From: Junio C Hamano @ 2007-10-02 22:12 UTC (permalink / raw)
To: git; +Cc: Andy Parkins
In-Reply-To: <200710021202.42452.andyparkins@gmail.com>
The string value of %(numparent) was not returned correctly.
Also %(parent) misbehaved for the root commits (returned garbage)
and merge commits (returned first parent, followed by a space).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I noticed this while playing with Andy's patch to enhance the
date format string we saw recently on the list.
Andy does not have anything to do with the breakage; this
patch is against 'maint' to fix the bug that has always been
there from the very beginning of this code.
builtin-for-each-ref.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 0afa1c5..29f70aa 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -43,7 +43,7 @@ static struct {
{ "objectsize", FIELD_ULONG },
{ "objectname" },
{ "tree" },
- { "parent" }, /* NEEDSWORK: how to address 2nd and later parents? */
+ { "parent" },
{ "numparent", FIELD_ULONG },
{ "object" },
{ "type" },
@@ -262,24 +262,26 @@ static void grab_commit_values(struct atom_value *val, int deref, struct object
}
if (!strcmp(name, "numparent")) {
char *s = xmalloc(40);
+ v->ul = num_parents(commit);
sprintf(s, "%lu", v->ul);
v->s = s;
- v->ul = num_parents(commit);
}
else if (!strcmp(name, "parent")) {
int num = num_parents(commit);
int i;
struct commit_list *parents;
- char *s = xmalloc(42 * num);
+ char *s = xmalloc(41 * num + 1);
v->s = s;
for (i = 0, parents = commit->parents;
parents;
- parents = parents->next, i = i + 42) {
+ parents = parents->next, i = i + 41) {
struct commit *parent = parents->item;
strcpy(s+i, sha1_to_hex(parent->object.sha1));
if (parents->next)
s[i+40] = ' ';
}
+ if (!i)
+ *s = '\0';
}
}
}
--
1.5.3.3.1144.gf10f2
^ permalink raw reply related
* Re: merging .gitignore
From: Pierre Habouzit @ 2007-10-02 22:07 UTC (permalink / raw)
To: martin f krafft; +Cc: git, Andy Parkins, Johannes Schindelin
In-Reply-To: <20071002214919.GA21260@lapse.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
On Tue, Oct 02, 2007 at 09:49:19PM +0000, martin f krafft wrote:
> also sprach Pierre Habouzit <madcoder@debian.org> [2007.10.02.2207 +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.
>
> In left, ab* is still ignored, in right ac* is still ignored, and in
> the integration branch, they're all ignored. We don't merge up in
> this model...
err maybe you didn't get my little picture
(a*)
/ \
v v
(ab*) (ac*)
\ /
v v
????
This is a perfectly sensible history. Or I miss sth on your end.
--
·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: git-svn merge helper
From: Steven Walter @ 2007-10-02 22:04 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20071002211400.GA992@atjola.homenet>
On Tue, Oct 02, 2007 at 11:14:00PM +0200, Björn Steinbrink wrote:
> 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?
When I want to do something like this, I go about it one of two ways.
The first option is to simply rebase mybranch onto master. Since my
feature branches are not usually published, there is no problem
rewinding them. That may not be an option for you, however.
The other option is to have a "build" branch. By example:
git checkout build
git reset --hard master
git merge mybranch
make
In that way, I have branch with the latest changes from head and the
changes from mybranch together. The downside to this method is that you
may have to repeated resolve merges. Despite the downsides, I find
these two methods to work quite well.
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* Re: [PATCH] Support tags in uncommit - use git_id instead of rev_parse
From: Pavel Roskin @ 2007-10-02 22:03 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0710011500o1bd621a4q10dfe0468c8795e2@mail.gmail.com>
On Mon, 2007-10-01 at 23:00 +0100, Catalin Marinas wrote:
> On 30/09/2007, Pavel Roskin <proski@gnu.org> wrote:
> > Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> With this patch, uncommit can take patch names (with modifiers) as the
> --to argument. When would this be needed?
Probably never.
> To allow tags, maybe just pass something like
> "git.rev_parse(options.to + '^{commit}')" or just modify git.rev_parse
> to do it (and git_id to avoid it).
I prefer to work with software that understands what I mean and tells me
that I cannot do it. It makes it easier to understand what is possible
and how the command is working.
Recognizing patch names in some commands but not others would be
annoying and inconsistent. Dumbing downs interactive software on
purpose is probably not worth the trouble.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: merging .gitignore
From: martin f krafft @ 2007-10-02 21:49 UTC (permalink / raw)
To: Pierre Habouzit, git, Andy Parkins, Johannes Schindelin
In-Reply-To: <20071002210748.GC19710@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
also sprach Pierre Habouzit <madcoder@debian.org> [2007.10.02.2207 +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.
In left, ab* is still ignored, in right ac* is still ignored, and in
the integration branch, they're all ignored. We don't merge up in
this model...
--
.''`. 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
"if there's anything more important than my ego,
i want it caught and shot now."
-- zaphod beeblebrox
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: metastore
From: martin f krafft @ 2007-10-02 21:44 UTC (permalink / raw)
To: git
Cc: David Härdeman, David Kastrup, Daniel Barkalow,
Johannes Schindelin, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz
In-Reply-To: <20071002211518.GA10445@hardeman.nu>
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
also sprach David Härdeman <david@hardeman.nu> [2007.10.02.2215 +0100]:
> I think the opposite approach would be better. Let git provide
> set/get/delete attribute operations and leave it at that.
I like that idea.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"information superhighway"
is just an anagram for
"i'm on a huge wispy rhino fart".
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: 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
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