* Re: How it was at GitTogether'08 ?
From: Tim Ansell @ 2008-11-10 3:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Shawn O. Pearce, Jeff King, Petr Baudis, Steven Grimm
In-Reply-To: <200811091249.40735.jnareb@gmail.com>
> > Wed, Oct 29, 2008
> > -----------------
> + What was the difference between "Tim: Large media in Git (Repeat)"
> from Wed, and earlier "Tim: Git as a Media Repository" from Tue?
The first day I got people feed back on my proposal (whiteboard
discussion) and then presented the proposal on Wednesday.
You can find the slides of the presentation at
http://www.thousandparsec.net/~tim/media+git.pdf
Sorry about the duplicate messages, I hit send too soon.
Tim 'mithro' Ansell
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: dhruva @ 2008-11-10 3:43 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: sverre, git
In-Reply-To: <87hc6gjs7v.fsf@erwin.mina86.com>
Hi,
On Mon, Nov 10, 2008 at 6:46 AM, Michal Nazarewicz <mina86@tlen.pl> wrote:
> "Sverre Rabbelier" <alturin@gmail.com> writes:
>
>> On Mon, Nov 10, 2008 at 01:22, Michal Nazarewicz <mina86@tlen.pl> wrote:
>>> Now, what I need is such feature in GIT. Upon committing I would like
>>> some magic string (say "$Date$") to be replaced with some value
>>> identifying uniquely given version of a file (a date of the commit would
>>> be sufficient).
>>
>> Please have a look at the relevant entry in the faq [0].
>>
>> [0] http://git.or.cz/gitwiki/GitFaq#head-4a0afe71a2bb7734777a8b0b345e0308aefdbd40
>
> Thanks for the quick reply (and yes, I can't believe I couldn't find
> that myself...) but it still lacks one thing that I'd like to have.
> I would like the "$Id$" sequences to be updated automatically after
> a commit (ie. without the need to check out). (Besides I would prefer
> $Date$ more but I can live with $Id$ I guess ;) ).
I have worked on this topic quite a bit to fix issues in git-p4. There
is no direct way to get this $Id$ expansion in git, however you can
use a simple pre-commit hook (alpha state, more a proof of concept
that happens to work for me)
#!/usr/bin/env bash
for file in `git diff-index --name-only --diff-filter=AM HEAD` ; do
perl -pi -e 's/(\$[ \t]*Id)(.*)([ \t]*\$)/"\$Id: git
".time()." \$"/e' ${file}
git add ${file} > /dev/null
done
-dhruva
--
Contents reflect my personal views only!
^ permalink raw reply
* Re: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
From: Han-Wen Nienhuys @ 2008-11-10 3:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vr65kagvm.fsf@gitster.siamese.dyndns.org>
Hi Junio,
I haven't been involved with git-p4 for a long time. I'm not really fit
for judging these patches.
Junio C Hamano escreveu:
> These are patches to fast-import/git-p4, which you two seem to in charge
> of.
>
> From: John Chapman <thestar@fussycoder.id.au>
> Subject: [PATCH 1/2] Added support for purged files and also optimised memory usage.
> Date: Sat, 8 Nov 2008 14:22:48 +1100
> Message-Id: <1226114569-8506-1-git-send-email-thestar@fussycoder.id.au>
>
> From: John Chapman <thestar@fussycoder.id.au>
> Subject: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
> Date: Sat, 8 Nov 2008 14:22:49 +1100
> Message-Id: <1226114569-8506-2-git-send-email-thestar@fussycoder.id.au>
>
> It was unfortunately not immediately obvious from the Subject: line what
> these patches are about, and I am guessing you missed them because of that.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Junio C Hamano @ 2008-11-10 5:18 UTC (permalink / raw)
To: Ian Hilt; +Cc: Francis Galiegue, Git Mailing List, Pierre Habouzit
In-Reply-To: <alpine.LFD.2.00.0811091910570.21142@sys-0.hiltweb.site>
Ian Hilt <ian.hilt@gmx.com> writes:
> On Sun, 9 Nov 2008, Junio C Hamano wrote:
>> Ian Hilt <ian.hilt@gmx.com> writes:
>>
>> > On Sun, 9 Nov 2008, Francis Galiegue wrote:
>> >> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
>> >> > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
>> >>
>> >> Greedy operators are only supported with perl 5.10 or more... I think it's a
>> >> bad idea to use them...
>> ...
>> You expect something non-blank there anyway, so why not do:
>>
>> To:\s*(\S.*?)\s*\n....
>
> That works. Although, I seem to be missing Francis' point. According
> to perlre, a quantified subpattern is "greedy". So a "greedy operator"
> is any one of the standard quantified subpatterns. The "+" and "?"
> modify its matching behavior. And it seems to me that it _has_ to use a
> q.s. to work ...
The "perlre" documentation you are reading is from Perl 5.10.0; check
"perldelta" documentation next to it.
I think you are wrong in saying that "it _has_ to use". Yes, you _can_
use possessive quantifiers to write that pattern (provided if you can
limit your users to Perl 5.10.0 or later), but you do _not_ have to (and I
just showed you how). By not using the new feature, you can make it work
for people with older version of Perl.
Not everybody who uses git can upgrade their Perl to newer versions. We
try to stick to "5.6.1 or later"; anything that is not available in 5.8
series is too new to be used outside the contrib/ area.
That's the point Francis raised that you missed.
^ permalink raw reply
* recognize loose local objects during repack
From: drafnel @ 2008-11-10 5:59 UTC (permalink / raw)
To: gitster; +Cc: git, spearce, nico, ae
In-Reply-To: <7v8wrwidi3.fsf@gitster.siamese.dyndns.org>
This was developed on top of the previous repack/pack-objects series.
Junio wrote:
> Presumably you meant "exclude objects accessible through alternates,
> either in packs or in loose form"? If so then I think it is a good thing
> to have.
This patch set looks like what is necessary to exclude loose objects accessible
through alternates from packing.
> I think the useful kinds are only these five:
>
> - scoop loose objects that exist in local repository into a new pack,
> without touching existing packs at all; exclude anything available in
> any existing pack or in alternate repository (either loose or packed);
repack -l
> - pack everything that is needed by the local ref, except the ones that
> are borrowed from alternate repositories (either loose or packed), into
> a single new pack. There are two variants of this: eject what is
> currently packed but unnecessary into loose format when existing local
> packs are replaced with the new pack, or lose them (i.e. -A).
repack -a -l
repack -A -l
> - fatten local repository by packing everything that is needed by the
> local ref into a single new pack, including things that are currently
> borrowed from alternates. There are two variants of this: eject what
> is currently packed but unnecessary into loose format when existing
> local packs are replaced with the new pack, or lose them (i.e. -A).
repack -a
repack -A
-brandon
^ permalink raw reply
* [PATCH 1/3] t7700: demonstrate mishandling of loose objects in an alternate ODB
From: drafnel @ 2008-11-10 5:59 UTC (permalink / raw)
To: gitster; +Cc: git, spearce, nico, ae, Brandon Casey
In-Reply-To: <1226296798-31522-1-git-send-email-foo@foo.com>
From: Brandon Casey <drafnel@gmail.com>
Loose objects residing in an alternate object database should not be packed
when the -l option to repack is used.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
t/t7700-repack.sh | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 356afe3..43c9cf9 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -34,5 +34,24 @@ test_expect_success 'objects in packs marked .keep are not repacked' '
test -z "$found_duplicate_object"
'
+test_expect_failure 'loose objects in alternate ODB are not repacked' '
+ mkdir alt_objects &&
+ echo `pwd`/alt_objects > .git/objects/info/alternates &&
+ echo content3 > file3 &&
+ objsha1=$(GIT_OBJECT_DIRECTORY=alt_objects git hash-object -w file3) &&
+ git add file3 &&
+ git commit -m commit_file3 &&
+ git repack -a -d -l &&
+ git prune-packed &&
+ for p in .git/objects/pack/*.idx; do
+ if git verify-pack -v $p | egrep "^$objsha1"; then
+ found_duplicate_object=1
+ echo "DUPLICATE OBJECT FOUND"
+ break
+ fi
+ done &&
+ test -z "$found_duplicate_object"
+'
+
test_done
--
1.6.0.2.588.g3102
^ permalink raw reply related
* [PATCH 3/3] pack-objects: extend --local to mean ignore non-local loose objects too
From: drafnel @ 2008-11-10 5:59 UTC (permalink / raw)
To: gitster; +Cc: git, spearce, nico, ae, Brandon Casey
In-Reply-To: <1226296798-31522-3-git-send-email-foo@foo.com>
From: Brandon Casey <drafnel@gmail.com>
With this patch, --local means pack only local objects that are not already
packed.
Additionally, this fixes t7700 testing whether loose objects in an alternate
object database are repacked.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
Documentation/git-pack-objects.txt | 2 +-
builtin-pack-objects.c | 3 +++
t/t7700-repack.sh | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index f9fac2c..7d4c1a7 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -121,7 +121,7 @@ base-name::
--local::
This flag is similar to `--incremental`; instead of
ignoring all packed objects, it only ignores objects
- that are packed and not in the local object store
+ that are packed and/or not in the local object store
(i.e. borrowed from an alternate).
--non-empty::
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index ddec341..69f351a 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -691,6 +691,9 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
return 0;
}
+ if (!exclude && local && has_loose_object_nonlocal(sha1))
+ return 0;
+
for (p = packed_git; p; p = p->next) {
off_t offset = find_pack_entry_one(sha1, p);
if (offset) {
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 43c9cf9..960bff4 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -34,7 +34,7 @@ test_expect_success 'objects in packs marked .keep are not repacked' '
test -z "$found_duplicate_object"
'
-test_expect_failure 'loose objects in alternate ODB are not repacked' '
+test_expect_success 'loose objects in alternate ODB are not repacked' '
mkdir alt_objects &&
echo `pwd`/alt_objects > .git/objects/info/alternates &&
echo content3 > file3 &&
--
1.6.0.2.588.g3102
^ permalink raw reply related
* [PATCH 2/3] sha1_file.c: split has_loose_object() into local and non-local counterparts
From: drafnel @ 2008-11-10 5:59 UTC (permalink / raw)
To: gitster; +Cc: git, spearce, nico, ae, Brandon Casey
In-Reply-To: <1226296798-31522-2-git-send-email-foo@foo.com>
From: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
cache.h | 1 +
sha1_file.c | 19 +++++++++++++------
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/cache.h b/cache.h
index 37ab457..1ec90f1 100644
--- a/cache.h
+++ b/cache.h
@@ -578,6 +578,7 @@ extern int move_temp_to_file(const char *tmpfile, const char *filename);
extern int has_sha1_pack(const unsigned char *sha1, const char **ignore);
extern int has_sha1_file(const unsigned char *sha1);
+extern int has_loose_object_nonlocal(const unsigned char *sha1);
extern int has_pack_file(const unsigned char *sha1);
extern int has_pack_index(const unsigned char *sha1);
diff --git a/sha1_file.c b/sha1_file.c
index f2b25bd..4912205 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -423,23 +423,30 @@ void prepare_alt_odb(void)
read_info_alternates(get_object_directory(), 0);
}
-static int has_loose_object(const unsigned char *sha1)
+static int has_loose_object_local(const unsigned char *sha1)
{
char *name = sha1_file_name(sha1);
- struct alternate_object_database *alt;
+ return !access(name, F_OK);
+}
- if (!access(name, F_OK))
- return 1;
+int has_loose_object_nonlocal(const unsigned char *sha1)
+{
+ struct alternate_object_database *alt;
prepare_alt_odb();
for (alt = alt_odb_list; alt; alt = alt->next) {
- name = alt->name;
- fill_sha1_path(name, sha1);
+ fill_sha1_path(alt->name, sha1);
if (!access(alt->base, F_OK))
return 1;
}
return 0;
}
+static int has_loose_object(const unsigned char *sha1)
+{
+ return has_loose_object_local(sha1) ||
+ has_loose_object_nonlocal(sha1);
+}
+
static unsigned int pack_used_ctr;
static unsigned int pack_mmap_calls;
static unsigned int peak_pack_open_windows;
--
1.6.0.2.588.g3102
^ permalink raw reply related
* Re: Something like $Id$, $Revision$ or $Date$?
From: Johannes Sixt @ 2008-11-10 7:26 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: sverre, git
In-Reply-To: <87hc6gjs7v.fsf@erwin.mina86.com>
Michal Nazarewicz schrieb:
> (Besides I would prefer
> $Date$ more but I can live with $Id$ I guess ;) ).
Just FYI: The $Id$ that git produces is completely different from what CVS
produces and probably not what you expect: 'man gitattributes'
-- Hannes
^ permalink raw reply
* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Piotr Findeisen @ 2008-11-10 7:38 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30811091052k77200785j722c8aed2beb7684@mail.gmail.com>
Hi!
>>> The attached file is a result of running `git diff HEAD~1`.
>
> Please read Documentation/SubmittingPatches for the preferred way to
> contribute patches.
Ok, I'll look there, when you tell me this patch is worth anything.
>>> Asciidoc replaces "--" with "—" when not in verbatim mode. This is
>>> sometimes unwanted -- especially when citing command line options like
>>> "git diff --cached". This commit includes proper quotes in user-manual.txt.
>
> Newer asciidoc versions have the following "workaround". Maybe adding
> something like this to Documentation/asciidoc.conf would be more
> future proof.
>
> # -- Spaced and unspaced em dashes (entity reference —)
> # But disallow unspaced in man pages because double-dash option name prefixes
> # are pervasive.
> ifndef::doctype-manpage[]
> (^|[^-\\])--($|[^-])=\1—\2
> endif::doctype-manpage[]
> ifdef::doctype-manpage[]
> (^|\s*[^\S\\])--($|\s+)=\1—\2
> endif::doctype-manpage[]
> \\--(?!-)=--
Well, this doesn't solve the problem -- I'm not talking about
manpages, the "--" where replaced with single "—" on the
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html page.
Yes, we can disable such a replacement in the config file, but take a
look at the sentence "...how to fetch and study a project using
git—read these chapters...". In this case "--" in the source file was
replaced with "—" and this is what we want.
I noticed that all substitutions "--" -> "—", where "—" is a part of
sentence punctuation, match \w--\w pattern (e.g. no spaces on both
sides) and probably this is how it should be written in English. But
basing on this doesn't seem to me to be fool proof.
Best regards,
Piotr
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Francis Galiegue @ 2008-11-10 7:49 UTC (permalink / raw)
To: Ian Hilt; +Cc: Junio C Hamano, Git Mailing List, Pierre Habouzit
In-Reply-To: <alpine.LFD.2.00.0811091910570.21142@sys-0.hiltweb.site>
Le Monday 10 November 2008 01:38:30 Ian Hilt, vous avez écrit :
> On Sun, 9 Nov 2008, Junio C Hamano wrote:
> > Ian Hilt <ian.hilt@gmx.com> writes:
> > > On Sun, 9 Nov 2008, Francis Galiegue wrote:
> > >> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
> > >> > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
> > >>
> > >> Greedy operators are only supported with perl 5.10 or more... I think
> > >> it's a bad idea to use them...
> > >
> > > The problem here was that a space should follow the field, but it may
> > > not. The user may unwarily backup over it. "\s*" would match this
> > > case.
> > >
> > > But if there is a space, it is included in the "(.+)". So I tried
> > > "\s+", which did not include the space, but it won't include the first
> > > address if there isn't a space after the field.
> > >
> > > The quantified subpattern seemed to do the trick. But, if it could
> > > result in a dependency issue, I would agree this would be a bad idea.
> >
> > You expect something non-blank there anyway, so why not do:
> >
> > To:\s*(\S.*?)\s*\n....
>
> That works. Although, I seem to be missing Francis' point.
No. The _lazy_ quantifiers (*?, ??, *?, +?, {...}?) are supported all right.
But they should be avoided in general.
> According
> to perlre, a quantified subpattern is "greedy". So a "greedy operator"
> is any one of the standard quantified subpatterns. The "+" and "?"
> modify its matching behavior. And it seems to me that it _has_ to use a
> q.s. to work ...
My wording may be bad, then. They're not greedy, they just don't allow for
backtracking. They are more than greedy. Let me explain.
Consider "number 42" for instance. If you match it against:
* .*(\d+) => $1 would be "2": the * eats everything but _has_ to backtrack for
\d+ to get anything, but just one number is enough;
* .*?(\d+) => $1 would be "42": as *? is lazy, this means that after each
match, it looks to see whether the next element in the regex would match
anything; as soon as \d+ matches 4, .*? stops there;
* .*+(\d+) => $1 would match nothing! *+ eats everything, but the + afterwards
_doesn't allow it to backtrack_.
I hope this makes things a little clearer ;) I think the correct term for *+,
++, ?+ etc is "possessive" quantifiers, I'm just not sure.
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Francis Galiegue @ 2008-11-10 7:57 UTC (permalink / raw)
To: Ian Hilt; +Cc: Git Mailing List, Pierre Habouzit, Junio C Hamano
In-Reply-To: <1226235588-2997-1-git-send-email-ian.hilt@gmx.com>
Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
[...]
> + my @recipients = split(/\s*,\s*/, $match);
This is where it gets complicated, for the "hey, I am" <some@one> case...
But then there is a solution: use a negative lookahead for the split regex.
I thought about splitting against /\s*,\s*(?![^"]+(?:\"[^*]*)*)"/.
A negative lookbehind would have been clearer to write, but perl doesn't
support arbitrary length negative lookbehinds, except by using a very, very
arcane construct.
--
fge
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Francis Galiegue @ 2008-11-10 7:59 UTC (permalink / raw)
To: Ian Hilt; +Cc: Git Mailing List, Pierre Habouzit, Junio C Hamano
In-Reply-To: <200811100857.10802.fg@one2team.net>
Le Monday 10 November 2008 08:57:10 Francis Galiegue, vous avez écrit :
> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
> [...]
>
> > + my @recipients = split(/\s*,\s*/, $match);
>
> This is where it gets complicated, for the "hey, I am" <some@one> case...
>
> But then there is a solution: use a negative lookahead for the split regex.
>
> I thought about splitting against /\s*,\s*(?![^"]+(?:\"[^*]*)*)"/.
>
Oops, that should have been /\s*,\s*(?![^"]+(?:\"[^*]*)*")/, sorry :/
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Aristotle Pagaltzis @ 2008-11-10 8:08 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <200811100849.36736.fg@one2team.com>
* Francis Galiegue <fg@one2team.com> [2008-11-10 08:55]:
> Le Monday 10 November 2008 01:38:30 Ian Hilt, vous avez écrit :
> > On Sun, 9 Nov 2008, Junio C Hamano wrote:
> > > Ian Hilt <ian.hilt@gmx.com> writes:
> > > > On Sun, 9 Nov 2008, Francis Galiegue wrote:
> > > >> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
> > > >> > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
> > > >>
> > > >> Greedy operators are only supported with perl 5.10 or more... I think
> > > >> it's a bad idea to use them...
Possessive quantification is supported in much earlier versions
of Perl, it’s just more awkward syntactically:
/^To:(?>\s*)(.+)\s*\nCc:/ism
But possessification is not going to make a difference in this
regex, since .+ can match anything that \s* can also match, so
the only difference is that if the regex does happen to
backtrack, it will backtrack over all the spaces after the To:
at once instead of one at a time.
I have only just subscribed so I do not have enough context to
know what the problem is, but based on what I have seen so far it
seems to me that all you want is simply
/^To:\s?(.+)\s*\nCc:/ism
although I have to wonder if the /s modifier here is really what
you want.
> I think the correct term for *+, ++, ?+ etc is "possessive"
> quantifiers, I'm just not sure.
That is correct.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
^ permalink raw reply
* Re: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
From: Steve Frécinaux @ 2008-11-10 8:38 UTC (permalink / raw)
To: Arafangion; +Cc: David Symonds, git
In-Reply-To: <1226127130.8252.6.camel@therock.nsw.bigpond.net.au>
Arafangion wrote:
> On Fri, 2008-11-07 at 21:19 -0800, David Symonds wrote:
> <snip>
>> _gitConfig = None
>> def gitConfig(key):
>> if _gitConfig is None:
>> lines = read_pipe("git config -l", ignore_error=True).readlines():
>> _gitConfig = dict([l.strip().split('=', 1) for l in lines])
>> return _gitConfig.get(key, None)
>
> That certainly is better, if one can assume that git's configuration is
> small. (And relative to the memory usage of the script, it will
> definetly be small).
What about using git config --get-regexp to only get the p4-related
settings ?
I don't really know the options used by git-p4, but something like this
seems like a good candidate to address every trade-off concerns?
git-config --get-regexp '^(p4|user)\.'
^ permalink raw reply
* Re: Large media in git (was: How it was at GitTogether'08)?
From: Jakub Narebski @ 2008-11-10 9:30 UTC (permalink / raw)
To: Kai Blin; +Cc: git, Tim Ansell
In-Reply-To: <200811091955.19304.kai@samba.org>
On Sun, 9 Nov 2008, Kai Blin wrote:
> On Sunday 09 November 2008 17:31:47 Jakub Narebski wrote:
>
> > The workaround is to put all large files for example in 'media/' folder,
> > and make this folder be submodule. Each clone of repository can have
> > this 'media' submodule either present (both in object database, although
> > usually separate from main project object database), or not present
> > (not cloned and not checked out).
>
> Tim was talking about that media/ folder and managing that in git. If you want
> to work on the media, you might end up getting hundreds of gigabytes of data
> to get that folder, even if you only need to change one single file.
>
> That's the issue we're running into, and I don't thing submodules solve this
> at all.
Ah, well... Submodules cannot be workaround for _this_ issue. You can
have only all or nothing: either all files in media/ or none of them,
both in working directory like in repository object database... well
unless you subdivide further.
I guess that mentioned work on the media is in remote setting (you
cannot have main repository on network drive) so Dana How's proposed
solution would not work for you, is it?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
From: Simon Hausmann @ 2008-11-10 9:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Han-Wen Nienhuys, John Chapman, git
In-Reply-To: <7vr65kagvm.fsf@gitster.siamese.dyndns.org>
On Sunday 09 November 2008 Junio C Hamano, wrote:
> These are patches to fast-import/git-p4, which you two seem to in charge
> of.
>
> From: John Chapman <thestar@fussycoder.id.au>
> Subject: [PATCH 1/2] Added support for purged files and also optimised
> memory usage. Date: Sat, 8 Nov 2008 14:22:48 +1100
> Message-Id: <1226114569-8506-1-git-send-email-thestar@fussycoder.id.au>
>
> From: John Chapman <thestar@fussycoder.id.au>
> Subject: [PATCH 2/2] Cached the git configuration, which is now
> noticibly faster on windows. Date: Sat, 8 Nov 2008 14:22:49 +1100
> Message-Id: <1226114569-8506-2-git-send-email-thestar@fussycoder.id.au>
>
> It was unfortunately not immediately obvious from the Subject: line what
> these patches are about, and I am guessing you missed them because of that.
Ack on both patches. The second one could be done better, as suggested in the
follow-ups, but both are clearly an improvement :)
Simon
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Michal Nazarewicz @ 2008-11-10 9:49 UTC (permalink / raw)
To: dhruva; +Cc: sverre, git
In-Reply-To: <e3f230850811091943k63e4a93n566402458a6947dd@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]
> On Mon, Nov 10, 2008 at 6:46 AM, Michal Nazarewicz <mina86@tlen.pl> wrote:
>> I would like the "$Id$" sequences to be updated automatically after
>> a commit (ie. without the need to check out).
dhruva <dhruvakm@gmail.com> writes:
> There is no direct way to get this $Id$ expansion in git, however you
> can use a simple pre-commit hook (alpha state, more a proof of concept
> that happens to work for me)
>
> #!/usr/bin/env bash
>
> for file in `git diff-index --name-only --diff-filter=AM HEAD` ; do
> perl -pi -e 's/(\$[ \t]*Id)(.*)([ \t]*\$)/"\$Id: git
> ".time()." \$"/e' ${file}
> git add ${file} > /dev/null
> done
In fact the following works just as well:
#v+
files=$(git diff-index --name-only --diff-filter=AM HEAD)
perl -pi -e 's/\$\s*Id.*?\$/\$Id: git '$(TZ=UTC date +%s)' \$/g' $files
git add $files
#v-
But then again, it has two unpleasant side effects: (i) all modified
files are added and (ii) if I abort a commit the file stays modified.
(i) can be fixed by removing "git add" but then again (iii) even files
which are not committed will be modified.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Johannes Schindelin @ 2008-11-10 9:58 UTC (permalink / raw)
To: Kai Blin; +Cc: Jakub Narebski, David Symonds, git, Tim Ansell
In-Reply-To: <200811091955.19304.kai@samba.org>
Hi,
On Sun, 9 Nov 2008, Kai Blin wrote:
> On Sunday 09 November 2008 17:31:47 Jakub Narebski wrote:
>
> > The workaround is to put all large files for example in 'media/'
> > folder, and make this folder be submodule. Each clone of repository
> > can have this 'media' submodule either present (both in object
> > database, although usually separate from main project object
> > database), or not present (not cloned and not checked out).
>
> Tim was talking about that media/ folder and managing that in git. If
> you want to work on the media, you might end up getting hundreds of
> gigabytes of data to get that folder, even if you only need to change
> one single file.
>
> That's the issue we're running into, and I don't thing submodules solve
> this at all.
You'd have to have a single repository for each and every media file, and
you'd need to use shallow clones and shallow fetches.
However, a push-conflict will probably be beyond any non-programmer
skillz.
I'd rather propose to have a different interface, like through a web
server, where the user can say "I have some cool new graphics, in this
.zip file" together with a commit message.
Kind of a git-gui via browser.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/2] Document "git log --source"
From: Nanako Shiraishi @ 2008-11-10 9:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Documentation/git-log.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 93a2a22..34cf4e5 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -40,6 +40,10 @@ include::diff-options.txt[]
--decorate::
Print out the ref names of any commits that are shown.
+--source::
+ Print out the ref name given on the command line by which each
+ commit was reached.
+
--full-diff::
Without this flag, "git log -p <path>..." shows commits that
touch the specified paths, and diffs about the same specified
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH 2/2] Document "git log --simplify-by-decoration"
From: Nanako Shiraishi @ 2008-11-10 9:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Documentation/rev-list-options.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 966276b..977290c 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -456,6 +456,13 @@ Note the major differences in `N` and `P` over '\--full-history':
removed completely, because it had one parent and is TREESAME.
--
+The '\--simplify-by-decoration' option can be used to treat commits that
+are not referenced by tags as TREESAME, and treat commits that are tagged
+as !TREESAME (even when they have exactly the same tree as their parents).
+This can be used when you are only interested in the big picture of the
+topology of the history.
+
+
ifdef::git-rev-list[]
Bisection Helpers
~~~~~~~~~~~~~~~~~
--
1.6.0.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Jonas Fonseca @ 2008-11-10 10:07 UTC (permalink / raw)
To: Piotr Findeisen; +Cc: git
In-Reply-To: <ddb82bf60811092338m3aad8041w20de23f18aa7d56e@mail.gmail.com>
Piotr Findeisen <piotr.findeisen@gmail.com> wrote Mon, Nov 10, 2008:
> >>> Asciidoc replaces "--" with "—" when not in verbatim mode. This is
> >>> sometimes unwanted -- especially when citing command line options like
> >>> "git diff --cached". This commit includes proper quotes in user-manual.txt.
> >
> > Newer asciidoc versions have the following "workaround". Maybe adding
> > something like this to Documentation/asciidoc.conf would be more
> > future proof.
>
> Well, this doesn't solve the problem -- I'm not talking about
> manpages, the "--" where replaced with single "—" on the
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html page.
Sorry I didn't read your mail carefully enough.
> Yes, we can disable such a replacement in the config file, but take a
> look at the sentence "...how to fetch and study a project using
> git—read these chapters...". In this case "--" in the source file was
> replaced with "—" and this is what we want.
True.
> I noticed that all substitutions "--" -> "—", where "—" is a part of
> sentence punctuation, match \w--\w pattern (e.g. no spaces on both
> sides) and probably this is how it should be written in English. But
> basing on this doesn't seem to me to be fool proof.
So another option is to disable all substitution of "--" and just use
the "—" character when it is explicitly needed. The documentation is
using UTF-8 after all. This would also fix the usage of "--" in the
manpages, e.g.
You've now initialized the working directory--you may notice ...
in gittutorial(7). On my setup, with "--" replaced with "—", I get the
following nroff code:
You've now initialized the working directory\(emyou may notice
...
--
Jonas Fonseca
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Kai Blin @ 2008-11-10 10:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, David Symonds, git, Tim Ansell
In-Reply-To: <alpine.DEB.1.00.0811101055020.30769@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
On Monday 10 November 2008 10:58:05 Johannes Schindelin wrote:
Hi Dscho,
> > Tim was talking about that media/ folder and managing that in git. If
> > you want to work on the media, you might end up getting hundreds of
> > gigabytes of data to get that folder, even if you only need to change
> > one single file.
> >
> > That's the issue we're running into, and I don't thing submodules solve
> > this at all.
>
> You'd have to have a single repository for each and every media file, and
> you'd need to use shallow clones and shallow fetches.
>
> However, a push-conflict will probably be beyond any non-programmer
> skillz.
Ok, I agree. But you could work around that by teaching the artists to
fetch/rebase/push instead of just pushing, or hiding this in the GUI. If
there's a conflict on a binary data file you're screwed anyway. :)
> I'd rather propose to have a different interface, like through a web
> server, where the user can say "I have some cool new graphics, in this
> .zip file" together with a commit message.
>
> Kind of a git-gui via browser.
Incidentally I'm currently working on something like this, just aimed at
the "artist side", instead of the VCS side. This certainly is a useable
solution for artists. But at some point a developer will want to check out
the repository to cut a release tarball, and we're back to wanting shallow
and narrow clones. :)
Cheers,
Kai
--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Large media in git (was: How it was at GitTogether'08)?
From: Kai Blin @ 2008-11-10 10:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Tim Ansell
In-Reply-To: <200811101030.54070.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]
On Monday 10 November 2008 10:30:53 Jakub Narebski wrote:
> On Sun, 9 Nov 2008, Kai Blin wrote:
> > On Sunday 09 November 2008 17:31:47 Jakub Narebski wrote:
> > > The workaround is to put all large files for example in 'media/'
> > > folder, and make this folder be submodule. Each clone of repository can
> > > have this 'media' submodule either present (both in object database,
> > > although usually separate from main project object database), or not
> > > present (not cloned and not checked out).
> >
> > Tim was talking about that media/ folder and managing that in git. If you
> > want to work on the media, you might end up getting hundreds of gigabytes
> > of data to get that folder, even if you only need to change one single
> > file.
> >
> > That's the issue we're running into, and I don't thing submodules solve
> > this at all.
>
> Ah, well... Submodules cannot be workaround for _this_ issue. You can
> have only all or nothing: either all files in media/ or none of them,
> both in working directory like in repository object database... well
> unless you subdivide further.
>
> I guess that mentioned work on the media is in remote setting (you
> cannot have main repository on network drive) so Dana How's proposed
> solution would not work for you, is it?
If my google-fu worked, the proposed solution you're talking about involves
simply hiding large blobs from pack files, right? In that case it won't work,
as the users of the repository indeed are remote.
Cheers,
Kai
--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Piotr Findeisen @ 2008-11-10 10:14 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20081110100757.GA12868@diku.dk>
>
>> I noticed that all substitutions "--" -> "—", where "—" is a part of
>> sentence punctuation, match \w--\w pattern (e.g. no spaces on both
>> sides) and probably this is how it should be written in English. But
>> basing on this doesn't seem to me to be fool proof.
>
> So another option is to disable all substitution of "--" and just use
> the "—" character when it is explicitly needed. The documentation is
> using UTF-8 after all. This would also fix the usage of "--" in the
> manpages, e.g.
>
> You've now initialized the working directory--you may notice ...
>
> in gittutorial(7). On my setup, with "--" replaced with "—", I get the
> following nroff code:
On my machine, make gittutorial.7 produces manpage that displays "--"
in this place :)
>
> You've now initialized the working directory\(emyou may notice
Anyway, this may be a good idea to use unambiguous "—" (though people
writing docs may be used to using "--" as a punctuation). I can run
through the Documentation replacing "\w--\w" with m-dash, if you want.
Regards,
Piotr
^ 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