undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
f1250edff5
git-commit-vandalism/git-pull.sh

96 lines
2.3 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-18 21:15:10 +02: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 06:57:59 +02:00
# Copyright (c) 2005 Junio C Hamano
#
# Fetch one or more remote refs and merge it/them into the current HEAD.
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-13 23:30:31 +01:00
USAGE='[-n | --no-summary] [--no-commit] [-s strategy]... [<fetch-options>] <repo> <head>...'
LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
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-24 09:12:11 +01:00
. git-sh-setup
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 03:15:32 +02: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 04:30:11 +01: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 04:43:51 +02: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 04:30:11 +01: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 04:43:51 +02: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 "
;;
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-07 06:30:56 +01:00
-h|--h|--he|--hel|--help)
usage
;;
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 04:43:51 +02:00
-*)
git-pull: do not barf on -a flag meant for git-fetch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-04 00:45:44 +02: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 04:43:51 +02: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 03:14:27 +02: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 02:26:23 +02: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 03:15:32 +02: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 03:14:27 +02: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 03:15:32 +02: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 07:54:23 +02: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 11:57:26 +02: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 06:57:59 +02: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 04:43:51 +02:00
?*' '?*)
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 11:07:59 +01:00
var=`git-repo-config --get pull.octopus`
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 23:51:41 +01:00
if test -n "$var"
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-08 11:00:31 +01:00
then
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-11 21:39:11 +01:00
strategy_default_args="-s $var"
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-08 11:00:31 +01:00
fi
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 04:43:51 +02:00
;;
*)
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 11:07:59 +01:00
var=`git-repo-config --get pull.twohead`
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 23:51:41 +01:00
if test -n "$var"
then
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-11 21:39:11 +01:00
strategy_default_args="-s $var"
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-08 11:00:31 +01:00
fi
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 04:43:51 +02:00
;;
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-21 23:01:56 +02: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 11:57:26 +02: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 09:55:22 +02: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 04:30:11 +01:00
git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
Reference in New Issue Copy Permalink