* Re: [PATCH] Fix naming scheme for configure cache variables.
From: Junio C Hamano @ 2009-01-21 10:26 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20090119203436.GB3539@ins.uni-bonn.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> In order to be cached, configure variables need to contain the
> string '_cv_', and they should begin with a package-specific
> prefix in order to avoid interfering with third-party macros.
> Rename ld_dashr, ld_wl_rpath, ld_rpath to git_cv_ld_dashr etc.
>
> Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Thanks.
^ permalink raw reply
* Re: [PATCH resend] bash completion: add 'rename' subcommand to git-remote
From: Junio C Hamano @ 2009-01-21 10:26 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Shawn O. Pearce, git
In-Reply-To: <200901201921.10223.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> Junio C Hamano, 17.01.2009:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>
>> > Markus Heidelberg <markus.heidelberg@web.de> wrote:
>> >>
>> >> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
>> >
>> > Acked-by: Shawn O. Pearce <spearce@spearce.org>
>> >
>> >> I've just accidently read in the completion file itself, that
>> >> Shawn is the maintainer, so I give it a third try. The first two
>> >> haven't been sent to him.
>> >
>> > Sorry, I must have missed the other two attempts. :-)
>>
>> And I seem to have missed all three.
>
> I really don't like to bother you again, but compared to the inclusion
> of the other patches, I guess you have forgotten the third try of this
> patch.
>
> Thus this fourth try :)
I did not mean that I forgot by the above "I seem to have missed".
Literally none of your three attempts seem to have reached me. I can
guess what you wrote from the _included_ text in Shawn's response, but
that is not a good/right place for me to pick up a patch from, is it?
^ permalink raw reply
* Re: [PATCH] [TOPGIT] make creating a commit from a topgit branch a function
From: Uwe Kleine-König @ 2009-01-21 10:16 UTC (permalink / raw)
To: martin f krafft; +Cc: git, Petr Baudis
In-Reply-To: <20090121031913.GA7422@lapse.rw.madduck.net>
On Wed, Jan 21, 2009 at 02:19:13PM +1100, martin f krafft wrote:
> also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.01.15.0827 +1100]:
> > This helps avoiding code duplication for the next commit.
>
> What's the "next commit"?
oh, sorry. I intended to post my patch that implements `tg export
--linearize`, but then found a bug and so didn't send it.
You can find it in my pu branch at
git://git.pengutronix.de/git/ukl/topgit.git pu
. It's not yet ready for general use, but I look forward to any
constructive feedback.
Best regards and thanks for the reminder,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [VALGRIND PATCH for nth_last patch series] Fix invalid memory access
From: Junio C Hamano @ 2009-01-21 10:13 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johannes Schindelin, git, Johannes Sixt, Johan Herland
In-Reply-To: <200901211019.01493.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Actually the point of that exercise was to ignore branch (non)switches
> of the form
>
> checkout: moving from A to A
Ahhh, Ok, that is what I missed.
> I originally thought that this would be desirable behaviour, but now
> that it causes so much trouble, I'm not that sure any more. I still
> think it would be more intuitive to not count them as switches (after
> all git-checkout says 'Already on "$branch"'), but OTOH 'cd .; cd -'
> also stays in the same directory.
An entry of the form "from A to A" is made only when you explicitly ask to
checkout the current branch by name (i.e. "git checkout" without any
parameter won't add such an entry to the reflog), so I tend to agree with
"cd" that the users may find it more natural if we counted them.
Having said all that, I think Dscho's one had an off-by-one (but it is
getting late and it may be I who has one).
When parsing "checkout: moving from master to side\n", match points at
"master to...", target points at "side\n", and len is 6 (length of
"master"). We want to see if target is "master\n" and ignore such an
entry, so we should be checking if target is one longer than len.
sha1_name.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git c/sha1_name.c w/sha1_name.c
index 38c9f1b..9aed8ae 100644
--- c/sha1_name.c
+++ w/sha1_name.c
@@ -731,7 +731,10 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
return 0;
len = target - match - 4;
- if (target[len] == '\n' && !strncmp(match, target, len))
+ if (len + 1 == strlen(target) &&
+ target[len] == '\n' &&
+ !memcmp(target, match, len))
+ /* switching same branch "from A to A\n" */
return 0;
nth = cb->cnt++ % cb->alloc;
^ permalink raw reply related
* Re: how to git a read only directory
From: Michael J Gruber @ 2009-01-21 9:57 UTC (permalink / raw)
To: git, cbill.lam
In-Reply-To: <20090121083354.GG6970@b2j>
bill lam venit, vidit, dixit 21.01.2009 09:33:
> I want to use git to keep track of files inside /etc but do not want
> to do it as a super user. Is that possible to put GIT_DIR under my
> home directory and add public-read files inside /etc? Or that it could
> be done in some other ways.
>
> Thanks.
>
You can use the core.worktree config variable in order to specify a
worktree (/etc) which is not directly above .git. For your git commands
to find the .git dir you would need to set GIT_DIR or use the --git-dir
parameter.
I have found, though, that several git commands require you to be within
the worktree or else they become confused. I use a shell function for
that, doing something like "gg ~/path/project log" which requires
~/path/project.git to have its core.worktree set. Also, having a git
alias like "git view" set up for gitk helps calling gitk in that way.
git-gui makes unfounded assumptions and is completely unhappy in a
situation like that.
I think the situation around GIT_DIR and and worktree is a bit in the
flux at the moment (panta rhei..) but it works for me.
Cheers,
Michael
Here's the "git go" bash function. I'm not proud of it, it makes several
assumptions and does no error checking. Use it like "gg path/project
command parameters" if the git-dir is "path/project.git" or "gg
path/project/" if the git-dir is "path/project/.git". Have your
core.worktree set in the former case, and also in the latter if the
worktree is not "path/project".
I'm sure it can be done much better using helper functions from git's
bash-completion, e.g.
gg ()
{
local _gg="$1";
shift;
local _ggwt=`git --git-dir="${_gg}.git" config --get core.worktree`;
if [ -z "${_ggwt}" ]; then
_ggwt=$(cd ${_gg} 2> /dev/null && pwd -P);
fi;
local _gggd=$(cd ${_gg}.git 2> /dev/null && pwd -P);
pushd ${_ggwt} > /dev/null;
git --git-dir=${_gggd} "$@";
popd > /dev/null
}
^ permalink raw reply
* Re: how to keeping track of cherry-pick?
From: Junio C Hamano @ 2009-01-21 9:47 UTC (permalink / raw)
To: Knut Olav Bøhmer; +Cc: git
In-Reply-To: <4976E059.6000404@telenor.com>
Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:
> Junio C Hamano wrote:
>> Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:
>>
>>> svnmerge.py can give us a list of revisions available for merging. The
>>> result is similar to "git log --chery-pick master..dev" The difference
>>> is that svnmerge.py operates on revision-numbers, and --chery-pick looks
>>> at the diffs. The result of that is that when we get a conflict when a
>>> patch is cherry-picked, it will still show up as "available" when I run
>>> "git log --cherry-pick master..dev"
>>
>> I think you are looking at it a wrong way.
>>
>> Because subversion (at least the older one) does not keep track of merges,
>> you had to track cherry-picks. But cherry-pick is not how you usually do
>> things in git. You keep many topic branches with different doneness, and
>> you merge well-cooked ones to the more stable integration branch while
>> leaving others still cooking. So what you want to know is not cherry-pick
>> status, but merge status.
>
>
> I was afraid I would get this answer. I know that you change your
> workflow when you migrate to git, but I was looking for a way to resolve
> the situation we are in, due to our old vcs.
Maybe I should rephrase the answer, then.
I had an impression that you made it sound as if svnmerge.py is a tool
only meant for a workflow of always cherry-picking, but it actually is
not. It also enhances your SVN experience by giving something closer to
proper merge tracking. Even though you only mentioned cherry-picks and
merge blocking, if you like things offered by svnmerge.py other than these
two, you might find that git already has them natively.
When your workflow is based on a single large, unfocused, everything
mixed-in, playpen branch, plus one stable integration branch, you have to
cherry pick to keep the stable integration branch sane, and you need a
good tool to help you keep track of what is cherry picked and what isn't
(yet). Maybe your SCM has such a tool natively, or maybe it doesn't and
needs a third party tool support (similar to users of older SVN needed to
use svnmerge.py for merge tracking) bolted on.
---A1--B1--C1--A2--A3--C2--D1--... playpen kitchen-sink
---o---o---o---A1'--A2'--A3'... stable integration
The workflow when using git is typically merge based, and git lets you
manage topic branches well and helps you merge easily by keeping track of
merges.
I am reading from http://www.orcaware.com/svn/wiki/Svnmerge.py while I am
typing this, but here is a summary:
(1) Because merge tracking is built-in to git, you do not need "something
like svnmerge.py" bolted on. If you have been using topic branches
in your established SVN-based workflow, you can keep the same
workflow and git will do the right thing when you merge your
branches naturally.
(2) We didn't have need for "cherry-pick tracking" part of what
svnmerge.py offers, because we do not do cherry-picks as often.
You can call this shortcoming if you want, but it should be easy for
you to contribute a patch to add such a tool if you miss this part of
svnmerge.py; essentially, you need to keep a database of commit
object names on the "playpen branch" depicted above, and
corresponding commit objects cherry-picked from them into the
integration branch.
(3) We have "listing changes that are available for merging" natively, as
I've already explained in the previous message.
(4) Bidirectional merges, merging from multiple branches, reverting
merges, and merge commit message generation are all native features
of "git merge". If you have git, you already have them. If you do
not like the merge result, you can always amend it; commit-free-ness
is listed as if it is a feature but it does not matter here.
(5) We do not have "merge blocking". This falls into the same category
as (2) above.
^ permalink raw reply
* Re: [PATCH] Change the spelling of "wordregex".
From: Thomas Rast @ 2009-01-21 9:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Boyd Stephen Smith Jr., Santi Béjar, git, Junio C Hamano,
Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901210925430.7929@racer>
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
Johannes Schindelin wrote:
> And Thomas just imitated "xfuncname", which just so happens to be without
> an "_".
Then again I ignored the 'x' for "extended regex", so it's not
entirely consistent.
[Mostly because I think the user expects a "<something>" whenever
there's an "x<something>", and "funcname" is actually deprecated/not
documented any more, so introducing a basic-regex version seemed
silly.]
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VALGRIND PATCH for nth_last patch series] Fix invalid memory access
From: Thomas Rast @ 2009-01-21 9:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vwscpgi7t.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
Junio C Hamano wrote:
> We only accept "checkout: moving from A to B" newer style reflog entries,
> in order to pick up A. There is no point computing where B begins at
> after running strstr to locate " to ", nor adding 4 and then subtracting 4
> from the same pointer.
[...]
> - len = target - match - 4;
> - if (target[len] == '\n' && !strncmp(match, target, len))
> - return 0;
> -
> + len = target - match;
Actually the point of that exercise was to ignore branch (non)switches
of the form
checkout: moving from A to A
I originally thought that this would be desirable behaviour, but now
that it causes so much trouble, I'm not that sure any more. I still
think it would be more intuitive to not count them as switches (after
all git-checkout says 'Already on "$branch"'), but OTOH 'cd .; cd -'
also stays in the same directory.
Thanks for all the work you (both) are doing on this. I hope to find
the time to read the current state of the series tonight.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: how to keeping track of cherry-pick?
From: Michael J Gruber @ 2009-01-21 9:13 UTC (permalink / raw)
To: Knut Olav Bøhmer; +Cc: git, Junio C Hamano
In-Reply-To: <4976E059.6000404@telenor.com>
Knut Olav Bøhmer venit, vidit, dixit 21.01.2009 09:44:
> Junio C Hamano wrote:
>> Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:
>>
>>> svnmerge.py can give us a list of revisions available for merging. The
>>> result is similar to "git log --chery-pick master..dev" The difference
>>> is that svnmerge.py operates on revision-numbers, and --chery-pick looks
>>> at the diffs. The result of that is that when we get a conflict when a
>>> patch is cherry-picked, it will still show up as "available" when I run
>>> "git log --cherry-pick master..dev"
>> I think you are looking at it a wrong way.
>>
>> Because subversion (at least the older one) does not keep track of merges,
>> you had to track cherry-picks. But cherry-pick is not how you usually do
>> things in git. You keep many topic branches with different doneness, and
>> you merge well-cooked ones to the more stable integration branch while
>> leaving others still cooking. So what you want to know is not cherry-pick
>> status, but merge status.
>
>
> I was afraid I would get this answer. I know that you change your
> workflow when you migrate to git, but I was looking for a way to resolve
> the situation we are in, due to our old vcs.
In the transition phase, while you still have to work off your
un-gittish svn feature branches, you can mimick svnmerge.py's blocking
at least somewhat: If you merge that branch (or a commit on that branch,
i.e. that branch up to that commit) using "git merge -s ours" then git
records a merge but does not change your base branch. This effectively
blocks all commits up that one from being merged in subsequent merges:
They're recorded as merged, but they are not "applied".
The disadvantage is that you have to go through your svn feature branch
sequentially, merge what you want to keep, merge -s ours what you want
to block. You can't easily "unblock" later because that would mean
reverting a merge.
For sure, the better option is to rip your svn feature branch apart into
git feature branches as Junio suggests, maybe using one of the patch
queue like "extensions" to git.
Michael
^ permalink raw reply
* Re: [PATCH 1/2 v2] Add valgrind support in test scripts
From: Junio C Hamano @ 2009-01-21 8:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0901210209580.19014@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This patch adds the ability to use valgrind's memcheck tool to
> diagnose memory problems in git while running the test scripts....
Hmmm, why do I haf to suffer with these new warnings from the tests?
$ sh t2012-checkout-last.sh --valgrind -v -i
warning: templates not found /git/git.git/t/valgrind/bin/templates/blt/
Initialized empty Git repository in /git/git.git/t/trash directory.t2012-checkout-last/.git/
mv: cannot stat `.git/hooks': No such file or directory
* expecting success:
echo hello >world &&
Am I using the patch incorrectly somehow?
^ permalink raw reply
* Re: [VALGRIND PATCH for nth_last patch series] Fix invalid memory access
From: Junio C Hamano @ 2009-01-21 8:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <alpine.DEB.1.00.0901210113500.19014@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> sha1_name.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/sha1_name.c b/sha1_name.c
> index 4d10705..803f9d2 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -735,7 +735,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
> if ((target = strstr(match, " to ")) != NULL) {
> len = target - match;
> target += 4;
> - if (target[len] == '\n' && !strncmp(match, target, len))
> + if (len == strlen(target) && !strncmp(match, target, len))
> return 0;
> }
> else
Actually, I think this patch to a884d0c (sha1_name: tweak @{-N} lookup,
2009-01-17) would make more sense.
-- >8 --
Subject: [PATCH] Simplify parsing branch switching events in reflog
We only accept "checkout: moving from A to B" newer style reflog entries,
in order to pick up A. There is no point computing where B begins at
after running strstr to locate " to ", nor adding 4 and then subtracting 4
from the same pointer.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
sha1_name.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 38c9f1b..7d95bbb 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -723,17 +723,13 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
if (!prefixcmp(message, "checkout: moving from ")) {
match = message + strlen("checkout: moving from ");
- if ((target = strstr(match, " to ")) != NULL)
- target += 4;
+ target = strstr(match, " to ");
}
if (!match || !target)
return 0;
- len = target - match - 4;
- if (target[len] == '\n' && !strncmp(match, target, len))
- return 0;
-
+ len = target - match;
nth = cb->cnt++ % cb->alloc;
strbuf_reset(&cb->buf[nth]);
strbuf_add(&cb->buf[nth], match, len);
--
1.6.1.281.g16db
^ permalink raw reply related
* Re: how to keeping track of cherry-pick?
From: Knut Olav Bøhmer @ 2009-01-21 8:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vfxjdjvk8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:
>
>> svnmerge.py can give us a list of revisions available for merging. The
>> result is similar to "git log --chery-pick master..dev" The difference
>> is that svnmerge.py operates on revision-numbers, and --chery-pick looks
>> at the diffs. The result of that is that when we get a conflict when a
>> patch is cherry-picked, it will still show up as "available" when I run
>> "git log --cherry-pick master..dev"
>
> I think you are looking at it a wrong way.
>
> Because subversion (at least the older one) does not keep track of merges,
> you had to track cherry-picks. But cherry-pick is not how you usually do
> things in git. You keep many topic branches with different doneness, and
> you merge well-cooked ones to the more stable integration branch while
> leaving others still cooking. So what you want to know is not cherry-pick
> status, but merge status.
I was afraid I would get this answer. I know that you change your
workflow when you migrate to git, but I was looking for a way to resolve
the situation we are in, due to our old vcs.
--
Knut Olav Bøhmer
^ permalink raw reply
* how to git a read only directory
From: bill lam @ 2009-01-21 8:33 UTC (permalink / raw)
To: git
I want to use git to keep track of files inside /etc but do not want
to do it as a super user. Is that possible to put GIT_DIR under my
home directory and add public-read files inside /etc? Or that it could
be done in some other ways.
Thanks.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩164 張喬 書邊事
調角斷清秋 征人倚戍樓 春風對青塚 白日落梁州
大漠無兵阻 窮邊有客遊 蕃情似此水 長願向南流
^ permalink raw reply
* Re: [PATCH] Change the spelling of "wordregex".
From: Johannes Schindelin @ 2009-01-21 8:26 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Santi Béjar, Thomas Rast, git, Junio C Hamano, Teemu Likonen
In-Reply-To: <200901202259.54886.bss@iguanasuicide.net>
Hi,
On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
> diff --git a/userdiff.c b/userdiff.c
> index 2b55509..d556da9 100644
> --- a/userdiff.c
> +++ b/userdiff.c
> @@ -6,8 +6,8 @@ static struct userdiff_driver *drivers;
> static int ndrivers;
> static int drivers_alloc;
>
> -#define PATTERNS(name, pattern, wordregex) \
> - { name, NULL, -1, { pattern, REG_EXTENDED }, wordregex }
> +#define PATTERNS(name, pattern, word_regex) \
> + { name, NULL, -1, { pattern, REG_EXTENDED }, word_regex }
> static struct userdiff_driver builtin_drivers[] = {
> PATTERNS("html", "^[ \t]*(<[Hh][1-6][ \t].*>.*)$",
> "[^<>= \t]+|[^[:space:]]|[\x80-\xff]+"),
In general, it is an awesomly good idea to imitate code that is already
there. That literally guarantees consistency (which is Good, as you
know).
And Thomas just imitated "xfuncname", which just so happens to be without
an "_".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] color-words: Support diff.color-words config option
From: Johannes Schindelin @ 2009-01-21 8:25 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Santi Béjar, Thomas Rast, git, Junio C Hamano, Teemu Likonen
In-Reply-To: <200901202146.58651.bss@iguanasuicide.net>
Hi,
On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
> It uses "diff.wordregex" for reasons mention by Dscho and because that
> was already what the diff drivers were using.
To be fair, Jakub and Junio mentioned it, too.
> I'm not entirely satisfied with it. There should probably be some way
> to force the default behavior (which is a bit faster) even if a global
> config or diff driver exists. Also, I think camelCase is better than
> runtogether so I'd prefer to change "wordregex" -> "wordRegex" across
> the entire patch set.
Well, the thing is, it _should_ be "wordRegex", _except_ in the strcmp()
because the config helpers get a downcased key.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add --contains flag to git tag
From: Johannes Schindelin @ 2009-01-21 8:21 UTC (permalink / raw)
To: Jake Goulding; +Cc: Miklos Vajna, git
In-Reply-To: <25058429.247441232510076471.JavaMail.root@scalix.vivisimo.com>
Hi,
On Tue, 20 Jan 2009, Jake Goulding wrote:
> I actually have 1 commit for the code change, one for documentation, and
> one for the test case. Should I squash all these together?
In general, if the patches are not very large and logically belong
together, it is a matter of taste if you squash together documentation and
code changes. Tests, however, belong with the code.
> Also, my test case is in a separate file (t7704-tag-contains.sh) as that
> is how I read t/README. Was this incorrect?
Again, the size matters. If it is a single test case, it is not worth a
whole new file, especially when something like t7004-tag.sh already
exists, whose name just asks for your test case to go in there.
Ciao,
Dscho
^ permalink raw reply
* read-only working copy using symlinks to blobs
From: chadrik @ 2009-01-21 8:15 UTC (permalink / raw)
To: git
hi all,
i'm looking into using git to manage a lot of very large binary data. git
seems particularly suited to this task because it has features for saving
disk space such as clone--shared, and it's fast due to simple compression by
default (instead of deltas).
in my mind, there's still one major feature for working with large binaries
that has not been addressed: the ability to check out symbolic/hard links
to blobs into the working copy instead of creating duplicates of the files.
imagine a scenario where one user is putting large binary files into a git
repo. 100 other users need read-only access to this repo. they clone the
repo shared, which saves disk space for the object files, but each of these
100 working copies also creates copies of all the binary files at the HEAD
revision. it would be 100x as efficient if, in place of these files,
symbolic or hard links were made to the blob files in .git/objects.
the crux of the issue is that the blob objects would have to be stored as
exact copies of the original files. i did some googling and it would seem
there are two things that currently prevent this from happening. 1) blobs
are stored with compression and 2) they include a small header. compression
can be disabled by setting core.loosecompression to 0, so that seems like
less of an issue. as for the header, wouldn't it be possible to store it as
a separate file per blob object and thus keep the original data completely
pristine?
what are the caveats to a system like this? any thoughts on the
feasibility?
-chad
--
View this message in context: http://www.nabble.com/read-only-working-copy-using-symlinks-to-blobs-tp21578696p21578696.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir]
From: Alex Riesen @ 2009-01-21 7:25 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: John Chapman, Hannu Koivisto, rdkrsr, git
In-Reply-To: <alpine.LNX.1.00.0901201833400.19665@iabervon.org>
2009/1/21 Daniel Barkalow <barkalow@iabervon.org>:
> On Wed, 21 Jan 2009, Alex Riesen wrote:
>
>> 2009/1/20 Daniel Barkalow <barkalow@iabervon.org>:
>> > My impression was that this didn't happen in practice, because teams
>> > would tend to not have two people create the same file at the same time,
>> > but with different cases, and people interacting with the same file at
>> > different times would use whatever case it was introduced with.
>>
>> It will and does happen in practice (annoingly too often even). Not with Git
>> yet (with Perforce), where people do "branching" by simply copying things
>> in another directory (perforce world does not know real branches),
>> renaming files randomly, and putting the new directory back in the
>> system (or maybe it is the strange tools here which do that - often
>> it is the first character of a directory or file which gets down- or up-cased).
>
> How does the resulting code work at all? ...
Sometimes it does not. Sometimes it does. Depends on that particular
checkout order perforce (or user?) selected to use this time.
> ... With a case-sensitive filesystem,
> most of the files you're using don't have the expected names any more, and
> most systems will therefore not actually build or run.
Except that there is no case-sensitive file systems on development machines.
So a botched case wont be noticed by a standard build procedure unless
the content of the files causes an error.
>> As Perforce itself is case sensitive (like Git), using of such branches
>> is a nightmare: the files get overwritten in checkout order which is
>> not always sorted in predictable order. Combined with case-stupidity
>> of the file system the working directories sometimes cause "interesting
>> time" for unlucky users.
>> Luckily (sadly) it is all-opening-in-a-wall shop, so the problem with "fanthom"
>> files is rare (it is hard to notice) for most. Which actually makes it more
>> frustrating when the real shit happens.
>>
>> And it will happen to Git as well, especially if development go crossplatform.
>> It is not that hard to accidentally rename a file on case-sensitive file system,
>> "git add *" it and commit without thinking (that's how most of software
>> development happens, come to think of it).
>
> People can accidentally rename files?
Aside from tools (and in my own experience - I did) - they can and do.
> And still have things work when they do it on a case-sensitive filesystem?
Shameless luck, I'd say. That and "no file systems permitted, but the one
from finance dept".
^ permalink raw reply
* Re: what are plumbing and porcelain
From: bill lam @ 2009-01-21 7:23 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: bill lam, git
In-Reply-To: <200901210051.21663.bss@iguanasuicide.net>
Thanks for bringing my attention to that.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩306 鄭畋 馬嵬坡
玄宗回馬楊妃死 雲雨難忘日月新 終是聖明天子事 景陽宮井又何人
^ permalink raw reply
* Re: what are plumbing and porcelain
From: Boyd Stephen Smith Jr. @ 2009-01-21 6:51 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090121060726.GE6970@b2j>
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
On Wednesday 21 January 2009, bill lam <cbill.lam@gmail.com> wrote
about 'Re: what are plumbing and porcelain':
>On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
>> "plumbing" are the commands that do low-level operations. Generally,
>> end-users won't have to use them much, if at all, but they
>
>I can see now gitk should probably be porcelain. But how about
>commands such as git add or git rebase used with either the -i switch
>on or off?
If you have git installed, "man git" should contain separate lists of
porcelain and plumbing. If not, the documentation is available in the git
repository, under Documentation/. Porcelain: cmds-mainporcelain.txt,
cmds-ancillarymanipulators.txt, cmds-ancillaryinterrogators.txt, and
cmds-foreignscminterface.txt. Plumbing: cmds-plumbingmanipulators.txt,
cmds-plumbinginterrogators.txt, cmds-synchingrepositories.txt,
cmds-synchelpers.txt, and cmds-purehelpers.txt
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: what are plumbing and porcelain
From: bill lam @ 2009-01-21 6:07 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901202350.15011.bss@iguanasuicide.net>
On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
> "plumbing" are the commands that do low-level operations. Generally,
> end-users won't have to use them much, if at all, but they
I can see now gitk should probably be porcelain. But how about
commands such as git add or git rebase used with either the -i switch
on or off?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩299 李商隱 寄令狐郎中
嵩雲秦樹久離居 雙鯉迢迢一紙筆 休問梁園舊賓客 茂陵秋雨病相如
^ permalink raw reply
* Re: what are plumbing and porcelain
From: Boyd Stephen Smith Jr. @ 2009-01-21 5:50 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090121052741.GC6970@b2j>
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]
On Tuesday 20 January 2009, bill lam <cbill.lam@gmail.com> wrote
about 'what are plumbing and porcelain':
>Sorry for this idiot question, but I really don't know what they are
>and why it is necessary to distinguish between them.
"plumbing" are the commands that do low-level operations. Generally,
end-users won't have to use them much, if at all, but they
are "fundamental" operations, upon which git is built. It's a term also
used in other project some, with a similar meaning.
"porcelain" is a cute name for the end-user operations. They "cover" the
plumbing to make it look and act "pretty". While some may be less useful
to some users, they all are high-level operations that depend on the
plumbing.
It's important to distinguish between them because we don't want the
plumbing to get needlessly complex. They should be single-purpose
commands and their options should be utilitarian in nature. Also,
porcelain is meant to be used interactively, not in scripts, so the output
or behavior might change a bit--but that is still kept to a minimum.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* what are plumbing and porcelain
From: bill lam @ 2009-01-21 5:27 UTC (permalink / raw)
To: git
Sorry for this idiot question, but I really don't know what they are
and why it is necessary to distinguish between them.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩318 李白 清平調三首之二
一枝紅豔露凝香 雲雨巫山枉斷腸 借問漢宮誰得似 可憐飛燕倚新妝
^ permalink raw reply
* [PATCH] Change the spelling of "wordregex".
From: Boyd Stephen Smith Jr. @ 2009-01-21 4:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Santi Béjar, Thomas Rast, git, Junio C Hamano, Teemu Likonen
In-Reply-To: <200901202146.58651.bss@iguanasuicide.net>
Use "wordRegex" for configuration variable names. Use "word_regex" for C
language tokens.
Signed-off-by: Boyd Stephen Smith Jr. <bss@iguanasuicide.net>
---
On Tuesday 20 January 2009, "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> wrote about '[PATCH]
color-words: Support diff.color-words config option':
>I'm not entirely satisfied with it. [...] I think camelCase is better than
>runtogether so I'd prefer to change "wordregex" -> "wordRegex" across
>the entire patch set.
Here's a patch that does something like that, that can be squashed into the
previous patch.
Documentation/config.txt | 2 +-
Documentation/gitattributes.txt | 4 ++--
t/t4034-diff-words.sh | 8 ++++----
userdiff.c | 4 ++--
4 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0ca983a..332213e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -639,7 +639,7 @@ diff.suppress-blank-empty::
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
-diff.wordregex::
+diff.wordRegex::
A POSIX Extended Regular Expression used to determine what is a "word"
when performing word-by-word difference calculations. Character
sequences that match the regular expression are "words", all other
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index ba3ba12..227934f 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -341,14 +341,14 @@ Customizing word diff
You can customize the rules that `git diff --color-words` uses to
split words in a line, by specifying an appropriate regular expression
-in the "diff.*.wordregex" configuration variable. For example, in TeX
+in the "diff.*.wordRegex" configuration variable. For example, in TeX
a backslash followed by a sequence of letters forms a command, but
several such commands can be run together without intervening
whitespace. To separate them, use a regular expression such as
------------------------
[diff "tex"]
- wordregex = "\\\\[a-zA-Z]+|[{}]|\\\\.|[^\\{}[:space:]]+"
+ wordRegex = "\\\\[a-zA-Z]+|[{}]|\\\\.|[^\\{}[:space:]]+"
------------------------
A built-in pattern is provided for all languages listed in the
diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
index 6bcc153..4508eff 100755
--- a/t/t4034-diff-words.sh
+++ b/t/t4034-diff-words.sh
@@ -86,7 +86,7 @@ test_expect_success 'word diff with a regular expression' '
'
test_expect_success 'set a diff driver' '
- git config diff.testdriver.wordregex "[^[:space:]]" &&
+ git config diff.testdriver.wordRegex "[^[:space:]]" &&
cat <<EOF > .gitattributes
pre diff=testdriver
post diff=testdriver
@@ -121,8 +121,8 @@ test_expect_success 'use regex supplied by driver' '
'
-test_expect_success 'set diff.wordregex option' '
- git config diff.wordregex "[[:alnum:]]+"
+test_expect_success 'set diff.wordRegex option' '
+ git config diff.wordRegex "[[:alnum:]]+"
'
cp expect.letter-runs-are-words expect
@@ -138,7 +138,7 @@ test_expect_success '.gitattributes override config' '
'
test_expect_success 'remove diff driver regex' '
- git config --unset diff.testdriver.wordregex
+ git config --unset diff.testdriver.wordRegex
'
cat > expect <<\EOF
diff --git a/userdiff.c b/userdiff.c
index 2b55509..d556da9 100644
--- a/userdiff.c
+++ b/userdiff.c
@@ -6,8 +6,8 @@ static struct userdiff_driver *drivers;
static int ndrivers;
static int drivers_alloc;
-#define PATTERNS(name, pattern, wordregex) \
- { name, NULL, -1, { pattern, REG_EXTENDED }, wordregex }
+#define PATTERNS(name, pattern, word_regex) \
+ { name, NULL, -1, { pattern, REG_EXTENDED }, word_regex }
static struct userdiff_driver builtin_drivers[] = {
PATTERNS("html", "^[ \t]*(<[Hh][1-6][ \t].*>.*)$",
"[^<>= \t]+|[^[:space:]]|[\x80-\xff]+"),
--
1.5.6.5
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
^ permalink raw reply related
* Re: [PATCH] Add --contains flag to git tag
From: Jake Goulding @ 2009-01-21 3:54 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20090121032058.GG21473@genesis.frugalware.org>
That is actually in a subsequent commit (in my unmarked patch sequence).
I actually have 1 commit for the code change, one for documentation, and one for the test case. Should I squash all these together?
Also, my test case is in a separate file (t7704-tag-contains.sh) as that is how I read t/README. Was this incorrect?
Thanks!
-Jake
----- Original Message -----
From: "Miklos Vajna" <vmiklos@frugalware.org>
To: "Jake Goulding" <goulding@vivisimo.com>
Cc: git@vger.kernel.org
Sent: Tuesday, January 20, 2009 10:20:58 PM GMT -05:00 US/Canada Eastern
Subject: Re: [PATCH] Add --contains flag to git tag
On Tue, Jan 20, 2009 at 08:37:09PM -0500, Jake Goulding <goulding@vivisimo.com> wrote:
> Please let me know what else I have inevitably messed up, and I shall
> endeavor to fix and resubmit.
Please document your improvements in Documentation/git-tag.txt and don't
forget to add a testcase to t7004-tag.sh.
^ 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