* Re: git failing to create new branches, depending on the name
From: Thomas Rast @ 2009-08-08 17:04 UTC (permalink / raw)
To: Artur Skawina; +Cc: Git Mailing List, Daniel Barkalow
In-Reply-To: <4A7D9AA7.1030709@gmail.com>
Artur Skawina wrote:
> + git checkout -f -b branch-g90bc1a6 askern/release
> fatal: git checkout: branch branch-g90bc1a6 already exists
This bisects to
commit 352eadc40024b141e1295693654ec20cc123844f
Author: Daniel Barkalow <barkalow@iabervon.org>
Date: Sun Sep 21 14:36:06 2008 -0400
Check early that a new branch is new and valid
If you fail to update refs to change branches in checkout, your index
and working tree are left already updated. We don't have an easy way
to undo this, but at least we can check things that would make the
creation of a new branch fail. These checks were in the shell version,
and were lost in the C conversion.
The messages are from the shell version, and should probably be made nicer.
[jc: added test to t7201]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not sure this is a bug though. If we allow branch names that are
ambiguous to rev-parse, what do they resolve to? E.g., in the
presence of only 'master', 'master-g01234567' is defined to be the
same as 01234567. What is it if you also have a *branch* called
'master-g01234567'?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 0/7] block-sha1: improved SHA1 hashing
From: Linus Torvalds @ 2009-08-08 17:10 UTC (permalink / raw)
To: Artur Skawina; +Cc: Git Mailing List
In-Reply-To: <4A7D0E7B.3030601@gmail.com>
On Sat, 8 Aug 2009, Artur Skawina wrote:
>
> I've inlined the byteswapping in 'opensslb', maybe that one will
> do a bit better.
>
> http://www.src.multimo.pl/YDpqIo7Li27O0L0h/sha1bench.tar.gz
Hmm. Testing on my atom, the inlined bswap is worse, but the asm versions
are generally superior to any C one:
# TIME[s] SPEED[MB/s]
rfc3174 2.194 27.82
rfc3174 2.19 27.87
linus 0.947 64.45
linusph 0.9381 65.06
linusv 0.8943 68.25
linusvph 0.8803 69.34
linusasm 0.9349 65.29
linusp4 1.006 60.66
linusas 1.062 57.48
linusas2 1.009 60.5
mozilla 2.264 26.96
mozillaas 2.197 27.78
openssl 0.648 94.19
opensslb 0.7419 82.27
spelvin 0.636 95.96
spelvina 0.6671 91.49
nettle 0.717 85.12
nettle-ror 0.7137 85.52
nettle-p4sch 0.7158 85.27
Interestingly, -mtune=prescott does well for that 'linusv' version on atom
too, and gets it up to
linusv 0.8365 72.96
and it's the only one that improves. Odd interactions.
Linus
^ permalink raw reply
* Re: git failing to create new branches, depending on the name
From: Artur Skawina @ 2009-08-08 17:33 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git Mailing List, Daniel Barkalow
In-Reply-To: <200908081904.58186.trast@student.ethz.ch>
Thomas Rast wrote:
> Artur Skawina wrote:
>> + git checkout -f -b branch-g90bc1a6 askern/release
>> fatal: git checkout: branch branch-g90bc1a6 already exists
>
> This bisects to
>
> commit 352eadc40024b141e1295693654ec20cc123844f
> Author: Daniel Barkalow <barkalow@iabervon.org>
> Date: Sun Sep 21 14:36:06 2008 -0400
>
> Check early that a new branch is new and valid
> Not sure this is a bug though. If we allow branch names that are
well, it didn't say it didn't like the name, and sent me looking
for bugs in my scripts for quite a while, until i realized what's
going on...
> ambiguous to rev-parse, what do they resolve to? E.g., in the
> presence of only 'master', 'master-g01234567' is defined to be the
> same as 01234567. What is it if you also have a *branch* called
> 'master-g01234567'?
I'd expect the branch namespace to take precedence, unless branches
ending in -g01234567 are illegal, but that seems like an odd limitation.
Note that currently this works:
+ ( cd /tmp/build-tree/ && git checkout -f whatever/random-name-g90bc1a6 )
HEAD is now at 90bc1a6... Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus
which doesn't seem right either.
artur
^ permalink raw reply
* Re: git failing to create new branches, depending on the name
From: Daniel Barkalow @ 2009-08-08 17:35 UTC (permalink / raw)
To: Artur Skawina; +Cc: Git Mailing List
In-Reply-To: <4A7D9AA7.1030709@gmail.com>
On Sat, 8 Aug 2009, Artur Skawina wrote:
> One of my build scripts, which takes a 'work' git tree, clones it to
> make a build tree, then creates an unique branch there and goes on
> to do the rest of the work, started mysteriously failing recently
> .
> Turns out git doesn't like the branch names that my script is
> choosing and git-checkout fails with a misleading fatal error.
> I don't remember changing the script recently and it used to work
> for months, something must have changed.
>
> This is what i did while trying to find why the checkout is failing:
>
> + git --version
> git version 1.6.4
> + rm -rf /tmp/build-tree
> + git clone -l -s -n -o askern --reference /tmp/work-tree /tmp/work-tree /tmp/build-tree
> Initialized empty Git repository in /tmp/build-tree/.git/
> + cd /tmp/build-tree
> + git branch -a | grep g90bc1a6
> + git checkout -f -b branch-g90bc1a6 askern/release
> fatal: git checkout: branch branch-g90bc1a6 already exists
> # WTF?
Perhaps it shouldn't say "branch branch-g90bc1a6", but...
> + (
> + cd /tmp/work-tree
> + git branch -a | grep g90bc1a6
> + )
> # nothing in parent repo either.
> + git checkout -f branch-g90bc1a6
> Checking out files: 100% (29109/29109), done.
"branch-g90bc1a6" does already exist, in the sense that you can already
check it out. It's probably a bad idea, from the point of view of having
your repository make sense, to have a branch whose name is a valid name
for a different commit (or, in any case, a commit not specified by the
current value of the branch).
The check was added (restored, actually; it had been lost in the
conversion to C) in order to prevent people from accidentally making local
branches named things like "origin/master" when there's a remote branch
named that.
> Note: moving to 'branch-g90bc1a6' which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
> git checkout -b <new_branch_name>
> HEAD is now at 90bc1a6... Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus
> # so where is coming from?
The official documentaion on specifying revisions is in the man page for
git-rev-parse (it's referenced for a bunch of places, although this is
obviously not the first place you'd think to look).
The error message should probably be improved to not imply that what's
already using that name is a branch.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 0/7] block-sha1: improved SHA1 hashing
From: Artur Skawina @ 2009-08-08 18:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.01.0908081004560.3288@localhost.localdomain>
Linus Torvalds wrote:
>
> On Sat, 8 Aug 2009, Artur Skawina wrote:
>> I've inlined the byteswapping in 'opensslb', maybe that one will
>> do a bit better.
> Hmm. Testing on my atom, the inlined bswap is worse, but the asm versions
> are generally superior to any C one:
It loses on atom, but is the best one on both P3 and P4 here.
Based on your other numbers I was expecting it to win on 32-bit
nehalem too. gcc doing a better job of scheduling w/ 'linusv'
wouldn't surprise though (since there are no spills, the data reads
are about the only other thing that could make a difference. And, yes,
they show up in the profiles; if x86 only had one more register...)
artur
^ permalink raw reply
* Re: [PATCH 1/6 (v2)] revision caching documentation: man page and technical discussion
From: Junio C Hamano @ 2009-08-08 18:31 UTC (permalink / raw)
To: Nick Edelen
Cc: Nicolas Pitre, Johannes Schindelin, Sam Vilain, Michael J Gruber,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <op.uyb1uuu4tdk399@sirnot.private>
"Nick Edelen" <sirnot@gmail.com> writes:
> Before any code is introduced the full documentation is put forth. This
> provides a man page for the porcelain, and a technical doc in technical/. The
> latter describes the API, and discusses rev-cache's design, file format and
> mechanics.
>
> Signed-off-by: Nick Edelen <sirnot@gmail.com>
Quite respectable work, in that not many people try to start from
specification.
I'll ask quite a many questions in the following. I do not want you to
explain them to _me_ in your response. I am asking them so that the v3
and subsequent revision will remove the need for these questions to be
asked by somebody (other than me) who reads the document.
> Documentation/git-rev-cache.txt | 96 +++++++++
> Documentation/technical/rev-cache.txt | 379 +++++++++++++++++++++++++++++++++
> 2 files changed, 475 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-rev-cache.txt b/Documentation/git-rev-cache.txt
> new file mode 100755
An executable documentation?
> index 0000000..600cf64
> --- /dev/null
> +++ b/Documentation/git-rev-cache.txt
> @@ -0,0 +1,96 @@
> +git-rev-cache(1)
> +================
> +
> +NAME
> +----
> +git-rev-cache - Add, walk and maintain revision cache slices.
Drop the last '.'; also you may need to add this command to the command
classification list so that "man git" would know where to include this in
its command list.
> +SYNOPSIS
> +--------
> +'git-rev-cache' COMMAND [options] [<commit>...]
> +
> +DESCRIPTION
> +-----------
> +A front end for the rev-cache API. It is mainly intended for cache slice
> +generation and maintenance, but can also walk commits within a slice. It
> +currently provides basic administrative functionality.
> +
Briefly discuss
- what rev-cache is for (e.g. "an optional mechanism to speed up
revision traversal");
- what a cache slice is (e.g. "records such and such for a set of commit
objects");
- how these two relate to each other (e.g. "one or more slices are tied
together with a single rev-cache-index to form a rev-cache); and
- how a rev-cache relates to a repository or an object store (e.g. "a
given repository can have up to N rev-cache that describes its
objects")
here.
> +COMMANDS
> +--------
> +
> +add
> +~~~
> +Add revisions to the cache by creating a new cache slice. Reads a revision
> +list from the command line, formatted as: `START START ... \--not END END ...`
> +
> +Options:
> +
> +\--all::
> + Include all branch heads in the new cache slice.
Is this "all branch heads"? Shouldn't it be "all refs?" If not, why not?
> +\--fresh::
> + Exclude everything already in the revision cache.
This concept seems to correspond to --incremental in pack-objects parlance.
> +\--stdin::
> + Read newline-seperated revisions from the standard input. Use \--not
> + to exclude commits, as on the command line.
> +
> +\--legs::
> + Ensure newly-generated cache slice is self-contained. This means that
> + no commit has partially cached parents, in that all its parents are
> + cached or none of them are.
If I am reading the description correctly what you mean is that for a
history:
---A---C---D
/
---B
a slice is allowed to consist of (empty), (D), (C D), (A B C D), but not
(A C D), if it wants to be "--legs compliant".
But without your definition in the second and third line, people would not
call (C D) "self-contained", as you cannot tell what C's parents are.
Because you do not use "self-containedness" in the rest of documentation
to explain other things, you do not need to introduce such an unintuitive
definition of a word. I'd suggest dropping the first line.
Also for the lack of better word I said "--legs compliant" above. We do
need a better word to express this concept, and use that as the option
name. Unfortunately, I can tell "legs" is not it, but I cannot offhand
think of what word should it be.
> +\--noobjects::
> + Non-commit objects are normally included along with the commit with
> + which they were introduced. This is obviously very benificial, but can
> + take longer in cache slice generation. Use this option to disable
> + non-commit object caching.
"--no-objects" (I think you meant reverse of --objects to rev-list).
What is the ramification of using this option? "rev-list" and "gitk" will
still be fast but "pack-objects" won't get as much speed-up? Will use of
the option affect correctness? Can a slice generated with this option
later fused with another generated without this option? What are the
performance (or correctness) characteristics of a resulting slice of such
a fuse?
If the target audience of this manual page is Porcelain writers and API
users, these things need to be explained somewhere in this documentation.
> +walk
> +~~~~
> +Walk a cache slice based on revision list, formatted like 'add'.
What is formatted like 'add'? The output from the command? The command
line arguments this subcommand takes?
Define "walk". Is it "dump the contents of a slice"? In a rev-cache with
more than one slice, which slice is chosen to be walked, and how? How
does the command line argument and options interract with cached data?
For example...
> +Options:
> +
> +\--objects::
> + Like 'git-rev-list', 'walk' will normally only list commits. Use this
> + option to list non-commit objects as well.
... how does walking with --objects option behave if you created all of
your slices with --no-objects? Does it notice the lack of cached object
information and falls back on reading from the objects? If so how is this
different from rev-list itself? If not, when is the walk command useful?
"while debugging the rev-cache machinery" is a perfectly acceptable answer
to the last question, but if that is the case please say so in the
documentation.
> +fuse
> +~~~~
> +Merge several cache slices into a single large slice. On each invocation of
> +'add' a new file ("slice") is added to the revision cache directory, and after
> +several additions the directory may become populated with many, relatively
> +small slices. Numerous smaller slices will yield poorer performance than a one
> +or two large ones, because of the overhead of loading new slices into memory.
Something like this is a perfect overview description that should have
been given upfront (remember, I earlier said "Briefly discuss..."?).
This operation feels like "repack".
> +Running 'fuse' every once in a while will solve this problem by coalescing all
> +the cache slices into one larger slice. For very large projects, using
> +\--ignore-size is advisable to prevent overly large cache slices.
> +
> +Options:
> +
> +\--all::
> + Normally fuse will only include everything that's already in the
> + revision cache. \--add tells it to start walking from the branch
> + heads, effectively an `add --all --fresh; fuse` (pseudo-command).
> +
> +\--noobjects::
> + As in 'add', this option disables inclusion of non-commit objects. If
> + some cache slices do contain such objects, the information will be lost.
> +
> +\--ignore-size[=N]::
> + Do not merge cache slices of size >=N. If N is not provided 'fuse'
> + will default to a size of ~25MB (be aware that slices must be mapped to
> + memory).
Should this autotune, perhaps relative to pack.windowMemory? --ignore
sounds misnomer; it is similar to "keep" flag that packfiles have.
> +index
> +~~~~~
> +Regenerate the cache index. If the index file associating objects with cache
> +slices gets corrupted, lost, or otherwise becomes unusable, 'index' will
> +quickly regenerate the file. 'fuse' will also regenerate the index.
We already have .git/index (the index), and .git/objects/pack/pack-*.idx
(pack idx files). At least please call this "the rev-cache index" so that
technical documentations can differentiate when they want to talk about
this new index without having to worry about disambiguities.
At the beginning of your DESCRIPTION, you mentioned "rev-cache", then
"cache slice", without explaining what they are, or how they relate to
each other, leaving frustration to the readers. The reader who reads on,
suppressing this frustration, is finally rewarded at the beginning of
"fuse" description, where you mention that a rev-cache contains one or
more cache slices. At that point, how these two concepts relate to each
other is finally revealed.
But here, you introduce a new frustration. There is no meantion in how
the rev-cache index relates to the other two concepts introduced earlier
(the rev-cache itself, and cache slices).
When is this "reindex" operation necessary under normal circumstances? Is
it primarily to recover bugs in rev-cache? For example, "repack -a -f" is
not about recovering from bugs in "repack" but is a way to squeeze out
more redundancy from your pack because repeated "repack -a" may degrade
the pack efficiency over time. Is "reindex" useful for a similar reason,
even when the rev-cache mechanism is bug-free?
> diff --git a/Documentation/technical/rev-cache.txt b/Documentation/technical/rev-cache.txt
> new file mode 100755
Executable documentation.
> index 0000000..78d7218
> --- /dev/null
> +++ b/Documentation/technical/rev-cache.txt
> @@ -0,0 +1,379 @@
> +rev-cache
> +=========
> +
> +The revision cache API ('rev-cache') provides a method for efficiently storing
> +and accessing commit branch sections. Such branch slices are defined by a
> +series of top (interesting) and bottom (uninteresting) commits. Each slice
> +contains, per commit:
> +
> +* All intra-slice topological relations, encoded into path "channels" (see
> + 'Mechanics' for full explanation).
> +* Object meta-data: type, SHA-1, size, date (for commits).
> +* Objects introduced in that commit, relative to slice (ie. only for non-start
> + commits).
"introduced"? That is a bit puzzling description to me, probably because
of an untold assumption.
Do you mean, in a two-commit history "B builds on top of root A", your
slice lists objects by traversing topology from the top, so commit A is
listed, and the tree and its subtrees and blobs are "introduced to the
slice", and then commit B is listed, along with its tree and associated
objects that have not been listed in the slice before commit B (namely,
objects commit B changed since commit A) are "introduced to the slice (by
commit B)"?
You can alley the above puzzlement by saying something like:
Each slice stores information on commits and its associated
objects, in the topological order traversing from the top
commits. For each commit, the following is recorded:
> +Storage data structures are not exported, in part to keep git's global scope
> +clean, but largely because they're pretty much useless outside of rev-cache.
> +
> +The API
> +-------
> +
> +The API for 'rev-cache' is quite simple. You can find the function prototypes
> +in `revision.h`.
Drop the first sentence and leave the judging of simplicity to the reader.
> +Data Structures
> +~~~~~~~~~~~~~~~
> +
> +The `rev_cache_info` struct holds all the options and flags for the API.
> +
> +----
> +struct rev_cache_info {
> + /* generation flags */
> + unsigned objects : 1,
> + legs : 1,
> + make_index : 1;
> +
> + /* traversal flags */
> + unsigned save_unique : 1,
> + add_to_pending : 1,
> + add_names : 1;
> +
> + /* fuse options */
> + unsigned int ignore_size;
> +};
> +----
> +
> +The fields:
> +
> +`objects`::
> + Add non-commit objects to slice.
> +
> +`legs`::
> + Ensure end commits have no children.
What are "end commits"?
> +`make_index`::
> + Integrate newly-made slice into index.
> +
> +`save_unique`::
> + Load non-commit objects into `unique` field of their associated
> + `commit` object.
What is "unique" field? What is it used for? Is it a list that can hold
many objects?
> +`add_to_pending`::
> + Append unique non-commit objects to the `pending` object list in the
> + passed `rev_info` instance.
> +
> +`add_names`::
> + Include non-commit object names in the pending object entries (if
> + `add_to_pending` is set), and set the `name` field of `blob` and `tree`
> + objects (if `save_unique`).
> +
> +`ignore_size`::
> + If non-zero, ignore slices with size greater or equal to this during
> +fusion.
> +
> +Functions
> +~~~~~~~~~
> +
> +`init_rci`::
> + Initiate a `rev_cache_info` struct to default options.
"Initialize"?
Spell it out like "init_rev_cache_info()". It's not like you will be
calling this over and over again, and "i" is ambiguous between rev cache
info and rev cache index.
> +`make_cache_slice`::
> + Create a cache based on an a `rev_info` instance or `commit_list` s of
> + "starts" and "ends" (defaulting to latter if `rev_info` pointer is
> + NULL), copying the cache SHA-1 into a passed pointer if non-zero. A
What's "cache SHA-1"? I imagine that rev-cache consists of one or more
cache slices, and each slice is named after the hash value of its data,
but the documentation should not make _me_ guess.
Also a pointer is either NULL or non-NULL; it is never "zero".
> + `rev_cache_info` struct pointer can be passed to set options, while
> + passing NULL will set default options. A last parameter can
> + optionally recieve the final cache hash.
Is it just me who wish to see list of parameters on the head line, e.g.
make_cache_slice(struct rev_info *, ...)::
to understand what the description is talking about better?
> +`make_cache_index`::
> + Add a slice to the cache index. Requires a file descriptor, the cache
> + hash and the file size. Note that this is normally called by
> + `make_cache_slice` under the `make_index` option.
A file descriptor points at what file? The index is written to that
descriptor? The slice is read from the descriptor? What is "cache hash"?
File size of what file is taken as parameter?
> +`get_cache_slice`::
> + Given a commit SHA-1 `get_cache_slice` will search the slice index and
> + return, if found, the cache-identifying SHA-1.
Is there a "slice index"? How does it relate to "the cache index" the
earlier documentation mentioned in its description of the "index"
subcommand?
> +`traverse_cache_slice`::
> + Traverse a specified cache slice based on:
> +
> + * `rev_info` instance; options set in the `rev_cache_info` field.
> + * cache SHA-1 identifier
> + * a starting commit and commit work list
> + * date of oldest encountered interesting commit (passing 0 will tell
> + rev-cache to use defaults)
> + * current `slop` (this is a counter, a la `revision.c`, to determine
> + when to stop traversing; typically you can just pass 0 and rev-cache
> + will use default settings)
> +
> ++
> +The output is sent to a FILO `commit_list` "queue", while any end commits
> +are passed back into the work list. If the walk is not contained within the
> +slice, commit boundaries are also inserted into "work".
> +
> +`start_from_slices`::
> + Will mark all start-commits in the specified cache slices with a given
> + flag, and add them to the rev pending list. Will include all if no
> + slices are specified.
> +
> +`coagulate_cache_slices`::
> + Generate a slice based on the passed `rev_info` instance, replacing all
> + encountered slices with one (larger) slice. The `ignore_size` field in
> + `rci`, if non-zero, will dictate which cache slice sizes to ignore in
> + both traversal and replacement.
"coagulate"? If you want to say "fuse", use that word consistently.
> +Some Internals
> +--------------
> +
> +Although you really don't need to know anything about how rev-cache actually
> +does its magic shizz, a bit of background may go a long way if you're wading
> +through the source.
Drop these three lines. People know that already when they are reading
this section.
> +File Formats
> +~~~~~~~~~~~~
> +
> +A slice has a basic fixed-size header, followed by a certain number of object
> +entries, then a NULL-seperated list of object names. Commits are sorted in
> +topo-order, and each commit entry is followed by the objects added in that
> +commit.
What's in the header? Is there a version number?
> +struct object_entry {
Rename this to something more rev-cache specific, perhaps rev_cache_entry,
as the name is already used for different purposes in pack-objects and
fast-import.
> + unsigned type : 3;
> + unsigned is_end : 1;
> + unsigned is_start : 1;
> + unsigned uninteresting : 1;
> + unsigned include : 1;
> + unsigned flags : 1;
> + unsigned char sha1[20];
> +
> + unsigned merge_nr : 6;
> + unsigned split_nr : 7;
> + unsigned size_size : 3;
> + unsigned name_size : 3;
> + unsigned what_to_do : 5;
> +
> + uint32_t date;
> + uint16_t path;
> +
> + /* merge paths */
> + /* split paths */
> + /* size */
> + /* name index */
> +};
> +----
> +
> +An explanation of each field:
> +
> +`type`::
> + Object type
> +`is_end`::
> + The commit has some parents outside the cache slice (all if slice has
> + legs)
> +`is_start`::
> + The commit has no children in cache slice
You said "top" and "bottom" in the documentation. Perhaps use them
here as well for consistency?
> +`uninteresting`::
> + Run-time flag, used in traversal
> +`include`::
> + Run-time flag, used in traversal (initialization)
> +`flags`::
> + Currently unused, extra bit
> +`sha`::
> + Object SHA-1 hash
That's `sha1` if I am reading the above display correctly.
> +`merge_nr`::
> + The number of paths the current channel diverges into; the current path
> + ends upon any merge.
> +`split_nr`::
> + The number of paths this commit ends; used on both merging and
> + branching.
How will an overflowing situation handled?
> +`size_size`::
> + Number of bytes the object size takes up.
> +`name_size`::
> + Number of bytes the name index takes up.
> +`what_to_do`::
> + Currently space-filler, to properly align the struct fields. Can
> + potentially be used for anything.
You seem to be assuming that 24-bit fields starting at merge_nr (begins at
offset 21) will be packed and it is Ok that after this filler field date
is aligned to multiple of 4. I am not sure if that is a safe assumption.
We use 'unsigned long' for timestamps. Is uint32_t sufficient?
What is `path` (not "merge paths" nor "split paths" you explain next)?
Is uint32_t sufficient?
> +merge paths::
> + The path IDs (16-bit) that are to be created.
> +split paths::
> + The path IDs (16-bit) that are to be ended.
Are 65536 paths sufficient? How will an overflowing situation handled?
> +size::
> + The size split into the minimum number of bytes.
> +name index::
> + An offset for the null-seperated, object name list at the end of the
> + cache slice. Also split into the minimum number of bytes.
What does this mean? 1-to-8 bytes integer in network byte order?
Did you consider using the variable-length size representation used by the
pack object layer (cf. encode_header() in builtin-pack-objects.c and
unpack_object_header_buffer() in sha1_file.c)?
> +
> +Each path ID refers to an index in a 'path array', which stores the current
> +status (eg. active, interestingness) of each channel.
> +
> +Due to topo-relations and boundary tracking, all of a commit's parents must be
> +encountered before the path is reallocated. This is achieved by using a
> +counter system per merge: starting at the parent number, the counter is
> +decremented as each parent is encountered (dictated by 'split paths'); at 0 the
> +path is cleared.
> +
> +Boundary tracking is necessary because non-commits are stored relative to the
> +commit in which they were introduced. If a series of commits is not included
> +in the output, the last interesting commit must be parsed manually to ensure
> +all objects are accounted for.
> +
> +To prevent list-objects from recursing into trees that we've already taken care
> +of, the flag `FACE_VALUE` is introduced. An object with this flag is not
> +explored (= "taken at face value"), significantly reducing I/O and processing
> +time.
> +(NSE)
You do not need this last line. As 530e741 (Start preparing the API
documents., 2007-11-24) mention, these were pointers to people who may
know enough information to fill in _undocumented_ territory. You
documented this API fairly completely.
Besides, nobody would know who NSE is ;-). Back then, there were only
handful of people, all of whom can be ientified by short names, who were
responsible for large body of internal API code that needed further
documentation.
^ permalink raw reply
* Re: [PATCH] gitweb: squelch harmless variable scoping errors
From: Junio C Hamano @ 2009-08-08 18:40 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git, Jakub Narebski, Mark A Rada
In-Reply-To: <F203660D-5123-475D-8288-F398EA670002@mailservices.uwaterloo.ca>
Mark A Rada <marada@uwaterloo.ca> writes:
> I fiddled around a bit and this solution seems to work, but is a bit
> odd, as the method is declared obsolete in the Perl documentation
> (v5.8.8).
>
> What do you think?
I'd prefer to summon our resident Perl expert ;-)
> --
> Mark A Rada (ferrous26)
> marada@uwaterloo.ca
>
>
> --->8---
> This will use the 'vars' method of declaring global variables instead
> of the 'our' method.
>
> Though 'vars' has been obsoleted, it has the advantage of pre-declaring
> global symbols; this ensures that those symbols will be available to
> routines loaded later, whereas 'our' does not seem to do this.
>
> The result is that when using mod_perl you will no longer get any
> warnings printed to your error_log.
>
> Signed-off-by: Mark Rada <marada@uwaterloo.ca>
> ---
> gitweb/gitweb.perl | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 37120a3..0544aa2 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -57,12 +57,14 @@ if ($path_info) {
> our $GIT = "++GIT_BINDIR++/git";
>
> # absolute fs-path which will be prepended to the project path
> -#our $projectroot = "/pub/scm";
> -our $projectroot = "++GITWEB_PROJECTROOT++";
> +use vars qw($projectroot);
> +#$projectroot = "/pub/scm";
> +$projectroot = "++GITWEB_PROJECTROOT++";
>
> # fs traversing limit for getting project list
> # the number is relative to the projectroot
> -our $project_maxdepth = "++GITWEB_PROJECT_MAXDEPTH++";
> +use vars qw($project_maxdepth);
> +$project_maxdepth = "++GITWEB_PROJECT_MAXDEPTH++";
>
> # target of the home link on top of all pages
> our $home_link = $my_uri || "/";
> --
> 1.6.4
^ permalink raw reply
* Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Junio C Hamano @ 2009-08-08 18:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nick Edelen, Michael J Gruber, Junio C Hamano, Jeff King,
Sam Vilain, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0908062030340.8306@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> My idea with that was that you already have a SHA-1 map in the pack index,
> and if all you want to be able to accelerate the revision walker, you'd
> probably need something that adds yet another mapping, from commit to
> parents and tree, and from tree to sub-tree and blob (so you can avoid
> unpacking commit and tree objects).
>
> I just thought that it could be more efficient to do it at the time the
> pack index is written _anyway_, as nothing will change in the pack after
> that anyway.
After reading the version 2 of the "documentation" patch and commenting
heavily on it, I partly share the same feeling with you. The codepath to
pack objects is _one of the places_ you can generate rev-cache and slice
information without redoing a lot of work that has already been done
anyway.
But
- You can write that information separately out to a different file.
Logically it does not have to be _in_ the same pack idx file; and
- You may want to generate rev-cache information even if you do not pack
the repository. They may practically go hand-in-hand, but logically
they are orthogonal.
And I am not sure if it is easy to retrofit "rev-list | pack-objects" code
to additionally produce this information, while keeping the standalone
version of rev-cache generation.
Having said all that.
I haven't read the side of the patch that _uses_ the information stored in
the rev-cache to figure out what it optimizes and what its limitations are
(e.g. how it interacts with pathspecs). Perhaps the rev-cache may turn
out to be _only_ useful for pack-objects and nothing else, in which case
we may not care about standalone version of rev-cache generator after all.
If that is the case, I think it is also a reasonable implementation if the
rev-cache is generated only by "rev-list | pack-objects" codepath as a
side effect of traversal it already does, and it might even make sense to
introduce the version 3 of pack idx format that let you record additional
information, like you suggest. I am not ready to make that judgement as I
haven't read the rest, but my gut feeling tells me that you might be
right.
^ permalink raw reply
* [PATCH] pull: Change tab to spaces in error mesage
From: Matt Kraai @ 2009-08-08 18:51 UTC (permalink / raw)
To: git, gitster; +Cc: Matt Kraai
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
git-pull.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 0f24182..9ad3662 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -99,7 +99,7 @@ error_on_no_merge_candidates () {
else
echo "You asked me to pull without telling me which branch you"
echo "want to merge with, and 'branch.${curr_branch}.merge' in"
- echo "your configuration file does not tell me either. Please"
+ echo "your configuration file does not tell me either. Please"
echo "specify which branch you want to merge on the command line and"
echo "try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 4/9] add missing long option to 'git grep' bash competion
From: Junio C Hamano @ 2009-08-08 19:48 UTC (permalink / raw)
To: Emmanuel Trillaud; +Cc: Shawn O. Pearce, git
In-Reply-To: <9f50533b0908080156h23415740lb94cbd9f2c6a165d@mail.gmail.com>
Emmanuel Trillaud <etrillaud@gmail.com> writes:
> according to the 'git-grep' man page, the following long options are missing
> from the 'git grep' bash completion :
> --null
> --color
> --no-color
I do not think completion's purpose should be to offer everything
available under the sun, so "according to manpage these are missing" can
never be a good justification for patches in this series.
Does it even make sense to complete --null in an interactive invocation?
^ permalink raw reply
* Re: [PATCH 6/9] update 'git-rm' bash completion according to the man page
From: Junio C Hamano @ 2009-08-08 19:49 UTC (permalink / raw)
To: Emmanuel Trillaud; +Cc: Shawn O. Pearce, git
In-Reply-To: <9f50533b0908080156t7cfd05ebg3e5d29f7d2260c25@mail.gmail.com>
Emmanuel Trillaud <etrillaud@gmail.com> writes:
> Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
Description of what you did?
> - __gitcomp "--cached --dry-run --ignore-unmatch --quiet"
> + __gitcomp "--force --cached --dry-run --ignore-unmatch --quiet"
I thought not completing --force to allow a dangerous operation was a
conscious decision.
^ permalink raw reply
* Re: [PATCH 7/9] update 'git-show' bash completion to match the man page
From: Junio C Hamano @ 2009-08-08 19:49 UTC (permalink / raw)
To: Emmanuel Trillaud; +Cc: Shawn O. Pearce, git
In-Reply-To: <9f50533b0908080156j33db6f99u18de79537677451b@mail.gmail.com>
Emmanuel Trillaud <etrillaud@gmail.com> writes:
> Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
What did you add?
> - __gitcomp "--pretty= --format= --abbrev-commit --oneline
> + __gitcomp "--pretty= --format= --abbrev-commit --oneline --encoding
Is it not "--encoding="? If not, why not?
^ permalink raw reply
* Re: [PATCH 9/9] update 'git apply' bash-completion according to its man page
From: Junio C Hamano @ 2009-08-08 19:50 UTC (permalink / raw)
To: Emmanuel Trillaud; +Cc: Shawn O. Pearce, git
In-Reply-To: <9f50533b0908080157r6e58a6a4rf42ff684d095c002@mail.gmail.com>
Emmanuel Trillaud <etrillaud@gmail.com> writes:
> ---
> contrib/completion/git-completion.bash | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 8ba1249..c08422c 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -694,9 +694,15 @@ _git_apply ()
> --*)
> __gitcomp "
> --stat --numstat --summary --check --index
> - --cached --index-info --reverse --reject --unidiff-zero
> - --apply --no-add --exclude=
> + --cached
> + --build-fake-ancestor=
> + --index-info --reverse --reject --unidiff-zero
> + --apply --no-add
> + --exclude=
> + --include=
> --whitespace= --inaccurate-eof --verbose
> + --recount
> + --directory=
I'd rather suggest dropping --no-add that is script-only and not useful in
interactive use. I also won't add --build-fake-ancestor for the same
reason.
^ permalink raw reply
* Re: [PATCH 5/9] add missing long options to 'git push bash completion'
From: Junio C Hamano @ 2009-08-08 19:50 UTC (permalink / raw)
To: Emmanuel Trillaud; +Cc: Shawn O. Pearce, git
In-Reply-To: <9f50533b0908080156n3e990a69lc54e8ab4f0422d0a@mail.gmail.com>
Emmanuel Trillaud <etrillaud@gmail.com> writes:
> according to git-push(1), the following long-options are missing to the bash
> completion :
> --porcelain
> --thin
> --no-thin
Does it even make sense to complete --porcelain in interactive session?
For that matter, I think being able to control --thin/--no-thin outlived
their usefulness. Have you ever used them to toggle this aspect of the
behaviour per invocation?
^ permalink raw reply
* Re: [PATCH 4/9] add missing long option to 'git grep' bash competion
From: Emmanuel Trillaud @ 2009-08-08 20:07 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vskg2dr3o.fsf@alter.siamese.dyndns.org>
> > according to the 'git-grep' man page, the following long options are
> > missing from the 'git grep' bash completion :
> > --null
> > --color
> > --no-color
>
> I do not think completion's purpose should be to offer everything
> available under the sun, so "according to manpage these are missing" can
> never be a good justification for patches in this series.
When I saw that completion for the long options of 'git checkout' was
mising, I just start looking around the docs to see if there wasn't other
git commands with some missing completions. I see now it was a wrong way
to update the git bash completion. I will soon come back with a new set
of (more reasonnable) patches.
Emmanuel
^ permalink raw reply
* Re: [PATCH 6/9] update 'git-rm' bash completion according to the man page
From: Emmanuel Trillaud @ 2009-08-08 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljludr2d.fsf@alter.siamese.dyndns.org>
> > - __gitcomp "--cached --dry-run --ignore-unmatch
> > --quiet"
> > + __gitcomp "--force --cached --dry-run
> > --ignore-unmatch --quiet"
>
> I thought not completing --force to allow a dangerous operation was a
> conscious decision.
For me, completion as always been a reminder for options I forgot (or I
think they exist) and I use short options when I know them because it is
easier to type. So IMHO '--force' is a useful option that deserve to be
complete.
But if you make a conscious decision in the past to not complete
'--force', I won't fight :-) and I will just add a comment in the
git-completion script for the guys like me who think it is missing.
Best regard
Emmanuel
^ permalink raw reply
* [PATCH js/run-command-updates] api-run-command.txt: describe error behavior of run_command functions
From: Johannes Sixt @ 2009-08-08 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Documentation/technical/api-run-command.txt | 31 ++++++++++++++++++++++++--
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/Documentation/technical/api-run-command.txt
b/Documentation/technical/api-run-command.txt
index 2efe7a4..b26c281 100644
--- a/Documentation/technical/api-run-command.txt
+++ b/Documentation/technical/api-run-command.txt
@@ -35,12 +35,32 @@ Functions
Convenience functions that encapsulate a sequence of
start_command() followed by finish_command(). The argument argv
specifies the program and its arguments. The argument opt is zero
- or more of the flags `RUN_COMMAND_NO_STDIN`, `RUN_GIT_CMD`, or
- `RUN_COMMAND_STDOUT_TO_STDERR` that correspond to the members
- .no_stdin, .git_cmd, .stdout_to_stderr of `struct child_process`.
+ or more of the flags `RUN_COMMAND_NO_STDIN`, `RUN_GIT_CMD`,
+ `RUN_COMMAND_STDOUT_TO_STDERR`, or `RUN_SILENT_EXEC_FAILURE`
+ that correspond to the members .no_stdin, .git_cmd,
+ .stdout_to_stderr, .silent_exec_failure of `struct child_process`.
The argument dir corresponds the member .dir. The argument env
corresponds to the member .env.
+The functions above do the following:
+
+. If a system call failed, errno is set and -1 is returned. A diagnostic
+ is printed.
+
+. If the program was not found, then -1 is returned and errno is set to
+ ENOENT; a diagnostic is printed only if .silent_exec_failure is 0.
+
+. Otherwise, the program is run. If it terminates regularly, its exit
+ code is returned. No diagnistic is printed, even if the exit code is
+ non-zero.
+
+. If the program terminated due to a signal, then the return value is the
+ signal number - 128, ie. it is negative and so indicates an unusual
+ condition; a diagnostic is printed. This return value can be passed to
+ exit(2), which will report the same code to the parent process that a
+ POSIX shell's $? would report for a program that died from the signal.
+
+
`start_async`::
Run a function asynchronously. Takes a pointer to a `struct
@@ -143,6 +163,11 @@ string pointers (NULL terminated) in .env:
To specify a new initial working directory for the sub-process,
specify it in the .dir member.
+If the program cannot be found, the functions return -1 and set
+errno to ENOENT. Normally, an error message is printed, but if
+.silent_exec_failure is set to 1, no message is printed for this
+special error condition.
+
* `struct async`
--
1.6.4.87.g9ec6e
^ permalink raw reply related
* Re: [PATCH js/run-command-updates] api-run-command.txt: describe error behavior of run_command functions
From: Junio C Hamano @ 2009-08-08 20:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200908082244.20476.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> Documentation/technical/api-run-command.txt | 31 ++++++++++++++++++++++++--
> 1 files changed, 28 insertions(+), 3 deletions(-)
Thanks.
^ permalink raw reply
* [PATCH v2] Re: push: point to 'git pull' and 'git push --force' in case of non-fast forward
From: Nicolas Sebrecht @ 2009-08-08 22:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, Teemu Likonen, git
In-Reply-To: <7vy6pujmsc.fsf@alter.siamese.dyndns.org>
The 08/08/09, Junio C Hamano wrote:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> > Teemu Likonen <tlikonen@iki.fi> writes:
> >
> > Right, but I don't think this error message is the place to discuss
> > that. Anything involving rebasing should be taken with care, and
> > pointing the user to it in a short sentence sounds like "try shooting
> > yourself in the foot, and read the man page if it hurts" ;-).
>
> Instead of saying "Merge in", we could say "Integrate" to cover both
> practices. I also happen to think that the mention of --force falls into
> the same category as "try shooting and then study if it hurgs".
I'd say that everywhere we try to guess what the user should do (and
telling him to do so) falls into this category. Of course, some
operations are really destructive with no way to recover to a previous
state where some other operations aren't destructive at all. But Git can
be used in many various workflows and telling ― in an error/warning
message ― what the user should do may hurt some of the workflows and/or
finally confuse the beginners. Actually, I believe that a message with
only "See the /WONDERFULL/ section in the /LEARN_GIT/ man page" is the
best answer.
Also, I think that mentionning --force is the worst thing to do because
the beginner will immediatly run it without thinking of all the
consequences at all: "Oh, we could do that, let's try".
> So how about phrasing it like this?
>
> Non-fast forward pushes were rejected because you would discard remote
> changes you have not seen. Integrate them with your changes and then
> push again. See 'non-fast forward' section of 'git push --help'.
Well, a beginner may rewrite a commit whithout realize what he did. If he is
the only to work on the projet, this message is somewhat wrong.
What about
Non-fast forward pushes were rejected because you would discard remote
changes. See 'non-fast forward' section of 'git push --help'.
?
--
Nicolas Sebrecht
^ permalink raw reply
* [PATCH] git-instaweb: fix mod_perl detection for apache2
From: Mark A Rada @ 2009-08-08 22:24 UTC (permalink / raw)
To: git
The script was looking for something that matched the '^our $gitbin'
regex, which no longer exists in gitweb.cgi.
Now it looks for 'MOD_PERL', which should be on the line that checks
to see if the script is running in a mod_perl environment.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
---
git-instaweb.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 32f6496..5f5cac7 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -278,7 +278,7 @@ EOF
# check to see if Dennis Stosberg's mod_perl compatibility patch
# (<20060621130708.Gcbc6e5c@leonov.stosberg.net>) has been applied
- if test -f "$module_path/mod_perl.so" && grep '^our $gitbin' \
+ if test -f "$module_path/mod_perl.so" && grep 'MOD_PERL' \
"$GIT_DIR/gitweb/gitweb.cgi" >/dev/null
then
# favor mod_perl if available
--
1.6.4
^ permalink raw reply related
* Re: [PATCH 0/7] block-sha1: improved SHA1 hashing
From: Artur Skawina @ 2009-08-08 22:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <4A7D0E7B.3030601@gmail.com>
Artur Skawina wrote:
> Linus Torvalds wrote:
>> magic? I force the stores to the 512-bit hash bucket to be done in order.
>> That seems to help a lot.
>
> I named it 'linusv':
> linusv 0.3697 165.1
I was not going to spend even more time on the C version, but after looking
at what gcc does to it, tried this:
diff --git a/block-sha1/sha1vol.c b/block-sha1/sha1vol.c
--- a/block-sha1/sha1vol.c
+++ b/block-sha1/sha1vol.c
@@ -93,7 +93,7 @@ void blk_SHA1_Finalv(unsigned char hashout[20], blk_SHA_CTX *ctx)
/* This "rolls" over the 512-bit array */
#define W(x) (array[(x)&15])
-#define setW(x, val) (*(volatile unsigned int *)&W(x) = (val))
+#define setW(x, val) W(x) = (val); __asm__ volatile ("": "+m" (W(x)))
/*
* Where do we get the source from? The first 16 iterations get it from
and got a nice improvement:
rfc3174 1.436 42.49
linus 0.5843 104.5
linusph 0.5639 108.2
linusv 0.3098 197
linusvph 0.3082 198.1
linusasm 0.5849 104.3
linusp4 0.433 141
linusas 0.4077 149.7
linusas2 0.436 140
mozilla 1.099 55.54
mozillaas 1.295 47.11
openssl 0.2632 231.9
opensslb 0.2395 254.8
spelvin 0.2687 227.2
spelvina 0.2526 241.7
nettle 0.4378 139.4
nettle-ror 0.4379 139.4
nettle-p4sch 0.4231 144.2
The atom numbers didn't change much.
artur
^ permalink raw reply
* Re: [PATCH 0/7] block-sha1: improved SHA1 hashing
From: Artur Skawina @ 2009-08-08 23:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <4A7E030E.2040301@gmail.com>
Artur Skawina wrote:
> Artur Skawina wrote:
> -#define setW(x, val) (*(volatile unsigned int *)&W(x) = (val))
> +#define setW(x, val) W(x) = (val); __asm__ volatile ("": "+m" (W(x)))
and w/ this on top:
diff --git a/block-sha1/sha1vol.c b/block-sha1/sha1vol.c
--- a/block-sha1/sha1vol.c
+++ b/block-sha1/sha1vol.c
@@ -103,9 +103,9 @@ void blk_SHA1_Finalv(unsigned char hashout[20], blk_SHA_CTX *ctx)
#define SHA_MIX(t) SHA_ROL(W(t+13) ^ W(t+8) ^ W(t+2) ^ W(t), 1)
#define SHA_ROUND(t, input, fn, constant, A, B, C, D, E) do { \
- unsigned int TEMP = input(t); setW(t, TEMP); \
- E += TEMP + SHA_ROL(A,5) + (fn) + (constant); \
- B = SHA_ROR(B, 2); } while (0)
+ unsigned int TEMP = SHA_ROL(A,5); E+= (fn); \
+ E += (constant) + TEMP; TEMP = input(t); setW(t, TEMP); \
+ B = SHA_ROR(B, 2); E += TEMP; } while (0)
#define T_0_15(t, A, B, C, D, E) SHA_ROUND(t, SHA_SRC, (((C^D)&B)^D) , 0x5a827999, A, B, C, D, E )
#define T_16_19(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, (((C^D)&B)^D) , 0x5a827999, A, B, C, D, E )
I see an improvement on atom and reach ~200M/s on P4 (i686).
.
When compiled w/ '-mtune=prescott':
rfc3174 1.459 41.84
linus 0.6574 92.85
linusph 0.6613 92.29
linusv 0.2682 227.6
linusvph 0.2681 227.7
linusasm 0.5868 104
linusp4 0.3586 170.2
linusas 0.3795 160.8
linusas2 0.3583 170.3
mozilla 1.171 52.11
mozillaas 1.381 44.2
openssl 0.2623 232.7
opensslb 0.2404 253.9
spelvin 0.2659 229.6
spelvina 0.2492 244.9
nettle 0.4362 139.9
nettle-ror 0.436 140
nettle-p4sch 0.4204 145.2
it's now just 2% slower than the openssl assembler version.
artur
^ permalink raw reply
* gitk won't stay open
From: Mark Polesky @ 2009-08-08 23:44 UTC (permalink / raw)
To: git
Hi.
When I type gitk, the new window opens for about one
second, showing the history of commits, and then
quickly closes on its own. I'm on Windows XP.
Is there a known cause for this?
Thanks.
- Mark
^ permalink raw reply
* Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Sam Vilain @ 2009-08-08 23:54 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nicolas Pitre, Nick Edelen, Michael J Gruber, Junio C Hamano,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0908081709380.8306@pacific.mpi-cbg.de>
On Sat, 2009-08-08 at 17:18 +0200, Johannes Schindelin wrote:
> > Speeding up rev-list with a rev cache is completely orthogonal to
> > whether the repository is packed or not.
>
> No, it is not.
>
> For both technical and practical reasons, caching revision walker data is
> very closely related to packing.
> [...]
> ... the rev cache has a certain target audience,
> and that the regular user is not part of that audience, and that it just
> so happens that the _technical_ similarities with the pack index can be
> exploited in those scenarios?
>
> IOW we can be pretty certain that a heavy-load server has a fully (or
> next-to-fully) packed object database. The pack indices already contain a
> SHA-1 table that we can simply reuse. And it should not be hard (or
> fragile) at all to put the "cached" information about parents,
> referenced tree and blob objects into that file, into a different section.
I think your argument would work better if packs and bundles were the
same thing, and we always stored bundles in the objects/packs directory,
but they're not and we don't. You can't assume that a pack has any
particular properties, such as representing the objects returned from a
single rev-cache walk. And I will say that *especially* on a busy git
server, serving active projects you can't expect people to repack their
repository for every single update. Repacking daily or so by a batch
job, sure. Expecting the repository to always be fully packed? No.
Too much churn, or inefficient packing. You can't just pretend that the
mixed packed/loose case doesn't exist.
The 10% size seems a very good bang for your buck to me and a good
start.
Sam
^ permalink raw reply
* [PATCH] Document 'stash clear' recovery via unreachable commits
From: Thomas Rast @ 2009-08-09 0:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Björn Steinbrink
Add an example to the stash documentation that shows how to quickly
find candidate commits among the 'git fsck --unreachable' output.
Unless you have merges of branch names containing WIP, or edit your
merge messages to say WIP, there will be no false positives.
Snippet written by Björn "doener" Steinbrink and me after zepolen_
asked on IRC.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-stash.txt | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 1c64a02..2f5ca7b 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -114,7 +114,8 @@ no conflicts.
clear::
Remove all the stashed states. Note that those states will then
- be subject to pruning, and may be difficult or impossible to recover.
+ be subject to pruning, and may be impossible to recover (see
+ 'Examples' below for a possible strategy).
drop [-q|--quiet] [<stash>]::
@@ -217,6 +218,20 @@ $ edit/build/test remaining parts
$ git commit foo -m 'Remaining parts'
----------------------------------------------------------------
+Recovering stashes that were cleared/dropped erroneously::
+
+If you mistakenly drop or clear stashes, they cannot be recovered
+through the normal safety mechanisms. However, you can try the
+following incantation to get a list of stashes that are still in your
+repository, but not reachable any more:
++
+----------------------------------------------------------------
+git fsck --unreachable |
+grep commit | cut -d\ -f3 |
+xargs git log --merges --no-walk --grep=WIP
+----------------------------------------------------------------
+
+
SEE ALSO
--------
linkgit:git-checkout[1],
--
1.6.4.195.g3a1c2
^ 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