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>
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>
The git-rev-parse manpage talks about the :$n:path notation (buried deep in
a list of other syntax) but it just says $n is a "stage number" -- someone
who is not familiar with the internals of git's merge implementation is
never going to be able to figure out that "1", "2", and "3" means.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --walk-reflogs logic and the --reverse logic are completely
incompatible with one another. Attempting to use both at the same
time leads to confusing results that sometimes violates the user's
formatting options or ignores the user's request to see the reflog
message and timestamp.
Unfortunately the implementation of both of these features is glued
onto the side of the revision walking machinary in such a way that
they are probably not going to be easy to make them compatible with
each other. Rather than offering the user confusing results we are
better off bailing out with an error message until such a time as
the implementations can be refactored to be compatible.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes it easier to find out how to enable the reflog
for a bare repository by searching the documentation for
"reflog".
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To keep the change small, this is done by setting GIT_PAGER to "cat".
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default 'git reflog show' will show the reflog of 'HEAD' and not
the reflog of the current branch. This is most likely due to the
work done a while ago as part of the detached HEAD series to allow
HEAD to have its own reflog independent of each branch's reflog.
Since 'git reflog show' is really just an obscure alias for 'git
log -g --abbrev-commit --pretty=oneline' it should behave the same
way and its documentation should match.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing checkpoint command is very useful to force fast-import
to dump the branches out to disk so that standard Git tools can
access them and the objects they refer to. However there was not a
way to know when fast-import had finished executing the checkpoint
and it was safe to read those refs.
The progress command can be used to make fast-import output any
message of the frontend's choosing to standard out. The frontend
can scan for these messages using select() or poll() to monitor a
pipe connected to the standard output of fast-import.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
For the same reasons as the prior change we want to allow frontends
to omit the trailing LF that usually delimits commands. In some
cases these just make the input stream more verbose looking than
it needs to be, and its just simpler for the frontend developer to
get started if our parser is slightly more lenient about where an
LF is required and where it isn't.
To make this optional LF feature work we now have to buffer up to one
line of input in command_buf. This buffering can happen if we look
at the current input command but don't recognize it at this point
in the code. In such a case we need to "unget" the entire line,
but we cannot depend upon the stdio library to let us do ungetc()
for that many characters at once.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Junio C Hamano