2020-01-13 13:37:23 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
# Script to add some local git customizations suitable for working
|
|
|
|
# with the GCC git repository
|
|
|
|
|
|
|
|
ask () {
|
|
|
|
question=$1
|
|
|
|
default=$2
|
|
|
|
var=$3
|
2022-03-09 14:53:52 +00:00
|
|
|
printf "%s [%s]? " "$question" "$default"
|
2020-01-13 13:37:23 +00:00
|
|
|
read answer
|
|
|
|
if [ "x$answer" = "x" ]
|
|
|
|
then
|
2020-01-16 14:26:31 +00:00
|
|
|
eval $var=\$default
|
2020-01-13 13:37:23 +00:00
|
|
|
else
|
2020-01-16 14:26:31 +00:00
|
|
|
eval $var=\$answer
|
2020-01-13 13:37:23 +00:00
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
# Add a git command to find the git commit equivalent to legacy SVN revision NNN
|
2020-04-03 10:30:39 +00:00
|
|
|
git config alias.svn-rev '!f() { rev=$1; shift; git log --all --grep="^From-SVN: r\\?$rev\\b" "${@}"; } ; f'
|
2020-01-13 13:37:23 +00:00
|
|
|
|
2020-01-13 14:15:17 +00:00
|
|
|
# Add git commands to convert git commit to monotonically increasing revision number
|
|
|
|
# and vice versa
|
2022-01-27 15:01:55 +00:00
|
|
|
git config alias.gcc-descr '!f() { "`git rev-parse --show-toplevel`/contrib/git-descr.sh" $@; } ; f'
|
|
|
|
git config alias.gcc-undescr '!f() { "`git rev-parse --show-toplevel`/contrib/git-undescr.sh" $@; } ; f'
|
2020-01-13 14:15:17 +00:00
|
|
|
|
2020-05-19 07:19:18 +00:00
|
|
|
git config alias.gcc-verify '!f() { "`git rev-parse --show-toplevel`/contrib/gcc-changelog/git_check_commit.py" $@; } ; f'
|
2020-05-26 13:32:32 +00:00
|
|
|
git config alias.gcc-backport '!f() { "`git rev-parse --show-toplevel`/contrib/git-backport.py" $@; } ; f'
|
2022-01-19 06:57:05 +00:00
|
|
|
git config alias.gcc-fix-changelog '!f() { "`git rev-parse --show-toplevel`/contrib/git-fix-changelog.py" $@; } ; f'
|
2020-05-14 22:44:07 +00:00
|
|
|
git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.py" $@; } ; f'
|
2021-08-17 12:57:40 +00:00
|
|
|
git config alias.gcc-commit-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/git-commit-mklog.py" "$@"; }; f'
|
2023-12-12 00:38:32 +00:00
|
|
|
git config alias.gcc-style '!f() {
|
|
|
|
check=`git rev-parse --show-toplevel`/contrib/check_GNU_style.py;
|
|
|
|
arg=; if [ $# -ge 1 ] && [ "$1" != "-f" ]; then arg="$1"; shift;
|
|
|
|
elif [ $# -eq 3 ]; then arg="$3"; set -- "$1" "$2"; fi
|
|
|
|
git show $arg | $check "$@" -; }; f'
|
2020-05-22 22:40:35 +00:00
|
|
|
|
2020-01-15 13:29:53 +00:00
|
|
|
# Make diff on MD files use "(define" as a function marker.
|
2020-01-13 13:37:23 +00:00
|
|
|
# Use this in conjunction with a .gitattributes file containing
|
|
|
|
# *.md diff=md
|
|
|
|
git config diff.md.xfuncname '^\(define.*$'
|
|
|
|
|
2020-12-01 15:46:13 +00:00
|
|
|
# Tell git send-email where patches go.
|
|
|
|
# ??? Maybe also set sendemail.tocmd to guess from MAINTAINERS?
|
|
|
|
git config sendemail.to 'gcc-patches@gcc.gnu.org'
|
|
|
|
|
2020-01-16 13:48:37 +00:00
|
|
|
set_user=$(git config --get "user.name")
|
|
|
|
set_email=$(git config --get "user.email")
|
|
|
|
|
|
|
|
if [ "x$set_user" = "x" ]
|
|
|
|
then
|
|
|
|
# Try to guess the user's name by looking it up in the password file
|
2023-09-11 10:36:04 +00:00
|
|
|
if type getent >/dev/null 2>&1; then
|
|
|
|
new_user=$(getent passwd $(whoami) | awk -F: '{ print $5 }')
|
|
|
|
elif [ $(uname -s) = Darwin ]; then
|
|
|
|
new_user=$(id -F 2>/dev/null)
|
|
|
|
fi
|
2020-01-16 13:48:37 +00:00
|
|
|
if [ "x$new_user" = "x" ]
|
|
|
|
then
|
|
|
|
new_user="(no default)"
|
|
|
|
fi
|
|
|
|
else
|
|
|
|
new_user=$set_user
|
|
|
|
fi
|
|
|
|
ask "Your name" "${new_user}" new_user
|
|
|
|
if [ "x$new_user" = "x(no default)" ]
|
|
|
|
then
|
|
|
|
echo "Cannot continue, git needs to record your name against commits"
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ "x$set_email" = "x" ]
|
|
|
|
then
|
|
|
|
new_email="(no_default)"
|
|
|
|
else
|
|
|
|
new_email=$set_email
|
|
|
|
fi
|
|
|
|
|
|
|
|
ask "Your email address (for git commits)" "${new_email}" new_email
|
|
|
|
if [ "x$new_email" = "x(no default)" ]
|
|
|
|
then
|
|
|
|
echo "Cannot continue, git needs to record your email address against commits"
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ "x$set_user" != "x$new_user" ]
|
|
|
|
then
|
|
|
|
git config "user.name" "$new_user"
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ "x$set_email" != "x$new_email" ]
|
|
|
|
then
|
|
|
|
git config "user.email" "$new_email"
|
|
|
|
fi
|
|
|
|
|
|
|
|
upstream=$(git config --get "gcc-config.upstream")
|
2020-01-13 13:37:23 +00:00
|
|
|
if [ "x$upstream" = "x" ]
|
|
|
|
then
|
|
|
|
upstream="origin"
|
|
|
|
fi
|
|
|
|
ask "Local name for upstream repository" "origin" upstream
|
contrib: New remotes structure for vendor and personal refs
The initial structure for vendor and personal branches makes use of
the default remote (normally origin) for the upstream
repository). Unfortunately, this causes some confusion, especially for
personal branches because a push will not push to the correct upstream
location. This can be 'fixed' by adding a push refspec for the remote,
but that has the unfortunate consequence of breaking the push.default
behaviour for git push, and it becomes too easy to accidentally commit
something unintended to the main parts of the repository.
To work around this, this patch changes the configuration to use
separate 'remotes' for these additional refs, with one remote for the
personal space and another remote for each vendor's space. The
personal space is called after the user's preferred branch-space
prefix (default 'me'), the vendor spaces are called
vendors/<vendor-name>.
As far as possible, I've made the script automatically restructure any
existing fetch or push lines that earlier versions of the scripts may
have created - the gcc-git-customization.sh script will convert all
vendor refs that it can find, so it is not necessary to re-add any
vendors you've already added.
You might, however, want to run
git remote prune <origin>
after running to clean up any stale upstream-refs that might still be
in your local repo, and then
git fetch vendors/<vendor>
or
git fetch <me>
to re-populate the remotes/ structures.
Also, for any branch you already have that tracks a personal or vendor
branch upstream, you might need to run
git config branch.<name>.remote <new-remote>
so that merges and pushes go to the right place (I haven't attempted
to automate this last part).
For vendors, the new structure means that
git checkout -b <vendor>/<branch> remotes/vendors/<vendor>/<branch>
will correctly set up a remote tracking branch.
Please be aware that if you have multiple personal branches set up, then
git push <me>
will still consider all of them for pushing. If you only want to push
one branch, then either write
git push <me> HEAD
or
git push <me> <me>/branch
as appropriate.
And don't forget '-n' (--dry-run) to see what would be done if this
were not a dry run.
Finally, now that the vendors spaces are isolated from each other and
from the other spaces, I've added an option "--enable-push" to
git-fetch-vendor.sh. If passed, then a "push" spec will be added for
that vendor to enable pushing to the upstream. If you re-run the
script for the same vendor without the option, the push spec will be
removed.
* gcc-git-customization.sh: Check that user-supplied remote
name exists before continuting. Use a separate remotes for the
personal commit area. Convert existing personal and vendor
fetch rules to new layout.
* git-fetch-vendor.sh: New vendor layout. Add --enable-push
option.
2020-01-20 10:37:29 +00:00
|
|
|
|
|
|
|
v=$(git config --get-all "remote.${upstream}.fetch")
|
|
|
|
if [ "x$v" = "x" ]
|
|
|
|
then
|
|
|
|
echo "Remote $upstream does not seem to exist as a remote"
|
|
|
|
exit 1
|
|
|
|
fi
|
2020-01-13 13:37:23 +00:00
|
|
|
git config "gcc-config.upstream" "$upstream"
|
|
|
|
|
2020-01-16 13:48:37 +00:00
|
|
|
remote_id=$(git config --get "gcc-config.user")
|
2020-01-13 13:37:23 +00:00
|
|
|
if [ "x$remote_id" = "x" ]
|
|
|
|
then
|
|
|
|
# See if the url specifies the remote user name.
|
2020-01-16 13:48:37 +00:00
|
|
|
url=$(git config --get "remote.$upstream.url")
|
2020-01-13 13:37:23 +00:00
|
|
|
if [ "x$url" = "x" ]
|
|
|
|
then
|
|
|
|
# This is a pure guess, but for many people it might be OK.
|
2020-01-16 13:48:37 +00:00
|
|
|
remote_id=$(whoami)
|
2020-01-13 13:37:23 +00:00
|
|
|
else
|
2022-03-09 14:53:52 +00:00
|
|
|
remote_id=$(echo $url | sed 's|^.*ssh://\(..*\)@gcc.gnu.org.*$|\1|')
|
2020-01-13 13:37:23 +00:00
|
|
|
if [ x$remote_id = x$url ]
|
|
|
|
then
|
2020-01-16 13:48:37 +00:00
|
|
|
remote_id=$(whoami)
|
2020-01-13 13:37:23 +00:00
|
|
|
fi
|
|
|
|
fi
|
|
|
|
fi
|
contrib: New remotes structure for vendor and personal refs
The initial structure for vendor and personal branches makes use of
the default remote (normally origin) for the upstream
repository). Unfortunately, this causes some confusion, especially for
personal branches because a push will not push to the correct upstream
location. This can be 'fixed' by adding a push refspec for the remote,
but that has the unfortunate consequence of breaking the push.default
behaviour for git push, and it becomes too easy to accidentally commit
something unintended to the main parts of the repository.
To work around this, this patch changes the configuration to use
separate 'remotes' for these additional refs, with one remote for the
personal space and another remote for each vendor's space. The
personal space is called after the user's preferred branch-space
prefix (default 'me'), the vendor spaces are called
vendors/<vendor-name>.
As far as possible, I've made the script automatically restructure any
existing fetch or push lines that earlier versions of the scripts may
have created - the gcc-git-customization.sh script will convert all
vendor refs that it can find, so it is not necessary to re-add any
vendors you've already added.
You might, however, want to run
git remote prune <origin>
after running to clean up any stale upstream-refs that might still be
in your local repo, and then
git fetch vendors/<vendor>
or
git fetch <me>
to re-populate the remotes/ structures.
Also, for any branch you already have that tracks a personal or vendor
branch upstream, you might need to run
git config branch.<name>.remote <new-remote>
so that merges and pushes go to the right place (I haven't attempted
to automate this last part).
For vendors, the new structure means that
git checkout -b <vendor>/<branch> remotes/vendors/<vendor>/<branch>
will correctly set up a remote tracking branch.
Please be aware that if you have multiple personal branches set up, then
git push <me>
will still consider all of them for pushing. If you only want to push
one branch, then either write
git push <me> HEAD
or
git push <me> <me>/branch
as appropriate.
And don't forget '-n' (--dry-run) to see what would be done if this
were not a dry run.
Finally, now that the vendors spaces are isolated from each other and
from the other spaces, I've added an option "--enable-push" to
git-fetch-vendor.sh. If passed, then a "push" spec will be added for
that vendor to enable pushing to the upstream. If you re-run the
script for the same vendor without the option, the push spec will be
removed.
* gcc-git-customization.sh: Check that user-supplied remote
name exists before continuting. Use a separate remotes for the
personal commit area. Convert existing personal and vendor
fetch rules to new layout.
* git-fetch-vendor.sh: New vendor layout. Add --enable-push
option.
2020-01-20 10:37:29 +00:00
|
|
|
|
2022-03-09 14:53:52 +00:00
|
|
|
ask "Account name on gcc.gnu.org (for your personal branches area)" "$remote_id" remote_id
|
2020-01-13 13:37:23 +00:00
|
|
|
git config "gcc-config.user" "$remote_id"
|
|
|
|
|
2020-01-16 13:48:37 +00:00
|
|
|
old_pfx=$(git config --get "gcc-config.userpfx")
|
2020-01-13 13:37:23 +00:00
|
|
|
if [ "x$old_pfx" = "x" ]
|
|
|
|
then
|
|
|
|
old_pfx="me"
|
|
|
|
fi
|
contrib: New remotes structure for vendor and personal refs
The initial structure for vendor and personal branches makes use of
the default remote (normally origin) for the upstream
repository). Unfortunately, this causes some confusion, especially for
personal branches because a push will not push to the correct upstream
location. This can be 'fixed' by adding a push refspec for the remote,
but that has the unfortunate consequence of breaking the push.default
behaviour for git push, and it becomes too easy to accidentally commit
something unintended to the main parts of the repository.
To work around this, this patch changes the configuration to use
separate 'remotes' for these additional refs, with one remote for the
personal space and another remote for each vendor's space. The
personal space is called after the user's preferred branch-space
prefix (default 'me'), the vendor spaces are called
vendors/<vendor-name>.
As far as possible, I've made the script automatically restructure any
existing fetch or push lines that earlier versions of the scripts may
have created - the gcc-git-customization.sh script will convert all
vendor refs that it can find, so it is not necessary to re-add any
vendors you've already added.
You might, however, want to run
git remote prune <origin>
after running to clean up any stale upstream-refs that might still be
in your local repo, and then
git fetch vendors/<vendor>
or
git fetch <me>
to re-populate the remotes/ structures.
Also, for any branch you already have that tracks a personal or vendor
branch upstream, you might need to run
git config branch.<name>.remote <new-remote>
so that merges and pushes go to the right place (I haven't attempted
to automate this last part).
For vendors, the new structure means that
git checkout -b <vendor>/<branch> remotes/vendors/<vendor>/<branch>
will correctly set up a remote tracking branch.
Please be aware that if you have multiple personal branches set up, then
git push <me>
will still consider all of them for pushing. If you only want to push
one branch, then either write
git push <me> HEAD
or
git push <me> <me>/branch
as appropriate.
And don't forget '-n' (--dry-run) to see what would be done if this
were not a dry run.
Finally, now that the vendors spaces are isolated from each other and
from the other spaces, I've added an option "--enable-push" to
git-fetch-vendor.sh. If passed, then a "push" spec will be added for
that vendor to enable pushing to the upstream. If you re-run the
script for the same vendor without the option, the push spec will be
removed.
* gcc-git-customization.sh: Check that user-supplied remote
name exists before continuting. Use a separate remotes for the
personal commit area. Convert existing personal and vendor
fetch rules to new layout.
* git-fetch-vendor.sh: New vendor layout. Add --enable-push
option.
2020-01-20 10:37:29 +00:00
|
|
|
echo
|
2020-01-13 13:37:23 +00:00
|
|
|
echo "Local branch prefix for personal branches you want to share"
|
|
|
|
echo "(local branches starting <prefix>/ can be pushed directly to your"
|
|
|
|
ask "personal area on the gcc server)" $old_pfx new_pfx
|
|
|
|
git config "gcc-config.userpfx" "$new_pfx"
|
|
|
|
|
2020-05-22 22:40:35 +00:00
|
|
|
echo
|
|
|
|
ask "Install prepare-commit-msg git hook for 'git commit-mklog' alias" yes dohook
|
|
|
|
if [ "x$dohook" = xyes ]; then
|
2022-03-09 14:53:52 +00:00
|
|
|
hookdir=`git rev-parse --git-path hooks 2>/dev/null`
|
|
|
|
if [ $? -eq 0 ]; then
|
|
|
|
if [ -f "$hookdir/prepare-commit-msg" ]; then
|
|
|
|
echo " Moving existing prepare-commit-msg hook to prepare-commit-msg.bak"
|
|
|
|
mv "$hookdir/prepare-commit-msg" "$hookdir/prepare-commit-msg.bak"
|
|
|
|
fi
|
|
|
|
install -c "`git rev-parse --show-toplevel`/contrib/prepare-commit-msg" "$hookdir"
|
|
|
|
else
|
|
|
|
echo " `git --version` is too old, cannot find hooks dir"
|
2020-05-22 22:40:35 +00:00
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
contrib: New remotes structure for vendor and personal refs
The initial structure for vendor and personal branches makes use of
the default remote (normally origin) for the upstream
repository). Unfortunately, this causes some confusion, especially for
personal branches because a push will not push to the correct upstream
location. This can be 'fixed' by adding a push refspec for the remote,
but that has the unfortunate consequence of breaking the push.default
behaviour for git push, and it becomes too easy to accidentally commit
something unintended to the main parts of the repository.
To work around this, this patch changes the configuration to use
separate 'remotes' for these additional refs, with one remote for the
personal space and another remote for each vendor's space. The
personal space is called after the user's preferred branch-space
prefix (default 'me'), the vendor spaces are called
vendors/<vendor-name>.
As far as possible, I've made the script automatically restructure any
existing fetch or push lines that earlier versions of the scripts may
have created - the gcc-git-customization.sh script will convert all
vendor refs that it can find, so it is not necessary to re-add any
vendors you've already added.
You might, however, want to run
git remote prune <origin>
after running to clean up any stale upstream-refs that might still be
in your local repo, and then
git fetch vendors/<vendor>
or
git fetch <me>
to re-populate the remotes/ structures.
Also, for any branch you already have that tracks a personal or vendor
branch upstream, you might need to run
git config branch.<name>.remote <new-remote>
so that merges and pushes go to the right place (I haven't attempted
to automate this last part).
For vendors, the new structure means that
git checkout -b <vendor>/<branch> remotes/vendors/<vendor>/<branch>
will correctly set up a remote tracking branch.
Please be aware that if you have multiple personal branches set up, then
git push <me>
will still consider all of them for pushing. If you only want to push
one branch, then either write
git push <me> HEAD
or
git push <me> <me>/branch
as appropriate.
And don't forget '-n' (--dry-run) to see what would be done if this
were not a dry run.
Finally, now that the vendors spaces are isolated from each other and
from the other spaces, I've added an option "--enable-push" to
git-fetch-vendor.sh. If passed, then a "push" spec will be added for
that vendor to enable pushing to the upstream. If you re-run the
script for the same vendor without the option, the push spec will be
removed.
* gcc-git-customization.sh: Check that user-supplied remote
name exists before continuting. Use a separate remotes for the
personal commit area. Convert existing personal and vendor
fetch rules to new layout.
* git-fetch-vendor.sh: New vendor layout. Add --enable-push
option.
2020-01-20 10:37:29 +00:00
|
|
|
# Scan the existing settings to see if there are any we need to rewrite.
|
2022-03-09 14:53:52 +00:00
|
|
|
vendors=$(git config --get-all "remote.${upstream}.fetch" "refs/vendors/" | sed 's:.*refs/vendors/\([^/][^/]*\)/.*:\1:' | sort | uniq)
|
contrib: New remotes structure for vendor and personal refs
The initial structure for vendor and personal branches makes use of
the default remote (normally origin) for the upstream
repository). Unfortunately, this causes some confusion, especially for
personal branches because a push will not push to the correct upstream
location. This can be 'fixed' by adding a push refspec for the remote,
but that has the unfortunate consequence of breaking the push.default
behaviour for git push, and it becomes too easy to accidentally commit
something unintended to the main parts of the repository.
To work around this, this patch changes the configuration to use
separate 'remotes' for these additional refs, with one remote for the
personal space and another remote for each vendor's space. The
personal space is called after the user's preferred branch-space
prefix (default 'me'), the vendor spaces are called
vendors/<vendor-name>.
As far as possible, I've made the script automatically restructure any
existing fetch or push lines that earlier versions of the scripts may
have created - the gcc-git-customization.sh script will convert all
vendor refs that it can find, so it is not necessary to re-add any
vendors you've already added.
You might, however, want to run
git remote prune <origin>
after running to clean up any stale upstream-refs that might still be
in your local repo, and then
git fetch vendors/<vendor>
or
git fetch <me>
to re-populate the remotes/ structures.
Also, for any branch you already have that tracks a personal or vendor
branch upstream, you might need to run
git config branch.<name>.remote <new-remote>
so that merges and pushes go to the right place (I haven't attempted
to automate this last part).
For vendors, the new structure means that
git checkout -b <vendor>/<branch> remotes/vendors/<vendor>/<branch>
will correctly set up a remote tracking branch.
Please be aware that if you have multiple personal branches set up, then
git push <me>
will still consider all of them for pushing. If you only want to push
one branch, then either write
git push <me> HEAD
or
git push <me> <me>/branch
as appropriate.
And don't forget '-n' (--dry-run) to see what would be done if this
were not a dry run.
Finally, now that the vendors spaces are isolated from each other and
from the other spaces, I've added an option "--enable-push" to
git-fetch-vendor.sh. If passed, then a "push" spec will be added for
that vendor to enable pushing to the upstream. If you re-run the
script for the same vendor without the option, the push spec will be
removed.
* gcc-git-customization.sh: Check that user-supplied remote
name exists before continuting. Use a separate remotes for the
personal commit area. Convert existing personal and vendor
fetch rules to new layout.
* git-fetch-vendor.sh: New vendor layout. Add --enable-push
option.
2020-01-20 10:37:29 +00:00
|
|
|
url=$(git config --get "remote.${upstream}.url")
|
|
|
|
pushurl=$(git config --get "remote.${upstream}.pushurl")
|
|
|
|
for v in $vendors
|
|
|
|
do
|
2020-01-24 14:38:16 +00:00
|
|
|
echo "Migrating vendor \"$v\" to new remote \"vendors/$v\""
|
contrib: New remotes structure for vendor and personal refs
The initial structure for vendor and personal branches makes use of
the default remote (normally origin) for the upstream
repository). Unfortunately, this causes some confusion, especially for
personal branches because a push will not push to the correct upstream
location. This can be 'fixed' by adding a push refspec for the remote,
but that has the unfortunate consequence of breaking the push.default
behaviour for git push, and it becomes too easy to accidentally commit
something unintended to the main parts of the repository.
To work around this, this patch changes the configuration to use
separate 'remotes' for these additional refs, with one remote for the
personal space and another remote for each vendor's space. The
personal space is called after the user's preferred branch-space
prefix (default 'me'), the vendor spaces are called
vendors/<vendor-name>.
As far as possible, I've made the script automatically restructure any
existing fetch or push lines that earlier versions of the scripts may
have created - the gcc-git-customization.sh script will convert all
vendor refs that it can find, so it is not necessary to re-add any
vendors you've already added.
You might, however, want to run
git remote prune <origin>
after running to clean up any stale upstream-refs that might still be
in your local repo, and then
git fetch vendors/<vendor>
or
git fetch <me>
to re-populate the remotes/ structures.
Also, for any branch you already have that tracks a personal or vendor
branch upstream, you might need to run
git config branch.<name>.remote <new-remote>
so that merges and pushes go to the right place (I haven't attempted
to automate this last part).
For vendors, the new structure means that
git checkout -b <vendor>/<branch> remotes/vendors/<vendor>/<branch>
will correctly set up a remote tracking branch.
Please be aware that if you have multiple personal branches set up, then
git push <me>
will still consider all of them for pushing. If you only want to push
one branch, then either write
git push <me> HEAD
or
git push <me> <me>/branch
as appropriate.
And don't forget '-n' (--dry-run) to see what would be done if this
were not a dry run.
Finally, now that the vendors spaces are isolated from each other and
from the other spaces, I've added an option "--enable-push" to
git-fetch-vendor.sh. If passed, then a "push" spec will be added for
that vendor to enable pushing to the upstream. If you re-run the
script for the same vendor without the option, the push spec will be
removed.
* gcc-git-customization.sh: Check that user-supplied remote
name exists before continuting. Use a separate remotes for the
personal commit area. Convert existing personal and vendor
fetch rules to new layout.
* git-fetch-vendor.sh: New vendor layout. Add --enable-push
option.
2020-01-20 10:37:29 +00:00
|
|
|
git config --unset-all "remote.${upstream}.fetch" "refs/vendors/$v/"
|
|
|
|
git config --unset-all "remote.${upstream}.push" "refs/vendors/$v/"
|
|
|
|
git config "remote.vendors/${v}.url" "${url}"
|
|
|
|
if [ "x$pushurl" != "x" ]
|
|
|
|
then
|
|
|
|
git config "remote.vendors/${v}.pushurl" "${pushurl}"
|
|
|
|
fi
|
|
|
|
git config --add "remote.vendors/${v}.fetch" "+refs/vendors/$v/heads/*:refs/remotes/vendors/${v}/*"
|
|
|
|
git config --add "remote.vendors/${v}.fetch" "+refs/vendors/$v/tags/*:refs/tags/vendors/${v}/*"
|
|
|
|
done
|
2020-01-15 11:30:07 +00:00
|
|
|
|
2020-01-24 14:38:16 +00:00
|
|
|
# Convert the remote 'pfx' to users/pfx to avoid problems with ambiguous refs
|
|
|
|
# on user branches
|
|
|
|
old_remote=$(git config --get "remote.${old_pfx}.url")
|
|
|
|
if [ -n "${old_remote}" ]
|
|
|
|
then
|
|
|
|
echo "Migrating remote \"${old_pfx}\" to new remote \"users/${new_pfx}\""
|
|
|
|
# Create a dummy fetch rule that will cause the subsequent prune to remove the old remote refs.
|
|
|
|
git config --replace-all "remote.${old_pfx}.fetch" "+refs/empty/*:refs/remotes/${old_pfx}/*"
|
|
|
|
# Remove any remotes
|
|
|
|
git remote prune ${old_pfx}
|
|
|
|
git config --remove-section "remote.${old_pfx}"
|
|
|
|
for br in $(git branch --list "${old_pfx}/*")
|
|
|
|
do
|
|
|
|
old_remote=$(git config --get "branch.${br}.remote")
|
|
|
|
if [ "${old_remote}" = "${old_pfx}" ]
|
|
|
|
then
|
|
|
|
git config "branch.${br}.remote" "users/${new_pfx}"
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
fi
|
|
|
|
|
|
|
|
echo "Setting up tracking for personal namespace $remote_id in remotes/users/${new_pfx}"
|
|
|
|
git config "remote.users/${new_pfx}.url" "${url}"
|
contrib: New remotes structure for vendor and personal refs
The initial structure for vendor and personal branches makes use of
the default remote (normally origin) for the upstream
repository). Unfortunately, this causes some confusion, especially for
personal branches because a push will not push to the correct upstream
location. This can be 'fixed' by adding a push refspec for the remote,
but that has the unfortunate consequence of breaking the push.default
behaviour for git push, and it becomes too easy to accidentally commit
something unintended to the main parts of the repository.
To work around this, this patch changes the configuration to use
separate 'remotes' for these additional refs, with one remote for the
personal space and another remote for each vendor's space. The
personal space is called after the user's preferred branch-space
prefix (default 'me'), the vendor spaces are called
vendors/<vendor-name>.
As far as possible, I've made the script automatically restructure any
existing fetch or push lines that earlier versions of the scripts may
have created - the gcc-git-customization.sh script will convert all
vendor refs that it can find, so it is not necessary to re-add any
vendors you've already added.
You might, however, want to run
git remote prune <origin>
after running to clean up any stale upstream-refs that might still be
in your local repo, and then
git fetch vendors/<vendor>
or
git fetch <me>
to re-populate the remotes/ structures.
Also, for any branch you already have that tracks a personal or vendor
branch upstream, you might need to run
git config branch.<name>.remote <new-remote>
so that merges and pushes go to the right place (I haven't attempted
to automate this last part).
For vendors, the new structure means that
git checkout -b <vendor>/<branch> remotes/vendors/<vendor>/<branch>
will correctly set up a remote tracking branch.
Please be aware that if you have multiple personal branches set up, then
git push <me>
will still consider all of them for pushing. If you only want to push
one branch, then either write
git push <me> HEAD
or
git push <me> <me>/branch
as appropriate.
And don't forget '-n' (--dry-run) to see what would be done if this
were not a dry run.
Finally, now that the vendors spaces are isolated from each other and
from the other spaces, I've added an option "--enable-push" to
git-fetch-vendor.sh. If passed, then a "push" spec will be added for
that vendor to enable pushing to the upstream. If you re-run the
script for the same vendor without the option, the push spec will be
removed.
* gcc-git-customization.sh: Check that user-supplied remote
name exists before continuting. Use a separate remotes for the
personal commit area. Convert existing personal and vendor
fetch rules to new layout.
* git-fetch-vendor.sh: New vendor layout. Add --enable-push
option.
2020-01-20 10:37:29 +00:00
|
|
|
if [ "x$pushurl" != "x" ]
|
2020-01-15 11:30:07 +00:00
|
|
|
then
|
2020-01-24 14:38:16 +00:00
|
|
|
git config "remote.users/${new_pfx}.pushurl" "${pushurl}"
|
2020-01-15 11:30:07 +00:00
|
|
|
fi
|
2020-01-24 14:38:16 +00:00
|
|
|
git config --replace-all "remote.users/${new_pfx}.fetch" "+refs/users/${remote_id}/heads/*:refs/remotes/users/${new_pfx}/*" "refs/users/${remote_id}/heads/"
|
|
|
|
git config --replace-all "remote.users/${new_pfx}.fetch" "+refs/users/${remote_id}/tags/*:refs/tags/users/${new_pfx}/*" "refs/users/${remote_id}/tags/"
|
|
|
|
git config --replace-all "remote.users/${new_pfx}.push" "refs/heads/${new_pfx}/*:refs/users/${remote_id}/heads/*" "refs/users/${remote_id}"
|
contrib: New remotes structure for vendor and personal refs
The initial structure for vendor and personal branches makes use of
the default remote (normally origin) for the upstream
repository). Unfortunately, this causes some confusion, especially for
personal branches because a push will not push to the correct upstream
location. This can be 'fixed' by adding a push refspec for the remote,
but that has the unfortunate consequence of breaking the push.default
behaviour for git push, and it becomes too easy to accidentally commit
something unintended to the main parts of the repository.
To work around this, this patch changes the configuration to use
separate 'remotes' for these additional refs, with one remote for the
personal space and another remote for each vendor's space. The
personal space is called after the user's preferred branch-space
prefix (default 'me'), the vendor spaces are called
vendors/<vendor-name>.
As far as possible, I've made the script automatically restructure any
existing fetch or push lines that earlier versions of the scripts may
have created - the gcc-git-customization.sh script will convert all
vendor refs that it can find, so it is not necessary to re-add any
vendors you've already added.
You might, however, want to run
git remote prune <origin>
after running to clean up any stale upstream-refs that might still be
in your local repo, and then
git fetch vendors/<vendor>
or
git fetch <me>
to re-populate the remotes/ structures.
Also, for any branch you already have that tracks a personal or vendor
branch upstream, you might need to run
git config branch.<name>.remote <new-remote>
so that merges and pushes go to the right place (I haven't attempted
to automate this last part).
For vendors, the new structure means that
git checkout -b <vendor>/<branch> remotes/vendors/<vendor>/<branch>
will correctly set up a remote tracking branch.
Please be aware that if you have multiple personal branches set up, then
git push <me>
will still consider all of them for pushing. If you only want to push
one branch, then either write
git push <me> HEAD
or
git push <me> <me>/branch
as appropriate.
And don't forget '-n' (--dry-run) to see what would be done if this
were not a dry run.
Finally, now that the vendors spaces are isolated from each other and
from the other spaces, I've added an option "--enable-push" to
git-fetch-vendor.sh. If passed, then a "push" spec will be added for
that vendor to enable pushing to the upstream. If you re-run the
script for the same vendor without the option, the push spec will be
removed.
* gcc-git-customization.sh: Check that user-supplied remote
name exists before continuting. Use a separate remotes for the
personal commit area. Convert existing personal and vendor
fetch rules to new layout.
* git-fetch-vendor.sh: New vendor layout. Add --enable-push
option.
2020-01-20 10:37:29 +00:00
|
|
|
|
|
|
|
if [ "$old_pfx" != "$new_pfx" -a "$old_pfx" != "${upstream}" ]
|
|
|
|
then
|
|
|
|
git config --remove-section "remote.${old_pfx}"
|
|
|
|
fi
|
|
|
|
|
|
|
|
git config --unset-all "remote.${upstream}.fetch" "refs/users/${remote_id}/"
|
|
|
|
git config --unset-all "remote.${upstream}.push" "refs/users/${remote_id}/"
|
2020-01-24 14:38:16 +00:00
|
|
|
|
|
|
|
git fetch "users/${new_pfx}"
|