* Re: [PATCH] Support ent:relative_path
From: Alex Riesen @ 2007-05-04 17:17 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <56b7f5510705040957v4580b6c1xbe767892ada3bcde@mail.gmail.com>
On 5/4/07, Dana How <danahow@gmail.com> wrote:
> > > This all depends on deciding that :relpath should be the (incompatible)
> > > new default, and I'm not sure that's going to happen.
> >
> > If we are to stay that compatible, maybe ":./" for relative paths and the
> > old syntax left to mean top-level would the best choice for now.
>
> Let's summarize so far: I think everyone's convinced me we need
> to be careful, so this email will be more tedious than I'd like.
>
> (a) :./relpath clearly inidicates relative path. [Also take :../relpath .]
Ack
> (b) I'd like a more natural way to do :./relpath (e.g. :relpath),
> or at least a future path to such.
> (c) We would like to avoid new special characters beyond ":".
> This means everything has to be done with "." and "/".
And new semantics, if possible
> (d) We are left with the following patterns:
> 1. :string
Probably breaks something
> 2. :/string
Taken
> 3. ://string
Ugly (and breaks tab completion)
> [ We need a clear way to say relative, a clear way to say absolute,
> and the current :string can change from absolute to relative some time
> in the future if we so decide. ]
>
> Ideas for (d) 2&3:
> I. Make :/string actually match the RE ^[/]*string, and ://string a full path.
> The leading [/]* is a very small change to get_sha1_oneline().
> [Or change prefixcmp() to strstr() in get_sha1_oneline().]
> How often do commit messages start with / ?
How often should they start to justify any decision?
> II. Make :/string a full path, and ://string match ^string .
> Is changing the current :/string to ://string less painful/dangerous?
Johannes?
> III. Make :/string match ^string when string has no slashes,
> :/string a full path when string does have slashes,
> and ://string match ^string . Hmm, seems confusing.
Very/
> Do you use :/string now? Since it's a case-sensitive exact match,
No. It just exists, AFAICS
> I don't think I'd even use it.
> I find idea (II) most natural: absolute paths have one /,
> and string matches have 2 suggesting an RE.
I think, I'd be convinced by this one too, if not for "//" making
no sense anywhere but root accidentally typed twice.
I'd even sacrifice (or change) the search syntax for good.
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Junio C Hamano @ 2007-05-04 17:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <463AFAAE.853DEF7B@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> writes:
> Alex Riesen wrote:
>> On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:
>> > My preference is (2), (3) and then (1), but I do not have
>> > offhand a suggestion for a good metacharacter we could use.
>>
>> "./" :)
>
> +1, without the :)
> and ../ should DWIM, too.
I think these feel more or less natural (except that we do not
say ":/fullpath" and instead say ":fullpath" which is
unfortunate).
In the hindsight, if we had the perfect vision into the future,
we would have made <path> relative to where you are when we
initially did "<something>:<path>", with obvious semantics for
things like "<something>:../<path>" and "<something>:/<path>".
We didn't. Further, we made a mistake to make :/ to mean
something completely unrelated. My bad.
So I think "./" is the best compromise in the meantime.
With your suggestion, we can train people's fingers to type "./"
now, and perhaps later in one of those big feature release like
the 1.5.0 was, we could switch to "default to relative".
At the same time of that big "UI correction", we could make
"<something>:/<path>" to mean "full path in commit (or
index/stage) no matter where I am".
The current ":/<string>" is about going back, looking for the
string, so it should not have used '/'; instead it should have
been "<something>:?<string>". Maybe we could fix it by start
accepting ":?" now (in addition to ":/"), give a big fat warning
about ":/" going to mean a different thing, and encouraging
users to use the question-mark form, in preparation for the big
"UI correction".
Do people like that plan?
(soon after 1.5.2)
- start accepting "<something>:./<path>" as "relative to where I am".
- start accepting "<something>:?<string>" as "look back to find
the string".
- clearly explain the plan and prepare the users.
(a big release in the future, perhaps 1.6.0)
- "<something>:<path>" becomes relative to where you are.
- stop "<something>:/<string>" and start "<something>:/<fullpath>".
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Florian Weimer @ 2007-05-04 17:23 UTC (permalink / raw)
To: git
In-Reply-To: <463B5ABB.5D7A3EC4@eudaptics.com>
* Johannes Sixt:
> Andy Parkins wrote:
>> On Friday 2007 May 04, Michael Niedermayer wrote:
>> > for these we currently copy the last good version of the affected files
>> > over the current one with svn cp and then apply the changes in nicely
>> > split manner. (possibly without the reindention if its uneeded ...)
>>
>> I might be misunderstanding, but doesn't that leave the "bad" commit in the
>> history?
>
> In the history? Yes.
> In the blame? No.
>
>>
>> * -- * -- G -- B -- !B -- 1 -- 2 -- 3
>>
>> B is the bad commit; !B would be the result of the svn cp from the previous
>> known-good revision, "G"; then 1, 2, and 3 would be the correctly split
>> version of "B".
>
> With svn cp you actually create this "blame" history:
>
> * -- * -- G -- B
> \
> ----- G* -- 1 -- 2 -- 3
>
> where G* is a new revision, but since it is otherwise identical to G, it
> does not introduce new blame-able lines.
With GIT, you could create:
* -- * -- G --- B
\ \
---- 1 -- 2 -- 3
Or perhaps :
* -- * -- G --- B
\ \
---- G* -- 1 -- 2 -- 3
How do the history viewers handle this situation?
^ permalink raw reply
* Re: repack: handling of .keep files
From: Alex Riesen @ 2007-05-04 17:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vslacttij.fsf@assigned-by-dhcp.cox.net>
On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > Still, git-log shouldn't crash (nothing should, of course).
>
> Honestly, I think that's borderline. If you "dd if=/dev/random
> of=/dev/hda", should the kernel keep going, perhaps gracefully
> declining access to the filesystem on that drive?
e2fsck has a test somewhere which randomly corrupts a partition
and then lets the program fix it.
All kind of corruptions happen, we will have to deal with them.
Especially if this crash is so simple to reproduce.
> case of temporary pack I do not think there would be a risk of
> filename collisions, I think it makes sense to use either
> GIT_DIR or GIT_OBJECT_DIRECTORY instead of the working tree.
>
> I do not know pros-and-cons between .git/ and .git/objects/;
These are settable separately, so theoretically you can end
up with .git and .git/objects being on different filesystems.
Atomic rename wont be possible than.
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Carl Worth @ 2007-05-04 18:17 UTC (permalink / raw)
To: Michael Niedermayer; +Cc: git
In-Reply-To: <loom.20070504T143538-533@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4182 bytes --]
On Fri, 4 May 2007 13:46:28 +0000 (UTC), Michael Niedermayer wrote:
> well, my example above was exagerated, noone ever reindented the whole
> ffmpeg or checked in a old version over HEAD. what did and does occasionally
> happen is that people check in several things at once (like a 100k reindenton
> mixed with various functional changes)
That sounds like an opportunity to educate your contributors a bit on
what good commits should look like. So I think this is more a social
issue than a technical issue, (but git has some technical means that
make it much easier to address the social issues).
Your description above makes an assumption that there is a single
central repository that multiple people push changes into, (which is
really the only way to organize a project with svn or cvs). And with
those systems all you get is a bit than you can flip on for whether
you trust someone to push changes into the repository or not. But git
is much more flexible than that.
The opposite extreme is to organize the project in a way similar to
the linux kernel---all contributors maintain their own repositories
and things get merged only when a maintainer reviews and pulls. With
this approach, garbage never lands in your own repository by
definition, (since you don't pull if it looks like garbage to you). So
that solves the problem, but this organization might seem too radical
a shift for your project.
Fortunately, git is flexible enough to do things in between as
well. For example, you can have a central repository where multiple
people push changes, and also have personal repositories. Git reduces
the cost of creating a new personal repository to basically zero, so
you can use these quite freely. They make a great place for new
contributors to publish changes where the more experienced maintainers
can review and educate the new contributors on mistakes like you
describe above.
So with this, you can let people play in their own repositories while
they're still learning the cultural aspects of what code should look
like. I've found that new contributors really like the freedom this
gives them, (there's no fear that they are going to break anything
this way, since they are relying on others to review and pull at
first). So the trust relationship can grow as you work together,
(which is how it should be).
And that whole relationship-building happens while you're both
benefiting from the support of the tool, (not like cvs or svn where
the new contributor is cut off from almost all help from the tool
until you flip the "absolute trust" bit).
> well if git blame and others could somehow be told to automatically ignore
> nonsense changes and matching nonsense reverts that would be great
> maybe by searching for some keyword in the revert message?
That sounds like a bad technical workaround for a problem that really
shouldn't exist. You should look for ways to create the history you'd
really like to have rather than trying to find a way to get the tool
to ignore the history that's actually there.
Sure, mistakes will happen. Just learn to live with that.
Oh, and I also think the emphasis on "blame" is due to a lack of other
more powerful history exploration features in other systems. For
example, the fact that "git log" can filter based on subsets of the
directory tree:
git log -p -- some/directory
or by content of the patches themselves:
git log -p -S'snippet of interest'
[*]
is often just plain more powerful than blame is, and it makes it quite
trivial to skip past any noise, (since you get the complete history of
what you care about, not just information about the last time a line
in a file got touched).
For example, I often use git-log to find out what happened to code
that used to be in the file, but doesn't appear there anymore. That's
simple to do with git log, (sometimes even just plain "git log -p" and
searching with the pager), but it's something that something like cvs
or svn blame just fundametally cannot even help with.
-Carl
[*] I just noticed that -S isn't mentioned in the documentation for
git-log at all, (though, oddly enough, a 'git log -S' example is
provided in the git-blame documentation).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Dana How @ 2007-05-04 18:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, danahow, Alex Riesen
In-Reply-To: <7vabwktsng.fsf@assigned-by-dhcp.cox.net>
On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:
> Johannes Sixt <J.Sixt@eudaptics.com> writes:
>
> > Alex Riesen wrote:
> >> On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:
> >> > My preference is (2), (3) and then (1), but I do not have
> >> > offhand a suggestion for a good metacharacter we could use.
> >>
> >> "./" :)
> >
> > +1, without the :)
> > and ../ should DWIM, too.
>
> I think these feel more or less natural (except that we do not
> say ":/fullpath" and instead say ":fullpath" which is
> unfortunate).
>
> In the hindsight, if we had the perfect vision into the future,
> we would have made <path> relative to where you are when we
> initially did "<something>:<path>", with obvious semantics for
> things like "<something>:../<path>" and "<something>:/<path>".
>
> We didn't. Further, we made a mistake to make :/ to mean
> something completely unrelated. My bad.
>
> So I think "./" is the best compromise in the meantime.
>
> With your suggestion, we can train people's fingers to type "./"
> now, and perhaps later in one of those big feature release like
> the 1.5.0 was, we could switch to "default to relative".
>
> At the same time of that big "UI correction", we could make
> "<something>:/<path>" to mean "full path in commit (or
> index/stage) no matter where I am".
>
> The current ":/<string>" is about going back, looking for the
> string, so it should not have used '/'; instead it should have
> been "<something>:?<string>". Maybe we could fix it by start
> accepting ":?" now (in addition to ":/"), give a big fat warning
> about ":/" going to mean a different thing, and encouraging
> users to use the question-mark form, in preparation for the big
> "UI correction".
>
> Do people like that plan?
>
> (soon after 1.5.2)
>
> - start accepting "<something>:./<path>" as "relative to where I am".
>
> - start accepting "<something>:?<string>" as "look back to find
> the string".
>
> - clearly explain the plan and prepare the users.
>
> (a big release in the future, perhaps 1.6.0)
>
> - "<something>:<path>" becomes relative to where you are.
> - stop "<something>:/<string>" and start "<something>:/<fullpath>".
I will resubmit the patch following Junio's plan.
It will include the "1.6.0" features but disabled.
I would just request that we expedite, if possible,
at least the later switch from "<something>:/<string>"
to "<something>:/<fullpath>",
since with the patch _and_ the latter behavior enabled,
scripts can be updated to always insert "./" or "/" and
their intent will always be clear.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Johan Herland @ 2007-05-04 18:25 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87y7k4lahq.wl%cworth@cworth.org>
[-- Attachment #1: Type: text/plain, Size: 480 bytes --]
On Friday 04 May 2007, Carl Worth wrote:
> [*] I just noticed that -S isn't mentioned in the documentation for
> git-log at all, (though, oddly enough, a 'git log -S' example is
> provided in the git-blame documentation).
It's also used in an example in the User Manual (Chapter 1. Git Quick
Start -- Exploring history). I was also surprised that it wasn't
mentioned in the git-log manual page.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Mention version 1.5.1 in tutorial and user-manual
From: Carl Worth @ 2007-05-04 18:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]
Most other documentation will frequently be read from an installation
of git so will naturally be associated with the installed version.
But these two documents in particular are often read from web pages
while users are still exploring git. It's important to mention
version 1.5.1 since these documents provide example commands that
won't work with previous versions of git.
---
This really tripped up a recent friend who tried to go through the
tutorial on the web page while following along with a 1.4 version of
git, and got very confused.
There's definitely a bunch more that could be done here, (include a
paragraph explaining which version of git is necessary, mention where
to go to upgrade git, call out particular commands that require
specific versions of git, dynamically generate the version that gets
stuck into the documentation, etc.). But I just went with the most
minimal think I could think of to solve the problem
-Carl
Documentation/tutorial.txt | 4 ++--
Documentation/user-manual.txt | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index e978562..99efce4 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -1,5 +1,5 @@
-A tutorial introduction to git
-==============================
+A tutorial introduction to git (for version 1.5.1 or newer)
+===========================================================
This tutorial explains how to import a new project into git, make
changes to it, and share changes with other developers.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 9c4c41d..dff438f 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1,5 +1,5 @@
-Git User's Manual
-_________________
+Git User's Manual (for version 1.5.1 or newer)
+______________________________________________
This manual is designed to be readable by someone with basic unix
command-line skills, but no previous knowledge of git.
--
1.5.1.1.g6aead
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] Support ent:relative_path
From: Johannes Schindelin @ 2007-05-04 19:00 UTC (permalink / raw)
To: Alex Riesen; +Cc: Dana How, Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0705041017l1ceb419j733e9cf3389e9709@mail.gmail.com>
Hi,
On Fri, 4 May 2007, Alex Riesen wrote:
> On 5/4/07, Dana How <danahow@gmail.com> wrote:
>
> > II. Make :/string a full path, and ://string match ^string .
> > Is changing the current :/string to ://string less painful/dangerous?
>
> Johannes?
Huh? Hello!
I did not follow this thread closely...
Having said that, I think ":./bla/blub" is the most intuitive, and the
least breaking.
You _could_ change the current :/ notation, but _why_?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Johannes Schindelin @ 2007-05-04 19:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vabwktsng.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 4 May 2007, Junio C Hamano wrote:
> (a big release in the future, perhaps 1.6.0)
>
> - "<something>:<path>" becomes relative to where you are.
FWIW I still find that unintuitive. I know "<something>:<path>" from ssh,
and there it does not change meaning depending on where I am. IMHO in most
cases you want to use git-diff anyway, which _does_ honour the current
relative path.
Ciao,
Dscho
^ permalink raw reply
* Re: repack: handling of .keep files
From: Junio C Hamano @ 2007-05-04 19:20 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0705041024i43d7fc5ah1967d6a6192dc6ee@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:
> ...
>> I do not know pros-and-cons between .git/ and .git/objects/;
>
> These are settable separately, so theoretically you can end
> up with .git and .git/objects being on different filesystems.
> Atomic rename wont be possible than.
Fair enough.
As we've lived without trouble long enough creating the new pack
tempfile in $GIT_DIR, I do not think it is urgent; but feel free
to propose moving it to GIT_OBJECT_DIRECTORY. We _might_ need
to teach fsck to take notice of such leftover temporary files
from an earlier, aborted run if we do this -- I haven't looked.
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Junio C Hamano @ 2007-05-04 19:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0705042104370.4015@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> FWIW I still find that unintuitive. I know "<something>:<path>" from ssh,
> and there it does not change meaning depending on where I am. IMHO in most
> cases you want to use git-diff anyway, which _does_ honour the current
> relative path.
There, its meaning is relative to where you are, namely "$HOME".
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Johannes Schindelin @ 2007-05-04 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7v1whwtmvj.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 4 May 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > FWIW I still find that unintuitive. I know "<something>:<path>" from ssh,
> > and there it does not change meaning depending on where I am. IMHO in most
> > cases you want to use git-diff anyway, which _does_ honour the current
> > relative path.
>
> There, its meaning is relative to where you are, namely "$HOME".
No, it is relative to where I am _at the other end_. If I "cd /tmp", it
still is relative to $HOME.
Now, what you want to do is changing the meaning of v1.5.1:Makefile,
depending if you "cd Documentation/"ed or not.
For me, "v1.5.1:" means something similar to ssh: it is a distant
revision. It is not a complete filesystem. I think of revisions as
something more general than a directory, but less general than a
filesystem. And thus, it makes perfect sense to me that "v1.5.1:Makefile"
means the main Makefile, no matter where I am in the current repository.
Now, I agree that often you want to compare some file in the current
directory to the corresponding file in a certain revision. That is why
git-diff has a different idea, and indeed, a different notation, too.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Junio C Hamano @ 2007-05-04 19:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0705042127390.4015@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> For me, "v1.5.1:" means something similar to ssh: it is a distant
> revision. It is not a complete filesystem. I think of revisions as
> something more general than a directory, but less general than a
> filesystem. And thus, it makes perfect sense to me that "v1.5.1:Makefile"
> means the main Makefile, no matter where I am in the current repository.
I see merits in both sides' arguments.
Saying "path out of THIS version" anchors your mindset at the
top of that version, so in that sense v1.5.1:Makefile should
mean the toplevel no matter where you are. However...
> Now, I agree that often you want to compare some file in the current
> directory to the corresponding file in a certain revision. That is why
> git-diff has a different idea, and indeed, a different notation, too.
... don't you expect "git show HEAD@{yesterday}:git.txt" while
in Documentation/ subdirectory to work? I wonder if the current
alternative "git show HEAD@{yesterday}:Documentation/git.txt" a
bit unintuitive.
^ permalink raw reply
* Re: repack: handling of .keep files
From: Nicolas Pitre @ 2007-05-04 19:40 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0705041024i43d7fc5ah1967d6a6192dc6ee@mail.gmail.com>
On Fri, 4 May 2007, Alex Riesen wrote:
> On 5/4/07, Junio C Hamano <junkio@cox.net> wrote:
> > "Alex Riesen" <raa.lkml@gmail.com> writes:
> >
> > > Still, git-log shouldn't crash (nothing should, of course).
> >
> > Honestly, I think that's borderline. If you "dd if=/dev/random
> > of=/dev/hda", should the kernel keep going, perhaps gracefully
> > declining access to the filesystem on that drive?
>
> e2fsck has a test somewhere which randomly corrupts a partition
> and then lets the program fix it.
> All kind of corruptions happen, we will have to deal with them.
> Especially if this crash is so simple to reproduce.
>
> > case of temporary pack I do not think there would be a risk of
> > filename collisions, I think it makes sense to use either
> > GIT_DIR or GIT_OBJECT_DIRECTORY instead of the working tree.
> >
> > I do not know pros-and-cons between .git/ and .git/objects/;
>
> These are settable separately, so theoretically you can end
> up with .git and .git/objects being on different filesystems.
> Atomic rename wont be possible than.
Other temporary pack/object creation instances already use
GIT_OBJECT_DIRECTORY.
Nicolas
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Johannes Schindelin @ 2007-05-04 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vwszos7l2.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 4 May 2007, Junio C Hamano wrote:
> ... don't you expect "git show HEAD@{yesterday}:git.txt" while
> in Documentation/ subdirectory to work?
Actually, no. I expect "git diff HEAD@{yesterday} git.txt" to work fine,
and "git show HEAD@{yesterday}:git.c" also, both when in Documentation/,
because I expect "git show HEAD@{yesterday}:git.c" to work _also_ when I
set GIT_DIR=/path/to/my/bare-repo.git/ before that, while I do not expect
the call to git-diff to work (for obvious reasons).
Ciao,
Dscho
^ permalink raw reply
* Re: [RFD/PATCH] Implement pack.compression and pack-objects --compression=N
From: Dana How @ 2007-05-04 19:51 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git Mailing List, danahow
In-Reply-To: <alpine.LFD.0.99.0705041218130.24220@xanadu.home>
On 5/4/07, Nicolas Pitre <nico@cam.org> wrote:
> On Fri, 4 May 2007, Dana How wrote:
> > On 5/4/07, Nicolas Pitre <nico@cam.org> wrote:
> > > I think that would make sense to have separate configs for pack and
> > > loose object compression. When not specified they should simply default
> > > to core.compression if it exists. Otherwise I'd suggest that pack
> > > compression default level be Z_DEFAULT_COMPRESSION and loose object
> > > compression default level be Z_BEST_SPEED. This would make interactive
> > > operations like git-add and git-commit even faster by default.
> > I agree with your Z_BEST_SPEED idea. I did not include it in
> > the patch b/c I didn't want to change any behavior in the absence
> > of new config settings.
> > Are you actually arguing for *3* different compression-related config
> > variables?
> Yes.
>
> > How about:
> > (a) core.compression controls loose objects. defaults to Z_BEST_SPEED.
> > (b) pack.compression controls packing. defaults to Z_DEFAULT_COMPRESSION
> > if neither variable exists. defaults to core.compression if only that exists
> Yes, although I wouldn't default pack.compression to core.compression
> if pack.compression doesn't exist. The documentation about
> core.compression currently talks
> (wrongly) only about loose objects anyway, so making pack.compression
> stand on its own won't be that bad.
Now that I'm awake your original quote at the top suggests:
(a) zlib_compression_level =
isset(core.loosecompression) ? core.loosecompression :
isset(core.compression) ? core.compression : Z_BEST_SPEED;
(b) pack_compression_level =
isset(pack.compression) ? pack.compression :
isset(core.compression) ? core.compression : Z_DEFAULT_COMPRESSION;
Your later reaction to my quoted (a)/(b) table suggests:
(a) zlib_compression_level =
isset(core.compression) ? core.compression : Z_BEST_SPEED;
(b) pack_compresion_level =
isset(pack.compression) ? pack.compression : Z_DEFAULT_COMPRESSION;
In either case, the C variable
zlib_compression_level controls compression level for loose objects,
and pack_compression_level controls compression in a pack.
"isset()" means an active setting does appear in a config file
(it could be the default value).
The 2nd behavior table is sufficient for me and simpler than my patch.
Do you want the 1st or 2nd behavior?
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [RFD/PATCH] Implement pack.compression and pack-objects --compression=N
From: Nicolas Pitre @ 2007-05-04 20:17 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <56b7f5510705041251v1a09103eif677c02efc53059e@mail.gmail.com>
On Fri, 4 May 2007, Dana How wrote:
> Now that I'm awake your original quote at the top suggests:
> (a) zlib_compression_level =
> isset(core.loosecompression) ? core.loosecompression :
> isset(core.compression) ? core.compression : Z_BEST_SPEED;
> (b) pack_compression_level =
> isset(pack.compression) ? pack.compression :
> isset(core.compression) ? core.compression : Z_DEFAULT_COMPRESSION;
>
> Your later reaction to my quoted (a)/(b) table suggests:
> (a) zlib_compression_level =
> isset(core.compression) ? core.compression : Z_BEST_SPEED;
> (b) pack_compresion_level =
> isset(pack.compression) ? pack.compression : Z_DEFAULT_COMPRESSION;
My final comment is that I think the former looks more coherent, while
the later is simpler to implement.
Nicolas
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Alex Riesen @ 2007-05-04 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vabwktsng.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Fri, May 04, 2007 19:17:39 +0200:
> Do people like that plan?
>
> (soon after 1.5.2)
>
> - start accepting "<something>:./<path>" as "relative to where I am".
>
> - start accepting "<something>:?<string>" as "look back to find
> the string".
Still don't like the feature. It makes things special: suddenly we
have to be careful about not having files with a "?" as their first
symbol (well, scripts always can prepend "./" or "/")
And it is hard to use: only prefix, must be unambiguous and is
case sensitive.
> - clearly explain the plan and prepare the users.
>
> (a big release in the future, perhaps 1.6.0)
>
> - "<something>:<path>" becomes relative to where you are.
> - stop "<something>:/<string>" and start "<something>:/<fullpath>".
I like the plan.
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Alex Riesen @ 2007-05-04 20:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dana How, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0705042025130.4015@racer.site>
Johannes Schindelin, Fri, May 04, 2007 21:00:53 +0200:
> Having said that, I think ":./bla/blub" is the most intuitive, and the
> least breaking.
>
> You _could_ change the current :/ notation, but _why_?
To use the syntax for full path starting from root of repo.
It looks "most intuitive" for this.
^ permalink raw reply
* Re: [PATCH v2] Support ent:relative_path
From: Alex Riesen @ 2007-05-04 20:26 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <463AE404.9060906@gmail.com>
Dana How, Fri, May 04, 2007 09:43:00 +0200:
> + if (!strcmp(var, "core.relativepaths")) {
> + assume_relative_paths = git_config_bool(var, value);
> + return 0;
> + }
Still don't like it. What good is a syntax you cannot depend upon?
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Michael Niedermayer @ 2007-05-04 20:24 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87y7k4lahq.wl%cworth@cworth.org>
[-- Attachment #1: Type: text/plain, Size: 4193 bytes --]
Hi
On Fri, May 04, 2007 at 11:17:05AM -0700, Carl Worth wrote:
> On Fri, 4 May 2007 13:46:28 +0000 (UTC), Michael Niedermayer wrote:
> > well, my example above was exagerated, noone ever reindented the whole
> > ffmpeg or checked in a old version over HEAD. what did and does occasionally
> > happen is that people check in several things at once (like a 100k reindenton
> > mixed with various functional changes)
>
> That sounds like an opportunity to educate your contributors a bit on
> what good commits should look like.
we have a nice svn policy which explains that, also people wont receive
write access without having submitted a few clean patches first
so i dont know if more education would really help, the problems are IMHO
rather caused by a mix of lazyness, arrogance and plain oversight
but please dont missunderstand, these problems are not that common, its
rather once every few month
> So I think this is more a social
> issue than a technical issue,
yes i think so too, the added push after commit wont stop a bad commit
as the developer already saw the change when running svn diff ...
> (but git has some technical means that
> make it much easier to address the social issues).
>
> Your description above makes an assumption that there is a single
> central repository that multiple people push changes into, (which is
> really the only way to organize a project with svn or cvs). And with
> those systems all you get is a bit than you can flip on for whether
> you trust someone to push changes into the repository or not. But git
> is much more flexible than that.
>
> The opposite extreme is to organize the project in a way similar to
> the linux kernel---all contributors maintain their own repositories
> and things get merged only when a maintainer reviews and pulls. With
> this approach, garbage never lands in your own repository by
> definition, (since you don't pull if it looks like garbage to you). So
> that solves the problem, but this organization might seem too radical
> a shift for your project.
yes, id like to switch ffmpeg to git or mercurial as that seems like a
good idea and many of our developers seem to want it, the question
about the organization is a different thing, not a single ffmpeg
developer suggested to change the current "every developer has write access"
system, actually its even more than just that, almost every mplayer
developer has technically write access to ffmpeg and almost every ffmpeg
developer has technically write access to mplayer and this has never
caused a problem ...
also its kinda nice to review a patch and reply with "looks ok" and
someone else applies the patch locally, tests it extensively and
commits it, it reduces the work for reviewers ...
[...]
>
> > well if git blame and others could somehow be told to automatically ignore
> > nonsense changes and matching nonsense reverts that would be great
> > maybe by searching for some keyword in the revert message?
>
> That sounds like a bad technical workaround for a problem that really
> shouldn't exist. You should look for ways to create the history you'd
> really like to have rather than trying to find a way to get the tool
> to ignore the history that's actually there.
>
> Sure, mistakes will happen. Just learn to live with that.
btw, that leads me to another minor issue, i think commit log
messages cannot be changed in git after they are public, while we
commonly did change them to improve them, the issue simply is that some
developers are not good at writing nice commit log messages, sometimes
due them being plain bad in english or bad at writing descriptive
log messages ...
also our docs team loves to correct spelling errors in the commit messages
not that i consider that of any importance :)
>
> Oh, and I also think the emphasis on "blame" is due to a lack of other
> more powerful history exploration features in other systems. For
yes
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Support ent:relative_path
From: Dana How @ 2007-05-04 20:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Git Mailing List, danahow
In-Reply-To: <20070504202613.GC4033@steel.home>
On 5/4/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> Dana How, Fri, May 04, 2007 09:43:00 +0200:
> > + if (!strcmp(var, "core.relativepaths")) {
> > + assume_relative_paths = git_config_bool(var, value);
> > + return 0;
> > + }
> Still don't like it. What good is a syntax you cannot depend upon?
No worry.
Junio already squashed this, and I agreed.
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH 2/5] git-config: add --remote option for reading config from remote repo
From: Frank Lichtenheld @ 2007-05-04 21:03 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: git
In-Reply-To: <1178276203127-git-send-email-skimo@liacs.nl>
Some comments on the documentation:
On Fri, May 04, 2007 at 12:56:40PM +0200, Sven Verdoolaege wrote:
> +'git-config' [--system | --global | --remote=[<host>:]<directory ]
> + [type] name [value [value_regex]]
maybe something more like
'git-config' [ scope ]
where you mention later that scope can be --system | --global | --remote
would be more readable...
> +'git-config' [--system | --global | --remote=[<host>:]<directory ]
> + [type] --add name value
> +'git-config' [--system | --global | --remote=[<host>:]<directory ]
> + [type] --replace-all name [value [value_regex]]
> +'git-config' [--system | --global | --remote=[<host>:]<directory ]
> + [type] --get name [value_regex]
> +'git-config' [--system | --global | --remote=[<host>:]<directory ]
> + [type] --get-all name [value_regex]
> +'git-config' [--system | --global | --remote=[<host>:]<directory ]
> + [type] --unset name [value_regex]
> +'git-config' [--system | --global | --remote=[<host>:]<directory ]
> + [type] --unset-all name [value_regex]
> +'git-config' [--system | --global | --remote=[<host>:]<directory ]
> + [type] --rename-section old_name new_name
> +'git-config' [--system | --global | --remote=[<host>:]<directory ]
> + [type] --remove-section name
> +'git-config' [--system | --global | --remote=[<host>:]<directory ] -l | --list
>
> DESCRIPTION
> -----------
> @@ -80,6 +89,10 @@ OPTIONS
> Use system-wide $(prefix)/etc/gitconfig rather than the repository
> .git/config.
>
> +--remote=[<host>:]<directory
> + Use remote config instead of the repository .git/config.
> + Only available for reading options.
Why did you add it to all options in the SYNOPSYS then?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH 2/5] git-config: add --remote option for reading config from remote repo
From: Sven Verdoolaege @ 2007-05-04 21:10 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git
In-Reply-To: <20070504210339.GB30324@planck.djpig.de>
On Fri, May 04, 2007 at 11:03:40PM +0200, Frank Lichtenheld wrote:
>
> Some comments on the documentation:
>
> On Fri, May 04, 2007 at 12:56:40PM +0200, Sven Verdoolaege wrote:
> > +'git-config' [--system | --global | --remote=[<host>:]<directory ]
> > + [type] name [value [value_regex]]
>
> maybe something more like
>
> 'git-config' [ scope ]
Sounds reasonable, although I'd probably say [<scope>].
> > +--remote=[<host>:]<directory
> > + Use remote config instead of the repository .git/config.
> > + Only available for reading options.
>
> Why did you add it to all options in the SYNOPSYS then?
Because I wasn't thinking.
skimo
^ 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