I thought it could be easier to use check_GNU_style.py.  With this alias,
'git gcc-style' will take a git revision as argument instead of a file, or
check HEAD if no argument is given.

contrib/ChangeLog:

	* gcc-git-customization.sh: Add git gcc-style alias.

contrib/ChangeLog:

	PR other/111359
	* gcc-git-customization.sh: Check for getent before using it.
	Use id on macOS.

Use printf instead of echo -n. Use Basic Regular Expressions instead of
sed -r. Check for error from ancient Git versions that don't support the
--git-path option for git-rev-parse. Remove -c flag from install
command, as it's ignored by GNU and BSD install, but means something
different for Solaris and AIX.

contrib/ChangeLog:

	PR other/102664
	* gcc-git-customization.sh: Fix non-portable commands.

contrib/ChangeLog:

	* git-descr.sh: New file.
	* git-undescr.sh: New file.
	Support optional arguments --long, --short and default
	to 14 characters of git hash.
	* gcc-git-customization.sh: Use the created files.

Co-Authored-By: Martin Jambor <mjambor@suse.cz>

contrib/ChangeLog:

	* git-backport.py: Use it.
	* git-fix-changelog.py: New file.
	* gcc-git-customization.sh: Add new alias git gcc-fix-changelog.

The argument can be used for addition of Co-Authored-By lines
with --trailer='Co-Authored-By=Mona Lisa Octocat <mona@github.com>'.

contrib/ChangeLog:

	* gcc-git-customization.sh: Wrap $@ in quotes.
	* git-commit-mklog.py: Add new argument --co.
	* mklog.py: Skip the Co-Authored-By lines.

contrib/ChangeLog:

	* gcc-git-customization.sh: Use the new wrapper.
	* git-commit-mklog.py: New file.
	* prepare-commit-msg: Support GCC_MKLOG_ARGS.

I've been using

  git send-email --annotate --suppress-from --to=gcc-patches@gcc.gnu.org \
  ${@:-HEAD^} ':!*/ChangeLog' ':!*configure'

for sending most patches, but it occurs to me that it would be useful to put
the To: address in the configury.

If someone were feeling ambitious, they could write a script to analyze a
patch and add the relevant maintainers to To: or CC:.

contrib/ChangeLog:

	* gcc-git-customization.sh: Configure sendemail.to.

contrib/ChangeLog:

	* gcc-git-customization.sh: Use git-backport.py to drop
	all changes for ChangeLog files.
	* git-backport.py: New file.

contrib/ChangeLog:

	* gcc-git-customization.sh: Rename
	commit-mklog to gcc-commit-mklog.

This patch introduces a prepare-commit-msg hook that appends a ChangeLog
skeleton to a commit message when the GCC_FORCE_MKLOG environment variable
is set, and a 'git commit-mklog' command set that variable while running
'git commit'.

contrib/ChangeLog:

	* prepare-commit-msg: New file.
	* gcc-git-customization.sh: Install it.  Add commit-mklog alias.
	* mklog.py: Add new option -c which appends
	to a ChangeLog file.

	* gcc-changelog/git_commit.py: Support cherry pick
	prefix.
	* gcc-changelog/test_email.py: Test it.
	* gcc-changelog/test_patches.txt: Add new patch.
	* gcc-git-customization.sh: Add gcc-backport.

contrib/ChangeLog:

2020-05-15  Martin Liska  <mliska@suse.cz>

	* gcc-git-customization.sh: Add
	alias.gcc-mklog new hook.
	* mklog.py: New file.
	* test_mklog.py: New file.

	* gcc-git-customization.sh: Add gcc-verify alias
	that uses contrib/gcc-changelog/git_check_commit.py.

	* gcc-git-customization.sh: Search for the pattern
	at line beginning only.

Whilst trying to convert the add vendor branch script to work with
personal branches I encountered a minor issue where git would report
ambiguous refs when checking out the new branch.

It turns out that this is because git considers <me>/<topic> to be
ambiguous if both

  refs/heads/<me>/<topic>

and

  refs/remotes/<me>/<topic>

exist in the list of known branches.

Having thought about this a bit, I think the best solution is to adopt
something more like the vendors space and call the remote users/<me>
(this also works better if you want to set up remotes to track other
users branches as well).

So this patch has two parts.

1) It updates gcc-git-customization.sh to set up the new 'remote' and
converts any existing remote and branches tracking that to the new
format
2) It adds a new script to set up a personal branch on the gcc git repository.

	* gcc-git-customization.sh: Use users/<pfx> for the personal remote
	rather than just <pfx>.  Convert any existing personal branches to the
	new remote.
	* git-add-user-branch.sh: New file.

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.

As discussed on IRC, this adds a couple more checks in the
customization setup for git.  If the variables user.name and
user.email are not set anywhere in the git config hierarchy, we set
some local values.  We always ask about the values we detect and if
the user gives an answer that is new, we save that in the local
config: this gives the opportunity to use different values to those
configured for the global space.

Also cleaned up a couple of minor niggles, such as using $(cmd) rather
than `cmd` for subshells and some quoting issues when using eval.

	* gcc-git-customization.sh: Check that user.name and user.email
	are set.  Use $(cmd) instead of `cmd`.  Fix variable quoting when
	using eval.

contrib: Verify the id to be printed is ancestor of the corresponding remote release branch (or master), otherwise print nothing.

The monotonically increasing revision ids need to be globally unique, so they should
only identify commits that were committed to the upstream repo to its master or
releases/gcc-N branches.  The alias could print something even for private branches
or vendor branches etc., but if such an identifier is then used publicly, it will
refer to something else.

2020-01-16  Jakub Jelinek  <jakub@redhat.com>

	* gcc-git-customization.sh: Verify the id to be printed is ancestor of
	the corresponding remote release branch (or master), otherwise print
	nothing.

2020-01-15  Segher Boessenkool  <segher@kernel.crashing.org>
	    Jakub Jelinek  <jakub@redhat.com>

	* .gitattributes: Add *.md diff=md.
contrib/
	* gcc-git-customization.sh: Change uses to use in comment.

Originally, it seemed like a good idea to add automatic 'push' rules
to the git configuration, so that personal- and vendor-space commits
would automatically push to the right place.  Unfortunately, this
changes git's behaviour and with these settings "git push" will try to
push all branches in a local tree up to the corresponding location on
the server (ignoring the push.default setting).  The only known
mitigation for this is to ALWAYS use "git push <server> <branch>".

So instead, we no-longer add those rules by default and will document
the options on the wiki.  We don't automatically remove the push
entries but do print out the command that will do so, if the user so
wishes.

	* gcc-git-customization.sh: Explain why we want the user's
	upstream account name.  Don't add push rules.  Check if push rules
	have been added and suggest that they should be removed.
	* git-fetch-vendor.sh: Don't add push rules.

This reverts commit b60563a8.

Doesn't work as expected.

When we add a push rule, the default rule gets removed, so add that in
explicitly.  This needs to come last since otherwise it would match
the custom redirecting rules we have for personal and vendor
sub-spaces.

I also noticed that the push rule for the vendor subspace still had
a force push default.  We don't want that so remove it.

	* gcc-git-customization.sh: Add back the default rule that
	is lost by adding a custom push rule.
	* git-fetch-vendor.sh: Likewise, also remove '+' from push specs.

2020-01-13  Jakub Jelinek  <jakub@redhat.com>

	* contrib/gcc-git-customization.sh: Add git gcc-descr and gcc-undescr
	aliases.

This patch is intended to help with folks setting up a git work
environment for use with GCC following the transition to git.  It
currently does a couple of things.

1) Add an alias 'svn-rev' to git so that you can look up a legacy
commit by its svn revision number.  This enables you to type
	git svn-rev 1234
and git will show the commit log entry relating to SVN r1234.

2) Sets up tracking information for the user's personal area in
the git repo.  It tries to figure out some sensible answers to the
data it needs, but allows the user to override the values.  It then
creates the fetch and push entries that are needed for tracking the
extra refs. This implements one part of the recommendations that I've
proposed in svnwrite.html for dealing with private branches.

It should be possible to run the script more than once and for it to
DTRT.  If you change your answers the configuration should be
correctly updated.

2020-01-13  Richard Earnshaw  <rearnsha@arm.com>

    * gcc-git-customization: New file.