* Re: Why do we need [PATCH]?
From: Dave Jones @ 2005-12-16 21:13 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20051216210145.GA25311@mars.ravnborg.org>
On Fri, Dec 16, 2005 at 10:01:45PM +0100, Sam Ravnborg wrote:
> I've just applied a patch to my git tree using git-applymbox.
> It worked like a charm as it often do.
> But then when I did a quick check with gitk it stuck me that
> the subject was prefixed with [PATCH].
> I am aware that the [PATCH] in subject tell me:
> "patch is received from somewhere and applied by me to the .git tree".
> This is in comparsion to patches received when I merge a git tree for
> example.
>
> But with common practice to use sign-off I wonder the value of this
> patch marker.
> When browsing the kernel shortlog I often focus on first word in subject
> - cause this tells me what system/drivers is changed. But with the
> [PATCH] marker I have to read some non-sense to see actual subject.
>
> The information is redundant since metadata already tell me who is the
> author and who committed the change.
> So could we have it removed or if people continue to find it usefull
> then at least hide it behind some option. Using the [PATCH] prefix is
> not the natural thing to do with git.
>
> I looked at the source and found the -k option, but adding [PATCH]
> should not be default behaviour so this is not the correct solution.
I'm still using Linus' original 'applypatch' script, on which I think
this stuff was based, and this behaviour annoyed me too.
So I changed it to do this..
if [ -f .treename ]; then
TREENAME=`cat .treename`
else
TREENAME='PATCH'
fi
(echo "[$TREENAME] $SUBJECT" ; if [ -s $MSGFILE ]; then echo ; cat $MSGFILE; fi ) > $final
and then I have a .treename in say the AGP tree, containing just 'AGPGART',
and the changelogs get the prefixes that actually mean something useful.
(And those markers are invaluable when searching through history for changes)
Dave
^ permalink raw reply
* Re: git merge questions
From: Don Zickus @ 2005-12-16 21:13 UTC (permalink / raw)
Cc: git
In-Reply-To: <7vacf0g4ga.fsf@assigned-by-dhcp.cox.net>
On 12/16/05, Junio C Hamano <junkio@cox.net> wrote:
> Don Zickus <dzickus@gmail.com> writes:
>
> > Now over the course of 2.6.15 the arch/ppc64 was renamed to
> > arch/powerpc. Fine. The merge algorithms handled all the unchanged
> > files properly. However arch/ppc64/Kconfig was modified and the
> > merging was left unresolved. In fact there is no file no merge
> > against (because it moved). So 'git-ls-files -u' only shows stage 1+3
> > (no stage 2, of course).
> >
> > How do I merge those changes? I don't know enough about all the git
> > commands to figure this out, especially how to take advantage of the
> > stage 1, 2, and 3 files.
>
> I do not work on the kernel myself so I'll probably get the
> details wrong, but I am guessing here is what you have:
>
Sorry, I should have been more specific. How about this:
1) 2.6.14-test branch modifies arch/ppc64/Kconfig
2) master branch renames arch/ppc64/Kconfig to arch/powerpc/Kconfig
3) 2.6.14-test and master branch share a common ancestor v2.6.14
4) Need to merge change arch/ppc64/Kconfig to arch/powerpc/Kconfig
$ git ls-files -u
100644 c658650af429672267409508b02b38754c11a40f 1 arch/ppc64/Kconfig
100644 8abf1118ebbd59954d098d87679114ffda0e75cb 3 arch/ppc64/Kconfig
***Notice no stage 2
$ ls -ld arch/p*
drwxrwxr-x 9 dzickus dzickus 4096 Dec 16 14:12 arch/parisc
drwxrwxr-x 11 dzickus dzickus 4096 Dec 16 14:26 arch/powerpc
drwxrwxr-x 15 dzickus dzickus 4096 Dec 16 14:26 arch/ppc
***Notice no ppc64 (was removed in master branch)
$ ls -ld arch/powerpc/Kconfig*
-rw-rw-r-- 1 dzickus dzickus 24279 Dec 16 14:26 arch/powerpc/Kconfig
***Notice no backup or side copy of Kconfig
There were other conflicts with this merge (ones that weren't
automatically resolved) but those were easily merged using vi and
searching for <<<. However this particular file is providing an
unusual case.
Let me know if this helps or not.
Cheers,
Don
^ permalink raw reply
* Re: Why do we need [PATCH]?
From: Brian Gerst @ 2005-12-16 21:14 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20051216210145.GA25311@mars.ravnborg.org>
Sam Ravnborg wrote:
> Hi git's.
>
> I've just applied a patch to my git tree using git-applymbox.
> It worked like a charm as it often do.
> But then when I did a quick check with gitk it stuck me that
> the subject was prefixed with [PATCH].
> I am aware that the [PATCH] in subject tell me:
> "patch is received from somewhere and applied by me to the .git tree".
> This is in comparsion to patches received when I merge a git tree for
> example.
>
> But with common practice to use sign-off I wonder the value of this
> patch marker.
> When browsing the kernel shortlog I often focus on first word in subject
> - cause this tells me what system/drivers is changed. But with the
> [PATCH] marker I have to read some non-sense to see actual subject.
>
> The information is redundant since metadata already tell me who is the
> author and who committed the change.
> So could we have it removed or if people continue to find it usefull
> then at least hide it behind some option. Using the [PATCH] prefix is
> not the natural thing to do with git.
>
> I looked at the source and found the -k option, but adding [PATCH]
> should not be default behaviour so this is not the correct solution.
>
> Sam
[PATCH] makes sense for the actual email message so that the recipient
knows that the message contains a patch. But I agree that it does not
add any value to the commit message in git. It actually detracts value,
because it takes up limited space in the shortlog message.
--
Brian Gerst
^ permalink raw reply
* Why do we need [PATCH]?
From: Sam Ravnborg @ 2005-12-16 21:01 UTC (permalink / raw)
To: git
Hi git's.
I've just applied a patch to my git tree using git-applymbox.
It worked like a charm as it often do.
But then when I did a quick check with gitk it stuck me that
the subject was prefixed with [PATCH].
I am aware that the [PATCH] in subject tell me:
"patch is received from somewhere and applied by me to the .git tree".
This is in comparsion to patches received when I merge a git tree for
example.
But with common practice to use sign-off I wonder the value of this
patch marker.
When browsing the kernel shortlog I often focus on first word in subject
- cause this tells me what system/drivers is changed. But with the
[PATCH] marker I have to read some non-sense to see actual subject.
The information is redundant since metadata already tell me who is the
author and who committed the change.
So could we have it removed or if people continue to find it usefull
then at least hide it behind some option. Using the [PATCH] prefix is
not the natural thing to do with git.
I looked at the source and found the -k option, but adding [PATCH]
should not be default behaviour so this is not the correct solution.
Sam
^ permalink raw reply
* Re: allow only a strictly defined set of references under .git/
From: Alex Riesen @ 2005-12-16 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x0cj4zz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Fri, Dec 16, 2005 19:01:20 +0100:
> > Maybe we should only allow only a strictly defined set of refnames
> > under $GIT_DIR? The directory is used pretty much for anything else
> > (temporary message files, config, description).
>
> I am glad somebody is paying attention.
>
I actually run into it...
> Probably post 1.0 --- I have not assessed the extent of
> confusion yet.
It has good chances to continue to grow, as git gets more exposure.
^ permalink raw reply
* Re: git merge questions
From: Junio C Hamano @ 2005-12-16 20:41 UTC (permalink / raw)
To: Don Zickus; +Cc: git
In-Reply-To: <68948ca0512161205x3d5921bfm3bfcaa64f988eb99@mail.gmail.com>
Don Zickus <dzickus@gmail.com> writes:
> Now over the course of 2.6.15 the arch/ppc64 was renamed to
> arch/powerpc. Fine. The merge algorithms handled all the unchanged
> files properly. However arch/ppc64/Kconfig was modified and the
> merging was left unresolved. In fact there is no file no merge
> against (because it moved). So 'git-ls-files -u' only shows stage 1+3
> (no stage 2, of course).
>
> How do I merge those changes? I don't know enough about all the git
> commands to figure this out, especially how to take advantage of the
> stage 1, 2, and 3 files.
I do not work on the kernel myself so I'll probably get the
details wrong, but I am guessing here is what you have:
- 2.6.14.z has arch/ppc64/Kconfig;
- Your "test" branch has arch/ppc64/Kconfig. You may or may
not have changes since 2.6.14.z on that file;
- "test2" branch has 2.6.15-rc4, which has the file at
arch/powerpc/Kconfig;
Then, with the current branch being "test2", you pulled "test"
into it.
- Untouched [by whom???] files from arch/{ppc64,powerpc}/ were
merged correctly and you find the result of merge under
arch/powerpc --- after all you are applying changes on top of
2.6.15-rc4 and you want them under arch/powerpc as the
upstream has;
- arch/ppc64/Kconfig was modified [by whom???] and merge was
left unresolved.
I suspect these:
ls -l arch/ppc64/Kconfig <1>
git ls-files -s arch/ppc64/Kconfig <2>
ls -l arch/powerpc/Kconfig arch/powerpc/Kconfig~* <3>
git ls-files -s arch/powerpc/Kconfig <4>
<1> has the file from your "test" branch based on 2.6.14z;
<2> shows that same file;
<3> may show the three variants (I am not sure about this);
<4> has 2.6.15-rc4 version at stage 3 and merge base version at
stage 1 (I am not absolutely certain what stage 1 has, and
also am puzzled why stage 2 is not there --- if the
recursive strategy figured out renames it should have the
contents of arch/ppc64/Kconfig from test branch there).
The safest (however most primitive) way I can think of to go
from here is:
1. figure out the merge-base Kconfig file's contents.
$ mb=$(git merge-base refs/heads/test refs/heads/test2)
$ git ls-tree $(mb) arch/powerpc/Kconfig arch/ppc/Kconfig
I do not know which path the merge base has, but it should
have either one of those. Note the blob object name (call it
$oSHA1).
2. extract three versions.
$ git ls-tree refs/heads/test2 arch/powerpc/Kconfig
$ git ls-tree refs/heads/test arch/powerpc/Kconfig
Note the blob object name from these two as well (call them
$aSHA1, and $bSHA1).
3. merge those three.
$ git cat-file blob $oSHA1 >orig
$ git cat-file blob $aSHA1 >from-test2
$ git cat-file blob $bSHA1 >from-test
$ merge from-test2 orig from-test
With luck from-test2 would contain a clean automerge result, or
you will get <<< === >>> conflict markers. Resolve them in the
file, and then:
4. resolve the index and remove cruft.
$ cat from-test2 >arch/powerpc/Kconfig
$ rm -f arch/ppc64/Kconfig orig from-test2 from-test
$ git update-index --add --remove \
arch/ppc64/Kconfig arch/powerpc/Kconfig
5. if there is no other merge cruft, commit.
$ git commit
What puzzles me is that I think it is supposed to have done all
the above for you. Namely:
$ ls -l arch/ppc64/Kconfig <1>
$ git ls-files -s arch/ppc64/Kconfig <2>
$ ls -l arch/powerpc/Kconfig arch/powerpc/Kconfig~* <3>
$ git ls-files -s arch/powerpc/Kconfig <4>
<1> should not remain --- recursive merge could have notied that
the file was moved.
<2> ditto.
<3> arch/powerpc/Kconfig should be there with possibly merge
conflict markers.
<4> stage1 with merge base version (possibly renamed), stage2
with test2 version, stage3 with your test version (definitely
renamed).
and after editing arch/powerpc/Kconfig to resolve conflicts, you
should be able to just say:
$ git update-index arch/powerpc/Kconfig
$ git commit
^ permalink raw reply
* git merge questions
From: Don Zickus @ 2005-12-16 20:05 UTC (permalink / raw)
Cc: git
I now have a git merge question. I decided to try merging branches
and was left with a situation in which the file was moved on the
master branch and updated on my branch. Not sure how to properly
integrate the changes from my branch.
For example:
%git checkout -b test v2.6.14
%<manually apply all the 2.6.14.z stable patches>
%<commit those patches>
%git checkout -b test2 v2.6.15-rc4
%git pull . test
Now over the course of 2.6.15 the arch/ppc64 was renamed to
arch/powerpc. Fine. The merge algorithms handled all the unchanged
files properly. However arch/ppc64/Kconfig was modified and the
merging was left unresolved. In fact there is no file no merge
against (because it moved). So 'git-ls-files -u' only shows stage 1+3
(no stage 2, of course).
How do I merge those changes? I don't know enough about all the git
commands to figure this out, especially how to take advantage of the
stage 1, 2, and 3 files.
Thanks for any help,
Don
^ permalink raw reply
* Re: bad git pull
From: Junio C Hamano @ 2005-12-16 19:21 UTC (permalink / raw)
To: Morten Welinder; +Cc: Don Zickus, git
In-Reply-To: <118833cc0512161007k38fdd15w2dcdf0c93f26d29e@mail.gmail.com>
Morten Welinder <mwelinder@gmail.com> writes:
>> While I am sympathetic, this "Oops, I said pull when I meant
>> fetch" sounds remotely similar to "oops, I said 'rm -r' when I
>> meant to say 'ls -r'". Is it that the tool is too fragile?
>
> Didn't bk come with some kind of (one-level) undo pull? It should not
> be too hard to create something similar considering that one could
> just leave new objects in the db orphaned.
Yes, that is called "git reset".
^ permalink raw reply
* Re: bad git pull
From: Junio C Hamano @ 2005-12-16 19:20 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git, Don Zickus
In-Reply-To: <20051216172535.GA25856@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> Whenever I give a colleage an introduction to git I emphatically
> recommend that they start with using git fetch and git merge
> independantly of each other and stay away for git pull at least until
> they know what they're doing.
You "reduced" this sequence:
$ git symbolic-ref HEAD ;# to make sure you are on the branch
# you think you are on
$ git pull
to this sequence:
$ git fetch origin ;# would not damage the repository
$ git symbolic-ref HEAD ;# to make sure you are on the branch
# you think you are on
$ git merge "Merge from frotz branch of git://..." HEAD FETCH_HEAD
The thing is, you need to make sure where you are, in either
case, before the actual merge happens. Yours needs extra
typing, and in addition loses the merge message autogenerated by
"git pull". Sorry, I fail to see how that is an improvement.
> I see nothing in the English dictionary to suggest that pull
> means fetch + merge.
I agree to this. I have never used BK so this is just a
speculation, but I suspect what happened is that we inherited
"pull" terminology from there, needed to name the merge-less
part something, and we ended up calling it "fetch". So the
history behind them might be expressed better by "fetch = pull -
merge" instead of saying "pull = fetch + merge" ;-).
> ... I also recommend that some
> extra care should be taken in the tutorials and documentation to warn
> about this difference up front and possibly suggest avoiding the use of
> pull for those new to git.
Yup. Thanks for the comments. I am not a good writer, so a
patch is greatly appreciated.
BTW, I feel that setting Mail-Followup-To: to other people is
just plain rude.
Mail-Followup-To: Junio C Hamano <junkio@cox.net>,
Don Zickus <dzickus@gmail.com>, git@vger.kernel.org
I suspect you are trying to avoid receiving a duplicate message
because you subscribe to the list, but when I tell my MUA "I
want to say something to the author of this message in public" I
get Don Zickus on the To: line instead of you, and I had to edit
the To: line to point at you. Aren't you forcing me (and other
people who might want to follow-up to your message) to do extra
work, and making Don's life harder [*1*], just to work around
the problem on your end, when you could just filter the incoming
duplicates yourself?
Removing yourself from CC: line when the CC: line already
contains the mailing list you subscribe to would be fine, but I
find this use of Mail-Followup-To: somewhat objectionable.
[Footnote]
*1* Don could have a mail sorter that prioritizes messages
addressed To: over Cc: him, and response meant to *you* goes
with To: Don --- which messes up such a mail sorting rule.
^ permalink raw reply
* Re: bad git pull
From: Morten Welinder @ 2005-12-16 18:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Don Zickus, git
In-Reply-To: <7vu0d9lxx9.fsf@assigned-by-dhcp.cox.net>
> While I am sympathetic, this "Oops, I said pull when I meant
> fetch" sounds remotely similar to "oops, I said 'rm -r' when I
> meant to say 'ls -r'". Is it that the tool is too fragile?
Didn't bk come with some kind of (one-level) undo pull? It should not
be too hard to create something similar considering that one could
just leave new objects in the db orphaned.
M.
^ permalink raw reply
* Re: allow only a strictly defined set of references under .git/
From: Junio C Hamano @ 2005-12-16 18:01 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0512160024q47afe0b9v1b7f217a6cecfe68@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> The patch below reminded me of something:
>
> + /* We want to allow .git/description file and
> + * "description" branch to exist at the same time.
> + * "git-rev-parse description" should silently skip
> + * .git/description file as a candidate for
> + * get_sha1(). However, having garbage file anywhere
> + * under refs/ is not OK, and we would not have caught
> + * ambiguous heads and tags with the above test.
> + */
> + else if (**p && !access(pathname, F_OK)) {
> + /* Garbage exists under .git/refs */
> + return error("garbage ref found '%s'", pathname);
> + }
>
> Maybe we should only allow only a strictly defined set of refnames
> under $GIT_DIR? The directory is used pretty much for anything else
> (temporary message files, config, description).
I am glad somebody is paying attention.
The ref-to-object-name loop in get_sha1_basic() gets what the
user gave us, first checks it immediately under .git/ and then
under .git/refs, .git/refs/tags, .git/refs/heads, in this order.
Originally it grabbed the first match. For the last couple of
weeks, it has been made "extra careful" to detect a case where
both .git/refs/heads/foo and .git/refs/tags/foo exists and
to reject unadorned "foo" with complaints.
I have been nagged by a suspition that the whole disambiguation
business should not be there [*1*]. I think the original
semantics of getting the first match is as easy to explain, if
not easier, as the current one, and I suspect that we do not
have to worry about .git/refs/heads/HEAD if we did so. If
somebody is curious enough to name a branch "HEAD", the only
thing she should be aware of is this search order, and wherever
"branchname" is called for she should be able to say "HEAD" to
mean .git/refs/heads/HEAD, but places that call for an arbitrary
object name, she needs to disambiguate by saying "heads/HEAD" or
even "refs/heads/HEAD".
I suspect that git barebone Porcelain-ish carelessly uses
"git-rev-parse --verify $branchname" when it really means
"git-rev-parse --verify refs/heads/$branchname" in some places
[*2*], but if we fix them, we may not even need to have the "we
do not like HEAD" patch by Johannes (which has already been
merged).
Probably post 1.0 --- I have not assessed the extent of
confusion yet.
[Footnote]
*1* It was not in Linus version, and I consider anything I added
recently is of suspecious design value.
*2* That is, where we advertise that we get branchname as
parameter to the command.
^ permalink raw reply
* Re: bad git pull
From: Junio C Hamano @ 2005-12-16 17:40 UTC (permalink / raw)
To: Don Zickus; +Cc: git
In-Reply-To: <68948ca0512160739g12a3e25en256bae8c354c3a45@mail.gmail.com>
Don Zickus <dzickus@gmail.com> writes:
>> While I am sympathetic, this "Oops, I said pull when I meant
>> fetch" sounds remotely similar to "oops, I said 'rm -r' when I
>> meant to say 'ls -r'". Is it that the tool is too fragile?
>
> Sorry, wrong choice of words. Didn't mean to imply anything negative.
> Though, I am still learning the tool and its features, I do appreciate
> your feedback and your last email was correct in understanding the
> mess I created. I'll go read up on the differences between 'fetch'
> and 'pull'.
I too was a bit too defensive, and I agree the tool is prone to
easy errors; the worst part is that there is no "rm -i"
equivalent to be extra careful [*1*]. On the other hand, we
have "git reset" to recover from, so it is not as bad as
a mistake with "rm" ;-).
If for example there were a way to say "this `origin' shortcut
is to be pulled into `master' branch and nothing else", we could
have caught the "git pull" you had trouble with. There was a
discussion on the list in the past to extend remotes/ files to
allow such restriction of the patchflow to be expressed, but
back then I felt the kind of restriction the proposal could
express was too limiting, and the discussion was a bit premature
because we did not have recommended patterns yet.
We might want to revive the discussion post 1.0. Taking the
example of the topic-branch workflow by Tony, the "patch flow"
language needs to be able to express something at least this:
- topic branches -- branched from 'origin' somewhere in the
past; commits accumulated but usually nothing is merged
into them.
- 'test' -- branched from 'origin' somewhere in the past; used
solely to merge topic branches into it and no commits are
made into it directly; branches that are regularly merged
into it are:
- topic branches
- 'origin'
- 'release'
- 'release' -- branched from 'origin' somewhere in the
past; trivial/obviously correct commits are made into it
directly; proven to be good topic branches are merged into it
for consumption by others; branches that are regularly merged
into it are:
- topic branches
- 'origin'
- never 'test'
[Footnote]
*1* IMHO "rm -i" is not that safe, though. If one overuses it,
it trains one's fingers to say "y" without much thinking.
^ permalink raw reply
* Re: bad git pull
From: Carl Baldwin @ 2005-12-16 17:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Don Zickus, git
In-Reply-To: <7vu0d9lxx9.fsf@assigned-by-dhcp.cox.net>
Hello,
Here are my two cents. I'll try my best to make a case for those poor
souls who get into this sort of mess.
Whenever I give a colleage an introduction to git I emphatically
recommend that they start with using git fetch and git merge
independantly of each other and stay away for git pull at least until
they know what they're doing. This is because I have found that people
are really surprised at what happens when they type git pull until it
really sinks in that 'pull = fetch + merge to current branch, whatever
that may be'.
The difference between the words fetch and pull is much more subtle than
the difference between remove and list which are the basis for the
commands rm and ls. I see nothing in the English dictionary to suggest
that pull means fetch + merge. This is a gitism. Even after reading
documentation clearly and even using git for a while the difference
really takes some time to sink in.
I think a great degree of understanding should be shown toward those who
dig themselves into this kind of thing. I also recommend that some
extra care should be taken in the tutorials and documentation to warn
about this difference up front and possibly suggest avoiding the use of
pull for those new to git.
Carl
PS The issue was exacerbated when cogito and git were inconsistent on
their respective usages of pull and fetch. I think this has gone away,
hasn't it? I haven't used cogito in some time so I really don't know.
On Thu, Dec 15, 2005 at 03:53:38PM -0800, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Don Zickus <dzickus@gmail.com> writes:
> >
> >> I notice if I create a branch (and switch to it) in the linux kernel
> >> off of say version 2.6.14, then later do a git pull, things get ugly.
> >> It seems like all the upstream changes are being merged into the
> >> 2.6.14 branch (instead of the latest kernel tag).
> >>
> >> Is this a user error because the tool is still fragile?
> >
> > I do not understand the question.
> >
> > The user wanted all the good developments from the mainline into
> > the fork he created starting at 2.6.14, and the tool did what
> > was asked. Why would you want to forbid that from happening,
> > and what did you want to happen instead?
>
> Actually I think I do understand the question. You have a clone
> of linux-2.6 repository, and your "origin" branch tracks the
> bleeding edge from Linus. You also have "myhack" branch that
> was forked off from 2.6.14, and wanted to see what new things
> Linus has by updating "origin", and perhaps merge those changes
> into your "master" which keeps track of your hacks based on
> Linus tip, but unfortunately you were on "myhack" branch.
>
> Ouch.
>
> So what you wanted to do was probably:
>
> $ git fetch ;# this updates "origin" to Linus tip
>
> instead of
>
> $ git pull ;# this updates "origin" to Linus tip *and*
> # merges that into the current branch
>
> As you may probably know, you can recover by
>
> $ git reset --hard
>
> While I am sympathetic, this "Oops, I said pull when I meant
> fetch" sounds remotely similar to "oops, I said 'rm -r' when I
> meant to say 'ls -r'". Is it that the tool is too fragile?
>
>
> -
> 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
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: [RFC] faking cvs annotate
From: Linus Torvalds @ 2005-12-16 17:07 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Johannes Schindelin, Junio C Hamano, Git Mailing List
In-Reply-To: <46a038f90512152037u66993aadg566a2a47abd279c9@mail.gmail.com>
On Fri, 16 Dec 2005, Martin Langhoff wrote:
>
> On 12/16/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > For starters, you could use my attempt:
> > http://www.gelato.unsw.edu.au/archives/git/0508/7171.html
>
> Not bad at all! I might simplify it a bit (won't need the commitmsg
> parsing), and see if how fast I can make it.
NOTE! You can make it a whole lot faster these days by passing the path
down to git-rev-list. But as usual, I'm perl-incompatible, so I can't help
you with that modification.
> OTOH, yours didn't get included. Any particular reasons? (other than
> stressing the point that you should use whatchanged/pickaxe?)
I'd love to see a git-annotate, but I want it to be efficient enough that
it's not embarrassing.
For example, "git-whatchanged" is certainly efficient enough, and you
could just parse that output (possible without using -p and comparing file
contents on your own against the current HEAD as you progress backwards)
Or, you could now use "git-rev-list <rev> <filename>", which is even more
efficient, but the downside of that is that it computes the _full_ graph
before it starts outputting the early ones.
But, for example:
[torvalds@g5 linux-history]$ time git-whatchanged drivers/char/Makefile > /dev/null
real 0m37.993s
user 0m41.912s
sys 0m0.400s
[torvalds@g5 linux-history]$ time git-rev-list HEAD drivers/char/Makefile > /dev/null
real 0m6.713s
user 0m6.656s
sys 0m0.056s
that's the old Linux history thing, with 60,000+ commit. The path-based
git-rev-list thing cuts it down to just 103 commits you need to look at
(so the annotate itself should be really fast, and the cost really is all
in that "git-rev-list" thing).
Of course, with the current kernel tree, the git-rev-list takes a lot less
time, and only results in six commits, but that's a tree that only has a
few months of history, so when looking at performance, you really should
look at some bigger tree.
NOTE! You can also decide to cut down on time by saying "annotate back
only to a specific date", ie something like
git-rev-list $(git-rev-parse --since=2.years.ago HEAD) drivers/char/Makefile
which limits the thing by filename _and_ date (a good way to handle really
really big projects) where the rev-parse might otherwise be very
expensive.
And, of course, a quality implementation will notice when a file
disappears, and use "git-diff-tree -M" on that commit to see if it was
renamed, and then continuing with the old name...
Linus
^ permalink raw reply
* Re: bad git pull
From: Don Zickus @ 2005-12-16 15:39 UTC (permalink / raw)
Cc: git
In-Reply-To: <7vu0d9lxx9.fsf@assigned-by-dhcp.cox.net>
> While I am sympathetic, this "Oops, I said pull when I meant
> fetch" sounds remotely similar to "oops, I said 'rm -r' when I
> meant to say 'ls -r'". Is it that the tool is too fragile?
>
Sorry, wrong choice of words. Didn't mean to imply anything negative.
Though, I am still learning the tool and its features, I do appreciate
your feedback and your last email was correct in understanding the
mess I created. I'll go read up on the differences between 'fetch'
and 'pull'.
Cheers,
Don
^ permalink raw reply
* Re: make install bug?
From: eschvoca @ 2005-12-16 15:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmn6i4kf.fsf@assigned-by-dhcp.cox.net>
You are right, CDPATH is the problem. I am no longer exporting CDPATH.
e
On 12/12/05, Junio C Hamano <junkio@cox.net> wrote:
> eschvoca <eschvoca@gmail.com> writes:
>
> > I can fix the problem by changing templates/Makefile to the following:
> >
> > install: all
> > $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(template_dir))
> > (cd blt && $(TAR) cf - . > /tmp/a.tar) | \
> > (cd $(call shellquote,$(DESTDIR)$(template_dir)) && $(TAR) xf /tmp/a.tar)
>
> Here is my guess. Could you try, from your interactive shell:
>
> $ (unset CDPATH; make install)
>
> first without the above "fix" (your "fixed" pipe does not make
> any sense --- what are the data passed between pipe upstream and
> downstream?)?
>
> If that makes the problem go away, then your environment is
> broken --- my guess is that you are exporting CDPATH to
> non-interactive scripts. Don't do that.
>
> I once googled for "CDPATH" and saw many "guide to unix" type
> webpages talk about "CDPATH environment variable"; they are the
> real culprit to cause this confusion in peoples' .bash_profile.
> CDPATH might be a nice variable for interactive shells, but is a
> horrible one if made environment.
>
>
^ permalink raw reply
* Re: [RFC] faking cvs annotate
From: Ryan Anderson @ 2005-12-16 15:05 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Martin Langhoff, git
In-Reply-To: <20051216060953.GA22150@mail.yhbt.net>
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
Eric Wong wrote:
> #!/usr/bin/env perl
> # Copyright (c) 2005, Eric Wong <normalperson@yhbt.net>
> #
> # This file is licensed under the GPL v2, or a later version
> # at the discretion of Linus.
Please use full names for this kind of authority delegation.
> # Read git-whatchanged output and let all Algorithm::Annotate do all
> # the hard work for us. Thanks to Chia-liang Kao for the awesome
> # Algorithm::Annotate module.
> #
You'll want to add libalgorithm-annotate-perl to the Debian/control
Depends: line when you submit this as a patch. (I dont' have an
RPM-based machine handy, so I can't doublecheck that.)
I was going to comment on the rest, but I don't really have time to play
with it at the moment.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* [RFC] git-fetch: Optionally store fetch information under a nick
From: Johannes Schindelin @ 2005-12-16 14:16 UTC (permalink / raw)
To: git, junkio
This is on top of my .git/remotes/* -> .git/config patch. With this, you
can do:
git pull -S junio git://git.kernel.org/pub/scm/git/git.git \
master:junio todo:todo +pu:pu
once, and after that,
git pull junio
will have the same effect.
Signed-off-by: Johannes "always off by one" Schindelin <Johannes.Schindelin@gmx.de>
---
This was what git-repo-config was all about, but I backed off a
little when I felt not much enthusiasm for remote information in
the config.
However, when I tried to get a CVS user to work *with* (as opposed
to *on*) git, he told me that he was sick of editing files, and
if there would be a more user friendly way to store the remote
information. So, I whipped this up.
Documentation/fetch-options.txt | 6 ++++++
git-fetch.sh | 16 ++++++++++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
2bbb9ef0fc8601a91f0b36ad27a7e2be09cc6e46
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 200c9b2..a1d9210 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -10,6 +10,12 @@
fetches is a descendant of `<lbranch>`. This option
overrides that check.
+-S, \--store <nick>::
+ Store the URL and the refnames in the config file so that
+ `git fetch <nick>` repeats the exercise.
+ If the nick exists already, edit the URL, but append the
+ refnames.
+
-t, \--tags::
By default, the git core utilities will not fetch and store
tags under the same name as the remote repository; ask it
diff --git a/git-fetch.sh b/git-fetch.sh
index 0a4fc98..f3f6146 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -16,6 +16,7 @@ append=
force=
verbose=
update_head_ok=
+store=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -25,6 +26,10 @@ do
-f|--f|--fo|--for|--forc|--force)
force=t
;;
+ -S|--s|--st|--sto|--stor|--store)
+ store="$2"
+ shift
+ ;;
-t|--t|--ta|--tag|--tags)
tags=t
;;
@@ -204,10 +209,21 @@ then
fi
fi
+if test "$store"
+then
+ git-repo-config remote."$store".url $remote ||
+ die "Could not store into $store"
+fi
+
for ref in $reflist
do
refs="$refs$LF$ref"
+ if test "$store"
+ then
+ git-repo-config remote."$store".pull "$ref" '^$'
+ fi
+
# These are relative path from $GIT_DIR, typically starting at refs/
# but may be HEAD
if expr "$ref" : '\.' >/dev/null
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] We do not like "HEAD" as a new branch name
From: Johannes Schindelin @ 2005-12-16 11:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xullfct.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 15 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Okay. Why not go the full nine yards, and not be difficult about it:
>
> That's fine. There is an off-by-one in your code, though.
> I've committed it with a tweak.
Thanks. I did test it (quickly), and t3300 said it was fine. Strange.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] [COGITO] make cg-tag use git-check-ref-format
From: Petr Baudis @ 2005-12-16 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7virtplr9s.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Dec 16, 2005 at 03:17:19AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Junio C Hamano <junkio@cox.net> writes:
>
> > The wildcard letters like ? and * I understand and sympathetic
> > about somewhat. Something like this:
> >
> > name="*.sh" ;# this also comes from the end user
> > echo $name
> >
> > ends up showing every shell script in the current directory,
> > and not literal '*.sh'.
>
> So why don't we do this?
I'm all for it, and now I also agree that forbidding \'" is pointless.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* allow only a strictly defined set of references under .git/
From: Alex Riesen @ 2005-12-16 8:24 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]
The patch below reminded me of something:
+ /* We want to allow .git/description file and
+ * "description" branch to exist at the same time.
+ * "git-rev-parse description" should silently skip
+ * .git/description file as a candidate for
+ * get_sha1(). However, having garbage file anywhere
+ * under refs/ is not OK, and we would not have caught
+ * ambiguous heads and tags with the above test.
+ */
+ else if (**p && !access(pathname, F_OK)) {
+ /* Garbage exists under .git/refs */
+ return error("garbage ref found '%s'", pathname);
+ }
Maybe we should only allow only a strictly defined set of refnames
under $GIT_DIR? The directory is used pretty much for anything else
(temporary message files, config, description).
So, if we, say, allow only HEAD, ORIG_HEAD, and MERGE_HEAD to be
references in .git/ and ignore everything else. Then there will be no
ambiguity anymore and no need to parse "description" or "config"
reference (besides, I can very simply imagine a message file
containing "ref: refs/heads/foo").
Does it make sense or have I missed some very informative discussion
as to why we do allow references to be anywhere in .git?
[-- Attachment #2: 0001-The-patch-below-reminded-me-of-something.txt --]
[-- Type: text/plain, Size: 2395 bytes --]
Subject: [PATCH] The patch below reminded me of something:
+ /* We want to allow .git/description file and
+ * "description" branch to exist at the same time.
+ * "git-rev-parse description" should silently skip
+ * .git/description file as a candidate for
+ * get_sha1(). However, having garbage file anywhere
+ * under refs/ is not OK, and we would not have caught
+ * ambiguous heads and tags with the above test.
+ */
+ else if (**p && !access(pathname, F_OK)) {
+ /* Garbage exists under .git/refs */
+ return error("garbage ref found '%s'", pathname);
+ }
Maybe we should only allow only a strictly defined set of refnames under $GIT_DIR? The directory is used pretty much for anything else (temporary message files, config, description).
So, if we, say, allow only HEAD, ORIG_HEAD, and MERGE_HEAD to be references in .git/ and ignore everything else. Then there will be no ambiguity anymore and no need to parse "description" or "config" reference (besides, I can very simply imagine a message file containing "ref: refs/heads/foo").
Does it make sense or have I missed some very informative discussion as to why we do allow references to be anywhere in .git?
---
sha1_name.c | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
4a0ef1ed775d2311da7125257cb734d561fd2ef1
diff --git a/sha1_name.c b/sha1_name.c
index bf8f0f0..dce1574 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -247,7 +247,27 @@ static int get_sha1_basic(const char *st
if (ambiguous_path(str, len))
return -1;
- for (p = prefix; *p; p++) {
+ p = prefix;
+ /* Check references _without_ leading directories */
+ if (!memchr(str, '/', len)) {
+ /* only these references can be directly in $GIT_DIR... */
+ static const char *git_refs[] = {
+ "HEAD",
+ "ORIG_HEAD",
+ "FETCH_HEAD",
+ "MERGE_HEAD",
+ NULL
+ };
+ const char **r;
+ for (r = git_refs; *r; ++r)
+ if (strlen(*r) == len && strncmp(*r, str, len) == 0)
+ break;
+ /* ...all the others have to be somewhere under .git/refs/ */
+ if ( !*r )
+ ++p;
+ }
+
+ for (; *p; p++) {
char *pathname = git_path("%s/%.*s", *p, len, str);
if (!read_ref(pathname, sha1)) {
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] We do not like "HEAD" as a new branch name
From: Junio C Hamano @ 2005-12-16 6:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512160238300.6530@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Okay. Why not go the full nine yards, and not be difficult about it:
That's fine. There is an off-by-one in your code, though.
I've committed it with a tweak.
^ permalink raw reply
* Re: [RFC] faking cvs annotate
From: Eric Wong @ 2005-12-16 6:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git
In-Reply-To: <7vpsnxlsw7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Martin Langhoff <martin.langhoff@gmail.com> writes:
>
> > Suggestions of GIT machinery that would shortcut the trip from
> >
> > git-rev-list HEAD $path
> >
> > to a annotate-ish output. Did I dream it or is qgit showing something
> > annotate-ish in its screenshots?
>
> I haven't actively done anything but one of the good things that
> could happen is to split out the access routines for annotate
> database qgit build when run the first time in the repository,
> and make them available to other Porcelains. There is no need
> to reinvent the wheel.
I started working on something using Algorithm::Annotate on CPAN during
an ADD excursion a few weeks ago, but mostly forgot about it (thanks
again to ADD :). A few versions of git later and it still seems to
work as well as I remembered it.
It doesn't handle renames/copies yet, but it does let you customize the
left-hand side output unlike most/(all?) annotate implementations.
I guess it's also quite useful when the output is piped to vim with a
repository browser like the one I brought up in
<20051124093322.GA3899@mail.yhbt.net>
---------- 8< ---------
#!/usr/bin/env perl
# Copyright (c) 2005, Eric Wong <normalperson@yhbt.net>
#
# This file is licensed under the GPL v2, or a later version
# at the discretion of Linus.
#
# Read git-whatchanged output and let all Algorithm::Annotate do all
# the hard work for us. Thanks to Chia-liang Kao for the awesome
# Algorithm::Annotate module.
#
# Formatting options of annotation output is available.
# Dates can be formatted through strftime strings using the -D switch,
# and annotation expansion can be done using the -F switch
# on following variables:
=cut
%commit% %tree% %author_name% %author_email% %author_date%
%committer_name% %committer_email% %commit_date% %message%
=cut
use warnings;
use strict;
sub usage ($) {
print '* git-annotate ',
'[-w <width>] [-D <date-format>] [-F <annotate-format>] ',
'[--localtime] [--line-prefix <str>] [--line-postfix <str>] ',
'<file>', "\n";
exit $_[0];
}
# everybody with Perl 5 should have these, right?
use POSIX qw(strftime);
use Getopt::Long qw(:config gnu_getopt no_ignore_case no_auto_abbrev);
my %_o; # options
usage(1) unless (GetOptions(\%_o, qw(help|H|h width|w=i
line_prefix|line-prefix:s line_postfix|line-postfix:s
format|F=s date_format|date-format|D=s localtime|l)));
usage(0) if $_o{help};
# ok, see if we can do more than show a help message:
require Algorithm::Annotate or die
"Can't find Algorithm::Annotate, get it from CPAN ($!)\n";
my $file = shift or usage(1);
unless (-f $file) {
print STDERR "File does not exist or is not a file: $file\n";
exit 1;
}
my $date_format = $_o{date_format} || '%Y-%m-%dT%H-%M-%SZ'; # ISO 8601
my $re_sha1 = qr/[a-f0-9]{40}/; # match 40 char hex strings
my @blobs; # we read from newest to oldest, but $ann needs it reversed
sub t ($) {
return localtime($_[0]) if $_o{'localtime'};
return gmtime($_[0]);
}
if (my $pid = open my $child, '-|') {
my $meta;
while (<$child>) {
chomp;
if (/^diff-tree ($re_sha1) /o) {
$meta = { commit => $1, message => [] };
} elsif (/^tree ($re_sha1)$/) {
$meta->{tree} = $1;
} elsif (/^author (.*) <(\S+)> (\d+) [\+\-]?\d+$/) {
$meta->{author_name} = $1;
$meta->{author_email} = $2;
$meta->{author} = "$1 <$2>";
$meta->{author_date} = strftime($date_format, t($3));
} elsif (/^committer (.*) <(\S+)> (\d+) [\+\-]?\d+$/) {
$meta->{committer_name} = $1;
$meta->{committer_email} = $2;
$meta->{committer} = "$1 <$2>";
$meta->{commit_date} = strftime($date_format, t($3));
} elsif (/^\s{4}(.*)$/) {
push @{$meta->{message}}, $1;
} elsif (/^:\d{6} \d{6} $re_sha1 ($re_sha1)/o) {
my $blob = $1;
if ($blob =~ /^0{40}$/) {
# nonexistent (hopefully!) blob
$meta = undef;
next;
}
$meta->{message} = join("\n",@{$meta->{message}});
push @blobs, { meta => $meta, blob => $blob };
$meta = undef;
}
}
} else {
exec('git-whatchanged','-m','--pretty=raw','--',$file) or die
"Unable to execute git-whatchanged $file: $? $!";
}
my $msg_format = $_o{format} || '%commit% %commit_date%';
my $max_len = 0;
my $ann = Algorithm::Annotate->new;
foreach my $x (reverse @blobs) {
my @contents;
# no need to do safe pipe opens since we know $x->{blob} is a hex sum
@contents = `git-cat-file blob $x->{blob}`;
# $msg is the left hand side of our final annotation output,
# format it according to $msg_format
my $msg = $msg_format;
my $meta = $x->{meta};
# our annotation message templating engine:
$msg =~ s/\%$_\%/$meta->{$_}/g foreach keys %$meta;
$msg =~ s/\\t/\t/g;
$msg =~ s/\\n/\n/g;
$ann->add($msg, \@contents);
if ($msg !~ /\n/) {
$max_len = length $msg if length $msg > $max_len;
} else {
foreach (split /\n/, $msg) {
$max_len = length $_ if length $_ > $max_len;
}
}
}
# see if we can annotate local changes, too
my $local_change;
my @diff_opts = qw(-z -C --find-copies-harder --name-only);
{ # see if we've changed $file in the working tree
if (my $pid = open my $child, '-|') {
$local_change = (<$child>);
} else {
exec('git-diff-files',@diff_opts,'--',$file);
}
}
unless ($local_change) {
# see if we've changed $file in the working tree
if (my $pid = open my $child, '-|') {
$local_change = (<$child>);
} else {
exec('git-diff-index',@diff_opts,'--cached','HEAD','--',$file);
}
}
open my $fd,'<',$file or die "Error opening file: $file: $!\n";
my @contents = <$fd>;
if ($local_change) {
my $msg = '(uncommitted): ';
$ann->add($msg, \@contents);
$max_len = length $msg if length $msg > $max_len;
}
# $result here is an array ref, each element corresponding to a line of
# the annotated file contents
my $result = $ann->result or do {
print STDERR "Unable to annotate $file. Is it tracked by git?\n";
exit 1;
};
my $pre = defined $_o{line_prefix} ? $_o{line_prefix} : '';
my $post = defined $_o{line_postfix} ? $_o{line_postfix} : ': ';
my $width = $_o{width} || $max_len;
foreach (@contents) {
my $msg = shift @$result;
if ($msg !~ /\n/) {
print ($pre, pack("A$width", $msg), $post, $_);
} else {
my @msgs = split /\n/, $msg;
print ($pre, pack("A$width", shift @msgs), $post, $_);
foreach my $m (@msgs) {
print ($pre, pack("A$width", $m), $post,"\n");
}
}
}
close $fd;
exit 0;
--
Eric Wong
^ permalink raw reply
* Re: [RFC] faking cvs annotate
From: Martin Langhoff @ 2005-12-16 4:37 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0512160229140.6323@wbgn013.biozentrum.uni-wuerzburg.de>
On 12/16/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> For starters, you could use my attempt:
> http://www.gelato.unsw.edu.au/archives/git/0508/7171.html
Not bad at all! I might simplify it a bit (won't need the commitmsg
parsing), and see if how fast I can make it.
> It does not fool any CVS user,
Ah, no. Those have been fooled already ;-)
> However, I learnt to use git-whatchanged in the meantime, and I'll
> probably never go back.
Of course. I'm trying to meet a few the expectations of popular cvs
clients (cli, TortoiseCVS, Eclipse, etc). If a workable git-annotate
falls out of this, oh well.
OTOH, yours didn't get included. Any particular reasons? (other than
stressing the point that you should use whatchanged/pickaxe?)
Also! On 12/16/05, Junio C Hamano <junkio@cox.net> wrote:
> I haven't actively done anything but one of the good things that
> could happen is to split out the access routines for annotate
> database qgit build when run the first time in the repository,
> and make them available to other Porcelains. There is no need
> to reinvent the wheel.
That would be cool! Though my particular implementation may be a tad
unconventional in its view of the "file history" as a strictly linear
thing. Normal git porcelains don't even blink when dealing with
branching/merging development histories.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] [COGITO] make cg-tag use git-check-ref-format
From: Junio C Hamano @ 2005-12-16 2:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: Alex Riesen, git
In-Reply-To: <7vacf2lyn4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> The wildcard letters like ? and * I understand and sympathetic
> about somewhat. Something like this:
>
> name="*.sh" ;# this also comes from the end user
> echo $name
>
> ends up showing every shell script in the current directory,
> and not literal '*.sh'.
So why don't we do this?
-- >8 --
Subject: [PATCH] Forbid pattern maching characters in refnames.
by marking '?', '*', and '[' as bad_ref_char().
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-check-ref-format.txt | 8 +++++---
refs.c | 4 +++-
2 files changed, 8 insertions(+), 4 deletions(-)
d04ec25a77249095b6d2af5a08fe131351f2d86d
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 636e951..f7f84c6 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -26,13 +26,15 @@ imposes the following rules on how refs
. It cannot have ASCII control character (i.e. bytes whose
values are lower than \040, or \177 `DEL`), space, tilde `~`,
- caret `{caret}`, or colon `:` anywhere;
+ caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
+ or open bracket `[` anywhere;
. It cannot end with a slash `/`.
These rules makes it easy for shell script based tools to parse
-refnames, and also avoids ambiguities in certain refname
-expressions (see gitlink:git-rev-parse[1]). Namely:
+refnames, pathname expansion by the shell when a refname is used
+unquoted (by mistake), and also avoids ambiguities in certain
+refname expressions (see gitlink:git-rev-parse[1]). Namely:
. double-dot `..` are often used as in `ref1..ref2`, and in some
context this notation means `{caret}ref1 ref2` (i.e. not in
diff --git a/refs.c b/refs.c
index b8fcb98..0d63c1f 100644
--- a/refs.c
+++ b/refs.c
@@ -313,7 +313,9 @@ int write_ref_sha1(const char *ref, int
static inline int bad_ref_char(int ch)
{
return (((unsigned) ch) <= ' ' ||
- ch == '~' || ch == '^' || ch == ':');
+ ch == '~' || ch == '^' || ch == ':' ||
+ /* 2.13 Pattern Matching Notation */
+ ch == '?' || ch == '*' || ch == '[');
}
int check_ref_format(const char *ref)
--
0.99.9.GIT
^ 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