As suggested by Junio and Johannes, change the name of the former
attribute specfile to export-subst to indicate its function rather
than purpose and to make clear that it is not applied to working tree
files.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As suggested by Johannes, --pretty=format: placeholders in specfiles
need to be wrapped in $Format:...$ now. This syntax change restricts
the expansion of placeholders and makes it easier to use with files
that contain non-placeholder percent signs.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add support for a new attribute, specfile. Files marked as being
specfiles are expanded by git-archive when they are written to an
archive. It has no effect on worktree files. The same placeholders
as those for the option --pretty=format: of git-log et al. can be
used.
The attribute is useful for creating auto-updating specfiles. It is
limited by the underlying function format_commit_message(), though.
E.g. currently there is no placeholder for git-describe like output,
and expanded specfiles can't contain NUL bytes. That can be fixed
in format_commit_message() later and will then benefit users of
git-log, too.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
HPA noticed that yum does not like the newer git RPM set; it turns out
that we do not ship git-p4 anymore but existing installations do not
realize the package is gone if we do not tell anything about it.
David Kastrup suggests using Obsoletes in the spec file of the new
RPM to replace the old package, so here is a try.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow port specification in ssh:// URLs in the
usual notation:
ssh://[user@]host.domain[:<port>]/<path>
This allows git to be used over ssh-tunneling
networks.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The warning message to suggest "Consider running git-status" from
"git-diff" that we experimented with during the 1.5.3 cycle turns
out to be a bad idea. It robbed cache-dirty information from people
who valued it, while still asking users to run "update-index --refresh".
It was hoped that the new behaviour would at least have some educational
value, but not showing the cache-dirty paths like before meant that the
user would not even know easily which paths were cache-dirty, and it
made the need to refresh the index look like even more unnecessary chore.
This commit reinstates the traditional behaviour, but with a twist.
By default, the empty "diff --git" output is totally squelched out
from "git diff" output. At the end of the command, it automatically
runs "update-index --refresh" as needed, without even bothering the
user. In other words, people who do not care about the cache-dirtyness
do not even have to see the warning.
The traditional behaviour to see the stat-dirty output and to bypassing
the overhead of content comparison can be specified by setting the
configuration variable diff.autorefreshindex to false.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this function, a commit filter can leave out unwanted commits
(such as temporary commits). It does _not_ undo the changeset
corresponding to that commit, but it _skips_ the revision. IOW
no tree object is changed by this.
If you like to commit early and often, but want to filter out all
intermediate commits, marked by "@@@" in the commit message, you can
now do this with
git filter-branch --commit-filter '
if git cat-file commit $GIT_COMMIT | grep '@@@' > /dev/null;
then
skip_commit "$@";
else
git commit-tree "$@";
fi' newbranch
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move the convenience functions to the top of git-filter-branch.sh, and
return from the script when the environment variable SOURCE_FUNCTIONS is
set.
By sourcing git-filter-branch with that variable set automatically, all
commit filters may access the convenience functions like "map".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The interactive mode of rebase can be used to split commits. Tell the
interested parties about it, with a dedicated section in the man page.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some time ago, filter-branch's syntax changed so that more than one
ref can be rewritten at the same time. This involved the removal of
the ref name for the result; instead, the refs are rewritten in-place.
This updates the last leftovers in the documentation to reflect the
new behavior.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jari Aalto noticed a handful places in git-daemon documentation
that need to be improved.
* --inetd makes --pid-file to be ignored, in addition to --user
and --group
* receive-pack service was not described at all. We should, if
only to warn about the security implications of it.
* There was no example of per repository configuration.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As pointed out by Linus, these notations require the endpoints
given by the end user to be commits. Clarify.
Also, three-dots in AsciiDoc are turned into ellipses unless
quoted with bq. Be careful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I think the trick with Git-side filename globbing is important and perhaps
not that well known. Clarify a bit in git-add documentation what it means.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to trigger the special case "things not in origin"
semantics only when one and only one positive ref is given, and
no number (e.g. "git format-patch -4 origin") was specified, and
used the general revision range semantics for everything else.
This narrows the special case a bit more, by making:
git format-patch --root this_version
to show everything that leads to the named commit.
More importantly, document the two different semantics better.
The generic revision range semantics came later and bolted on
without being clearly documented.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"GIT_DIR=some.where git --bare cmd" and worse yet
"git --git-dir=some.where --bare cmd" were very confusing. They
both ignored git-dir specified, and instead made $cwd as GIT_DIR.
This changes --bare not to override existing GIT_DIR.
This has been like this for a long time. Let's hope nobody sane
relied on this insane behaviour.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Options -d, -l, -v have already been explained in OPTIONS below.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://linux-nfs.org/~bfields/git:
Documentation/user-manual.txt: fix a few omissions of gitlink commands.
user-manual: fix incorrect header level
user-manual: use pithier example commit
user-manual: introduce the word "commit" earlier
user-manual: minor editing for conciseness
user-manual: edit "ignoring files" for conciseness
Documentation/user-manual.txt: fix a few omissions of gitlink commands.
Actually, we should have a competition for the favorite example commit.
Criteria:
- length: one-line changes with one-line comments preferred,
and no long lines
- significance/memorability
- comic value
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The immediate motivation for writing this section was to explain the
various places ignore patterns could be used. However, I still think
.gitignore is the case most people will want to learn about first. It
also makes it a bit more concrete to introduce ignore patterns in the
context of .gitignore first. And the existance of gitignore(5) relieves
the pressure to explain it all here.
So, stick to the .gitignore example, with only a brief mention of the
others, explain the syntax only by example, and leave the rest to
gitignore(5).
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Cc: Johan Herland <johan@herland.net>
The usage string for the executable was missing --refresh. In
addition, the documentation referred to "file", but the usage string
referred to "filepattern". Updated the documentation to
"filepattern", as git-add does handle patterns.
Signed-off-by: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When not referring to the cvs command, CVS makes more sense.
Signed-off-by: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --stdlayout option to git-svn init/clone initialises the default
Subversion values of trunk,tags,branches: -T trunk -b branches -t tags.
If any of the -T/-t/-b options are given in addition, they are given
preference.
[ew: fixed whitespace and added "-s" shortcut]
Signed-off-by: martin f. krafft <madduck@madduck.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
As noted by Mike Hommey, the documentation for the config setting tar.umask
is not up-to-date. Commit f08b3b0e2e changed
the default from 0 to 2; this patch finally documents it.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Hopefully last rc of 1.5.3 cycle, except a few documentation and
message wording changes, and git-gui 0.8.2.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
