On Tue, Sep 10, 2013 at 01:46:27AM -0500, Felipe Contreras wrote:
> On Mon, Sep 9, 2013 at 9:21 PM, Jeff King wrote:
> > On Mon, Sep 09, 2013 at 05:49:36PM -0500, Felipe Contreras wrote:
> >
> >> > These deprecation warning messages should be written to stderr, and
> >> > should probably be prefi
On Mon, Sep 9, 2013 at 9:21 PM, Jeff King wrote:
> On Mon, Sep 09, 2013 at 05:49:36PM -0500, Felipe Contreras wrote:
>
>> > These deprecation warning messages should be written to stderr, and
>> > should probably be prefixed with "WARNING: ".
>>
>> Is there any deprecation warning that works this
On Sun, Sep 08, 2013 at 06:15:06PM +, brian m. carlson wrote:
> The HTTP 1.1 standard requires an Allow header for 405 Method Not Allowed:
>
> The response MUST include an Allow header containing a list of valid methods
> for the requested resource.
>
> So provide such a header when we r
Brad King wrote:
> The function resets refs rather than doing arbitrary updates.
> Rename it to allow a future general-purpose update_refs function
> to be added.
Makes sense; thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kerne
On Mon, Sep 09, 2013 at 05:49:36PM -0500, Felipe Contreras wrote:
> > These deprecation warning messages should be written to stderr, and
> > should probably be prefixed with "WARNING: ".
>
> Is there any deprecation warning that works this way?
The ones in C code typically use warning(), which
On Mon, Sep 9, 2013 at 6:30 PM, brian m. carlson
wrote:
> On Mon, Sep 09, 2013 at 02:00:55AM -0500, Felipe Contreras wrote:
>> Of course not. First of all, who exactly is packaging release
>> candidates nowadays? And second, why they can't they use the existing
>> tools, like the 'version' file?
>
The function resets refs rather than doing arbitrary updates.
Rename it to allow a future general-purpose update_refs function
to be added.
Signed-off-by: Brad King
---
builtin/reset.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index
Extend t/t1400-update-ref.sh to cover cases using the --stdin option.
Signed-off-by: Brad King
---
t/t1400-update-ref.sh | 639 ++
1 file changed, 639 insertions(+)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index e415ee0..a510500
Expose lock_ref_sha1_basic's type_p argument to callers of
lock_any_ref_for_update. Update all call sites to ignore it by passing
NULL for now.
Signed-off-by: Brad King
---
branch.c | 2 +-
builtin/commit.c | 2 +-
builtin/fetch.c| 3 ++-
builtin/receive-pack.c | 3 +
Generalize repack_without_ref as repack_without_refs to support a list
of refs and implement the former in terms of the latter.
Signed-off-by: Brad King
---
refs.c | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/refs.c b/refs.c
index b14f59b
Factor loose ref deletion into helper function delete_ref_loose to allow
later use elsewhere.
Signed-off-by: Brad King
---
refs.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/refs.c b/refs.c
index f7d3c09..b14f59b 100644
--- a/refs.c
+++ b/ref
Factor the lock and write steps and error handling into helper functions
update_ref_lock and update_ref_write to allow later use elsewhere.
Expose lock_any_ref_for_update's type_p to update_ref_lock callers.
While at it, drop "static" from the local "lock" variable as it is not
necessary to keep a
Add 'struct ref_update' to encode the information needed to update or
delete a ref (name, new sha1, optional old sha1, no-deref flag). Add
function 'update_refs' accepting an array of updates to perform. First
sort the input array to order locks consistently everywhere and reject
multiple updates
Add a --stdin signature to read update instructions from standard input
and apply multiple ref updates together. Use an input format that
supports any update that could be specified via the command-line,
including object names like "branch:path with space".
Signed-off-by: Brad King
---
Document
Hi Folks,
Here is the sixth revision of a series to support locking multiple
refs at the same time to update all of them consistently. The
previous revisions of the series can be found at $gmane/233260,
$gmane/233458, $gmane/233647, $gmane/233840, and $gmane/234324.
Updates since the previous re
On Tue, Sep 10, 2013 at 2:25 AM, Nicolas Pitre wrote:
> An eventual optimization to index-pack when completing a pack would be
> to attempt the encoding of appended tree objects into the packv4 format
> using the existing dictionary table in the pack, and fall back to the
> canonical format if tha
On Mon, Sep 9, 2013 at 10:01 PM, Nicolas Pitre wrote:
> However this means that the progress meter will now be wrong and that's
> terrible ! Users *will* complain that the meter doesn't reach 100% and
> they'll protest for being denied the remaining objects during the
> transfer !
>
> Joking asid
Le 09/10/13 01:06, Andreas Schwab a écrit :
> THILLOSEN Andreas writes:
>
>> It implies "interweaving" their histories, so that I can get a "state"
>> of both RepA and RepB around a same time period of time.
>
> This is only possible by rewriting every commit to point to a new tree
> containing
On Mon, Sep 09, 2013 at 02:00:55AM -0500, Felipe Contreras wrote:
> Of course not. First of all, who exactly is packaging release
> candidates nowadays? And second, why they can't they use the existing
> tools, like the 'version' file?
Debian unstable, for one. However, they don't use RPMs and th
On Sun, Sep 8, 2013 at 12:41 PM, Junio C Hamano wrote:
> Sebastian Schuberth writes:
>
>> Which raises another question on my side: Isn't it tedious for you to
>> both update DEF_VER *and* tag a version? Wouldn't it probably be less
>> error prove (in the sense of keeping DEF_VER and tagged versi
On Mon, Sep 9, 2013 at 2:18 AM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson
>> wrote:
>>
>>> Yes, that would be me. My hesitance here is that as the one usually
>>> driving git updates (which so far have happened once a year), I will end
THILLOSEN Andreas writes:
> It implies "interweaving" their histories, so that I can get a "state"
> of both RepA and RepB around a same time period of time.
This is only possible by rewriting every commit to point to a new tree
containing the combined trees of the two repositories. To get a
me
Jeff King writes:
> It somehow feels a little weird to me that we would output the
> information about refs/foo on the HEAD line.
I see that you realized why the above is not the case in the
downthread; the capability list is not about describing HEAD. The
list happens to be on the line for HEAD
Sebastian Schuberth writes:
> Which raises another question on my side: Isn't it tedious for you to
> both update DEF_VER *and* tag a version? Wouldn't it probably be less
> error prove (in the sense of keeping DEF_VER and tagged version in
> sync) to remove DEF_VER completely and just die if all
Richard Hansen writes:
> def do_export(parser):
> -global parsed_refs, dirname
> +global parsed_refs, dirname, transports
As this has been acked by Felipe who knows the script the best, I'll
apply this directly to 'master'.
These additions of "global transports" however have trivial
in
On Mon, Sep 9, 2013 at 3:17 PM, Jeff King wrote:
> On Sun, Sep 08, 2013 at 03:50:46AM -0400, Jeff King wrote:
>
>> > > If you are interested, I can ask the opinion of some of the GitHub
>> > > trainers. They see a lot of new users and have a sense of what kinds of
>> > > confusion come up most fre
Uli Heller writes:
> From a763550fc59b756580f9b162839d2737c27f2fe3 Mon Sep 17 00:00:00 2001
> From: Uli Heller
> Date: Tue, 3 Sep 2013 09:14:03 +0200
> Subject: [PATCH] git-svn: Fix termination issues for remote svn connections
None of the above need to be in the e-mail body (the first one must
Philip Oakley writes:
> Merges are often treated as special case objects so tell users that
> they are not special here.
>
> Signed-off-by: Philip Oakley
> ---
>
> This updates my in-line patch given in [PATCH v3 07/11]
> Documentation/replace: tell that -f option bypasses the type check
> ($gma
On Mon, Sep 9, 2013 at 3:24 PM, John Keeping wrote:
> On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote:
>> On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:
>>
>> > You are in favor of an _option_ to allow people to forbid a pull in
>> > a non-ff situation, and I think other
Felipe Contreras writes:
>> Hmph, is the above sufficient? I added a case that mimics Stefano's
>> original regression report (which is handled) and another that uses
>> doubled "@" for the same purpose of introducing a "funny" hierarchy,
>> and it appears that "checkout -b" chokes on it.
>
> Th
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The second batch of topics are now in 'master'.
You can find the changes described here in the integration branches
of the repositories listed
On Mon, Sep 9, 2013 at 4:23 PM, Richard Hansen wrote:
> On 2013-09-08 21:23, Felipe Contreras wrote:
>> The old configurations still work, but get deprecated.
>
> Should some tests for the deprecated configs be added? We wouldn't want
> to accidentally break those.
Probably, but Junio is not pic
On Mon, Sep 09, 2013 at 09:45:10AM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -1234,7 +1234,7 @@ X-Mailer: git-send-email $gitversion
> > if ($smtp->code == 220) {
> >
I am very excited, but I already am deep into today's integration
cycle, so I'd have to do this either tonight or early tomorrow.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kern
"Philip Oakley" writes:
> These look to work OK. Not sure If I've properly covered all the
> options.
>
> A nice feature is that ls-remote will find the fake ref !
>
> $ git ls-remote /c/gitBundleTest1/RepoHEADnomaster.bundle Test:HEAD
> 41ccb18028d1cb6516251e94cef1cd5cb3f0bcb5refs/heads/
Dear User
Your e-mail size exceeds 2 GB, which is created by our
Webmaster, is currently working on the 2.30GB, you can not
send or receive new messages until you check your account.
Fill out the form to verify your account.
Please complete the information below to update your account
(1) E-mail
From: "Junio C Hamano"
Sent: Monday, September 09, 2013 3:44 PM
"Philip Oakley" writes:
One is to extend the ref format such that
refs/heads/Test:HEAD
would be considered a valid indicator of a symref relationship
(i.e. using the typical 'colon' style). It would be appended after
the
regu
Niels Basjes wrote:
> As we all know the hooks ( in .git/hooks ) are not cloned along with
> the code of a project.
> Now this is a correct approach for the scripts that do stuff like
> emailing the people responsible for releases or submitting the commit
> to a CI system.
More often than not, mai
On 2013-09-09 16:44, Jeff King wrote:
> On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:
>> I think we need to make sure that we give instructions for how to go
>> back if the default hasn't done what you wanted. Something like this:
>>
>> Your pull did not fast-forward, so Git ha
From: "Jeff King"
Sent: Monday, September 09, 2013 9:53 PM
On Mon, Sep 09, 2013 at 10:50:31PM +0200, Matthieu Moy wrote:
John Keeping writes:
> I think we need to make sure that we give instructions for how to
> go
> back if the default hasn't done what you wanted. Something like
> this:
Hi,
I recently stumbled over problems, while trying to merge two
repositories (RepA and RepB) into a single one (RepM).
I must mention that indexed files in RepA are totally distinct from
indexed files in RepB, thus no conflict shall appear.
The problem is that I never manage to get the exact resu
On 2013-09-08 21:23, Felipe Contreras wrote:
> The old configurations still work, but get deprecated.
Should some tests for the deprecated configs be added? We wouldn't want
to accidentally break those.
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index ec57a15..9489a59 1
On Mon, Sep 09, 2013 at 10:50:31PM +0200, Matthieu Moy wrote:
> John Keeping writes:
>
> > I think we need to make sure that we give instructions for how to go
> > back if the default hasn't done what you wanted. Something like this:
> >
> > Your pull did not fast-forward, so Git has merged
On Mon, Sep 9, 2013 at 11:13 PM, Hilco Wijbenga
wrote:
> On 9 September 2013 13:48, Niels Basjes wrote:
>> So I propose the following new feature:
>>
>> 1) A scripting language is put inside git. Perhaps a version of python
>> or ruby or go or ... (no need for a 'new' language)
>
> That sounds ni
On 9 September 2013 13:48, Niels Basjes wrote:
> If those scripts were how ever written in a language that is build
> into the git program and the script are run in such a way that they
> can only interact with the files in the local git (and _nothing_
> outside of that) this would be solved.
Tha
On Mon, Sep 09, 2013 at 04:44:16PM -0400, Jeff King wrote:
> On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:
>
> > > I think that would address the concern I raised, because it does not
> > > create a roadblock to new users accomplishing their task. They can
> > > ignore the warning,
Junio C Hamano writes:
> You are in favor of an _option_ to allow people to forbid a pull in
> a non-ff situation, and I think other people are also in
> agreement.
Yes. Having an option can't harm anybody, and there's a clear demand for
that.
> So perhaps:
>
> - drop jc/pull-training-wheel an
John Keeping writes:
> I think we need to make sure that we give instructions for how to go
> back if the default hasn't done what you wanted. Something like this:
>
> Your pull did not fast-forward, so Git has merged '$upstream' into
> your branch, which may not be correct for your proj
Hi,
As we all know the hooks ( in .git/hooks ) are not cloned along with
the code of a project.
Now this is a correct approach for the scripts that do stuff like
emailing the people responsible for releases or submitting the commit
to a CI system.
For several other things it makes a lot of sense
On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:
> > I think that would address the concern I raised, because it does not
> > create a roadblock to new users accomplishing their task. They can
> > ignore the warning, or choose "merge" as the default to shut up the
> > warning (and it
On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote:
> On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:
>
> > You are in favor of an _option_ to allow people to forbid a pull in
> > a non-ff situation, and I think other people are also in
> > agreement. So perhaps:
> >
> > -
On Sun, Sep 08, 2013 at 03:50:46AM -0400, Jeff King wrote:
> > > If you are interested, I can ask the opinion of some of the GitHub
> > > trainers. They see a lot of new users and have a sense of what kinds of
> > > confusion come up most frequently, what kinds of workflows they tend to
> > > see,
Junio, would you please pull the following into pu:
git://git.linaro.org/people/nico/git
This is the pack v4 work to date which is somewhat getting usable. It
is time it gets more exposure, and possibly some more people's attention
who would like to work on the missing parts as I need
On Sun, Sep 08, 2013 at 11:03:52AM +0100, John Keeping wrote:
> > I know those are all balanced by some advantages of rebasing, but I also
> > think they are things that can be troublesome for a user who does not
> > fully grok the rebase process. I'm just wondering if we should mention
> > both,
On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:
> You are in favor of an _option_ to allow people to forbid a pull in
> a non-ff situation, and I think other people are also in
> agreement. So perhaps:
>
> - drop jc/pull-training-wheel and revert its merge from 'next';
>
> - up
On Mon, 9 Sep 2013, Junio C Hamano wrote:
> Nicolas Pitre writes:
>
> > Do we know the actual number of objects to send during the capability
> > negociation?
>
> No, and that is not what I meant. We know upfront after capability
> negotiation (by seeing a request to give them a thin-pack) th
On Sun, Sep 08, 2013 at 08:36:35PM -0400, Eric Sunshine wrote:
> On Sun, Sep 8, 2013 at 4:36 AM, Jeff King wrote:
> > When we are parsing an integer or unsigned long, we use
> > the strto*max functions, which properly set errno to ERANGE
> > if we get a large value. However, we also do further ra
Nicolas Pitre writes:
> Do we know the actual number of objects to send during the capability
> negociation?
No, and that is not what I meant. We know upfront after capability
negotiation (by seeing a request to give them a thin-pack) that we
will send, in addition to the usual packfile, the p
Of course pack v4, while significantly better on disk space, is still
lagging behind pack v2 in terms of runtime performance. This is because
right now the reading side is implemented as a compatibility layer that
parses the packv4 data to regenerate a canonical object representation,
which is
While reviewing the pack v4 thin support Ive realized that some base
tree objects appended to a thin pack won't be in pack v4 format. Hence
the patch below to deal with that possibility.
An eventual optimization to index-pack when completing a pack would be
to attempt the encoding of appended
On Mon, 9 Sep 2013, Junio C Hamano wrote:
> Nicolas Pitre writes:
>
> >> > ... I was
> >> > wondering if some kind of prefix to the pack stream could be inserted
> >> > onto the wire when sending a pack v4. Something like:
> >> >
> >> > 'T', 'H', 'I', 'N',
> >> >
> >> > This 8-byte prefix w
On Mon, Sep 9, 2013 at 12:32 PM, Junio C Hamano wrote:
>> + echo "initial in dir1/dir2" >expected &&
>> + git -C dir1/dir2 commit -m "initial in dir1/dir2" &&
>
> to reduce possibilities of breaking this test in the future due to
> typos (e.g. somebody may want to say "initial commit in di
Nicolas Pitre writes:
> On Mon, 9 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
>
>> nr_objects in the next patch is used to reflect the number of actual
>> objects in the stream, which may be smaller than the number recorded
>> in pack header.
>
> This highlights an issue that has been nagging me for a
On Mon, 9 Sep 2013, Junio C Hamano wrote:
> Nicolas Pitre writes:
>
> > On Mon, 9 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
> >
> >> nr_objects in the next patch is used to reflect the number of actual
> >> objects in the stream, which may be smaller than the number recorded
> >> in pack header.
> >
Yikes. The updated series looks very sensible, but I already have
the previous one in 'next'.
Will do the usual "revert and requeue" dance...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
Nicolas Pitre writes:
>> > ... I was
>> > wondering if some kind of prefix to the pack stream could be inserted
>> > onto the wire when sending a pack v4. Something like:
>> >
>> > 'T', 'H', 'I', 'N',
>> >
>> > This 8-byte prefix would simply be discarded by index-pack after being
>> > pars
Matthieu Moy writes:
> First, the discussions on this thread show that it's hard to find the
> right behavior. My guess is that it's hard because we're trying to think
> for the users. I've used GNU Arch for a while, and this VCS was trying
> to impose what the developer thought was good for me.
Eric Sunshine writes:
> On Mon, Sep 9, 2013 at 12:32 PM, Junio C Hamano wrote:
>> Nazri Ramliy writes:
>>
>>> Subject: git: run in a directory given with -C option
>>>
>>> +-C ::
>>> + Run as if git was started in '' instead of the current working
>>> + directory. When multiple '-C' op
On Mon, Sep 9, 2013 at 12:32 PM, Junio C Hamano wrote:
> Nazri Ramliy writes:
>
>> Subject: git: run in a directory given with -C option
>>
>> +-C ::
>> + Run as if git was started in '' instead of the current working
>> + directory. When multiple '-C' options are given, each subsequent
Nazri Ramliy writes:
> Subject: git: run in a directory given with -C option
>
> This is similar in spirit to to "make -C dir ..." and "tar -C dir ...".
The doubled-"to to" which I locally fixed when I queued the last one
(together with other rewording to make it more agreeable and easier
to rea
"brian m. carlson" writes:
> If SSL verification is enabled in git send-email, we could attempt to call a
> method on an undefined value if the verification failed, since $smtp would end
> up being undef. Look up the error string in a way that will produce a helpful
> error message and not cause
On Mon, 09 Sep 2013 07:44:04 +, Junio C Hamano wrote:
...
> I'd rather not go this route. Allowing refs/heads/master and local
> branches that forked from it in refs/heads/master/{a,b,c,...} could
> be a potentially useful future enhancement,
Want! We're currently going the route of naming th
Matthieu Moy writes:
> Since a1549e10, git-rebase--am.sh uses the shell's "return" statement, to
> mean "return from the current file inclusion", which is POSIXly correct,
> but badly interpreted on FreeBSD, which returns from the current
> function, hence skips the finish_rebase statement that f
Nicolas Pitre writes:
> Is anyone still using --max-pack-size ?
>
> I'm wondering if producing multiple packs from pack-objects is really
> useful these days. If I remember correctly, this was created to allow
> the archiving of large packs onto CDROMs or the like.
I thought this was more abo
"Philip Oakley" writes:
> One is to extend the ref format such that
> refs/heads/Test:HEAD
> would be considered a valid indicator of a symref relationship
> (i.e. using the typical 'colon' style). It would be appended after the
> regular refs, so all the existing refs are still transported.
>
On Mon, 9 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
> nr_objects in the next patch is used to reflect the number of actual
> objects in the stream, which may be smaller than the number recorded
> in pack header.
This highlights an issue that has been nagging me for a while.
We decided to send the fi
This helps construct tree dictionary in pack v4.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 2 +-
builtin/rev-list.c | 4 ++--
list-objects.c | 9 -
list-objects.h | 3 ++-
upload-pack.c | 2 +-
5 files changed, 14 insertions(+), 6 delet
SHA-1 table is trickier than ident or path tables because it must
contains exactly the number entries in pack. In the thin pack case it
must also cover bases that will be appended by index-pack.
The problem is not all preferred_base entries end up becoming actually
needed. So we do a fake write_on
Signed-off-by: Nguyễn Thái Ngọc Duy
---
pack-write.c | 33 +
pack.h | 1 +
2 files changed, 34 insertions(+)
diff --git a/pack-write.c b/pack-write.c
index 36b88a3..c1e9da4 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -1,6 +1,7 @@
#include "cache.h"
#
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index b38d3dc..9613732 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -1756,8 +1756,12 @@ s
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 62 --
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index fb2394d..60ea5a7 100644
--- a/builtin/pack-objects.c
+++ b/
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 33faea8..ef68fc5 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -81,6 +81,7 @@ static
In v2, the number of objects in the pack header indicates how many
objects are sent. In v4 this is no longer true, that number includes
the base objects ommitted by pack-objects. An "end-of-pack" is
inserted just before the final SHA-1 to let index-pack knows when to
stop. The EOP is zero (in varia
commit_ident_table and tree_path_table are local to packv4-create.c
and test-packv4.c. Move them out of add_*_dict_entries so
add_*_dict_entries can be exported to pack-objects.c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
packv4-create.c | 22 --
1 file changed, 12 insertions(+)
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 53 +---
1 file changed, 38 insertions(+), 15 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index dc9961b..8a6e2a3 100644
--- a/builtin/index-pack.c
+++ b/built
nr_objects in the next patch is used to reflect the number of actual
objects in the stream, which may be smaller than the number recorded
in pack header.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 9613732..fb2394d 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -1329,7 +1329,8 @@ sta
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 85 +-
pack.h | 2 +-
2 files changed, 78 insertions(+), 9 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 055b59d..12d9af4 100644
--
Signed-off-by: Nguyễn Thái Ngọc Duy
---
packv4-create.c | 103 --
packv4-create.h (new) | 11 ++
2 files changed, 69 insertions(+), 45 deletions(-)
create mode 100644 packv4-create.h
diff --git a/packv4-create.c b/packv4-create.c
index
git-packv4-create now becomes test-packv4. Code that will not be used
by pack-objects.c is moved to test-packv4.c. It may be removed when
the code transition to pack-objects completes.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Makefile| 4 +-
packv4-create.c | 480 +--
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 2 +-
bulk-checkin.c | 2 +-
pack-write.c | 7 +--
pack.h | 3 +--
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index f069462..
Signed-off-by: Nguyễn Thái Ngọc Duy
---
pack-write.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/pack-write.c b/pack-write.c
index 88e4788..36b88a3 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -325,8 +325,17 @@ int encode_in_pack_object_header(enum object_t
This version supports thin pack. I could clone from git.git with only
master, then fetch the rest and fsck did not complain anything. I did
not check if I broke --max-pack-size though.
Interesting patches are the ones near the end: "prepare SHA-1 table",
"support writing pack v4" and "support comp
On Mon, Sep 09, 2013 at 01:01:33AM -0400, Eric Sunshine wrote:
> On Sun, Sep 8, 2013 at 9:49 PM, Nazri Ramliy wrote:
> Thanks for the reference. I did read that thread earlier. It doesn't
> really answer my question, but perhaps it's not terribly important
> since the interaction is documented. I
Hi Folks,
Here is the fifth revision of a series to support locking multiple
refs at the same time to update all of them consistently. The
previous revisions of the series can be found at $gmane/233260,
$gmane/233458, $gmane/233647, and $gmane/233840.
Updates since the previous revision of the s
Add a --stdin signature to read update instructions from standard input
and apply multiple ref updates together. Use an input format that
supports any update that could be specified via the command-line,
including object names like "branch:path with space".
Signed-off-by: Brad King
---
Document
Extend t/t1400-update-ref.sh to cover cases using the --stdin option.
Signed-off-by: Brad King
---
t/t1400-update-ref.sh | 639 ++
1 file changed, 639 insertions(+)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index e415ee0..a510500
On Mon, 9 Sep 2013, Duy Nguyen wrote:
> On Sun, Sep 8, 2013 at 10:04 PM, Nguyễn Thái Ngọc Duy
> wrote:
> > +static void prepare_sha1_table(void)
> > +{
> > + unsigned i;
> > + /*
> > +* This table includes SHA-1s that may not be present in the
> > +* pack. One of the
On Sun, Sep 8, 2013 at 10:04 PM, Nguyễn Thái Ngọc Duy wrote:
> +static void prepare_sha1_table(void)
> +{
> + unsigned i;
> + /*
> +* This table includes SHA-1s that may not be present in the
> +* pack. One of the use of such SHA-1 is for completing thin
> +* pa
Dear Beneficiary,
You have won £1,000.000 great british pounds in the ongoing promo draw.
For claims, contact Mr Jeremy via email on: enquiry.d...@qq.com
Thanks,
Notification Department.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.
1 - 100 of 106 matches
Mail list logo
