This patch removes the '$Keyword: ...$' '...' data, so that files
don't have spurious megre conflicts between branches.
Handles both +ko and +k styles, and leaves the '$Foo$' in
the original file.
Signed-off-by: Simon Hausmann <simon@lst.de>
The scripted version might not have handled this correctly
either, but the version rewritten in C definitely does not grok
this and complains $tag is not a commit object.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adjust the command syntax to better reflect the call parameters:
[save] [message...] => [save [<message>]].
Signed-off-by: Jari Aalto <jari.aalto AT cante.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is the absolute minimum (and reliable) reproduction recipe
to demonstrate that revision range in a history with clock skew
sometimes fails to mark UNINTERESTING commit in topologically
early parts of the history.
The history looks like this:
o---o---o---o
one four
but one has the largest timestamp. "git rev-list four..one"
fails to notice that "one" should not be emitted.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we have known breakages, we still said "passed all N
test(s)", which was a bit funny.
This rewords it to read "passed all remaining N test(s)" in such
a case.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally, test_expect_failure was designed to be the opposite
of test_expect_success, but this was a bad decision. Most tests
run a series of commands that leads to the single command that
needs to be tested, like this:
test_expect_{success,failure} 'test title' '
setup1 &&
setup2 &&
setup3 &&
what is to be tested
'
And expecting a failure exit from the whole sequence misses the
point of writing tests. Your setup$N that are supposed to
succeed may have failed without even reaching what you are
trying to test. The only valid use of test_expect_failure is to
check a trivial single command that is expected to fail, which
is a minority in tests of Porcelain-ish commands.
This large-ish patch rewrites all uses of test_expect_failure to
use test_expect_success and rewrites the condition of what is
tested, like this:
test_expect_success 'test title' '
setup1 &&
setup2 &&
setup3 &&
! this command should fail
'
test_expect_failure is redefined to serve as a reminder that
that test *should* succeed but due to a known breakage in git it
currently does not pass. So if git-foo command should create a
file 'bar' but you discovered a bug that it doesn't, you can
write a test like this:
test_expect_failure 'git-foo should create bar' '
rm -f bar &&
git foo &&
test -f bar
'
This construct acts similar to test_expect_success, but instead
of reporting "ok/FAIL" like test_expect_success does, the
outcome is reported as "FIXED/still broken".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because ':/substring' extended SHA1 expression cannot take
postfix modifiers such as ^{tree} and ^{commit}, we would need
to do it in multiple steps. With the patch, you can start a new
branch from a randomly-picked commit whose message has the named
string in it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
filter-branch previously took the first non-option argument as the name for
a new branch. Since dfd05e38, it now takes a revision or a revision range
and modifies the current branch. Update to operate on HEAD by default to
conform with standard git interface practice.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We only care about getting what should be an empty string and
sending it to a file, without a trailing LF, so the empty string
translates into a 0 byte file. Earlier when I originally wrote
these lines Mac OS X allowed the format string of printf to be
the empty string, but more recent versions appear to have been
'improved' with error messages if the format is not given.
This may cause problems if we ever wind up with changes to the hook
tests. A minor cleanup makes the test more safe on all systems,
by conforming to accepted printf conventions.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
One of the first things filter-branch does is to create a temporary
directory. This directory is eventually removed by the script during
normal operation, but is not removed if the script encounters an error.
Set a trap to remove it when the script terminates for any reason.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-relink is intended to search for packs and loose objects in
common between two repositories and to replace the one set with
hard links to the other. Files other than packs and loose objects
should not be touched, so add the "info" sub-directory to the
pattern of directory excludes.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Those two configuration variables are important enough that it is
worth to explicitely write about them in the "Gitweb config file
variables" section even if they are usually set during build by
GITWEB_PROJECTROOT and GITWEB_LIST build (Makefile) configuration
variables.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git reflog expire --all" opened a directory in $GIT_DIR/logs/,
read reflog files in there readdir(3), and rewrote the file by
creating a new file and renaming it back inside the loop. This
code structure can cause the newly created file to be returned
by subsequent call to readdir(3), and fall into an infinite loop
in the worst case.
This separates the processing to two phase. Running
for_each_reflog() to find out and collect all refs, and then
iterate over them, calling expire_reflog(). This way, the
program would behave exactly the same way as if all the refs
were given by the user from the command line.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the commit message, or commit author contains non-ascii, it must be
converted from Perl internal representation to utf-8, to follow what
got declared in HTTP header. Use to_utf8() to do the conversion.
This necessarily replaces here-doc with "print" statements.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
Acked-by: İsmail Dönmez <ismail@pardus.org.tr>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This accompanies c5b09feb78 (Avoid
update hook during git-rebase --interactive) to make sure that
any regression to make Debian's Bug#458782 (git-core: git-rebase
doesn't work when trying to squash changes into commits created
with --no-verify) resurface will be caught.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The exit value of some commands was not being used for the
test output.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the upstream branch is tracked, we can detect if that branch
was rebased since it was last fetched. Teach git to use that
information to rebase from the old remote head onto the new remote head.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git histories may have multiple roots, which can cause
git merge-base to fail and this caused git cvsserver to die.
This commit teaches git cvsserver to handle a failing git
merge-base gracefully, and modifies the test case to verify this.
All the test cases now use a history with two roots.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
git-cvsserver.perl | 9 ++++++++-
t/t9400-git-cvsserver-server.sh | 10 +++++++++-
2 files changed, 17 insertions(+), 2 deletions(-)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is preferable to have the test setup in a test case. The
setup itself may fail and having it as a test case handles this
situation more gracefully.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While there is information about this in the configuration section, it was
missing in the options section.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If options are aggregated, and that the whole token is an exact
prefix of a long option that is longer than 2 letters, reject
it. This is to prevent a common typo:
$ git commit -amend
to get interpreted as "commit all with message 'end'".
The typo check isn't performed if there is no aggregation,
because the stuck form is the recommended one. If we have `-o`
being a valid short option that takes an argument, and --option
a long one, then we _MUST_ accept -option as "'o' option with
argument 'ption'", which is our official recommended form.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The -n option stands for --no-summary in git pull
[jes: reworded the description to avoid mentioning 'git-fetch';
also exclude '-n' conditional on git-pull -- ugly because of
the missing "else" statement in asciidoc]
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn expects its references under refs/remotes/*; but these will
not be copied or set by "git clone"; put in this man page the manual
fiddling that is required with current git-svn to get this to work.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pre-POSIX.1-2001 systems don't have <sys/select.h>, but select(2)
is declared in <sys/time.h>, which git-compat-util.h includes.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
POSIX.1-2001 has declaration of select(2) in <sys/select.h>, but
in the previous version of SUS, it was declared in <sys/time.h>
(which is already included in git-compat-util.h).
This introduces NO_SYS_SELECT_H macro in the Makefile to be set
on older systems, to skip inclusion of <sys/select.h> that does
not exist on them.
We could check _POSIX_VERSION with 200112L and do this
automatically, but earlier it was reported that the approach
does not work well on some vintage of HP-UX. Other systems may
get _POSIX_VERSION itself wrong. At least for now, this manual
configuration is safer.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://repo.or.cz/git-gui:
git-gui: Correctly cleanup msgfmt '1 message untranslated' output
git-gui: Make the statistics of po2msg match those of msgfmt
git-gui: Fallback to Tcl based po2msg.sh if msgfmt isn't available
git-gui: Work around random missing scrollbar in revision list
In certain rare cases, the creation of the commit object
and update of HEAD can succeed, but then installing the
updated index will fail. This is most likely caused by a
full disk or exceeded disk quota. When this happens the
new index file will be removed, and the repository will
be left with the original now-out-of-sync index. The
user can recover with a "git reset HEAD" once the disk
space issue is resolved.
We should detect this failure and offer the user some
helpful guidance.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is a scenario when using git clone -s and git gc --prune togother is
dangerous. Document this.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This creates a hash index of every single file added to the index.
Right now that hash index isn't actually used for much: I implemented a
"cache_name_exists()" function that uses it to efficiently look up a
filename in the index without having to do the O(logn) binary search,
but quite frankly, that's not why this patch is interesting.
No, the whole and only reason to create the hash of the filenames in the
index is that by modifying the hash function, you can fairly easily do
things like making it always hash equivalent names into the same bucket.
That, in turn, means that suddenly questions like "does this name exist
in the index under an _equivalent_ name?" becomes much much cheaper.
Guiding principles behind this patch:
- it shouldn't be too costly. In fact, my primary goal here was to
actually speed up "git commit" with a fully populated kernel tree, by
being faster at checking whether a file already existed in the index. I
did succeed, but only barely:
Best before:
[torvalds@woody linux]$ time git commit > /dev/null
real 0m0.255s
user 0m0.168s
sys 0m0.088s
Best after:
[torvalds@woody linux]$ time ~/git/git commit > /dev/null
real 0m0.233s
user 0m0.144s
sys 0m0.088s
so some things are actually faster (~8%).
Caveat: that's really the best case. Other things are invariably going
to be slightly slower, since we populate that index cache, and quite
frankly, few things really use it to look things up.
That said, the cost is really quite small. The worst case is probably
doing a "git ls-files", which will do very little except puopulate the
index, and never actually looks anything up in it, just lists it.
Before:
[torvalds@woody linux]$ time git ls-files > /dev/null
real 0m0.016s
user 0m0.016s
sys 0m0.000s
After:
[torvalds@woody linux]$ time ~/git/git ls-files > /dev/null
real 0m0.021s
user 0m0.012s
sys 0m0.008s
and while the thing has really gotten relatively much slower, we're
still talking about something almost unmeasurable (eg 5ms). And that
really should be pretty much the worst case.
So we lose 5ms on one "benchmark", but win 22ms on another. Pick your
poison - this patch has the advantage that it will _likely_ speed up
the cases that are complex and expensive more than it slows down the
cases that are already so fast that nobody cares. But if you look at
relative speedups/slowdowns, it doesn't look so good.
- It should be simple and clean
The code may be a bit subtle (the reasons I do hash removal the way I
do etc), but it re-uses the existing hash.c files, so it really is
fairly small and straightforward apart from a few odd details.
Now, this patch on its own doesn't really do much, but I think it's worth
looking at, if only because if done correctly, the name hashing really can
make an improvement to the whole issue of "do we have a filename that
looks like this in the index already". And at least it gets real testing
by being used even by default (ie there is a real use-case for it even
without any insane filesystems).
NOTE NOTE NOTE! The current hash is a joke. I'm ashamed of it, I'm just
not ashamed of it enough to really care. I took all the numbers out of my
nether regions - I'm sure it's good enough that it works in practice, but
the whole point was that you can make a really much fancier hash that
hashes characters not directly, but by their upper-case value or something
like that, and thus you get a case-insensitive hash, while still keeping
the name and the index itself totally case sensitive.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This moves a common boolean expression into a helper function,
and makes the comparison between filesystem timestamp and index
timestamp done in the function in line with the other places.
st.st_mtime should be casted to (unsigned int) when compared to
an index timestamp ce_mtime.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is a D/F conflict if you want to add "foo/bar" to the index
when "foo" already exists. Also it is a conflict if you want to
add a file "foo" when "foo/bar" exists.
An exception is when the existing entry is there only to mark "I
used to be here but I am being removed". This is needed for
operations such as "git read-tree -m -u" that update the index
and then reflect the result to the work tree --- we need to
remember what to remove somewhere, and we use the index for
that. In such a case, an existing file "foo" is being removed
and we can create "foo/" directory and hang "bar" underneath it
without any conflict.
We used to use (ce->ce_mode == 0) to mark an entry that is being
removed, but (CE_REMOVE & ce->ce_flags) is used for that purpose
these days. An earlier commit forgot to convert the logic in
the code that checks D/F conflict condition.
The old code knew that "to be removed" entries cannot be at
higher stage and actively checked that condition, but it was an
unnecessary check. This patch removes the extra check as well.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the multiple message case we remove the word "messages" from the
statistics output of msgfmt as it looks cleaner on the tty when you
are watching the build process. However we failed to strip the word
"message" when only 1 message was found to be untranslated or fuzzy,
as msgfmt does not produce the 's' suffix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The strings we were showing from po2msg didn't exactly match those
of msgfmt's --statistics output so we didn't show quite the same
results when building git-gui's message files. Now we're closer
to what msgfmt shows (at least for an en_US locale) so the make
output matches.
I noticed that the fuzzy translation count is off by one for the
current po/zh_cn.po file. Not sure why and I'm not going to try
and debug it at this time as the po2msg is strictly a fallback,
users building from source really should prefer msgfmt.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
