* Re: Track /etc directory using Git
From: Pierre Habouzit @ 2007-09-15 15:27 UTC (permalink / raw)
To: martin f krafft; +Cc: git, Nicolas Vilz, Thomas Harning Jr., Francis Moreau
In-Reply-To: <20070915152455.GA16223@piper.oerlikon.madduck.net>
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
On Sat, Sep 15, 2007 at 03:24:55PM +0000, martin f krafft wrote:
> also sprach Pierre Habouzit <madcoder@debian.org> [2007.09.15.1629 +0200]:
> > I fear that you'll end up with quite a big bloat of git, for a use
> > case that is fairly limited.
>
> I think it doesn't get bloated until you try to support the model of
> tracking different stuff for different files in the same repo. If
> you just track one set of data across all files in the repo, I don't
> think it'll cause too much bloat.
Yeah but if the stuff is opaque to git, you'll definitely end up with
security issues, which makes it also a no-go for /etc versionning.
Note that I don't specifically care about git being able to deal with
/etc, I was just pointing out some issues I can see with it, but I'm
neiter in favor nor against it.
--
·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: Track /etc directory using Git
From: martin f krafft @ 2007-09-15 15:42 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit, Nicolas Vilz, Thomas Harning Jr., Francis Moreau
In-Reply-To: <20070915152724.GC27494@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
also sprach Pierre Habouzit <madcoder@debian.org> [2007.09.15.1727 +0200]:
> > I think it doesn't get bloated until you try to support the model of
> > tracking different stuff for different files in the same repo. If
> > you just track one set of data across all files in the repo, I don't
> > think it'll cause too much bloat.
>
> Yeah but if the stuff is opaque to git, you'll definitely end up with
> security issues, which makes it also a no-go for /etc versionning.
With "opaque to git" do you mean "implemented outside git"?
I'd say if done properly inside git, the security issues could be
prevented.
--
.''`. 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
"this sentence contradicts itself -- no actually it doesn't."
-- douglas hofstadter
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-svn: remove --first-parent, add --upstream
From: Peter Baumann @ 2007-09-15 15:49 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Eric Wong, Junio C Hamano, git
In-Reply-To: <8c5c35580709150824l6eb4fa40l7ef77db03a48af4b@mail.gmail.com>
On Sat, Sep 15, 2007 at 05:24:02PM +0200, Lars Hjemli wrote:
> On 9/15/07, Peter Baumann <waste.manager@gmx.de> wrote:
> > On Sat, Sep 15, 2007 at 04:08:31PM +0200, Lars Hjemli wrote:
> > > On 9/7/07, Lars Hjemli <hjemli@gmail.com> wrote:
> > > > On 9/7/07, Peter Baumann <waste.manager@gmx.de> wrote:
> > > > > lets reset 'trunk' to its state before the merge and
> > > > > 'branch1' to the merge commit, before fixing the bug in 'branch1'.
> > > > >
> > > > > a-b-c-d-e trunk
> > > > > \ \
> > > > > \ -x-y m branch1
> > > >
> > > > Yeah, this would certainly not be handled correctly by dcommit using
> > > > --first-parent (but it could be handled by (a correct implementation
> > > > of) --upstream).
> > >
> > > Actually, I don't think there's any way to handle this correctly. The
> > > current git-svn will do the right thing except in cases like the one
> > > you described, and in these cases it can be _forced_ to do the right
> > > thing by editing the grafts file, so I'll drop the whole --upstream
> > > idea.
> > >
> >
> > What do you mean by editing the graft file? Remove (the wrong) parent
> > from the merge commit by a graft?
>
> I imagined just changing the order of the parents.
>
Doh. I missed the obvious.
-Peter
^ permalink raw reply
* Re: Track /etc directory using Git
From: martin f krafft @ 2007-09-15 16:32 UTC (permalink / raw)
To: git
In-Reply-To: <38b2ab8a0709140120k50f5b474oc8a841ea0a5fda50@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 513 bytes --]
also sprach Francis Moreau <francis.moro@gmail.com> [2007.09.14.1020 +0200]:
> The funny thing is that this tool is based on git/cogito but the
> scm used to manage it is darc.
They switched to git after running their heads too many times
against darcs walls.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
if god had meant for us to be naked,
we would have been born that way.
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: Mailing patch series'
From: Russ Brown @ 2007-09-15 16:44 UTC (permalink / raw)
To: git
In-Reply-To: <20070915023518.GX3099@spearce.org>
Shawn O. Pearce wrote:
> Russ Brown <pickscrape@gmail.com> wrote:
>> I've noticed the method of mailing series' of patches on this mailing
>> list, and I'd like to know a little more about how it's done, as I'm
>> considering how well it might work for us as a workflow and review process.
>>
>> Particularly, where does the series of patches come from?
>
> Usually from Git itself, as in each Git commit is turned into its
> own email message by `git format-patch` which can then be sent by
> `git send-email` or your favorite mail client.
>
<snip>
Shawn, thank you very much for your extremely detailed and helpful
explanation. It's given me plenty of food for thought!
Thanks again!
--
Russ
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: Grzegorz Kulewski @ 2007-09-15 16:22 UTC (permalink / raw)
To: martin f krafft
Cc: git, Johannes Schindelin, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz, David Härdeman
In-Reply-To: <20070915145437.GA12875@piper.oerlikon.madduck.net>
On Sat, 15 Sep 2007, martin f krafft wrote:
> also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.09.15.1610 +0200]:
>> No. Git is a source code management system. Everything else that
>> you can do with it is a bonus, a second class citizen. Should we
>> really try to support your use case, we will invariably affect the
>> primary use case.
>
> I thought git was primarily a content tracker... so it all comes
> down to how to define content, doesn't it? But either way, we need
> not discuss that because that definition depends a lot on context
> and purpose and thus cannot be answered once and for all.
>
> I understand that for the primary use case, tracking nothing more
> than +x makes sense and should not be interfered with. This is why
> I was proposing a policy-based approach. The primary use case is
> unaffected, it's the default policy. Someone may choose to track
> other mode bits or file/inode attributes, according to one of
> several policies available with git, or even a custom policy. In
> that case, the repository needs to be appropriately configured.
>
> The reason why I say this should be done inside git rather than with
> hooks and an external tool, such as metastore is quite simple: git
> knows about every content entity in any tree of a repo and already
> has a data node for each object. Rather than introducing a parallel
> object database (shadow hierarchy or single file), it would make
> a lot more sense and be way more robust to attach additional
> information to these object nodes, wouldn't it?
>
> So with "appropriately configured" above, I meant that one should be
> able to say
>
> git-config core.track all
>
> or
>
> git-config core.track mode+attr
>
> or the default:
>
> git-config core.track 7666
> (read that as a umask, which masks out everything but the three
> x bits. I made it 7666 instead of 7677 because core.umask and
> core.sharedrepository then override the group and world bits if
> needed)
>
> and have git do the right thing, rather than expecting those who
> want to track more than the executable bit to assemble a brittle set
> of hooks and metadata collectors+applicators and hope it all works.
>
> I understand also that this is not top priority for git, which is
> why I said earlier in the thread that the real difficulty might be
> to get Junio to accept a patch. But I think that the patch would be
> rather contained and small, having it all configurable would make it
> unintrusive, and if we all test it real well, it should pass as
> a bonus. After all, git can e.g upload patches to IMAP boxes, which
> in my world clearly is bonus material as well.
I also think such configuration option would be cool.
Not only for tracking /etc or /home but also for example for "web
applications" (for example in PHP). In that case file and directory
permissions can be as important as the source code tracked and it is pain
to chmod (and sometimes chown) all files to different values after each
checkout. Not speaking about potential race.
Thanks,
Grzegorz Kulewski
^ permalink raw reply
* Re: Track /etc directory using Git
From: David Kastrup @ 2007-09-15 16:57 UTC (permalink / raw)
To: martin f krafft; +Cc: git
In-Reply-To: <20070915163209.GA18508@piper.oerlikon.madduck.net>
martin f krafft <madduck@madduck.net> writes:
> also sprach Francis Moreau <francis.moro@gmail.com> [2007.09.14.1020 +0200]:
>> The funny thing is that this tool is based on git/cogito but the
>> scm used to manage it is darc.
>
> They switched to git after running their heads too many times
> against darcs walls.
Since they are not using git as a source code management system nor
darcs as a versioned file system, it is not particularly funny.
It's like being proud when the neighbor watchmaker borrows a hammer:
"ah, I always told him that a hammer is the ultimate device for
repairing a clock".
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC] strbuf's in builtin-apply
From: Pierre Habouzit @ 2007-09-15 17:07 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <20070915141210.GA27494@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]
On Sat, Sep 15, 2007 at 02:12:10PM +0000, Pierre Habouzit wrote:
> + nsize = buf->len;
> + nbuf = convert_to_git(path, buf->buf, &nsize);
> + if (nbuf)
> + strbuf_embed(buf, nbuf, nsize, nsize);
Okay, I managed to be able to be sure that convert_to_git always have
an extra ending NUL byte, with an intermediate patch. So now I call
strbuf_embed with nsize, nsize + 1 which has negligible cost.
Though this question remains:
> Another suspicious hunk is:
>
> - data = (void*) fragment->patch;
> [...]
> case BINARY_LITERAL_DEFLATED:
> - free(desc->buffer);
> - desc->buffer = data;
> - dst_size = fragment->size;
> - break;
> + strbuf_embed(buf, fragment->patch, fragment->size, fragment->size);
> + return 0;
>
> TTBOMK the ->patch pointer is a pointer inside a buffer, not a buffer
> that has been malloc'ed (and there are code paths before my patch that
> would still realloc the buffer so I don't think I introduce an issue).
> It passes the test-suite without crashing, but well, maybe this should
> be a copy instead.
>
> The rest is pretty straightforward.
>
> --
> ·O· Pierre Habouzit
> ··O madcoder@debian.org
> OOO http://www.madism.org
--
·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: Data Integrity & un-Commited Branches
From: Nikodemus Siivola @ 2007-09-15 17:14 UTC (permalink / raw)
To: David Kastrup; +Cc: Shawn O. Pearce, Jan Hudec, Brian Scott Dobrovodsky, git
In-Reply-To: <85myvoav1g.fsf@lola.goethe.zz>
On 9/15/07, David Kastrup <dak@gnu.org> wrote:
> "Take a while"? What's wrong with git-reflog?
Not needing it as a part of my regular workflow, and therefore
not thinking about it. *blush*
Cheers,
-- Nikodemus
^ permalink raw reply
* Re: STG, problem with pop/push of alternative versions of a patch
From: Catalin Marinas @ 2007-09-15 17:31 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910709150725k73bec66bw753c4b3c01244cff@mail.gmail.com>
On 15/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 9/15/07, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> > On 15/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > I trying to test two different versions of a patch that add files.
> > > These patches create a new directory and add several files. When I pop
> > > a version of the patch the directory and files and not getting
> > > removed. This causes an error when I push the alternative version of
> > > the patch.
> >
> > This shouldn't happen AFAICT (at least for the files, as GIT doesn't
> > care much about directories). What GIT/StGIT version are you using?
> > StGIT simply calls GIT to do the HEAD switch.
>
> I have played around with some more. It is more complicated than the
> simple case I described. Earlier I noticed a message about applying a
> patch that was empty that shouldn't have been. I checked and the patch
> is indeed empty. The empty patch probably caused the files to be left.
> I had been using hide/unide and reordering with on the patch and had
> encountered a couple errors in stg. I'll try and track down the
> sequence that caused the contents of the patch to be lost.
BTW, you can run 'stg log <patch>' to see how the patch was changed.
It even has a -g option to invoke gitk and see each change.
One way a patch could become empty is if the changes it makes are
already in the repository (in another patch or merged upstream).
--
Catalin
^ permalink raw reply
* Re: Data Integrity & un-Commited Branches
From: David Kastrup @ 2007-09-15 17:33 UTC (permalink / raw)
To: Nikodemus Siivola
Cc: Shawn O. Pearce, Jan Hudec, Brian Scott Dobrovodsky, git
In-Reply-To: <6bcc356f0709151014j9606a3ape6b62770304560ba@mail.gmail.com>
"Nikodemus Siivola" <nikodemus@random-state.net> writes:
> On 9/15/07, David Kastrup <dak@gnu.org> wrote:
>
>> "Take a while"? What's wrong with git-reflog?
>
> Not needing it as a part of my regular workflow, and therefore
> not thinking about it. *blush*
"Oh no, what have I done now?"
I am afraid that working with git still exposes me to this question
time and again. And git-reflog usually provides the answer, as well
as what I need to recover.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] revision walker: --cherry-pick is a limited operation
From: Johannes Schindelin @ 2007-09-15 17:39 UTC (permalink / raw)
To: mbaehr, gitster, git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1872 bytes --]
We used to rely on the fact that cherry-pick would trigger the code path
to set limited = 1 in handle_commit(), when an uninteresting commit was
encountered.
However, when cherry picking between two independent branches, i.e. when
there are no merge bases, and there is only linear development (which can
happen when you cvsimport a fork of a project), no uninteresting commit
will be encountered.
So set limited = 1 when --cherry-pick was asked for.
Noticed by Martin Bähr.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
revision.c | 1 +
t/t6007-rev-list-cherry-pick-file.sh | 14 ++++++++++++++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index c193c3e..33d092c 100644
--- a/revision.c
+++ b/revision.c
@@ -1024,6 +1024,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
}
if (!strcmp(arg, "--cherry-pick")) {
revs->cherry_pick = 1;
+ revs->limited = 1;
continue;
}
if (!strcmp(arg, "--objects")) {
diff --git a/t/t6007-rev-list-cherry-pick-file.sh b/t/t6007-rev-list-cherry-pick-file.sh
index 3faeae6..4b8611c 100755
--- a/t/t6007-rev-list-cherry-pick-file.sh
+++ b/t/t6007-rev-list-cherry-pick-file.sh
@@ -40,4 +40,18 @@ test_expect_success '--cherry-pick bar does not come up empty' '
! test -z "$(git rev-list --left-right --cherry-pick B...C -- bar)"
'
+test_expect_success '--cherry-pick with independent, but identical branches' '
+ git symbolic-ref HEAD refs/heads/independent &&
+ rm .git/index &&
+ echo Hallo > foo &&
+ git add foo &&
+ test_tick &&
+ git commit -m "independent" &&
+ echo Bello > foo &&
+ test_tick &&
+ git commit -m "independent, too" foo &&
+ test -z "$(git rev-list --left-right --cherry-pick \
+ HEAD...master -- foo)"
+'
+
test_done
--
1.5.3.1.949.g98c3
^ permalink raw reply related
* Re: STG, problem with pop/push of alternative versions of a patch
From: Jon Smirl @ 2007-09-15 17:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Git Mailing List
In-Reply-To: <b0943d9e0709151031m70b9d03bw4068805e697e97f5@mail.gmail.com>
On 9/15/07, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> On 15/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 9/15/07, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> > > On 15/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > I trying to test two different versions of a patch that add files.
> > > > These patches create a new directory and add several files. When I pop
> > > > a version of the patch the directory and files and not getting
> > > > removed. This causes an error when I push the alternative version of
> > > > the patch.
> > >
> > > This shouldn't happen AFAICT (at least for the files, as GIT doesn't
> > > care much about directories). What GIT/StGIT version are you using?
> > > StGIT simply calls GIT to do the HEAD switch.
> >
> > I have played around with some more. It is more complicated than the
> > simple case I described. Earlier I noticed a message about applying a
> > patch that was empty that shouldn't have been. I checked and the patch
> > is indeed empty. The empty patch probably caused the files to be left.
> > I had been using hide/unide and reordering with on the patch and had
> > encountered a couple errors in stg. I'll try and track down the
> > sequence that caused the contents of the patch to be lost.
>
> BTW, you can run 'stg log <patch>' to see how the patch was changed.
> It even has a -g option to invoke gitk and see each change.
>
> One way a patch could become empty is if the changes it makes are
> already in the repository (in another patch or merged upstream).
I was not happy when my patch disappeared. Luckily I had exported it a
little while earlier.
This error may have messed up my state and I didn't detect it until
later. 0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch
is the patch that went missing.
---------- Forwarded message ----------
From: Jon Smirl <jonsmirl@gmail.com>
Date: Sep 13, 2007 4:08 PM
Subject: Stg AssertionError in sink command
To: Git Mailing List <git@vger.kernel.org>, catalin.marinas@gmail.com
Using current git source for Stg
Patch 008 was hidden and I used unhide to bring it back. But the
hide/unhide process moved it to the top of the stack. I need to sink
it back down to where it came from. Shouldn't hide/unhide preserve the
patch position in the stack?
jonsmirl@terra:~/mpc5200b$ stg series
+ 0001-powerpc-exports-rheap-symbol-to-modules.patch
+ 0002-powerpc-Changes-the-config-mechanism-for-rheap.patch
+ 0003-powerpc-ppc32-Update-mpc52xx_psc-structure-with-B-r.patch
+ 0004-powerpc-BestComm-core-support-for-Freescale-MPC5200.patch
+ 0005-powerpc-BestcComm-ATA-task-support.patch
+ 0006-powerpc-BestcComm-FEC-task-support.patch
> 0007-powerpc-BestcComm-GenBD-task-support.patch
- domen-fec
- 0009-sound-Add-support-for-Freescale-MPC5200-AC97-interf.patch
- 0010-powerpc-In-rheap.c-move-the-EXPORT_SYMBOL-and-use.patch
- 0011-powerpc-BestComm-move-the-EXPORT_SYMBOL-and-use-th.patch
- 0012-powerpc-BestComm-ATA-task-move-the-EXPORT_SYMBOL-a.patch
- 0013-powerpc-BestComm-FEC-task-move-the-EXPORT_SYMBOL-a.patch
- 0014-powerpc-BestComm-GenBD-task-move-the-EXPORT_SYMBOL.patch
- 0015-powerpc-BestComm-Replace-global-variable-bcom-by-b.patch
- 0016-powerpc-Make-the-BestComm-driver-a-standard-of_plat.patch
- 0017-powerpc-Fix-typo-in-BestComm-ATA-task-support-code.patch
- 0018-powerpc-BestComm-ATA-task-microcode-insert-copyri.patch
- 0019-powerpc-BestComm-FEC-task-microcode-insert-copyri.patch
- 0020-powerpc-BestComm-GenBD-task-microcode-insert-copy.patch
- 0021-powerpc-Fix-errors-in-bcom-bcom_eng-renaming.patch
- Makefile
- pcm030_bsp_powerpc
- fs_jffs2_use_memcpy_fromio
- gpio_frame
- ppc_gpio
- GPIO-adaption
- mpc52xx_restart
- pcm_dts_eth_phys
- 0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch
jonsmirl@terra:~/mpc5200b$ stg sink -t domen-fec
0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch
Checking for changes in the working directory ... done
Traceback (most recent call last):
File "/usr/local/bin/stg", line 43, in <module>
main()
File "/usr/local/lib/python2.5/site-packages/stgit/main.py", line 284, in main
command.func(parser, options, args)
File "/usr/local/lib/python2.5/site-packages/stgit/commands/sink.py",
line 58, in func
crt_series.pop_patch(options.to or oldapplied[0])
File "/usr/local/lib/python2.5/site-packages/stgit/stack.py", line
1129, in pop_patch
assert(name in applied)
AssertionError
jonsmirl@terra:~/mpc5200b$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: Johannes Schindelin @ 2007-09-15 17:43 UTC (permalink / raw)
To: Grzegorz Kulewski
Cc: martin f krafft, git, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz, David Härdeman
In-Reply-To: <Pine.LNX.4.63.0709151819200.19941@alpha.polcom.net>
Hi,
On Sat, 15 Sep 2007, Grzegorz Kulewski wrote:
> On Sat, 15 Sep 2007, martin f krafft wrote:
> > I understand also that this is not top priority for git, which is why
> > I said earlier in the thread that the real difficulty might be to get
> > Junio to accept a patch. But I think that the patch would be rather
> > contained and small, having it all configurable would make it
> > unintrusive, and if we all test it real well, it should pass as a
> > bonus. After all, git can e.g upload patches to IMAP boxes, which in
> > my world clearly is bonus material as well.
>
> I also think such configuration option would be cool.
Why don't you just give it a try? Hack on git, make it work for what you
want to do, clean it up, make a nice patch series, post it here.
Then we'll talk.
Ciao,
Dscho
^ permalink raw reply
* Conflicting "-n" short options for git-pull?
From: Frans Pop @ 2007-09-15 19:14 UTC (permalink / raw)
To: git
Hello,
According to the man page for git-pull from git-core 1.5.3.1 (Debian
package), two options are defined as having the short option "-n":
-n, --no-summary
Do not show diffstat at the end of the merge.
[...]
-n, --no-tags
By default, git-fetch fetches tags that point at objects that are
downloaded from the remote repository and stores them locally. This
option disables this automatic tag following.
Cheers,
Frans Pop
^ permalink raw reply
* Re: metastore (was: Track /etc directory using Git)
From: Daniel Barkalow @ 2007-09-15 19:56 UTC (permalink / raw)
To: martin f krafft
Cc: git, Johannes Schindelin, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz, David Härdeman
In-Reply-To: <20070915145437.GA12875@piper.oerlikon.madduck.net>
On Sat, 15 Sep 2007, martin f krafft wrote:
> also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.09.15.1610 +0200]:
> > No. Git is a source code management system. Everything else that
> > you can do with it is a bonus, a second class citizen. Should we
> > really try to support your use case, we will invariably affect the
> > primary use case.
>
> I thought git was primarily a content tracker... so it all comes
> down to how to define content, doesn't it? But either way, we need
> not discuss that because that definition depends a lot on context
> and purpose and thus cannot be answered once and for all.
>
> I understand that for the primary use case, tracking nothing more
> than +x makes sense and should not be interfered with. This is why
> I was proposing a policy-based approach. The primary use case is
> unaffected, it's the default policy. Someone may choose to track
> other mode bits or file/inode attributes, according to one of
> several policies available with git, or even a custom policy. In
> that case, the repository needs to be appropriately configured.
Configuration options only apply to the local aspects of the repository.
That is, when you clone a repository, you don't get the configuration
options from it, in general. And changing configuration options on a
repository does not have any effect on the content it contains. So
configuration options aren't appropriate.
> The reason why I say this should be done inside git rather than with
> hooks and an external tool, such as metastore is quite simple: git
> knows about every content entity in any tree of a repo and already
> has a data node for each object. Rather than introducing a parallel
> object database (shadow hierarchy or single file), it would make
> a lot more sense and be way more robust to attach additional
> information to these object nodes, wouldn't it?
Git doesn't have any way to represent owners or groups, and they would
need to be represented carefully in order to make sense across multiple
computers. If you're adding support for metadata-as-content (for more than
"is this a script?"), you should be able to cover all of the common cases
of extended stuff, like AFS-style ACLs. And if you want to allow
meaningful development with this mechanism (as opposed to just archival of
a sequence of states of a live system), the normal case will be that the
metadata beyond +x is manipulated by ordinary users in some way other than
modifying their working directory. So the normal case here will be like
working on a filesystem that doesn't support symlinks or an executable bit
when this is important content.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] git-sh-setup.sh
From: Anupam Srivastava @ 2007-09-15 20:38 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 147 bytes --]
English is not my native language but I think this patch corrects a
grammar mistake.
I am not subscribed so please CC to me if replying.
Anupam
[-- Attachment #2: doc.patch --]
[-- Type: text/x-patch, Size: 459 bytes --]
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 185c5c6..3c325fd 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -6,7 +6,7 @@
# it dies.
# Having this variable in your environment would break scripts because
-# you would cause "cd" to be be taken to unexpected places. If you
+# you would cause "cd" to be taken to unexpected places. If you
# like CDPATH, define it for your interactive shell sessions without
# exporting it.
unset CDPATH
^ permalink raw reply related
* Re: metastore (was: Track /etc directory using Git)
From: Johannes Schindelin @ 2007-09-15 22:14 UTC (permalink / raw)
To: Daniel Barkalow
Cc: martin f krafft, git, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz, David Härdeman
In-Reply-To: <Pine.LNX.4.64.0709151430040.5298@iabervon.org>
Hi,
On Sat, 15 Sep 2007, Daniel Barkalow wrote:
> Git doesn't have any way to represent owners or groups, and they would
> need to be represented carefully in order to make sense across multiple
> computers.
[speaking mostly to the proponents of git-as-a-backup-tool]
While at it, you should invent a fallback what to do when the owner is not
present on the system you check out on. And a fallback when checking out
on a filesystem that does not support owners.
And a fallback when a non-root user uses it.
Oh, and while you're at it (you said that it would be nice not to restrict
git in any way: "it is a content tracker") support the Windows style
"Group-or-User-or-something:[FRW]" ACLs.
Looking forward to your patches,
Dscho
^ permalink raw reply
* Re: Stg AssertionError in sink command
From: Catalin Marinas @ 2007-09-15 22:37 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910709131308la9b3e44le70e1fac2b339189@mail.gmail.com>
On 13/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
> Patch 008 was hidden and I used unhide to bring it back. But the
> hide/unhide process moved it to the top of the stack. I need to sink
> it back down to where it came from. Shouldn't hide/unhide preserve the
> patch position in the stack?
I now got the time to read this thread in more detail.
The initial implementation of hide/unhide was to preserve the patch
position in the stack. This behaviour was really confusing for people
since pushing a patch after the hidden one actually forced the pushing
of the hidden patch, which isn't normally shown by 'series'. I decided
afterwards to create a third category of patches - 'hidden' (the other
two being applied and unapplied). This cleared the unpredictable
behaviour when pushing since hidden patches cannot be pushed.
Karl's patch does the correct thing of raising an error if sinking
below an unapplied patch.
I implemented the hidden patches feature just to hide some patches I
no longer need (various tests or early prototypes of some patches) but
I still want to keep them around in case I have to look again.
Regarding the reordering of the unapplied patches, at the moment you
can (but I *don't* recommend) edit .git/patches/<branch>/unapplied.
Maybe the 'float' and 'sink' functionality could be modified to also
act on unapplied patches (with a --unapplied option). I don't think a
separate command would be needed as it duplicates a lot of
functionality from the above.
--
Catalin
^ permalink raw reply
* Re: STG, problem with pop/push of alternative versions of a patch
From: Catalin Marinas @ 2007-09-15 22:44 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910709151042p7c681e25o386be2ca2719daa9@mail.gmail.com>
On 15/09/2007, Jon Smirl <jonsmirl@gmail.com> wrote:
> I was not happy when my patch disappeared. Luckily I had exported it a
> little while earlier.
Otherwise, the patch log should be present and it shows each commit id
of the patch.
Since we are at this, I think we need a config option to automatically
back up (export) the patches. Since StGIT detects whether the patch
applied cleanly or it was modified (with a diff3 merge), it only needs
to export in a few cases and not affect the performance (diff3 takes
significantly longer anyway).
Thanks for reporting this issue.
--
Catalin
^ permalink raw reply
* git-svn error when cloning apache repo
From: Jing Xue @ 2007-09-15 23:08 UTC (permalink / raw)
To: git
I'm trying to clone the Apache Ivy repo and got this error. What does
the "Using higher level of URL" mean? Also, of course, what does the
error message mean?
$ git svn clone https://svn.apache.org/repos/asf/incubator/ivy/core/ ivy-core -T trunk -b branches -t tags
Initialized empty Git repository in .git/
Using higher level of URL: https://svn.apache.org/repos/asf/incubator/ivy/core => https://svn.apache.org/repos/asf
W: Ignoring error from SVN, path probably does not exist: (175002): RA layer request failed: REPORT request failed on '/repos/asf/!svn/bc/100': REPORT of '/repos/asf/!svn/bc/100': Could not read chunk size: Secure connection truncated (https://svn.apache.org)
branch_from: /incubator/ivy/tags => /incubator/ivy/tags/1.4.1
Found possible branch point: https://svn.apache.org/repos/asf/incubator/ivy/tags/1.4.1 => https://svn.apache.org/repos/asf/incubator/ivy/core/tags/1.4.1, 499505
Initializing parent: tags/1.4.1@499505
Found possible branch point: https://svn.apache.org/repos/asf/incubator/ivy/trunk => https://svn.apache.org/repos/asf/incubator/ivy/tags/1.4.1, 488008
Initializing parent: tags/1.4.1@488008
RA layer request failed: REPORT request failed on '/repos/asf/!svn/vcc/default': REPORT of '/repos/asf/!svn/vcc/default': 400 Bad Request (https://svn.apache.org) at /home/jingxue/bin/git-svn line 3155
Any thoughts are appreciated.
Thanks.
--
Jing Xue
^ permalink raw reply
* Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch
From: Karl Hasselström @ 2007-09-15 23:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: Catalin Marinas, git
In-Reply-To: <9e4733910709140918wbe94b5eu6ec326b25b0f3d42@mail.gmail.com>
On 2007-09-14 12:18:17 -0400, Jon Smirl wrote:
> On 9/14/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > $ stg pop p2 p3
> > $ stg push p3 p2
> >
> > Does this cover what you had in mind?
>
> Sure this works. I'm just wondering if it is a good idea to have
> separate reordering commands for patches that are applied vs
> unapplied. The separate commands confused me.
>
> Would it be better to simply prohibit reordering of apply patches
> and require that they be popped before they can be reordered? A
> sink/float that causes merge errors must be a mess to sort out.
It's not a mess, actually -- it's implemented in terms of push and pop
of single patches, so the theory is dead simple. (The push and pop
commands are also implemented in terms of push and pop of single
patches.)
> If you prohibit reordering of applied patches sink/float can be
> eliminated.
But they're useful! Though as I said earlier, they're implemented in
terms of push and pop, so they're technically redundant. But "sink p5
--to p2" would be "pop p3..p5 && push p5 p3 p4", which is more typing
(starting with applied patches p1, p2, p3, p4, p5).
> Another way to handle this would be to eliminate the ability of
> pop/push to reorder and extend sink/float to handle unapplied
> patches.
I think that I'd like the latter without the former -- that is,
teaching sink/float how to handle unapplied patches, and leaving
push/pop as is. That'll let you do what you tried to do in the first
place, and will leave us with a more redundant command set, but I
don't think that's bad.
Another idea that's been kicked around is to have a general reorder
command, that spawns an editor and lets you move around (and delete)
patch names until you're satisfied. (This too would be implemented in
terms of push and pop of single patches.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: StGIT patch editing command
From: Karl Hasselström @ 2007-09-15 23:26 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <b0943d9e0709141057i7d03a2b6n408b820926cd95a5@mail.gmail.com>
On 2007-09-14 18:57:43 +0100, Catalin Marinas wrote:
> Since some people mentioned in the past that it would be nice to be
> able to edit patches, including the diff, I added the 'edit' command
> in today's snapshot (and StGIT repository).
Sounds great! I won't have time to test drive it for a few days,
though.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: metastore
From: Randal L. Schwartz @ 2007-09-15 23:33 UTC (permalink / raw)
To: Grzegorz Kulewski
Cc: martin f krafft, git, Johannes Schindelin, Thomas Harning Jr.,
Francis Moreau, Nicolas Vilz, David Härdeman
In-Reply-To: <Pine.LNX.4.63.0709151819200.19941@alpha.polcom.net>
>>>>> "Grzegorz" == Grzegorz Kulewski <kangur@polcom.net> writes:
Grzegorz> Not only for tracking /etc or /home but also for example for "web
Grzegorz> applications" (for example in PHP). In that case file and directory
Grzegorz> permissions can be as important as the source code tracked and it is pain to
Grzegorz> chmod (and sometimes chown) all files to different values after each
Grzegorz> checkout. Not speaking about potential race.
Uh, works just fine for me to manage my web site content. The point is
that I treat git for what it is... a source code management system.
And then I have a Makefile that "installs" my source code into the live
directory, with the right modes during installation.
Why does everyone keep wanting "work dir == live dir". Ugh! The work dir is
the *source*... it gets *copied* into your live dir *somehow*. And *that* is
where the meta information needs to be. In that "somehow".
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [StGit PATCH 13/13] Remove the 'top' field
From: Karl Hasselström @ 2007-09-15 23:36 UTC (permalink / raw)
To: David Kågedal; +Cc: git, catalin.marinas
In-Reply-To: <20070914223215.7001.80066.stgit@morpheus.local>
On 2007-09-15 00:32:15 +0200, David Kågedal wrote:
> @@ -436,7 +422,13 @@ class Series(PatchSet):
> patch = patch.strip()
> os.rename(os.path.join(branch_dir, patch),
> os.path.join(patch_dir, patch))
> - Patch(patch, patch_dir, refs_base).update_top_ref()
> + topfield = os.path.join(patch_dir, patch, 'top')
> + if os.path.isfile(topfield):
> + top = read_string(topfield, False)
> + else:
> + top = None
> + if top:
> + git.set_ref(refs_base + '/' + patch, top)
> set_format_version(1)
>
> # Update 1 -> 2.
And remove the top file, maybe? (Or I may be mistaken; I don't have a
copy of the surrounding code handy.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ 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