On Tue, Jan 29, 2013 at 11:53:19AM -0800, Junio C Hamano wrote:
> Either way it still encourages a plaintext password to be on disk,
> which may not be what we want, even though it may be slight if not
> really much of an improvement. Again the Help-for-users has this
> amusing bit:
I do not min
Junio C Hamano writes:
> Please take this as just a preview of early WIP. I think I may end
> up doing moderate amount of refactoring as a preparatory step before
> these patches, so nitpick-reviews are likely to become waste of
> reviewer's time at this point.
I've pushed out a mostly-done rer
On Wed, Jan 30, 2013 at 10:31:43AM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Jan 29, 2013 at 4:14 PM, Jeff King wrote:
> > The timings from this one are roughly similar to what I posted earlier.
> > Unlike the earlier version, this one keeps the data for a single commit
> > together for better
> True, but it is even less headache if the file is totally separate and
> optional.
Once you start thinking about using an offset to some list of SHA-1,
perhaps? A section inside the same file can never go out of sync.
Also a longer-term advantage is that you can teach index-pack to do
this.
--
On Wed, Jan 30, 2013 at 10:36:10AM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Jan 29, 2013 at 4:16 PM, Jeff King wrote:
> > +int commit_metapack(unsigned char *sha1,
> > + uint32_t *timestamp,
> > + unsigned char **tree,
> > + unsigned char
On Tue, Jan 29, 2013 at 10:08:08AM -0800, Junio C Hamano wrote:
> > In order to reduce the disk footprint and I/O cost, the future
> > direction for this mechanism may want to point into an existing
> > store of SHA-1 hashes with a shorter file offset, and the .idx file
> > could be such a store,
On Tue, Jan 29, 2013 at 09:38:10AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > +int commit_metapack(unsigned char *sha1,
> > + uint32_t *timestamp,
> > + unsigned char **tree,
> > + unsigned char **parent1,
> > + unsigned char **
David Aguilar writes:
> Update variable assignments to always use $(command "$arg")
> in their RHS instead of "$(command "$arg")" as the latter
> is harder to read. Make get_merge_tool_cmd() simpler by
> avoiding "echo" and $(command) substitutions completely.
>
> Signed-off-by: David Aguilar
>
On Wed, Jan 30, 2013 at 08:30:57AM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Jan 29, 2013 at 4:15 PM, Jeff King wrote:
> > +static void write_meta_header(struct metapack_writer *mw, const char *id,
> > + uint32_t version)
> > +{
> > + version = htonl(version);
On Tue, Jan 29, 2013 at 09:35:12AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > +static void write_meta_header(struct metapack_writer *mw, const char *id,
> > + uint32_t version)
> > +{
> > + version = htonl(version);
> > +
> > + sha1write(mw->out, "META", 4
Update variable assignments to always use $(command "$arg")
in their RHS instead of "$(command "$arg")" as the latter
is harder to read. Make get_merge_tool_cmd() simpler by
avoiding "echo" and $(command) substitutions completely.
Signed-off-by: David Aguilar
---
This is a replacement patch for
On 01/29/2013 12:10 PM, Jeff King wrote:
> On Tue, Jan 29, 2013 at 11:15:34AM +0100, Michael Haggerty wrote:
>> Please document the new functions in
>> Documentation/technical/api-strbuf.txt. Personally I would also
>> advocate a "docstring" in the header file, but obviously that preference
>> is
On Tue, Jan 29, 2013 at 4:16 PM, Jeff King wrote:
> +int commit_metapack(unsigned char *sha1,
> + uint32_t *timestamp,
> + unsigned char **tree,
> + unsigned char **parent1,
> + unsigned char **parent2)
> +{
Nit picking. tree
Junio C Hamano writes:
> Heh, I actually was hoping that you will send in a replacement for
> David's patch ;-)
>
> Here is what I will squash into the one we have been discussing. In
> a few hours, I expect I'll be able to push this out in the 'pu'
> branch.
I ended up doing this a bit differe
On Tue, Jan 29, 2013 at 4:14 PM, Jeff King wrote:
> The timings from this one are roughly similar to what I posted earlier.
> Unlike the earlier version, this one keeps the data for a single commit
> together for better cache locality (though I don't think it made a big
> difference in my tests, s
John Keeping writes:
> On Tue, Jan 29, 2013 at 02:55:26PM -0800, Junio C Hamano wrote:
> ...
>> I can work with John to get this part into a shape to support his
>> extended use sometime toward the end of this week, by which time
>> hopefully you have some time to comment on the result. John, ho
On Jan 29, 2013, at 7:25 AM, Ævar Arnfjörð Bjarmason wrote:
> On Sun, Jan 27, 2013 at 9:37 AM, Michael Haggerty
> wrote:
>> A while ago, I submitted an RFC for adding a new email notification
>> script to "contrib" [1]. The reaction seemed favorable and it was
>> suggested that the new script
On Tue, Jan 29, 2013 at 4:15 PM, Jeff King wrote:
> +static void write_meta_header(struct metapack_writer *mw, const char *id,
> + uint32_t version)
> +{
> + version = htonl(version);
> +
> + sha1write(mw->out, "META", 4);
> + sha1write(mw->out, "\0\0\
On Wed, Jan 30, 2013 at 1:44 AM, Jonathan Nieder wrote:
>> - # You are currently rebasing.
>> + # You are currently rebasing branch '\''rebase_conflicts'\'' on
>> '\''000106f'\''.
>
> SHA1-in-tests radar blinking.
>
> Would it be possible to compute the expected output, as in
>
>
Michal Nazarewicz writes:
>> Is it bad to use Net::Netrc instead? This looks like exactly the
>> use case that module was written for, no?
>
> I don't think that's the case. For one, Net::Netrc does not seem to
> process port number.
>
> There is a Text::Authinfo module but it just uses Text::C
Ah! Lovely, thank you, Jeff!
Alas, it's a shared server so I'm limited to what the host provides, but that
solves my problem.
Cheers!
On 29 Jan 2013, at 19:23, Jeff King wrote:
> On Tue, Jan 29, 2013 at 04:54:13PM +1100, Michael Tyson wrote:
>
>> I've a readonly git repository that I'm hos
From: Michal Nazarewicz
Make git-send-email read password from a ~/.authinfo or ~/.netrc file
instead of requiring it to be stored in git configuration, passed as
command line argument or typed in.
There are various other applications that use this file for
authentication information so letting
On Tue, Jan 29, 2013 at 02:55:26PM -0800, Junio C Hamano wrote:
> David Aguilar writes:
>
> > I don't want to stomp on your feet and poke at this file too much if
> > you're planning on building on top of it (I already did a few times
> > ;-). My git time is a bit limited for the next few days s
On Tue, Jan 29, 2013 at 02:27:21PM -0800, David Aguilar wrote:
> I don't want to stomp on your feet and poke at this file too much if
> you're planning on building on top of it (I already did a few times
> ;-). My git time is a bit limited for the next few days so I don't
> want to hold you up. I
David Aguilar writes:
> I don't want to stomp on your feet and poke at this file too much if
> you're planning on building on top of it (I already did a few times
> ;-). My git time is a bit limited for the next few days so I don't
> want to hold you up. I can help shepherd through small fixups
Michal Nazarewicz writes:
>> It is rather strange to require a comma-separated-values parser to
>> read a file format this simple, isn't it?
>
> I was worried about spaces in password. CVS should handle such case
> nicely, whereas simple split won't. Nonetheless, I guess that in the
> end this
David Aguilar writes:
> On Tue, Jan 29, 2013 at 11:22 AM, John Keeping wrote:
>> On Sun, Jan 27, 2013 at 04:52:23PM -0800, David Aguilar wrote:
>>> Update variable assignments to always use $(command "$arg")
>>> in their RHS instead of "$(command "$arg")" as the latter
>>> is harder to read. Ma
On Tue, Jan 29, 2013 at 12:22 PM, Junio C Hamano wrote:
> John Keeping writes:
>
>> On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
>>> --- a/git-mergetool--lib.sh
>>> +++ b/git-mergetool--lib.sh
>>> @@ -2,6 +2,35 @@
>>> # git-mergetool--lib is a library for common merge tool func
Jeff King writes:
>> > But how do these somewhat mediocre concatenated packs get turned into
>> > real packs?
>>
>> How do they get processed in a fetch-only repositories that
>> sometimes run "gc --auto" today? By runninng "repack -a -d -f"
>> occasionally, perhaps?
>
> Do we run "repack -adf"
On Tue, Jan 29, 2013 at 11:22 AM, John Keeping wrote:
> On Sun, Jan 27, 2013 at 04:52:23PM -0800, David Aguilar wrote:
>> Update variable assignments to always use $(command "$arg")
>> in their RHS instead of "$(command "$arg")" as the latter
>> is harder to read. Make get_merge_tool_cmd() simple
On Tue, Jan 29, 2013 at 07:58:01AM -0800, Junio C Hamano wrote:
> The point is not about space. Disk is cheap, and it is not making
> it any worse than what happens to your target audience, that is a
> fetch-only repository with only "gc --auto" in it, where nobody
> passes "-f" to "repack" to ca
From: Michal Nazarewicz
Make git-send-email read password from a ~/.authinfo or a ~/.netrc
file instead of requiring it to be stored in git configuration, passed
as command line argument or typed in.
There are various other applications that use this file for
authentication information so lettin
Sorry for being absent a long time. I hope you have managed to sort out
the git-blame fixes anyway.
Jonathan Nieder writes:
>Without this patch, the author column in git-blame-mode spills
>over in some rows:
>
> 822a7d :const char git_usage_
> f2dd8c : "git [--version] [--exec-
>
Toralf Förster wrote:
> On 01/29/2013 08:57 PM, Jonathan Nieder wrote:
>> As you guessed, 7.0.45 seems to live in a different area of history. :)
>
> Well, seems be point to the root cause ..
>
> BTW
> $> gitk --simplify-by-decoration
> client_release_7.0.44..client_release_7.0.45
>
> only 3 ro
John Keeping writes:
> On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
>> --- a/git-mergetool--lib.sh
>> +++ b/git-mergetool--lib.sh
>> @@ -2,6 +2,35 @@
>> # git-mergetool--lib is a library for common merge tool functions
>> MERGE_TOOLS_DIR=$(git --exec-path)/mergetools
>>
>> +
On 01/29/2013 08:57 PM, Jonathan Nieder wrote:
> As you guessed, 7.0.45 seems to live in a different area of history. :)
Well, seems be point to the root cause ..
BTW
$> gitk --simplify-by-decoration client_release_7.0.44..client_release_7.0.45
only 3 rows in the main window where
$> gitk clie
Hi Toralf,
Toralf Förster wrote:
> $> git clone git://boinc.berkeley.edu/boinc.git
>
> the following 2 commands shows both starting and ending revisions :
>
> $> gitk client_release_7.0.41..client_release_7.0.42
gitk is running something similar to
git log --graph --decorate --boundary
On Tue, Jan 29, 2013 at 11:34:31AM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
> > Changes since v1:
> >
> > - Set 3.1 as the minimum Python 3 version
> >
> > - Remove the section on Unicode literals - it just adds confusion and
> > doesn't apply to the current code; we can deal with
Michal Nazarewicz writes:
> From: Michal Nazarewicz
>
> Make git-send-email read password from a ~/.authinfo file instead of
> requiring it to be stored in git configuration, passed as command line
> argument or typed in.
Makes one wonder why .authinfo and not .netrc;
http://www.gnu.org/softw
On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -2,6 +2,35 @@
> # git-mergetool--lib is a library for common merge tool functions
> MERGE_TOOLS_DIR=$(git --exec-path)/mergetools
>
> +mode_ok () {
> + diff_mode &
For a cloned BOINC git tree :
$> git clone git://boinc.berkeley.edu/boinc.git
the following 2 commands shows both starting and ending revisions :
$> gitk client_release_7.0.41..client_release_7.0.42
$> gitk client_release_7.0.43..client_release_7.0.44
however this command doesn't show the tag "
John Keeping writes:
> Changes since v1:
>
> - Set 3.1 as the minimum Python 3 version
>
> - Remove the section on Unicode literals - it just adds confusion and
> doesn't apply to the current code; we can deal with any issues if they
> ever arise.
> ...
> + - We use the 'b' prefix for bytes l
Junio C Hamano wrote:
> - refer to gmane;
GMane has a wonderful interface, and deserves to be advertised.
> - git-scm.org gives a CNAME with less commercial feeling to the
>same thing;
Nice touch.
> - "A note from the maintainer" is not usually followed by useful
>discussion to discu
On Sun, Jan 27, 2013 at 04:52:23PM -0800, David Aguilar wrote:
> Update variable assignments to always use $(command "$arg")
> in their RHS instead of "$(command "$arg")" as the latter
> is harder to read. Make get_merge_tool_cmd() simpler by
> avoiding "echo" and $(command) substitutions complete
These are kept short by simply deferring to PEP-8. Most of the Python
code in Git is already very close to this style (some things in contrib/
are not).
Rationale for version suggestions:
- Amongst the noise in [1], there isn't any disagreement about using
2.6 as a base (see also [2]), altho
From: Michal Nazarewicz
Make git-send-email read password from a ~/.authinfo file instead of
requiring it to be stored in git configuration, passed as command line
argument or typed in.
There are various other applications that use this file for
authentication information so letting users use it
Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> In the spirit of status' in-progress info. I think showing this is
> more useful than "(no branch)". I tend to do "git br" more often than
> "git st" and this catches my eyes.
Very nice idea. This would also have been
How about doing this instead, to update all outdated or incorrect
information in that file? In addition to the marc.info update,
- refer to gmane;
- git-scm.org gives a CNAME with less commercial feeling to the
same thing;
- "A note from the maintainer" is not usually followed by useful
Hi Duy,
Nguyễn Thái Ngọc Duy wrote:
> --- a/t/t7512-status-help.sh
> +++ b/t/t7512-status-help.sh
> @@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before
> resolving conflicts'
> test_must_fail git rebase HEAD^ --onto HEAD^^ &&
> cat >expected <<-\EOF &&
>
Jonathan Nieder writes:
> Odd. "https://www.gravatar.com/"; also seems to work. I've put in a
> technical support query to find out what the Gravatar admins prefer.
Thanks; will hold onto Andrej's patch until we hear what the story
is.
Of course we could do something like this (untested).
g
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Ramkumar Ramachandra writes:
>>
>>> marc.theaimsgroup.com does not exist anymore, so replace it
>>> with a link to the archive on GMane.
>>
>> I think it has been at http://marc.info/?l=git for some time.
>
> Isn't GMane what all of us refe
Junio C Hamano writes:
> I am torn on this one.
>
> These cached properties of a single commit will not change no matter
> which pack it appears in, and it feels logically wrong, especially
> when you record these object names in the full SHA-1 form, to tie a
> "commit metapack" to a pack. Logic
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> marc.theaimsgroup.com does not exist anymore, so replace it
>> with a link to the archive on GMane.
>
> I think it has been at http://marc.info/?l=git for some time.
Isn't GMane what all of us refer to on the list though?
--
To unsubscribe
Jeff King writes:
> +int commit_metapack(unsigned char *sha1,
> + uint32_t *timestamp,
> + unsigned char **tree,
> + unsigned char **parent1,
> + unsigned char **parent2)
> +{
> + struct commit_metapack *p;
> +
> + prepare_co
Jeff King writes:
> +static void write_meta_header(struct metapack_writer *mw, const char *id,
> + uint32_t version)
> +{
> + version = htonl(version);
> +
> + sha1write(mw->out, "META", 4);
> + sha1write(mw->out, "\0\0\0\1", 4);
> + sha1write(mw->out, mw
On Tue, Jan 29, 2013 at 08:15:15AM -0800, Junio C Hamano wrote:
> With any backend that is non-trivial, it would not be unusual for
> the *tool.cmd to look like:
>
> [mergetool]
> mytool = sh -c '
> ... some massaging to prepare the command line
> ... to ru
Ramkumar Ramachandra writes:
> marc.theaimsgroup.com does not exist anymore, so replace it
> with a link to the archive on GMane.
I think it has been at http://marc.info/?l=git for some time.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> On Tue, Jan 29, 2013 at 11:35 AM, Duy Nguyen wrote:
>>> :(glob) magic
>>> =
>>>
>>> This magic is for people who want globbing. However, it does _not_ use
>>> the same matching mechanism the non-magic pathspec does today. It uses
>>>
Duy Nguyen writes:
> On Tue, Jan 29, 2013 at 11:35 AM, Duy Nguyen wrote:
>> :(glob) magic
>> =
>>
>> This magic is for people who want globbing. However, it does _not_ use
>> the same matching mechanism the non-magic pathspec does today. It uses
>> wildmatch(WM_PATHNAME), which basic
Matthieu Moy writes:
> Not HEAD, but .git/rebase-merge/onto, i.e. the target of the rebase.
> Ideally, I would have loved to see "rebasing master on origin/master",
> but I do not think the target ref name is stored during rebase.
Perhaps do it with --format=%s then. It often is useless to know
John Keeping writes:
> On Tue, Jan 29, 2013 at 12:56:58PM +0100, Joachim Schmitz wrote:
>> John Keeping wrote:
>> > Currently I'm extracting the command word using:
>> >
>> >cmd=$(eval -- "set -- $(git config mergetool.$tool.cmd); echo
>> > \"$1\"")
>>
>> Shouldnt this work?
>> cmd=$((git co
Jeff King writes:
>> I also wonder if we would be helped by another "repack" mode that
>> coalesces small packs into a single one with minimum overhead, and
>> run that often from "gc --auto", so that we do not end up having to
>> have 50 packfiles.
>> ...
>
> I'm not sure. If I understand you co
On Sun, Jan 27, 2013 at 9:37 AM, Michael Haggerty wrote:
> A while ago, I submitted an RFC for adding a new email notification
> script to "contrib" [1]. The reaction seemed favorable and it was
> suggested that the new script should replace post-receive-email rather
> than be added separately, i
Jeff King wrote:
>On Sat, Jan 26, 2013 at 10:32:42PM -0800, Junio C Hamano wrote:
>
>> Both makes sense to me.
>>
>> I also wonder if we would be helped by another "repack" mode that
>> coalesces small packs into a single one with minimum overhead, and
>> run that often from "gc --auto", so th
Hi Jed, all,
On 28.01.2013, at 06:19, Jed Brown wrote:
> I'm working on an hg remote helper that uses git notes for the sha1
> revision, so that git users can more easily refer to specific commits
> when communicating with hg users.
For the record, I am also working on that very same thing; it
Signed-off-by: Nguyễn Thái Ngọc Duy
---
- fix bisecting on detached HEAD
- show onto sha-1 for rebase
t/t7512-status-help.sh | 36 ++--
wt-status.c| 91 ++
wt-status.h| 2 ++
3 files changed, 105 insertio
Duy Nguyen writes:
> On Tue, Jan 29, 2013 at 7:31 PM, Matthieu Moy
> wrote:
>> I like the idea.
>>
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
>>> index b3f6eb9..096ba6f 100755
>>> --- a/t/t7512-status-help.sh
>>> +++ b/t/t7512-status-help
On Tue, Jan 29, 2013 at 7:31 PM, Matthieu Moy
wrote:
> I like the idea.
>
> Nguyễn Thái Ngọc Duy writes:
>
>> diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
>> index b3f6eb9..096ba6f 100755
>> --- a/t/t7512-status-help.sh
>> +++ b/t/t7512-status-help.sh
>> @@ -76,7 +76,7 @@ test_exp
I like the idea.
Nguyễn Thái Ngọc Duy writes:
> diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
> index b3f6eb9..096ba6f 100755
> --- a/t/t7512-status-help.sh
> +++ b/t/t7512-status-help.sh
> @@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before
> resolving c
On Tue, Jan 29, 2013 at 11:35 AM, Duy Nguyen wrote:
> :(glob) magic
> =
>
> This magic is for people who want globbing. However, it does _not_ use
> the same matching mechanism the non-magic pathspec does today. It uses
> wildmatch(WM_PATHNAME), which basically means '*' does not match
Signed-off-by: Nguyễn Thái Ngọc Duy
---
In the spirit of status' in-progress info. I think showing this is
more useful than "(no branch)". I tend to do "git br" more often than
"git st" and this catches my eyes.
builtin/branch.c| 10 +-
t/t6030-bisect-porcelain.sh | 2 +-
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Seems like a good thing to do.
t/t7512-status-help.sh | 36 +++
wt-status.c| 58 ++
wt-status.h| 1 +
3 files changed, 68 insertions(+), 27 deletions(-)
On Tue, Jan 29, 2013 at 12:56:58PM +0100, Joachim Schmitz wrote:
> John Keeping wrote:
> > Currently I'm extracting the command word using:
> >
> >cmd=$(eval -- "set -- $(git config mergetool.$tool.cmd); echo
> > \"$1\"")
>
> Shouldnt this work?
> cmd=$((git config "mergetool.$tool.cmd" || git
John Keeping wrote:
On Mon, Jan 28, 2013 at 01:50:19PM -0800, Junio C Hamano wrote:
What are the situations where a valid user-defined tools is
unavailable, by the way?
The same as a built-in tool: the command isn't available.
Currently I'm extracting the command word using:
cmd=$(eval --
On Tue, Jan 29, 2013 at 11:24:45AM +0100, Michael Haggerty wrote:
> On 01/29/2013 10:16 AM, Jeff King wrote:
> > When we are doing a commit traversal that does not need to
> > look at the commit messages themselves (e.g., rev-list,
> > merge-base, etc), we spend a lot of time accessing,
> > decomp
On Tue, Jan 29, 2013 at 11:15:34AM +0100, Michael Haggerty wrote:
> > +void strbuf_chompmem(struct strbuf *sb, const void *data, size_t len)
> > +{
> > + if (sb->len >= len && !memcmp(data, sb->buf + sb->len - len, len))
> > + strbuf_setlen(sb, sb->len - len);
> > +}
> > +
> > +void st
On Sun, Jan 27, 2013 at 1:32 PM, Junio C Hamano wrote:
> I also wonder if we would be helped by another "repack" mode that
> coalesces small packs into a single one with minimum overhead, and
> run that often from "gc --auto", so that we do not end up having to
> have 50 packfiles.
>
> When we hav
8f26aa4 (Makefile: remove tracking of TCLTK_PATH, 2012-12-18) removed
"/gitk-git/gitk-wish" from the toplevel .gitignore, with the intent of
moving it to gitk-git/.gitignore in a later patch. This was never
realized.
Signed-off-by: Ramkumar Ramachandra
---
Minor patch, so I didn't bother sendin
marc.theaimsgroup.com does not exist anymore, so replace it
with a link to the archive on GMane.
Signed-off-by: Ramkumar Ramachandra
---
README |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/README b/README
index 49713ea..3aae16a 100644
--- a/README
+++ b/README
@@ -4
On 01/29/2013 10:16 AM, Jeff King wrote:
> When we are doing a commit traversal that does not need to
> look at the commit messages themselves (e.g., rev-list,
> merge-base, etc), we spend a lot of time accessing,
> decompressing, and parsing the commit objects just to find
> the parent and timesta
On 01/29/2013 10:15 AM, Jeff King wrote:
> Sometimes it is handy to cut a trailing string off the end
> of a strbuf (e.g., a file extension). These helper functions
> make it a one-liner.
>
> Signed-off-by: Jeff King
> ---
> strbuf.c | 11 +++
> strbuf.h | 2 ++
> 2 files changed, 13 in
Now that we have the plumbing in place to generate and read
commit metapacks, we can hook them up to parse_commit to
fill in the traversal information much more quickly.
We only do so if save_commit_buffer is turned off;
otherwise, the callers will expect to be able to read
commit->buffer after pa
This is a plumbing command for generating metapack files.
Right now it understands only the "commits" metapack (and
there is not yet a reader). Eventually we may want to build
this metapack automatically when we generate a new pack.
Let's be conservative for now, though, and let the idea
prove itse
When we are doing a commit traversal that does not need to
look at the commit messages themselves (e.g., rev-list,
merge-base, etc), we spend a lot of time accessing,
decompressing, and parsing the commit objects just to find
the parent and timestamp information. We can make a
space-time tradeoff b
The on-disk packfile format is nicely compact, but it does
not always provide the fastest format for looking up
information. This patch introduces the concept of
"metapacks", optional metadata files which can live
alongside packs and represent their data in different ways.
This can allow space-time
Sometimes it is handy to cut a trailing string off the end
of a strbuf (e.g., a file extension). These helper functions
make it a one-liner.
Signed-off-by: Jeff King
---
strbuf.c | 11 +++
strbuf.h | 2 ++
2 files changed, 13 insertions(+)
diff --git a/strbuf.c b/strbuf.c
index 9a373be
We do not modify the buffer we are asked to write; mark it
with const so that callers with const buffers do not get
unnecessary complaints from the compiler.
Signed-off-by: Jeff King
---
csum-file.c | 6 +++---
csum-file.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cs
This is the cleaned-up version of the commit caching patches I mentioned
here:
http://article.gmane.org/gmane.comp.version-control.git/212329
The basic idea is to generate a cache file that sits alongside a
packfile and contains the timestamp, tree, and parents in a more compact
and easy-to-acc
[resending as plain text]
If a p4 client is configured to /p/foo which is a symlink
to /vol/bar/projects/foo, then resolving symlink, which
is done by git-p4's chdir will confuse p4: "Path
/vol/bar/projects/foo/... is not under client root /p/foo"
While AltRoots in p4 client specification can be u
On Sat, Jan 26, 2013 at 10:32:42PM -0800, Junio C Hamano wrote:
> Both makes sense to me.
>
> I also wonder if we would be helped by another "repack" mode that
> coalesces small packs into a single one with minimum overhead, and
> run that often from "gc --auto", so that we do not end up having t
On Tue, Jan 29, 2013 at 04:54:13PM +1100, Michael Tyson wrote:
> I've a readonly git repository that I'm hosting via HTTP (a bare git
> repository located within the appropriate directory on the server). I
> push to it via my own SSH account (local repository with a remote
> pointing to the ssh://
On Tue, Jan 29, 2013 at 12:10:59AM -0800, Shawn O. Pearce wrote:
> > On a repository with 120K refs, the advertisement portion of
> > upload-pack goes from ~3.4s to 3.2s (the failure to speed up
> > more is largely due to the fact that most of these refs are
> > tags, which need dereferenced to fi
On Fri, Jan 6, 2012 at 11:17 AM, Jeff King wrote:
> When we advertise a ref, the first thing we do is parse the
> pointed-to object. This gives us two things:
...
> The downside is that we are no longer verifying objects that
> we advertise by fully parsing them (however, we do still
> know we act
On Sat, Jan 26, 2013 at 10:32 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> This is a repost from here:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/211176
>>
>> which got no response initially. Basically the issue is that read-only
>> repos (e.g., a CI server) whose workfl
94 matches
Mail list logo
