* Re: Wiki front page pointing to HelpOnLanguages
From: Matthieu Moy @ 2007-05-09 16:30 UTC (permalink / raw)
To: git
In-Reply-To: <20070509162654.GZ4489@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> yes, thanks for the report - I fixed it on Monday, but didn't notice
> your mail before now. One of the admins upgraded the machine to etch
> when I was not looking and it caused some bits to break. ;-)
Great: the formatting was also totally messed up, but I felt someone
was already working on it. That's fixed also.
Good work!
--
Matthieu
^ permalink raw reply
* [PATCH] allow for undeltified objects not to be reused
From: Nicolas Pitre @ 2007-05-09 16:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Dana How
Currently non deltified object data is always reused when possible.
This means that any change to core.compression has no effect on those
objects as they don't get recompressed when repacking them.
Let's add a --no-reuse-object flag to git-repack in order to force
recompression of all objects when desired.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index bd3ee45..ce89214 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -127,6 +127,13 @@ base-name::
This flag tells the command not to reuse existing deltas
but compute them from scratch.
+--no-reuse-object::
+ This flag tells the command not to reuse existing object data at all,
+ including non deltified object, forcing recompression of everything.
+ This implies --no-reuse-delta. Useful only in the obscur case where
+ wholesale enforcement of a different compression level on the
+ packed data is desired.
+
--delta-base-offset::
A packed archive can express base object of a delta as
either 20-byte object name or as an offset in the
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 966f843..d94c79a 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -17,9 +17,9 @@
static const char pack_usage[] = "\
git-pack-objects [{ -q | --progress | --all-progress }] \n\
[--local] [--incremental] [--window=N] [--depth=N] \n\
- [--no-reuse-delta] [--delta-base-offset] [--non-empty] \n\
- [--revs [--unpacked | --all]*] [--reflog] [--stdout | base-name] \n\
- [<ref-list | <object-list]";
+ [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] \n\
+ [--non-empty] [--revs [--unpacked | --all]*] [--reflog] \n\
+ [--stdout | base-name] [<ref-list | <object-list]";
struct object_entry {
unsigned char sha1[20];
@@ -55,7 +55,7 @@ static struct object_entry *objects;
static uint32_t nr_objects, nr_alloc, nr_result;
static int non_empty;
-static int no_reuse_delta;
+static int no_reuse_delta, no_reuse_object;
static int local;
static int incremental;
static int allow_ofs_delta;
@@ -412,7 +412,9 @@ static unsigned long write_object(struct sha1file *f,
crc32_begin(f);
obj_type = entry->type;
- if (! entry->in_pack)
+ if (no_reuse_object)
+ to_reuse = 0; /* explicit */
+ else if (!entry->in_pack)
to_reuse = 0; /* can't reuse what we don't have */
else if (obj_type == OBJ_REF_DELTA || obj_type == OBJ_OFS_DELTA)
to_reuse = 1; /* check_object() decided it for us */
@@ -425,7 +427,7 @@ static unsigned long write_object(struct sha1file *f,
* and we do not need to deltify it.
*/
- if (!entry->in_pack && !entry->delta) {
+ if (!no_reuse_object && !entry->in_pack && !entry->delta) {
unsigned char *map;
unsigned long mapsize;
map = map_sha1_file(entry->sha1, &mapsize);
@@ -1125,8 +1127,8 @@ static void check_object(struct object_entry *entry)
buf = use_pack(p, &w_curs, entry->in_pack_offset, &avail);
/*
- * We want in_pack_type even if we do not reuse delta.
- * There is no point not reusing non-delta representations.
+ * We want in_pack_type even if we do not reuse delta
+ * since non-delta representations could still be reused.
*/
used = unpack_object_header_gently(buf, avail,
&entry->in_pack_type,
@@ -1655,6 +1657,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
no_reuse_delta = 1;
continue;
}
+ if (!strcmp("--no-reuse-object", arg)) {
+ no_reuse_object = no_reuse_delta = 1;
+ continue;
+ }
if (!strcmp("--delta-base-offset", arg)) {
allow_ofs_delta = 1;
continue;
^ permalink raw reply related
* Re: [FAQ?] Rationale for git's way to manage the index
From: Dana How @ 2007-05-09 16:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Martin Langhoff, git, Junio C Hamano, danahow
In-Reply-To: <alpine.LFD.0.98.0705090825090.4062@woody.linux-foundation.org>
On 5/9/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> - I just switch back to my starting point (and now I'm usually on
> "master"), and do
>
> git diff -R target > diff
>
> to create a diff of my current tree (which is initially the starting
> point) to the good result.
>
> - I actually edit the "diff" file by hand, and edit it down to the part I
> actually want to commit as the first in the series. And then I just do
> a "git-apply diff" to actually apply that part to my working tree.
>
> - I then edit any missing parts in the actual working tree (for example,
> if there were mixed hunks that I want to get to in later commits, and I
> edited out above, or that I need to partially undo), to do any
> finishing touches.
>
> - I now have a tree I can compile and test, and has the "first part" of
> the journey towards the final "target" state. If compiling/testing
> shows that I missed something, I can still fix things, and/or go back
> to doing another "git diff -R target" to see if I missed something).
>
> - I commit that first case, and repeat the sequence from step 2 (and
> at every step, the "diff" file ends up shrinking and shrinking).
Geez, this is similar [in nature, not scale] to what I've been doing.
After reading about people "right-clicking on hunks in git-gui",
I was convinced I needed to force myself to do more manipulations
inside git itself. Hmm...
Maybe, in addition to [or in] the User Manual, git should have some
workflow examples, which have been cribbed from various emails
on this list?
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: Dana How @ 2007-05-09 16:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Git Mailing List, danahow
In-Reply-To: <7vlkfyt13i.fsf@assigned-by-dhcp.cox.net>
On 5/9/07, Junio C Hamano <junkio@cox.net> wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > So I suggest that we get rid of core.legacyheaders, preserve the legacy
> > format as the only writable loose object format and deprecate the other
> > one to keep things simpler. Thoughts?
>
> I agree with your analysis, especially when deeper delta chains
> are allowed, straight copy of loose object becomes less and less
> likely.
I too agree with the logic in the original <tangential comment>,
and deprecation is the appropriate thing. So I'm not actually
going to change anything here in today's patch.
> > What we need instead is a --no-reuse-object that would force
> > recompression of everything when you really want to enforce a specific
> > compression level across the whole pack(s).
>
> Yeah. Or maybe --no-reuse to mean both and make '-f' a
> short-hand synonym for that.
>
> I do not see much reason to want to tweak them independently;
> recomputing delta is much more expensive than recompressing
> anyway, and when the user says 'repack -f', it is a sign that
> the user is willing to spend CPU cycles.
We have the same idea about git-repack -f -- it implies both
--no-reuse-delta and --no-reuse-object , and I will do that.
I will incorporate Nicolas's new --no-reuse-object
in my patch to builtin-pack-objects.c .
I won't go so far as collapsing --no-reuse-* to --no-reuse in this patch.
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: Dana How @ 2007-05-09 16:44 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Git Mailing List, danahow
In-Reply-To: <20070509135602.GB21489@thunk.org>
On 5/9/07, Theodore Tso <tytso@mit.edu> wrote:
> I noticed that the patch didn't include additions to
> Documentation/config.txt; could those be added, so that as much as
> possible all of the various configuration knobs are documented in one
> place, please?
I will update the documentation, after we've stopped changing
the set of options and behaviors.
You can see that's just what I did in the max-pack-size patch.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: svn user trying to recover from brain damage
From: Linus Torvalds @ 2007-05-09 16:57 UTC (permalink / raw)
To: Joshua Ball; +Cc: git
In-Reply-To: <92fdc3450705090830t64c8f5b9r4af277807dfe834d@mail.gmail.com>
On Wed, 9 May 2007, Joshua Ball wrote:
>
> What the heck do these terms mean?
>
> HEAD
> HEAD REF
These are the same thing. HEAD is basically a special local branch, which
usually (but not always) points to one of the local branches. I say
"usually", because you *can* make it an independent branch in its own
right, in which case you are using what is now called a "detached" HEAD.
But even when HEAD is "detached", and it's thus really an independent
branch in its own right, it's still special: it's the branch that your
current working tree is associated with.
So if you think of "HEAD" as just "current branch", you'll be in good
shape.
> working tree
This is just your files - both untracked (ie you may be building stuff in
the working tree) and tracked (ie the ones that git knows about).
It's *not* necessarily going to match the state that HEAD describes: HEAD
describes the last *committed* state, while your working tree obviously
can have changes to the tracked files (along with files that aren't
tracked at all), but the working tree state is certainly _associated_ with
HEAD, in that HEAD would point to the most recent commit that the working
tree is all about.
> object
This is just an internal git term. It's how git stores all revision
history information - as a set of objects in a content-addressable
filesystem. As a pure user, you generally never need to worry about this
term, although you might notice in the case you have corruption, and run
"git fsck" and it starts talking about corrupt or missing objects.
> branch
A "branch" is just any "tip of development". It's *literally* defined by
its name (which git doesn't care about, but you do), and the name of the
top-most commit (the SHA1) of that developmet series. That SHA1 is all
that git really cares about - the name is purely for your enjoyment and to
clarify what the branch is about.
Git can track an arbitrary number of branches, but your working tree would
be associated with just one of them, and HEAD points to that branch. The
default branch is called "master", but that doesn't really have any
special meaning per se, and as mentioned, HEAD might even be a detached
branch and not associated with any "real" branch at all!
> merge
That's the act of bringing in the contents of another branch (possibly
from an external repository) into your current branch. If you merge from
something external, you need to "fetch" that other branch first, and the
combination of "fetch+merge" is called a "pull".
It sounds like you may have never worked with branches before, in which
case you can just ignore *all* of this. Git will set up one branch for you
at "git init" time (the "master" branch) and you don't actually ever have
to use any more than that one branch, in which case you can literally
ignore everything about branches and merging.
> master
See above: it's just the default name of the initial branch. It has no
other meaning - git itself doesn't care about branch names at all, and
it's literally nothing more than a "default branch name".
> commit (as in the phrase "bring the working tree to a given commit")
Any development series is just a series of "commits". They point to the
"parent" commit(s) and can thus form a series (or more generally a DAG:
directed acyclic graph).
So a "branch" is really just a named pointer to a commit, and that commit
will in turn point to its parent commit, which will point to its parent
etc. Which is why I started by explaining a branch as a "tip of
development", because you'd see a branch as the top-most commit that it
points to, and you'd normally *change* the branch by committing to it,
which will create a new commit (and move the branch to point to it), and
make that new commit point to the old commit as its parent.
One of the best ways to visualize this is probably to just do
- clone git itself if you haven't already
git clone git://git.kernel.org/pub/scm/git/git.git git
- use "gitk" to see the commit history and see the branches as pointers
into that commit history. With "--all -d", it will show you all
branches, and the "-d" shows the commit history in date order, so while
it's a bit messier than the default cleaned-up format that tries to
show branches on their own, it's perhaps also a bit more instructive:
gitk --all -d
In particular, you should see a commit that has both a green-boxed
"master" pointer pointing to it, and a "remotes/origin/master" (colored in
a mixed brown/green box). Those are examples of branches: the "master"
branch is your local (and normally current) brach, while the
"remotes/origin/master" thing is a so-called "remote branch", which means
that you cannot check it out, but you can see it and you can update it by
fetching new versions from the remote.
> Is there a difference between HEAD and the working tree?
Yes, see above.
> Does HEAD change when I cg-switch/git-checkout?
Yes. But it switches by making it point to a different branch, while
something like "git reset" will *also* potentially change HEAD, but do so
by still staying on the same branch, but making that branch "reset" (aka
jump) to another point in history.
So you can literally change HEAD two fundamentally different ways:
- by switching branches (which includes making HEAD be a detached branch
of its own)
- by changing the state of the current branch (the most common form of
this is just "git commit" - it will update HEAD by creating a new
commit, but as mentioned, "git reset" can also do this by jumping
around in history, and that's how you'd undo work entirely, for
example).
> What is an object? Is it a set of patches? A tree snapshot?
An object is the lowest-level of git information. It's an indivisible and
unchanging "thing", that can potentially point to other objects. You
can kind of think of it as an "inode" in a UNIX filesystem, and like an
inode, it can point to file data or be a directory (but unlike an inode,
it's immutable by design, and it can also be a "commit" or a "tag"
object).
So internally, git does have "tree snapshots" (not patches - git is
*purely* based on snapshotting states of the project), but they are not a
single object, they are built up from "tree objects" that point to other
tree objects or to "blob objects".
And a commit is literally a "commit object" that points to the snapshot
(the "tree object") that it's associated with, and the previous commits
(the "parents") that build up the history.
> What the heck is a branch? (Why does it have so many different
> definitions? I feel like every time I come across "branch" in the man
> pages, it means something different.)
Ok, hope I clarified that.
> More on branches: The wiki says that a group of commits linked
> together form a DAG. Does that mean every fork/clone/branch-create
> possibly doubles the number of branches. So if I fork and then
> remerge, do I have two branches?
Yes and no. When you do a clone, you do get your totally own set of
branches, but a branch is just a *pointer*. So it does _not_ duplicate
history in any way, you do *not* get:
> A -> B -> D
> A -> C -> D
But instead you get
A -> B -> C -> D
as commits, and you now have a new pointer to D.
So creating a branch *literally* just creates a new pointer.
In fact, you can still create a new branch manually by doing
echo "sha1-of-branch-goes-here" > .git/refs/heads/my-new-branch
and that is how the git scripts literally used to do it (well, slightly
simplified: verifying that the SHA1 is valid, and that the branch didn't
already exist).
So the branch really *is* just a named commit.
> Would D be the head of this branch? If so, then heads do not uniquely
> identify a branch?
A branch uniquely identify a particular commit, but many branches can
point to the same commit (and the branches are considered "identical" when
they do that - you can have two different branches, but if they point to
the same thing they are identical in all respectcs except for naming).
> Is there a standard revision notation? (Where my definition of
> "revision" is a tree snapshot. In SVN, it would be identified by a
> number.) `cg-diff -r A..B` works fine if A and B are branches, but how
> do I diff from an older revision to a newer revision? Can I diff
> between two revisions which haven't shared the same parent since 2006?
The "standard" revision notation is the SHA1 of the commit, but quite
frankly, you'd never use it.
If you have two branches named A and B, you'd generate the diff with
git diff A..B
and it doesn't matter if they share a parent since yesterday, since five
years ago or whether they are related AT ALL. Git will happily diff
totally unrelated branches (if you imported two tar-balls independently,
they may not have any common history at all, but you may still want to
diff them if they are from the same project!)
> What about the master branch? Is there anything special about it? By
> special I mean, do any of the git or cogito commands implicitly assume
> that you are working with master? If git is truly decentralized, then
> wouldn't master be on an equal footing with all other branches?
Correct.
The only thing that is special about master is that it's the one that is
created by "git init" (or "git clone", for that matter).
> What is a merge? My understanding of merge comes from the SVN book,
Forget SVN merges. SVN cannot do merges (SVN also cannot really do
branches - what SVN calls branches is some abhorrent and stupid copy of a
working tree with copying of the limited notion of history that SVN
knows about).
> where it was described as diff+apply. Diff takes 2 arguments, and
> apply takes a 1 argument (if the patch is implicit). However, cg-merge
> only appears to take one branch. (There again a use of the word
> branch! Wouldn't commit or revision be a more accurate term?)
(You're likely better off using just "raw git" rather than cg these days,
so I'll talk about "git merge").
A "git merge" actually does have two branches: the current one, aka HEAD,
and the one you want to merge _into_ the current one.
So when you do
git merge other-branch
it will merge 'other-branch' into the current branch (HEAD).
And no, it's not a "diff+apply" (although early and *very* broken versions
of cg implemented the data part that way), it's a much more interesting
operation that figures out the last common point from the history, and
does a series of three-way merges (especially if there were *multiple*
independent common history points), and then records the set of parents
in the result.
That, btw, is why SVN cannot do merges. It really *does* do a fancy
"diff+apply" that probably involves three-way operations too, but since it
doesn't actually remember the resulting history, it cannot be considered a
"merge". It didn't really merge the history - it just smushed the
*contents* of two branches together, and then totally threw out all the
really important bits.
> Lastly, the most important question of all, which may answer many of
> the questions above:
>
> Can you fill in the missing pieces, making corrections where
> necessary? (recommend unispace font)
>
> Command | Reads | Writes
> cg-fetch | remote branch | corresponding branch in local respository
> cg-commit | working copy | HEAD
> cg-update | remote branch | working copy AND HEAD
> cg-merge | branch & working copy | working copy
> cg-diff | arguments | STDOUT
> cg-push | | remote branch (usually origin)
> cg-pull | remote branch |
> cg-restore | |
I'll use the git names (which are generally the same)
Command | reads | writes
--------------+-----------------------+-----------
git fetch | remote branch(es) | local branch(es)
git commit | local data | HEAD
git pull | remote branch(es) | HEAD
git merge | local branch(es) | HEAD
git diff | local data |
git push | local branch(es) | remote branch(es)
git reset | --- | HEAD
and everything that writes HEAD implicitly will always also update the
working tree too (with the obvious exception of "git commit" - since it's
filling in the HEAD with the current state, it's obviously not going to
update the working tree).
The "local data" is really a combination of "local branches, staging area
and working tree": neither "git diff" and "git commit" really work purely
on the working tree, they both will mix using the staging area, the
working tree, and pure branch information depending on exact flags.
And note that most of the operations really can work on multiple branches
(that's not true in cg). IOW, you can actually merge multiple branches in
one go (the end result is called an "octopus merge", because it looks cool
and has many "legs" when you see the merge history in a bottom-to-top kind
of thing like gitk).
> On cg-fetch, is the remote branch necessarily remote? Or can you fetch
> from local
You can always consider the local tree to be a remote one: just use ".".
So
git merge other-branch
is basically the same as
git pull . other-branch
> cg-switch-branches? What does "corresponding branch in local
> repository" mean? Does cg-fetch touch your working copy?
Confusing cogito terminology.
The pure git stuff is actually clearer. And in git, you can specify what
the "corresponding" branch is for any local branch. For example, if you
just do the "git clone" of the git repository, then assuming you have a
recent enough git, you can look into the ".git/config" file of the result,
and you should see something like this:
[remote "origin"]
url = master.kernel.org:/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
which describes a remote repository ("origin") and tells you what branches
should be fetched when you do a "git fetch origin", but it *also*
describes the local branch "master", and says that when you do a "git
pull", it should merge the *remote* branch "refs/heads/master" from
"origin".
> What is the difference between cg-restore and cg-seek?
Don't use them. Cogito confusion.
Linus
^ permalink raw reply
* Re: git rebase chokes on directory -> symlink -> directory
From: H. Peter Anvin @ 2007-05-09 16:58 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0705090050i644a18c2g12c74462ab88163a@mail.gmail.com>
Alex Riesen wrote:
> On 5/9/07, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> 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 :-/
>>
>
> Hmm. What Git version do you have?
Not sure anymore, because I ran a systemwide upgrade late last night.
*Now* I have git-1.5.1.4, but I think I had 1.5.1.2 before.
>> Either way, it's still a bug that it stops for either checkin, ...
>
> Right. And because it is a bug, I'd like to have it fixed.
> So, what did you do in that fixup?
I'm sorry, I'm not sure I understand the question, in particular, I'm
getting the feeling I'm not sure what "that fixup" refers to.
-hpa
^ permalink raw reply
* Re: failing test t9400 (Re: [PATCH] git-update-ref: add --no-deref option for overwriting/detaching ref)
From: Sven Verdoolaege @ 2007-05-09 16:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Frank Lichtenheld
In-Reply-To: <7vr6pqt1fu.fsf@assigned-by-dhcp.cox.net>
On Wed, May 09, 2007 at 09:19:01AM -0700, Junio C Hamano wrote:
> Sven Verdoolaege <skimo@kotnet.org> writes:
> > Shouldn't these tests be skipped if I don't have all that stuff installed?
> > There doesn't even seem to be an option to turn off these tests.
>
> I agree. We would need something like this, but I have no easy
> way to test it myself, short of uninstalling what I need on the
> box. As you do not have them, maybe you can give it a quick
> whirl?
Seems to work, albeit with a nasty warning,
bash-3.00$ sh t9400-git-cvsserver-server.sh
Can't locate DBD/SQLite.pm in @INC (@INC contains: /usr/lib/perl5/5.8.0/i686-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl .) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
* ok 1: skipping git-cvsserver tests, Perl SQLite interface unavailable
* passed all 1 test(s)
skimo
^ permalink raw reply
* [PATCH] make "repack -f" imply "pack-objects --no-reuse-object"
From: Nicolas Pitre @ 2007-05-09 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dana How, Git Mailing List
In-Reply-To: <7vlkfyt13i.fsf@assigned-by-dhcp.cox.net>
As Junio said:
Recomputing delta is much more expensive than recompressing
anyway, and when the user says 'repack -f', it is a sign that
the user is willing to spend CPU cycles.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Wed, 9 May 2007, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > What we need instead is a --no-reuse-object that would force
> > recompression of everything when you really want to enforce a specific
> > compression level across the whole pack(s).
>
> Yeah. Or maybe --no-reuse to mean both and make '-f' a
> short-hand synonym for that.
>
> I do not see much reason to want to tweak them independently;
> recomputing delta is much more expensive than recompressing
> anyway, and when the user says 'repack -f', it is a sign that
> the user is willing to spend CPU cycles.
This applies on top of my --no-reuse-object patch. I think it is good
to have the flexibility in the plumbing, but as you say git-repack
might as well use the strongest option.
diff --git a/git-repack.sh b/git-repack.sh
index ddfa8b4..8bf66a4 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -8,7 +8,7 @@ SUBDIRECTORY_OK='Yes'
. git-sh-setup
no_update_info= all_into_one= remove_redundant=
-local= quiet= no_reuse_delta= extra=
+local= quiet= no_reuse= extra=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -16,7 +16,7 @@ do
-a) all_into_one=t ;;
-d) remove_redundant=t ;;
-q) quiet=-q ;;
- -f) no_reuse_delta=--no-reuse-delta ;;
+ -f) no_reuse=--no-reuse-object ;;
-l) local=--local ;;
--window=*) extra="$extra $1" ;;
--depth=*) extra="$extra $1" ;;
@@ -61,7 +61,7 @@ case ",$all_into_one," in
;;
esac
-args="$args $local $quiet $no_reuse_delta$extra"
+args="$args $local $quiet $no_reuse$extra"
name=$(git-pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
exit 1
if [ -z "$name" ]; then
^ permalink raw reply related
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: J. Bruce Fields @ 2007-05-09 17:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Petr Baudis, kha, junio, git
In-Reply-To: <Pine.LNX.4.64.0705091822590.4167@racer.site>
On Wed, May 09, 2007 at 06:25:01PM +0200, Johannes Schindelin wrote:
> None. I only suspected them to be carried out in byte order. From what I
> know, there are some shifts involved, which might or might not be helped
> by 32-bit arithmetic.
>
> I did not really look into it.
>
> From my prior debugging experiences on Intel, though, I automatically
> looked for the least significant bytes at the beginning of those "sha1"
> variables, and came up empty.
So, I'm confused about what you actually mean by "big endian" here. I
originally assumed that you meant that SHA1's are defined as bit arrays,
and that the first bit of the SHA1 is in the high-order bit of the first
byte. But if you just meant that the first byte of the SHA1 is stored
in the first byte of the array... that kind of goes without saying,
doesn't it?
In any case, maybe this is a detail that's best left to the code itself.
--b.
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Matthieu Moy @ 2007-05-09 17:18 UTC (permalink / raw)
To: git
In-Reply-To: <vpqbqgxak1i.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> (I would actually complain about the documentation not being clear
> enough, but I'll try to complain with a contribution instead ;-) I'll
> add something to the FAQ on the wiki, but it's down right now).
As promised, here's a FAQ entry on the wiki:
http://git.or.cz/gitwiki/GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717
Feel free to correct it.
Anyway, thanks for the interesting discussion.
--
Matthieu
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: J. Bruce Fields @ 2007-05-09 17:18 UTC (permalink / raw)
To: Dana How
Cc: Linus Torvalds, Petr Baudis, Martin Langhoff, git, Junio C Hamano
In-Reply-To: <56b7f5510705090933t261e414es9e3cc63b28b60546@mail.gmail.com>
On Wed, May 09, 2007 at 09:33:40AM -0700, Dana How wrote:
> Geez, this is similar [in nature, not scale] to what I've been doing.
> After reading about people "right-clicking on hunks in git-gui",
> I was convinced I needed to force myself to do more manipulations
> inside git itself. Hmm...
>
> Maybe, in addition to [or in] the User Manual, git should have some
> workflow examples, which have been cribbed from various emails
> on this list?
That's something several people have asked for, and I think it's a great
idea--I just haven't personally had much time to get to it. But I'd
happily take even very rough patches and help get them into shape.
The way I'd thought of doing it was having an "examples" section at the
end of each chapter, with subsections for each individual example; see
the one at the end of the "exploring git history" chapter:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#history-examples
They shouldn't use the material introduced in the associated chapter,
but it's also OK to introduce new commands (with references to the man
pages) when their use in the example is pretty self-explanatory. (In
fact, this is a great way to introduce more commands and options--git
has so many that it would be tedious to try to be comprehensive, but
they'd fit well in examples.)
The patch-editing stuff discussed above might fit best at the end of
"rewriting history and maintaining patch series".
--b.
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Petr Baudis @ 2007-05-09 17:26 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Dana How, Linus Torvalds, Martin Langhoff, git, Junio C Hamano
In-Reply-To: <20070509171845.GC23778@fieldses.org>
On Wed, May 09, 2007 at 07:18:45PM CEST, J. Bruce Fields wrote:
> On Wed, May 09, 2007 at 09:33:40AM -0700, Dana How wrote:
> > Geez, this is similar [in nature, not scale] to what I've been doing.
> > After reading about people "right-clicking on hunks in git-gui",
> > I was convinced I needed to force myself to do more manipulations
> > inside git itself. Hmm...
> >
> > Maybe, in addition to [or in] the User Manual, git should have some
> > workflow examples, which have been cribbed from various emails
> > on this list?
>
> That's something several people have asked for, and I think it's a great
> idea--I just haven't personally had much time to get to it. But I'd
> happily take even very rough patches and help get them into shape.
>
> The way I'd thought of doing it was having an "examples" section at the
> end of each chapter, with subsections for each individual example; see
> the one at the end of the "exploring git history" chapter:
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#history-examples
>
> They shouldn't use the material introduced in the associated chapter,
> but it's also OK to introduce new commands (with references to the man
> pages) when their use in the example is pretty self-explanatory. (In
> fact, this is a great way to introduce more commands and options--git
> has so many that it would be tedious to try to be comprehensive, but
> they'd fit well in examples.)
>
> The patch-editing stuff discussed above might fit best at the end of
> "rewriting history and maintaining patch series".
There is some workflow-related discussion accumulated over years in
Documentation/howto/, some of them also already suffering quite of a
bitrot. :-(
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: J. Bruce Fields @ 2007-05-09 17:29 UTC (permalink / raw)
To: Petr Baudis
Cc: Dana How, Linus Torvalds, Martin Langhoff, git, Junio C Hamano
In-Reply-To: <20070509172622.GA4489@pasky.or.cz>
On Wed, May 09, 2007 at 07:26:22PM +0200, Petr Baudis wrote:
> There is some workflow-related discussion accumulated over years in
> Documentation/howto/, some of them also already suffering quite of a
> bitrot. :-(
Yup. I think we should one-by-one update those and suck them into the
manual. (Patches accepted!)
--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 17:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v4pmmzivz.fsf@assigned-by-dhcp.cox.net>
On Tue, May 08, 2007 at 10:05:36PM -0700, Junio C Hamano wrote:
> Having said that, I do not think the patch belongs to the "git
> USER'S manual".
Well, we could remove the word "user" from the name. There's a pretty
good continuum between users and hackers, and that's as it should be.
(Where do you document "porcelain" level stuff?)
> It is a very good introductory material for a separate "git hackers
> manual", though.
But that would be OK too, as long as we have a clear idea how we're
going to decide what goes in which manual. No need to wait until the
whole thing's done--we could commit an initial version of it Johannes's
work and your outline and fill in the rest later.
--b.
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Daniel Barkalow @ 2007-05-09 17:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Martin Langhoff, git
In-Reply-To: <alpine.LFD.0.98.0705090825090.4062@woody.linux-foundation.org>
On Wed, 9 May 2007, Linus Torvalds wrote:
> Many people seem to enjoy per-hunk commits, but I seldom do that. Maybe
> it's just because I'm *so* comfortable with diffs, that when I clean up an
> ugly sequence of commits, what I do is literally:
>
> - I make sure that my ugly sequence of commits is on some temporary
> branch, but that the _end_result_ is good and clean (ie I will have
> tested the end result fairly well, and made sure that there are no
> debug statements etc crud left).
>
> I would call this branch something like "target", because the end
> result of that branch is what I'm looking for - even if the commits in
> the sequence that gets me there are individually ugly!
>
> - I just switch back to my starting point (and now I'm usually on
> "master"), and do
>
> git diff -R target > diff
>
> to create a diff of my current tree (which is initially the starting
> point) to the good result.
>
> - I actually edit the "diff" file by hand, and edit it down to the part I
> actually want to commit as the first in the series. And then I just do
> a "git-apply diff" to actually apply that part to my working tree.
>
> - I then edit any missing parts in the actual working tree (for example,
> if there were mixed hunks that I want to get to in later commits, and I
> edited out above, or that I need to partially undo), to do any
> finishing touches.
>
> - I now have a tree I can compile and test, and has the "first part" of
> the journey towards the final "target" state. If compiling/testing
> shows that I missed something, I can still fix things, and/or go back
> to doing another "git diff -R target" to see if I missed something).
>
> - I commit that first case, and repeat the sequence from step 2 (and
> at every step, the "diff" file ends up shrinking and shrinking).
>
> The above sounds like it's a complicated sequence, but it really isn't.
> Partly because I just am very comfortable with diffs indeed (probably more
> than most people), but partly because at all times "git diff" works fine
> to see what I've done, and what the diff to "target" is.
It only sounds like a complicated sequence because you didn't write a
script to do it...
$ git checkout -b clean origin
$ git-refine target
(edit the patch in the editor that pops up)
$ git-refine
Test changes and commit
$ make test
...
$ git commit
(write message)
$ git-refine
(edit the patch, etc)
...
$ git commit
$ git-refine
All done.
I actually wrote it years ago, but I couldn't describe my workflow well
enough, so I didn't submit it. If everybody seems to be doing the same
thing, I can submit my script...
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: svn user trying to recover from brain damage
From: J. Bruce Fields @ 2007-05-09 17:43 UTC (permalink / raw)
To: Joshua Ball; +Cc: git
In-Reply-To: <92fdc3450705090830t64c8f5b9r4af277807dfe834d@mail.gmail.com>
On Wed, May 09, 2007 at 10:30:18AM -0500, Joshua Ball wrote:
> 1. Tutorials for people brand new to version control, with just enough
> information for them to "obey the rules", but completely empty of any
> information that could help them exploit the real power of
> decentralized version control.
> 2. Technical documentation which assumes pre-obtained knowledge.
Would you mind also trying
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
It *tries* to fill that gap you're referring to, but you might find it
has some more gaps (which we'd like to hear about).
> What the heck do these terms mean? The glossary on the Git wiki was
> unhelpful (I'll explain later).
Hm. I wonder how that and the glossary included in Documentation/ have
diverged?
--b.
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Linus Torvalds @ 2007-05-09 18:16 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.64.0705091322180.18541@iabervon.org>
On Wed, 9 May 2007, Daniel Barkalow wrote:
>
> It only sounds like a complicated sequence because you didn't write a
> script to do it...
Well, I actually think it sounds like a complicated sequence because I
tried to explain what I do.
The "script" parts don't really end up being any smaller, and not
scripting it actually means that I can (and often do) things outside of a
strict scripting environment.
As mentioned, I not only mix it up with "git cherry-pick", but since I
just use "git diff", I can - and do - things like pick only a certain set
of files to diff and edit the patch on.
So it's an iterative process at several levels (the "outer" level is the
act of actually committing each change, and iterating to the next one,
while the "inner" level is often a sequence of "git diff" exploration),
it's not very fixed.
For example, when I said that I do a
git diff -R target > diff
that's not strictly true. The "git diff -R" is useful for comparing the
current working tree to another commit, but quite often I actually end up
doing it differently, and doing it as
git diff ..target file > diff
.. edit ..
git apply diff
or, if I don't need the edit (ie just the fact that I limit it to a single
file is a sufficient "edit" in itself), I might just do
git checkout target file
instead, which will fetch the whole file from the "target" branch (and
also update it in the index, which may or may not actually be what I want,
but that's a different issue).
So the "process" as far as I'm concerned is actually much more fluid than
necessarily always working with diffs. Git gives you so many ways to do
things like this, and I'm pretty comfortable with lots of them.
Linus
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Robin Rosenberg @ 2007-05-09 18:17 UTC (permalink / raw)
To: Marco Costalba
Cc: Paul Mackerras, Alex Riesen, Linus Torvalds, Karl Hasselstr?m,
Junio C Hamano, Carl Worth, Michael Niedermayer, Git Mailing List
In-Reply-To: <e5bfff550705082338p1a0c003lef230f96a3219ab8@mail.gmail.com>
onsdag 09 maj 2007 skrev Marco Costalba:
> 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.
Yes, there is package called PyQT (GPL) here: http://www.riverbankcomputing.co.uk/pyqt/
There are bindings for most languages, even a Java binding.
-- robin
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Jan Hudec @ 2007-05-09 18:28 UTC (permalink / raw)
To: Marco Costalba
Cc: Paul Mackerras, Alex Riesen, Linus Torvalds, Karl Hasselstr?m,
Junio C Hamano, Carl Worth, Michael Niedermayer, Git Mailing List
In-Reply-To: <e5bfff550705082338p1a0c003lef230f96a3219ab8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
On Wed, May 09, 2007 at 08:38:48 +0200, Marco Costalba wrote:
> 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.
Tried them, beed deeply disapointed. Qt always destroys all child objects
with the parent, which is OK in C++, but does not play well with
garbage-collection. And the python bindings (ruby ones seem to be better)
fail to check reference validity, so you can quite easily segfault the python
interpreter. Gtk plays much better with dynamic languages.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Jan Hudec @ 2007-05-09 18:31 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git, Marco Costalba
In-Reply-To: <46415106.5040401@xs4all.nl>
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
On Wed, May 09, 2007 at 01:41:42 -0300, Han-Wen Nienhuys wrote:
> 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.
Would you care to share the installer scripts? Maybe you can find someone to
help.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Han-Wen Nienhuys @ 2007-05-09 18:40 UTC (permalink / raw)
To: Jan Hudec; +Cc: git, Marco Costalba
In-Reply-To: <20070509183152.GB2982@efreet.light.src>
2007/5/9, Jan Hudec <bulb@ucw.cz>:
> > > 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.
>
> Would you care to share the installer scripts? Maybe you can find someone to
> help.
see
http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=gub
there is a mingit.make which has the targets for the MinGW git
version. Unfortunately, the last successful compile was some months
ago. It's likely to be broken due to the frantic hacking that occurred
in the last months, but it should be
make -f mingit.make bootstrap
make -f mingit.make mingw
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* [PATCH] deprecate the new loose object header format
From: Nicolas Pitre @ 2007-05-09 18:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dana How, Git Mailing List
In-Reply-To: <7vlkfyt13i.fsf@assigned-by-dhcp.cox.net>
Now that we encourage and actively preserve objects in a packed form
more agressively than we did at the time the new loose object format and
core.legacyheaders were introduced, that extra loose object format
doesn't appear to be worth it anymore.
Because the packing of loose objects has to go through the delta match
loop anyway, and since most of them should end up being deltified in
most cases, there is really little advantage to have this parallel loose
object format as the CPU savings it might provide is rather lost in the
noise in the end.
This patch gets rid of core.legacyheaders, preserve the legacy format as
the only writable loose object format and deprecate the other one to
keep things simpler.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Wed, 9 May 2007, Junio C Hamano wrote:
> I agree with your analysis, especially when deeper delta chains
> are allowed, straight copy of loose object becomes less and less
> likely.
So here it is, with a nice code reduction:
Documentation/config.txt | 13 --------
builtin-pack-objects.c | 69 ----------------------------------------------
cache.h | 2 -
config.c | 5 ---
environment.c | 1 -
sha1_file.c | 47 +++++++------------------------
6 files changed, 11 insertions(+), 126 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ea434af..d6d89ba 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -209,19 +209,6 @@ core.compression::
compression, and 1..9 are various speed/size tradeoffs, 9 being
slowest.
-core.legacyheaders::
- A boolean which
- changes the format of loose objects so that they are more
- efficient to pack and to send out of the repository over git
- native protocol, since v1.4.2. However, loose objects
- written in the new format cannot be read by git older than
- that version; people fetching from your repository using
- older versions of git over dumb transports (e.g. http)
- will also be affected.
-+
-To let git use the new loose object format, you have to
-set core.legacyheaders to false.
-
core.packedGitWindowSize::
Number of bytes of a pack file to map into memory in a
single mapping operation. Larger window sizes may allow
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 966f843..c74a361 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -346,56 +346,6 @@ static void copy_pack_data(struct sha1file *f,
}
}
-static int check_loose_inflate(unsigned char *data, unsigned long len, unsigned long expect)
-{
- z_stream stream;
- unsigned char fakebuf[4096];
- int st;
-
- memset(&stream, 0, sizeof(stream));
- stream.next_in = data;
- stream.avail_in = len;
- stream.next_out = fakebuf;
- stream.avail_out = sizeof(fakebuf);
- inflateInit(&stream);
-
- while (1) {
- st = inflate(&stream, Z_FINISH);
- if (st == Z_STREAM_END || st == Z_OK) {
- st = (stream.total_out == expect &&
- stream.total_in == len) ? 0 : -1;
- break;
- }
- if (st != Z_BUF_ERROR) {
- st = -1;
- break;
- }
- stream.next_out = fakebuf;
- stream.avail_out = sizeof(fakebuf);
- }
- inflateEnd(&stream);
- return st;
-}
-
-static int revalidate_loose_object(struct object_entry *entry,
- unsigned char *map,
- unsigned long mapsize)
-{
- /* we already know this is a loose object with new type header. */
- enum object_type type;
- unsigned long size, used;
-
- if (pack_to_stdout)
- return 0;
-
- used = unpack_object_header_gently(map, mapsize, &type, &size);
- if (!used)
- return -1;
- map += used;
- mapsize -= used;
- return check_loose_inflate(map, mapsize, size);
-}
-
static unsigned long write_object(struct sha1file *f,
struct object_entry *entry)
{
@@ -425,25 +375,6 @@ static unsigned long write_object(struct sha1file *f,
* and we do not need to deltify it.
*/
- if (!entry->in_pack && !entry->delta) {
- unsigned char *map;
- unsigned long mapsize;
- map = map_sha1_file(entry->sha1, &mapsize);
- if (map && !legacy_loose_object(map)) {
- /* We can copy straight into the pack file */
- if (revalidate_loose_object(entry, map, mapsize))
- die("corrupt loose object %s",
- sha1_to_hex(entry->sha1));
- sha1write(f, map, mapsize);
- munmap(map, mapsize);
- written++;
- reused++;
- return mapsize;
- }
- if (map)
- munmap(map, mapsize);
- }
-
if (!to_reuse) {
buf = read_sha1_file(entry->sha1, &type, &size);
if (!buf)
diff --git a/cache.h b/cache.h
index 8e76152..5725bce 100644
--- a/cache.h
+++ b/cache.h
@@ -273,7 +273,6 @@ extern void rollback_lock_file(struct lock_file *);
extern int delete_ref(const char *, const unsigned char *sha1);
/* Environment bits from configuration mechanism */
-extern int use_legacy_headers;
extern int trust_executable_bit;
extern int has_symlinks;
extern int assume_unchanged;
@@ -354,7 +353,6 @@ extern int move_temp_to_file(const char *tmpfile, const char *filename);
extern int has_sha1_pack(const unsigned char *sha1, const char **ignore);
extern int has_sha1_file(const unsigned char *sha1);
extern void *map_sha1_file(const unsigned char *sha1, unsigned long *);
-extern int legacy_loose_object(unsigned char *);
extern int has_pack_file(const unsigned char *sha1);
extern int has_pack_index(const unsigned char *sha1);
diff --git a/config.c b/config.c
index 70d1055..298966f 100644
--- a/config.c
+++ b/config.c
@@ -299,11 +299,6 @@ int git_default_config(const char *var, const char *value)
return 0;
}
- if (!strcmp(var, "core.legacyheaders")) {
- use_legacy_headers = git_config_bool(var, value);
- return 0;
- }
-
if (!strcmp(var, "core.compression")) {
int level = git_config_int(var, value);
if (level == -1)
diff --git a/environment.c b/environment.c
index 2231659..54e3aba 100644
--- a/environment.c
+++ b/environment.c
@@ -11,7 +11,6 @@
char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
-int use_legacy_headers = 1;
int trust_executable_bit = 1;
int has_symlinks = 1;
int assume_unchanged;
diff --git a/sha1_file.c b/sha1_file.c
index 32244d7..e715527 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -972,7 +972,7 @@ void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
return map;
}
-int legacy_loose_object(unsigned char *map)
+static int legacy_loose_object(unsigned char *map)
{
unsigned int word;
@@ -1034,6 +1034,14 @@ static int unpack_sha1_header(z_stream *stream, unsigned char *map, unsigned lon
return inflate(stream, 0);
}
+
+ /*
+ * There used to be a second loose object header format which
+ * was meant to mimic the in-pack format, allowing for direct
+ * copy of the object data. This format turned up not to be
+ * really worth it and we don't write it any longer. But we
+ * can still read it.
+ */
used = unpack_object_header_gently(map, mapsize, &type, &size);
if (!used || !valid_loose_object_type[type])
return -1;
@@ -1962,40 +1970,6 @@ static int write_buffer(int fd, const void *buf, size_t len)
return 0;
}
-static int write_binary_header(unsigned char *hdr, enum object_type type, unsigned long len)
-{
- int hdr_len;
- unsigned char c;
-
- c = (type << 4) | (len & 15);
- len >>= 4;
- hdr_len = 1;
- while (len) {
- *hdr++ = c | 0x80;
- hdr_len++;
- c = (len & 0x7f);
- len >>= 7;
- }
- *hdr = c;
- return hdr_len;
-}
-
-static void setup_object_header(z_stream *stream, const char *type, unsigned long len)
-{
- int obj_type, hdrlen;
-
- if (use_legacy_headers) {
- while (deflate(stream, 0) == Z_OK)
- /* nothing */;
- return;
- }
- obj_type = type_from_string(type);
- hdrlen = write_binary_header(stream->next_out, obj_type, len);
- stream->total_out = hdrlen;
- stream->next_out += hdrlen;
- stream->avail_out -= hdrlen;
-}
-
int hash_sha1_file(const void *buf, unsigned long len, const char *type,
unsigned char *sha1)
{
@@ -2062,7 +2036,8 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha
/* First header.. */
stream.next_in = (unsigned char *)hdr;
stream.avail_in = hdrlen;
- setup_object_header(&stream, type, len);
+ while (deflate(&stream, 0) == Z_OK)
+ /* nothing */;
/* Then the data itself.. */
stream.next_in = buf;
^ permalink raw reply related
* Re: [PATCH] checkout: allow full refnames for local branches
From: Shawn O. Pearce @ 2007-05-09 18:54 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <8c5c35580705090207y2979aaa5u7ce9de5fa1dfe658@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> wrote:
> I'm playing around with a gui frontend, and there I use
> git-for-each-ref to obtain possible arguments for git-checkout. That's
> how I discovered the 'problem', and solved it by stripping
> 'refs/heads/' in my frontend. But then I thought it would be nice if
> 'git-checkout' did the stripping on my behalf, since this might bite
> others too :)
If you are building "porcelain" to sit over Git and offer up a pretty
view of things, I would encourage you to avoid the stock porcelain.
Don't use git-checkout, its stock porcelain. Instead go right to
the plumbing. The plumbing doesn't really change behavior as often
(if ever).
You can see in git-checkout.sh what actions you need to perform,
but its really quite simple if there's no file-level merge involved.
Here's the relevent bits from git-gui:
set cmd [list git read-tree]
lappend cmd -m
lappend cmd -u
lappend cmd --exclude-per-directory=.gitignore
lappend cmd $HEAD
lappend cmd $new_branch
set fd_rt [open "| $cmd" r]
fconfigure $fd_rt -blocking 0 -translation binary
fileevent $fd_rt readable \
[list switch_branch_readtree_wait $fd_rt $new_branch]
...
git symbolic-ref HEAD "refs/heads/$new_branch"
Really all I'm doing is building up an argument list for git
read-tree, passing it the commit that is currently in HEAD and the
commit I want to switch to ($new_branch), and then I wait for it
to finish its job. When its done, I run git symbolic-ref to update
the current branch name.
--
Shawn.
^ permalink raw reply
* Re: GIT on Windows
From: Shawn O. Pearce @ 2007-05-09 18:58 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <loom.20070509T142518-558@post.gmane.org>
Panagiotis Issaris <takis.issaris@uhasselt.be> wrote:
> Any clues on the reason for this crash? Is anyone already using GIT on Windows
> on real repositories?
Yes, I'm using Git on Cygwin on real repositories. My largest there
is about 60 MiB, ~70,000 objects, 10,000 files. Myself and about
25 others who are required to use Windows use it every day just fine.
I also use HTTP fetch to download the latest git.git changes so I
can build them locally (I don't use the Cygwin package, I compile it
myself from scratch) but I haven't done a clone over HTTP in ages as
I already have a local git.git clone established in a few locations.
I'd build any new clone from my existing local ones first...
--
Shawn.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox