I think the trick with Git-side filename globbing is important and perhaps not that well know. Clarify a bit in git-add documentation what it means. Signed-off-by: Petr Baudis <pasky@suse.cz> --- Documentation/git-add.txt | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index e5efbc9..2fe7355 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -33,9 +33,9 @@ files have changes that ...

For one of my projects I've been using 'svnversion' to automatically generate a 'build number' to include in the version string of the project. 'svnversion' will output the revision of the current checkout, possibly with an 'M' appended if you've made local modifications. This obviously wont work if you have a git-svn repository instead of an svn checkout. This patch adds this behaviour to git-svn find-rev, so 'git-svn find-rev HEAD' should be usable instead of 'svnversion'. Previously ...

I thought modern file-level merge added comments on where things came from on <<< and >>> lines. Insisting on /^={7}$/ might be I would usually say "Don't. If you want to have clean-up patches, do them as separate patches, please", here. This is especially true if your primary point of the patch is sound but "Other changes" are questionable --- you do not want a good fix Ok, but I can see you haven't even tested this patch with one of the warn that supposedly has three strings as ...

This is what we do at work. We're 3-6 developers on each project, and each of us have our own branch, into which we merge our topic-branches. Someone is then designated integrator of the project, and responsible for merging branches or cherrypicking commits into master. In our case, we use 'testing' rather than 'master', to denote that the test-department should take over and try out all the features/fixes we've added. The test-team only ever gets email when something ends up on their ...

See below. Using stg with git commit --amend creates big problems, yet stg has no way (?) to alter commit descriptions. Any advice? Thanks -- Andy [agrover@sitar git]$ stg version Stacked GIT 0.12.1 git version 1.5.2.4 Python version 2.5 (r25:51908, Apr 10 2007, 10:27:40) [GCC 4.1.2 20070403 (Red Hat 4.1.2-8)] [agrover@sitar git]$ stg clone linux-2.6/ stg-smp Cloning "linux-2.6/" into "stg-smp"... Initialized empty Git repository in /home/agrover/git/stg-smp/.git/ remote: Generating ...

From http://en.wikipedia.org/wiki/Transport_Secure_Layer (emphasizis in the form of capital letters mine) TLS provides endpoint authentication and communications privacy over the Internet using cryptography. Typically, only the server is authenticated (i.e., its identity is ensured) while the client remains unauthenticated; this means that the end user (whether an individual or an application, such as a Web browser) can be sure with whom they are communicating. The next level of ...

I added the escapes, I'm just getting confused about when I need to escape and not escape in gitweb. It is not consistent everywhere. The -- Jon Smirl jonsmirl@gmail.com -

I tried adding an email address to hometext.html yesterday, I got the same XML errors caused by the <> that I received in the project owner -- Jon Smirl jonsmirl@gmail.com -

Actually it is _different_ problem, because while projects list file is meant to be *plain text* file with two space separated, URL-encoded strings per line, hometext.html (and header.html, gooter.html and per repository README.html) is meant as a *fragment* to insert on gitweb page, and of course it should follow the same syntax as main gitweb page. Which might be HTML, or might be XHTML. So if you need something which needs escaping, do this in hometext.html. -- Jakub ...

When cloning an existing repository, is there any way to grab the .git/hooks files as part of the clone (or pull)? -JE -

Thanks Petr. I think I'll look at using the git clone --template functionality and just keep my own templates around. -JE -

I assume you have "Show nearby tags" turned off. I'll fix it, but in the short term you can work around it by turning "Show nearby tags" on. Paul. -

is a _good_ compromise. It just was that it would make it even _better_ compromise if we can demonstrate that the above setting would work equally well with other programs. -

Huh? It could execute arbitrary code, like an editor. Which is the whole point of the variable. What you might be thinking of is that it might execute material which has a non-local impact on the calling environment. If that is your concern, just wrap the eval inside of parens, like (eval ...). But frankly: setuid shell scripts are a security hole fit to drive a truck through, anyway. One does not need eval for that. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -

Interesting, this uses eval: git_editor() { : "${GIT_EDITOR:=$(git config core.editor)}" : "${GIT_EDITOR:=${VISUAL:-${EDITOR}}}" [...] eval "${GIT_EDITOR:=vi}" '"$@"' } I was told eval was "wrong on multiple levels". Bill -

>>>>> "Bill" == Bill Lear <rael@zopyra.com> writes: Bill> I was told eval was "wrong on multiple levels". I should elaborate. Using "eval" here means that you *then* have to be careful about whitespace quoting. For example, if my $HOME had a space in it, EDITOR="$HOME/bin/superemacs" would be broken if you add the extra eval, since the whitespace would be treated as a delimeter on the second lexing. I'd have to figure out how to set EDITOR with the right quotes or backwhacks in it ...

You can't have both the ability to use a command with options as well as an unquoted command with spaces in its path. It is rather glaringly obvious. A space is a space is a space. Without a way of quoting it, the argument splitting space is the same the path-contained one. If you do something like woozle='"a b c"' set $woozle echo $1 echo $2 echo $3 you get "a b c" Quotes don't get reinterpreted. At this level, only IFS-splitting If you are lucky. There is also the ...

It's not clear to me how this ever would have worked. Programs *can* execute $EDITOR with system(3), but it's possible they could execute it with exec, in which case the binary "~/bin/xemacs -nw" definitely would not be found. The right solution to this IMO is to do both of the following: (1) Create a shell script ~/bin/xemacs-nox that contains #! /bin/bash xemacs -nw "$@" (2) Set the editor to EDITOR=~/bin/xemacs-nox Note the distinct LACK of double quotes around the value, which ...

>>>>> "Bill" == Bill Lear <rael@zopyra.com> writes: Bill> Of course, and one could use a full path also, but tilde is a Bill> perfectly valid replacement for $HOME, Only to a shell. The kernel has no clue about it. I'd even say "only to *some* shells" as well, but most modern shells now understand it. Bill> and I think git should support Bill> it, and not force the user to work around it. The eval solution is wrong on multiple levels. -- Randal L. Schwartz - Stonehenge Consulting ...

Of course, and one could use a full path also, but tilde is a perfectly valid replacement for $HOME, and I think git should support it, and not force the user to work around it. Bill -

EDITOR=~/bin/xemacs\ -nw No need for the script. -

C does not have tilde expansion or "eval", but it has "system()": int main () { system("~/bin/scripts/moy-editor.sh foo.txt"); } works as you'd expect. -- Matthieu -

This one is not a good argument. If you write this: export EDITOR=~/bin/emacs the shell does the tilde expansion, and git doesn't have to worry I just checked, and at least less, svn, cvs and mutt do the tilde expansion themselves (the way you expect). To me, that is an argument: if a setup works with most unix-ish tools, it should work for git too. Now, for the good news: with the latest git, it just works! commit 08874658b450600e72bb7cb0d0747c1ec4b0bfe1 Author: David Kastrup ...

Ah, yeah, sorry. Apparently, I've already worked too much today. ;-) -- Petr "Pasky" Baudis Early to rise and early to bed makes a male healthy and wealthy and dead. -- James Thurber -

That your point is wrong. Shell will perform word splitting after variable expansion. But it will perform variable expansion after tilde expansion, and that's the trouble. -- Petr "Pasky" Baudis Early to rise and early to bed makes a male healthy and wealthy and dead. -- James Thurber -

Your point being ? Mike -

You then are apparently mistaken in your reasoning. 1) It was definitely not quoted; 2) the EDITOR setting was as I said; and 3) the error message came out exactly as I said. Bill -

Well it is certainly valid to a user to set their EDITOR in that way, both in bash and zsh, so "only to a shell" is false, not even considering that he works with this every day with plenty of other tools, and has not seen a problem with them. I do notice that cvs pukes on this, however: % cd bin % ln -s /usr/bin/vim vingo % cd ~/testo % EDITOR="~/bin/vingo -C" % cvs commit cvs commit: cannot exec ~/bin/vingo: No such file or directory Fine with me: that's why I brought it up and asked ...

Is there a fast and easy way to find out which of a set of SHA1 ids refer to commits that (still) exist in a repository? This is for use in gitk and there could be several ids, so I'd prefer to avoid a fork/exec per id. I could do a git cat-file -t $id for each id, but that's a fork/exec per id. git rev-parse doesn't check whether an id actually refers to an existing commit, so it isn't the answer. What I want to be able to do is to cache the condensed topology information that gitk uses ...

Assuming you have a completely random set of ids, I think the easiest way to do it would be to extend git-cat-file to accept several ids I'm assuming you will still have to do git-rev-list to get the new commits since the last known location of a branch head. If so, git rev-list <bogus-sha1>..<rewound-branch-tip> should be enough to tell you you need to re-read that branch's entire history. I just got up though, and since I don't drink coffee, waking up is a lengthy process for me. -- ...

Sorry but I fail to see the reason why you would have to move or delete the git tag if there are commits under a tags directory. I assume that your reasoning is that otherwise checking out the tag from svn and checking out the tag from git would give different results, but that's the reason for having the tags/tagname branch, not for shuffling the git tag around. -- Giuseppe "Oblomov" Bilotta -

Well, because it's the behaviour that the repository owner is indicating. Just like in git if you have a tag you don't like, you can delete it and re-create it, I think that's what we should do. The new version of the tag would point to the new head of the tags/tagname branch. But until that re-writing of the tag happens, the branch doesn't need to exist as it introduces no new commits. Sam. -

Hi, When running `git-p4 rebase` from a subdirectory of the main repository, I get: fatal: cannot locate git repository foo/.git even though the path reported as `foo` is the correct path to the main repository. This is with git 1.5.0.3, running on Windows/cygwin with a recent version of git-p4. - Reece -

Wincent Colaiuta wrote: > El 28/8/2007, a las 13:02, Florian Weimer escribi

> > Does the filesystem compare '

Hi, The problem is _really_ the filesystem, as you experienced. You just cannot do an "mv foo Foo". You cannot. And that is _exactly_ the problem you experience with git, since at some point, git tries exactly that: "mv foo Foo". So it really, really, really is not a git problem. Just as I told you in my other reply. Ciao, Dscho -

Hi, What did you expect? A regular "mv foo Foo" does not work either! So it is not like this is a bug in git, but in your setup. Ciao, Dscho -

El 28/8/2007, a las 16:07, Andreas Ericsson escribi

Those two are actually known to be different. "ß" and "SS" would be harder: when words are ambiguous like "Masse" ("mass") against "Maße" ("measures"), the capitalization is actually allowed to turn "ß" into Those are different. The problem is "STRASSE" vs "straße" (identical). Things become even more fun in Turkish: "i" and "I" are _different_ letters not just because of case: the uppercase version of "i" actually is "İ", and the lowercase version of "I" is "ı". So what do you do with ...

El 28/8/2007, a las 22:45, Johannes Schindelin escribi

Hi, It is right that they support it. But since the _default_ is case insensitive (but only as long as it is not _reporting_ file names), it is _as bad_ as "doesn't even have a case sensitive filesystem". No sophistry helps here. Ciao, Dscho -

But without case sensitivity in the tracker there's no way "mv foo Foo" Yes, because then you give the filesystem some leeway in that it doesn't have to create two files with conflicting hash entries. And that's the hoop, I suspect. Some really insane filesystems have the odd ability to report case sensitively while not actually supporting it (VFAT, I think, displays this absurd capability). Either way, the tools manipulating the file- True. What happens when you "git mv -f foo ...

If you rename 'foo' to 'Foo' in the index, the filesystem will still say it has 'foo' in the working directory. You could ofcourse rename it in the index, delete it from the working directory and then check it out from the index under the new name, but that means there'll be a short time during which the file is deleted. That doesn't feel entirely safe to me. Better then to do something like git_rename("foo", "Foo"); if (src_and_dst_are_same) { git_rename ("foo", "foo1"); git_rename ...

It needs to be dealt with either in the filesystem implementation (kernel level), or in the library providing the interface to the kernel calls. If it's done in the application, code duplication will be ridiculous, and application behaviour will be inconsistent. If it's done in the library, there'll possibly be an extra cmp+branch each time someone tries to move a file to a destination that already exists. It doesn't happen *that* often, so the extra overhead might be acceptable. The ...

Hi, If you are using git-p4 on Windows, with a Linux-based Perforce server, clone/rebase for a changelist containing: p4 integrate foo Foo p4 delete foo (i.e. move foo Foo) ends up deleting the file in question, so it is no longer contained in the git repository. This may be a core git issue (which I am going to raise as a separate issue), but I don't yet understand git-p4 enough to say for sure. - Reece -

OK, thanks for the explanation. I will keep hashing it out with Dscho, and see if we have something useful for post-1.5.3. -Peff -

Will do the final rc for 1.5.3 hopefully tomorrow night or Wednesday at the latest. Honest. Promise. Unless the late last minute "fixes" break other things, that is. ---------------------------------------------------------------- * The 'master' branch has these since the last announcement in addition to the above. Brian Hetro (5): Documentation: For consistency, use CVS instead of cvs. Documentation: Correct various misspellings and typos. Make usage documentation for git-am ...

Ok, this is hopefully the last time I reply to myself. I'm inlining the quick'n'dirty patch I've whipped up, hoping that gmail doesn't destroy it too much.. -- Giuseppe "Oblomov" Bilotta --- gitweb.cgi 2007-08-26 12:41:13.000000000 +0200 +++ gitweb.cgi-my 2007-08-28 13:47:15.000000000 +0200 @@ -1667,7 +1667,7 @@ sub git_get_heads_list { open my $fd, '-|', git_cmd(), 'for-each-ref', ($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate', '--format=%(objectname) %(refname) ...

Hi, I agree that sorting by topic is easier to read. Rarely do you look up the meaning of an option you know, but you look up an option for a meaning. And when looking for "-m" in the man page, why not use the pager's search function? Ciao, Dscho -

It sounds like you could use the following strategy: Have a primary Development branch. When a developer needs to add a feature, he forks a "topic branch" from Development, and implements the feature. When the feature is complete and tested, the topic branch is merged back into Development. Since forking and merging is one of git's strengths, it should be quite possible to have multiple "topic branches" in progress at any one time, obviously modulo interdependencies. Once the ...

Yeah, that makes a lot of sense. If there were a lot of files git-add would have taken a lot of time in prior versions, before that O(n^2) bug was fixed. Thanks for retesting. -- Shawn. -

fast-import will also accept the shorter (perhaps more common) form: This might be more clear as: print $fi "data $len\n"; -- Shawn. -

I'm not sure this really warrants C. Just a language that is able to do lots of file IO, avoids forks to do it, and is also simple enough that most readers could follow it. Your shell script fits all byt the "avoids forks" part. Anyone who seriously needs the Uhhh. That's not very good. How many files? What was their average size? What was the size of the largest file? Binary? Text? We should be able to handle this. The fact that it killed your system means we should ...

It may also have to do with the large amount of data going over a pipe, as well as the fact that we have to write the data into the packfile then go back and reread all of it to compute the SHA-1 of the entire thing. That's a lot of IO, all going through your poor Yea, so like the parallel pack-objects experiment that Nico had done recently we decreased wall-clock time at the expense of using a larger amount of the system resources. That is bad as we use more CPU time than we saved in ...

Right. Now that fast-import has a 'progress' command in its stream language it may be possible to let it read from raw files in the UNIX filesystem. I almost implemented this a while ago but realized it wasn't very useful because the frontend couldn't tell when fast-import was done reading from the file. With 'progress' That doesn't surprise me. It would be very hard to beat `git-add .`. Where fast-import usually wins is avoiding many fork+exec if you are doing many individual commits. ...

Tested again. Core git runs fine. It must have been O(n^2) bug that has been fixed in -rc3. So the script is educational only. -- Duy -

"remain"? Things don't need to stay the same. Most (but not necessarily all) Subversion tags presumably start out as "tags", top level trunk copies, and then "just a final fix" gets in at some point of time. Of course, one can also "tag" off branches, or of subdirectories or whatever in Subversion. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -

On both Mac OS X and Windows (Cygwin and MSYS) Tcl/Tk has a native look and feel. I don't have git-gui looking completely like a native Mac OS X application, but it is close enough that its fine for its current state of development. On Windows it fits in alongside the rest of the c**p^H^H^H^Hawesome programs on that platform. git-gui only looks horrible on UNIX X11, where Tk has just not gotten the level of UI improvement that it has on Mac OS X and Windows. I'm waiting for Tk 8.5 where the ...

Ahh. That is the thing I was looking for. side-note: strbuf.h should also be used in populate_from_stdin (which is currently O(n^2) because of a linear increment + xrealloc), and I guess run-command.h can be used in spawn_prog regardless of my patch, isn't it? Thanks for your help, -- Matthieu -

git-diff accepts range looking syntax that was not yet documented, and that is the very opposite of what is described in git-rev-parse. Signed-off-by: Mike Hommey <mh@glandium.org> --- Documentation/git-diff.txt | 32 ++++++++++++++++++++++++++++++-- 1 files changed, 30 insertions(+), 2 deletions(-) diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index b36e705..dcb103e 100644 --- a/Documentation/git-diff.txt +++ b/Documentation/git-diff.txt @@ -43,9 +43,22 @@ tree ...

Heh, deep magic ;-). Essentially, the traditional "single commit" behaviour is implemented as a special case that - has one and only one positive ref specified on the command line; - without -$count (or -n $count). Everything else uses the usual revision range parsing machinery, including the case you specify the same ref twice redundantly on the command line in duplicates. Even that counts as "not just one positive ref on the command line" and triggers the usual revision range ...

Maybe the last sentence should be omitted? The fact that sometimes you need to specify --root is pretty well hidden as a plumbing-level option up until now, so what --root does is largely an impleementation detail that the average user doesn't need to know and would probably confuse him/her deeply anyway. (i.e., it's needed by git-diff-tree, but it's not needed by git-diff.) BTW, I'm probably missing some history here, but why isn't --root/rev->show_root_diff=1 the default? Why do we ...

I'm not so sure that what you do with a connection is a relevant part of a URL. What about this: $ ssh somehost mycommand If I wrote that as a URL should it be mycommand+ssh://somehost/ ? Obviously not. The protocol part tells you how to talk, not what you should be done with it. The very fact that the first thing git does is run git-daemon (or whatever) demonstrates that you are talking "ssh" protocol _not_ "git+ssh" protocol. Andy -- Dr Andy Parkins, M Eng ...

Hi, It _is_ hard, if you want to keep any kind of safe permissions. Think Nope: for b in $(git ls-remote /that/other/repo | sed "s/^[^ ]* //") do git push /that/other/repo :$b done Ciao, Dscho -

What would be the use of that (outside of gitweb) ? skimo -

It isn't fetch-only since 4b3b1e1e488fe83a8a889ff26cf88355692b6a8c (though you have to enable it with a config option). -Peff -

Hi, Sorry for not mentioning it, but IMHO it does not really matter for this discussion, or does it? Ciao, Dscho -

Sorry, I have not been keeping up with this thread, so I may be confused. But I thought you were saying that there is no point to git-daemon over TLS, since git-daemon is purely for fetching public data. My point is that it's not, and thus there might be some value to it (though really, I would have no interest in implementing it -- its functionality would be a duplicate of git over ssh, which works fine). -Peff -

Hi, I actually *don't* want any objects to go ever away from a project. I just have no idea how to prevent it but still have some sane packing behaviour. I've been already thinking about this few years ago and even ended up with some patches in progress, but never finished them... (What I've found in my IRC logs:) 22:03 < pasky> I do run git repack -a -d but as far as I understand, that should be fine 22:03 < gitster> Huh? "repack -a -d" within git.git? 22:04 < gitster> What ...

There is still the question though - "located by _whom_?" IMHO, the answer to that question determines the _different contexts_ for these URLs. When I'm specifying a URL on a git command line (e.g. "git clone /url/to/some/repo"), it does seem redundant to say the least to have to always prefix the underlying protocol with "git+". (I think Linus had a good point here, in that if we were to say "git clone git+ssh://...", we should also say "git clone git+rsync://..." etc. for ...

This has been discussed before, and it wouldn't be *that* hard to have "git clone --shared" create a backpointer from B to A, so that "git-prune" could also search the B's refs and not prune anything that Why don't you even allow people to push into A? That should be This is morally the same, but it makes the hardlink step easier (only one pack to link from A to B), and by using git-gc mit makes it conceptually easier for people to understand what's going on. git --git-dir=A gc ln ...

Huh? Do you think a URL "http:" ceases to be a URL if there is It doesn't to me. Not least of all because rsync does not work using URLs to start with. Can all of the U-is-Universal-flouting people read the manual pages of the utilities they are advertising? It would make the discussion less surreal. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -

For the hypothetical (planned?) future '--recurse-submodules' option to git-diff family, git-ls-tree and git-ls-files, git-fetch and git-push (but I think not git-pull), perhaps git-log (besides what it supports by the way of git-diff-tree), maybe even git-status and git-commit. Gitweb support is a special case of git-ls-tree support, of sorts. BTW I think this would need complementing "lightweight checkout" support, i.e. core.gitdir (overrideable by GIT_DIR and --git-dir) and ...

Hi, Hehe, I was a little confused by your answer... I guess I did not respond Happily, file properties as well hidden as these have _no_ _place_ in source code that needs to be tracked. Ciao, Dscho -

But you're restricting your statements to tidy, sane code bases. Are there any particular reasons that git shouldn't be able to track insane code bases, with attributes etc? It sure would shut up a whole load of people. Sam. -

On Sat, Aug 25, 2007 at 08:10:05AM CEST, Junio C Hamano wrote: > V

>> V

Yes, I am beginning to think this is getting very complex for a problem that really hasn't proven itself to be worth considering. Sure, I suppose name-rev is a little bit of a memory hog, but running Uwe's tests only consumed about 17M even on my static implementation. That really isn't enough to worry about. I still prefer my implementation to the MERGE_TRAVERSAL_WEIGHT, but that is perhaps a matter of preference. With mine, you could plug in comparators to tweak the names (e.g., number of ...

Hello Johannes, That's what I meant. I only want to make a statement like: If you want feature xy, you need to update to at least v2.6.22-rc1. I didn't think deeply about it, but there was a similar discussion for git describe which implied counting refs on all paths leading to a given tag. It might be different here, as we look in the other direction. Best regards Uwe -- Uwe Kleine-K

Hi, The problem is: what is oldest? We cannot rely on the timestamps. And doing the naive thing -- counting edges in the commit graph (in effect using a weighting of 1) -- ends up in ugly names such as tags/v2.6.22-rc1~1^2^2^2~11^2~13^2~8^2~1^3~5 Besides, you successfully hid from yours truly what your hypothetic flag should accomplish. Ciao, Dscho -

On Tue, Aug 28, 2007 at 11:17:19AM +0200, Uwe Kleine-K

Can't that number get stale if the pointed-to rev_name improves? That is, if I have named a rev "foo~20^2~5", and another rev points at it with "^2~30", then in the second rev we know that the number of merge traversals is 2. But what if foo~20^2~5 is actually "bar", and when we process the "bar" ref, our merge traversal number _should_ shrink to 1. But it won't, since when we're processing the pointed-to rev, we don't know which commits point to it. I have a feeling we would eventually hit ...

That's a clever trick, and I think it should work in most cases as long as there are fewer than 65535 generations (though I haven't really thought hard about it). Here's my alternate approach which builds a stack of merge traversals, and let's you compare two stacks (it uses the same criteria as the original, but now we have the other generational information accessible for comparison). It comes up with the answer Uwe expects for his problem commit, and I think in general is the "right" ...

Hi, Well, we could actually do the correct thing, and not have a fifo, but a Fibonacci heap, so that we traverse the commits by cost. Then there Most comparisons (I guess) would be relatively cheap, since the traversals alone would suffice, and most of the others would be relatively short. But I really wonder now if it is not just easier to increase MERGE_TRAVERSAL_WEIGHT to (1<<24) and be done with it once and (probably) for all. Ciao, Dscho -

Hi, Let's hope that your suspicion holds better than my worktree/gitdir suspicion... In any case, ACK on your patch. Ciao, Dscho -

There is no 'B' status in raw tree output. Broken filepairs can be left as pair of addition 'A' and deletion 'D', or merged into modification with dissimilarity score, e.g. 'M064'. See Documentation/diffcore.txt: the latest implementation always merges all the broken pairs back into modifications, but the resulting patch output is formatted differently for easier review in case of such a complete rewrite by showing the entire contents of old version prefixed with '-', followed by ...