Jonathan Nieder jrnie...@gmail.com writes:
In other words, why not use something like this?
write_index: optionally allow broken null sha1s
Commit 4337b58 (do not write null sha1s to on-disk index, 2012-07-28)
added a safety check preventing git from writing null sha1s
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
The two possible fixes which I see are:
1) Replace back if (alternate_shallow_file) condition in fetch pack with
if (args-depth 0)
2) alternate_shallow_file should be copy of shallow_lock.filename not a
reference to it
Command git branch -vv will report tracking branches, but invalid
tracking branches are also reported. This is because the function
stat_tracking_info() can not distinguish invalid tracking branch
from other cases which it would not like to report, such as
there is no upstream settings at all, or
Changes since v7:
* Squashed patch 1/3 and patch 2/3 into one big patch.
But not s/gone/absent/ as Matthieu suggested.
Jiang Xin (2):
branch: report invalid tracking branch as gone
status: always show tracking branch even no change
builtin/branch.c | 36
In order to see what the current branch is tracking, one way is using
git branch -v -v, but branches other than the current are also
reported. Another way is using git status, such as:
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
...
But
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com writes:
I think Phil meant that when git grep is asked to search within
HEAD:some/path, filenames tacked on at the end should be appended
with a '/' separator instead of the usual ':' (e.g.,
Eric Sunshine sunsh...@sunshineco.com writes:
... when 'next' is ready to be rewound after 1.8.4
is released, a replacement to the original series should be sent with
all the incremental patches squashed in.
It was more like could, if you want to help us keep clean history
going forward,
From: Johannes Sixt j...@kdbg.org
Am 25.08.2013 21:44, schrieb Christian Couder:
What about:
die(Objects must be of the same type.\n
'%s' points to a replaced object of type '%s'\n
while '%s' points to a replacement object of type
Jiang Xin worldhello@gmail.com writes:
Changes since v7:
* Squashed patch 1/3 and patch 2/3 into one big patch.
But not s/gone/absent/ as Matthieu suggested.
Thanks. Will requeue.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
But this will not work if there is no change between the current
branch and its upstream. Always report upstream tracking info
even if there is no difference, so that git status is consistent
for checking tracking info for current branch. E.g.
$ git status
# On branch feature1
2013/8/26 Jeremy Rosen jeremy.ro...@openwide.fr:
nitpicking, but shouldn't this be worded as up to date rather than
identical ?
The reason is that identical gives the idea that the two branch happen to be
on the same
commit wheras up to date gives the idea that there is a special
Hi Brian,
Sorry for the delay.
On 20/08/13 12:26, brian m. carlson wrote:
When git submodule summary is run and there is a deleted submodule, there is
an
warning from git rev-parse:
fatal: Not a git repository: '.vim/pathogen/.git'
Silence this warning, since it is fully expected
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
How would I do that? The update to the remote namespace is done by Git,
not by the remote-helper.
OK, I'm now convinced that my solution is the right one. The
alternatives are far more complex and I
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
How would I do that? The update to the remote namespace is done by Git,
not by the remote-helper.
OK, I'm now convinced that my solution is the
The current documentation mentions the private ref namespace, but does
not really explain why it can be useful.
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
This small patch was sent inline during a previous conversation, but
did not really catch attention ;-).
Resending as a proper
On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com writes:
I think Phil meant that when git grep is asked to search within
HEAD:some/path, filenames tacked on at the end should be appended
with
Hi,
I am still working on implementing git in Python for self education
purposes. Implementing the Index in memory was no problem after I
understood how its done with help of Andreas Ericsson and Junio C
Hamano.
Now I want to store an Index state to the filesystem in a
git-compatible file
Thomas Ackermann th.ac...@arcor.de writes:
Sorry Jon, but this might not be of any help to new Git users ;)
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
Yeah, I think this is long overdue. The drawing was taken from an
e-mail posted in a discussion, and the credit should have
On Sun, Aug 25, 2013 at 11:50:01AM -0400, Pete Wyckoff wrote:
Modern git, including your version, do streaming reads from p4,
so the git-p4 python process never even holds a whole file's
worth of data. You're seeing git-fast-import die, it seems. It
will hold onto the entire file contents.
On Sun, Aug 25, 2013 at 12:54:12PM -0700, Jonathan Nieder wrote:
[setup split across three tests]
This is kind of an old-fashioned test, since each step of the setup is
treated as a separate test assertion. I don't really mind until we
get better automation to make it easy to skip or
On Sun, Aug 25, 2013 at 11:03:54PM -0700, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
In other words, why not use something like this?
write_index: optionally allow broken null sha1s
Commit 4337b58 (do not write null sha1s to on-disk index, 2012-07-28)
When a commit is grepped and matching filenames are printed, grep-objects
creates the filename by prefixing the original cmdline argument to the
matched path separated by a colon. Normally this forms a valid blob
reference to the filename, like this:
git grep -l foo HEAD
Jeff King p...@peff.net writes:
I found this version more readable than Peff's (albeit slightly).
OK. Do you want to apply with Jonathan's wording, then?
I can do that, as it seems all of us are in agreement.
There's one subtle thing I didn't mention in the it is already on stack
overflow.
Jiang Xin worldhello@gmail.com writes:
2013/8/26 Jeremy Rosen jeremy.ro...@openwide.fr:
nitpicking, but shouldn't this be worded as up to date rather than
identical ?
The reason is that identical gives the idea that the two branch happen to be
on the same
commit wheras up to date
Phil Hord phil.h...@gmail.com writes:
On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com writes:
I think Phil meant that when git grep is asked to search within
HEAD:some/path, filenames
Matthieu Moy matthieu@grenoble-inp.fr writes:
Not updating was the default until 664059fb62 (i.e. until 1.8.4), so the
default already changed once. I tend to agree with Felipe that doing the
update by default makes sense.
OK. Thanks.
git-remote-mediawiki is kind of a special case, as
On Mon, Aug 26, 2013 at 4:16 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
How would I do that? The update to the remote namespace is done by
On Mon, Aug 26, 2013 at 12:23 PM, Junio C Hamano gits...@pobox.com wrote:
Phil Hord phil.h...@gmail.com writes:
On Mon, Aug 26, 2013 at 3:14 AM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com writes:
I think Phil meant
Consider [anything]-by: a valid signature.
This includes Tested-by: Acked-by: Reviewed-by: etc.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
git-send-email.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index
Junio C Hamano gits...@pobox.com writes:
If your justification were above says 'there may be a readon why
the user wanted to ask it in that way', i.e. 'find in this tree
object HEAD:some/path and report where hits appear', but the reason
can only be from laziness and/or broken script and the
On Mon, Aug 26, 2013 at 12:49 PM, Phil Hord phil.h...@gmail.com wrote:
If so, then I would like to point out to you the convenience I
accidentally encountered using this tool. Perhaps you didn't realize
how helpful it was when you chose to use a colon there.
My itch comes from a case where I
I was trying to clone a SVN repo, but not having luck:
$ git svn clone $PWD/private-lustre-svn $PWD/private-lustre-git
perl: subversion/libsvn_subr/dirent_uri.c:321: canonicalize: Assertion `*src
!= '/'' failed.
error: git-svn died of signal 6
What is Perl or Subversion or GIT trying to
On Mon, Aug 26, 2013 at 1:03 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
If your justification were above says 'there may be a readon why
the user wanted to ask it in that way', i.e. 'find in this tree
object HEAD:some/path and report where hits
Phil Hord phil.h...@gmail.com writes:
If your justification were above says 'there may be a readon why
the user wanted to ask it in that way', i.e. 'find in this tree
object HEAD:some/path and report where hits appear', but the reason
can only be from laziness and/or broken script and the
Hi,
Bruce Korb wrote:
I was trying to clone a SVN repo, but not having luck:
$ git svn clone $PWD/private-lustre-svn $PWD/private-lustre-git
perl: subversion/libsvn_subr/dirent_uri.c:321: canonicalize: Assertion `*src
!= '/'' failed.
error: git-svn died of signal 6
What is Perl or
Hi,
On Mon, Aug 26, 2013 at 10:28 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Bruce Korb wrote:
I was trying to clone a SVN repo, but not having luck:
$ git svn clone $PWD/private-lustre-svn $PWD/private-lustre-git
perl: subversion/libsvn_subr/dirent_uri.c:321: canonicalize: Assertion
Jeff King wrote:
On Sun, Aug 25, 2013 at 12:54:12PM -0700, Jonathan Nieder wrote:
[setup split across three tests]
This is kind of an old-fashioned test, since each step of the setup is
treated as a separate test assertion. I don't really mind until we
get better automation to make it easy
Bruce Korb wrote:
$ git svn --version
git-svn version 1.8.1.4 (svn 1.7.11)
Hm. Two ideas:
* Does 1.8.2 or newer work better? (It contains v1.8.2-rc0~110^2,
git-svn: do not escape certain characters in paths, 2013-01-17,
which at first glance looks unlikely to help but might be worth
On Mon, Aug 26, 2013 at 1:26 PM, Junio C Hamano gits...@pobox.com wrote:
Phil Hord phil.h...@gmail.com writes:
If your justification were above says 'there may be a readon why
the user wanted to ask it in that way', i.e. 'find in this tree
object HEAD:some/path and report where hits appear',
On Mon, Aug 26, 2013 at 10:42 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Bruce Korb wrote:
$ git svn --version
git-svn version 1.8.1.4 (svn 1.7.11)
Hm. Two ideas:
* Does 1.8.2 or newer work better? (It contains v1.8.2-rc0~110^2,
git-svn: do not escape certain characters in paths,
On Mon, Aug 26, 2013 at 10:46:12AM -0400, Phil Hord wrote:
This version is a bit more deterministic and also adds a test.
It accepts the expense of examining the path argument again to
determine if it is a tree-ish + path rather than just a tree (commit).
The get_sha1 call occurs one extra
We use an object_array to store the set of objects to grep
that we received on the command-line. There is no particular
reason to use object_array here except that its code was
already written, and it contained the elements we needed
(though we did not care about mode at all).
However, future
From: Phil Hord ho...@cisco.com
When a commit is grepped and matching filenames are printed, grep-objects
creates the filename by prefixing the original cmdline argument to the
matched path separated by a colon. Normally this forms a valid blob
reference to the filename, like this:
git grep
I've noticed that Git by default puts long output through less as a
pager. I don't like that, but this is not the time to change
established behavior. But while tracking that down, I noticed that
the paging behavior is controlled by at least 5 things:
the -p/--paginate/--no-pager options
the
Am 26.08.2013 10:26, schrieb Chris Packham:
Hi Brian,
Sorry for the delay.
Same here.
On 20/08/13 12:26, brian m. carlson wrote:
When git submodule summary is run and there is a deleted submodule, there is
an
warning from git rev-parse:
fatal: Not a git repository:
Up until the latest release, I've been able to compile git for a uclibc
based embedded linux. The toolchain I use is from entware, which is
based off of the openwrt toolchain.
https://code.google.com/p/wl500g-repo/
Somewhere between git 1.8.3.4 1.8.4 there seems to be some changes
that
Am 26.08.2013 21:56, schrieb Jeff King:
Also, prevent the delimiter being added twice, as happens now in these
examples:
git grep -l foo HEAD:
HEAD::some/path/to/foo.txt
^
Which one of these two does it print then?
HEAD:/some/path/to/foo.txt
HEAD:some/path/to/foo.txt
On Mon, Aug 26, 2013 at 02:10:43PM -0600, Lance wrote:
Up until the latest release, I've been able to compile git for a
uclibc based embedded linux. The toolchain I use is from entware,
which is based off of the openwrt toolchain.
https://code.google.com/p/wl500g-repo/
Somewhere between git
On 8/26/2013 2:18 PM, Lukas Fleischer wrote:
On Mon, Aug 26, 2013 at 02:10:43PM -0600, Lance wrote:
Up until the latest release, I've been able to compile git for a
uclibc based embedded linux. The toolchain I use is from entware,
which is based off of the openwrt toolchain.
On Mon, Aug 26, 2013 at 02:29:12PM -0600, Lance wrote:
[...]
CC config.o
config.c: In function 'get_next_char':
config.c:220:14: error: expected identifier before '(' token
config.c:220:14: error: expected statement before ')' token
config.c:220:14: error: expected statement before ')'
On Mon, Aug 26, 2013 at 4:13 PM, Johannes Sixt j...@kdbg.org wrote:
Am 26.08.2013 21:56, schrieb Jeff King:
Also, prevent the delimiter being added twice, as happens now in these
examples:
git grep -l foo HEAD:
HEAD::some/path/to/foo.txt
^
Which one of these two does it print
On Mon, Aug 26, 2013 at 10:13:14PM +0200, Johannes Sixt wrote:
Am 26.08.2013 21:56, schrieb Jeff King:
Also, prevent the delimiter being added twice, as happens now in these
examples:
git grep -l foo HEAD:
HEAD::some/path/to/foo.txt
^
Which one of these two does it
On Mon, Aug 26, 2013 at 10:31:54PM +0200, Lukas Fleischer wrote:
I also had to change line 224 to the following
c = (cf-fgetc)(cf);
Once both places were changes, it compiled successfully.
Sounds like a parser bug to me. Should we patch this in Git in order to
make
On Mon, Aug 26, 2013 at 4:52 PM, Jeff King p...@peff.net wrote:
On Mon, Aug 26, 2013 at 10:13:14PM +0200, Johannes Sixt wrote:
Am 26.08.2013 21:56, schrieb Jeff King:
Also, prevent the delimiter being added twice, as happens now in these
examples:
git grep -l foo HEAD:
Lukas Fleischer g...@cryptocrack.de writes:
On Mon, Aug 26, 2013 at 02:29:12PM -0600, Lance wrote:
[...]
CC config.o
config.c: In function 'get_next_char':
config.c:220:14: error: expected identifier before '(' token
config.c:220:14: error: expected statement before ')' token
On Mon, Aug 26, 2013 at 05:03:04PM -0400, Phil Hord wrote:
$ git grep -l foo HEAD | head -1
HEAD:RelNotes/1.5.1.5.txt
we still limit to the current directory, but the output does not note
this (it should be HEAD:./RelNotes/1.5.1.5.txt). I think this bug is
orthogonal to Phil's
Hello all,
As of 1.8.0, the compdefs I set up for my shell aliases (in zsh 5.0)
worked. They can be found here:
https://github.com/gfontenot/dotfiles/blob/master/git/completion.zsh
However, once updating to 1.8.3, they broke, complaining that zsh
couldn't find the command __git-checkout_main
On Mon, Aug 26, 2013 at 10:35:01AM -0700, Jonathan Nieder wrote:
I don't see that splitting it up more hurts this. If we wanted more
automatic rearranging or skipping of tests, we would need tests to
declare dependencies on their setup. And we would need to be able to
declare dependencies
On Mon, Aug 26, 2013 at 09:02:46AM -0700, Junio C Hamano wrote:
There's one subtle thing I didn't mention in the it is already on stack
overflow. If you have a version of git which complains about the null
sha1, then the SO advice is already broken. But if the SO works, then
you do not
On Sun, Aug 25, 2013 at 10:27:52PM -0700, Junio C Hamano wrote:
I'm on the fence. It doesn't actually save that many lines of code, and
I guess it's possible that somebody would want a custom mailmap in the
future. Even though you can't do it right now, all it would take is
exposing
On Mon, Aug 26, 2013 at 04:59:01PM -0400, Jeff King wrote:
Hmm. I wonder if fgetc is a macro in uclibc? Just grepping their
stdio.h, it looks like that is a possibility.
I think they are probably wrong to do so (but I'd have to check the
standard). However, the cleaner workaround would
On Mon, Aug 26, 2013 at 02:34:18PM +0200, Erik Bernoth wrote:
Now there's a lot of information (all the stat(2) stuff) that gets
stored about the staged files, which I never needed for file-IO in
Python or Java. In my eyes if a person would be cloning my git
repository he wouldn't need it as
On Fri, 23 Aug 2013, Junio C Hamano wrote:
The latest feature release Git v1.8.4 is now available at the usual
places. It contains 870+ changes from ~100 contributors (among
which 33 people are new) since v1.8.3.
We will have two more releases til the end of this year; the release
after
On Tue, Aug 27, 2013 at 7:06 AM, Nicolas Pitre n...@fluxnic.net wrote:
Yes, after being vaporware for many many years (I don't even remember
when I started making references to a possible pack format version 4 --
certainly more than 6 years ago) I finally completed the code to produce
a new
On Mon, Aug 26, 2013 at 05:57:18PM -0400, Jeff King wrote:
On Mon, Aug 26, 2013 at 04:59:01PM -0400, Jeff King wrote:
Hmm. I wonder if fgetc is a macro in uclibc? Just grepping their
stdio.h, it looks like that is a possibility.
I think they are probably wrong to do so (but I'd have to
Do you have an updated patch? Want to take some time to clean up and
resubmit the entire series? The batching should be incorporated with
the last 2/2 that I sent out.
I don't have other update.
I'm satisfied because able to want to do and it became better than my
original modification
Jeff King p...@peff.net writes:
On Mon, Aug 26, 2013 at 03:28:26PM -0400, Jeff King wrote:
Changing the object_array API would be hard, but I don't think we need
to do it here. Can we simply stop using object_array to pass the list,
and instead just have a custom list?
I'll see how
Nicolas Pitre n...@fluxnic.net writes:
On Fri, 23 Aug 2013, Junio C Hamano wrote:
The latest feature release Git v1.8.4 is now available at the usual
places. It contains 870+ changes from ~100 contributors (among
which 33 people are new) since v1.8.3.
We will have two more releases til
Jeff King p...@peff.net writes:
I'd be very surprised if this works in practice on most of our current
test scripts. There are often subtle dependencies on the state left over
from previous tests. Running the script below up through t3800 (at which
point I lost patience) reveals 37 test
Antoine Pelisse apeli...@gmail.com writes:
I've tried to use the netrc credential with git-send-email
(v1.8.4-rc2), and I've had the following log (running with -d -v):
Peff what do you think? From credential layer's point of view, I
think we make it totally up to the helper to decide if a
On Tue, 27 Aug 2013, Duy Nguyen wrote:
On Tue, Aug 27, 2013 at 7:06 AM, Nicolas Pitre n...@fluxnic.net wrote:
Yes, after being vaporware for many many years (I don't even remember
when I started making references to a possible pack format version 4 --
certainly more than 6 years ago) I
Junio C Hamano gits...@pobox.com writes:
Not necessarily. If the user is asking the question in a more
natural way (I want to see where in 'next' branch's tip commit hits
appear, by the way, I know I am only interested in builtin/ so I'd
give pathspec as well when I am asking this question),
Subject says it all... at last !
This can also be fetched here:
git://git.linaro.org/people/nico/git
Demonstration of what it does at the moment:
http://article.gmane.org/gmane.comp.version-control.git/233038
I'd like to preserve the author time stamps as they relate to where
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 58 +++--
1 file changed, 44 insertions(+), 14 deletions(-)
diff --git a/packv4-create.c b/packv4-create.c
index 5c08871..20d97a4 100644
--- a/packv4-create.c
+++
From: Nicolas Pitre nico@lenovo.(none)
Let's read a pack to feed our dictionary with all the path strings
contained in all the tree objects.
Dump the resulting dictionary sorted by frequency to stdout.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
Makefile| 1 +
packv4-create.c |
Let's create a struct pack_idx_entry list with sorted sha1 which will
be useful later. The offset sorted list is now a separate indirect
list.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 72 +
1 file changed, 42
In order to be able to quickly walk tree objects, let's encode their
delta as a range of entries into another tree object.
The encoding allows for the base object to change so multiple base
objects can be borrowed from. The code doesn't try to exploit this
possibility at the moment though.
The
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
cache.h | 1 +
sha1_file.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 85b544f..b6634c4 100644
--- a/cache.h
+++ b/cache.h
@@ -1160,6 +1160,7 @@ struct object_info {
} u;
};
extern
This goes as follows:
- Number of tree entries: variable length encoded.
Then for each tree entry:
- Path component reference: variable length encoded index into the path
string dictionary table which also covers the entry mode. To make the
overall encoding efficient, the author table is
A bit crud but good enough for now.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
cache.h | 1 +
sha1_file.c | 58 +++---
2 files changed, 52 insertions(+), 7 deletions(-)
diff --git a/cache.h b/cache.h
index b6634c4..63066a1 100644
Let's create another dictionary table to hold the author and committer
entries. We use the same table format used for tree entries where the
16 bit data prefix is conveniently used to store the timezone value.
In order to copy straight from a commit object buffer, dict_add_entry()
is modified to
Add variable length number encoding. Let's apply the same encoding
currently used for the offset to base of OBJ_OFS_DELTA objects which
is the most efficient way to do this, and apply it to everything with
pack version 4.
Also add SHA1 reference encoding. This one is either an index into a
SHA1
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index 6801e21..22e14da 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -13,6 +13,7 @@
#include tree-walk.h
#include pack.h
This is a minor change over pack index v2. Since pack v4 already contains
the sorted SHA1 table, it is therefore ommitted from the index file.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
pack-write.c| 6 +-
packv4-create.c | 10 +-
2 files changed, 14 insertions(+), 2
This goes as follows:
- Tree reference: either variable length encoding of the index
into the SHA1 table or the literal SHA1 prefixed by 0 (see
add_sha1_ref()).
- Parent count: variable length encoding of the number of parents.
This is normally going to occupy a single byte but doesn't
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 73 +++--
1 file changed, 34 insertions(+), 39 deletions(-)
diff --git a/packv4-create.c b/packv4-create.c
index bb171c5..6801e21 100644
--- a/packv4-create.c
+++
At least commit af25e94d4dcfb9608846242fabdd4e6014e5c9f0 in the Linux
kernel repository has author 1120285620 -0700
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/packv4-create.c b/packv4-create.c
In pack v4 the object size and type is encoded differently from pack v3.
The object size uses the same efficient variable length number encoding
already used elsewhere.
The object type has 4 bits allocated to it compared to 3 bits in pack v3.
This should be quite sufficient for the foreseeable
This adds the missing code to finally be able to produce a complete
pack file version 4. We trap commit and tree objects as those have
a completely new encoding. Other object types are copied almost
unchanged.
As we go the pack index entries are updated in place to store the new
object offsets
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index ed67eb6..2d46d11 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -15,6 +15,7 @@
#include pack-revindex.h
Here's the code to dump a table into a pack. Table entries are written
according to the current sort order. This is important as objects use
this order to index into the table.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 49
Blob and tag objects have no particular changes except for their object
header.
Delta objects are also copied as is, except for their delta base reference
which is converted to the new way as used elsewhere in pack v4 encoding
i.e. an index into the SHA1 table or a literal SHA1 prefixed by 0 if
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 137
1 file changed, 137 insertions(+)
create mode 100644 packv4-create.c
diff --git a/packv4-create.c b/packv4-create.c
new file mode 100644
index 000..2de6d41
---
The SHA1 of the base object is retrieved and the corresponding object
is loaded in memory for conv_to_dict_tree() to look at. Simple but
effective. Obviously this relies on the delta matching already performed
during the pack v3 delta search. Some native delta search for pack v4
could be
Augment dict entries with a 16-bit prefix in order to store the file
mode value of tree entries.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 56
1 file changed, 36 insertions(+), 20 deletions(-)
diff --git
Let's actually open the destination pack file and write the header and
the tables.
The header isn't much different from pack v3, except for the pack version
number of course.
The first table is the sorted SHA1 table normally found in the pack index
file. With pack v4 we write this table in the
wor...@alum.mit.edu (Dale R. Worley) writes:
I've noticed that Git by default puts long output through less as a
pager. I don't like that, but this is not the time to change
established behavior. But while tracking that down, I noticed that
the paging behavior is controlled by at least 5
Jeff King p...@peff.net writes:
On Mon, Aug 26, 2013 at 04:59:01PM -0400, Jeff King wrote:
Hmm. I wonder if fgetc is a macro in uclibc? Just grepping their
stdio.h, it looks like that is a possibility.
I think they are probably wrong to do so (but I'd have to check the
standard). However,
Linus Torvalds torva...@linux-foundation.org writes:
So it would probably be a great idea to make the filtering code able
to do things in smaller chunks, but I suspect that the patch to chunk
up xread/xwrite is the right thing to do anyway.
Yes and yes, but the first yes is a bit tricky for
99 matches
Mail list logo
