mirrors/git
0
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-24 10:26:17 +08:00
Code Issues Packages Projects Releases Wiki Activity
90279074ca
git/git-pull.sh

87 lines
2.1 KiB
Bash
Raw Normal View History

Add the simple scripts I used to do a merge with content conflicts. They sure as hell aren't perfect, but they allow you to do: ./git-pull-script {other-git-directory} to do the initial merge, and if that had content clashes, you do merge-cache ./git-merge-one-file-script -a which tries to auto-merge. When/if the auto-merge fails, it will leave the last file in your working directory, and you can edit it and then when you're happy you can do "update-cache filename" on it. Re-do the merge-cache thing until there are no files left to be merged, and now you can write the tree and commit: write-tree commit-tree .... -p $(cat .git/HEAD) -p $(cat .git/MERGE_HEAD) and you're done.
2005-04-19 03:15:10 +08:00
#!/bin/sh
#
[PATCH] Use git-octopus when pulling more than one heads. With this, you can finally say "git pull jgarzik sil24 pdc2027x". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 12:57:59 +08:00
# Copyright (c) 2005 Junio C Hamano
#
# Fetch one or more remote refs and merge it/them into the current HEAD.
Big tool rename. As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-08 08:26:23 +08:00
. git-sh-setup || die "Not a git archive"
Fix pulling into the same branch. When the "git pull" command updates the branch head you are currently on, before doing anything else, first update your index file and the working tree contents to that of the new branch head. Otherwise, the later resolving steps would think your index file is attempting to revert the change between the original head commit and the updated head commit. It uses two-tree fast-forward form of "read-tree -m -u" to prevent losing whatever local changes you may have in the working tree to do this update. I think this would at least make things safer (a lot safer), and prevent mistakes. Also "git fetch" command is forbidden from fetching and fast forwarding the current branch head unless --update-head-ok flag is given. "git pull" passes the flag when it internally calls "git fetch". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26 09:15:32 +08:00
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-26 10:43:51 +08:00
usage () {
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-05 10:17:16 +08:00
die "git pull [-n] [--no-commit] [-s strategy]... <repo> <head>..."
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-26 10:43:51 +08:00
}
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-02 11:30:11 +08:00
strategy_args= no_summary= no_commit=
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-26 10:43:51 +08:00
while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
do
case "$1" in
-n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
--no-summa|--no-summar|--no-summary)
no_summary=-n ;;
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-02 11:30:11 +08:00
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
no_commit=--no-commit ;;
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-26 10:43:51 +08:00
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
case "$#,$1" in
*,*=*)
strategy=`expr "$1" : '-[^=]*=\(.*\)'` ;;
1,*)
usage ;;
*)
strategy="$2"
shift ;;
esac
strategy_args="${strategy_args}-s $strategy "
;;
-*)
git-pull: do not barf on -a flag meant for git-fetch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-04 06:45:44 +08:00
# Pass thru anything that is meant for fetch.
break
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-26 10:43:51 +08:00
;;
esac
shift
done
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 09:14:27 +08:00
orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
Big tool rename. As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-08 08:26:23 +08:00
git-fetch --update-head-ok "$@" || exit 1
Fix pulling into the same branch. When the "git pull" command updates the branch head you are currently on, before doing anything else, first update your index file and the working tree contents to that of the new branch head. Otherwise, the later resolving steps would think your index file is attempting to revert the change between the original head commit and the updated head commit. It uses two-tree fast-forward form of "read-tree -m -u" to prevent losing whatever local changes you may have in the working tree to do this update. I think this would at least make things safer (a lot safer), and prevent mistakes. Also "git fetch" command is forbidden from fetching and fast forwarding the current branch head unless --update-head-ok flag is given. "git pull" passes the flag when it internally calls "git fetch". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26 09:15:32 +08:00
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 09:14:27 +08:00
curr_head=$(git-rev-parse --verify HEAD)
Fix pulling into the same branch. When the "git pull" command updates the branch head you are currently on, before doing anything else, first update your index file and the working tree contents to that of the new branch head. Otherwise, the later resolving steps would think your index file is attempting to revert the change between the original head commit and the updated head commit. It uses two-tree fast-forward form of "read-tree -m -u" to prevent losing whatever local changes you may have in the working tree to do this update. I think this would at least make things safer (a lot safer), and prevent mistakes. Also "git fetch" command is forbidden from fetching and fast forwarding the current branch head unless --update-head-ok flag is given. "git pull" passes the flag when it internally calls "git fetch". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-26 09:15:32 +08:00
if test "$curr_head" != "$orig_head"
then
# The fetch involved updating the current branch.
# The working tree and the index file is still based on the
# $orig_head commit, but we are merging into $curr_head.
# First update the working tree to match $curr_head.
echo >&2 "Warning: fetch updated the current branch head."
echo >&2 "Warning: fast forwarding your working tree."
git-read-tree -u -m "$orig_head" "$curr_head" ||
die "You need to first update your working tree."
fi
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-26 13:54:23 +08:00
merge_head=$(sed -e '/ not-for-merge /d' \
-e 's/ .*//' "$GIT_DIR"/FETCH_HEAD | \
tr '\012' ' ')
[PATCH] Retire git-parse-remote. Update git-pull to match updated git-fetch and allow pull to fetch from multiple remote references. There is no support for resolving more than two heads, which will be done with "git octopus". Update "git ls-remote" to use git-parse-remote-script. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 17:57:26 +08:00
case "$merge_head" in
[PATCH] Use git-octopus when pulling more than one heads. With this, you can finally say "git pull jgarzik sil24 pdc2027x". Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-23 12:57:59 +08:00
'')
echo >&2 "No changes."
exit 0
;;
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-26 10:43:51 +08:00
?*' '?*)
strategy_default_args='-s octopus'
;;
*)
strategy_default_args='-s resolve'
;;
esac
case "$strategy_args" in
'')
strategy_args=$strategy_default_args
Revert "Use git-merge instead of git-resolve in git-pull." This reverts f887564ab72e107bcdee3ba83c91e2bb4ae13ca7 commit.
2005-09-22 05:01:56 +08:00
;;
[PATCH] Retire git-parse-remote. Update git-pull to match updated git-fetch and allow pull to fetch from multiple remote references. There is no support for resolving more than two heads, which will be done with "git octopus". Update "git ls-remote" to use git-parse-remote-script. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-20 17:57:26 +08:00
esac
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 15:55:22 +08:00
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
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-02 11:30:11 +08:00
git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
Reference in New Issue Copy Permalink