* jc/setup:
builtin-mv: minimum fix to avoid losing files
git-add: adjust to the get_pathspec() changes.
Make blame accept absolute paths
setup: sanitize absolute and funny paths in get_pathspec()
* maint:
Clarified the meaning of git-add -u in the documentation
git-clone.sh: properly configure remote even if remote's head is dangling
Documentation/git-stash: document options for git stash list
send-email: squelch warning due to comparing undefined $_ to ""
The git-add documentation did not state clearly that the -u switch
updates only the tracked files that are in the current directory and
its subdirectories.
Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When switching branches from a subdirectory, checkout rewritten
in C extracted the toplevel of the tree in there.
This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When checking out a branch that is behind or forked from a
branch you are building on top of, we used to show full
left-right log but if you already _know_ you have long history
since you forked, it is a bit too much.
This tones down the message quite a bit, by only showing the
number of commits each side has since they diverged. Also the
message is not shown at all under --quiet.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cloning a remote repository which's HEAD refers to a nonexistent
ref, git-clone cloned all existing refs, but failed to write the
configuration for 'remote'. Now it detects the dangling remote HEAD,
refuses to checkout any local branch since HEAD refers to nowhere, but
properly writes the configuration for 'remote', so that subsequent
'git fetch's don't fail.
The problem was reported by Daniel Jacobowitz through
http://bugs.debian.org/466581
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This will make it a little less posix-dependent, and more efficient.
Included is also a minor doc improvement.
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
Acked-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When pushing a refspec like "HEAD", we used to treat it as
"HEAD:HEAD", which didn't work without rewriting. Instead, we should
resolve the ref. If it's a symref, further require it to point to a
branch, to avoid doing anything especially unexpected. Also remove the
rewriting previously added in builtin-push.
Since the code for "HEAD" uses the regular refspec parsing, it
automatically handles "+HEAD" without anything special.
[jc: added a further test to make sure that "remote.*.push = HEAD" works]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The check to see if initial_reply_to is defined was also comparing $_ to
"" for a reason I cannot ascertain (looking at the commit which made the
change didn't provide enlightenment), but if $_ is undefined, perl
generates a warning.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Rename git-core rpm to just git and rename the meta-pacakge to git-all.
push: document the status output
Documentation/push: clarify matching refspec behavior
push: indicate partialness of error message
In my use cases, "cvs status" sometimes reordered the passed filenames,
which often led to a misdetection of a dirty state (when it was in
reality a clean state).
I finally tracked it down to two filenames having the same basename.
So no longer trust the order of the results blindly, but actually check
the file name.
Since "cvs status" only returns the basename (and the complete path on the
server which is useless for our purposes), run "cvs status" several times
with lists consisting of files with unique (chomped) basenames.
Be a bit clever about new files: these are reported as "no file <blabla>",
so in order to discern it from existing files, prepend "no file " to the
basename.
In other words, one call to "cvs status" will not ask for two files
"blabla" (which does not yet exist) and "no file blabla" (which exists).
This patch makes cvsexportcommit slightly slower, when the list of changed
files has non-unique basenames, but at least it is accurate now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes my favorite annoyance with the git rpm packaging: don't pull
in tla when I say yum install git! You wouldn't expect yum install gcc
to pull in gcc-gfortran, right?
With this change, and blanket 'yum update' will automatically pull in the
new 'git' package and push out the old 'git-core', and if the old 'git'
package was installed 'git-all' will be pulled in instead. A couple of
things do break though: 'yum update git-core', because yum behaves
differently when given a specific package name - it doesn't follow obsoletes.
Instead, 'yum install git' will pull in the new git rpm, which will then
push out the old 'git-core'. Similarly, to get the newest version of
the meta package, 'yum install git-all' will install git-all, which then
pushes out the old 'git' meta package.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have particular reviewers you want to sent particular series
to, it's nice to be able to generate the whole series with them as
additional recipients, without configuring them into your general
headers or adding them by hand afterwards.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
RFC 2822 only permits a single To: header and a single Cc: header, so
we need to turn multiple values of each of these into a list. This
will be particularly significant with a command-line option to add Cc:
headers, where the user can't make sure to configure valid header sets
in any easy way.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now each value of format.headers will always be treated as a single
valid header, and newlines will be inserted between them as needed.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Presently, it works with each header ending with a newline, but not
without the newlines.
Also add a test to see that multiple "To:" headers get combined.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If --cover-letter is provided, generate a cover letter message before
the patches, numbered 0.
Original patch thanks to Johannes Schindelin
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --rebase option was documented in the wrong place (under MERGE
STRATEGIES instead of OPTIONS). Noted the branch.<name>.rebase
option.
Signed-off-by: Jay Soffian <jaysoffian@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>
Documents the branch.autosetupmerge=always setting and usage of --track
when branching from a local branch.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git branch" and "git checkout -b" now honor --track option even when
the upstream branch is local. Previously --track was silently ignored
when forking from a local branch. Also the command did not error out
when --track was explicitly asked for but the forked point specified
was not an existing branch (i.e. when there is no way to set up the
tracking configuration), but now it correctly does.
The configuration setting branch.autosetupmerge can now be set to
"always", which is equivalent to using --track from the command line.
Setting branch.autosetupmerge to "true" will retain the former behavior
of only setting up branch.*.merge for remote upstream branches.
Includes test cases for the new functionality.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The output was meant to be a balance of self-explanatory and
terse. In case we have erred too far on the terse side, it
doesn't hurt to explain in more detail what each line means.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous text was correct, but it was easy to miss the
fact that we are talking about "matching" refs. That is, the
text can be parsed as "we push the union of the sets
of remote and local heads" and not "we push the intersection
of the sets of remote and local heads". (The former actually
doesn't make sense if you think about it, since we don't
even _have_ some of those heads). A careful reading would
reveal the correct meaning, but it makes sense to be as
explicit as possible in documentation.
We also explicitly use and introduce the term "matching";
this is a term discussed on the list, and it seems useful
to for users to be able to refer to this behavior by name.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing message indicates that an error occured during
push, but it is unclear whether _any_ refs were actually
pushed (even though the status table above shows which were
pushed successfully and which were not, the message "failed
to push" implies a total failure). By indicating that "some
refs" failed, we hopefully indicate to the user that the
table above contains the details.
We could also put in an explicit "see above for details"
message, but it seemed to clutter the output quite a bit
(both on a line of its own, or at the end of the error line,
which inevitably wraps).
This could also be made more fancy if the transport
mechanism passed back more details on how many refs
succeeded and failed:
error: failed to push %d out of %d refs to '%s'
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git gui" would complain at launch if the local version of Git was
"1.5.4.2.dirty". Loosen the regular expression to look for either
"-dirty" or ".dirty", thus eliminating spurious warnings.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
These will be used for generating the cover letter in addition to the
patch emails.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tests -o, and an excessively long subject, and --thread, with and
without --in-reply-to=
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This also changes it such that:
$ git checkout
will give the same information without changing branches. This is good
for finding out if the fetch you did recently had anything to say
about the branch you've been on, whose name you don't remember at the
moment.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using 'git rev-parse --git-dir' makes the code shorter and more future-
proof.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mk/maint-parse-careful:
peel_onion: handle NULL
check return value from parse_commit() in various functions
parse_commit: don't fail, if object is NULL
revision.c: handle tag->tagged == NULL
reachable.c::process_tree/blob: check for NULL
process_tag: handle tag->tagged == NULL
check results of parse_commit in merge_bases
list-objects.c::process_tree/blob: check for NULL
reachable.c::add_one_tree: handle NULL from lookup_tree
mark_blob/tree_uninteresting: check for NULL
get_sha1_oneline: check return value of parse_object
read_object_with_reference: don't read beyond the buffer
Some codepaths (eg. builtin-rev-parse -> get_merge_bases -> parse_commit)
can pass NULL.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As these functions are directly called with the result
from lookup_tree/blob, they must handle NULL.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As these functions are directly called with the result
from lookup_tree/blob, they must handle NULL.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As these functions are directly called with the result
from lookup_tree/blob, they must handle NULL.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
