On July 5, 2021 10:03 AM, I wrote: >On July 2, 2021 6:38 PM, martin wrote: >>To: Felipe Contreras <felipe.contreras@xxxxxxxxx>; Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> >>Cc: git@xxxxxxxxxxxxxxx; Junio C Hamano <gitster@xxxxxxxxx> >>Subject: Re: [PATCH 5/5] config: add default aliases >> >>On 02/07/2021 23:58, Felipe Contreras wrote: >>> Ævar Arnfjörð Bjarmason wrote: >>>>> +ALIAS >>>>> +~~~~~ >>>>> +'git rb' >>>> So 'r'e'b'ase, not 're'base. >>> I don't know if 're' makes more sense here. >> >>re: >>restore >>rebase >>reset >> >>And restore is on the level of checkout => so more important. > >I do not want anything helping out the use of rebase, which we actively discourage in our shop - except for rebase --autosquash to fix up >topic branches for delivery. git 're' is certainly not helpful. > >>From an earlier suggestion, why not just put all of your desired aliases in its own file somewhere and reference them through a construct >in .gitconfig like: > >include="/path/to/alias-config" > >which would have to be implemented, but that decouples alias definitions from core git code and allows sharing of the definitions by a >team without impinging on anyone else. I have great trepidation that users are going to start writing scripts using these aliases. I am >going to be implementing a team standards document that would cause any use of aliases in scripts to fail code reviews - in fact, I'm >looking to implement a commit hook that rejects the use of aliases in scripts that are committed. This is already in place in .gitconfig: [include] path = /path/to/git-aliases So whatever a team's alias set needs to be can be completely decoupled from git and put into its own repo, and delivered to the team that way. I'm going to recommend that my team uses this for alias management instead of this patch set. -Randall
