{〈GitHub〉}{〈GitLab〉}{~/.local/srv/git/gh/}{仕類即譜からGitの構成譜に適した形式に変換する}{〈Git〉}{台録}{pwd}{Gitの構成譜}{Gitにおける別名}{台録構造}...=}(14)

{台録を認識して,cloneする引数の省略を補えるようにする K#D657/30EE}

わたしはたとえばGitHub収庫から入手したものは
~/.local/srv/git/gh/{{user/orgname}}/{{reponame}}に保管しているが
git cloneするときにそれが.../gh/{{user/orgname}}という経路にいることは
わかるんだから,

$ pwd
.../gh/fvwmorg/
$ git c1 fvwm3 # = 'git://github.com/fvwmorg/fvwm3'

とか打てると嬉しいかも。


pwd | sed -ne 's/.*\/\([^/]\{1,\}\)\/\([^/]\{1,\}\)\/\{0,1\}/\1 \2/p'

検討

git提供方の構造がかなり違う場合がある

GitLabなんかは,その企業専用の用地であっても,「利用者名」に相当する階層構造があるが,git.sv.gnu.orgなんかは,頂上下に一つだけ階層があり,それがいきなりgit台録。まあ,これは「利用者」がいない場合の構造としてはそう不自然ではない。また,この場合は,git.sv.nongnu.orgと分ける,みたいな考えもできるけどそれはこの場合(GNU,非GNUの区別がある)に限られるし,そもそも「変数となる階層名がきっかり二つある」という状況は別にgitの要件でも仕様でもなんでもない。

いやもう,その時は別に手で打てばいいか。

上を受けて

GitHubみたいに変数が二つある場合でも

$ cd ~/.var/srv/git/gh
$ git c1 fvwmorg/fvwm3

と打てると便利じゃないか?

実装としては,まず引数に/が含まれているか,
そして含まれていれば「2変数かつ2変数指定」
含まれていなければまた場合分け。
そのときは,2段上の階層が短縮語一覧に登録済みか
→違うなら1段上


[alias]
	c1test = !printf '!!!%s!!!\\n'
# ↑こうすると実質的に引数を処理できる
	c1test = !sh -c 'echo $1' sh
	c1test = !sh -c '\
	          "echo a; echo b\n"\
	          "pwd; dirname .\n"\
	          "echo $1"\
	          ' sh
# ↑あるいはこう
# こっちのほうが汎用性高そうだが,「なぜうまくいくのか分からない」
# のでこわい。

gitの構成譜の書式↓
https://git-scm.com/docs/git-config#_syntax
\で越化されるのは"\自身。

{〈Git〉}{Gitの構成譜}{変換}{仕類即譜}{傾楊子病}{仕類}=}(6)

{仕類即譜からGitの構成譜に適した形式に変換する K#D657/C6EA}

#!/bin/sh

printf '!sh -c \047\\\n'
sed -e '
s/'"'"'/'"'"'"&"'"'"'/g
s/[\\"]/\\&/g
s/^.*$/ "&\\n"\\/
'
printf ' \047 sh\n'
使用法
$ <<. cat | ./sh2gitconf.sh
echo a; echo b
pwd; dirname .
printf '"dq" and '
printf "'sq' and "
printf '\\slash\\!\n'
echo $1
.
{互換}{分散型版制御機構}{〈Git〉}=}(3)
{版制御機構}{〈Mercurial〉}{〈Git〉}{遂行記録}{標記子}=}(5)

{廃止標記子 K#D657/4A40}

obsolescence marker (obsolete marker?)

可変履歴にたいする簡単な共有・協働を含めた履歴の安全な書き換えを実現するための新たな概念とのこと


以下接触元:

GitはMercurialみたいにObsolescence markerを実装してくれるとrebase運用がやりやすいはず https://mercurial-scm.org/wiki/ChangesetEvolution

前提としてきれいなコミットログを作って直列かしたい(e.g. レビューで指摘があった部分の変更、みたいなコミットをなくしたい)としたときに、例えばコードレビューで受けた指摘をHEADから3つ離れたコミットで反映したいみたいなときに現在だと3つ前のコミットをamendして、そのあと2つコミットを何かしらの方法で乗せるってことになるんですけど、これが結構面倒くさい。Mercurialのevolveだとこれが一発でできる。

現在だと3つ前のコミットをamendして、そのあと2つコミットを何かしらの方法で乗せるってことになるんですけど、これが結構面倒くさい。Mercurialのevolveだとこれが一発でできる。

適当にコミットしてfix-upでもいいけど、場合によってはビルドが壊れる(例えばHEADでは動くけど、それを3つまえにfixupすると動かなくなる)みたいな感じになるので、面倒くさい場合が割とある。

たぶんosakさんがいまcommit, rebase -i, move & fixupを考えているからなんか食い違ってるんと思うんですが、それだとmoveしたコミットがHEADで動くけどfixup先で動かないケースがあるので、直接fixupしたいコミットをcheckoutしてamend, evolveしたい、というフローができるんです。
ちなみにcommit, rebase -i, move & fixupを自動化するabsorbってやつもあります。https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-changes-in-mercurial-4.8/ これはgitでやってるひとがいるっぽい

あーなるほど、間のコミットが同じとこ触ってるとかで安全にmoveできるfixupコミットがそもそもHEADから生やせない状態か。確かにそれは面倒ですね

=}
{〈Git〉}{Brainfuck}{論組言語}=}(3)
{〈Git〉}{遂行}=}(2)
{〈Git〉}

{}