- 13 4月, 2008 2 次提交
-
-
由 SZEDER Gábor 提交于
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: NSZEDER Gábor <szeder@ira.uka.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 SZEDER Gábor 提交于
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: NSZEDER Gábor <szeder@ira.uka.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 2月, 2008 1 次提交
-
-
由 Jay Soffian 提交于
rebase supports --strategy, so pull should pass the option along to it. Signed-off-by: NJay Soffian <jaysoffian@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 1月, 2008 1 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 12月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 29 11月, 2007 1 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 11月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
--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: NJunio C Hamano <gitster@pobox.com>
-
- 30 10月, 2007 1 次提交
-
-
由 Lars Hjemli 提交于
These options are supported by git-merge, but git-pull didn't know about them. Signed-off-by: NLars Hjemli <hjemli@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 10月, 2007 1 次提交
-
-
由 Federico Mena Quintero 提交于
Signed-off-by: NFederico Mena Quintero <federico@gnu.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 24 9月, 2007 1 次提交
-
-
由 David Kastrup 提交于
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: NDavid Kastrup <dak@gnu.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 03 7月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 5月, 2007 1 次提交
-
-
由 Alex Riesen 提交于
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: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 1月, 2007 1 次提交
-
-
由 Jeff King 提交于
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: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 13 1月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 11 1月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 02 1月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 28 12月, 2006 3 次提交
-
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 12月, 2006 1 次提交
-
-
由 Josef Weidendorfer 提交于
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: NJosef Weidendorfer <weidendo@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 17 11月, 2006 1 次提交
-
-
由 Linus Torvalds 提交于
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: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 11 10月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 12 7月, 2006 1 次提交
-
-
由 Shawn Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 11 7月, 2006 1 次提交
-
-
由 Shawn Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 28 6月, 2006 1 次提交
-
-
由 Dennis Stosberg 提交于
Some implementations of "expr" (e.g. FreeBSD's) fail, if an argument starts with a dash. Signed-off-by: NDennis Stosberg <dennis@stosberg.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 24 6月, 2006 2 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 22 3月, 2006 2 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 18 3月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
... as discussed on the list for consistency. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 3月, 2006 1 次提交
-
-
由 Mark Hollomon 提交于
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: NMark Hollomon <markhollomon@comcast.net> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 12 2月, 2006 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 14 12月, 2005 1 次提交
-
-
由 freku045@student.liu.se 提交于
Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 26 11月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 10 11月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 08 11月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 07 11月, 2005 1 次提交
-
-
由 Jon Loeliger 提交于
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: NJon Loeliger <jdl@freescale.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 05 11月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
Pasky and I did overlapping documentation independently; this is to pick up better wordings from what he sent me. Signed-off-by: NPetr Baudis <pasky@suse.cz> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 04 11月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 04 10月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <junkio@cox.net>
-