* Re: rebase: strange failures to apply patc 3-way
From: Andrew Wong @ 2013-03-08 15:32 UTC (permalink / raw)
To: Max Horn; +Cc: git
In-Reply-To: <494292C5-EBD9-487B-8846-9D9DD23ACB83@quendi.de>
On 3/8/13, Max Horn <max@quendi.de> wrote:
> All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with
> journaling, not case sensitive (the default)) might be at fault. Still, this
> is quite puzzling and annoying, and so I still wonder if anybody has any
> insights on this.
When "rebase" errors out at COMMIT A, try manually running "git apply"
on the patch file (rebase-apply/patch) a couple times, and see if the
error occurs randomly. You'd have to do a "reset --hard" to revert the
changes done by "git apply" every time before you run it again. The
error from "git apply" might shed more light on the issue.
^ permalink raw reply
* Re: [PATCH] git svn: consistent spacing after "W:" in warnings
From: Junio C Hamano @ 2013-03-08 16:06 UTC (permalink / raw)
To: Eric Wong
Cc: git, 'Matthieu Moy', 'Sam Vilain', Jan Pešta
In-Reply-To: <20130308100152.GA32643@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Eric Wong <normalperson@yhbt.net> wrote:
>> will push another change for formatting existing warnings more
>> consistently.
>
> Just pushed. My master is sitting at git://git.bogomips.org/git-svn.git
> commit eae6cf5aa8ae2d8a90a99bbe4aeb01c29e01fd02
Thanks.
>
> Eric Wong (1):
> git svn: consistent spacing after "W:" in warnings
>
> Jan Pešta (1):
> git svn: ignore partial svn:mergeinfo
>
> I don't have further updates planned, maybe others do.
> ----------------------------8<------------------------------
> From eae6cf5aa8ae2d8a90a99bbe4aeb01c29e01fd02 Mon Sep 17 00:00:00 2001
> From: Eric Wong <normalperson@yhbt.net>
> Date: Fri, 8 Mar 2013 09:46:41 +0000
> Subject: [PATCH] git svn: consistent spacing after "W:" in warnings
>
> All other instances of "W:"-prefixed warning messages have a space after
> the "W:" to help with readability.
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> ---
> perl/Git/SVN.pm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
> index 46aeb85..5273ee8 100644
> --- a/perl/Git/SVN.pm
> +++ b/perl/Git/SVN.pm
> @@ -1504,7 +1504,7 @@ sub lookup_svn_merge {
> my $top_commit = $gs->find_rev_before( $top, 1, $bottom );
>
> unless ($top_commit and $bottom_commit) {
> - warn "W:unknown path/rev in svn:mergeinfo "
> + warn "W: unknown path/rev in svn:mergeinfo "
> ."dirprop: $source:$range\n";
> next;
> }
^ permalink raw reply
* Re: Questions/investigations on git-subtree and tags
From: Jeremy Rosen @ 2013-03-08 16:29 UTC (permalink / raw)
To: Paul Campbell; +Cc: git
In-Reply-To: <1027208424.206728.1362672550530.JavaMail.root@openwide.fr>
[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]
ok, attached is a patch on top of your patch that solves my particular
problem
I am not "formally submitting it" since its on top of your part and i'd
really like your input before submitting.
It solves my problem and afaict does what your fix did and what git-subtree
originally intended to do...
tell me what you think
Cordialement
Jérémy Rosen
fight key loggers : write some perl using vim
----- Mail original -----
> >
> > I think I tried adding the ^{} syntax, but I don't think it works
> > on
> > remote repos. Or I couldn't get the right syntax.
> >
>
> indeed, it doesn't work on fetch, but it could be used somewhere
> between the fetch and the commit-tree to move from the ref to the
> associated commit
>
>
>
>
> >
> > Latest patch:
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/217257
> >
>
> oh, that patch, yes I found it while looking around it is a step in
> the right direction but it doesn't help in my case since i'm using a
> valid remote ref that can be fetched
>
> (on a side note you could use git ls-remote to check for the remote
> ref and avoid a fetch in case of an incorrect ref, but that's just a
> detail)
>
>
>
> I just tested with it and here is what happens
>
> git subtree add --squash -P br2 git://git.buildroot.net/buildroot
> 2013.02 => works ok, br2 is created
>
> however the message of the squash commit is
>
>
> Squashed 'br2/' content from commit f1d2c19
>
> git-subtree-dir: br2
> git-subtree-split: f1d2c19091e1c2ef803ec3267fe71cf6ce7dd948
>
>
> which is not correct :
>
> git ls-remote git://git.buildroot.net/buildroot 2013.02
> f1d2c19091e1c2ef803ec3267fe71cf6ce7dd948 refs/tags/2013.02
>
> git ls-remote git://git.buildroot.net/buildroot 2013.02^{}
> 15ace1a845c9e7fc65b648bbaf4dd14e03d938fd refs/tags/2013.02^{}
>
>
> as you can see git subtee thinks it splited from the tag SHA instead
> of the tag's commit SHA
>
> this is incorrect because the tag isn't here, and at split time git
> subtree won't be able to find the correct ancestor. We just need to
> make sure we use the tag's commit instead
> of the tag
>
>
>
> changing
> revs=FETCH_HEAD
> to
> revs=FETCH_HEAD^{}
> in cmd_add_repository
>
> seems to fix it, both for remote branch pull and remote tag pull
>
>
> we still have a bug lurking around it's the case where the user does
> the fetch himself then use subtree add with a tag SHA. but let's
> discuss problems one at a time :)
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gst.diff --]
[-- Type: text/x-patch; name=gst.diff, Size: 479 bytes --]
506,513c506,507
< case "$2" in
< *\**) # Avoid pulling in multiple branches
< die "'$2' contains a wildcard"
< ;;
< *:*) # Don't create a local branch for the subtree
< die "'$2' contains a local branch name"
< ;;
< esac
---
> git ls-remote --exit-code $1 $2 ||
> die "'$2' is not a correct reference on '$1'"
535c529
< revs=$(git rev-parse $default --revs-only "$@") || exit $?
---
> revs=$(git rev-parse $default --revs-only "$1^{commit}") || exit $?
^ permalink raw reply
* Re: question re tags
From: Carlos Martín Nieto @ 2013-03-08 16:30 UTC (permalink / raw)
To: John Stean; +Cc: git
In-Reply-To: <25720629.116.1362755762863.JavaMail.User@LANE15-HP>
On Fri, 2013-03-08 at 15:16 +0000, John Stean wrote:
> Ive been tagging some commits using tortoise git , for example with
> "v1.0", "v1.1" etc. In tortoise git log the tag sits alongside the
> commit as I expect.
> But when I do a git describe it outputs the first tag along with the
> latest commit. What am I doing wrong?
Those tags are probably lightweight tags, so by default git-describe
doesn't take them into account. You can pass the --tags flag to tell it
to consider lightweight tags as well.
cmn
^ permalink raw reply
* Re: Questions/investigations on git-subtree and tags
From: Junio C Hamano @ 2013-03-08 17:23 UTC (permalink / raw)
To: Jeremy Rosen; +Cc: Paul Campbell, git
In-Reply-To: <349468457.245193.1362760197563.JavaMail.root@openwide.fr>
Jeremy Rosen <jeremy.rosen@openwide.fr> writes:
> 506,513c506,507
> < case "$2" in
> < *\**) # Avoid pulling in multiple branches
> < die "'$2' contains a wildcard"
> < ;;
> < *:*) # Don't create a local branch for the subtree
> < die "'$2' contains a local branch name"
> < ;;
> < esac
> ---
>> git ls-remote --exit-code $1 $2 ||
You would need to quote $1 and $2 properly to prevent the shell from
splitting them into words, no?
>> die "'$2' is not a correct reference on '$1'"
> 535c529
> < revs=$(git rev-parse $default --revs-only "$@") || exit $?
> ---
>> revs=$(git rev-parse $default --revs-only "$1^{commit}") || exit $?
Is it guaranteed that your $# is 1 at this point, or is it something
you would also need to check here, or perhaps in the caller of this
function (I cannot tell offhand in a patch without any context)?
^ permalink raw reply
* Re: Questions/investigations on git-subtree and tags
From: Jeremy Rosen @ 2013-03-08 17:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Campbell, git
In-Reply-To: <7vboathkla.fsf@alter.siamese.dyndns.org>
----- Mail original -----
> Jeremy Rosen <jeremy.rosen@openwide.fr> writes:
>
> > 506,513c506,507
> > < case "$2" in
> > < *\**) # Avoid pulling in multiple branches
> > < die "'$2' contains a wildcard"
> > < ;;
> > < *:*) # Don't create a local branch for the subtree
> > < die "'$2' contains a local branch name"
> > < ;;
> > < esac
> > ---
> >> git ls-remote --exit-code $1 $2 ||
>
> You would need to quote $1 and $2 properly to prevent the shell from
> splitting them into words, no?
>
yes... I'm not very good at shell programming, good catch
> >> die "'$2' is not a correct reference on '$1'"
>
> > 535c529
> > < revs=$(git rev-parse $default --revs-only "$@") || exit $?
> > ---
> >> revs=$(git rev-parse $default --revs-only "$1^{commit}") || exit
> >> $?
>
> Is it guaranteed that your $# is 1 at this point, or is it something
> you would also need to check here, or perhaps in the caller of this
> function (I cannot tell offhand in a patch without any context)?
>
I have checked the call sites and yes we can only have one arguement at
this point. so the $@ to $1 is more about future-proofing and readability
thx for proofreading
^ permalink raw reply
* Re: rebase: strange failures to apply patc 3-way
From: Max Horn @ 2013-03-08 17:35 UTC (permalink / raw)
To: Andrew Wong; +Cc: git@vger.kernel.org
In-Reply-To: <CADeaMWp_R0HLwEYn7O3oX4-0OoSeqLfzz_2AYXT-Po88nM4HkQ@mail.gmail.com>
Am 08.03.2013 um 16:32 schrieb Andrew Wong <andrew.kw.w@gmail.com>:
> On 3/8/13, Max Horn <max@quendi.de> wrote:
>> All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with
>> journaling, not case sensitive (the default)) might be at fault. Still, this
>> is quite puzzling and annoying, and so I still wonder if anybody has any
>> insights on this.
>
> When "rebase" errors out at COMMIT A, try manually running "git apply"
> on the patch file (rebase-apply/patch) a couple times, and see if the
> error occurs randomly. You'd have to do a "reset --hard" to revert the
> changes done by "git apply" every time before you run it again. The
> error from "git apply" might shed more light on the issue.
I tried this a dozen times, but 'git apply' failed to fail even once. No surprise there, given that the patch that throws off rebase every time is clean and simple. I am flabbergasted :-(
^ permalink raw reply
* Re: [ANNOUNCE] Git v1.8.2-rc3
From: Junio C Hamano @ 2013-03-08 17:39 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqtxommbxo.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> A few suggestions on the release notes (you may safely ignore)
They both look very sensible, at least to me. Perhaps like this?
Thanks.
Documentation/RelNotes/1.8.2.txt | 60 +++++++++++++++++++++++-----------------
1 file changed, 34 insertions(+), 26 deletions(-)
diff --git a/Documentation/RelNotes/1.8.2.txt b/Documentation/RelNotes/1.8.2.txt
index 78c6577..fc606ae 100644
--- a/Documentation/RelNotes/1.8.2.txt
+++ b/Documentation/RelNotes/1.8.2.txt
@@ -1,19 +1,8 @@
Git v1.8.2 Release Notes
========================
-Backward compatibility notes
-----------------------------
-
-In the next major release Git 2.0 (not *this* one), we will change the
-behavior of the "git push" command.
-
-When "git push [$there]" does not say what to push, we have used the
-traditional "matching" semantics so far (all your branches were sent
-to the remote as long as there already are branches of the same name
-over there). We will use the "simple" semantics that pushes the
-current branch to the branch with the same name, only when the current
-branch is set to integrate with that remote branch. There is a user
-preference configuration variable "push.default" to change this.
+Backward compatibility notes (this release)
+-------------------------------------------
"git push $there tag v1.2.3" used to allow replacing a tag v1.2.3
that already exists in the repository $there, if the rewritten tag
@@ -22,22 +11,41 @@ that the old tag v1.2.3 points at. This was found to be error prone
and starting with this release, any attempt to update an existing
ref under refs/tags/ hierarchy will fail, without "--force".
-When "git add -u" and "git add -A", that does not specify what paths
-to add on the command line, is run from inside a subdirectory, the
+When "git add -u" and "git add -A" that does not specify what paths
+to add on the command line is run from inside a subdirectory, the
scope of the operation has always been limited to the subdirectory.
Many users found this counter-intuitive, given that "git commit -a"
and other commands operate on the entire tree regardless of where you
-are. In this release, these commands give warning in such a case and
-encourage the user to say "git add -u/-A ." instead when restricting
-the scope to the current directory.
-
-At Git 2.0 (not *this* one), we plan to change these commands without
-pathspec to operate on the entire tree. Forming a habit to type "."
-when you mean to limit the command to the current working directory
-will protect you against the planned future change, and that is the
-whole point of the new message (there will be no configuration
-variable to squelch this warning---it goes against the "habit forming"
-objective).
+are. In this release, these commands give a warning message that
+suggests the users to use "git add -u/-A ." when they want to limit
+the scope to the current directory; doing so will squelch the message,
+while training their fingers.
+
+
+Backward compatibility notes (for Git 2.0)
+------------------------------------------
+
+When "git push [$there]" does not say what to push, we have used the
+traditional "matching" semantics so far (all your branches were sent
+to the remote as long as there already are branches of the same name
+over there). In Git 2.0, the default will change to the "simple"
+semantics that pushes the current branch to the branch with the same
+name, only when the current branch is set to integrate with that
+remote branch. There is a user preference configuration variable
+"push.default" to change this. If you are an old-timer who is used
+to the "matching" semantics, you can set it to "matching" to keep the
+traditional behaviour. If you want to live in the future early,
+you can set it to "simple" today without waiting for Git 2.0.
+
+When "git add -u" and "git add -A", that does not specify what paths
+to add on the command line is run from inside a subdirectory, these
+commands will operate on the entire tree in Git 2.0 for consistency
+with "git commit -a" and other commands. Because there will be no
+mechanism to make "git add -u" behave as if "git add -u .", it is
+important for those who are used to "git add -u" (without pathspec)
+updating the index only for paths in the current subdirectory to start
+training their fingers to explicitly say "git add -u ." when they mean
+it before Git 2.0 comes.
Updates since v1.8.1
^ permalink raw reply related
* Re: [ANNOUNCE] Git v1.8.2-rc3
From: Matthieu Moy @ 2013-03-08 17:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7glhhjub.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> A few suggestions on the release notes (you may safely ignore)
>
> They both look very sensible, at least to me. Perhaps like this?
Looks good, yes.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] git-push.txt: mention about remote.*.push when no refspec is given
From: Junio C Hamano @ 2013-03-08 17:59 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <CACsJy8BNpMN3-Y1eZrJXpZp3-KU=kDN_4eM=87OD9d7yYYrHCg@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Thu, Mar 7, 2013 at 1:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> I agree that saying what it is, what it does or what it is for
>> upfront (i.e. "Specifies what are pushed") before how it is spelled
>> is an improvement. I however think describing "If not specified"
>> here was a mistake, and you are making it worse by burying the
>> description of what happens when <refspec>... are missing in the
>> middle of the description for <refspec>...
>>
>> I would rather see this done in the direction the attached "how
>> about doing it this way" patch illustrates. The way how "where" and
>> "what" are determined when the command line does not specify is the
>> proparty of the entire command, not of an individual parameter.
>
> I agree your patch looks better than mine. Put it on 'pu', perhaps?
Heh, that's not my itch ;-)
-- >8 --
Subject: [PATCH] Documentation/git-push: clarify the description of defaults
We describe what gets pushed by default when the command line does
not give any <refspec> under the bullet point of <refspec>.
It is a bit unfriendly to expect users to read on <refspec> when
they are not giving any in the first place. "What gets pushed" is
determined by taking many factors (<refspec> argument being only one
of them) into account, and is a property of the entire command, not
an individual argument. Also we do not describe "Where the push
goes" when the command line does not say.
Give the description on "what gets pushed to where" upfront before
explaining individual arguments and options.
Also update the description of <refspec> to say what it is, what it
is used for, before explaining what shape it takes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-push.txt | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 8b637d3..3b41e72 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -23,6 +23,17 @@ You can make interesting things happen to a repository
every time you push into it, by setting up 'hooks' there. See
documentation for linkgit:git-receive-pack[1].
+When the command line does not specify where to push with the
+`<repository>` argument, `branch.*.remote` configuration for the
+current branch is consulted to determine where to push. If the
+configuration is missing, it defaults to 'origin'.
+
+When the command line does not specify what to push with `<refspec>...`
+arguments or `--all`, `--mirror`, `--tags` options, the command finds
+the default `<refspec>` by consulting `remote.*.push` configuration,
+and if it is not found, honors `push.default` configuration to decide
+what to push (See gitlink:git-config[1] for the meaning of `push.default`).
+
OPTIONS[[OPTIONS]]
------------------
@@ -33,13 +44,10 @@ OPTIONS[[OPTIONS]]
of a remote (see the section <<REMOTES,REMOTES>> below).
<refspec>...::
+ Specify what destination ref to update with what source object.
The format of a <refspec> parameter is an optional plus
- `+`, followed by the source ref <src>, followed
+ `+`, followed by the source object <src>, followed
by a colon `:`, followed by the destination ref <dst>.
- It is used to specify with what <src> object the <dst> ref
- in the remote repository is to be updated. If not specified,
- the behavior of the command is controlled by the `push.default`
- configuration variable.
+
The <src> is often the name of the branch you would want to push, but
it can be any arbitrary "SHA-1 expression", such as `master~4` or
@@ -65,10 +73,7 @@ the remote repository.
The special refspec `:` (or `+:` to allow non-fast-forward updates)
directs git to push "matching" branches: for every branch that exists on
the local side, the remote side is updated if a branch of the same name
-already exists on the remote side. This is the default operation mode
-if no explicit refspec is found (that is neither on the command line
-nor in any Push line of the corresponding remotes file---see below) and
-no `push.default` configuration variable is set.
+already exists on the remote side.
--all::
Instead of naming each ref to push, specifies that all
--
1.8.2-rc3-243-g6506aa2
^ permalink raw reply related
* [PATCH v2] bundle: Add colons to list headings in "verify"
From: Lukas Fleischer @ 2013-03-08 18:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin, Lukas Fleischer
In-Reply-To: <1362617796-4120-1-git-send-email-git@cryptocrack.de>
These slightly improve the reading flow by making it obvious that a list
follows.
Also, make the wording of both headings consistent by changing "contains
%d ref(s)" to "contains this ref"/"contains these %d refs".
Signed-off-by: Lukas Fleischer <git@cryptocrack.de>
---
bundle.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/bundle.c b/bundle.c
index 65db53b..6210a6b 100644
--- a/bundle.c
+++ b/bundle.c
@@ -183,8 +183,8 @@ int verify_bundle(struct bundle_header *header, int verbose)
struct ref_list *r;
r = &header->references;
- printf_ln(Q_("The bundle contains %d ref",
- "The bundle contains %d refs",
+ printf_ln(Q_("The bundle contains this ref:",
+ "The bundle contains these %d refs:",
r->nr),
r->nr);
list_refs(r, 0, NULL);
@@ -192,8 +192,8 @@ int verify_bundle(struct bundle_header *header, int verbose)
if (!r->nr) {
printf_ln(_("The bundle records a complete history."));
} else {
- printf_ln(Q_("The bundle requires this ref",
- "The bundle requires these %d refs",
+ printf_ln(Q_("The bundle requires this ref:",
+ "The bundle requires these %d refs:",
r->nr),
r->nr);
list_refs(r, 0, NULL);
--
1.8.2.rc2.352.g908df73
^ permalink raw reply related
* Re: rebase: strange failures to apply patc 3-way
From: Andrew Wong @ 2013-03-08 18:02 UTC (permalink / raw)
To: Max Horn; +Cc: git@vger.kernel.org
In-Reply-To: <205D17C4-F737-46E9-BC48-D16D5948C707@quendi.de>
On 3/8/13, Max Horn <max@quendi.de> wrote:
> I tried this a dozen times, but 'git apply' failed to fail even once. No
> surprise there, given that the patch that throws off rebase every time is
> clean and simple. I am flabbergasted :-(
Hm, what if you add in the "--index" flag? i.e.
git apply --index .git/rebase-apply/patch
Wonder if that makes any difference...
^ permalink raw reply
* Re: rebase: strange failures to apply patc 3-way
From: Max Horn @ 2013-03-08 18:47 UTC (permalink / raw)
To: Andrew Wong; +Cc: git@vger.kernel.org
In-Reply-To: <CADgNjan9v++__TSPE55j7+=BBZrVEkMD52O+9kXAm-C8SRV+Ww@mail.gmail.com>
Am 08.03.2013 um 19:02 schrieb Andrew Wong <andrew.kw.w@gmail.com>:
> On 3/8/13, Max Horn <max@quendi.de> wrote:
>> I tried this a dozen times, but 'git apply' failed to fail even once. No
>> surprise there, given that the patch that throws off rebase every time is
>> clean and simple. I am flabbergasted :-(
>
> Hm, what if you add in the "--index" flag? i.e.
> git apply --index .git/rebase-apply/patch
>
> Wonder if that makes any difference...
Same result, it works fine.
^ permalink raw reply
* Re: rebase: strange failures to apply patc 3-way
From: Andrew Wong @ 2013-03-08 19:20 UTC (permalink / raw)
To: Max Horn; +Cc: git@vger.kernel.org
In-Reply-To: <B21B6CEC-7507-47A1-9BBB-FB95EA6B831F@quendi.de>
On 3/8/13, Max Horn <max@quendi.de> wrote:
> Same result, it works fine.
Just shooting in the dark here... I wonder if there's some background
process running in OS X that's messing with the files/directories
while rebase is working... backup, virus scan, etc? Or maybe some
programs that you're using at the same time? Maybe also make sure you
don't have any programs (shells, editors, etc.) opened that's
accessing those files/directories?
Does the error always happen at COMMIT A and COMMIT B? Or is it all
over the place?
In cases where COMMIT A succeeded, did it say it did a 3-way merge? Or
was it exactly as the output in your original message? i.e. no message
at all
^ permalink raw reply
* Re: [feature request] 2) Remove many tags at once and 1) Prune tags on old-branch-before-rebase
From: Eric Chamberland @ 2013-03-08 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <7v38w6lr8n.fsf@alter.siamese.dyndns.org>
Hi Junio,
On 03/07/2013 06:33 PM, Junio C Hamano wrote:
> Eric Chamberland <Eric.Chamberland@giref.ulaval.ca> writes:
>
> What you want is a way to compute, given a set of tags (or refs in
> general) and a set of branches (or another set of refs in general),
> find the ones in the former that none of the latter can reach. With
> that, you can drive "git tag -d $(that way)".
>
Yes, this is *exactly* what I want...
> In other words, the feature does not belong to "git tag" command.
>
>> 2) git tag -d "TOKEN*"
>
> Again, not interesting. You already have:
>
> git for-each-ref --format='%(refname:short)' refs/tags/TOKEN\* |
> xargs -r git tag -d
>
I don't agree here for one reason:
git tag -l "TOKEN*"
already exists and works very well...
So why is it not interesting to have:
git tag -d "TOKEN*"
?
We can also write:
git tag -d `git tag -l "TOKEN*"`
but a simple addition to "-d" feature looks like a receivable behavior
here, no?
Thanks,
Eric
^ permalink raw reply
* Re: Adding "--ignore-submodules" switch to git-describe
From: Francis Moreau @ 2013-03-08 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann
In-Reply-To: <7v621bggi5.fsf@alter.siamese.dyndns.org>
Hi,
Sorry for the long delay, I somehow missed your answer...
On Fri, Mar 1, 2013 at 6:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Francis Moreau <francis.moro@gmail.com> writes:
>
>> Would it make sense to add the option --ignore-submodules (currently
>> available in git-status) to git-describe when the later is used with
>> --dirty option ?
>
> I think the spirit of "describe --dirty" is to allow people who
> gives out binaries this assurance:
>
> The version string I got out of "describe --dirty" does not
> say dirty. If the recipient of the binary later reports
> issues, I should be able to reproduce the same binary by
> starting from a pristine checkout of the version (provided
> if I didn't screw up and depended on an untracked file when
> I initially created the binary, or used a custom build
> option, or lost the toolchain, ..., of course).
>
> With that in mind, does --ignore-submodules make sense?
Well, I wouldn't have thought about this definition of "describe
--dirty". I would have thought that, by default, this command look
only at the files that git knows/tracks. There're too many external
(to the git repo) parameters that could influence the build of a
project: environment variables, components of the toolchain, version
of each components etc... that git doesn't know about.
[...]
>
> But when we ignore untracked paths in the superproject, we should
> ignore untracked paths in submodule working trees consistently.
>
>
yes I agree.
But in the short term, could you suggest a method to workaround this
inconsistency ?
Thanks.
--
Francis
^ permalink raw reply
* Re: Adding "--ignore-submodules" switch to git-describe
From: Junio C Hamano @ 2013-03-08 21:26 UTC (permalink / raw)
To: Francis Moreau; +Cc: git, Jens Lehmann
In-Reply-To: <CAC9WiBhHmqn7QZMLFcLjqGPamHmbMFNxvQ6Yzv5dr=+fe+F3_g@mail.gmail.com>
Francis Moreau <francis.moro@gmail.com> writes:
>> But when we ignore untracked paths in the superproject, we should
>> ignore untracked paths in submodule working trees consistently.
>
> yes I agree.
>
> But in the short term, could you suggest a method to workaround this
> inconsistency ?
Hrm, ... didn't I already?
As we do not take untracked content at the superproject level into
account when deciding "--dirty"-ness, I think it is very sensible to
either do one of the following:
(1) always ignore untracked files in submodule working trees; or
(2) if we were to introduce some form of --ignore-submodules,
ignore untracked files in the superproject working tree when we
use that mechanism to ignore untracked files in submodule
working trees.
Strictly speaking, (1) is a degenerate case of (2).
...
I think what is missing from "--dirty" is not "--ignore-submodules",
but "--do-not-ignore-untracked" option [*1*]. "describe --dirty"
ignores untracked files in the superproject by default, and we
should ignore untracked files in submodule working trees, but the
current code does not. Fixing that is (1) above.
I think the right first step without any new option is to make
"describe --dirty" to ignore the dirtiness in submodules coming
solely from having untracked files in submodules' working trees.
You could later add --having-untracked-is-dirty option to mark the
output dirty when there is an untracked file in submodules' working
trees or the toplevel working tree, which would be the second step.
^ permalink raw reply
* Re: Memory corruption when rebasing with git version 1.8.1.5 on arch
From: Jeff King @ 2013-03-08 21:28 UTC (permalink / raw)
To: Bernhard Posselt; +Cc: git
In-Reply-To: <5139D76D.80703@bernhard-posselt.com>
On Fri, Mar 08, 2013 at 01:19:57PM +0100, Bernhard Posselt wrote:
> Using valgrind gives me:
>
> $ valgrind /usr/bin/git pull --rebasehttps://github.com/PatrickHeller/core.git master
> ==5995== Memcheck, a memory error detector
> ==5995== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==5995== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==5995== Command: /usr/bin/git pull --rebasehttps://github.com/PatrickHeller/core.git master
> ==5995==
> remote: Counting objects: 5, done.
> remote: Compressing objects: 100% (1/1), done.
> remote: Total 3 (delta 2), reused 3 (delta 2)
> Unpacking objects: 100% (3/3), done.
> Fromhttps://github.com/PatrickHeller/core
> * branch master -> FETCH_HEAD
> First, rewinding head to replay your work on top of it...
> Applying: distinguish between touch and write
> Applying: remove debug output
> *** Error in `git': malloc(): memory corruption: 0x00000000027f14e0 ***
The problem is likely happening in a sub-command of git-pull, so
valgrind isn't reporting it. Can you try re-running with
"valgrind --trace-children=yes", or alternatively narrow down the
problematic command by setting GIT_TRACE=1 in the environment?
-Peff
^ permalink raw reply
* Re: [PATCH v2 2/3] environment: add GIT_PREFIX to local_repo_env
From: Eric Sunshine @ 2013-03-08 21:39 UTC (permalink / raw)
To: Jeff King; +Cc: git, Johannes Sixt, Junio C Hamano, Mark Lodato
In-Reply-To: <20130308093025.GB1923@sigill.intra.peff.net>
On Fri, Mar 8, 2013 at 4:30 AM, Jeff King <peff@peff.net> wrote:
> The GIT_PREFIX variable is set based on our location within
> the working tree. It should therefore be cleared whenever
> GIT_WORK_TREE is cleared.
>
> In practice, this doesn't cause any bugs, because none of
> the sub-programs we invoke with local_repo_env cleared
> actually care about GIT_PREFIX. But this is the right thing
> to do, and future proofs us again that assumption changing.
s/again/against/
-- ES
^ permalink raw reply
* Re: [PATCH v2 2/3] environment: add GIT_PREFIX to local_repo_env
From: Jeff King @ 2013-03-08 21:44 UTC (permalink / raw)
To: Eric Sunshine; +Cc: git, Johannes Sixt, Junio C Hamano, Mark Lodato
In-Reply-To: <CAPig+cRUCnWJLeuXL=LLk7kUkwPnHqaL_KGcSdq3yO+YZ345tQ@mail.gmail.com>
On Fri, Mar 08, 2013 at 04:39:02PM -0500, Eric Sunshine wrote:
> On Fri, Mar 8, 2013 at 4:30 AM, Jeff King <peff@peff.net> wrote:
> > The GIT_PREFIX variable is set based on our location within
> > the working tree. It should therefore be cleared whenever
> > GIT_WORK_TREE is cleared.
> >
> > In practice, this doesn't cause any bugs, because none of
> > the sub-programs we invoke with local_repo_env cleared
> > actually care about GIT_PREFIX. But this is the right thing
> > to do, and future proofs us again that assumption changing.
>
> s/again/against/
Yep, thanks.
-Peff
^ permalink raw reply
* Re: [PATCH v2 3/4] status: show more info than "currently not on any branch"
From: Junio C Hamano @ 2013-03-08 21:46 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Matthieu Moy, Jonathan Niedier
In-Reply-To: <CACsJy8CnDoMRzR5ifH3+0AKRLfzrNpkc3-NOxoA85SiRUb40ng@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
>> It should be more like this, I would think:
>>
>> for_each_recent_reflog_ent();
>> if (!found)
>> for_each_reflog_ent();
>> if (!found)
>> return;
>
> Yes. This "recent" optimization is tricky.
Not really. What is tricky is that reflog is an append-only file
and we only have an API to let us read it in the oldest to newer
order, which is natural for the file format, but unsuited for the
purpose of finding out nth most recent anything.
See the other thread I am going to send out soon on this.
^ permalink raw reply
* [PATCH 0/3] Enumerating reflog entries in a wrong order
From: Junio C Hamano @ 2013-03-08 21:53 UTC (permalink / raw)
To: git
The for_each_reflog_ent() function yields reflog entries from the
oldest to newer, and is inefficient when we know what we are looking
for are near the newest end (e.g. "find the nth newest reflog entry
that matches 'checkout: moving from X to Y'"). To optimize for the
common case, we introduced for_each_recent_reflog_ent() to scan only
the newest part (i.e. tail) of the reflog file, but it is difficult
to use this function correctly.
Just bite the bullet and stop working around the API that reads the
file in a wrong order. The new for_each_reflog_ent_reverse()
function gives us reflog entries from the newest to older.
Junio C Hamano (3):
for_each_reflog_ent(): extract a helper to process a single entry
for_each_recent_reflog_ent(): simplify opening of a reflog file
reflog: add for_each_reflog_ent_reverse() API
refs.c | 161 +++++++++++++++++++++++++++++++++++++++++++-----------------
refs.h | 2 +-
sha1_name.c | 48 +++++++-----------
3 files changed, 134 insertions(+), 77 deletions(-)
--
1.8.2-rc3-189-g94c4d42
^ permalink raw reply
* [PATCH 1/3] for_each_reflog_ent(): extract a helper to process a single entry
From: Junio C Hamano @ 2013-03-08 21:53 UTC (permalink / raw)
To: git
In-Reply-To: <1362779624-15513-1-git-send-email-gitster@pobox.com>
Split the logic that takes a single line of reflog entry in a strbuf
parses it and calls the callback function out of the loop into a
separate helper function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
refs.c | 59 ++++++++++++++++++++++++++++++-----------------------------
1 file changed, 30 insertions(+), 29 deletions(-)
diff --git a/refs.c b/refs.c
index da74a2b..9f702a7 100644
--- a/refs.c
+++ b/refs.c
@@ -2290,6 +2290,34 @@ int read_ref_at(const char *refname, unsigned long at_time, int cnt,
return 1;
}
+static int show_one_reflog_ent(struct strbuf *sb, each_reflog_ent_fn fn, void *cb_data)
+{
+ unsigned char osha1[20], nsha1[20];
+ char *email_end, *message;
+ unsigned long timestamp;
+ int tz;
+
+ /* old SP new SP name <email> SP time TAB msg LF */
+ if (sb->len < 83 || sb->buf[sb->len - 1] != '\n' ||
+ get_sha1_hex(sb->buf, osha1) || sb->buf[40] != ' ' ||
+ get_sha1_hex(sb->buf + 41, nsha1) || sb->buf[81] != ' ' ||
+ !(email_end = strchr(sb->buf + 82, '>')) ||
+ email_end[1] != ' ' ||
+ !(timestamp = strtoul(email_end + 2, &message, 10)) ||
+ !message || message[0] != ' ' ||
+ (message[1] != '+' && message[1] != '-') ||
+ !isdigit(message[2]) || !isdigit(message[3]) ||
+ !isdigit(message[4]) || !isdigit(message[5]))
+ return 0; /* corrupt? */
+ email_end[1] = '\0';
+ tz = strtol(message + 1, NULL, 10);
+ if (message[6] != '\t')
+ message += 6;
+ else
+ message += 7;
+ return fn(osha1, nsha1, sb->buf + 82, timestamp, tz, message, cb_data);
+}
+
int for_each_recent_reflog_ent(const char *refname, each_reflog_ent_fn fn, long ofs, void *cb_data)
{
const char *logfile;
@@ -2314,35 +2342,8 @@ int for_each_recent_reflog_ent(const char *refname, each_reflog_ent_fn fn, long
}
}
- while (!strbuf_getwholeline(&sb, logfp, '\n')) {
- unsigned char osha1[20], nsha1[20];
- char *email_end, *message;
- unsigned long timestamp;
- int tz;
-
- /* old SP new SP name <email> SP time TAB msg LF */
- if (sb.len < 83 || sb.buf[sb.len - 1] != '\n' ||
- get_sha1_hex(sb.buf, osha1) || sb.buf[40] != ' ' ||
- get_sha1_hex(sb.buf + 41, nsha1) || sb.buf[81] != ' ' ||
- !(email_end = strchr(sb.buf + 82, '>')) ||
- email_end[1] != ' ' ||
- !(timestamp = strtoul(email_end + 2, &message, 10)) ||
- !message || message[0] != ' ' ||
- (message[1] != '+' && message[1] != '-') ||
- !isdigit(message[2]) || !isdigit(message[3]) ||
- !isdigit(message[4]) || !isdigit(message[5]))
- continue; /* corrupt? */
- email_end[1] = '\0';
- tz = strtol(message + 1, NULL, 10);
- if (message[6] != '\t')
- message += 6;
- else
- message += 7;
- ret = fn(osha1, nsha1, sb.buf + 82, timestamp, tz, message,
- cb_data);
- if (ret)
- break;
- }
+ while (!ret && !strbuf_getwholeline(&sb, logfp, '\n'))
+ ret = show_one_reflog_ent(&sb, fn, cb_data);
fclose(logfp);
strbuf_release(&sb);
return ret;
--
1.8.2-rc3-189-g94c4d42
^ permalink raw reply related
* [PATCH 3/3] reflog: add for_each_reflog_ent_reverse() API
From: Junio C Hamano @ 2013-03-08 21:53 UTC (permalink / raw)
To: git
In-Reply-To: <1362779624-15513-1-git-send-email-gitster@pobox.com>
"git checkout -" is a short-hand for "git checkout @{-1}" and the
"@{nth}" notation for a negative number is to find nth previous
checkout in the reflog of the HEAD to determine the name of the
branch the user was on. We would want to find the nth most recent
reflog entry that matches "checkout: moving from X to Y" for this.
Unfortunately, reflog is implemented as an append-only file, and the
API to iterate over its entries, for_each_reflog_ent(), reads the
file in order, giving the entries from oldest to newer. For the
purpose of finding nth most recent one, this API makes us to record
the last n entries in a rotating buffer and give the result out only
after we read everything. To optimize for a common case of finding
the nth most recent one for a small value of n, we also have a side
API for_each_recent_reflog_ent() that starts reading near the end of
the file, but it still reads the entries in the "wrong" order. The
implementation of understanding @{-1} uses this interface.
This all becomes unnecessary if we had an API to let us iterate over
reflog entries in the reverse order, from the newest to older.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
refs.c | 102 ++++++++++++++++++++++++++++++++++++++++++++++++++----------
refs.h | 2 +-
sha1_name.c | 48 +++++++++++-----------------
3 files changed, 105 insertions(+), 47 deletions(-)
diff --git a/refs.c b/refs.c
index e302521..8e24060 100644
--- a/refs.c
+++ b/refs.c
@@ -2318,30 +2318,89 @@ static int show_one_reflog_ent(struct strbuf *sb, each_reflog_ent_fn fn, void *c
return fn(osha1, nsha1, sb->buf + 82, timestamp, tz, message, cb_data);
}
-int for_each_recent_reflog_ent(const char *refname, each_reflog_ent_fn fn, long ofs, void *cb_data)
+static char *find_beginning_of_line(char *bob, char *scan)
+{
+ while (bob < scan && *(--scan) != '\n')
+ ; /* keep scanning backwards */
+ /*
+ * Return either beginning of the buffer, or LF at the end of
+ * the previous line.
+ */
+ return scan;
+}
+
+int for_each_reflog_ent_reverse(const char *refname, each_reflog_ent_fn fn, void *cb_data)
{
- FILE *logfp;
struct strbuf sb = STRBUF_INIT;
- int ret = 0;
+ FILE *logfp;
+ long pos;
+ int ret = 0, at_tail = 1;
logfp = fopen(git_path("logs/%s", refname), "r");
if (!logfp)
return -1;
- if (ofs) {
- struct stat statbuf;
- if (fstat(fileno(logfp), &statbuf) ||
- statbuf.st_size < ofs ||
- fseek(logfp, -ofs, SEEK_END) ||
- strbuf_getwholeline(&sb, logfp, '\n')) {
- fclose(logfp);
- strbuf_release(&sb);
- return -1;
+ /* Jump to the end */
+ if (fseek(logfp, 0, SEEK_END) < 0)
+ return error("cannot seek back reflog for %s: %s",
+ refname, strerror(errno));
+ pos = ftell(logfp);
+ while (!ret && 0 < pos) {
+ int cnt;
+ size_t nread;
+ char buf[BUFSIZ];
+ char *endp, *scanp;
+
+ /* Fill next block from the end */
+ cnt = (sizeof(buf) < pos) ? sizeof(buf) : pos;
+ if (fseek(logfp, pos - cnt, SEEK_SET))
+ return error("cannot seek back reflog for %s: %s",
+ refname, strerror(errno));
+ nread = fread(buf, cnt, 1, logfp);
+ if (nread < 0)
+ return error("cannot read %d bytes from reflog for %s: %s",
+ cnt, refname, strerror(errno));
+ pos -= cnt;
+
+ scanp = endp = buf + cnt;
+ if (at_tail && scanp[-1] == '\n')
+ /* Looking at the final LF at the end of the file */
+ scanp--;
+ at_tail = 0;
+
+ while (buf < scanp) {
+ /*
+ * terminating LF of the previous line, or the beginning
+ * of the buffer.
+ */
+ char *bp;
+
+ bp = find_beginning_of_line(buf, scanp);
+
+ if (*bp != '\n') {
+ strbuf_splice(&sb, 0, 0, buf, endp - buf);
+ if (pos)
+ break; /* need to fill another block */
+ scanp = buf - 1; /* leave loop */
+ } else {
+ /*
+ * (bp + 1) thru endp is the beginning of the
+ * current line we have in sb
+ */
+ strbuf_splice(&sb, 0, 0, bp + 1, endp - (bp + 1));
+ scanp = bp;
+ endp = bp + 1;
+ }
+ ret = show_one_reflog_ent(&sb, fn, cb_data);
+ strbuf_reset(&sb);
+ if (ret)
+ break;
}
- }
- while (!ret && !strbuf_getwholeline(&sb, logfp, '\n'))
+ }
+ if (!ret && sb.len)
ret = show_one_reflog_ent(&sb, fn, cb_data);
+
fclose(logfp);
strbuf_release(&sb);
return ret;
@@ -2349,9 +2408,20 @@ int for_each_recent_reflog_ent(const char *refname, each_reflog_ent_fn fn, long
int for_each_reflog_ent(const char *refname, each_reflog_ent_fn fn, void *cb_data)
{
- return for_each_recent_reflog_ent(refname, fn, 0, cb_data);
-}
+ FILE *logfp;
+ struct strbuf sb = STRBUF_INIT;
+ int ret = 0;
+
+ logfp = fopen(git_path("logs/%s", refname), "r");
+ if (!logfp)
+ return -1;
+ while (!ret && !strbuf_getwholeline(&sb, logfp, '\n'))
+ ret = show_one_reflog_ent(&sb, fn, cb_data);
+ fclose(logfp);
+ strbuf_release(&sb);
+ return ret;
+}
/*
* Call fn for each reflog in the namespace indicated by name. name
* must be empty or end with '/'. Name will be used as a scratch
diff --git a/refs.h b/refs.h
index d6c2fe2..a62b9db 100644
--- a/refs.h
+++ b/refs.h
@@ -103,7 +103,7 @@ extern int read_ref_at(const char *refname, unsigned long at_time, int cnt,
/* 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 *refname, each_reflog_ent_fn fn, void *cb_data);
-int for_each_recent_reflog_ent(const char *refname, each_reflog_ent_fn fn, long, void *cb_data);
+int for_each_reflog_ent_reverse(const char *refname, each_reflog_ent_fn fn, 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 95003c7..635cd13 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -856,8 +856,8 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1,
}
struct grab_nth_branch_switch_cbdata {
- long cnt, alloc;
- struct strbuf *buf;
+ int remaining;
+ struct strbuf buf;
};
static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
@@ -867,7 +867,6 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
struct grab_nth_branch_switch_cbdata *cb = cb_data;
const char *match = NULL, *target = NULL;
size_t len;
- int nth;
if (!prefixcmp(message, "checkout: moving from ")) {
match = message + strlen("checkout: moving from ");
@@ -876,11 +875,12 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
if (!match || !target)
return 0;
-
- len = target - match;
- nth = cb->cnt++ % cb->alloc;
- strbuf_reset(&cb->buf[nth]);
- strbuf_add(&cb->buf[nth], match, len);
+ if (--(cb->remaining) == 0) {
+ len = target - match;
+ strbuf_reset(&cb->buf);
+ strbuf_add(&cb->buf, match, len);
+ return 1; /* we are done */
+ }
return 0;
}
@@ -891,7 +891,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
static int interpret_nth_prior_checkout(const char *name, struct strbuf *buf)
{
long nth;
- int i, retval;
+ int retval;
struct grab_nth_branch_switch_cbdata cb;
const char *brace;
char *num_end;
@@ -901,34 +901,22 @@ static int interpret_nth_prior_checkout(const char *name, struct strbuf *buf)
brace = strchr(name, '}');
if (!brace)
return -1;
- nth = strtol(name+3, &num_end, 10);
+ nth = strtol(name + 3, &num_end, 10);
if (num_end != brace)
return -1;
if (nth <= 0)
return -1;
- cb.alloc = nth;
- cb.buf = xmalloc(nth * sizeof(struct strbuf));
- for (i = 0; i < nth; i++)
- strbuf_init(&cb.buf[i], 20);
- cb.cnt = 0;
+ cb.remaining = nth;
+ strbuf_init(&cb.buf, 20);
+
retval = 0;
- for_each_recent_reflog_ent("HEAD", grab_nth_branch_switch, 40960, &cb);
- if (cb.cnt < nth) {
- cb.cnt = 0;
- for_each_reflog_ent("HEAD", grab_nth_branch_switch, &cb);
+ if (0 < for_each_reflog_ent_reverse("HEAD", grab_nth_branch_switch, &cb)) {
+ strbuf_reset(buf);
+ strbuf_add(buf, cb.buf.buf, cb.buf.len);
+ retval = brace - name + 1;
}
- if (cb.cnt < nth)
- 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);
+ strbuf_release(&cb.buf);
return retval;
}
--
1.8.2-rc3-189-g94c4d42
^ permalink raw reply related
* [PATCH 2/3] for_each_recent_reflog_ent(): simplify opening of a reflog file
From: Junio C Hamano @ 2013-03-08 21:53 UTC (permalink / raw)
To: git
In-Reply-To: <1362779624-15513-1-git-send-email-gitster@pobox.com>
There is no reason to use a temporary variable logfile.
---
refs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index 9f702a7..e302521 100644
--- a/refs.c
+++ b/refs.c
@@ -2320,13 +2320,11 @@ static int show_one_reflog_ent(struct strbuf *sb, each_reflog_ent_fn fn, void *c
int for_each_recent_reflog_ent(const char *refname, each_reflog_ent_fn fn, long ofs, void *cb_data)
{
- const char *logfile;
FILE *logfp;
struct strbuf sb = STRBUF_INIT;
int ret = 0;
- logfile = git_path("logs/%s", refname);
- logfp = fopen(logfile, "r");
+ logfp = fopen(git_path("logs/%s", refname), "r");
if (!logfp)
return -1;
--
1.8.2-rc3-189-g94c4d42
^ permalink raw reply related
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