* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2009-12-19 2:24 UTC (permalink / raw)
To: Eric Blake; +Cc: git
In-Reply-To: <loom.20091218T234129-280@post.gmane.org>
On 12/18/2009 02:42 PM, Eric Blake wrote:
> Stephen Boyd<bebarino<at> gmail.com> writes:
>>> echo and \ do not portably mix. For that matter, shell double quotes and
>>> backslash escapes that are not required by POSIX do not portably mix.
>>
>> Thanks. Hopefully squashing this in will make it even more portable?
>>
>> + printf "X-Fake-Field: Line One\015\n"&&
>
> Nope. You need either "\\015\\n" or '\015\n', since "\015" and "\n" are both
> undefined in portable shell.
So, how about this?
{
echo "X-Fake-Field: Line One"&&
echo "X-Fake-Field: Line Two"&&
echo "X-Fake-Field: Line Three"&&
git format-patch --stdout first | sed -e "1d"
} | sed -e "s/$/;/" | tr "'";"'" "'"\015"'"> patch1-crlf.eml
Or maybe this?
{
echo "X-Fake-Field: Line One"&&
echo "X-Fake-Field: Line Two"&&
echo "X-Fake-Field: Line Three"&&
git format-patch --stdout first | sed -e "1d"
} | sed -e "s/$/;/" | tr ";" "\\015"> patch1-crlf.eml
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Moe @ 2009-12-19 3:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miklos Vajna, Junio C Hamano, git
In-Reply-To: <20091219020947.GB10687@spearce.org>
Shawn O. Pearce wrote:
> Miklos Vajna <vmiklos@frugalware.org> wrote:
>> This is like GIT_CONFIG but it is not read instead of .git/config, but
>> in addtition to it.
>
> What file does `git config --add` modify? Should we be able to
> modify the GIT_CONFIG_EXTRA file?
>From my use-case corner: Yes, this would basically be used
to divert ~/.gitconfig and should behave in all the same ways.
> What order is GIT_CONFIG_EXTRA applied in relative to other files
> that git config would also have read?
This is up to Miklos to answer but again from my use-case angle it would
make the most sense to read the usual config files first
and GIT_CONFIG_EXTRA last - that way the user config gets the
last word in terms of overriding global and repository defaults.
And btw, thanks for the fast action Miklos!
Kind regards,
Moe
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Junio C Hamano @ 2009-12-19 3:24 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Moe, git
In-Reply-To: <20091219013246.GD25474@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> This is like GIT_CONFIG but it is not read instead of .git/config, but
> in addtition to it.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Fri, Dec 18, 2009 at 11:54:32PM +0100, Moe <moe@signalbeam.net> wrote:
>> $GIT_CONFIG doesn't work for this purpose because when set
>> git will *only* read the referenced file and ignore the
>> repository settings.
>
> What about this?
The patch text itself may be fine, in the sense that it makes "we read
from three" to "we now read from four", but I am not impressed.
I find the original use case highly moronic.
For people to be sharing an account, hence $HOME, there must be a reason.
They want to (rather, the administrator wants them to) use a common shared
set of settings, so $HOME/.gitconfig should be shared among them, just
like $HOME/.emacs and $HOME/.login are, unless there is some strong reason
to treat .gitconfig any differently from all the other $HOME/.whatever
files. But I don't think there wasn't any argument to defend that.
That makes the patch doubly suspect and throws it into "because we can",
not "because we should".
Wouldn't it be just a matter of giving different HOME after they log-in?
After all, Moe will be giving _some_ way to his users set different value
to GIT_CONFIG_EXTRA depending on who they really are, and that same
mechanism should be usable to set different HOME to them, no?
As $HOME/.gitconfig is relative to the value of that environment variable,
I don't see a reason for us to fall into this "three is not enough, but
when we add another, we are fine" attitude, which makes me suspect that
there is something fundamentally wrong there.
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Nanako Shiraishi @ 2009-12-19 3:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jakub Narebski, Johannes Sixt, Sverre Rabbelier, Git Mailing List
In-Reply-To: <7vr5qrsv4g.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Come back with a proof that there has never existed any script that uses
> "read-tree" without arguments to purge the index, and I'd immediately
> accept and apply the patch to retroactively forbid what the implementation
> has allowed users to do for a long time.
For what it's worth, I compiled the very first version of git
commit e83c5163316f89bfbde7d9ab23ca2e25604af290
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Thu Apr 7 15:13:13 2005 -0700
Initial revision of "git", the information manager from hell
and its read-tree fails with
read-tree: read-tree <key>
Is it a proof enough?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Moe @ 2009-12-19 4:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vhbrnodd9.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
>> This is like GIT_CONFIG but it is not read instead of .git/config, but
>> in addtition to it.
>>
>> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
>> ---
>>
>> On Fri, Dec 18, 2009 at 11:54:32PM +0100, Moe <moe@signalbeam.net> wrote:
>>> $GIT_CONFIG doesn't work for this purpose because when set
>>> git will *only* read the referenced file and ignore the
>>> repository settings.
>> What about this?
>
>
> The patch text itself may be fine, in the sense that it makes "we read
> from three" to "we now read from four", but I am not impressed.
>
> I find the original use case highly moronic.
>
> For people to be sharing an account, hence $HOME, there must be a reason.
> They want to (rather, the administrator wants them to) use a common shared
> set of settings, so $HOME/.gitconfig should be shared among them, just
> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason
> to treat .gitconfig any differently from all the other $HOME/.whatever
> files. But I don't think there wasn't any argument to defend that.
I'm not arguing to treat .gitconfig differently from other
dot-files, but to treat it differently from .git/config.
The former is user-specific, the latter is repository-specific.
For a contrived analogy: Imagine apache would ignore the contents
of .htaccess files when you start httpd with the "-f" switch to
load a different configuration file.
> That makes the patch doubly suspect and throws it into "because we can",
> not "because we should".
>
> Wouldn't it be just a matter of giving different HOME after they log-in?
>
> After all, Moe will be giving _some_ way to his users set different value
> to GIT_CONFIG_EXTRA depending on who they really are, and that same
> mechanism should be usable to set different HOME to them, no?
The individual users are identified by their ssh key. Ssh sets a
distinct environment variable for each, which in turn is used in
.bash_profile to read an additional user-profile.
Yes, we could overwrite $HOME but that would defeat the purpose.
The goal of this setup is to share almost all settings.
Overwriting $HOME would turn this upside down. Instead of diverting
the two bits that we want to customize (git identity and editor
preferences) we would then have to duplicate all other dot-files
for each virtual user - and probably watch out for unforeseen side-effects.
> As $HOME/.gitconfig is relative to the value of that environment variable,
> I don't see a reason for us to fall into this "three is not enough, but
> when we add another, we are fine" attitude, which makes me suspect that
> there is something fundamentally wrong there.
I understand the sentiment.
Without drifting into a discussion about the merit of shared
unix-accounts (they do make a lot of sense in some scenarios)
I hope this can still make it, considering the small size of
the patch and the .git/config vs ~/.gitconfig argument.
--
Kind regards, Moe
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Junio C Hamano @ 2009-12-19 4:43 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Jakub Narebski, Johannes Sixt, Sverre Rabbelier, Git Mailing List
In-Reply-To: <20091219122509.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> Come back with a proof that there has never existed any script that uses
>> "read-tree" without arguments to purge the index, and I'd immediately
>> accept and apply the patch to retroactively forbid what the implementation
>> has allowed users to do for a long time.
>
> For what it's worth, I compiled the very first version of git
>
> commit e83c5163316f89bfbde7d9ab23ca2e25604af290
> Author: Linus Torvalds <torvalds@ppc970.osdl.org>
> Date: Thu Apr 7 15:13:13 2005 -0700
>
> Initial revision of "git", the information manager from hell
>
> and its read-tree fails with
>
> read-tree: read-tree <key>
>
> Is it a proof enough?
Ok, that initial one was "read a single tree to populate the index".
I consider it a fundamentally different program from "read-tree" as we
know now, which was introduced by d99082e (Make "read-tree" merge the
trees it reads by giving them consecutive states., 2005-04-15). Ever
since that "multi-stage" version, read-tree was "starting from an empty
index, read these trees into stages #1, #2, ..." And even that version
called the program "read-tree", not "git read-tree". IOW, "git read-tree"
never had that "no tree is an error" restriction during its entire life.
Having said all that, I don't care that deeply either way myself.
As read-tree is a very basic and low-level Porcelain, if somebody were
using it to empty the index in an existing script, this change would
appear as a regression and hopefully will be caught eventually, and
updating such a script can be made reasonably easy if we want to be
helpful (the error message can suggest running "rm $GIT_DIR/index", for
example).
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Junio C Hamano @ 2009-12-19 4:53 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Jakub Narebski, Johannes Sixt, Sverre Rabbelier, Git Mailing List
In-Reply-To: <7veimrmv3r.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> As read-tree is a very basic and low-level Porcelain, if somebody were
> using it to empty the index in an existing script, this change would
> appear as a regression and hopefully will be caught eventually, and
> updating such a script can be made reasonably easy if we want to be
> helpful (the error message can suggest running "rm $GIT_DIR/index", for
> example).
IOW, I would prefer to queue something like this in the upcoming version,
and then later make it die(). I do not think anybody relies on it, but we
have been wrong before. If the warning doesn't trigger for anybody, that
is also fine as well.
builtin-read-tree.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 2a3a32c..311c489 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -111,6 +111,9 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
argc = parse_options(argc, argv, unused_prefix, read_tree_options,
read_tree_usage, 0);
+ if (!argc)
+ warning("running read-tree without argument to empty the index is deprecated.");
+
newfd = hold_locked_index(&lock_file, 1);
prefix_set = opts.prefix ? 1 : 0;
^ permalink raw reply related
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Eric Blake @ 2009-12-19 5:38 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <4B2C395A.6080300@gmail.com>
According to Stephen Boyd on 12/18/2009 7:24 PM:
>> Nope. You need either "\\015\\n" or '\015\n', since "\015" and "\n"
>> are both
>> undefined in portable shell.
>
> So, how about this?
>
> {
> echo "X-Fake-Field: Line One"&&
> echo "X-Fake-Field: Line Two"&&
> echo "X-Fake-Field: Line Three"&&
> git format-patch --stdout first | sed -e "1d"
> } | sed -e "s/$/;/" | tr "'";"'" "'"\015"'"> patch1-crlf.eml
Syntax error. "$/" is not defined, so the argument to sed is not
portable. Then, following the tr, you have an unquoted ;, meaning you
invoked 'tr "'"', followed by invoking the (non-existent) command '.
>
> Or maybe this?
>
> {
> echo "X-Fake-Field: Line One"&&
> echo "X-Fake-Field: Line Two"&&
> echo "X-Fake-Field: Line Three"&&
> git format-patch --stdout first | sed -e "1d"
> } | sed -e "s/$/;/" | tr ";" "\\015"> patch1-crlf.eml
Closer, but not there yet. "$/" is still not defined. Then, as a matter
of style, '\' is more readable than "\\" for representing a backslash. So
as long as we are shifting to '', we might as well do it everywhere in
that line - write it like this:
} | sed -e 's/$/;/' | tr ';' '\015' > patch1-crlf.eml
and you should be set.
--
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Junio C Hamano @ 2009-12-19 5:55 UTC (permalink / raw)
To: Moe; +Cc: Miklos Vajna, git
In-Reply-To: <4B2C5A1A.8000201@signalbeam.net>
Moe <moe@signalbeam.net> writes:
>> I find the original use case highly moronic.
>>
>> For people to be sharing an account, hence $HOME, there must be a reason.
>> They want to (rather, the administrator wants them to) use a common shared
>> set of settings, so $HOME/.gitconfig should be shared among them, just
>> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason
>> to treat .gitconfig any differently from all the other $HOME/.whatever
>> files. But I don't think there wasn't any argument to defend that.
>
> I'm not arguing to treat .gitconfig differently from other
> dot-files, but to treat it differently from .git/config.
>
> The former is user-specific, the latter is repository-specific.
That is something we already do, like everybody else. $HOME/.emacs is
user specific, /etc/emacs.d/* are site-wide, and "Local Variables:..End:"
section is per-document. Have you asked emacs guys (and vim folks) about
a change similar to the one on topic here? This question is rhetoric and
you do not have to answer it.
>> Wouldn't it be just a matter of giving different HOME after they log-in?
>>
>> After all, Moe will be giving _some_ way to his users set different value
>> to GIT_CONFIG_EXTRA depending on who they really are, and that same
>> mechanism should be usable to set different HOME to them, no?
>
> The individual users are identified by their ssh key. Ssh sets a
> distinct environment variable for each, which in turn is used in
> .bash_profile to read an additional user-profile.
>
> Yes, we could overwrite $HOME but that would defeat the purpose.
> The goal of this setup is to share almost all settings.
You haven't answered the crucial question, and repeating yourself is not
an explanation. I've already said sharing the account is to share things,
you know I understand you want to _share_. I asked why $HOME/.gitconfig
has to be treated differently from others like $HOME/.mailrc, $HOME/.gitk,
etc. that are shared. You are not answering the question.
What makes $HOME/.gitconfig different from $HOME/.ssh/., $HOME/.vimrc, and
all the other things? Why do you want to share all the other dot files,
most of which lack the support for you to do the "set-up" you have to do
in $HOME/.bashrc to switch based on something other than the UID (I would
call that a "set-up", not a "hack", because you have to do that
somewhere)? Why do your users tolerate that they cannot have their own
private $HOME/.rpmmacros nor $HOME/.newsrc but it is not Ok that they have
to share $HOME/.gitconfig with others?
Knowing that is very important for us, as $HOME/.gitconfig will not stay
the only thing you would need to single out with future versions of git.
For example, we have discussed a support for $HOME/.git-excludes that sits
between $GIT_DIR/info/exclude and the file pointed at by core.excludesfile
configuration variable. Should it be shared, or separated? Why?
I do not want to count on you, who I have never seen on this list before,
being around to ask if such a change would break your use case when the
day comes. If we do not know the _criteria_ you are using, the reason why
you want to single out $HOME/.gitconfig when it is Ok for your users to
share $HOME/.vimrc, we will not be able to make good design decisions to
support this "shared account" configuration [*1*]. Will we introduce
GIT_EXCLUDE_EXTRA at the time like Miklos added GIT_CONFIG_EXTRA? Where
does it end?
> I hope this can still make it, considering the small size of
> the patch and the .git/config vs ~/.gitconfig argument.
That is not an argument at all. We handle .git/config vs $HOME/.gitconfig
just fine; see above.
One plausible answer you could have given is that your users do not have
an account in the usual sense of the word at all, and the _only_ thing
they can do with your system is to run git and nothing else. IOW they
have no business with even having $HOME/.vimrc or $HOME/.rhosts, so these
other dotfiles do not matter at all. That makes $HOME/.gitconfig special.
A possible solution might be for us to honor $GIT_HOME that is favoured
over $HOME, just like $GIT_EDITOR overrides $EDITOR. That allows us to
extend the notion more naturally in the future. For example, when we
start reading from $HOME/.git-excludes, if the GIT_HOME environment is
set, we would instead read from $GIT_HOME/.git-excludes. That would be a
much cleaner solution than Miklos's patch [*2*].
But you have given us too little for us to be able to judge what the best
longer-term course of action is. How could you even _hope_ it can "make
it"?
[Footnote]
*1* Of course, before doing so, we need to decide if this "shared account"
configuration makes sense or not to begin with, but you haven't given us
enough to work with to even decide that.
*2* I am not criticizing Miklos's patch in particular. The patch was done
in the same void without any usable information from you what you really
needed, so the lack of provision for future we can see in the patch is not
Miklos's fault. Also he is not the git maintainer and is not used to
worry about the future like I do.
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2009-12-19 6:21 UTC (permalink / raw)
To: Eric Blake; +Cc: git
In-Reply-To: <4B2C66D3.1070508@byu.net>
On 12/18/2009 09:38 PM, Eric Blake wrote:
> Closer, but not there yet. "$/" is still not defined. Then, as a matter
> of style, '\' is more readable than "\\" for representing a backslash. So
> as long as we are shifting to '', we might as well do it everywhere in
> that line - write it like this:
>
> } | sed -e 's/$/;/' | tr ';' '\015'> patch1-crlf.eml
>
> and you should be set.
Ah, I think you missed that this stuff is inside single quotes already.
I would love to just do what you suggest here.
I'm a little confused because I see this in a test (am
--committer-date-is-author-date) a ways down in the same file
git cat-file commit HEAD | sed -e "/^$/q">head1&&
and following your reasoning that wouldn't be portable?
Either way, I'll look for a better replacement character instead of
semi-colon.
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2009-12-19 7:07 UTC (permalink / raw)
To: Eric Blake; +Cc: git
In-Reply-To: <4B2C70ED.1020602@gmail.com>
I found this in t0022
sed -e "s/\$/
^M/" "$TEST_DIRECTORY"/t0022-crlf-rename.sh>elpmas&&
so I'd like to use that if possible.
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Moe @ 2009-12-19 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vzl5fik3o.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Moe <moe@signalbeam.net> writes:
>
>>> I find the original use case highly moronic.
>>>
>>> For people to be sharing an account, hence $HOME, there must be a reason.
>>> They want to (rather, the administrator wants them to) use a common shared
>>> set of settings, so $HOME/.gitconfig should be shared among them, just
>>> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason
>>> to treat .gitconfig any differently from all the other $HOME/.whatever
>>> files. But I don't think there wasn't any argument to defend that.
>> I'm not arguing to treat .gitconfig differently from other
>> dot-files, but to treat it differently from .git/config.
>>
>> The former is user-specific, the latter is repository-specific.
>
> That is something we already do, like everybody else. $HOME/.emacs is
> user specific, /etc/emacs.d/* are site-wide, and "Local Variables:..End:"
> section is per-document. Have you asked emacs guys (and vim folks) about
> a change similar to the one on topic here? This question is rhetoric and
> you do not have to answer it.
>
>>> Wouldn't it be just a matter of giving different HOME after they log-in?
>>>
>>> After all, Moe will be giving _some_ way to his users set different value
>>> to GIT_CONFIG_EXTRA depending on who they really are, and that same
>>> mechanism should be usable to set different HOME to them, no?
>> The individual users are identified by their ssh key. Ssh sets a
>> distinct environment variable for each, which in turn is used in
>> .bash_profile to read an additional user-profile.
>>
>> Yes, we could overwrite $HOME but that would defeat the purpose.
>> The goal of this setup is to share almost all settings.
>
> You haven't answered the crucial question, and repeating yourself is not
> an explanation. I've already said sharing the account is to share things,
> you know I understand you want to _share_. I asked why $HOME/.gitconfig
> has to be treated differently from others like $HOME/.mailrc, $HOME/.gitk,
> etc. that are shared. You are not answering the question.
I refrained from delving deeper into our particular use-case at first,
due to the verbosity and to avoid a potential "git wasn't meant for
this" knockout. But it seems we're over this, so see below.
> What makes $HOME/.gitconfig different from $HOME/.ssh/., $HOME/.vimrc, and
> all the other things? Why do you want to share all the other dot files,
> most of which lack the support for you to do the "set-up" you have to do
> in $HOME/.bashrc to switch based on something other than the UID (I would
> call that a "set-up", not a "hack", because you have to do that
> somewhere)? Why do your users tolerate that they cannot have their own
> private $HOME/.rpmmacros nor $HOME/.newsrc but it is not Ok that they have
> to share $HOME/.gitconfig with others?
>
> Knowing that is very important for us, as $HOME/.gitconfig will not stay
> the only thing you would need to single out with future versions of git.
>
> For example, we have discussed a support for $HOME/.git-excludes that sits
> between $GIT_DIR/info/exclude and the file pointed at by core.excludesfile
> configuration variable. Should it be shared, or separated? Why?
>
> I do not want to count on you, who I have never seen on this list before,
> being around to ask if such a change would break your use case when the
> day comes. If we do not know the _criteria_ you are using, the reason why
> you want to single out $HOME/.gitconfig when it is Ok for your users to
> share $HOME/.vimrc, we will not be able to make good design decisions to
> support this "shared account" configuration [*1*]. Will we introduce
> GIT_EXCLUDE_EXTRA at the time like Miklos added GIT_CONFIG_EXTRA? Where
> does it end?
>
>> I hope this can still make it, considering the small size of
>> the patch and the .git/config vs ~/.gitconfig argument.
>
> That is not an argument at all. We handle .git/config vs $HOME/.gitconfig
> just fine; see above.
>
> One plausible answer you could have given is that your users do not have
> an account in the usual sense of the word at all, and the _only_ thing
> they can do with your system is to run git and nothing else. IOW they
> have no business with even having $HOME/.vimrc or $HOME/.rhosts, so these
> other dotfiles do not matter at all. That makes $HOME/.gitconfig special.
Yes, that's pretty close. What we do is, we put our entire runtime
environment [for a web application] under a dedicated user and under
version control. This is a very comfortable way to maintain an
identical environment across the board, we even deploy this way
to our production servers by the means of a git pull on a
dedicated branch.
In practice our developers will su or ssh to this user to get working
and generally they need only a very small set of divertions from the
common configuration - such as their personal git identity and their
preferred editor settings.
One may argue that a bunch of host-specific symlinks could achieve a
similar effect - and that would be correct - but having literally
everything under version control yields certain advantages that we
wouldn't want to miss. Such as any developer being able to ssh into
the shared user on any host and being right at home (including
properly attributed git commits) without further twiddling.
(that usually comes into play when ssh'ing into a production host,
performing a hotfix and feeding it back)
This all may seem esoteric or even moronic to you. All I can say is
that it's been working extraordinary well for us over the past 2 years,
despite the minor git inconvenience.
> A possible solution might be for us to honor $GIT_HOME that is favoured
> over $HOME, just like $GIT_EDITOR overrides $EDITOR. That allows us to
> extend the notion more naturally in the future. For example, when we
> start reading from $HOME/.git-excludes, if the GIT_HOME environment is
> set, we would instead read from $GIT_HOME/.git-excludes. That would be a
> much cleaner solution than Miklos's patch [*2*].
Sounds like that would serve our case just as well
and yes, probably much cleaner in the long run.
> But you have given us too little for us to be able to judge what the best
> longer-term course of action is. How could you even _hope_ it can "make
> it"?
Well, sorry for being so brief initially. Being not as involved with git
development I based my request on what I figured could be a
sane generalization of our particular problem.
Also I don't mean to blow this out of proportion; it's a minor,
mostly cosmetic inconvenience for us and we can stick to our workarounds
or Miklos' patch if a mainline change shakes
things up too much.
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Junio C Hamano @ 2009-12-19 7:39 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Eric Blake, git
In-Reply-To: <4B2C7B9C.1030404@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> I found this in t0022
>
> sed -e "s/\$/
> ^M/" "$TEST_DIRECTORY"/t0022-crlf-rename.sh>elpmas&&
>
> so I'd like to use that if possible.
That needs fixing; I think we caught something similar from Shawn before
it got in, primarily because the mail path corrupted the message and
turned the literal CR into LF.
^ permalink raw reply
* Query remote repository files, blobs
From: Shakthi Kannan @ 2009-12-19 7:45 UTC (permalink / raw)
To: git
Hi,
>From git-ls-remote:
http://www.kernel.org/pub/software/scm/git/docs/git-ls-remote.html
I am able to query for list of remote heads, and tags. I would like to
know if it is possible to query for information on remote files, or
blobs? Sometimes, I am on a slow Internet connection, and I just want
to be able to see the remote file diffs, or new file, branch
additions, or changes without having to clone the repository.
Appreciate any inputs on this regard,
Thanks!
SK
--
Shakthi Kannan
http://www.shakthimaan.com
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Andreas Schwab @ 2009-12-19 10:26 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Eric Blake, git
In-Reply-To: <4B2C70ED.1020602@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> On 12/18/2009 09:38 PM, Eric Blake wrote:
>> Closer, but not there yet. "$/" is still not defined. Then, as a matter
>> of style, '\' is more readable than "\\" for representing a backslash. So
>> as long as we are shifting to '', we might as well do it everywhere in
>> that line - write it like this:
>>
>> } | sed -e 's/$/;/' | tr ';' '\015'> patch1-crlf.eml
>>
>> and you should be set.
>
> Ah, I think you missed that this stuff is inside single quotes already. I
> would love to just do what you suggest here.
You can replace every use of ' by '\''.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Johannes Schindelin @ 2009-12-19 10:54 UTC (permalink / raw)
To: Moe; +Cc: Junio C Hamano, Miklos Vajna, git
In-Reply-To: <4B2C7EC3.6070501@signalbeam.net>
Hi,
On Sat, 19 Dec 2009, Moe wrote:
> What we do is, we put our entire runtime environment [for a web
> application] under a dedicated user and under version control. This is a
> very comfortable way to maintain an identical environment across the
> board, we even deploy this way to our production servers by the means of
> a git pull on a dedicated branch.
Just ignoring the fact that you version control a version controlled
directory (including the repository), which is inefficient, and even
further ignoring the fact that you open the door for concurrent --
incompatible -- modifications, if all you want to do is:
> In practice our developers will su or ssh to this user to get working
> and generally they need only a very small set of divertions from the
> common configuration - such as their personal git identity and their
> preferred editor settings.
... then I suggest reading up on GIT_EDITOR, GIT_AUTHOR_IDENT and
GIT_COMMITTER_IDENT, and leaving the $HOME/.gitconfig alone.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Johannes Schindelin @ 2009-12-19 10:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Jakub Narebski, Johannes Sixt, Sverre Rabbelier,
Git Mailing List
In-Reply-To: <7vfx77lg2s.fsf@alter.siamese.dyndns.org>
Hi,
On Fri, 18 Dec 2009, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > As read-tree is a very basic and low-level Porcelain, if somebody were
> > using it to empty the index in an existing script, this change would
> > appear as a regression and hopefully will be caught eventually, and
> > updating such a script can be made reasonably easy if we want to be
> > helpful (the error message can suggest running "rm $GIT_DIR/index",
> > for example).
>
> IOW, I would prefer to queue something like this in the upcoming
> version, and then later make it die(). I do not think anybody relies on
> it, but we have been wrong before. If the warning doesn't trigger for
> anybody, that is also fine as well.
I fully expect it not to trigger for anybody (except maybe you, if you
have hidden a script somewhere that uses read-tree to empty the index),
because at least for this developer, the standard way of emptying the
index is simply "rm .git/index".
Ciao,
Dscho
^ permalink raw reply
* Re: Query remote repository files, blobs
From: Johannes Schindelin @ 2009-12-19 11:02 UTC (permalink / raw)
To: Shakthi Kannan; +Cc: git
In-Reply-To: <d16b1c80912182345h4163430bv810adb860575d67a@mail.gmail.com>
Hi,
On Sat, 19 Dec 2009, Shakthi Kannan wrote:
> Hi,
>
> >From git-ls-remote:
> http://www.kernel.org/pub/software/scm/git/docs/git-ls-remote.html
>
> I am able to query for list of remote heads, and tags. I would like to
> know if it is possible to query for information on remote files, or
> blobs?
This has been discussed a number of times, but we cannot allow that for
security reasons. A blob might contain confidential information, in which
case the branch has to be rewritten and force-pushed. However, that does
not make the blob go away, but makes it only unreachable. Until the next
garbage collection kicks in, that is (which you typically cannot control).
So: sorry, your feature request cannot be granted.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Moe @ 2009-12-19 11:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Miklos Vajna, git
In-Reply-To: <alpine.DEB.1.00.0912191150450.4985@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Sat, 19 Dec 2009, Moe wrote:
>
>> What we do is, we put our entire runtime environment [for a web
>> application] under a dedicated user and under version control. This is a
>> very comfortable way to maintain an identical environment across the
>> board, we even deploy this way to our production servers by the means of
>> a git pull on a dedicated branch.
>
> Just ignoring the fact that you version control a version controlled
> directory (including the repository), which is inefficient, and even
> further ignoring the fact that you open the door for concurrent --
> incompatible -- modifications, if all you want to do is:
Neither is true.
>> In practice our developers will su or ssh to this user to get working
>> and generally they need only a very small set of divertions from the
>> common configuration - such as their personal git identity and their
>> preferred editor settings.
>
> ... then I suggest reading up on GIT_EDITOR, GIT_AUTHOR_IDENT and
> GIT_COMMITTER_IDENT, and leaving the $HOME/.gitconfig alone.
Thanks, that solved my problem.
Seems I started by asking the wrong question.
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2009-12-19 11:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Blake, git
In-Reply-To: <7vk4wjfm4s.fsf@alter.siamese.dyndns.org>
On 12/18/2009 11:39 PM, Junio C Hamano wrote:
> Stephen Boyd<bebarino@gmail.com> writes:
>
>> I found this in t0022
>>
>> sed -e "s/\$/
>> ^M/" "$TEST_DIRECTORY"/t0022-crlf-rename.sh>elpmas&&
>>
>> so I'd like to use that if possible.
>>
> That needs fixing; I think we caught something similar from Shawn before
> it got in, primarily because the mail path corrupted the message and
> turned the literal CR into LF
Sorry it looks like my mailer turned the CR into a LF. That should all
be one line.
Are you saying that t0022 needs fixing?
^ permalink raw reply
* [PATCH] rebase -i: abort cleanly if the editor fails to launch
From: Björn Gustavsson @ 2009-12-19 12:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
If the user's configured editor is emacsclient, the editor
will fail to launch if emacs is not running and the git
command that tried to lanuch the editor will abort. For most
commands, all you have to do is to start emacs and repeat
the command.
The "git rebase -i" command, however, aborts without cleaning
the "$GIT_DIR/rebase-merge" directory if it fails to launch the
editor, so you'll need to do "git rebase --abort" before
repeating the rebase command.
Change "git rebase -i" to terminate using "die_abort" (instead of
with "die") if the initial launch of the editor fails.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 0bd3bf7..d529328 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -779,7 +779,7 @@ EOF
cp "$TODO" "$TODO".backup
git_editor "$TODO" ||
- die "Could not execute editor"
+ die_abort "Could not execute editor"
has_action "$TODO" ||
die_abort "Nothing to do"
--
1.6.6.rc3.dirty
^ permalink raw reply related
* Git as electronic lab notebook
From: Thomas Johnson @ 2009-12-19 12:23 UTC (permalink / raw)
To: git
Hello group,
I've been using git on a few different projects over the last couple of months,
and as a former svn user I really like it. Recently, I've been using it as an
'electronic lab notebook' for an empirical project. My workflow looks like this:
1. Start with the stable code base on head
2. Create and change to branch 'Experiment123'
3. Make some changes
4. Run the program, which generates a giant (10MB-4G) output text file,
Experiment123.log. Update my LabNotebook.txt file.
5. Were the new changes helpful?
5.yes: Bzip Experiment123.log, and commit it on the branch. Merge the
Experiment123 branch to head and goto 1.
5.no: Bzip Experiment123.log, and commit it on the branch. Merge LabNotebook.txt
and Experiment123.log back to head. Switch back to head and goto 1.
The thing is, Experiment123.log is going to be very similar to Experiment122.log
and Experiment124.log except for a few details. My understanding is that git is
great at compressing groups of files like this, is that correct? Should I not be
bzipping them myself? On the other hand, I don't want HEAD to contain hundreds
of gigs of uncompressed files that bzip down to only a few hundred megs.
Any thoughts on the workflow itself would also be very welcome.
^ permalink raw reply
* This is to inform you that £1,000,000.00 GBP has been awarded to your Email ID in our Tobacco Xmas Promo Xmas send your details:
From: End Of Year Winner @ 2009-12-19 13:18 UTC (permalink / raw)
Names:..........
Address:........
Tel:...........
^ permalink raw reply
* Re: Query remote repository files, blobs
From: Bill Lear @ 2009-12-19 13:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shakthi Kannan, git
In-Reply-To: <alpine.DEB.1.00.0912191159280.4985@pacific.mpi-cbg.de>
On Saturday, December 19, 2009 at 12:02:02 (+0100) Johannes Schindelin writes:
>On Sat, 19 Dec 2009, Shakthi Kannan wrote:
>...
>> I am able to query for list of remote heads, and tags. I would like to
>> know if it is possible to query for information on remote files, or
>> blobs?
>
>This has been discussed a number of times, but we cannot allow that for
>security reasons. A blob might contain confidential information, in which
>case the branch has to be rewritten and force-pushed. However, that does
>not make the blob go away, but makes it only unreachable. Until the next
>garbage collection kicks in, that is (which you typically cannot control).
Hmm, I thought this had been addressed by git in a different way (removing
confidential information). A company will not be satisfied that its
proprietary information is "unreachable" in your software repository.
They want absolute assurance that the information is completely
removed.
Have I remembered wrongly --- is this still not possible with git?
Bill
^ permalink raw reply
* [PATCH/RFCv2 4/6] gitweb: Makefile improvements
From: Jakub Narebski @ 2009-12-19 13:32 UTC (permalink / raw)
To: J.H.; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <200912111741.51760.jnareb@gmail.com>
From: John 'Warthog9' Hawley <warthog9@kernel.org>
This commit adjust the main Makefile so you can simply run
make gitweb
which in turn calls gitweb/Makefile. This means that in order to
generate gitweb, you can simply run 'make' from gitweb subdirectory:
cd gitweb
make
Targets gitweb/gitweb.cgi and (dependent on JSMIN being defined)
gitweb/gitweb.min.js in main Makefile are preserved for backward
compatibility.
Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This implements separate Makefile for gitweb, with main Makefile calling
it, like for gitk-git/, git-gui/, Documentation/, t/, and templates/
directories.
It is marked as RFC because I don't feel that my make-fu is strong enough
to be sure that there are no errors / mistakes. Very slightly tested.
Makefile | 64 +++++----------------------
gitweb/Makefile | 129 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 141 insertions(+), 52 deletions(-)
create mode 100644 gitweb/Makefile
diff --git a/Makefile b/Makefile
index 4a1e5bc..50d815e 100644
--- a/Makefile
+++ b/Makefile
@@ -280,29 +280,6 @@ pathsep = :
# JavaScript minifier invocation that can function as filter
JSMIN =
-# default configuration for gitweb
-GITWEB_CONFIG = gitweb_config.perl
-GITWEB_CONFIG_SYSTEM = /etc/gitweb.conf
-GITWEB_HOME_LINK_STR = projects
-GITWEB_SITENAME =
-GITWEB_PROJECTROOT = /pub/git
-GITWEB_PROJECT_MAXDEPTH = 2007
-GITWEB_EXPORT_OK =
-GITWEB_STRICT_EXPORT =
-GITWEB_BASE_URL =
-GITWEB_LIST =
-GITWEB_HOMETEXT = indextext.html
-GITWEB_CSS = gitweb.css
-GITWEB_LOGO = git-logo.png
-GITWEB_FAVICON = git-favicon.png
-ifdef JSMIN
-GITWEB_JS = gitweb.min.js
-else
-GITWEB_JS = gitweb.js
-endif
-GITWEB_SITE_HEADER =
-GITWEB_SITE_FOOTER =
-
export prefix bindir sharedir sysconfdir
CC = gcc
@@ -1509,6 +1486,11 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
chmod +x $@+ && \
mv $@+ $@
+
+.PHONY: gitweb
+gitweb:
+ $(QUIET_SUBDIR0)gitweb $(QUIET_SUBDIR1) all
+
ifdef JSMIN
OTHER_PROGRAMS += gitweb/gitweb.cgi gitweb/gitweb.min.js
gitweb/gitweb.cgi: gitweb/gitweb.perl gitweb/gitweb.min.js
@@ -1516,30 +1498,13 @@ else
OTHER_PROGRAMS += gitweb/gitweb.cgi
gitweb/gitweb.cgi: gitweb/gitweb.perl
endif
- $(QUIET_GEN)$(RM) $@ $@+ && \
- sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
- -e 's|++GIT_VERSION++|$(GIT_VERSION)|g' \
- -e 's|++GIT_BINDIR++|$(bindir)|g' \
- -e 's|++GITWEB_CONFIG++|$(GITWEB_CONFIG)|g' \
- -e 's|++GITWEB_CONFIG_SYSTEM++|$(GITWEB_CONFIG_SYSTEM)|g' \
- -e 's|++GITWEB_HOME_LINK_STR++|$(GITWEB_HOME_LINK_STR)|g' \
- -e 's|++GITWEB_SITENAME++|$(GITWEB_SITENAME)|g' \
- -e 's|++GITWEB_PROJECTROOT++|$(GITWEB_PROJECTROOT)|g' \
- -e 's|"++GITWEB_PROJECT_MAXDEPTH++"|$(GITWEB_PROJECT_MAXDEPTH)|g' \
- -e 's|++GITWEB_EXPORT_OK++|$(GITWEB_EXPORT_OK)|g' \
- -e 's|++GITWEB_STRICT_EXPORT++|$(GITWEB_STRICT_EXPORT)|g' \
- -e 's|++GITWEB_BASE_URL++|$(GITWEB_BASE_URL)|g' \
- -e 's|++GITWEB_LIST++|$(GITWEB_LIST)|g' \
- -e 's|++GITWEB_HOMETEXT++|$(GITWEB_HOMETEXT)|g' \
- -e 's|++GITWEB_CSS++|$(GITWEB_CSS)|g' \
- -e 's|++GITWEB_LOGO++|$(GITWEB_LOGO)|g' \
- -e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \
- -e 's|++GITWEB_JS++|$(GITWEB_JS)|g' \
- -e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
- -e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
- $< >$@+ && \
- chmod +x $@+ && \
- mv $@+ $@
+ $(QUIET_SUBDIR0)gitweb $(QUIET_SUBDIR1) $(patsubst gitweb/%,%,$@)
+
+ifdef JSMIN
+gitweb/gitweb.min.js: gitweb/gitweb.js
+ $(QUIET_SUBDIR0)gitweb $(QUIET_SUBDIR1) $(patsubst gitweb/%,%,$@)
+endif # JSMIN
+
git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css gitweb/gitweb.js
$(QUIET_GEN)$(RM) $@ $@+ && \
@@ -1566,11 +1531,6 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh
mv $@+ $@
endif # NO_PERL
-ifdef JSMIN
-gitweb/gitweb.min.js: gitweb/gitweb.js
- $(QUIET_GEN)$(JSMIN) <$< >$@
-endif # JSMIN
-
configure: configure.ac
$(QUIET_GEN)$(RM) $@ $<+ && \
sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
diff --git a/gitweb/Makefile b/gitweb/Makefile
new file mode 100644
index 0000000..c9eb1ee
--- /dev/null
+++ b/gitweb/Makefile
@@ -0,0 +1,129 @@
+# The default target of this Makefile is...
+all::
+
+# Define V=1 to have a more verbose compile.
+#
+# Define JSMIN to point to JavaScript minifier that functions as
+# a filter to have gitweb.js minified.
+#
+
+prefix ?= $(HOME)
+bindir ?= $(prefix)/bin
+RM ?= rm -f
+
+# JavaScript minifier invocation that can function as filter
+JSMIN ?=
+
+# default configuration for gitweb
+GITWEB_CONFIG = gitweb_config.perl
+GITWEB_CONFIG_SYSTEM = /etc/gitweb.conf
+GITWEB_HOME_LINK_STR = projects
+GITWEB_SITENAME =
+GITWEB_PROJECTROOT = /pub/git
+GITWEB_PROJECT_MAXDEPTH = 2007
+GITWEB_EXPORT_OK =
+GITWEB_STRICT_EXPORT =
+GITWEB_BASE_URL =
+GITWEB_LIST =
+GITWEB_HOMETEXT = indextext.html
+GITWEB_CSS = gitweb.css
+GITWEB_LOGO = git-logo.png
+GITWEB_FAVICON = git-favicon.png
+ifdef JSMIN
+GITWEB_JS = gitweb.min.js
+else
+GITWEB_JS = gitweb.js
+endif
+GITWEB_SITE_HEADER =
+GITWEB_SITE_FOOTER =
+
+# include user config
+-include ../config.mak.autogen
+-include ../config.mak
+
+# determine version
+../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
+ $(QUIET_SUBDIR0)../ $(QUIET_SUBDIR1) GIT-VERSION-FILE
+
+-include ../GIT-VERSION-FILE
+
+### Build rules
+
+SHELL_PATH ?= $(SHELL)
+PERL_PATH ?= /usr/bin/perl
+
+# Shell quote;
+bindir_SQ = $(subst ','\'',$(bindir)) #'
+SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH)) #'
+PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH)) #'
+
+# Quiet generation (unless V=1)
+QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
+QUIET_SUBDIR1 =
+
+ifneq ($(findstring $(MAKEFLAGS),w),w)
+PRINT_DIR = --no-print-directory
+else # "make -w"
+NO_SUBDIR = :
+endif
+
+ifneq ($(findstring $(MAKEFLAGS),s),s)
+ifndef V
+ QUIET = @
+ QUIET_GEN = $(QUIET)echo ' ' GEN $@;
+ QUIET_SUBDIR0 = +@subdir=
+ QUIET_SUBDIR1 = ;$(NO_SUBDIR) echo ' ' SUBDIR $$subdir; \
+ $(MAKE) $(PRINT_DIR) -C $$subdir
+ export V
+ export QUIET
+ export QUIET_GEN
+ export QUIET_SUBDIR0
+ export QUIET_SUBDIR1
+endif
+endif
+
+all:: gitweb.cgi
+
+ifdef JSMIN
+FILES=gitweb.cgi gitweb.min.js
+gitweb.cgi: gitweb.perl gitweb.min.js
+else # !JSMIN
+FILES=gitweb.cgi
+gitweb.cgi: gitweb.perl
+endif # JSMIN
+
+gitweb.cgi:
+ $(QUIET_GEN)$(RM) $@ $@+ && \
+ sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ -e 's|++GIT_VERSION++|$(GIT_VERSION)|g' \
+ -e 's|++GIT_BINDIR++|$(bindir)|g' \
+ -e 's|++GITWEB_CONFIG++|$(GITWEB_CONFIG)|g' \
+ -e 's|++GITWEB_CONFIG_SYSTEM++|$(GITWEB_CONFIG_SYSTEM)|g' \
+ -e 's|++GITWEB_HOME_LINK_STR++|$(GITWEB_HOME_LINK_STR)|g' \
+ -e 's|++GITWEB_SITENAME++|$(GITWEB_SITENAME)|g' \
+ -e 's|++GITWEB_PROJECTROOT++|$(GITWEB_PROJECTROOT)|g' \
+ -e 's|"++GITWEB_PROJECT_MAXDEPTH++"|$(GITWEB_PROJECT_MAXDEPTH)|g' \
+ -e 's|++GITWEB_EXPORT_OK++|$(GITWEB_EXPORT_OK)|g' \
+ -e 's|++GITWEB_STRICT_EXPORT++|$(GITWEB_STRICT_EXPORT)|g' \
+ -e 's|++GITWEB_BASE_URL++|$(GITWEB_BASE_URL)|g' \
+ -e 's|++GITWEB_LIST++|$(GITWEB_LIST)|g' \
+ -e 's|++GITWEB_HOMETEXT++|$(GITWEB_HOMETEXT)|g' \
+ -e 's|++GITWEB_CSS++|$(GITWEB_CSS)|g' \
+ -e 's|++GITWEB_LOGO++|$(GITWEB_LOGO)|g' \
+ -e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \
+ -e 's|++GITWEB_JS++|$(GITWEB_JS)|g' \
+ -e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
+ -e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
+ $< >$@+ && \
+ chmod +x $@+ && \
+ mv $@+ $@
+
+ifdef JSMIN
+gitweb.min.js: gitweb.js
+ $(QUIET_GEN)$(JSMIN) <$< >$@
+endif # JSMIN
+
+clean:
+ $(RM) $(FILES)
+
+.PHONY: all clean .FORCE-GIT-VERSION-FILE
--
1.6.5.3
^ permalink raw reply related
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