Граф коммитов

55 Коммитов

Автор SHA1 Сообщение Дата
Junio C Hamano b0ad11ea16 pull: allow "git pull origin $something:$current_branch" into an unborn branch
Some misguided documents floating on the Net suggest this sequence:

    mkdir newdir && cd newdir
    git init
    git remote add origin $url
    git pull origin master:master

"git pull" has known about misguided "pull" that lets the underlying fetch
update the current branch for a long time.  It also has known about
"git pull origin master" into a branch yet to be born.

These two workarounds however were not aware of the existence of each
other and did not work well together.  This fixes it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-17 11:26:20 -07:00
Johannes Schindelin 7d90c8ee15 Ignore dirty submodule states in "git pull --rebase"
This is a companion patch to 6848d58c(Ignore dirty submodule states
during rebase and stash).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-23 11:36:56 -07:00
Stephan Beyer 1b1dd23f2d Make usage strings dash-less
When you misuse a git command, you are shown the usage string.
But this is currently shown in the dashed form.  So if you just
copy what you see, it will not work, when the dashed form
is no longer supported.

This patch makes git commands show the dash-less version.

For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
generates a dash-less usage string now.

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13 14:12:48 -07:00
Johannes Schindelin f9189cf8f2 pull --rebase: exit early when the working directory is dirty
When rebasing fails during "pull --rebase", you cannot just clean up the
working directory and call "pull --rebase" again, since the remote branch
was already fetched.

Therefore, die early when the working directory is dirty.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-22 23:05:11 -07:00
SZEDER Gábor efb779f887 merge, pull: add '--(no-)log' command line option
These are the command line option equivalents of the 'merge.log' config
variable.

The patch also updates documentation and bash completion accordingly, and
adds a test.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-12 19:28:18 -07:00
SZEDER Gábor d8abe148be merge, pull: introduce '--(no-)stat' option
This option has the same effect as '--(no-)summary' (i.e. whether to
show a diffsat at the end of the merge or not), and it is consistent
with the '--stat' option of other git commands.

Documentation, tests, and bash completion are updaed accordingly, and the
old --summary option is marked as being deprected.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-12 19:28:18 -07:00
Jay Soffian 0d2dd191cd pull: pass --strategy along to to rebase
rebase supports --strategy, so pull should pass the option along to it.

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-22 21:44:46 -08:00
Johannes Schindelin c85c79279d pull --rebase: be cleverer with rebased upstream branches
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>
2008-01-26 18:24:24 -08:00
Junio C Hamano 441ed4131b "git pull --tags": error out with a better message.
When "git pull --tags" is run without any other arguments, the
standard error message "You told me to fetch and merge stuff but
there is nothing to merge!  You might want to fix your config"
is given.

While the error may be technically correct, fixing the config
would not help, as "git pull --tags" itself tells "git fetch"
not to use the configured refspecs.

This commit makes "git pull --tags" to issue a different error
message to avoid confusion.  This is merely an interim solution.

In the longer term, it would be a better approach to change the
semantics of --tags option to make "git fetch" and "git pull"
to:

 (1) behave as if no --tags was given (so an explicit refspec on
     the command line overrides configured ones, or no explicit
     refspecs on the command line takes configured ones); but

 (2) no auto-following of tags is made even when using
     configured refspecs; and

 (3) fetch all tags as not-for-merge entries".

Then we would not need to have this separate error message, as
the ordinary merge will happen even with the --tags option.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-28 21:01:24 -08:00
Johannes Schindelin cd67e4d46b Teach 'git pull' about --rebase
When calling 'git pull' with the '--rebase' option, it performs a
fetch + rebase instead of a fetch + merge.

This behavior is more desirable than fetch + pull when a topic branch
is ready to be submitted and needs to be update.

fetch + rebase might also be considered a better workflow with shared
repositories in any case, or for contributors to a centrally managed
repository, such as WINE's.

As a convenience, you can set the default behavior for a branch by
defining the config variable branch.<name>.rebase, which is
interpreted as a bool.  This setting can be overridden on the command
line by --rebase and --no-rebase.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-28 17:32:23 -08:00
Junio C Hamano 8f321a3925 scripts: Add placeholders for OPTIONS_SPEC
--text follows this line--
These commands currently lack OPTIONS_SPEC; allow people to
easily list with "git grep 'OPTIONS_SPEC=$'" what they can help
improving.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-06 01:50:02 -08:00
Lars Hjemli 5072a32382 Teach git-pull about --[no-]ff, --no-squash and --commit
These options are supported by git-merge, but git-pull didn't know about
them.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-29 13:32:52 -07:00
Federico Mena Quintero 8fc293cb1e Make git-pull complain and give advice when there is nothing to merge with
Signed-off-by: Federico Mena Quintero <federico@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 17:27:48 -07:00
David Kastrup 822f7c7349 Supplant the "while case ... break ;; esac" idiom
A lot of shell scripts contained stuff starting with

	while case "$#" in 0) break ;; esac

and similar.  I consider breaking out of the condition instead of the
body od the loop ugly, and the implied "true" value of the
non-matching case is not really obvious to humans at first glance.  It
happens not to be obvious to some BSD shells, either, but that's
because they are not POSIX-compliant.  In most cases, this has been
replaced by a straight condition using "test".  "case" has the
advantage of being faster than "test" on vintage shells where "test"
is not a builtin.  Since none of them is likely to run the git
scripts, anyway, the added readability should be worth the change.

A few loops have had their termination condition expressed
differently.

Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-23 16:12:00 -07:00
Junio C Hamano 5be60078c9 Rewrite "git-frotz" to "git frotz"
This uses the remove-dashes target to replace "git-frotz" to "git frotz".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02 22:52:14 -07:00
Alex Riesen 51e7ecf4ec Add a configuration option to control diffstat after merge
The diffstat can be controlled either with command-line options
(--summary|--no-summary) or with merge.diffstat. The default is
left as it was: diffstat is active by default.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-24 21:37:08 -07:00
Jeff King a74b1706c8 git-pull: disallow implicit merging to detached HEAD
Instead, we complain to the user and suggest that they explicitly
specify the remote and branch. We depend on the exit status of
git-symbolic-ref, so let's go ahead and document that.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-15 15:37:22 -08:00
Junio C Hamano 533b70390e Allow whole-tree operations to be started from a subdirectory
This updates five commands (merge, pull, rebase, revert and cherry-pick)
so that they can be started from a subdirectory.

This may not actually be what we want to do.  These commands are
inherently whole-tree operations, and an inexperienced user may
mistakenly expect a "git pull" from a subdirectory would merge
only the subdirectory the command started from.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12 16:54:38 -08:00
Shawn O. Pearce 7eff28a9b4 Disallow working directory commands in a bare repository.
If the user tries to run a porcelainish command which requires
a working directory in a bare repository they may get unexpected
results which are difficult to predict and may differ from command
to command.

Instead we should detect that the current repository is a bare
repository and refuse to run the command there, as there is no
working directory associated with it.

[jc: updated Shawn's original somewhat -- bugs are mine.]

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-10 15:03:09 -08:00
Junio C Hamano d1014a1745 fail pull/merge early in the middle of conflicted merge
After a pull that results in a conflicted merge, a new user
often tries another "git pull" in desperation.  When the index
is unmerged, merge backends correctly bail out without touching
either index nor the working tree, so this does not make the
wound any worse.

The user will however see several lines of messsages during this
process, such as "filename: needs merge", "you need to resolve
your current index first", "Merging...", and "Entry ... would be
overwritten by merge. Cannot merge.".  They are unnecessarily
alarming, and cause useful conflict messages from the first pull
scroll off the top of the terminal.

This changes pull and merge to run "git-ls-files -u" upfront and
stop them much earlier than we currently do.  Old timers may
know better and would not to try pulling again before cleaning
things up; this change adds extra overhead that is unnecessary
for them.  But this would be worth paying for to save new people
from needless confusion.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-01 14:35:16 -08:00
Shawn O. Pearce 6b5a795bf5 Allow git-merge to select the default strategy.
Now that git-merge knows how to use the pull.{twohead,octopus}
configuration options to select the default merge strategy there
is no reason for git-pull to do the same immediately prior to
invoking git-merge.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-28 01:08:06 -08:00
Shawn O. Pearce bf699582fd Ensure `git-pull` fails if `git-merge` fails.
If git-merge exits with a non-zero exit status so should git-pull.
This way the caller of git-pull knows the task did not complete
successfully simply by checking the process exit status.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-28 01:07:37 -08:00
Shawn O. Pearce f94741324e Use GIT_REFLOG_ACTION environment variable instead.
Junio rightly pointed out that the --reflog-action parameter
was starting to get out of control, as most porcelain code
needed to hand it to other porcelain and plumbing alike to
ensure the reflog contained the top-level user action and
not the lower-level actions it invoked.

At Junio's suggestion we are introducing the new set_reflog_action
function to all shell scripts, allowing them to declare early on
what their default reflog name should be, but this setting only
takes effect if the caller has not already set the GIT_REFLOG_ACTION
environment variable.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-28 01:05:15 -08:00
Josef Weidendorfer 4363dfbe3d Move "no merge candidate" warning into git-pull
The warning triggered even when running "git fetch" only
when resulting .git/FETCH_HEAD only contained
branches marked as 'not-for-merge'.

Signed-off-by: Josef Weidendorfer <weidendo@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-19 01:53:02 -08:00
Linus Torvalds d09e79cb1c git-pull: allow pulling into an empty repository
We used to complain that we cannot merge anything we fetched
with a local branch that does not exist yet.  Just treat the
case as a natural extension of fast forwarding and make the
local branch'es tip point at the same commit we just fetched.
After all an empty repository without an initial commit is an
ancestor of any commit.

[jc: I added a trivial test.  We've become sloppy but we should
 stick to the discipline of covering new behaviour with new
 tests. ]

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-16 23:45:48 -08:00
Junio C Hamano a057f80667 git-pull: we say commit X, not X commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-10 23:00:29 -07:00
Shawn Pearce e1447e38c0 Log ref changes made by git-merge and git-pull.
When git-merge updates HEAD as a result of a merge record what
happened during the merge into the reflog associated with HEAD
(if any).  The log reports who caused the update (git-merge or
git-pull, by invoking git-merge), what the remote ref names were
and the type of merge process used.

The merge information can be useful when reviewing a reflog for
a branch such as `master` where fast forward and trivial in index
merges might be common as the user tracks an upstream.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-11 14:16:53 -07:00
Shawn Pearce 55b7835e1b Log ref changes made by git-fetch and git-pull.
When git-fetch updates a reference record in the associated reflog
what type of update took place and who caused it (git-fetch or
git-pull, by invoking git-fetch).

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-10 21:21:27 -07:00
Dennis Stosberg 8096fae726 Fix expr usage for FreeBSD
Some implementations of "expr" (e.g. FreeBSD's) fail, if an
argument starts with a dash.

Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-27 10:56:05 -07:00
Junio C Hamano 7d0c68871a git-merge --squash
Some people tend to do many little commits on a topic branch,
recording all the trials and errors, and when the topic is
reasonably cooked well, would want to record the net effect of
the series as one commit on top of the mainline, removing the
cruft from the history.  The topic is then abandoned or forked
off again from that point at the mainline.

The barebone porcelainish that comes with core git tools does
not officially support such operation, but you can fake it by
using "git pull --no-merge" when such a topic branch is not a
strict superset of the mainline, like this:

	git checkout mainline
	git pull --no-commit . that-topic-branch
	: fix conflicts if any
	rm -f .git/MERGE_HEAD
        git commit -a -m 'consolidated commit log message'
	git branch -f that-topic-branch ;# now fully merged

This however does not work when the topic branch is a fast
forward of the mainline, because normal "git pull" will never
create a merge commit in such a case, and there is nothing
special --no-commit could do to begin with.

This patch introduces a new option, --squash, to support such a
workflow officially in both fast-forward case and true merge
case.  The user-level operation would be the same in both cases:

	git checkout mainline
        git pull --squash . that-topic-branch
        : fix conflicts if any -- naturally, there would be
        : no conflict if fast forward.
	git commit -a -m  'consolidated commit log message'
	git branch -f that-topic-branch ;# now fully merged

When the current branch is already up-to-date with respect to
the other branch, there truly is nothing to do, so the new
option does not have any effect.

This was brought up in #git IRC channel recently.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24 01:11:19 -07:00
Junio C Hamano 86378b3289 git-pull: abort when fmt-merge-msg fails.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24 01:10:27 -07:00
Junio C Hamano 8323124afe git-pull: reword "impossible to fast-forward" message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-22 01:57:11 -08:00
Junio C Hamano cf46e7b899 git-pull: further safety while on tracking branch.
Running 'git pull' while on the tracking branch has a built-in
safety valve to fast-forward the index and working tree to match
the branch head, but it errs on the safe side too cautiously.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-22 01:09:43 -08:00
Junio C Hamano f5ef535ff5 git-pull: run repo-config with dash form.
... as discussed on the list for consistency.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-18 02:07:59 -08:00
Mark Hollomon c8e2db00f9 Let merge set the default strategy.
If the user does not set a merge strategy for git-pull,
let git-merge calculate a default strategy.

[jc: with minor stylistic tweaks]

Signed-off-by: Mark Hollomon <markhollomon@comcast.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-15 16:14:33 -08:00
Junio C Hamano 4890f62bc0 Avoid using "git-var -l" until it gets fixed.
This is to be nicer to people with unusable GECOS field.

"git-var -l" is currently broken in that when used by a user who
does not have a usable GECOS field and has not corrected it by
exporting GIT_COMMITTER_NAME environment variable it dies when
it tries to output GIT_COMMITTER_IDENT (same thing for AUTHOR).

"git-pull" used "git-var -l" only because it needed to get a
configuration variable before "git-repo-config --get" was
introduced.  Use the latter tool designed exactly for this
purpose.

"git-sh-setup" used "git-var GIT_AUTHOR_IDENT" without actually
wanting to use its value.  The only purpose was to cause the
command to check and barf if the repository format version
recorded in the $GIT_DIR/config file is too new for us to deal
with correctly.  Instead, use "repo-config --get" on a random
property and see if it die()s, and check if the exit status is
128 (comes from die -- missing variable is reported with exit
status 1, so we can tell that case apart).

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-12 04:59:25 -08:00
freku045@student.liu.se 806f36d4d7 Trivial usage string clean-up
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14 02:53:43 -08:00
Junio C Hamano ae2b0f1518 git-sh-setup: die if outside git repository.
Now all the users of this script detect its exit status and die,
complaining that it is outside git repository.  So move the code
that dies from all callers to git-sh-setup script.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-25 13:49:17 -08:00
Junio C Hamano a1c292958f Make git-recursive the default strategy for git-pull.
This does two things:

 - It changes the hardcoded default merge strategy for two-head
   git-pull from resolve to recursive.

 - .git/config file acquires two configuration items.
   pull.twohead names the strategy for two-head case, and
   pull.octopus names the strategy for octopus merge.

IOW you are paranoid, you can have the following lines in your
.git/config file and keep using git-merge-resolve when pulling
one remote:

	[pull]
		twohead = resolve

OTOH, you can say this:

	[pull]
		twohead = resolve
		twohead = recursive

to try quicker resolve first, and when it fails, fall back to
recursive.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-09 18:56:29 -08:00
Junio C Hamano 31b9755a65 Recover dropped +x bit from git-pull.sh by accident.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-07 12:52:07 -08:00
Jon Loeliger 93d69d8691 Refactored merge options into separate merge-options.txt.
Refactored fetch options into separate fetch-options.txt.
Made git-merge use merge-options.
Made git-fetch use fetch-options.
Made git-pull use merge-options and fetch-options.
Added --help option to git-pull and git-format-patch scripts.
Rewrote Documentation/Makefile to dynamically determine
include dependencies.

Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-06 23:32:04 -08:00
Junio C Hamano d8ae1d10cd Document the --no-commit flag better
Pasky and I did overlapping documentation independently; this is to
pick up better wordings from what he sent me.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-04 18:17:16 -08:00
Junio C Hamano 123ee3ca7b Add --no-commit to git-merge/git-pull.
With --no-commit flag, git-pull will perform the merge but pretends as
if the merge needed a hand resolve even if automerge cleanly resolves,
to give the user a chance to add further changes and edit the commit
message.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-03 14:55:10 -08:00
Junio C Hamano 619e5a0ed4 git-pull: do not barf on -a flag meant for git-fetch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-03 15:45:44 -07:00
Junio C Hamano 60fb5b2c4d Use git-merge in git-pull (second try).
This again makes git-pull to use git-merge, so that different merge
strategy can be specified from the command line.  Without explicit
strategy parameter, it defaults to git-merge-resolve if only one
remote is pulled, and git-merge-octopus otherwise, to keep the
default behaviour of the command the same as the original.

Also this brings another usability measure: -n flag from the command
line, if given, is passed to git-merge to prevent it from running the
diffstat at the end of the merge.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-29 00:24:41 -07:00
Junio C Hamano bf7960eb51 Use git-update-ref in scripts.
This uses the git-update-ref command in scripts for safer updates.
Also places where we used to read HEAD ref by using "cat" were fixed
to use git-rev-parse.  This will matter when we start using symbolic
references.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-28 16:42:44 -07:00
Junio C Hamano 05dd8e2ee2 Fix default pull not to do an unintended Octopus.
The refspecs specified in the .git/remotes/<remote> on the "Pull: "
lines are for fetching multiple heads in one go, but most of the time
making an Octopus out of them is not what is wanted.  Make git-fetch
leave the marker in .git/FETCH_HEAD file so that later stages can
tell which heads are for merging and which are not.

Tom Prince made me realize how stupid the original behaviour was.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-28 16:22:00 -07:00
Junio C Hamano c8b48ba476 Prettyprint octopus merge message.
Including the current branch in the list of heads being merged
was not a good idea, so drop it.  And shorten the message by
grouping branches and tags together to form a single line.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-22 18:09:07 -07:00
Junio C Hamano acfadcfb48 Revert "Use git-merge instead of git-resolve in git-pull."
This reverts f887564ab7 commit.
2005-09-21 14:01:56 -07:00
Junio C Hamano b91fb518cc Revert "Make Octopus merge message a bit nicer."
This reverts 63f1aa6c72 commit.
2005-09-21 13:59:54 -07:00