Multiple work dirs with git svn caused each work dir to have its own
stale copy of the SVN meta data in .git/svn
git svn rebase updates commits with git-svn-id: in the repository and
stores the SVN meta data information only in that work dir. Attempting to
git svn rebase in other work dirs for the same branch would fail because
the last revision fetched according to the git-svn-id is greater than the
revision in the SVN meta data for that work directory.
Signed-off-by: Bernt Hansen <bernt@norang.ca>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I think it would make more sense for rev~ to have the same guarantees that
rev^ has, namely to always return a commit. I would also suggest that not
giving a number would have the same effect of defaulting to 1, not 0.
Right now it's a bit illogical, but at least it's an _undocumented_
illogical behaviour.
This patch makes '^' and '~' act the same for the default count (i.e. both
default to 1), and also have the same behaviour for a count of zero.
Before (no discernible pattern):
[torvalds@woody git]$ git rev-parse v1.5.1 v1.5.1^0 v1.5.1~0 v1.5.1^ v1.5.1~
45354a57ee89815cab9545354a57ee045f5759c945354a57ee
After (fairly logical):
[torvalds@woody git]$ git rev-parse v1.5.1 v1.5.1^0 v1.5.1~0 v1.5.1^ v1.5.1~
45354a57ee89815cab9589815cab95045f5759c9045f5759c9
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, git-svn would blindly append '*' even if it was specified by
the user during initialization (for certain SVN setups, it is
necessary).
Now, the following command will work correctly:
git svn init -T trunk/docutils \
-t 'tags/*/docutils' \
-b 'branches/*/docutils' \
svn://svn.berlios.de/docutils
Thanks to martin f krafft for the bug report:
> My git-svn target configuration is
>
> [svn-remote "svn"]
> url = svn://svn.berlios.de/docutils
> fetch = trunk/docutils:refs/remotes/trunk
> branches = branches/*/docutils:refs/remotes/*
> tags = tags/*/docutils:refs/remotes/tags/*
>
> Unfortunately, when I run
>
> git-svn init -T trunk/docutils -t 'tags/*/docutils'
> -b 'branches/*/docutils'
>
> then I get (note the two asterisks on the left hand side):
>
> branches = branches/*/docutils/*:refs/remotes/*
> tags = tags/*/docutils/*:refs/remotes/tags/*
>
> I took a brief stab at the code but I can't even figure out where
> the /* is appended, so I defer to you.
>
> It should be trivial to keep git-svn from appending /* if the left
> side already contains an asterisk.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Tested-by: martin f krafft <madduck@madduck.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, it would error out while trying to read and/or writing them.
Now, calling merge-file with empty files is neither interesting nor
useful, but it is a bug that needed fixing.
Noticed by Clemens Buchacher.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
File mode changes should be handled similarly to changes of content.
That is, if the file mode changed in only one branch, keep the changed
version, and if both branch changed to different mode, mark it as a
conflict.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The wording of the interactive help text from git-add--interactive.perl is
clearer. Just duplicate that text here.
Signed-off-by: Vineet Kumar <vineet@doorstop.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Prior to commit 8320199 (Rewrite builtin-fetch option parsing to use
parse_options().), we understood '-n' as a short option to mean "don't
fetch tags from the remote". This patch reinstates behaviour similar,
but not identical to the pre commit 8320199 times.
Back then, -n always overrode --tags, so if both --tags and -n was
given on command-line, no tags were fetched regardless of argument
ordering. Now we use a "last entry wins" strategy, so '-n --tags'
means "fetch tags".
Since it's patently absurd to say both --tags and --no-tags, this
shouldn't matter in practice.
Spotted-by: Artem Zolochevskiy <azol@altlinux.org>
Reported-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit-tree fails when specifying a remote name (via -r option) and
one of the parent branch has a name. Prefixing with "$remote/" fix it.
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
URLs generated by href(..., -replay=>1) (which includes 'next page'
links and alternate view links) didn't set project info correctly
when current page URL is in pathinfo form.
This resulted in broken links such like:
http://www.example.com/w/ARRAY(0x85a5318)?a=shortlog;pg=1
if the 'pathinfo' feature was used, or
http://www.example.com/w/?a=shortlog;pg=1
if it wasn't, instead of correct:
http://www.example.com/w/project.git?a=shortlog;pg=1
This was caused by the fact that href() always replays params in the
arrayref form, were they multivalued or singlevalued, and the code
dealing with 'pathinfo' feature couldn't deal with $params{'project'}
being arrayref.
Setting $params{'project'} is moved before replaying params; this
ensures that 'project' parameter is processed correctly.
Noticed-by: Peter Oberndorfer <kumbayo84@arcor.de>
Noticed-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Just let the user know that a revision argument is missing instead of
a perl error. This error message mimic the "init" error message, but
could be improved.
Signed-off-by: Marc-Andre Lureau <marcandre.lureau@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Solaris' /usr/bin/tr doesn't seem to like multiple character
ranges in brackets (it simply prints "Bad string").
Instead, let's just enumerate the transformation we want.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The construct
sh -c "$0 \"$@\"" <editor> <file>
does not pick up quotes in <editor>, so you cannot give path to the
editor that has a shell IFS whitespace in it, and also give it initial
set of parameters and flags. Replace $0 with <editor> to fix this issue.
This fixes
git config core.editor '"c:/Program Files/What/Ever.exe"'
In other words, you can specify an editor with spaces in its path using a
config containing something like this:
[core]
editor = \"c:/Program Files/Darn/Spaces.exe\"
NOTE: we cannot just replace the $0 with \"$0\", because we still want
this to work:
[core]
editor = emacs -nw
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, --abort would end by git resetting to ORIG_HEAD, but some
commands, such as git reset --hard (which happened in git rebase --skip,
but could just as well be typed by the user), would have already modified
ORIG_HEAD.
Just use the orig-head we store in $dotest instead.
[jc: cherry-picked from 48411d and 4947cf9 on 'master']
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We might eventually be loosening this rule, but there is a longstanding
restriction that the users currently need to be aware of.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous parser wasn't able to grok:
* empty lines;
* annotated patch levels (trailing -pNNN annotations);
* trailing comments.
Now it understands them and uses the patch level hints as a git apply
argument.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "config --global" suggested in the message is a valid one-shot fix,
and hopefully one-shot across machines that NFS mounts the home directories.
This knowledge can hopefully be reused when you are forced to use git on
Windows, but the fix based on GECOS would not be applicable, so
it is not such a useful hint to mention the exact reason why the
name cannot be determined.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the rewriteRoot setting is used with git-svn, it causes the svn
IDs added to commit messages to bear a different URL than is actually
used to retrieve Subversion data.
It is common for Subversion repositories to be available multiple
ways: for instance, HTTP to the public, and svn+ssh to people with
commit access. The need to switch URLs for access is fairly common as
well -- perhaps someone was just given commit access. To switch URLs
without having to rewrite history, one can use the old url as a
rewriteRoot, and use the new one in the svn-remote url setting.
This works well for svn fetching and general git commands.
However, git-svn dcommit, rebase, and perhaps other commands do not
work in this scenario. They scan the svn ID lines in commit messages
and attempt to match them up with url lines in [svn-remote] sections
in the git config.
This patch allows them to match rewriteRoot options, if such options
are present.
Signed-off-by: John Goerzen <jgoerzen@complete.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
The subdirectory filter had a bug to notice that the commit in question
did not have anything in the path-limited part of the tree. $commit:$path
does not name an empty tree when $path does not appear in $commit.
This should fix it. The additional test in t7003 is originally from Kevin
Ballard but with fixups.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cmd_from() ends with a call to read_next_command(), which is needed
when using cmd_from() from commands where from is not the last element.
With reset, however, "from" is the last command, after which the flow
returns to the main loop, which calls read_next_command() again.
Because of this, always set unread_command_buf in cmd_reset_branch(),
even if cmd_from() was successful.
Add a test case for this in t9300-fast-import.sh.
Signed-off-by: Adeodato Simó <dato@net.com.org.es>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The optional endp parameter to unquote_c_style() was supposed to point at
a location past the closing double quote, but it was going one beyond it.
git-fast-import used this function heavily and the bug caused it to
misparse the input stream, especially when parsing a rename command:
R "filename that needs quoting" rename-target-name
Because the function erroneously ate the whitespace after the closing dq,
this triggered "Missing space after source" error when it shouldn't.
Thanks to Adeodato Simò for having caught this.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Dscho noticed that Term::ReadLine (used by send-email) colorized its
output for his TERM settings, inside t9001 tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The options --upload-pack (of git-fetch-pack) and --receive-pack (of
git-push) do the same as --exec (for both commands). But the former options
have the more descriptive name.
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Way back the perl version of shortlog would take the first populated line
of the commit body. The builtin version mearly takes the first line.
This leads to empty shortlog entries when there is some viable text in
the commit.
Reinstate this behaviour igoring all lines with nothing but whitespace.
This is often useful when dealing with commits imported from foreign SCMs
that do not tidy up the log message of useless blank lines at the beginning.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mac OS X Tiger may have a msgfmt available but it doesn't understand
how to implement --tcl. Falling back to po2msg.sh on such systems
is a reasonable behavior.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Back in 18f7c51c we switched git-ls-remote/git-peek-remote to
use the transport backend, rather than do everything itself.
As part of that switch we started to produce a non-zero exit
status if no refs were received from the remote peer, which
happens when the remote peer has no commits pushed to it yet.
(E.g. "git --git-dir=foo.git init; git ls-remote foo.git")
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A merge is not necessarily with a remote branch, it can be with any
commit.
Thanks to Paolo Ciarrocchi for pointing out the problem, and to
Nicolas Pitre for pointing out the fact that a merge is not
necessarily with a branch head.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-merge used to use either the --squash,--no-squash, --no-ff,--ff,
--no-commit,--commit option, whichever came last in the command line.
This lead to some un-intuitive behavior, having
git merge --no-commit --no-ff <branch>
actually commit the merge. Now git-merge respects --no-commit together
with --no-ff, as well as other combinations of the options. However,
this broke a selftest in t/t7600-merge.sh which expected to have --no-ff
completely override the --squash option, so that
git merge --squash --no-ff <branch>
fast-forwards, and makes a merge commit; combining --squash with --no-ff
doesn't really make sense though, and is now refused by git-merge. The
test is adapted to test --no-ff without the preceding --squash, and
another test is added to make sure the --squash --no-ff combination is
refused.
The unexpected behavior was reported by John Goerzen through
http://bing.sdebian.org/468568
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For some reason, http_cleanup was running all active slots, which could
lead in situations where a freed slot would be accessed in
fill_active_slots. OTOH, we are cleaning up, which means the caller
doesn't care about pending requests. Just forget about them instead
or running them.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous code mistakenly used wt_status_prepare to check whether the
index had anything commitable in it; however, that function is just an
init function, and will never report a dirty index.
The correct way with wt_status_* would be to call wt_status_print with the
output pointing to /dev/null or similar. However, that does extra work by
both examining the working tree and spewing status information to nowhere.
Instead, let's just implement the useful subset of wt_status_print as an
"is_index_dirty" function.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we expect a git command to notice and signal errors, we
carelessly wrote in our tests:
test_expect_success 'reject bogus request' '
do something &&
do something else &&
! git command
'
but a non-zero exit could come from the "git command" segfaulting.
A new helper function "tset_must_fail" is introduced and it is
meant to be used to make sure the command gracefully fails (iow,
dying and exiting with non zero status is counted as a failure
to "gracefully fail"). The above example should be written as:
test_expect_success 'reject bogus request' '
do something &&
do something else &&
test_must_fail git command
'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix typo in 'test -z "url"' when checking whether a submodule url is
empty. "url" should be "$url".
Signed-off-by: Ping Yin <pkufranky@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
511707d (use only the $PATH for exec'ing git commands) made it a
requirement to call setup_path() to include the git exec-dir in PATH
before spawning any other git commands. git-receive-pack was not yet
adapted to do this and therefore fails to spawn git-unpack-objects if that
is not in the standard PATH.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-status used the buffer name to find git-status buffers, and that
can fail if the buffer has another name, for example when multiple
working directories is tracked.
Signed-off-by: Rémi Vanicat <vanicat@debian.org>
Acked-by: Alexandre Julliard <julliard@winehq.org>
Tested-by: Xavier Maillard <xma@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't take the local umask setting into account when installing the
templates/* files and directories, running 'make install' with umask set
to 077 resulted in template/* installed with permissions 700 and 600.
The problem was discovered by Florian Zumbiehl, reported through
http://bugs.debian.org/467518
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
