* Re: Anyone running GIT on native Windows
From: Johannes Sixt @ 2007-05-09 7:08 UTC (permalink / raw)
To: hanwen; +Cc: Marco Costalba, git
In-Reply-To: <46415106.5040401@xs4all.nl>
Han-Wen Nienhuys wrote:
> I packaged Mingw GIT using NSIS some time ago; see
>
> http://lilypond.org/git/binaries/mingw/
>
> Due various personal reasons, I haven't been able to update this, but I
> will package a new version soon. Please try it to see whether there are
> any rough edges.
I've tried this shortly after you released it. But it did not work as
expected. The symtom was (IIRC) that a simple
git init
said that 'init' is not a git-command. I tried this from CMD, not rxvt.
There are meanwhile a number of improvements in the port that support
relocation (i.e. an arbitrary installation directory). Could you please
package the latest version from the 'devel' branch?
git://repo.or.cz/git/mingw.git
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Karl Hasselström @ 2007-05-09 6:48 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Johannes Schindelin, junio, git
In-Reply-To: <20070509031803.GA27980@fieldses.org>
On 2007-05-08 23:18:04 -0400, J. Bruce Fields wrote:
> Looks helpful, concise, and to the point. Neat-o.
Yeah, I like it too. I forgot to say that, and got right to the
criticism instead. But better late than never, I hope. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] gitweb: Do not use absolute font sizes
From: Chris Riddoch @ 2007-05-09 6:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20070509014150.7477.48489.stgit@rover>
On 5/8/07, Petr Baudis <pasky@ucw.cz> wrote:
> Avoid specifying font sizes in pixels, since that is just pure evil.
> Pointed out by Chris Riddoch.
Thanks! It's definitely a step in the right direction.
In my browser, the decent-sized fonts make it apparent that we're
trying to fit a lot in a limited horizontal space. In particular, the
links (commit | committdiff | tree | snapshot) wrap in the space
provided, for me. I dropped my default font size a little, and it's
just fine... but it does make me think, perhaps that's something where
either icons or abbreviations (with an appropriate key) might improve
the appearance of the page. Perhaps something like: C | D | T | S.
It might even let us put more functionality in and improve our use of
whitespace even more.
I like it.
--
epistemological humility
Chris Riddoch
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Dana How @ 2007-05-09 6:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git Mailing List, danahow
In-Reply-To: <alpine.LFD.0.99.0705082031370.24220@xanadu.home>
On 5/8/07, Nicolas Pitre <nico@cam.org> wrote:
> On Tue, 8 May 2007, Dana How wrote:
> > On 5/8/07, Nicolas Pitre <nico@cam.org> wrote:
> > > On Tue, 8 May 2007, Junio C Hamano wrote:
> > > If we want the fallback logic to work, at some point we must remember if
> > > the current value is the default or if it is the result of an explicit
> > > config option.
> > I can leave as-is, or use a magic value like -99 and
> > depend on it not colliding with values in zlib.h.
> And where would you set those variables to a sensible default in the
> absence of any config option?
This is why I used the _seen variables,
but they are not necessary -- see 3rd option below.
Unfortunately we agreed a day or two ago to use a config rule like
used_value = isset(var1) ? var1 : isset(var2) ? var2 : DEFAULT.
This doesn't interact well with each variable being processed
completely independently in git_config() and the callbacks it calls.
The isset() value is "out-of-band"; either store it in the _seen
variables, or some special value in used_value .
Which makes the most sense:
* Leave _seen as-is;
* Move pack.compression recognition into config.c which means
the _seen variables would all be local to config.c;
* Use some special value, and if still present replace it with the default
at the end of git_config() using extra code;
* Change the config rule to something simpler.
I like the 2nd and the 4th. You didn't like the 4th.
Shall I change to the 2nd?
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Marco Costalba @ 2007-05-09 6:38 UTC (permalink / raw)
To: Paul Mackerras
Cc: Alex Riesen, Linus Torvalds, Karl Hasselstr?m, Junio C Hamano,
Carl Worth, Michael Niedermayer, Git Mailing List
In-Reply-To: <17985.19926.347089.878721@cargo.ozlabs.ibm.com>
On 5/9/07, Paul Mackerras <paulus@samba.org> wrote:
> Marco Costalba writes:
>
> > Language to use is C++, not C (much more powerful IMHO)
>
> Sorry, C++ is not an option because I dislike it so much.
Well, speaking about GUI applications, the 90% is in the graphic
library and only in small part in the language. With Qt we are at 95%
Anyhow does exist also python bindings for Qt.
> The main
> reason for changing languages would be to enable people like Linus to
> hack on it more easily, and I don't think C++ would achieve that.
>
Poor Linus ;-)
I think the design of the application states the easiness of changes,
spaghetti code and bad designed functions are much worst then any ugly
language you can think about.
That's for substantial changes, for one liners or for adding little
features encapsulation and modularity of the code are the magical
words here, and an object oriented language *could* help achieving
that.
> > P.S: If you choose Qt/C++ (the best technically speaking ;-) please
> > you could consider starting from an already laid out code base instead
> > of starting from scratch.
> > As example, hmmmm, I think there is one called 'qgit', if I remember
> > correctly. It's nice and very very very fast.
>
> Yes, but isn't there already a talented hacker working on that? :)
>
Two is better then one :-)
Marco
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Karl Hasselström @ 2007-05-09 6:31 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, bfields, junio, git
In-Reply-To: <Pine.LNX.4.64.0705090015360.18541@iabervon.org>
On 2007-05-09 00:54:03 -0400, Daniel Barkalow wrote:
> And "unsigned char *" or "unsigned char[20]" is always the octets;
> the hex is always "char *".
uint8_t, anyone? :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Dana How @ 2007-05-09 6:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow, Nicolas Pitre
In-Reply-To: <7vr6pqy1ty.fsf@assigned-by-dhcp.cox.net>
On 5/8/07, Junio C Hamano <junkio@cox.net> wrote:
> "Dana How" <danahow@gmail.com> writes:
> > On 5/8/07, Junio C Hamano <junkio@cox.net> wrote:
> >> Dana How <danahow@gmail.com> writes:
> >> > This applies on top of the git-repack --max-pack-size patchset.
> >> Hmph, that makes the --max-pack-size patchset take this more
> >> trivial and straightforward improvements hostage. In general,
> >> I'd prefer more elaborate ones based on less questionable
> >> series.
> > The max-pack-size and pack.compression patches touch the same lines.
> > I thought my options were:
> > * Submit independently and make you merge; or
> > * Make one precede the other.
> > Since max-pack-size has been out there since April 4 and
> > the first acceptable version was May 1 (suggested by 0 comments),
> > I didn't realize it was a "questionable series".
> No, what I meant was that it is much "more elaborate" series
> than this custom compression which is much "less questionable".
>
> I think this custom compression is 1.5.2 material. I have not
> studied the code for the max-pack-size enough to be confident to
> put it in 1.5.2, at least not yet, and was planning to park the
> latter in 'next' until 1.5.2 final.
OK, thanks for guesstimating the overall schedule. I was starting to wonder
what the next step(s) should be.
I will incorporate your & Nicolas's comments and send out a new custom
compression patch tomorrow. I *think* I addressed everyone's comments
on max-pack-size, but let me know if you find anything else when you get
around to it.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Junio C Hamano @ 2007-05-09 5:59 UTC (permalink / raw)
To: Dana How; +Cc: Git Mailing List
In-Reply-To: <56b7f5510705081725v655d2ce1j28712507cfa7fa55@mail.gmail.com>
"Dana How" <danahow@gmail.com> writes:
> On 5/8/07, Junio C Hamano <junkio@cox.net> wrote:
>> Dana How <danahow@gmail.com> writes:
>> ...
>> > This applies on top of the git-repack --max-pack-size patchset.
>
>> Hmph, that makes the --max-pack-size patchset take this more
>> trivial and straightforward improvements hostage. In general,
>> I'd prefer more elaborate ones based on less questionable
>> series.
>
> The max-pack-size and pack.compression patches touch the same lines.
> I thought my options were:
> * Submit independently and make you merge; or
> * Make one precede the other.
> Since max-pack-size has been out there since April 4 and
> the first acceptable version was May 1 (suggested by 0 comments),
> I didn't realize it was a "questionable series".
No, what I meant was that it is much "more elaborate" series
than this custom compression which is much "less questionable".
I think this custom compression is 1.5.2 material. I have not
studied the code for the max-pack-size enough to be confident to
put it in 1.5.2, at least not yet, and was planning to park the
latter in 'next' until 1.5.2 final.
^ permalink raw reply
* Re: [PATCH] gitweb: Do not use absolute font sizes
From: Junio C Hamano @ 2007-05-09 5:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20070509014150.7477.48489.stgit@rover>
Petr Baudis <pasky@ucw.cz> writes:
> Avoid specifying font sizes in pixels, since that is just pure evil.
> Pointed out by Chris Riddoch.
>
> Note that this is pretty much just a proposal; I didn't test if everything
> fits perfectly right, but things seem to be pretty much okay. repo.or.cz
> uses it now as a test drive - if you find any visual quirks, please point
> them out, with a patch if possible since I'm total CSS noob and debugging
> CSS is an extremely painful experience for me.
This looks like going in the right direction, but...
> gitweb/gitweb.css | 19 +++++++++----------
> 1 files changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
> index 6c662a1..df12d78 100644
> --- a/gitweb/gitweb.css
> +++ b/gitweb/gitweb.css
> @@ -1,6 +1,5 @@
> body {
> font-family: sans-serif;
> - font-size: 12px;
> border: solid #d9d8d1;
> border-width: 1px;
> margin: 10px;
> @@ -31,7 +30,7 @@ img.logo {
> div.page_header {
> height: 25px;
> padding: 8px;
> - font-size: 18px;
> + font-size: 150%;
> font-weight: bold;
> background-color: #d9d8d1;
> }
> @@ -113,7 +112,7 @@ span.signoff {
>
> div.log_link {
> padding: 0px 8px;
> - font-size: 10px;
> + font-size: 70%;
> font-family: sans-serif;
> font-style: normal;
> position: relative;
[12, 18, 10] / 12 * 100 = [100, 150, 83.33]
why not use 83% for what were originally 10px?
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Daniel Barkalow @ 2007-05-09 5:05 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <11786309071033-git-send-email-tytso@mit.edu>
On Tue, 8 May 2007, Theodore Ts'o wrote:
> This allows the user to regenerate the deltas in packs while doing
> a git-gc. The user could just run git-repack -a -d -f -l after
> running git-gc, but then the first git-repack run by git-gc is
> a bit of waste.
Maybe git-gc should have an option for "compress hard"? It seems to me
like a two-sizes-fit-all solution would be good here; "git gc" for daily
use, and "git gc --squeeze" for when you want to make the result as small
as possible, with compute time not being a major factor. If all you know
is that you're going to burn this repository onto a stack of CDs and mail
it to somebody (but don't know about delta reuse, window sizes, and
depths, let alone good values for these), it would be good to have an
option where it picks an appropriate different set of defaults for you.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Junio C Hamano @ 2007-05-09 5:05 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Johannes Schindelin, git
In-Reply-To: <7vps5azlm1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
>> The organization of the next bit is slightly confusing: we're set up to
>> expect a longer lecture on the revision walker, but instead there's just
>> the historical note on git-rev-list, a mention of 'revision.c',
>> 'revision.h', and 'struct rev_info', and then it rapidly digresses into
>> discussing builtins.
>
> I had the same impression.
>
> I was meaning to write a "code walkthru for git hackers and
> wannabes" with target audience quite different from the
> user-manual. My idea of which areas to cover in what order
> seems to match with what Johannes started.
Having said that, I do not think the patch belongs to the "git
USER'S manual". It is a very good introductory material for a
separate "git hackers manual", though.
^ permalink raw reply
* Re: [PATCH] Add pack.depth option to git-pack-objects and change default depth to 50
From: Junio C Hamano @ 2007-05-09 5:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Theodore Tso, Git Mailing List
In-Reply-To: <alpine.LFD.0.99.0705081323040.24220@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 8 May 2007, Theodore Tso wrote:
>
>> On Tue, May 08, 2007 at 11:38:46AM -0400, Nicolas Pitre wrote:
>> > On Tue, 8 May 2007, Theodore Ts'o wrote:
>> >
>> > > Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
>> >
>> > I'd prefer if tests were performed on the performance impact before
>> > changing the default depth. If done separately from this patch then the
>> > commit log could contain those results as well.
>>
>> The following results are on a recent git repository, using time to
>> record the real, user, and sys times on the two commands: "git-gc
>> --no-reuse-delta --window=X --depth=Y" and "git log --pretty=oneline
>> -S'object' > /dev/null". All of these tests were done with a hot
>> cache, so disk speed didn't enter into the calculations.
> [...]
>> My conclusion given this quick benchmark is that it seems to me that
>> changing the defaults of --depth to 50, and keeping --window at 10, is
>> a reasonable thing to do.
>
> Effectively.
>
> I'd still prefer to see the default changed in a patch of its own
> though.
I'll split the patch into two and apply them separately.
^ permalink raw reply
* Re: [PATCH/RFC] diff: Make numstat machine friendly also for renames
From: Junio C Hamano @ 2007-05-09 4:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200705081433.58931.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>> The --stat format is for human consumption, and --numstat (be it
>> with -z or without) is for machines, so I am not opposed to a
>> format change that gives information that is already computed
>> but currently is hard to parse. If the format change breaks
>> existing scripts, we might want to do --numstat-extended,
>> though...
>>
>> For example, I do not see a reason not to add "R98" in there.
>> I.e.
>>
>> added deleted status TAB "src" (TAB "dst"){0,1} LF
>> added deleted status NUL "src" (NUL "dst"){0,1} NUL
>>
>> where the dst path is present only when status says it is a
>> rename/copy, just like the --raw format.
>
> That is a good idea, but wouldn't it break existing scripts? Well,
> break more than a bit hacky idea of using NUL NUL as separator between
> pre-image name and post-image name.
I think both would break equally. That's why I hinted --numstat-extended,
but I think the information is getting to be about --machine-readable, and
not necessarily about "stat" anymore.
^ permalink raw reply
* Re: minimize_url in git-svn?
From: Junio C Hamano @ 2007-05-09 4:56 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Seth Falcon
In-Reply-To: <20070508193455.GA14602@muzzle>
Eric Wong <normalperson@yhbt.net> writes:
> .rev_db is offset-based database. Revision numbers to git commits can
> be looked up using (SVN revision * 41).
Ah, that explains why the file looks so sparse. Their trunk/
seems to be somewhat inactive and activities elsewhere in the
branch/ namespace we cannot view may advance SVN revisions.
>> * Assuming there aren't any damage, or maybe some damage that
>> would cause minor decreased functionality/interoperability,
>> would it perhaps make sense to optionally allow skipping the
>> minimizing to avoid this problem? Would it make sense, or is
>> the setting at socialtext site too esoteric and it isn't
>> worth to worry about?
>
> It *should* be automatically detecting the highest level up it can
> access and stop there. In your case, there's obviously something
> broken in my code :(
Perhaps, but if the user has the proper user identity to access
the full site, I suspect you would be better off getting the
credential and connect to the higher level. In other words, the
definition of "the highest level up it can access" depends on
the user and what the user is trying to do (i.e. a user who does
have an account with that project may not be interested in
getting tags/ nor branches/, in which case the user may want to
be able to say "I am not interested in uplevel" upfront, so that
the program does not even have to ask for the password. On the
other hand the user may want to access tags/ and branches/ in
which case the user would appreciate the current behaviour,
asking for the password and go up after authenticated).
> I've definitely tested this as working against Seth Falcon's hedgehog
> repo (URL is somewhere in the archives). I also setup a test repository
> somewhere that I can double-check against.
>
>> [Footnote]
>>
>> *1* http://www.socialtext.net/stoss/index.cgi?developing_with_a_dev_env
>
> I'll try to take a look at that in the next few days. I also have
> segfaults to fix that I haven't gotten to :(
Thanks. If I type <Return> instead of ^C in the transcript at
the beginning of my message, I get a segfault. It may or may
not be the same one you have been chasing.
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Daniel Barkalow @ 2007-05-09 4:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Karl Hasselström, bfields, junio, git
In-Reply-To: <Pine.LNX.4.64.0705090105450.4167@racer.site>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; CHARSET=X-UNKNOWN, Size: 2423 bytes --]
On Wed, 9 May 2007, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 8 May 2007, Karl Hasselström wrote:
>
> > On 2007-05-08 23:07:04 +0200, Johannes Schindelin wrote:
> >
> > > On Tue, 8 May 2007, Karl Hasselström wrote:
> > >
> > > > On 2007-05-08 17:10:47 +0200, Johannes Schindelin wrote:
> > > >
> > > > > + char *`, but is actually expected to be a pointer to `unsigned
> > > > > + char[20]`. This variable will contain the big endian version of the
> > > > > + 40-character hex string representation of the SHA-1.
> > > >
> > > > Either it should be "unsigned char[40]" (or possibly 41 with a
> > > > terminating \0), or else you shouldn't be talking about
> > > > hexadecimal since it's just a 20-byte big-endian unsigned integer.
> > > > (A third possibility is that I'm totally confused.)
> > >
> > > It is 40 hex-character, but 20 _byte_. If you have any ideas how to
> > > formulate that better than I did...
> >
> > I think this is less confusing:
> >
> > This variable will contain the 160-bit SHA-1.
> >
> > It avoids talking of hex, since it's not really stored in hex format
> > any more than any other binary number with a number of bits divisible
> > by four. And it avoids saying big-endian, which is not relevant anyway
> > since we don't use hashes as integers.
>
> Well, I do not buy into that. First, we _have_ to say that it is
> big-endian. It was utterly confusing to _me_ that the hash was not little
> endian, as I expected on an Intel processor.
SHA-1 is defined as producing a octet sequence, and to have a canonical
hex digit sequence conversion with the high nibbles first. Internally, it
is canonically specified using big-endian math, but the same algorithm
could equally be specified with little-endian math and different rules for
input and output.
> And I'd rather mention the hex representation (what you see in git-log and
> git-ls-tree). This helps debugging, believe me.
It's kind of important to distinguish between the hex representation and
the octet representation, because your code will not work at all if you
use the wrong one. And "unsigned char *" or "unsigned char[20]" is always
the octets; the hex is always "char *". Primarily mentioning the one that
is more intuitive but less frequently used doesn't help with understanding
the actual code.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Han-Wen Nienhuys @ 2007-05-09 4:41 UTC (permalink / raw)
To: git; +Cc: Marco Costalba, git
In-Reply-To: <463F14FF.F8DF11EB@eudaptics.com>
Johannes Sixt escreveu:
> The next big thing to think about is an installer. Does anyone have a
> suggestion for a free installer tool? I only know about Microsoft's WiX
> (wix.sf.net), but it requires .NET (for the developer, not the user).
I packaged Mingw GIT using NSIS some time ago; see
http://lilypond.org/git/binaries/mingw/
Due various personal reasons, I haven't been able to update this, but I
will package a new version soon. Please try it to see whether there are
any rough edges.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Paul Mackerras @ 2007-05-09 4:28 UTC (permalink / raw)
To: Marco Costalba
Cc: Alex Riesen, Linus Torvalds, Karl Hasselstr?m, Junio C Hamano,
Carl Worth, Michael Niedermayer, Git Mailing List
In-Reply-To: <e5bfff550705072330h3b59f4a5off5f9e341ccf3e7e@mail.gmail.com>
Marco Costalba writes:
> Language to use is C++, not C (much more powerful IMHO)
Sorry, C++ is not an option because I dislike it so much. The main
reason for changing languages would be to enable people like Linus to
hack on it more easily, and I don't think C++ would achieve that.
> P.S: If you choose Qt/C++ (the best technically speaking ;-) please
> you could consider starting from an already laid out code base instead
> of starting from scratch.
> As example, hmmmm, I think there is one called 'qgit', if I remember
> correctly. It's nice and very very very fast.
Yes, but isn't there already a talented hacker working on that? :)
Paul.
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Junio C Hamano @ 2007-05-09 4:06 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Johannes Schindelin, git
In-Reply-To: <20070509031803.GA27980@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> The organization of the next bit is slightly confusing: we're set up to
> expect a longer lecture on the revision walker, but instead there's just
> the historical note on git-rev-list, a mention of 'revision.c',
> 'revision.h', and 'struct rev_info', and then it rapidly digresses into
> discussing builtins.
I had the same impression.
I was meaning to write a "code walkthru for git hackers and
wannabes" with target audience quite different from the
user-manual. My idea of which areas to cover in what order
seems to match with what Johannes started.
- sha1_name.c;
- read_sha1_file();
- revision.c::setup_revisions() to talk about parsing but not
about walking yet.
- start from builtin-merge-base.c into commit.c to talk about
revision traversal done by get_merge_bases(). This codepath
is much simpler than the revision.c machinery and is a good
primer to understand the latter.
- builtin-diff-tree.c to show one tree and two tree cases, go
into log-tree.c then tree-diff.c to show the use of
add_remove() and change() callbacks, and then finally talk
about diff_flush(), without talking about diffcore
transformations yet.
- start from builtin-log.c to review the setup_revisions(),
then talk about prepare_revision_walk() and get_revision()
machinery, first pass without talking about path limiting and
then with path limiting.
- fetch-pack.c and upload-pack.c to talk about the native
protocol over ssh and local forking, how revision traversal
machinery is used, the "objects pointed by refs are complete"
contract.
- daemon.c to see how upload-pack is invoked.
- read_cache(), active_cache[], active_nr and friends;
- update-index and write-tree, including how cache-tree
optimizes tree writing after small updates. Advanced students
can also look at git-apply here.
- unpack-trees.c and builtin-read-tree.c to talk about index stages.
- diffcore transformations, especially diffcore-rename.
- merge-recursive
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: J. Bruce Fields @ 2007-05-09 3:45 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Johannes Sixt, git
In-Reply-To: <20070508145311.GA31152@diana.vm.bytemark.co.uk>
On Tue, May 08, 2007 at 04:53:11PM +0200, Karl Hasselström wrote:
> I would introduce it with a paragraph or two right where committing is
> covered the first time. Explain that the empty file list box to the
> left contains the changes that will be committed when you press the
> commit button, and that the file list box on the right contains the
> changes that won't be committed. By clicking on a file name you get to
> see the diff to the file, and by clicking on the icon you move it to
> the other file list box -- that is, you stage/unstage it.
>
> And now comes the clever part: Introduce the index, by explaining that
> it essentially _is_ the left file list box. Explain that git-add is
> the command-line equivalent of moving changes to the left box, and
> that git-commit without arguments simply commits what's in the index
> -- exactly like git-gui's Commit button.
>
> I think it could work. :-)
Definitely, sounds fun.
For the in-tree documentation, maybe I'm just my crusty text-centric
commandline point of view, but I'd rather have the primary explanation
continue to depend only on text and commandline examples, and then add a
note telling people that playing with git-gui may help develop their
intuition for the way the index works.
But I think it'd be interesting to try out the above approach with
screenshots, etc., on a web page someplace. It might also make a good
visual aid for a talk.
--b.
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: J. Bruce Fields @ 2007-05-09 3:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: junio, git
In-Reply-To: <Pine.LNX.4.64.0705081709230.4167@racer.site>
On Tue, May 08, 2007 at 05:10:47PM +0200, Johannes Schindelin wrote:
>
> In http://thread.gmane.org/gmane.comp.version-control.git/42479,
> a birdview on the source code was requested.
>
> J. Bruce Fields suggested that my reply should be included in the
> user manual, and there was nothing of an outcry, so here it is,
> not even 2 months later.
Looks helpful, concise, and to the point. Neat-o.
Acked-by: J. Bruce Fields <bfields@citi.umich.edu>
Comments, nothing major:
> +If you grasp the ideas in that initial commit (it is really small and you
> +can get into it really fast, and it will help you recognize things in the
> +much larger code base we have now), you should go on skimming `cache.h`,
> +`object.h` and `commit.h`.
Might want to add "in a recent commit"?--it's not clear that you've
transitioned away from talking about the initial commit.
> +This is just to get you into the groove for the most libified part of Git:
> +the revision walker.
Unless the reader has already been hanging out on the mailing list a
while, "most libified" may not mean much to them yet at this point.
The organization of the next bit is slightly confusing: we're set up to
expect a longer lecture on the revision walker, but instead there's just
the historical note on git-rev-list, a mention of 'revision.c',
'revision.h', and 'struct rev_info', and then it rapidly digresses into
discussing builtins.
Which actually is fine, but just a few small markers of where we are in
the discussion might be reassuring--a section header or two, maybe a
little more emphasis on the pointers you're giving, like: "take a moment
to go read revision.h and revision.c now, paying special attention to
struct rev_info, which ....".
--b.
^ permalink raw reply
* Re: git rebase chokes on directory -> symlink -> directory
From: H. Peter Anvin @ 2007-05-09 2:43 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20070508215009.GA2670@steel.home>
Alex Riesen wrote:
>
> What kind of manual fixup did you do? I tried to reproduce it, and did
> the following:
>
> git clone --reference ~/linux.git git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-newsetup.git
> cd linux-2.6-newsetup.git
> git rebase a989705c4cf6e6c1a339c95f9daf658b4ba88ca8
>
> It stopped at 'Revert "x86-64: Make arch/x86-64/boot a symlink to
> arch/i386/boot"' aka cd312503f8e8a88895b12bf810677406284142e6.
> I went on:
>
> rm arch/x86-64/boot
> git checkout cd312503f8e8a88895b12bf810677406284142e6 arch/x86-64/boot
> git rebase --continue
>
> And then it just continued until all commits were rebased.
> I have a very recent git, so maybe that's why it worked.
>
Mine stops already at the directory -> symlink checkin (the above is the
symlink -> directory one), but your trick of using "git checkout" as a
trick to resolve things helped for both... eventually :-/
Either way, it's still a bug that it stops for either checkin, but it's
not blocking my work anymore.
-hpa
^ permalink raw reply
* [PATCH] gitweb: Do not use absolute font sizes
From: Petr Baudis @ 2007-05-09 1:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <6efbd9b70705071613p23017509qaf9af12c1d14f9cb@mail.gmail.com>
Avoid specifying font sizes in pixels, since that is just pure evil.
Pointed out by Chris Riddoch.
Note that this is pretty much just a proposal; I didn't test if everything
fits perfectly right, but things seem to be pretty much okay. repo.or.cz
uses it now as a test drive - if you find any visual quirks, please point
them out, with a patch if possible since I'm total CSS noob and debugging
CSS is an extremely painful experience for me.
Note that this patch actually does change visual look of gitweb in Firefox
with my resolution and default settings - everything is bigger and I can't
explain the joy of actually seeing gitweb text that is in _readable_ size;
also, my horizontal screen real estate feels better used now. But judging
from the look of most modern webpages on the 'net, most people prefer
reading the web with strained eyes and/or a magnifying glass (I wonder what
species of scientists should look into this mystifying phenomenon) - so,
please tell us what you think.
Maybe we might want to get rid of absolute sizes other than font sizes in
the CSS file too in the long term.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.css | 19 +++++++++----------
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 6c662a1..df12d78 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -1,6 +1,5 @@
body {
font-family: sans-serif;
- font-size: 12px;
border: solid #d9d8d1;
border-width: 1px;
margin: 10px;
@@ -31,7 +30,7 @@ img.logo {
div.page_header {
height: 25px;
padding: 8px;
- font-size: 18px;
+ font-size: 150%;
font-weight: bold;
background-color: #d9d8d1;
}
@@ -113,7 +112,7 @@ span.signoff {
div.log_link {
padding: 0px 8px;
- font-size: 10px;
+ font-size: 70%;
font-family: sans-serif;
font-style: normal;
position: relative;
@@ -204,13 +203,13 @@ table.blame {
table.blame td {
padding: 0px 5px;
- font-size: 12px;
+ font-size: 100%;
vertical-align: top;
}
th {
padding: 2px 5px;
- font-size: 12px;
+ font-size: 100%;
text-align: left;
}
@@ -232,14 +231,14 @@ tr.dark:hover {
td {
padding: 2px 5px;
- font-size: 12px;
+ font-size: 100%;
vertical-align: top;
}
td.link, td.selflink {
padding: 2px 5px;
font-family: sans-serif;
- font-size: 10px;
+ font-size: 70%;
}
td.selflink {
@@ -416,7 +415,7 @@ div.index_include {
}
div.search {
- font-size: 12px;
+ font-size: 100%;
font-weight: normal;
margin: 4px 8px;
position: absolute;
@@ -444,7 +443,7 @@ a.rss_logo {
background-color: #ff6600;
font-weight: bold;
font-family: sans-serif;
- font-size: 10px;
+ font-size: 70%;
text-align: center;
text-decoration: none;
}
@@ -455,7 +454,7 @@ a.rss_logo:hover {
span.refs span {
padding: 0px 4px;
- font-size: 10px;
+ font-size: 70%;
font-weight: normal;
border: 1px solid;
background-color: #ffaaff;
^ permalink raw reply related
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Nicolas Pitre @ 2007-05-09 1:23 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <56b7f5510705081725v655d2ce1j28712507cfa7fa55@mail.gmail.com>
On Tue, 8 May 2007, Dana How wrote:
> Since max-pack-size has been out there since April 4 and
> the first acceptable version was May 1 (suggested by 0 comments),
> I didn't realize it was a "questionable series".
>
> I think it should be straightforward for me to re-submit this
> based on current master.
Since this patch is simpler it could be merged much faster, before the
pack limit series.
> > > + /* differing core & pack compression when loose object -> must
> > recompress */
> > > + if (!entry->in_pack && pack_compression_level !=
> > zlib_compression_level)
> > > + to_reuse = 0;
> > > + else
> > I am not sure if that is worth it, as you do not know if the
> > loose object you are looking at were compressed with the current
> > settings.
> You do not know for certain, that is correct. However, config
> settings setting unequal compression levels signal that you
> care differently about the two cases. (For me, I want the
> compression investment to correspond to the expected lifetime of the file.)
> Also, *if* we have the knobs we want in the config file,
> I don't think we're going to be changing these settings all that often.
>
> If I didn't have this check forcing recompression in the pack,
> then in the absence of deltification each object would enter the pack
> by being copied (in the preceding code block) and pack.compression
> would have little effect. I actually experienced this the very first
> time I imported a large dataset into git (I was trying to achieve the
> effect of this patch by changing core.compression dynamically, and
> was a bit mystified for a while by the result).
>
> Thus, if core.loosecompression is set to speed up git-add, I should
> take the time to recompress the object when packing if pack.compression
> is different (of course the hit of not doing so will be lessened by
> deltification
> which forces a new compression).
Right. And this also depends whether or not you have core.legacyheaders
set to false or not.
And the whole purpose for setting core.legacyheaders is exactly to allow
for loose objects to be copied straight into the pack. This should have
priority over mismatched compression levels IMHO.
Also, when repacking, delta reuse does not recompress objects for the
same reason, regardless of the compression level used when they were
compressed initially. Same argument goes for delta depth.
So if you really want to ensure a compression level on the whole pack,
you'll have to use -f with git-repack. Or leave core.legacyheaders
unset.
Nicolas
^ permalink raw reply
* Re: [PATCH] remove unnecessary loop
From: Liu Yubao @ 2007-05-09 1:03 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20070508093902.GB9007@efreet.light.src>
Jan Hudec wrote:
> On Tue, May 08, 2007 at 12:49:35 +0800, Liu Yubao wrote:
>> +#ifdef __CYGWIN__
>> + /*
>> + * On cygwin, lstat("hello", &st) returns 0 when
>> + * "hello.exe" exists, so test with open() again.
>> + */
>> + if (lstat(match, &st) && -1 != (fd = open(match, O_RDONLY))) {
>> + struct dir_entry *ent;
>> + close(fd);
>> +#else
>> if (!lstat(match, &st)) {
>> struct dir_entry *ent;
>> -
>> +#endif
>
> You seem to have reversed the sense of the test.
>
Sorry I made a mistake, Junio's suggestion is pretty clean, and
that test should be
if (!lstat(match, &st) && -1 != (fd = open(match, O_RDONLY))) {
Yesterday I digged the Cygwin mail archive, I found it's a concession for windows
as you said in the previous message. I agree with you, just let it be.
Once more, I get the lesson: Windows is poor, sigh...
^ permalink raw reply
* [PATCH] Optimized cvsexportcommit: calling 'cvs status' only once instead of once per changed file.
From: Steffen Prohaska @ 2007-05-08 23:59 UTC (permalink / raw)
To: git
The old implementation executed 'cvs status' for each file touched by
the patch
to be applied. The new code calls 'cvs status' only once and parses
cvs's
output to collect status information of all files contained in the
cvs working
copy.
Runtime is now independent of the number of modified files. A
drawback is that
the new code retrieves status information for all files even if only
a few are
touched. The old implementation may be noticeably faster for small
patches to
large workingcopies. However, the old implementation doesn't scale if
more
files are touched, especially in remotely located cvs repositories.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-cvsexportcommit.perl | 45 ++++++++++++++++++++++++++++++++++
+----------
1 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 6ed4719..f2c4bc4 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -160,36 +160,61 @@ foreach my $p (@afiles) {
}
}
+# ... check dirs,
foreach my $d (@dirs) {
if (-e $d) {
$dirty = 1;
warn "$d exists and is not a directory!\n";
}
}
+# ... query and store status of files by parsing output of 'cvs
status',
+my @cvsoutput;
+my %cvsstat;
+open CVSSTAT, "cvs status 2>&1 |" || die "failed to query cvs status";
+@cvsoutput=<CVSSTAT>;
+close CVSSTAT || die "failed to query cvs status";
+my ( $dir, $status, $file );
+foreach my $f (@cvsoutput) {
+# cvs reports directories on stderr before reporting file status on
stdout
+# using basename of 'Repository revision:' should be a safe way to
deal with whitespace in filenames.
+ chomp $f;
+ if ( $f =~ /^cvs status: Examining (.*)$/ ) {
+ $dir = $1;
+ if ( $dir ne "." ) {
+ $dir .= "/";
+ } else {
+ $dir = "";
+ }
+ } elsif ( $f =~ /Status: (.*)$/ ) {
+ $status = $1;
+ } elsif ( $f =~ /^ Repository revision:/ ) {
+ $f =~ s/,v$//;
+ $f =~ /([^\/]*)$/;
+ $file = $1;
+ $cvsstat{"$dir$file"} = $status;
+ }
+}
+
+# ... validate new files,
foreach my $f (@afiles) {
# This should return only one value
if ($f =~ m,(.*)/[^/]*$,) {
my $p = $1;
next if (grep { $_ eq $p } @dirs);
}
- my @status = grep(m/^File/, safe_pipe_capture(@cvs, '-q',
'status' ,$f));
- if (@status > 1) { warn 'Strange! cvs status returned more than
one line?'};
- if (-d dirname $f and $status[0] !~ m/Status: Unknown$/
- and $status[0] !~ m/^File: no file /) {
+ if (defined ($cvsstat{$f})) {
$dirty = 1;
warn "File $f is already known in your CVS checkout -- perhaps it
has been added by another user. Or this may indicate that it exists
on a different branch. If this is the case, use -f to force the merge.
\n";
- warn "Status was: $status[0]\n";
+ warn "Status was: $cvsstat{$f}\n";
}
}
-
+# ... validate known files.
foreach my $f (@files) {
next if grep { $_ eq $f } @afiles;
# TODO:we need to handle removed in cvs
- my @status = grep(m/^File/, safe_pipe_capture(@cvs, '-q',
'status' ,$f));
- if (@status > 1) { warn 'Strange! cvs status returned more than
one line?'};
- unless ($status[0] =~ m/Status: Up-to-date$/) {
+ unless (defined ($cvsstat{$f}) and $cvsstat{$f} eq "Up-to-date") {
$dirty = 1;
- warn "File $f not up to date in your CVS checkout!\n";
+ warn "File $f not up to date but has status '$cvsstat{$f}' in your
CVS checkout!\n";
}
}
if ($dirty) {
--
1.5.1.2
^ 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