* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Thomas Rast @ 2009-01-20 8:57 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Junio C Hamano, git
In-Reply-To: <200901192317.23079.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
Boyd Stephen Smith Jr. wrote:
> Is there anywhere you are publishing these refs? Of course, I see the
> commits in 'pu', but sometimes I would like to merge something you have
> in 'next'/'pu' into a branch based on 'master' or one of my local
> branches, and I have to go hunting for the commit SHA.
[...]
> $ git pull origin jk/color-parse
> fatal: Couldn't find remote ref jk/color-parse
You could try the script I posted here:
http://article.gmane.org/gmane.comp.version-control.git/106129
Just 'git resurrect -m jk/color-parse' and you should be good to go.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] bash completion: refactor diff options
From: Junio C Hamano @ 2009-01-20 8:36 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Shawn O. Pearce
In-Reply-To: <1232399880-22036-2-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> diff, log and show all take the same diff options. Refactor them from
> __git_diff and __git_log into a variable, and complete them in
> __git_show too.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
>
> ---
> contrib/completion/git-completion.bash | 36 ++++++++++++++++++-------------
> 1 files changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 096603b..bfae953 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -773,14 +773,7 @@ _git_describe ()
> __gitcomp "$(__git_refs)"
> }
>
> -_git_diff ()
> -{
> - __git_has_doubledash && return
> -
> - local cur="${COMP_WORDS[COMP_CWORD]}"
> - case "$cur" in
> - --*)
> - __gitcomp "--cached --stat --numstat --shortstat --summary
> +__git_diff_common_options="--stat --numstat --shortstat --summary
> --patch-with-stat --name-only --name-status --color
> --no-color --color-words --no-renames --check
> --full-index --binary --abbrev --diff-filter=
> @@ -789,9 +782,21 @@ _git_diff ()
> --ignore-all-space --exit-code --quiet --ext-diff
> --no-ext-diff
> --no-prefix --src-prefix= --dst-prefix=
> - --base --ours --theirs
> --inter-hunk-context=
> --patience
> + --raw
> +"
> +
> +_git_diff ()
> +{
> + __git_has_doubledash && return
> +
> + local cur="${COMP_WORDS[COMP_CWORD]}"
> + case "$cur" in
> + --*)
> + __gitcomp "--cached --pickaxe-all --pickaxe-regex
> + --base --ours --theirs
> + $__git_diff_common_options
> "
> return
> ;;
> @@ -977,17 +982,16 @@ _git_log ()
> --relative-date --date=
> --author= --committer= --grep=
> --all-match
> - --pretty= --name-status --name-only --raw
> + --pretty=
> --not --all
> --left-right --cherry-pick
> --graph
> - --stat --numstat --shortstat
> - --decorate --diff-filter=
> - --color-words --walk-reflogs
> + --decorate
> + --walk-reflogs
> --parents --children --full-history
> --merge
> --inter-hunk-context=
> - --patience
> + $__git_diff_common_options
> --pickaxe-all --pickaxe-regex
> "
I'll tweak this part to drop duplicated --ihc; other than that it looked
good. Thanks.
^ permalink raw reply
* Re: [PATCH] interpret_nth_last_branch(): avoid traversing the reflogs twice
From: Junio C Hamano @ 2009-01-20 8:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <alpine.DEB.1.00.0901191331590.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This, together with a removal of the hard-coded limit of 16 could be
> squashed with this patch:
Yeah, I think that makes very much sense, not because 16 is too small, but
because it does not make sense to keep track of all 16 when you asked for
the last (or the second from the last) event.
Thanks for a free sanity ;-)
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Brian Foster @ 2009-01-20 8:12 UTC (permalink / raw)
To: Dilip M; +Cc: Reece Dunn, git list
In-Reply-To: <c94f8e120901190637i294d379dke3a07a90da5076f8@mail.gmail.com>
On Monday 19 January 2009 15:37:06 Dilip M wrote:
> On Mon, Jan 19, 2009 at 5:29 PM, Reece Dunn <msclrhd@googlemail.com> wrote:
> > 2009/1/19 Dilip M <dilipm79@gmail.com>:
> >> ..I recently install GIT on Ubuntu (hardy) box....I am able to use
> >> 'gitk' only If I do 'sudo'. Without 'sudo' it complains 'repository
> >> not found'
> >
> > Who is the owner of the repository directory (and the .git directory)
> > and what are the permissions on the directory? [ ... ]
>
> dm-laptop:~/repos/atria> id -a
> uid=1000(dm) gid=1000(dm) [ ... ]
> dm-laptop:~/repos/atria> ls -lh .git/
>[... all looks Ok ...]
repeating Reece's question, what is the permissions/owner
_of_the_directory_which_contains_ the ‘.git/’ directory?
I can reproduce this behaviour (git 1.6.0.4) simply by
denying myself search (née execute) permission on that
directory, for entirely obvious reasons.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: [PATCH] git-svn: fix SVN 1.1.x compatibility
From: Tom G. Christensen @ 2009-01-20 8:11 UTC (permalink / raw)
To: Eric Wong; +Cc: git@vger.kernel.org
In-Reply-To: <20090120012301.GA30236@dcvr.yhbt.net>
Eric Wong wrote:
> "Tom G. Christensen" <tgc@statsbiblioteket.dk> wrote:
>> Eric Wong wrote:
>>> The get_log() function in the Perl SVN API introduced the limit
>>> parameter in 1.2.0. However, this got discarded in our SVN::Ra
>>> compatibility layer when used with SVN 1.1.x. We now emulate
>>> the limit functionality in older SVN versions by preventing the
>>> original callback from being called if the given limit has been
>>> reached. This emulation is less bandwidth efficient, but SVN
>>> 1.1.x is becoming rarer now.
>>>
>>> Additionally, the --limit parameter in svn(1) uses the
>>> aforementioned get_log() functionality change in SVN 1.2.x.
>>> t9129 no longer depends on --limit to work and instead uses
>>> Perl to parse out the commit message.
>>>
>>> Thanks to Tom G. Christensen for the bug report.
>>>
>>> Signed-off-by: Eric Wong <normalperson@yhbt.net>
>> I applied this to 1.6.1 and the testsuite now passes using SVN 1.1.4 on
>> RHEL 4/i386 (t9106 still fails on RHEL 4/x86_64).
>
> Any chance I could have access to that RHEL4/x86_64 environment?
Unfortunately I can't offer that.
It is really just a mock buildroot, and it should be possible to
recreate the problem with CentOS 4/x86_64.
On Fedora Linux the default mock install has a suitable config (epel-4).
If you're not a Fedora/CentOS person then I could possibly prepare a
VMware image for you.
> I'll
> try to work around bugs in older SVN as best I can, but can't guarantee
> anything.
>
I don't expect more than that.
-tgc
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Sixt @ 2009-01-20 7:55 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090120044021.GE30714@sigill.intra.peff.net>
Jeff King schrieb:
> - the test needs a few tweaks to be portable to Windows
While this is true, the workaround I have in my tree is so ugly that its
discussion would hold back this series unnecessarily. So, please don't
wait for the fixup of the test.
[My intention is to send test suite fixups for Windows as a separate
series, which would include the fixup for this case, too.]
-- Hannes
^ permalink raw reply
* Re: how to track multiple upstreams in one repository
From: Ciprian Dorin, Craciun @ 2009-01-20 7:29 UTC (permalink / raw)
To: Greg KH; +Cc: david, Bryan Donlan, git
In-Reply-To: <20090120033402.GC8754@kroah.com>
On Tue, Jan 20, 2009 at 5:34 AM, Greg KH <greg@kroah.com> wrote:
> On Mon, Jan 19, 2009 at 09:52:16AM +0200, Ciprian Dorin, Craciun wrote:
>> I use something even simpler, please see the attached .git/config
>> file that I use. It also uses remote branches, and rewrites the refs
>> to something like: stable/v2.6.25/master or torvalds/v2.6/master. Also
>> in order to fetch them I use git fetch stable/v2.6.25
>
> You all do know that all of the -stable trees are automatically kept in
> one repo on kernel.org, so you don't have to jump through all of these
> hoops, right?
>
> confused,
>
> greg k-h
:) This is something that escaped me... Could you give me the
exact git url for this repository? (on kernel.org I'm not able to find
it, just the current one...)
Thanks,
Ciprian Craciun.
^ permalink raw reply
* Re: [PATCH] Fix naming scheme for configure cache variables.
From: Ralf Wildenhues @ 2009-01-20 7:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljt6mqv0.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano wrote on Tue, Jan 20, 2009 at 07:30:27AM CET:
> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
>
> > In order to be cached, configure variables need to contain the
> > string '_cv_', and they should begin with a package-specific
> > prefix in order to avoid interfering with third-party macros.
> > Rename ld_dashr, ld_wl_rpath, ld_rpath to git_cv_ld_dashr etc.
> We require every patch we accept to be accompanied with a sign-off.
>
> Can you certify that ... [see Documentation/SubmittingPatches and look for
> (4) Sign your work] ... please?
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Sorry about that.
Cheers,
Ralf
^ permalink raw reply
* Re: [PATCH] Provide pessimistic defaults for cross compilation tests.
From: Ralf Wildenhues @ 2009-01-20 7:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Julius Naperkowski, git
In-Reply-To: <7v63kampwz.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano wrote on Tue, Jan 20, 2009 at 07:50:52AM CET:
> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> > --- a/configure.ac
> > +++ b/configure.ac
> > + [ac_cv_c_c99_format=no],
> > if test $ac_cv_c_c99_format = no; then
>
> This one probably is Ok, but...
>
> > @@ -380,6 +381,7 @@ AC_RUN_IFELSE(
> > FILE *f = fopen(".", "r");
> > return f && fread(&c, 1, 1, f)]])],
> > [ac_cv_fread_reads_directories=no],
> > + [ac_cv_fread_reads_directories=yes],
> > [ac_cv_fread_reads_directories=yes])
> > ])
> > if test $ac_cv_fread_reads_directories = yes; then
>
> I am not quite sure if this is an improvement ...
>
> > @@ -414,6 +416,7 @@ AC_RUN_IFELSE(
> > if (snprintf(buf, 3, "%s", "12345") != 5
> > || strcmp(buf, "12")) return 1]])],
> > [ac_cv_snprintf_returns_bogus=no],
> > + [ac_cv_snprintf_returns_bogus=yes],
> > [ac_cv_snprintf_returns_bogus=yes])
> > ])
> > if test $ac_cv_snprintf_returns_bogus = yes; then
>
> ... nor this one.
I can see why you're cautious here, but AFAICS the actual code that will
be enabled by these defaults is portable to systems that have no bogus
snprintf and whose fread does not read directories. IOW, all you lose
is a bit of performance at most.
> Is there a way to say something like "I'll autodetect as much as I can
> without running tests, but please tell me these characteristics of the
> target system manually" and leave the resulting config.mak.autogen in a
> shape that will guarantee compilation failure until the missing ones are
> supplied by config.mak?
Well, without my patch, each of these three tests will get configure to
error out. Instead of setting a variable, these added arguments can
also output a more helpful error, in the sense of
"please find out whether the return value of snprintf is ok,
and set $ac_cv_snprintf_returns_bogus accordingly when rerunning
configure"
> The thing is, I am not convinced that it is desirable to be able to build
> a possibly suboptimal binary in a cross compilation environment, without
> being told in what aspect of the resulting binary is suboptimal. I'd
> rather see a build system that honestly tells me what information it needs
> but couldn't find, so that I would know I have a chance to help it.
Sure.
> Of course, suggesting a pessimistic default that can result in suboptimal
> but correct result would be a good thing to help the user help the build.
> I just think it is a good idea to tell the user we are giving such hint a
> bit more loudly to draw attention.
Agreed, too. Would you prefer a hard erroring out of configure, for
each of the tests, or would it suffice to see a warning fly by?
Thanks,
Ralf
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Junio C Hamano @ 2009-01-20 7:04 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090120044021.GE30714@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Jan 19, 2009 at 01:13:30AM -0800, Junio C Hamano wrote:
>
>> * jk/signal-cleanup (Sun Jan 11 06:36:49 2009 -0500) 3 commits
>> - pager: do wait_for_pager on signal death
>> - refactor signal handling for cleanup functions
>> - chain kill signals for cleanup functions
>>
>> Sorry, I lost track. What is the status of this one?
>
> I need to clean up and re-send. The three improvements needed are:
> ...
Thanks.
^ permalink raw reply
* Re: [PATCH/RFC v2 1/1] bug fix, diff whitespace ignore options
From: Junio C Hamano @ 2009-01-20 7:04 UTC (permalink / raw)
To: Keith Cascio; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.GSO.2.00.0901191000520.25883@kiwi.cs.ucla.edu>
Keith Cascio <keith@CS.UCLA.EDU> writes:
> Fixed bug in diff whitespace ignore options. It is now
> OK to specify more than one whitespace ignore option
> on the command line.
>
> Signed-off-by: Keith Cascio <keith@cs.ucla.edu>
> ---
> Dscho,
> You are right. The code and the patch are more readable this way.
Thanks; I've fixed it up so there is no need to resend but your patch was
whitespace mangled (format=flowed), by the way.
^ permalink raw reply
* Re: [PATCH] commit: more compact summary and without extra quotes
From: Junio C Hamano @ 2009-01-20 7:04 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <1232405116-2359-1-git-send-email-santi@agolina.net>
I've updated the log message, so there is no need to resend. I suspect
that documentation/tutorial needs updating after this one.
Will apply to 'master'. Thanks.
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Junio C Hamano @ 2009-01-20 6:59 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Johannes Schindelin, Santi Béjar, Thomas Rast, git,
Teemu Likonen
In-Reply-To: <200901192145.21115.bss@iguanasuicide.net>
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> When diff is invoked with --color-words (w/o =regex), use the regular
> expression the user has configured as diff.color-words.
>
> diff drivers configured via attributes take precedence over the
> diff.color-words setting. If the user wants to change them, they have
> their own configuration variables.
This needs an entry in Documentation/config.txt
None of the existing configuration variables defined use hyphens in
multi-word variable names.
Other than that, I think this is a welcome addition to the suite.
Thanks.
^ permalink raw reply
* Re: [PATCH] Provide pessimistic defaults for cross compilation tests.
From: Ralf Wildenhues @ 2009-01-20 6:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Julius Naperkowski, git
In-Reply-To: <7vab9mpu8w.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano wrote on Tue, Jan 20, 2009 at 03:49:03AM CET:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > How do you deal with the hardcoded limitation that uname_S is defined to
> > be the output of "uname -s" on the _build_ system, and that quite a large
> > part of the Makefile sets variables dependent on this?
Oh, up to now I have blissfully ignored cross-compilation issues in git
outside of configure.ac. :-)
> > IOW are you certain that configure (with your patch) will override _all_
> > uname_S dependent settings?
No, I am certain they won't override them at all.
Fixing Makefile will be more (but independent) work. All I did was get
configure.ac in shape to not error out in the face of cross compilation.
> It may be a valid question but it is not limited to cross compilation, is
> it? The matter is if values the Makefile wants to default to can be
> overriden by whatever is placed in config.mak, and as long as that is Ok
> we won't have a problem with or without use of configure (which is a
> second class citizen).
Yeah, I figured that. I assume it makes little sense to suggest adding
AC_CANONICAL_HOST to configure.ac, letting config.{guess,sub} do their
job, and the user to use "./configure --host=some-value" to specify a
host alias, and then using the computed host triple to decide features,
without the need to modify Makefile or other input files.
See, in a way I come from the GNU world here, and that's what I know
best. Since git does its own setup here, I trust you will invent some
way to solve this.
Thanks,
Ralf
^ permalink raw reply
* Re: [PATCH] Provide pessimistic defaults for cross compilation tests.
From: Junio C Hamano @ 2009-01-20 6:50 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: Julius Naperkowski, git
In-Reply-To: <20090119203400.GA3539@ins.uni-bonn.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> In a cross compile setup, configure tests that run programs
> cannot be executed; in that case, provide pessimistic default
> values.
>
> Bug reported by Julius Naperkowski.
> ---
>
>> I can post a patch to add sane default settings for AC_RUN_IFELSE in
>> cross compile setups, this weekend.
>
> configure.ac | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 363547c..4a208d4 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -360,6 +360,7 @@ AC_RUN_IFELSE(
> else if (strcmp(buf, "12345"))
> return 2;]])],
> [ac_cv_c_c99_format=yes],
> + [ac_cv_c_c99_format=no],
> [ac_cv_c_c99_format=no])
> ])
> if test $ac_cv_c_c99_format = no; then
This one probably is Ok, but...
> @@ -380,6 +381,7 @@ AC_RUN_IFELSE(
> FILE *f = fopen(".", "r");
> return f && fread(&c, 1, 1, f)]])],
> [ac_cv_fread_reads_directories=no],
> + [ac_cv_fread_reads_directories=yes],
> [ac_cv_fread_reads_directories=yes])
> ])
> if test $ac_cv_fread_reads_directories = yes; then
I am not quite sure if this is an improvement ...
> @@ -414,6 +416,7 @@ AC_RUN_IFELSE(
> if (snprintf(buf, 3, "%s", "12345") != 5
> || strcmp(buf, "12")) return 1]])],
> [ac_cv_snprintf_returns_bogus=no],
> + [ac_cv_snprintf_returns_bogus=yes],
> [ac_cv_snprintf_returns_bogus=yes])
> ])
> if test $ac_cv_snprintf_returns_bogus = yes; then
... nor this one.
Is there a way to say something like "I'll autodetect as much as I can
without running tests, but please tell me these characteristics of the
target system manually" and leave the resulting config.mak.autogen in a
shape that will guarantee compilation failure until the missing ones are
supplied by config.mak?
The thing is, I am not convinced that it is desirable to be able to build
a possibly suboptimal binary in a cross compilation environment, without
being told in what aspect of the resulting binary is suboptimal. I'd
rather see a build system that honestly tells me what information it needs
but couldn't find, so that I would know I have a chance to help it.
Of course, suggesting a pessimistic default that can result in suboptimal
but correct result would be a good thing to help the user help the build.
I just think it is a good idea to tell the user we are giving such hint a
bit more loudly to draw attention.
^ permalink raw reply
* Re: [PATCH] contrib: add 'git bpush' to push to bundles
From: Mike Hommey @ 2009-01-20 6:47 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <1232408791-16834-1-git-send-email-santi@agolina.net>
On Tue, Jan 20, 2009 at 12:46:31AM +0100, Santi Béjar wrote:
> 'git bpush' updates the branches in a bundle, while adding the objects
> necessary to complete the given branches. Basically, it is a 'git
> push' for bundles.
I think it'd be better to improve git-push to support that, instead of
adding yet another git command.
Mike
^ permalink raw reply
* Re: [PATCH] Fix naming scheme for configure cache variables.
From: Junio C Hamano @ 2009-01-20 6:30 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20090119203436.GB3539@ins.uni-bonn.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> In order to be cached, configure variables need to contain the
> string '_cv_', and they should begin with a package-specific
> prefix in order to avoid interfering with third-party macros.
> Rename ld_dashr, ld_wl_rpath, ld_rpath to git_cv_ld_dashr etc.
> ---
>
> This avoids a warning with newer autoconf versions about the naming of
> the cache variables, and makes the caching work for them.
Thanks.
We require every patch we accept to be accompanied with a sign-off.
Can you certify that ... [see Documentation/SubmittingPatches and look for
(4) Sign your work] ... please?
^ permalink raw reply
* [PATCH] Introduce for_each_recent_reflog_ent().
From: Junio C Hamano @ 2009-01-20 6:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <alpine.DEB.1.00.0901191331590.3586@pacific.mpi-cbg.de>
This can be used to scan only the last few kilobytes of a reflog, as a
cheap optimization when the data you are looking for is likely to be
found near the end of it. The caller is expected to fall back to the
full scan if that is not the case.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
refs.c | 17 ++++++++++++++++-
refs.h | 1 +
sha1_name.c | 8 +++++++-
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index 33ced65..024211d 100644
--- a/refs.c
+++ b/refs.c
@@ -1453,7 +1453,7 @@ int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *
return 1;
}
-int for_each_reflog_ent(const char *ref, each_reflog_ent_fn fn, void *cb_data)
+int for_each_recent_reflog_ent(const char *ref, each_reflog_ent_fn fn, long ofs, void *cb_data)
{
const char *logfile;
FILE *logfp;
@@ -1464,6 +1464,16 @@ int for_each_reflog_ent(const char *ref, each_reflog_ent_fn fn, void *cb_data)
logfp = fopen(logfile, "r");
if (!logfp)
return -1;
+
+ if (ofs) {
+ struct stat statbuf;
+ if (fstat(fileno(logfp), &statbuf) ||
+ statbuf.st_size < ofs ||
+ fseek(logfp, -ofs, SEEK_END) ||
+ fgets(buf, sizeof(buf), logfp))
+ return -1;
+ }
+
while (fgets(buf, sizeof(buf), logfp)) {
unsigned char osha1[20], nsha1[20];
char *email_end, *message;
@@ -1497,6 +1507,11 @@ int for_each_reflog_ent(const char *ref, each_reflog_ent_fn fn, void *cb_data)
return ret;
}
+int for_each_reflog_ent(const char *ref, each_reflog_ent_fn fn, void *cb_data)
+{
+ return for_each_recent_reflog_ent(ref, fn, 0, cb_data);
+}
+
static int do_for_each_reflog(const char *base, each_ref_fn fn, void *cb_data)
{
DIR *dir = opendir(git_path("logs/%s", base));
diff --git a/refs.h b/refs.h
index 06ad260..3bb529d 100644
--- a/refs.h
+++ b/refs.h
@@ -60,6 +60,7 @@ extern int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned
/* iterate over reflog entries */
typedef int each_reflog_ent_fn(unsigned char *osha1, unsigned char *nsha1, const char *, unsigned long, int, const char *, void *);
int for_each_reflog_ent(const char *ref, each_reflog_ent_fn fn, void *cb_data);
+int for_each_recent_reflog_ent(const char *ref, each_reflog_ent_fn fn, long, void *cb_data);
/*
* Calls the specified function for each reflog file until it returns nonzero,
diff --git a/sha1_name.c b/sha1_name.c
index 4c0370b..38c9f1b 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -775,7 +775,13 @@ int interpret_nth_last_branch(const char *name, struct strbuf *buf)
strbuf_init(&cb.buf[i], 20);
cb.cnt = 0;
retval = 0;
- for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
+ for_each_recent_reflog_ent("HEAD", grab_nth_branch_switch, 40960, &cb);
+ if (cb.cnt < nth) {
+ cb.cnt = 0;
+ for (i = 0; i < nth; i++)
+ strbuf_release(&cb.buf[i]);
+ for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
+ }
if (cb.cnt < nth)
goto release_return;
i = cb.cnt % nth;
--
1.6.1.267.g11c6e
^ permalink raw reply related
* [PATCH] interpret_nth_last_branch(): plug small memleak
From: Junio C Hamano @ 2009-01-20 6:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <alpine.DEB.1.00.0901191331590.3586@pacific.mpi-cbg.de>
The error return path leaked both cb.buf[] strbuf array itself, and the
strings contained in its elements.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
sha1_name.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index f54b6cb..4c0370b 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -754,7 +754,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
int interpret_nth_last_branch(const char *name, struct strbuf *buf)
{
long nth;
- int i;
+ int i, retval;
struct grab_nth_branch_switch_cbdata cb;
const char *brace;
char *num_end;
@@ -774,17 +774,21 @@ int interpret_nth_last_branch(const char *name, struct strbuf *buf)
for (i = 0; i < nth; i++)
strbuf_init(&cb.buf[i], 20);
cb.cnt = 0;
+ retval = 0;
for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
if (cb.cnt < nth)
- return 0;
+ goto release_return;
i = cb.cnt % nth;
strbuf_reset(buf);
strbuf_add(buf, cb.buf[i].buf, cb.buf[i].len);
+ retval = brace-name+1;
+
+release_return:
for (i = 0; i < nth; i++)
strbuf_release(&cb.buf[i]);
free(cb.buf);
- return brace-name+1;
+ return retval;
}
/*
--
1.6.1.267.g11c6e
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Boyd Stephen Smith Jr. @ 2009-01-20 5:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpu3r745.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
On Monday 19 January 2009, Junio C Hamano <gitster@pobox.com> wrote
about 'What's cooking in git.git (Jan 2009, #04; Mon, 19)':
>Here are the topics that have been cooking. Commits prefixed with '-'
> are only in 'pu' while commits prefixed with '+' are in 'next'. The
> ones marked with '.' do not appear in any of the branches, but I am
> still holding onto them.
Is there anywhere you are publishing these refs? Of course, I see the
commits in 'pu', but sometimes I would like to merge something you have
in 'next'/'pu' into a branch based on 'master' or one of my local
branches, and I have to go hunting for the commit SHA.
It's not a big deal: qgit, gitk, and 'git log'+grep all solve the issue
quickly enough, and I don't want to add to your workload. I was just
hoping they were already published and I could simply add a remote to my
config to get them.
Currently, I'm just using:
* remote origin
URL: git://git.kernel.org/pub/scm/git/git.git
Remote branch merged with 'git pull' while on branch master
master
Tracked remote branches
html maint man master next pu todo
and I get this:
$ git pull origin jk/color-parse
fatal: Couldn't find remote ref jk/color-parse
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-20 4:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901191407470.3586@pacific.mpi-cbg.de>
On Mon, Jan 19, 2009 at 02:08:48PM +0100, Johannes Schindelin wrote:
> > * jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits
> > . valgrind: ignore ldso errors
> > . add valgrind support in test scripts
>
> Could you put this in pu, at least, please?
I don't think I've really touched this since it was posted. One of the
things I didn't like about it was that the valgrind wrapper directory
was created in the Makefile. I think creating it inside the trash
directory for each test run that wants to use valgrind makes more sense
(probably as .git/valgrind, which is unlikely to hurt anything but will
stay out of the way of most of the tests).
I doubt I will have the chance to look at it anytime soon, so please
feel free to pick up the topic if you are interested.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-20 4:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpu3r745.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 19, 2009 at 01:13:30AM -0800, Junio C Hamano wrote:
> * jk/signal-cleanup (Sun Jan 11 06:36:49 2009 -0500) 3 commits
> - pager: do wait_for_pager on signal death
> - refactor signal handling for cleanup functions
> - chain kill signals for cleanup functions
>
> Sorry, I lost track. What is the status of this one?
I need to clean up and re-send. The three improvements needed are:
- there is a related Windows cleanup from JSixt, which I will send
when I re-post
- the test needs a few tweaks to be portable to Windows
- Some of the signal handlers should be guarded from inserting
themselves multiple times. I don't think any are dangerous to run
twice (they generally traverse a list, cleaning up files, and then
remove the list elements), but I'm not sure that you can't get some
stupid behavior, like inserting one handler per diff'd file, which
will unnecessarily allocate memory.
This series fixes pager handling for interrupted git programs. There is
also a related fix that needs to be done for forked git programs. I
posted a "how about this" patch to use run_command for external git
programs, but it has some serious problems ("git bogus" no longer
reports an error!).
I have unfortunately not had very much git time lately, but I'll try to
come up with something for both cases this week.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-20 4:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpu3r745.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 19, 2009 at 01:13:30AM -0800, Junio C Hamano wrote:
> * jk/color-parse (Sat Jan 17 10:38:46 2009 -0500) 2 commits
> + expand --pretty=format color options
> + color: make it easier for non-config to parse color specs
I posted a revised version of 1/2 based on René's work, but it looks
like you have the original. So here it is on top of what's in next.
-- >8 --
From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
optimize color_parse_mem
Commit 5ef8d77a implemented color_parse_mem, a function for
parsing colors from a non-NUL-terminated string, by simply
allocating a new NUL-terminated string and calling
color_parse. This had a small but measurable speed impact on
a user format that used the advanced color parsing. E.g.,
# uses quick parsing
$ time ./git log --pretty=tformat:'%Credfoo%Creset' >/dev/null
real 0m0.673s
user 0m0.652s
sys 0m0.016s
# uses color_parse_mem
$ time ./git log --pretty=tformat:'%C(red)foo%C(reset)' >/dev/null
real 0m0.692s
user 0m0.660s
sys 0m0.032s
This patch implements color_parse_mem as the primary
function, with color_parse as a wrapper for strings. This
gives comparable timings to the first case above.
Original patch by René. Commit message and debugging by Jeff
King.
Signed-off-by: Jeff King <peff@peff.net>
---
color.c | 38 +++++++++++++++++++++-----------------
1 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/color.c b/color.c
index 54a3da1..915d7a9 100644
--- a/color.c
+++ b/color.c
@@ -41,29 +41,40 @@ static int parse_attr(const char *name, int len)
void color_parse(const char *value, const char *var, char *dst)
{
+ color_parse_mem(value, strlen(value), var, dst);
+}
+
+void color_parse_mem(const char *value, int value_len, const char *var,
+ char *dst)
+{
const char *ptr = value;
+ int len = value_len;
int attr = -1;
int fg = -2;
int bg = -2;
- if (!strcasecmp(value, "reset")) {
+ if (!strncasecmp(value, "reset", len)) {
strcpy(dst, "\033[m");
return;
}
/* [fg [bg]] [attr] */
- while (*ptr) {
+ while (len > 0) {
const char *word = ptr;
- int val, len = 0;
+ int val, wordlen = 0;
- while (word[len] && !isspace(word[len]))
- len++;
+ while (len > 0 && !isspace(word[wordlen])) {
+ wordlen++;
+ len--;
+ }
- ptr = word + len;
- while (*ptr && isspace(*ptr))
+ ptr = word + wordlen;
+ while (len > 0 && isspace(*ptr)) {
ptr++;
+ len--;
+ }
- val = parse_color(word, len);
+ val = parse_color(word, wordlen);
if (val >= -1) {
if (fg == -2) {
fg = val;
@@ -75,7 +86,7 @@ void color_parse(const char *value, const char *var, char *dst)
}
goto bad;
}
- val = parse_attr(word, len);
+ val = parse_attr(word, wordlen);
if (val < 0 || attr != -1)
goto bad;
attr = val;
@@ -115,7 +126,7 @@ void color_parse(const char *value, const char *var, char *dst)
*dst = 0;
return;
bad:
- die("bad color value '%s' for variable '%s'", value, var);
+ die("bad color value '%.*s' for variable '%s'", value_len, value, var);
}
int git_config_colorbool(const char *var, const char *value, int stdout_is_tty)
@@ -191,10 +202,3 @@ int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...)
va_end(args);
return r;
}
-
-void color_parse_mem(const char *value, int len, const char *var, char *dst)
-{
- char *tmp = xmemdupz(value, len);
- color_parse(tmp, var, dst);
- free(tmp);
-}
--
1.6.1.335.g0366b.dirty
^ permalink raw reply related
* Re: [PATCH] commit: more compact summary and without extra quotes
From: Jeff King @ 2009-01-20 4:14 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <1232405116-2359-1-git-send-email-santi@agolina.net>
On Mon, Jan 19, 2009 at 11:45:16PM +0100, Santi Béjar wrote:
> Original:
> [master]: created d9a5491: "foo:bar"
>
> While with the patch it becomes:
> [master d9a5491] foo:bar
>
> As discussed in the git mailing list:
>
> http://marc.info/?l=git&m=122765031208922&w=2
I agree with Junio that the URL is fine, but it should not _replace_ a
summary of the issue. But as for the patch itself, I think it is
sensible (and I remember wondering at some point what had become of your
proposal, since everybody seemed to like it).
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] expand --pretty=format color options
From: Jeff King @ 2009-01-20 4:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Markus Heidelberg, git
In-Reply-To: <7vljt6q4cf.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 19, 2009 at 03:10:56PM -0800, Junio C Hamano wrote:
> > Hrm. OK, it doesn't actually work always. It does for git-log, but not
> > for rev-list, which leaves diff_use_color_default as -1. I don't know if
> > there are any other ways you can get to this code path without having
> > set diff_use_color_default.
>
> Yuck, no matter what you do please don't contaminate plumbing with the UI
> color options.
Of course. But the problem is that rev-list is _already_ contaminated by
--pretty=format:%Cred. Or do you mean, you really want rev-list to
unconditionally output color in such a case?
-Peff
^ 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