* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-19 16:28 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0707191715000.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Here a short description, which you should read until you understand
> it and then leave me alone:
>
> To add a directory to the tracked content, you have to _mark_ it as
> tracked. So that when you remove the _real_ content of the
> directory, Git will not remove it.
Correct. That is what my proposal is about.
> Alas, we already have such a marker. It is called ".gitignore", and
> has been ignored by _you_. There is _nothing_ wrong, from a
> technical standpoint, to call this marker ".gitignore", and it is
> _also_ not wrong to put this marker into the file system _in
> addition_ to the index.
Uh, then the directories are no longer empty.
> So go and add your directories via that marker, and _be done with
> it_.
But one is not done before running
find -name .gitignore -delete
and then the next recursive add will remove the .gitignore "markers".
The idea of "." is to have a marker that does _not_ appear in the work
directory.
--
David Kastrup
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Matthieu Moy @ 2007-07-19 16:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Gernhardt, David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0707191642270.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> More and more I get the impression that this thread is just not worth it.
> The problem was solved long ago, and all that is talked about here is how
> to complicate things.
The problem was not _solved_, it was _worked around_.
Adding a .gitignore or whatever other file to mean "the directory
exists" is clearly a good workaround, but still, you have to use
"git-add $dir/.gitignore" where you really _mean_ "git-add $dir/". I
can see no reason for the presence of this .gitignore file other than
"err, I've put it here because git doesn't manage empty directories".
The fact that you need a FAQ entry for that actually shows there is a
problem. You don't have a FAQ for "Q: How to I add a file? A: Use
git-add file", you shouldn't need a FAQ for "How do I add a
directory", it should just work as expected.
You claim it "solves" the problem, but have you ever used an importer
like git-svn on a project that uses empty directories as placeholders
(I do have this problem in daily life because my colleagues still use
SVN)? What is the meaning of this .gitignore file the day you export
it to anything outside git?
If you ignore problems because they have a workaround, then even CVS
can be usable. People have been working around CVS's problems for
years, and many people are happy with CVS because they didn't realise
that solving problems is better than working around them (See the
OpenCVS project ...). Fortunately, git doesn't have as many problems
to work around as CVS ;-).
I'm happy with the answer "it should be done, but not by me, send a
patch", and I can't really complain myself since I did not send a
patch, but here, you're complaining about someone who actually starts
volunteering to solve the problem, which I can't agree with.
--
Matthieu
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-19 16:21 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0707191642270.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 19 Jul 2007, Brian Gernhardt wrote:
>
>>
>> On Jul 19, 2007, at 8:24 AM, David Kastrup wrote:
>>
>> > I think that the placeholder name should rather be ".".
>>
>> For what it's worth, the more this gets discussed, the more I think your
>> idea is a good one.
>
> I do not like it at all. "." already has a very special meaning. It is a
> _directory_, no place holder.
And this is what it will be under my scheme: a directory. It is just
that "directory" is differentiated from a "tree". Both are tracked in
the repository (directory tracking is optional), and there is no such
thing as an empty tree, a tree being defined by its contents and
nothing else, as previously. A "directory" has no contents, but only
existence in index and repository. A "tree" only exists in the
repository, not in index or work directory. It is mapped to physical
directories in the work directory. If no corresponding "directory"
exists in index and/or repository, the work directories are created
and deleted on the fly as before in order to represent the state of
the "tree" in the repository. So here are the concepts:
entity working directory index repository
--------------------------------------------------------------
file mapped to files file [blob]
dir mapped to dir existence dir [dir]
tree mapped to dir tree unrepresented [tree] (non-empty container)
> More and more I get the impression that this thread is just not
> worth it. The problem was solved long ago, and all that is talked
> about here is how to complicate things.
I disagree on both accounts: that the problem has been solved (the
existence of a workaround involving constant manual intervention is
not a solution for me), and that my proposal will constitute a
complication to the user.
For projects setting a "." into the top level .gitignore, nothing at
all will change, even when "core.adddirs: true" will become the
default at some point of time. Once this is the default, new users
with new projects will not notice anything surprising, at least until
the time that they pull from somebody with a repository with different
non-explicit conventions.
This is something which may still require thought in order to result
in the least complicated handling of cooperation. But with regard to
the internals itself, I don't see that there is too much non-obvious
complexity involved here, and the framework appears very consistent,
logical, and compatible with git's ideas to me.
--
David Kastrup
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Johannes Schindelin @ 2007-07-19 16:17 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <6C96EBA9-CDCE-40EA-B0EC-F9195DBE83DB@silverinsanity.com>
Hi,
On Thu, 19 Jul 2007, Brian Gernhardt wrote:
> On Jul 19, 2007, at 11:43 AM, Johannes Schindelin wrote:
>
> > I do not like it at all. "." already has a very special meaning. It
> > is a _directory_, no place holder.
>
> And we're talking about using it to describe the directory.
>
> > More and more I get the impression that this thread is just not worth
> > it. The problem was solved long ago, and all that is talked about here
> > is how to complicate things.
>
> By solved, you mean ignored? There is no reason for git not to track
> empty directories other than "we don't like it".
No, no, no, no, no!
You are really trying to annoy me, right?
Here a short description, which you should read until you understand it
and then leave me alone:
To add a directory to the tracked content, you have to _mark_ it as
tracked. So that when you remove the _real_ content of the directory, Git
will not remove it.
Alas, we already have such a marker. It is called ".gitignore", and has
been ignored by _you_. There is _nothing_ wrong, from a technical
standpoint, to call this marker ".gitignore", and it is _also_ not wrong
to put this marker into the file system _in addition_ to the index.
So go and add your directories via that marker, and _be done with it_.
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Brian Gernhardt @ 2007-07-19 16:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0707191642270.14781@racer.site>
On Jul 19, 2007, at 11:43 AM, Johannes Schindelin wrote:
> I do not like it at all. "." already has a very special meaning.
> It is a
> _directory_, no place holder.
And we're talking about using it to describe the directory.
> More and more I get the impression that this thread is just not
> worth it.
> The problem was solved long ago, and all that is talked about here
> is how
> to complicate things.
By solved, you mean ignored? There is no reason for git not to track
empty directories other than "we don't like it".
Some projects I work on require certain directories to exist in order
to run properly, but tend to occasionally do things like delete all
files in this required directory. So far, it hasn't been an issue
because I'm working solo and using git just to bar against
stupidity. Git's policy of "don't touch things I don't know about"
works. But if I ever had to have someone clone it, they'd need to re-
create the directories. In this case, empty directories are part of
the content I care about. Yes, I could have a script do it, but
that's a work around, not a solution.
In another case, I'm using creating a git repository out of source
that is distributed as occasional tarballs with patches in between.
Git's lack of ability to track the empty directories means that I can
NOT re-create appropriate tarballs for the states distributed only as
patches. Yes, I could add placeholder files, but then the state is
not identical.
There are use cases for tracking directories. I'll agree that it
shouldn't be used for every source tree. But there are cases where
it is useful and there's no reason to simply forbid it.
~~ Brian
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Brian Gernhardt @ 2007-07-19 15:50 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86ejj45s8i.fsf@lola.quinscape.zz>
On Jul 19, 2007, at 11:27 AM, David Kastrup wrote:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> My apologies for the wasted bandwidth arguing for things that had
>> already been decided.
>
> "decided"! Now that's a strong word for my wild brainstorming if I
> ever heard one, in particular considering my well-near non-existent
> record of contributions and popularity here: most of the recent
> "discussion" has been me following up on myself.
Meh. I suppose I meant "talked about" or "brought up" here. Trying
to be quick and terse, and ended up losing meaning like usual.
~~ Brian
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Johannes Schindelin @ 2007-07-19 15:43 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: David Kastrup, git
In-Reply-To: <7FE87F7A-53AD-4B92-8F33-ECDFAE6A7EFB@silverinsanity.com>
Hi,
On Thu, 19 Jul 2007, Brian Gernhardt wrote:
>
> On Jul 19, 2007, at 8:24 AM, David Kastrup wrote:
>
> > I think that the placeholder name should rather be ".".
>
> For what it's worth, the more this gets discussed, the more I think your
> idea is a good one.
I do not like it at all. "." already has a very special meaning. It is a
_directory_, no place holder.
More and more I get the impression that this thread is just not worth it.
The problem was solved long ago, and all that is talked about here is how
to complicate things.
Unhappy,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-19 15:27 UTC (permalink / raw)
To: git
In-Reply-To: <FA38709A-7C68-4D66-BA26-B5ED49DFA85A@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> On Jul 19, 2007, at 10:40 AM, David Kastrup wrote:
>
>> Have you synched with the current state of my proposals posted to the
>> mailing list before posting this note? Perhaps your concerns have
>> already been addressed in them.
>
> Mail.app split the thread into two or three pieces. I wrote this
> after reading the first part, but had missed the rest. I very much
> like the proposals of separating trees from directories and the "."
> entries.
>
> My apologies for the wasted bandwidth arguing for things that had
> already been decided.
"decided"! Now that's a strong word for my wild brainstorming if I
ever heard one, in particular considering my well-near non-existent
record of contributions and popularity here: most of the recent
"discussion" has been me following up on myself.
Anyway, thanks for the heads-up: very much appreciated. I'll probably
badly need it when people in Pacific Standard Time get to work again
and tear me to pieces.
--
David Kastrup
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Brian Gernhardt @ 2007-07-19 15:08 UTC (permalink / raw)
To: David Kastrup
Cc: Shawn O.Pearce, Junio C Hamano, Linus Torvalds, Matthieu Moy,
Johannes Schindelin, Git Mailing List
In-Reply-To: <863azk78yp.fsf@lola.quinscape.zz>
On Jul 19, 2007, at 10:40 AM, David Kastrup wrote:
> Have you synched with the current state of my proposals posted to the
> mailing list before posting this note? Perhaps your concerns have
> already been addressed in them.
Mail.app split the thread into two or three pieces. I wrote this
after reading the first part, but had missed the rest. I very much
like the proposals of separating trees from directories and the "."
entries.
My apologies for the wasted bandwidth arguing for things that had
already been decided.
~~ Brian
^ permalink raw reply
* Re: [PATCH (REVISED)] Add core.editor configuration variable
From: Andy Parkins @ 2007-07-19 14:52 UTC (permalink / raw)
To: git; +Cc: Brian Gernhardt, Adam Roben, Junio C Hamano
In-Reply-To: <95E642DA-F848-4398-9D9D-52B03A235887@silverinsanity.com>
On Thursday 2007 July 19, Brian Gernhardt wrote:
> As far as [core] being only for plumbing, I disagree with that
> premise as well. Any option that is used across many of the git
> commands is a core (meaning central) option.
Fair enough. With the definition core != plumbing; my argument has no weight.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Brian Gernhardt @ 2007-07-19 14:44 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86wswwa8ej.fsf@lola.quinscape.zz>
On Jul 19, 2007, at 8:24 AM, David Kastrup wrote:
> I think that the placeholder name should rather be ".".
For what it's worth, the more this gets discussed, the more I think
your idea is a good one.
~~ Brian
^ permalink raw reply
* Re: [PATCH] Document how to tell git to not launch a pager
From: Brian Gernhardt @ 2007-07-19 14:38 UTC (permalink / raw)
To: martin f krafft; +Cc: git
In-Reply-To: <20070719110224.GA4293@piper.oerlikon.madduck.net>
On Jul 19, 2007, at 7:02 AM, martin f krafft wrote:
> +1 on the patch, but I also wonder why use of a pager is default in
> git anyway. At least I find it to be contrary to what I am used to
> on the Unix command line.
>
> For reference, there was an argument about this in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424978, which
> includes a long IRC log in German, unfortunately, where a bunch of
> people agreed with my proposal *not* to use a pager by default,
> since it makes it difficult to use information from the output to
> assemble the next command on the command line. Every terminal in use
> nowadays can easily scroll and even search back 250 lines with the
> added benefit of not randomly clearing the screen when you quit
> $PAGER.
I think it's because much of the core git community lives more on the
console or simple terminals like xterm than in something with easy
search and scrolling features like konsole or Terminal.app. Git
output tends to become very long very quickly, and usually you want
to start reading from the beginning.
Many command line tools either output small chunks of input (ls, in
most directories), output slowly (make), or their input is mostly
only important when it errors out (make). Git's output tends to be
quite long and have the most relevant (read: recent) information at
the beginning so paging is pretty much a must, instead of an
occasional need.
If someone thinks that git paging by default is obnoxious, it just
takes running "git config --global core.pager cat". Now, no more
paging. If you find your $PAGER clearing the screen when quitting
obnoxious, I suggest checking your configuration. In particular, I
find setting $LESS to "FX" (at least) to be most useful.
~~ Brian
^ permalink raw reply
* Re: [REVISED PATCH 2/6] Introduce commit notes
From: Andy Parkins @ 2007-07-19 14:33 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Junio C Hamano, Linus Torvalds,
Alberto Bertogli, Johan Herland
In-Reply-To: <Pine.LNX.4.64.0707191209200.14781@racer.site>
On Thursday 2007 July 19, Johannes Schindelin wrote:
> > In the case of the notes system, is there not a big hole available
> > because the layout is under tight control?
>
> No. It is a tree object, referenced from a ref. You can always check it
> out, modify it, and check it in. If only by mistake.
I was arguing for the tree-index being special cased though (ideally with an
invalid filename), such that it could never actually be checked out or
checked in, but would be maintained automatically "git-side". For backwards
compatibility, it would be optional; and making it an invalid filename
It was only a suggestion to answer Junio's request for a "hole" through which
a tree-object index could be poked.
If we're only talking about the notes tree, then would it matter that it could
be checked out and checked in? If someone chose to do that then it would be
their own fault when the index didn't work. If I wanted I could
edit .git/objects/ directly - I wouldn't expect poor git to work correctly
afterwards though.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH (REVISED)] Add core.editor configuration variable
From: Brian Gernhardt @ 2007-07-19 14:24 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Adam Roben, Junio C Hamano
In-Reply-To: <200707190848.54655.andyparkins@gmail.com>
On Jul 19, 2007, at 3:48 AM, Andy Parkins wrote:
> On Thursday 2007 July 19, Adam Roben wrote:
>
>> Well, it turns out we already do launch an editor in other places,
>> namely "git am -i" and "git send-email --compose". So, this patch
>> takes
>> care of those cases as well.
>
> Perhaps I'm being overly pedantic, but it seems odd to put options
> that are
> relevant only to porcelain under the "core" section.
>
> core.pager is in the same category - but that's already in.
Since I'm the one who added that, I feel compelled to add in my $0.02.
First, there wasn't much argument on the list when core.pager was
added... But that's not my major point.
To many git users (myself included), claiming that commands like git-
commit, git-log, and other "porcelain" isn't part of "core" git is
ridiculous. These are the commands that I use every day, and are a
part of the main git package, source, and repository. If the
porcelain was maintained separately from the pluming, like cognito
was, perhaps that would be a more compelling argument to me.
For many people commit is more "core" to their git usage than write-
tree and commit-tree. At this point, it's less an extra layer
porcelain and more the standard interface. It's a result of the
wonderful attempts to make git more user friendly.
As far as [core] being only for plumbing, I disagree with that
premise as well. Any option that is used across many of the git
commands is a core (meaning central) option.
~~ Brian
^ permalink raw reply
* Re: [PATCH (REVISED)] Add core.editor configuration variable
From: Andy Parkins @ 2007-07-19 14:23 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Adam Roben, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0707191213300.14781@racer.site>
On Thursday 2007 July 19, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 19 Jul 2007, Andy Parkins wrote:
> > On Thursday 2007 July 19, Johannes Schindelin wrote:
> > > On Thu, 19 Jul 2007, Andy Parkins wrote:
> > > > Would porcelain.editor be a better name for this variable?
> > >
> > > From my point of view you can put into "myWonderfulGit.editor". It
> > > does not matter.
> >
> > By that argument, why do we bother with subsections at all. In fact why
> > not call the variable "xhxhxjjjll.yqlaoospsp"?
>
> No. I said, and I quote here, "From my point of view".
That doesn't change my point - these things are named to give meaning, they
aren't just arbitrary strings of characters.
> And how would having "core.pager" but "porcelain.editor" be easier to
> remember? Nah, not really.
If there is no difference, then do you object so strongly?
Besides, memory isn't just about having words, it's about meaning too.
Categorisation and hierarchy are important. If I'm searching my brain for a
function that does something to strings then the fact that it starts
with "str" gets me a long way there. The fact that they _all_ start
with "str" is what's important.
I don't care _that_ strongly; just like you it won't make any difference to me
personally as I'll cope either way. I'm trying to think like a noob, and it
seems that coherency is broken when we make distinctions between porcelain
and plumbing and then don't stick to them in the config file.
Perhaps I am wrong in my assumption: I have always thought of core.* options
being those options which apply to plumbing - i.e. if I were a git-guru and
did everything with plumbing I would still need those options.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-19 13:21 UTC (permalink / raw)
To: git
In-Reply-To: <86bqe8a7ql.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Although it would be natural to have
>> core.adddirs: false
>> be equivalent to
>> core.excludefile: .
>>
>> And so it might be possible to actually not need a separate
>> core.adddirs option at all, technically.
>
> To followup on myself here:
>
> A project such as the linux kernel which presumably does not want to
> have directories tracked will put the single pattern
> .
> into its top-level .gitignore file. That is all. At least if it does
> not confuse current versions of git to do ugly things.
Another followup: it doesn't. I placed a single line
.
into a .gitignore file. This did not cause git to ignore the contents
of ., and even
git-add .
worked as previously, namely adding the contents of the current
directory and subdirectories to the index.
In short: the gitignore idea for policing directory management is
perfectly upwards-compatible with current versions of git.
--
David Kastrup
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-19 12:46 UTC (permalink / raw)
To: git
In-Reply-To: <20070719123214.GB4929@moonlight.home>
Tomash Brechko <tomash.brechko@gmail.com> writes:
> Hi David,
>
> On Thu, Jul 19, 2007 at 13:31:50 +0200, David Kastrup wrote:
>> core.excludefile: .
>
> Really nice idea to give directories 'DIR/.' name. I'm sure there are
> several other ways to implement your proposal. But why to put in in
> Git itself? Decomposition and abstraction principle tells me that
> this should go to some other place.
Because of a fundamental law of computation: information maintained in
two separate places will get out of synch eventually.
> Please consider this: I myself use Git to track my own local
> projects, and for this usage you proposal have no value for me,
> i.e. as a _Source_ Code Management system Git is rather complete.
> But I also track /etc and ~/ in Git, and for this I'd love to have
> directories, permissions, ownership, other attributes, to be
> tracked. I have Perl script wrapping Git that allows me to filter
> tracked paths by full regexps instead of Git's file globs, and also
> to filter out too big files assuming that they are binary anyway.
Look, git _tracks_ contents. Your permissions managements needs to be
told explicitly when and how things change. So you end up with git
_tracking_ material and your permissions/directory management needing
the level of manual handholding Subversion demands.
> And my point is that rather than building the support for all of it
> into core Git, and then implementing sophisticated configuration to
> disable parts of it, wouldn't it be better to have a separate tools
> orthogonal to Git itself?
And my personal answer to that is "no". We don't want orthogonality
for intimately related things, because it forces us to work the
"orthogonal" things in lockstep. And if you force git to operate in
lockstep with manual explicit tracking, then git becomes useless for
tracking stuff automatically.
> So the essence of my objection is that we should not pollute core
> Git with file system state tracking more than it's required to know
> where to put the contents to. Everything else should go elsewhere.
>
> Again, I'd love to have your proposal be implemented, but only in a
> way that won't interfere with pure SCM's operations.
Tell git to ignore "." and it won't "interfere".
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] gitweb: snapshot cleanups & support for offering multiple formats
From: Jakub Narebski @ 2007-07-19 9:14 UTC (permalink / raw)
To: Matt McCutchen; +Cc: Junio C Hamano, git, Petr Baudis, Luben Tuikov
In-Reply-To: <1184699486.9831.7.camel@mattlaptop2>
On Tue, 17 July 2007, Matt McCutchen wrote:
> sub feature_snapshot {
> - my ($ctype, $suffix, $command) = @_;
> + my (@fmts) = @_;
>
> my ($val) = git_get_project_config('snapshot');
>
> - if ($val eq 'gzip') {
> - return ('x-gzip', 'gz', 'gzip');
> - } elsif ($val eq 'bzip2') {
> - return ('x-bzip2', 'bz2', 'bzip2');
> - } elsif ($val eq 'zip') {
> - return ('x-zip', 'zip', '');
> - } elsif ($val eq 'none') {
> - return ();
> + if ($val) {
> + @fmts = ($val eq 'none' ? () : split /,/, $val);
> + @fmts = map $known_snapshot_format_aliases{$_} || $_, @fmts;
> + @fmts = grep exists $known_snapshot_formats{$_}, @fmts;
> }
>
> - return ($ctype, $suffix, $command);
> -}
I would use more permissive (be forbidding in what you accept) regexp
to split gitweb.snapshot value into list of snapshot formats, so one
could use "tgz, zip", or perhaps even "tgz zip", and not only "tgz,zip"
(no whitespace possible). For example
+ @fmts = ($val eq 'none' ? () : split(/\s*,\s*/, $val));
or even
+ @fmts = ($val eq 'none' ? () : split(/\s*[,\s]\s*/, $val));
to allow "tgz zip".
Your regexp for "tgz, zip" would get 'tgz', ' zip' (with leading space)
as snapshot formats to use.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: snapshot cleanups & support for offering multiple formats
From: Jakub Narebski @ 2007-07-19 9:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matt McCutchen, git, Petr Baudis, Luben Tuikov
In-Reply-To: <7vvech42nb.fsf@assigned-by-dhcp.cox.net>
On Thu, 19 July 2007, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> On Tue, 17 July 2007, Matt McCutchen napisał:
>> ...
>>> Alert for gitweb site administrators: This patch changes the format of
>>> $feature{'snapshot'}{'default'} in gitweb_config.perl from a list of
>>> three pieces of information about a single format to a list of one or
>>> more formats you wish to offer from the set ('tgz', 'tbz2', 'zip').
>>> Update your gitweb_config.perl appropriately. The preferred names for
>>> gitweb.snapshot in repository configuration have also changed from
>>> 'gzip' and 'bzip2' to 'tgz' and 'tbz2', but the old names are still
>>> recognized for compatibility.
>>
>> This alert/warning should probably be put in RelNotes for when it would
>> be in git.git
>
> Does anybody else worry about the backward imcompatibility, I
> wonder... List?
>
> I really hate to having to say something like that in the
> RelNotes. I do not think this is a good enough reason to break
> existing configurations; I would not want to be defending that
> change.
[...]
> I am wondering if something like this patch (totally untested,
> mind you) to convert the old style %feature in configuration at
> the site at runtime would be sufficient.
Would it be sufficient to put above alert/warning in commit message,
RelNotes and gitweb/INSTALL (or gitweb/README), and add rule to Makefile
to convert old configuration, or at least check if GITWEB_CONFIG uses
old snapshot configuration? This way if somebody is installing/upgrading
gitweb by hand he/she would know what needs possibly to be changes, and
if somebody uses "make gitweb/gitweb.cgi" he would get big fat warning,
and info how to convert gitweb config.
By the way, I think it was a mistake to use different syntax in the
%feature hash ([content-encoding, suffix, program]) than in repo config
override (name).
Besides the proposed patch incurs performance penalty for all feature
checks, not only for snapshot. I think it could be solved by using
a hack of providing more aliases, so that 'gzip' (repo config) but
also 'x-gzip', 'gz' and 'gzip' (gitweb config) would be aliases to
'tgz' snapshot, and we would perform "uniq" on the list of snapshot
formats (assuming it is sorted). Or make 'x-gzip' and 'gz' aliases
into undef, so 'gzip' from old configuration would be aliased to the
new format name 'tgz'. What do you think about this?
Ooops, this has disadvantage of having to guess what could be put
in the gitweb config regarding snapshot configuration, but I think we
could assume that only the values enumerated in the old feature_snapshot
would be used.
All said, I think it is a good change. I guess that gitweb admins would
want to provide both tgz/tar.gz archives for the Unix crowd, and zip
archives for MS Windows users...
P.S. I wonder why git-archive does not support tgz format. Git is linked
to zlib, so...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Install man3 manpages to $PREFIX/share/man/man3 even for site installs
From: martin f. krafft @ 2007-07-19 12:45 UTC (permalink / raw)
To: git
MakeMaker supports three installation modes: perl, site, and vendor. The first
and third install manpages to $PREFIX/share/man, only site installs to
$PREFIX/man. For consistency with the rest of git, which does not make the
distinction and writes all manpages to $PREFIX/share/man, this change makes
sure that perl does too, even when it's installed in site mode.
Signed-off-by: martin f. krafft <madduck@madduck.net>
---
perl/Makefile.PL | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index 4375161..6aecd89 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -29,5 +29,6 @@ WriteMakefile(
VERSION_FROM => 'Git.pm',
PM => \%pm,
MAKEFILE => 'perl.mak',
+ INSTALLSITEMAN3DIR => '$(SITEPREFIX)/share/man/man3',
%extra
);
--
1.5.3.rc2.19.gc4fba-dirty
^ permalink raw reply related
* Re: [PATCH 6/6] Add git-rewrite-commits
From: Sven Verdoolaege @ 2007-07-19 12:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0707181205260.14781@racer.site>
On Wed, Jul 18, 2007 at 12:17:03PM +0100, Johannes Schindelin wrote:
> Okay. For me it does not at all exclude that. If I want to replace a
> commit by no commit, I write a commit-filter which does not return
> anything. If I return more than one SHA1s, I damned well want all of
> those be the replacement "commit".
So how about you telling me what it _means_ for one commit to
be replaced by more than one commit or at least giving me an
example?
> > - if the parents of a commit have been rewritten to one or more
> > commits, then they are replaced by the new commits.
>
> Yes, that is the primary use for the mapping.
>
> > If any parent has been pruned, then it is replaced by
> > the result of applying this operation on _its_ parents.
>
> Why? This is overy complicated. If a commit has been pruned, why does
> the mapping not point to the _non-pruned_ parent?
It may not have any non-pruned parents and for the pruned ones, we
wouldn't want to lose the relation with the non-pruned ancestors.
> IOW if you have
> something like this:
>
> A - B - C - D - E - F
>
> and all commits except A and F are pruned, the mapping for A, B, C, D and
> E should _all_ point to the (possibly rewritten) A.
I'm not sure what you mean by "mapping" here, but the operation
described above would make all of B, C, D, E and F have (the
possibly rewritten) A as single parent (and parenthood was all
I was talking about above).
> > - a SHA1 of a commit that appears in a commit message is replaced
> > by the rewritten commit iff it was rewritten to a single commit.
> > That is, if the commit was pruned or rewritten (through a commit
> > filter to more than one commit), then the SHA1 is left alone.
>
> Both this behaviour and the one you described in your reply are wrong.
So tell me what you would do then and why that would make sense.
> > - the mapping available to filters
> > * if the commit was pruned, an empty file is created
> > * otherwise a file is created containing all rewritten SHA1s
>
> As I stated above: it is utterly wrong to create an empty mapping for a
> commit that was pruned. It does not take long to think of an example:
>
> A - B - C - D
>
> Now, A and D get pruned. Do you want the whole branch to vanish? _Hell,
> no_.
Define "vanish" and, again, tell me what you would do.
> You have to at least give the users a chance to grasp what they are doing.
> And if that means to change the semantics to something saner, then so be
> it.
Let's get things straight. I've added the map files and the possibility
for a commit filter to return more than one commit because you asked me to.
I've tried to make sense of it, but if you think the behavior I defined
is not what it is supposed to be, then it is up to _you_ to tell me what
you think it should be instead of letting me guess.
I think I'll just remove the possibility for the commit filter to
return more than one SHA1 (or maybe even no SHA1s).
filter-branch doesn't seem to allow either of those either.
skimo
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-19 12:38 UTC (permalink / raw)
To: git
In-Reply-To: <86zm1sbpeh.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Although it would be natural to have
> core.adddirs: false
> be equivalent to
> core.excludefile: .
>
> And so it might be possible to actually not need a separate
> core.adddirs option at all, technically.
To followup on myself here:
A project such as the linux kernel which presumably does not want to
have directories tracked will put the single pattern
.
into its top-level .gitignore file. That is all. At least if it does
not confuse current versions of git to do ugly things.
A separate option core.adddirs is still necessary because
man gitignore
states:
When deciding whether to ignore a path, git normally checks gitignore
patterns from multiple sources, with the following order of precedence:
· Patterns read from the file specified by the configuration variable
core.excludesfile.
· Patterns read from $GIT_DIR/info/exclude.
· Patterns read from a .gitignore file in the same directory as the
path, or in any parent directory, ordered from the deepest such file
to a file in the root of the repository. These patterns match rela‐
tive to the location of the .gitignore file. A project normally
includes such .gitignore files in its repository, containing pat‐
terns for files generated as part of the project build.
The priority for "core.adddirs", however, should be below that so that
preferences set in the repository's .gitignore files take precedence.
So core.excludesfile seems to be the wrong place.
A project with the policy of always tracking directories would place
!.
into its top-level .gitignore file.
--
David Kastrup
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Tomash Brechko @ 2007-07-19 12:32 UTC (permalink / raw)
To: git
In-Reply-To: <86zm1sbpeh.fsf@lola.quinscape.zz>
Hi David,
On Thu, Jul 19, 2007 at 13:31:50 +0200, David Kastrup wrote:
> core.excludefile: .
Really nice idea to give directories 'DIR/.' name. I'm sure there are
several other ways to implement your proposal. But why to put in in
Git itself? Decomposition and abstraction principle tells me that
this should go to some other place.
Please consider this: I myself use Git to track my own local projects,
and for this usage you proposal have no value for me, i.e. as a
_Source_ Code Management system Git is rather complete. But I also
track /etc and ~/ in Git, and for this I'd love to have directories,
permissions, ownership, other attributes, to be tracked. I have Perl
script wrapping Git that allows me to filter tracked paths by full
regexps instead of Git's file globs, and also to filter out too big
files assuming that they are binary anyway. Most people solving the
same problem moved further and implemented tools to store part of file
system state (permissions and ownership) in a textual representation,
to track that in Git. I'm sure you've seen such posts in the list.
And my point is that rather than building the support for all of it
into core Git, and then implementing sophisticated configuration to
disable parts of it, wouldn't it be better to have a separate tools
orthogonal to Git itself?
At the extreme case (probably not really seriously), consider the
following design: there are two layers, file system layer, and
contents layer. On checkout file system layer creates (or examines
existing) directory tree along with all files and their file system
state (permissions, ownership, ACLs, attributes, ...), and then asks
contents layer to update the contents. This way layers are
independent, and file system layer may be implemented on top of pure
contents tracking. File system layer may be extended to be made
particular OS/FS dependent if some development team wishes so. Even
hard links may be supported: since file system layer may deside to
remember that two paths really reference the same inode
(i.e. contents), contents layer may be asked to update the data only
once with either file name/descriptor.
This, BTW, is why I think not tracking file attributes when
versioning, say, /etc, is not a big loss. When I will move to the new
system, I will mostly be interested in contents diffs of the same
configuration files in /etc. I will trust their new attributes, and
will not want to restore them to what they were on the old system.
So the essence of my objection is that we should not pollute core Git
with file system state tracking more than it's required to know where
to put the contents to. Everything else should go elsewhere.
Again, I'd love to have your proposal be implemented, but only in a
way that won't interfere with pure SCM's operations.
--
Tomash Brechko
^ permalink raw reply
* Re: [PATCH] Force listingblocks to be monospaced in manpages
From: Jonas Fonseca @ 2007-07-19 12:25 UTC (permalink / raw)
To: Julian Phillips; +Cc: Junio C Hamano, Fredrik Tolf, git
In-Reply-To: <Pine.LNX.4.64.0707191239050.32611@reaper.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> wrote Thu, Jul 19, 2007:
> On Thu, 19 Jul 2007, Jonas Fonseca wrote:
> > This is because AsciiDoc does the escaping. I think it would be cleaner
> > to do this thing when converting from DocBook to roff like we already
> > do for other things.
>
> No. Docbook does the escaping (as it says here:
> http://docbook.sourceforge.net/release/xsl/current/RELEASE-NOTES.html#V1.72.0
> ).
Oops, yes, you are right.
> I tried your approach first, but 1) I idn't want to copy that much
> from the docbook xsl, as then we won't get updates/changes/fixes etc, 2) I
> still had to use ⌂ _anyway_.
OK, I didn't think you tried it. Nevermind then.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Johannes Schindelin @ 2007-07-19 12:25 UTC (permalink / raw)
To: Christian Stimming; +Cc: git, Shawn Pearce
In-Reply-To: <20070719125657.8utk85ynuow4ow48@webmail.tu-harburg.de>
Hi,
On Thu, 19 Jul 2007, Christian Stimming wrote:
> Does this implementation look okay?
This is valuable work, but unfortunately, it does not follow the
recommendation in Documentation/SubmittingPatches at all.
For starters, please send the patches inlined, one per mail. And you
might want to Cc the maintainer of git-gui (Shawn Pearce), too...
Ciao,
Dscho
^ 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