* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Michael J Gruber @ 2010-12-07 15:25 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <AANLkTinDyix3KEdLLGJEWQ8X+a3zQZOAiTh2mLf5wuvQ@mail.gmail.com>
Nguyen Thai Ngoc Duy venit, vidit, dixit 07.12.2010 12:37:
> On Tue, Dec 7, 2010 at 1:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>>
>>> On Tue, Dec 7, 2010 at 4:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> +#define BRANCH_DELETION_LOG "DELETED-REFS"
>>>> +
>>>
>>> Should this special log be mentioned in git-update-ref.txt or
>>> gitrepository-layout.txt?
>>
>> Perhaps, but I wasn't sure if this patch itself is a good idea to begin
>> with. Not the problem it tries to solve, but its approach.
>>
>> For example, this cannot be shown with "reflog show" or "log -g" due to
>> the way these frontends locate the reflog file to read (the logic wants to
>> have an underlying ref).
>>
>
> I think you have thought of this. What's wrong with keeping reflog
> when a branch is removed and appending "delete" line to the said
> reflog? I don't know how reflogs are managed, but those reflogs
> without associated branch will (or should) be cleaned when they are
> expired.
The problem is the following:
Say, you delete a branch and its reflog is kept (with a "delete" line
appended).
Then you create a new branch under the same name. What is supposed to
happen to the reflog? If you simply append, then old (unrelated) entries
will not expire through the imagined "expire branch reflogs" mechanism.
Now, you rename that branch. We should really split the reflog in two
now, keeping the old name for the old parts and moving only the newer
parts to the reflog with the new name.
This is all workable in principle but hints at a design flaw.
Maybe it's easier to teach "git reflog" about "DELETED_REFS"?
Michael
^ permalink raw reply
* cmd_cherry in builtin/log.c?
From: Thiago Farina @ 2010-12-07 16:02 UTC (permalink / raw)
To: Git Mailing List; +Cc: rene.scharfe
I was looking into builtin/log.c to see how it does --reverse and I
saw that cmd_cherry is there.
I'm wondering, why is it there? What was the reason to make the
decision to put it there and not in builtin/cherry.c?
^ permalink raw reply
* URGENT AND PRIVATE
From: BROWN HEYMAN @ 2010-12-07 8:55 UTC (permalink / raw)
To: giscardlesurvivant, git, glenda.webb, glen.shaw, glee,
givingandliving, gleb.mokhov, gla, gm, gleb, gloomy_beholder,
glebvitek, gjg, giperaslan_hasan, gku, gisslaved, gmcs,
gites.lafuste, glz, gnmanager, gloryaolesya, gloc, gliuchef,
gleb77-77, glasstrade, gladkov69, gk_nowo, glatcher, glinfl,
girl_friend_turkey, gis, gmail, gmproject, globatorseo,
glitterskinonline, glamdicinn, gksaratow, gl, girl, glee, glen,
gints.savejs, go, globator, gk81, gmalkin, glass, gisle, gmbh,
gmbh
Attention;
My name is Brown Heyman, formerly working with S N S Bank Netherlands Branch, presently I am working with Capital One Bank Europe Plc here in United Kingdom. I have a proposition to discuss with you about a certain bonded account in our Bank. The bonded Account has a balance of 17.3Million dollars.
It will be beneficial to all parties concerned I am contacting you on this due to you share the same Family name with the Bonded Account.
Thanks and hoping to hear from you soon.
Yours truly,
Brown Heyman
^ permalink raw reply
* Re: [RFC/PATCH 2/1] bash: eliminate dependency on bash_completion lib
From: SZEDER Gábor @ 2010-12-07 16:07 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Peter van der Does, Shawn O. Pearce, git, Marc Branchaud,
Brian Gernhardt, Kevin Ballard, Mathias Lafeldt
In-Reply-To: <20101202210207.GA4994@burratino>
Hi Jonathan,
What is this patch based on?
Thanks,
Gábor
On Thu, Dec 02, 2010 at 03:02:07PM -0600, Jonathan Nieder wrote:
> Add a minimal implementation of _get_comp_words_by_ref,
> the routine used to work around bash 4.0's COMP_WORDS semantics.
>
> Based on bash-completion 2.x (commit bf763033, 2010-10-26) but
> tweaked for simplicity and to allow zsh to at least parse the
> code.
>
> Based-on-patch-by: Peter van der Does <peter@avirtualhome.com>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> Peter van der Does wrote:
> > Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> >> 2. Import the definition of _get_comp_words_by_ref from the
> >> bash-completion lib and use it if ZSH_VERSION is unset.
> >>
> >> 3. Further refinements, if needed.
> >>
> >> What do you think?
> >
> > I like the idea and we should go with this solution.
> >
> > If by importing you mean using :
> > [CODE]. /git_bash_completion-functions[/CODE] in the
> > contrib/completion/git-completion.bash script, which would be the best
> > solution imho. The question is where to place that the function file.
> [...]
> > It would have to include copying the functions file somewhere as well.
> >
> > Or we could use the method used now and include the functions in the
> > git-completion.bash script.
>
> Sorry for the lack of clarity. Here's what I meant.
>
> contrib/completion/git-completion.bash | 125 ++++++++++++++++++++++++++++++++
> 1 files changed, 125 insertions(+), 0 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 0b0eb45..1743319 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -327,7 +327,102 @@ __gitcomp_1 ()
> done
> }
>
> +# The following function is based on code from:
> +#
> +# bash_completion - programmable completion functions for bash 3.2+
> +#
> +# Copyright © 2006-2008, Ian Macdonald <ian@caliban.org>
> +# © 2009-2010, Bash Completion Maintainers
> +# <bash-completion-devel@lists.alioth.debian.org>
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 2, or (at your option)
> +# any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write to the Free Software Foundation,
> +# Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> +#
> +# The latest version of this software can be obtained here:
> +#
> +# http://bash-completion.alioth.debian.org/
> +#
> +# RELEASE: 2.x
> +
> +# This function can be used to access a tokenized list of words
> +# on the command line:
> +#
> +# __reassemble_comp_words_by_ref '=:'
> +# if test "${words_[cword_-1]}" = -w
> +# then
> +# ...
> +# fi
> +#
> +# The argument should be a collection of characters from the list of
> +# word completion separators (COMP_WORDBREAKS) to treat as ordinary
> +# characters.
> +#
> +# This is roughly equivalent to locally setting COMP_WORDBREAKS to
> +# exclude those characters, but it does not clobber COMP_WORDBREAKS.
> +# The intent is for it to be used by commands like ssh that want to
> +# treat host:path as one token.
> +#
> +# Output: words_, cword_, cur_.
> +
> +__git_reassemble_comp_words_by_ref()
> +{
> + local exclude i j first
> + # Which word separators to exclude?
> + exclude="${1//[^$COMP_WORDBREAKS]}"
> + cword_=$COMP_CWORD
> + if [ -z "$exclude" ]; then
> + words_=("${COMP_WORDS[@]}")
> + return
> + fi
> + # List of word completion separators has shrunk;
> + # re-assemble words to complete.
> + for ((i=0, j=0; i < ${#COMP_WORDS[@]}; i++, j++)); do
> + # Append each nonempty word consisting of just
> + # word separator characters to the current word.
> + first=t
> + while
> + [ $i -gt 0 ] &&
> + [ -n "${COMP_WORDS[$i]}" ] &&
> + # word consists of excluded word separators
> + [ "${COMP_WORDS[$i]//[^$exclude]}" = "${COMP_WORDS[$i]}" ]
> + do
> + # Attach to the previous token,
> + # unless the previous token is the command name.
> + if [ $j -ge 2 ] && [ -n "$first" ]; then
> + ((j--))
> + fi
> + first=
> + words_[$j]=${words_[j]}${COMP_WORDS[i]}
> + if [ $i = $COMP_CWORD ]; then
> + cword_=$j
> + fi
> + if (($i < ${#COMP_WORDS[@]} - 1)); then
> + ((i++))
> + else
> + # Done.
> + return
> + fi
> + done
> + words_[$j]=${words_[j]}${COMP_WORDS[i]}
> + if [ $i = $COMP_CWORD ]; then
> + cword_=$j
> + fi
> + done
> +}
> +
> if ! type _get_comp_words_by_ref >/dev/null 2>&1; then
> +if [[ -n $ZSH_VERSION ]]; then
> _get_comp_words_by_ref ()
> {
> while [ $# -gt 0 ]; do
> @@ -352,6 +447,36 @@ _get_comp_words_by_ref ()
> shift
> done
> }
> +else
> +_get_comp_words_by_ref ()
> +{
> + local exclude cur_ cword_
> + local words_=()
> + if [ "$1" = "-n" ]; then
> + exclude=$2
> + shift 2
> + fi
> + __git_reassemble_comp_words_by_ref "$exclude"
> + cur_=${words_[cword_]}
> + while [ $# -gt 0 ]; do
> + case "$1" in
> + cur)
> + cur=$cur_
> + ;;
> + prev)
> + prev=${words_[$cword_-1]}
> + ;;
> + words)
> + words=("${words_[@]}")
> + ;;
> + cword)
> + cword=$cword_
> + ;;
> + esac
> + shift
> + done
> +}
> +fi
> fi
>
> # __gitcomp accepts 1, 2, 3, or 4 arguments
> --
> 1.7.2.3
>
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Jakub Narebski @ 2010-12-07 16:22 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <AANLkTinDyix3KEdLLGJEWQ8X+a3zQZOAiTh2mLf5wuvQ@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Tue, Dec 7, 2010 at 1:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>>
>>> On Tue, Dec 7, 2010 at 4:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> +#define BRANCH_DELETION_LOG "DELETED-REFS"
>>>> +
>>>
>>> Should this special log be mentioned in git-update-ref.txt or
>>> gitrepository-layout.txt?
>>
>> Perhaps, but I wasn't sure if this patch itself is a good idea to begin
>> with. Not the problem it tries to solve, but its approach.
>>
>> For example, this cannot be shown with "reflog show" or "log -g" due to
>> the way these frontends locate the reflog file to read (the logic wants to
>> have an underlying ref).
>>
>
> I think you have thought of this. What's wrong with keeping reflog
> when a branch is removed and appending "delete" line to the said
> reflog? I don't know how reflogs are managed, but those reflogs
> without associated branch will (or should) be cleaned when they are
> expired.
>
> I stick with this idea because I also want to archive old branches and
> am thinking those reflogs ending with "archive" line will be kept
> forever, or until I feel like digging up them again.
The problem with this idea is deleting branch 'foo' and creating 'foo/bar',
or deleting branch 'foo/bar' and creating branch 'foo'. Old reflog with
"delete" line would block creating reflog for new branch.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Casey Dahlin @ 2010-12-07 16:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlj42siu5.fsf@alter.siamese.dyndns.org>
On Mon, Dec 06, 2010 at 01:16:18PM -0800, Junio C Hamano wrote:
> This adds core.logrefdeletion configuration variable (enabled by default
> in a repository with a work tree, just like core.logallrefupdates), and
> logs deletion of refs via "update-ref -d", "branch -d", etc.
>
> "git branch" learns a new "--list-deleted" option to help users view the
> names of branches and the commit objects that were at the tip of them when
> the branches were deleted.
>
Could commits made onto a detached head also show up here? Or is that
better thwarted with another mechanism?
--CJD
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Nguyen Thai Ngoc Duy @ 2010-12-07 16:25 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <4CFE51FA.3060104@drmicha.warpmail.net>
On Tue, Dec 7, 2010 at 10:25 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Nguyen Thai Ngoc Duy venit, vidit, dixit 07.12.2010 12:37:
>> On Tue, Dec 7, 2010 at 1:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>>>
>>>> On Tue, Dec 7, 2010 at 4:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>> +#define BRANCH_DELETION_LOG "DELETED-REFS"
>>>>> +
>>>>
>>>> Should this special log be mentioned in git-update-ref.txt or
>>>> gitrepository-layout.txt?
>>>
>>> Perhaps, but I wasn't sure if this patch itself is a good idea to begin
>>> with. Not the problem it tries to solve, but its approach.
>>>
>>> For example, this cannot be shown with "reflog show" or "log -g" due to
>>> the way these frontends locate the reflog file to read (the logic wants to
>>> have an underlying ref).
>>>
>>
>> I think you have thought of this. What's wrong with keeping reflog
>> when a branch is removed and appending "delete" line to the said
>> reflog? I don't know how reflogs are managed, but those reflogs
>> without associated branch will (or should) be cleaned when they are
>> expired.
>
> The problem is the following:
>
> Say, you delete a branch and its reflog is kept (with a "delete" line
> appended).
>
> Then you create a new branch under the same name. What is supposed to
> happen to the reflog? If you simply append, then old (unrelated) entries
> will not expire through the imagined "expire branch reflogs" mechanism.
>
> Now, you rename that branch. We should really split the reflog in two
> now, keeping the old name for the old parts and moving only the newer
> parts to the reflog with the new name.
I don't see any problems with that. If I happen to create a branch
with the same name, most of the time, there is something related,
unless for very generic names like "tmp". We can always notify users
about the accident resurrection of an old branch at branch creation,
so they can remove the old reflog if they want.
--
Duy
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Nguyen Thai Ngoc Duy @ 2010-12-07 16:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3fwu9365i.fsf@localhost.localdomain>
On Tue, Dec 7, 2010 at 11:22 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>> On Tue, Dec 7, 2010 at 1:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>>>
>>>> On Tue, Dec 7, 2010 at 4:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>> +#define BRANCH_DELETION_LOG "DELETED-REFS"
>>>>> +
>>>>
>>>> Should this special log be mentioned in git-update-ref.txt or
>>>> gitrepository-layout.txt?
>>>
>>> Perhaps, but I wasn't sure if this patch itself is a good idea to begin
>>> with. Not the problem it tries to solve, but its approach.
>>>
>>> For example, this cannot be shown with "reflog show" or "log -g" due to
>>> the way these frontends locate the reflog file to read (the logic wants to
>>> have an underlying ref).
>>>
>>
>> I think you have thought of this. What's wrong with keeping reflog
>> when a branch is removed and appending "delete" line to the said
>> reflog? I don't know how reflogs are managed, but those reflogs
>> without associated branch will (or should) be cleaned when they are
>> expired.
>>
>> I stick with this idea because I also want to archive old branches and
>> am thinking those reflogs ending with "archive" line will be kept
>> forever, or until I feel like digging up them again.
>
> The problem with this idea is deleting branch 'foo' and creating 'foo/bar',
> or deleting branch 'foo/bar' and creating branch 'foo'. Old reflog with
> "delete" line would block creating reflog for new branch.
Thanks. That makes sense.
--
Duy
^ permalink raw reply
* Re: [PATCH] git-rm.txt: Fix quoting
From: Jeff King @ 2010-12-07 16:43 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <73d13b752212b557c0dc157edea9a62122840e93.1291712241.git.git@drmicha.warpmail.net>
On Tue, Dec 07, 2010 at 10:07:11AM +0100, Michael J Gruber wrote:
> Literal " produces typographically incorrect quotations, but "works" in
> most circumstances. In the subheadings of git-rm.txt, it "works" for the
> html backend but not for the docbook conversion to nroff: double "" and
> spurious double spaces appear in the output.
>
> Replace "incorrect" quotations by ``correct'' ones, and fix other
> "quotations" which are really `code fragments`.
>
> This should make git-rm.txt "-clean.
Thanks, this is a much better solution than what I posted earlier.
Acked-by: Jeff King <peff@peff.net>
> We still have a lingering inconsistency for denoting code fragments.
> Single backticks merely are a literal monospaced environment; html outputcolors
> this, nroff does not indicate it at all. I'm staying consistent with the
> surrounding text here.
Try setting MAN_BOLD_LITERAL in your config.mak.
-Peff
^ permalink raw reply
* [PATCH] Corrected return values in post-receive-email.prep_for_email
From: Alan Raison @ 2010-12-07 16:32 UTC (permalink / raw)
To: git; +Cc: alan
---
contrib/hooks/post-receive-email | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/hooks/post-receive-email
b/contrib/hooks/post-receive-email
index 85724bf..020536d 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -150,7 +150,7 @@ prep_for_email()
# Anything else (is there anything else?)
echo >&2 "*** Unknown type of update to $refname
($rev_type)"
echo >&2 "*** - no email generated"
- return 0
+ return 1
;;
esac
@@ -166,10 +166,10 @@ prep_for_email()
esac
echo >&2 "*** $config_name is not set so no email will be
sent"
echo >&2 "*** for $refname update $oldrev->$newrev"
- return 0
+ return 1
fi
- return 1
+ return 0
}
#
--
1.7.3.1.msysgit.0
^ permalink raw reply related
* Re: [PATCH] Corrected return values in post-receive-email.prep_for_email
From: Thiago Farina @ 2010-12-07 16:50 UTC (permalink / raw)
To: Alan Raison; +Cc: git
In-Reply-To: <002501cb962c$5fa3aa40$1eeafec0$@me.uk>
Care to explain in the change log message why the return value should
be 1 instead of 0?
On Tue, Dec 7, 2010 at 2:32 PM, Alan Raison <alan@theraisons.me.uk> wrote:
> ---
> contrib/hooks/post-receive-email | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/hooks/post-receive-email
> b/contrib/hooks/post-receive-email
> index 85724bf..020536d 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -150,7 +150,7 @@ prep_for_email()
> # Anything else (is there anything else?)
> echo >&2 "*** Unknown type of update to $refname
> ($rev_type)"
> echo >&2 "*** - no email generated"
> - return 0
> + return 1
> ;;
> esac
>
> @@ -166,10 +166,10 @@ prep_for_email()
> esac
> echo >&2 "*** $config_name is not set so no email will be
> sent"
> echo >&2 "*** for $refname update $oldrev->$newrev"
> - return 0
> + return 1
> fi
>
> - return 1
> + return 0
> }
>
> #
> --
> 1.7.3.1.msysgit.0
>
> --
> 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
>
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Jeff King @ 2010-12-07 17:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vmxoiqeoq.fsf@alter.siamese.dyndns.org>
On Mon, Dec 06, 2010 at 10:28:53PM -0800, Junio C Hamano wrote:
> > Should this special log be mentioned in git-update-ref.txt or
> > gitrepository-layout.txt?
>
> Perhaps, but I wasn't sure if this patch itself is a good idea to begin
> with. Not the problem it tries to solve, but its approach.
>
> For example, this cannot be shown with "reflog show" or "log -g" due to
> the way these frontends locate the reflog file to read (the logic wants to
> have an underlying ref).
Yeah, I think this is not _quite_ what people want in this area. A base
requirement from past discussions, I think, is that the whole reflog of
the deleted branch be saved rather than just the tip. And then "reflog
show" would make a lot more sense on such saved reflogs.
I'm not sure in practice how important that distinction is, as we are
not saving deleted branch reflogs _at all_ right now, so the
requirements are mostly speculation at this point.
The most recent discussion I recall is this one:
http://thread.gmane.org/gmane.comp.version-control.git/144250/focus=145353
where the general idea was to just keep deleted reflogs around, append
to them if the branch was recreated, and use a consistent renaming
scheme to avoid D/F naming conflicts (e.g., "foo" is a deleted ref, and
you create "foo/bar").
-Peff
^ permalink raw reply
* RE: [PATCH] Corrected return values in post-receive-email.prep_for_email
From: Alan Raison @ 2010-12-07 17:10 UTC (permalink / raw)
To: 'Thiago Farina'; +Cc: git
In-Reply-To: <AANLkTikYnDNRPVd-wd4+3jsX2fBbjxODEGATN5dD7t1E@mail.gmail.com>
In the main loop (lines 734 and 738 in the current master) the && and || operations assume true==0 and false==1; in line with shell defaults.
I tested it on a sourceforge shell (I think using Bash); error conditions reported an error to standard error, then proceeded to generate the email; if prep_for_email succeeded then no mail was sent.
HTH
Alan
-----Original Message-----
From: Thiago Farina [mailto:tfransosi@gmail.com]
Sent: 07 December 2010 16:50
To: Alan Raison
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Corrected return values in post-receive-email.prep_for_email
Care to explain in the change log message why the return value should
be 1 instead of 0?
On Tue, Dec 7, 2010 at 2:32 PM, Alan Raison <alan@theraisons.me.uk> wrote:
> ---
> contrib/hooks/post-receive-email | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/hooks/post-receive-email
> b/contrib/hooks/post-receive-email
> index 85724bf..020536d 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -150,7 +150,7 @@ prep_for_email()
> # Anything else (is there anything else?)
> echo >&2 "*** Unknown type of update to $refname
> ($rev_type)"
> echo >&2 "*** - no email generated"
> - return 0
> + return 1
> ;;
> esac
>
> @@ -166,10 +166,10 @@ prep_for_email()
> esac
> echo >&2 "*** $config_name is not set so no email will be
> sent"
> echo >&2 "*** for $refname update $oldrev->$newrev"
> - return 0
> + return 1
> fi
>
> - return 1
> + return 0
> }
>
> #
> --
> 1.7.3.1.msysgit.0
>
> --
> 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
>
^ permalink raw reply
* Re: [PATCH] git-rm.txt: Fix quoting
From: Jonathan Nieder @ 2010-12-07 17:19 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Jeff King, Junio C Hamano
In-Reply-To: <73d13b752212b557c0dc157edea9a62122840e93.1291712241.git.git@drmicha.warpmail.net>
Michael J Gruber wrote:
> --- a/Documentation/git-rm.txt
> +++ b/Documentation/git-rm.txt
> @@ -111,8 +111,8 @@ tree using this command:
> git ls-files -z | xargs -0 rm -f
> ----------------
>
> -and then "untar" the new code in the working tree. Alternately
> -you could "rsync" the changes into the working tree.
> +and then `untar` the new code in the working tree. Alternately
> +you could `rsync` the changes into the working tree.
I like the patch. Is there really an "untar" command?
Maybe something like this on top? ('rsync' is in italics because it
is just a command name rather than a full command ready to be typed on
the command line.)
---
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index dd61ebd..0adbe8b 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -90,7 +90,7 @@ depending on the use case, there are several ways that can be
done.
Using ``git commit -a''
-~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~
If you intend that your next commit should record all modifications
of tracked files in the working tree and record all removals of
files that have been removed from the working tree with `rm`
@@ -99,7 +99,7 @@ automatically notice and record all removals. You can also have a
similar effect without committing by using `git add -u`.
Using ``git add -A''
-~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~
When accepting a new code drop for a vendor branch, you probably
want to record both the removal of paths and additions of new paths
as well as modifications of existing paths.
@@ -111,8 +111,8 @@ tree using this command:
git ls-files -z | xargs -0 rm -f
----------------
-and then `untar` the new code in the working tree. Alternately
-you could `rsync` the changes into the working tree.
+and then untar the new code in the working tree. Alternately
+you could 'rsync' the changes into the working tree.
After that, the easiest way to record all removals, additions, and
modifications in the working tree is:
^ permalink raw reply related
* Re: [PATCH] git-rm.txt: Fix quoting
From: Jeff King @ 2010-12-07 17:25 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Michael J Gruber, git, Junio C Hamano
In-Reply-To: <20101207171939.GA21105@burratino>
On Tue, Dec 07, 2010 at 11:19:39AM -0600, Jonathan Nieder wrote:
> Michael J Gruber wrote:
>
> > --- a/Documentation/git-rm.txt
> > +++ b/Documentation/git-rm.txt
> > @@ -111,8 +111,8 @@ tree using this command:
> > git ls-files -z | xargs -0 rm -f
> > ----------------
> >
> > -and then "untar" the new code in the working tree. Alternately
> > -you could "rsync" the changes into the working tree.
> > +and then `untar` the new code in the working tree. Alternately
> > +you could `rsync` the changes into the working tree.
>
> I like the patch. Is there really an "untar" command?
Heh. Yeah, I was so caught up in looking at formatting that I didn't
think about the actual meaning. :) Untar should definitely not be a
literal (and should not have been quoted in the first place).
> Maybe something like this on top? ('rsync' is in italics because it
> is just a command name rather than a full command ready to be typed on
> the command line.)
No opinion on that from me.
> Using ``git commit -a''
> -~~~~~~~~~~~~~~~~~~~~~
> +~~~~~~~~~~~~~~~~~~~~~~~
I think this length doesn't have to match the text above, but I agree it
looks better to viewers of the source if it does.
-Peff
^ permalink raw reply
* Re: cmd_cherry in builtin/log.c?
From: Jonathan Nieder @ 2010-12-07 17:39 UTC (permalink / raw)
To: Thiago Farina; +Cc: Git Mailing List, rene.scharfe
In-Reply-To: <AANLkTikXmc-3BBkxy-D8GNLAMXUOPghp78GpStZ-_wBW@mail.gmail.com>
Hi,
Thiago Farina wrote:
> I was looking into builtin/log.c to see how it does --reverse and I
> saw that cmd_cherry is there.
>
> I'm wondering, why is it there?
Good question. So let's check.
$ git log --oneline -Scmd_cherry builtin/log.c
81b50f3 Move 'builtin-*' into a 'builtin/' subdirectory
That wasn't too helpful. Okay, okay.
$ git log --oneline -Scmd_cherry -- builtin-log.c
81b50f3 Move 'builtin-*' into a 'builtin/' subdirectory
e827633 Built-in cherry
Running "git show e827633" reveals that the core of the original
script is
for c in $inup
do
git-diff-tree -p $c
done | git-patch-id |
while read id name
do
echo $name >>$patch/$id
done
while the core of the builtin version is
get_patch_ids(&revs, &patch_id_opts, prefix);
The latter function is static, introduced by v1.4.1~12^2~5
(format-patch: introduce "--ignore-if-in-upstream", 2006-06-25).
So the answer is that "git cherry" is considered a variant on
"git log" (like format-patch, show, and whatchanged) and that it uses
"git log" internals.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Jonathan Nieder @ 2010-12-07 17:45 UTC (permalink / raw)
To: Casey Dahlin; +Cc: Junio C Hamano, git
In-Reply-To: <20101207162358.GT355@fearengine.rdu.redhat.com>
Casey Dahlin wrote:
> Could commits made onto a detached head also show up here? Or is that
> better thwarted with another mechanism?
I think that's better thwarted with the HEAD reflog:
$ git log -g HEAD
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Casey Dahlin @ 2010-12-07 17:54 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Casey Dahlin, Junio C Hamano, git
In-Reply-To: <20101207174520.GB21483@burratino>
On Tue, Dec 07, 2010 at 11:45:20AM -0600, Jonathan Nieder wrote:
> Casey Dahlin wrote:
>
> > Could commits made onto a detached head also show up here? Or is that
> > better thwarted with another mechanism?
>
> I think that's better thwarted with the HEAD reflog:
>
> $ git log -g HEAD
I was more worried about changes that were made onto a detached head,
and then the head was reattached, leaving the new commits dangling.
The end result is identical to a deleted branch, just wondering if we
should note it in the same place.
--CJD
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Jonathan Nieder @ 2010-12-07 18:02 UTC (permalink / raw)
To: Casey Dahlin; +Cc: Junio C Hamano, git
In-Reply-To: <20101207175418.GU355@fearengine.rdu.redhat.com>
Casey Dahlin wrote:
> On Tue, Dec 07, 2010 at 11:45:20AM -0600, Jonathan Nieder wrote:
>> Casey Dahlin wrote:
>>> Could commits made onto a detached head also show up here? Or is that
>>> better thwarted with another mechanism?
>>
>> I think that's better thwarted with the HEAD reflog:
>>
>> $ git log -g HEAD
>
> I was more worried about changes that were made onto a detached head,
> and then the head was reattached, leaving the new commits dangling.
But isn't that exactly what a detached HEAD is for? If one wants
the experiments one does on detached HEAD to be kept around "just
in case", wouldn't it make more sense to give them a (branch) name so
they can be separated from one another?
In other words, I do not see the connection yet. Maybe it would be
best to propose another patch on top to do that? (Patches often come
with documentation, which means clear explanation of use cases, which
would address my worry here.)
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Jeff King @ 2010-12-07 18:12 UTC (permalink / raw)
To: Casey Dahlin; +Cc: Jonathan Nieder, Junio C Hamano, git
In-Reply-To: <20101207175418.GU355@fearengine.rdu.redhat.com>
On Tue, Dec 07, 2010 at 12:54:18PM -0500, Casey Dahlin wrote:
> On Tue, Dec 07, 2010 at 11:45:20AM -0600, Jonathan Nieder wrote:
> > Casey Dahlin wrote:
> >
> > > Could commits made onto a detached head also show up here? Or is that
> > > better thwarted with another mechanism?
> >
> > I think that's better thwarted with the HEAD reflog:
> >
> > $ git log -g HEAD
>
> I was more worried about changes that were made onto a detached head,
> and then the head was reattached, leaving the new commits dangling.
>
> The end result is identical to a deleted branch, just wondering if we
> should note it in the same place.
We have enough information in the HEAD reflog already to reconstruct
those sorts of things.
You can detect entering and leaving the detached HEAD in the reflog. The
reflog comments look something like this:
checkout: moving from $SOME_BRANCH to $SOME_SHA1
commit: $SOME_COMMIT_MESSAGE
checkout: moving from $SOME_OTHER_SHA1 to $BRANCH|$SHA1
So from that you can see that we entered a detached HEAD state, made a
commit, and that commit became dangling when we moved. One could write a
script to search for these cases (but note that most detached instances
just involve rebasing, which is probably not interesting, as we install
the result into the branch tip at the end).
I don't think this belongs in the same realm as "deleted branches", but
I do think we could have a special option to "git fsck" to stick these
into lost-found.
-Peff
^ permalink raw reply
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Shawn Pearce @ 2010-12-07 18:14 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20101207170623.GB21749@sigill.intra.peff.net>
On Tue, Dec 7, 2010 at 9:06 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Dec 06, 2010 at 10:28:53PM -0800, Junio C Hamano wrote:
>
>> > Should this special log be mentioned in git-update-ref.txt or
>> > gitrepository-layout.txt?
>>
>> Perhaps, but I wasn't sure if this patch itself is a good idea to begin
>> with. Not the problem it tries to solve, but its approach.
>>
>> For example, this cannot be shown with "reflog show" or "log -g" due to
>> the way these frontends locate the reflog file to read (the logic wants to
>> have an underlying ref).
>
> Yeah, I think this is not _quite_ what people want in this area. A base
> requirement from past discussions, I think, is that the whole reflog of
> the deleted branch be saved rather than just the tip. And then "reflog
> show" would make a lot more sense on such saved reflogs.
Yup, that's what I recall too, folks (including myself) want to
save the reflog of the deleted branch, so it can be recovered if
the branch itself were to be recovered with an --undelete option.
> I'm not sure in practice how important that distinction is, as we are
> not saving deleted branch reflogs _at all_ right now, so the
> requirements are mostly speculation at this point.
>
> The most recent discussion I recall is this one:
>
> http://thread.gmane.org/gmane.comp.version-control.git/144250/focus=145353
>
> where the general idea was to just keep deleted reflogs around, append
> to them if the branch was recreated, and use a consistent renaming
> scheme to avoid D/F naming conflicts (e.g., "foo" is a deleted ref, and
> you create "foo/bar").
Per check-ref-format, ref names cannot contain two dots. We could
archive ref logs by renaming them, $GIT_DIR/logs/refs/heads/foo
becomes $GIT_DIR/logs/refs/heads/foo..deleted-1. If foo is created
and deleted again, it becomes foo..deleted-2.
This still causes problems for git reflog show / git log -g because
they want a current ref to enumerate the log of.
A different approach might be to have $GIT_DIR/logs/refs/REF_ATTIC,
and special case that in git reflog show / git log -g. When a
ref is deleted, append its entire log onto REF_ATTIC, between two
specially formatted marker lines. When recovering a branch, copy
out the region from the REF_ATTIC log.
--
Shawn.
^ permalink raw reply
* [PATCH] Improved error messages when temporary file creation fails
From: Arnout Engelen @ 2010-12-07 18:16 UTC (permalink / raw)
To: git
This patch has been submitted/discussed before, but that version doesn't apply
cleanly to the newest git anymore, so here's an updated version.
It improves diagnostic error messages when creating a temporary file fails.
Signed-off-by: Arnout Engelen <arnouten@bzzt.net>
---
Makefile | 1 +
t/t0070-fundamental.sh | 13 +++++++++++++
test-mktemp.c | 16 ++++++++++++++++
wrapper.c | 29 +++++++++++++++++++++++++----
wrapper.h | 4 ++++
5 files changed, 59 insertions(+), 4 deletions(-)
create mode 100644 test-mktemp.c
create mode 100644 wrapper.h
diff --git a/Makefile b/Makefile
index 7a5fb69..10cfab2 100644
--- a/Makefile
+++ b/Makefile
@@ -434,6 +434,7 @@ TEST_PROGRAMS_NEED_X += test-string-pool
TEST_PROGRAMS_NEED_X += test-svn-fe
TEST_PROGRAMS_NEED_X += test-treap
TEST_PROGRAMS_NEED_X += test-index-version
+TEST_PROGRAMS_NEED_X += test-mktemp
TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X))
diff --git a/t/t0070-fundamental.sh b/t/t0070-fundamental.sh
index 680d7d6..9bee8bf 100755
--- a/t/t0070-fundamental.sh
+++ b/t/t0070-fundamental.sh
@@ -12,4 +12,17 @@ test_expect_success 'character classes (isspace, isalpha etc.)' '
test-ctype
'
+test_expect_success 'mktemp to nonexistent directory prints filename' '
+ test_must_fail test-mktemp doesnotexist/testXXXXXX 2>err &&
+ grep "doesnotexist/test" err
+'
+
+test_expect_success POSIXPERM 'mktemp to unwritable directory prints filename' '
+ mkdir cannotwrite &&
+ chmod -w cannotwrite &&
+ test_when_finished "chmod +w cannotwrite" &&
+ test_must_fail test-mktemp cannotwrite/testXXXXXX 2>err &&
+ grep "cannotwrite/test" err
+'
+
test_done
diff --git a/test-mktemp.c b/test-mktemp.c
new file mode 100644
index 0000000..d392fa7
--- /dev/null
+++ b/test-mktemp.c
@@ -0,0 +1,16 @@
+/*
+ * test-mktemp.c: code to exercise the creation of temporary files
+ */
+#include <string.h>
+#include "git-compat-util.h"
+#include "wrapper.h"
+
+int main(int argc, char *argv[])
+{
+ if (argc != 2) {
+ usage("Expected 1 parameter defining the temporary file template");
+ }
+ xmkstemp(strdup(argv[1]));
+
+ return 0;
+}
diff --git a/wrapper.c b/wrapper.c
index 4c1639f..6640c87 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -2,6 +2,7 @@
* Various trivial helper wrappers around standard functions
*/
#include "cache.h"
+#include "wrapper.h"
static void do_nothing(size_t size)
{
@@ -196,10 +197,20 @@ FILE *xfdopen(int fd, const char *mode)
int xmkstemp(char *template)
{
int fd;
+ char origtemplate[255];
+ strlcpy(origtemplate, template, 255);
fd = mkstemp(template);
- if (fd < 0)
- die_errno("Unable to create temporary file");
+ if (fd < 0) {
+ if (!template[0])
+ template = origtemplate;
+
+ if (is_absolute_path(template))
+ die_errno("Unable to create temporary file '%s'", template);
+ else
+ die_errno("Unable to create temporary file '%s' at %s",
+ template, getcwd(NULL, 0));
+ }
return fd;
}
@@ -319,10 +330,20 @@ int gitmkstemps(char *pattern, int suffix_len)
int xmkstemp_mode(char *template, int mode)
{
int fd;
+ char origtemplate[255];
+ strlcpy(origtemplate, template, 255);
fd = git_mkstemp_mode(template, mode);
- if (fd < 0)
- die_errno("Unable to create temporary file");
+ if (fd < 0) {
+ if (!template[0])
+ template = origtemplate;
+
+ if (is_absolute_path(template))
+ die_errno("Unable to create temporary file '%s'", template);
+ else
+ die_errno("Unable to create temporary file '%s' at %s",
+ template, getcwd(NULL, 0));
+ }
return fd;
}
diff --git a/wrapper.h b/wrapper.h
new file mode 100644
index 0000000..b06ff0d
--- /dev/null
+++ b/wrapper.h
@@ -0,0 +1,4 @@
+/*
+ * Various trivial helper wrappers around standard functions
+ */
+int xmkstemp(char *template);
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] logging branch deletion to help recovering from mistakes
From: Jeff King @ 2010-12-07 18:20 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <AANLkTimnp3xCHp_3E7ry-5OQL3PFnYh=H8PhfzMN307C@mail.gmail.com>
On Tue, Dec 07, 2010 at 10:14:19AM -0800, Shawn O. Pearce wrote:
> Per check-ref-format, ref names cannot contain two dots. We could
> archive ref logs by renaming them, $GIT_DIR/logs/refs/heads/foo
> becomes $GIT_DIR/logs/refs/heads/foo..deleted-1. If foo is created
> and deleted again, it becomes foo..deleted-2.
>
> This still causes problems for git reflog show / git log -g because
> they want a current ref to enumerate the log of.
That seems reasonable to me. The "reflog show" limitation is just a
matter of a simple code fix, though, isn't it? Is there a good reason
for this restriction to exist? And even if there is, it would be simple
to special case it for ..deleted-* branches.
> A different approach might be to have $GIT_DIR/logs/refs/REF_ATTIC,
> and special case that in git reflog show / git log -g. When a
> ref is deleted, append its entire log onto REF_ATTIC, between two
> specially formatted marker lines. When recovering a branch, copy
> out the region from the REF_ATTIC log.
That seems a lot less efficient, as we have to linearly search all of
REF_ATTIC to get:
1. the reflog for one deleted branch
2. the list of deleted branches
Neither of those is probably particularly performance critical, but it
just seems like keeping the logs in files indexed by the original ref
names is a more natural fit.
-Peff
^ permalink raw reply
* [PATCH 1/2] describe: Use for_each_rawref
From: Anders Kaseorg @ 2010-12-07 18:22 UTC (permalink / raw)
To: Junio C Hamano, SZEDER Gábor
Cc: Jonathan Nieder, git, Kirill Smelkov, Thomas Rast
In-Reply-To: <20101207095818.GB1867@neumann>
Don’t waste time checking for dangling refs; they wouldn’t affect the
output of ‘git describe’ anyway. Although this doesn’t gain much
performance by itself, it does in conjunction with the next commit.
Signed-off-by: Anders Kaseorg <andersk@ksplice.com>
diff --git a/builtin/describe.c b/builtin/describe.c
index 43caff2..700f740 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -418,7 +418,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
return cmd_name_rev(i + argc, args, prefix);
}
- for_each_ref(get_name, NULL);
+ for_each_rawref(get_name, NULL);
if (!found_names && !always)
die("No names found, cannot describe anything.");
--
1.7.3.3
^ permalink raw reply related
* [PATCH 2/2] describe: Don’t look up commits with --exact-match
From: Anders Kaseorg @ 2010-12-07 18:22 UTC (permalink / raw)
To: Junio C Hamano, SZEDER Gábor
Cc: Jonathan Nieder, git, Kirill Smelkov, Thomas Rast
In-Reply-To: <alpine.DEB.2.02.1012071320240.23348@dr-wily.mit.edu>
This makes ‘git describe --exact-match HEAD’ about 15 times faster on
a cold cache (2.3s instead of 35s) in a linux-2.6 repository with many
packed tags. That’s a huge win for the interactivity of the __git_ps1
shell prompt helper when on a detached head.
Signed-off-by: Anders Kaseorg <andersk@ksplice.com>
diff --git a/builtin/describe.c b/builtin/describe.c
index 700f740..0cddef1 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -22,7 +22,7 @@ static int tags; /* Allow lightweight tags */
static int longformat;
static int abbrev = DEFAULT_ABBREV;
static int max_candidates = 10;
-static int found_names;
+static struct commit_name *names;
static const char *pattern;
static int always;
static const char *dirty;
@@ -34,6 +34,8 @@ static const char *diff_index_args[] = {
struct commit_name {
+ struct commit_name *next;
+ unsigned char peeled[20];
struct tag *tag;
unsigned prio:2; /* annotated tag = 2, tag = 1, head = 0 */
unsigned name_checked:1;
@@ -78,31 +80,26 @@ static int replace_name(struct commit_name *e,
}
static void add_to_known_names(const char *path,
- struct commit *commit,
+ const unsigned char *peeled,
int prio,
const unsigned char *sha1)
{
- struct commit_name *e = commit->util;
struct tag *tag = NULL;
- if (replace_name(e, prio, sha1, &tag)) {
- size_t len = strlen(path)+1;
- free(e);
- e = xmalloc(sizeof(struct commit_name) + len);
- e->tag = tag;
- e->prio = prio;
- e->name_checked = 0;
- hashcpy(e->sha1, sha1);
- memcpy(e->path, path, len);
- commit->util = e;
- }
- found_names = 1;
+ size_t len = strlen(path)+1;
+ struct commit_name *e = xmalloc(sizeof(struct commit_name) + len);
+ hashcpy(e->peeled, peeled);
+ e->tag = tag;
+ e->prio = prio;
+ e->name_checked = 0;
+ hashcpy(e->sha1, sha1);
+ memcpy(e->path, path, len);
+ e->next = names;
+ names = e;
}
static int get_name(const char *path, const unsigned char *sha1, int flag, void *cb_data)
{
int might_be_tag = !prefixcmp(path, "refs/tags/");
- struct commit *commit;
- struct object *object;
unsigned char peeled[20];
int is_tag, prio;
@@ -110,16 +107,10 @@ static int get_name(const char *path, const unsigned char *sha1, int flag, void
return 0;
if (!peel_ref(path, peeled) && !is_null_sha1(peeled)) {
- commit = lookup_commit_reference_gently(peeled, 1);
- if (!commit)
- return 0;
- is_tag = !!hashcmp(sha1, commit->object.sha1);
+ is_tag = !!hashcmp(sha1, peeled);
} else {
- commit = lookup_commit_reference_gently(sha1, 1);
- object = parse_object(sha1);
- if (!commit || !object)
- return 0;
- is_tag = object->type == OBJ_TAG;
+ hashcpy(peeled, sha1);
+ is_tag = 0;
}
/* If --all, then any refs are used.
@@ -142,7 +133,7 @@ static int get_name(const char *path, const unsigned char *sha1, int flag, void
if (!prio)
return 0;
}
- add_to_known_names(all ? path + 5 : path + 10, commit, prio, sha1);
+ add_to_known_names(all ? path + 5 : path + 10, peeled, prio, sha1);
return 0;
}
@@ -228,7 +219,7 @@ static void describe(const char *arg, int last_one)
unsigned char sha1[20];
struct commit *cmit, *gave_up_on = NULL;
struct commit_list *list;
- struct commit_name *n;
+ struct commit_name *n, *e;
struct possible_tag all_matches[MAX_TAGS];
unsigned int match_cnt = 0, annotated_cnt = 0, cur_match;
unsigned long seen_commits = 0;
@@ -240,7 +231,12 @@ static void describe(const char *arg, int last_one)
if (!cmit)
die("%s is not a valid '%s' object", arg, commit_type);
- n = cmit->util;
+ n = NULL;
+ for (e = names; e; e = e->next) {
+ if (!hashcmp(e->peeled, cmit->object.sha1) &&
+ replace_name(n, e->prio, e->sha1, &e->tag))
+ n = e;
+ }
if (n && (tags || all || n->prio == 2)) {
/*
* Exact match to an existing ref.
@@ -259,6 +255,12 @@ static void describe(const char *arg, int last_one)
if (debug)
fprintf(stderr, "searching to describe %s\n", arg);
+ for (e = names; e; e = e->next) {
+ struct commit *c = lookup_commit_reference_gently(e->peeled, 1);
+ if (c && replace_name(c->util, e->prio, e->sha1, &e->tag))
+ c->util = e;
+ }
+
list = NULL;
cmit->object.flags = SEEN;
commit_list_insert(cmit, &list);
@@ -419,7 +421,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
}
for_each_rawref(get_name, NULL);
- if (!found_names && !always)
+ if (!names && !always)
die("No names found, cannot describe anything.");
if (argc == 0) {
--
1.7.3.3
^ 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