这个简单的教程介绍了在 GIMP 中显示文本的轮廓的步骤。文本轮廓可以帮助你在其它颜色下高亮显示该文本。

让我们看看如何在你的文本周围添加一个边框。

在 GIMP 中添加文本轮廓

整个过程可以用这些简单的步骤描述：

• 创建文本，并复制它的轮廓路径
• 添加一层新的透明层，并添加轮廓路径到透明层中
• 更改轮廓的大小，给它添加一种不同的颜色

这就是全部的东西。不用担心，我将使用适当地截图详细的展示每个步骤。按照这个教程，你应该能够为文本添加轮廓，即使你在此之前从未使用过 GIMP 。

仅需要确保你已经 在 Linux 上安装 GIMP，或者也可以使用的其它任何操作系统。

这篇教程在 GIMP 2.10 版本下演示。

步骤 1: 创建你的主要文本，并复制它的轮廓

打开 GIMP ，并通过转到 “菜单 -> 文件 -> 新建” 来创建一个新的文件。你应该可以使用 Ctrl+N 键盘快捷键。

你可以在这里选择画布的大小。你也可以选择要白色背景或一种透明背景。它在 “高级选项 -> 颜色” 配置文件下。

我选择默认的白色背景。它在以后能够更改。

现在从左边栏的工具箱中选择文本工具。

写你想要的文本。你可以根据你的选择以更改文本的字体、大小和对齐方式。我保持这篇文章的文本的默认左对齐。

我故意为文本选择一种浅色，以便难于阅读。在这篇教程中我将添加一个深色轮廓到这个浅色的文本。

当你写完文本后，右键文本框并选择 “文本的路径” 。

步骤 2: 添加一个带有文本轮廓的透明层

现在，转到顶部菜单，转到“层”，并添加一个新层。

确保添加新层为透明的。你可以给它一个合适的名称，像“文本大纲”。单击确定来添加这个透明层。

再次转到菜单，这次转到 “选择” ，并单击 “来自路径” 。你将看到你的文本应该被高亮显示。

总的来说，你只创建了一个透明层，它有像你的原文一样相同的文本（但是透明）。现在你需要做的是在这个层上增加文本的大小。

步骤 3: 通过增加它的大小和更改它的颜色来添加文本轮廓

为此，再次在菜单中转到 “选择” ，这次选择 “增加”。这将允许增大透明层上的文本的大小。

以 5 或 10 像素增加，或者你喜欢的任意像素。

你选择需要做是使用一种你选择的颜色来填充这个扩大的选择区。因为我的原文是浅色，在这里我将为轮廓使用背景色。

如果尚未选择的话，先选择你的主图像层。这些层在右侧栏中可视。然后转到工具箱并选择油漆桶工具。为你的轮廓选择想要的颜色。

选择使用该工具来填充黑色到你的选择区。记住。你填充文本外部的轮廓，而不是文本本身。

在这里你完成了很多。使用 Ctrl+Shift+A 来取消你当前的选择区。

如此，你现在已经在 GIMP 中成功地添加轮廓到你的文本。它是在白色背景中，如果你想要一个透明背景，只需要在右侧栏的图层菜单中删除背景层。

如果你对结果感到满意，保存文件未 PNG 文件(来保留透明背景)，或你喜欢的任何文件格式。

你使它工作了吗？

就这样。这就是你在 GIMP 中为添加一个文本轮廓而需要做的全部工作。

我希望你发现这个 GIMP 教程有帮助。你可能想查看另一个 关于在 GIMP 中添加一个水印的简单教程。

如果你有问题或建议，请在下面自由留言。

via: https://itsfoss.com/gimp-text-outline/

作者：Abhishek Prakash 选题：lujun9972 译者：robsean 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

当使用 Git 存储库时，这六个 Bash 脚本将使你的生活更轻松。

我编写了许多 Bash 脚本，这些脚本使我在使用 Git 存储库时工作更加轻松。我的许多同事说没有必要：我所做的一切都可以用 Git 命令完成。虽然这可能是正确的，但我发现脚本远比尝试找出适当的 Git 命令来执行我想要的操作更加方便。

1、gitlog

gitlog 打印针对 master 分支的当前补丁的简短列表。它从最旧到最新打印它们，并显示作者和描述，其中 H 代表 HEAD，^ 代表 HEAD^，2 代表 HEAD~2，依此类推。例如：

$ gitlog
-----------------------[ recovery25 ]-----------------------
(snip)
11 340d27a33895 Bob Peterson     gfs2: drain the ail2 list after io errors
10 9b3c4e6efb10 Bob Peterson     gfs2: clean up iopen glock mess in gfs2_create_inode
 9 d2e8c22be39b Bob Peterson     gfs2: Do proper error checking for go_sync family of glops
 8 9563e31f8bfd Christoph Hellwig gfs2: use page_offset in gfs2_page_mkwrite
 7 ebac7a38036c Christoph Hellwig gfs2: don't use buffer_heads in gfs2_allocate_page_backing
 6 f703a3c27874 Andreas Gruenbacher gfs2: Improve mmap write vs. punch_hole consistency
 5 a3e86d2ef30e Andreas Gruenbacher gfs2: Multi-block allocations in gfs2_page_mkwrite
 4 da3c604755b0 Andreas Gruenbacher gfs2: Fix end-of-file handling in gfs2_page_mkwrite
 3 4525c2f5b46f Bob Peterson     Rafael Aquini's slab instrumentation
 2 a06a5b7dea02 Bob Peterson     GFS2: Add go_get_holdtime to gl_ops
 ^ 8ba93c796d5c Bob Peterson     gfs2: introduce new function remaining_hold_time and use it in dq
 H e8b5ff851bb9 Bob Peterson     gfs2: Allow rgrps to have a minimum hold time

如果我想查看其他分支上有哪些补丁，可以指定一个替代分支：

$ gitlog recovery24

2、gitlog.id

gitlog.id 只是打印出补丁的 SHA1 ID：

$ gitlog.id
-----------------------[ recovery25 ]-----------------------
56908eeb6940 2ca4a6b628a1 fc64ad5d99fe 02031a00a251 f6f38da7dd18 d8546e8f0023 fc3cc1f98f6b 12c3e0cb3523 76cce178b134 6fc1dce3ab9c 1b681ab074ca 26fed8de719b 802ff51a5670 49f67a512d8c f04f20193bbb 5f6afe809d23 2030521dc70e dada79b3be94 9b19a1e08161 78a035041d3e f03da011cae2 0d2b2e068fcd 2449976aa133 57dfb5e12ccd 53abedfdcf72 6fbdda3474b3 49544a547188 187032f7a63c 6f75dae23d93 95fc2a261b00 ebfb14ded191 f653ee9e414a 0e2911cb8111 73968b76e2e3 8a3e4cb5e92c a5f2da803b5b 7c9ef68388ed 71ca19d0cba8 340d27a33895 9b3c4e6efb10 d2e8c22be39b 9563e31f8bfd ebac7a38036c f703a3c27874 a3e86d2ef30e da3c604755b0 4525c2f5b46f a06a5b7dea02 8ba93c796d5c e8b5ff851bb9

同样，它假定是当前分支，但是如果需要，我可以指定其他分支。

3、gitlog.id2

gitlog.id2 与 gitlog.id 相同，但顶部没有显示分支的行。这对于从一个分支挑选所有补丁到当前分支很方便：

$ # 创建一个新分支
$ git branch --track origin/master
$ # 检出刚刚创建的新分支
$ git checkout recovery26
$ # 从旧的分支挑选所有补丁到新分支
$ for i in `gitlog.id2 recovery25` ; do git cherry-pick $i ;done

4、gitlog.grep

gitlog.grep 会在该补丁集合中寻找一个字符串。例如，如果我发现一个错误并想修复引用了函数 inode_go_sync 的补丁，我可以简单地执行以下操作：

$ gitlog.grep inode_go_sync
-----------------------[ recovery25 - 50 patches ]-----------------------
(snip)
11 340d27a33895 Bob Peterson     gfs2: drain the ail2 list after io errors
10 9b3c4e6efb10 Bob Peterson     gfs2: clean up iopen glock mess in gfs2_create_inode
 9 d2e8c22be39b Bob Peterson     gfs2: Do proper error checking for go_sync family of glops
152:-static void inode_go_sync(struct gfs2_glock *gl)
153:+static int inode_go_sync(struct gfs2_glock *gl)
163:@@ -296,6 +302,7 @@ static void inode_go_sync(struct gfs2_glock *gl)
 8 9563e31f8bfd Christoph Hellwig gfs2: use page_offset in gfs2_page_mkwrite
 7 ebac7a38036c Christoph Hellwig gfs2: don't use buffer_heads in gfs2_allocate_page_backing
 6 f703a3c27874 Andreas Gruenbacher gfs2: Improve mmap write vs. punch_hole consistency
 5 a3e86d2ef30e Andreas Gruenbacher gfs2: Multi-block allocations in gfs2_page_mkwrite
 4 da3c604755b0 Andreas Gruenbacher gfs2: Fix end-of-file handling in gfs2_page_mkwrite
 3 4525c2f5b46f Bob Peterson     Rafael Aquini's slab instrumentation
 2 a06a5b7dea02 Bob Peterson     GFS2: Add go_get_holdtime to gl_ops
 ^ 8ba93c796d5c Bob Peterson     gfs2: introduce new function remaining_hold_time and use it in dq
 H e8b5ff851bb9 Bob Peterson     gfs2: Allow rgrps to have a minimum hold time

因此，现在我知道补丁 HEAD~9 是需要修复的补丁。我使用 git rebase -i HEAD~10 编辑补丁 9，git commit -a --amend，然后 git rebase --continue 以进行必要的调整。

5、gitbranchcmp3

gitbranchcmp3 使我可以将当前分支与另一个分支进行比较，因此我可以将较旧版本的补丁与我的较新版本进行比较，并快速查看已更改和未更改的内容。它生成一个比较脚本（使用了 KDE 工具 Kompare，该工具也可在 GNOME3 上使用）以比较不太相同的补丁。如果除行号外没有其他差异，则打印 [SAME]。如果仅存在注释差异，则打印 [same]（小写）。例如：

$ gitbranchcmp3 recovery24
Branch recovery24 has 47 patches
Branch recovery25 has 50 patches

(snip)
38 87eb6901607a 340d27a33895 [same] gfs2: drain the ail2 list after io errors
39 90fefb577a26 9b3c4e6efb10 [same] gfs2: clean up iopen glock mess in gfs2_create_inode
40 ba3ae06b8b0e d2e8c22be39b [same] gfs2: Do proper error checking for go_sync family of glops
41 2ab662294329 9563e31f8bfd [SAME] gfs2: use page_offset in gfs2_page_mkwrite
42 0adc6d817b7a ebac7a38036c [SAME] gfs2: don't use buffer_heads in gfs2_allocate_page_backing
43 55ef1f8d0be8 f703a3c27874 [SAME] gfs2: Improve mmap write vs. punch_hole consistency
44 de57c2f72570 a3e86d2ef30e [SAME] gfs2: Multi-block allocations in gfs2_page_mkwrite
45 7c5305fbd68a da3c604755b0 [SAME] gfs2: Fix end-of-file handling in gfs2_page_mkwrite
46 162524005151 4525c2f5b46f [SAME] Rafael Aquini's slab instrumentation
47              a06a5b7dea02 [    ] GFS2: Add go_get_holdtime to gl_ops
48              8ba93c796d5c [    ] gfs2: introduce new function remaining_hold_time and use it in dq
49              e8b5ff851bb9 [    ] gfs2: Allow rgrps to have a minimum hold time

Missing from recovery25:
The missing:
Compare script generated at: /tmp/compare_mismatches.sh

6、gitlog.find

最后，我有一个 gitlog.find 脚本，可以帮助我识别补丁程序的上游版本在哪里以及每个补丁的当前状态。它通过匹配补丁说明来实现。它还会生成一个比较脚本（再次使用了 Kompare），以将当前补丁与上游对应补丁进行比较：

$ gitlog.find
-----------------------[ recovery25 - 50 patches ]-----------------------
(snip)
11 340d27a33895 Bob Peterson     gfs2: drain the ail2 list after io errors
lo 5bcb9be74b2a Bob Peterson     gfs2: drain the ail2 list after io errors
10 9b3c4e6efb10 Bob Peterson     gfs2: clean up iopen glock mess in gfs2_create_inode
fn 2c47c1be51fb Bob Peterson     gfs2: clean up iopen glock mess in gfs2_create_inode
 9 d2e8c22be39b Bob Peterson     gfs2: Do proper error checking for go_sync family of glops
lo feb7ea639472 Bob Peterson     gfs2: Do proper error checking for go_sync family of glops
 8 9563e31f8bfd Christoph Hellwig gfs2: use page_offset in gfs2_page_mkwrite
ms f3915f83e84c Christoph Hellwig gfs2: use page_offset in gfs2_page_mkwrite
 7 ebac7a38036c Christoph Hellwig gfs2: don't use buffer_heads in gfs2_allocate_page_backing
ms 35af80aef99b Christoph Hellwig gfs2: don't use buffer_heads in gfs2_allocate_page_backing
 6 f703a3c27874 Andreas Gruenbacher gfs2: Improve mmap write vs. punch_hole consistency
fn 39c3a948ecf6 Andreas Gruenbacher gfs2: Improve mmap write vs. punch_hole consistency
 5 a3e86d2ef30e Andreas Gruenbacher gfs2: Multi-block allocations in gfs2_page_mkwrite
fn f53056c43063 Andreas Gruenbacher gfs2: Multi-block allocations in gfs2_page_mkwrite
 4 da3c604755b0 Andreas Gruenbacher gfs2: Fix end-of-file handling in gfs2_page_mkwrite
fn 184b4e60853d Andreas Gruenbacher gfs2: Fix end-of-file handling in gfs2_page_mkwrite
 3 4525c2f5b46f Bob Peterson     Rafael Aquini's slab instrumentation
   Not found upstream
 2 a06a5b7dea02 Bob Peterson     GFS2: Add go_get_holdtime to gl_ops
   Not found upstream
 ^ 8ba93c796d5c Bob Peterson     gfs2: introduce new function remaining_hold_time and use it in dq
   Not found upstream
 H e8b5ff851bb9 Bob Peterson     gfs2: Allow rgrps to have a minimum hold time
   Not found upstream
Compare script generated: /tmp/compare_upstream.sh

补丁显示为两行，第一行是你当前的修补程序，然后是相应的上游补丁，以及 2 个字符的缩写，以指示其上游状态：

• lo 表示补丁仅在本地（local）上游 Git 存储库中（即尚未推送到上游）。
• ms 表示补丁位于 Linus Torvald 的主（master）分支中。
• fn 意味着补丁被推送到我的 “for-next” 开发分支，用于下一个上游合并窗口。 我的一些脚本根据我通常使用 Git 的方式做出假设。例如，当搜索上游补丁时，它使用我众所周知的 Git 树的位置。因此，你需要调整或改进它们以适合你的条件。gitlog.find 脚本旨在仅定位 GFS2 和 DLM 补丁，因此，除非你是 GFS2 开发人员，否则你需要针对你感兴趣的组件对其进行自定义。

源代码

以下是这些脚本的源代码。

1、gitlog

#!/bin/bash
branch=$1

if test "x$branch" = x; then
    branch=`git branch -a | grep "*" | cut -d ' ' -f2`
fi

patches=0
tracking=`git rev-parse --abbrev-ref --symbolic-full-name @{u}`

LIST=`git log --reverse --abbrev-commit --pretty=oneline $tracking..$branch | cut -d ' ' -f1 |paste -s -d ' '`
for i in $LIST; do patches=$(echo $patches + 1 | bc);done

if [[ $branch =~ .*for-next.* ]]
then
    start=HEAD
#    start=origin/for-next
else
    start=origin/master
fi

tracking=`git rev-parse --abbrev-ref --symbolic-full-name @{u}`

/usr/bin/echo "-----------------------[" $branch "]-----------------------"
patches=$(echo $patches - 1 | bc);
for i in $LIST; do
    if [ $patches -eq 1 ]; then
        cnt=" ^"
    elif [ $patches -eq 0 ]; then
        cnt=" H"
    else
        if [ $patches -lt 10 ]; then
            cnt=" $patches"
        else
            cnt="$patches"
        fi
    fi
    /usr/bin/git show --abbrev-commit -s --pretty=format:"$cnt %h %<|(32)%an %s %n" $i
    patches=$(echo $patches - 1 | bc)
done
#git log --reverse --abbrev-commit --pretty=format:"%h %<|(32)%an %s" $tracking..$branch
#git log --reverse --abbrev-commit --pretty=format:"%h %<|(32)%an %s" ^origin/master ^linux-gfs2/for-next $branch

2、gitlog.id

#!/bin/bash
branch=$1

if test "x$branch" = x; then
    branch=`git branch -a | grep "*" | cut -d ' ' -f2`
fi

tracking=`git rev-parse --abbrev-ref --symbolic-full-name @{u}`

/usr/bin/echo "-----------------------[" $branch "]-----------------------"
git log --reverse --abbrev-commit --pretty=oneline $tracking..$branch | cut -d ' ' -f1 |paste -s -d ' '

3、gitlog.id2

#!/bin/bash
branch=$1

if test "x$branch" = x; then
    branch=`git branch -a | grep "*" | cut -d ' ' -f2`
fi

tracking=`git rev-parse --abbrev-ref --symbolic-full-name @{u}`
git log --reverse --abbrev-commit --pretty=oneline $tracking..$branch | cut -d ' ' -f1 |paste -s -d ' '

4、gitlog.grep

#!/bin/bash
param1=$1
param2=$2

if test "x$param2" = x; then
    branch=`git branch -a | grep "*" | cut -d ' ' -f2`
    string=$param1
else
    branch=$param1
    string=$param2
fi

patches=0
tracking=`git rev-parse --abbrev-ref --symbolic-full-name @{u}`

LIST=`git log --reverse --abbrev-commit --pretty=oneline $tracking..$branch | cut -d ' ' -f1 |paste -s -d ' '`
for i in $LIST; do patches=$(echo $patches + 1 | bc);done
/usr/bin/echo "-----------------------[" $branch "-" $patches "patches ]-----------------------"
patches=$(echo $patches - 1 | bc);
for i in $LIST; do
    if [ $patches -eq 1 ]; then
        cnt=" ^"
    elif [ $patches -eq 0 ]; then
        cnt=" H"
    else
        if [ $patches -lt 10 ]; then
            cnt=" $patches"
        else
            cnt="$patches"
        fi
    fi
    /usr/bin/git show --abbrev-commit -s --pretty=format:"$cnt %h %<|(32)%an %s" $i
    /usr/bin/git show --pretty=email --patch-with-stat $i | grep -n "$string"
    patches=$(echo $patches - 1 | bc)
done

5、gitbranchcmp3

#!/bin/bash
#
# gitbranchcmp3 <old branch> [<new_branch>]
#
oldbranch=$1
newbranch=$2
script=/tmp/compare_mismatches.sh

/usr/bin/rm -f $script
echo "#!/bin/bash" > $script
/usr/bin/chmod 755 $script
echo "# Generated by gitbranchcmp3.sh" >> $script
echo "# Run this script to compare the mismatched patches" >> $script
echo " " >> $script
echo "function compare_them()" >> $script
echo "{"  >> $script
echo "    git show --pretty=email --patch-with-stat \$1 > /tmp/gronk1" >> $script
echo "    git show --pretty=email --patch-with-stat \$2 > /tmp/gronk2" >> $script
echo "    kompare /tmp/gronk1 /tmp/gronk2" >> $script
echo "}" >> $script
echo " " >> $script

if test "x$newbranch" = x; then
    newbranch=`git branch -a | grep "*" | cut -d ' ' -f2`
fi

tracking=`git rev-parse --abbrev-ref --symbolic-full-name @{u}`

declare -a oldsha1s=(`git log --reverse --abbrev-commit --pretty=oneline $tracking..$oldbranch | cut -d ' ' -f1 |paste -s -d ' '`)
declare -a newsha1s=(`git log --reverse --abbrev-commit --pretty=oneline $tracking..$newbranch | cut -d ' ' -f1 |paste -s -d ' '`)

#echo "old: " $oldsha1s
oldcount=${#oldsha1s[@]}
echo "Branch $oldbranch has $oldcount patches"
oldcount=$(echo $oldcount - 1 | bc)
#for o in `seq 0 ${#oldsha1s[@]}`; do
#    echo -n ${oldsha1s[$o]} " "
#    desc=`git show $i | head -5 | tail -1|cut -b5-`
#done

#echo "new: " $newsha1s
newcount=${#newsha1s[@]}
echo "Branch $newbranch has $newcount patches"
newcount=$(echo $newcount - 1 | bc)
#for o in `seq 0 ${#newsha1s[@]}`; do
#    echo -n ${newsha1s[$o]} " "
#    desc=`git show $i | head -5 | tail -1|cut -b5-`
#done
echo

for new in `seq 0 $newcount`; do
    newsha=${newsha1s[$new]}
    newdesc=`git show $newsha | head -5 | tail -1|cut -b5-`
    oldsha="            "
    same="[    ]"
    for old in `seq 0 $oldcount`; do
        if test "${oldsha1s[$old]}" = "match"; then
            continue;
        fi
        olddesc=`git show ${oldsha1s[$old]} | head -5 | tail -1|cut -b5-`
        if test "$olddesc" = "$newdesc" ; then
            oldsha=${oldsha1s[$old]}
            #echo $oldsha
            git show $oldsha |tail -n +2 |grep -v "index.*\.\." |grep -v "@@" > /tmp/gronk1
            git show $newsha |tail -n +2 |grep -v "index.*\.\." |grep -v "@@"  > /tmp/gronk2
            diff /tmp/gronk1 /tmp/gronk2 &> /dev/null
            if [ $? -eq 0 ] ;then
# No differences
                same="[SAME]"
                oldsha1s[$old]="match"
                break
            fi
            git show $oldsha |sed -n '/diff/,$p' |grep -v "index.*\.\." |grep -v "@@" > /tmp/gronk1
            git show $newsha |sed -n '/diff/,$p' |grep -v "index.*\.\." |grep -v "@@" > /tmp/gronk2
            diff /tmp/gronk1 /tmp/gronk2 &> /dev/null
            if [ $? -eq 0 ] ;then
# Differences in comments only
                same="[same]"
                oldsha1s[$old]="match"
                break
            fi
            oldsha1s[$old]="match"
            echo "compare_them $oldsha $newsha" >> $script
        fi
    done
    echo "$new $oldsha $newsha $same $newdesc"
done

echo
echo "Missing from $newbranch:"
the_missing=""
# Now run through the olds we haven't matched up
for old in `seq 0 $oldcount`; do
    if test ${oldsha1s[$old]} != "match"; then
        olddesc=`git show ${oldsha1s[$old]} | head -5 | tail -1|cut -b5-`
        echo "${oldsha1s[$old]} $olddesc"
        the_missing=`echo "$the_missing ${oldsha1s[$old]}"`
    fi
done

echo "The missing: " $the_missing
echo "Compare script generated at: $script"
#git log --reverse --abbrev-commit --pretty=oneline $tracking..$branch | cut -d ' ' -f1 |paste -s -d ' '

6、gitlog.find

#!/bin/bash
#
# Find the upstream equivalent patch
#
# gitlog.find
#
cwd=$PWD
param1=$1
ubranch=$2
patches=0
script=/tmp/compare_upstream.sh
echo "#!/bin/bash" > $script
/usr/bin/chmod 755 $script
echo "# Generated by gitbranchcmp3.sh" >> $script
echo "# Run this script to compare the mismatched patches" >> $script
echo " " >> $script
echo "function compare_them()" >> $script
echo "{"  >> $script
echo "    cwd=$PWD" >> $script
echo "    git show --pretty=email --patch-with-stat \$2 > /tmp/gronk2" >> $script
echo "    cd ~/linux.git/fs/gfs2" >> $script
echo "    git show --pretty=email --patch-with-stat \$1 > /tmp/gronk1" >> $script
echo "    cd $cwd" >> $script
echo "    kompare /tmp/gronk1 /tmp/gronk2" >> $script
echo "}" >> $script
echo " " >> $script

#echo "Gathering upstream patch info. Please wait."
branch=`git branch -a | grep "*" | cut -d ' ' -f2`
tracking=`git rev-parse --abbrev-ref --symbolic-full-name @{u}`

cd ~/linux.git
if test "X${ubranch}" = "X"; then
    ubranch=`git branch -a | grep "*" | cut -d ' ' -f2`
fi
utracking=`git rev-parse --abbrev-ref --symbolic-full-name @{u}`
#
# gather a list of gfs2 patches from master just in case we can't find it
#
#git log --abbrev-commit --pretty=format:"   %h %<|(32)%an %s" master |grep -i -e "gfs2" -e "dlm" > /tmp/gronk
git log --reverse --abbrev-commit --pretty=format:"ms %h %<|(32)%an %s" master fs/gfs2/ > /tmp/gronk.gfs2
# ms = in Linus's master
git log --reverse --abbrev-commit --pretty=format:"ms %h %<|(32)%an %s" master fs/dlm/ > /tmp/gronk.dlm

cd $cwd
LIST=`git log --reverse --abbrev-commit --pretty=oneline $tracking..$branch | cut -d ' ' -f1 |paste -s -d ' '`
for i in $LIST; do patches=$(echo $patches + 1 | bc);done
/usr/bin/echo "-----------------------[" $branch "-" $patches "patches ]-----------------------"
patches=$(echo $patches - 1 | bc);
for i in $LIST; do
    if [ $patches -eq 1 ]; then
        cnt=" ^"
    elif [ $patches -eq 0 ]; then
        cnt=" H"
    else
        if [ $patches -lt 10 ]; then
            cnt=" $patches"
        else
            cnt="$patches"
        fi
    fi
    /usr/bin/git show --abbrev-commit -s --pretty=format:"$cnt %h %<|(32)%an %s" $i
    desc=`/usr/bin/git show --abbrev-commit -s --pretty=format:"%s" $i`
    cd ~/linux.git
    cmp=1
    up_eq=`git log --reverse --abbrev-commit --pretty=format:"lo %h %<|(32)%an %s" $utracking..$ubranch | grep "$desc"`
# lo = in local for-next
    if test "X$up_eq" = "X"; then
        up_eq=`git log --reverse --abbrev-commit --pretty=format:"fn %h %<|(32)%an %s" master..$utracking | grep "$desc"`
# fn = in for-next for next merge window
        if test "X$up_eq" = "X"; then
            up_eq=`grep "$desc" /tmp/gronk.gfs2`
            if test "X$up_eq" = "X"; then
                up_eq=`grep "$desc" /tmp/gronk.dlm`
                if test "X$up_eq" = "X"; then
                    up_eq="   Not found upstream"
                    cmp=0
                fi
            fi
        fi
    fi
    echo "$up_eq"
    if [ $cmp -eq 1 ] ; then
        UP_SHA1=`echo $up_eq|cut -d' ' -f2`
        echo "compare_them $UP_SHA1 $i" >> $script
    fi
    cd $cwd
    patches=$(echo $patches - 1 | bc)
done
echo "Compare script generated: $script"

via: https://opensource.com/article/20/1/bash-scripts-git

作者：Bob Peterson 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

2020 年，在我们的 20 个使用开源提升生产力的系列文章中，让我们了解如何使用 Stow 跨机器管理配置。

去年，我在 19 天里给你介绍了 19 个新（对你而言）的生产力工具。今年，我换了一种方式：使用你在使用或者还没使用的工具，构建一个使你可以在新一年更加高效的环境。

使用 Stow 管理符号链接

昨天，我解释了如何使用 Syncthing 在多台计算机上保持文件同步。但是，这只是我用来保持配置一致性的工具之一。还有另一个表面上看起来更简单的工具：Stow。

Stow 管理符号链接。默认情况下，它会链接目录到上一级目录。还有设置源和目标目录的选项，但我通常不使用它们。

正如我在 Syncthing 的文章 中提到的，我使用 Syncthing 来保持 myconfigs 目录在我所有的计算机上一致。myconfigs 目录下面有多个子目录。每个子目录包含我经常使用的应用之一的配置文件。

在每台计算机上，我进入 myconfigs 目录，并运行 stow -S <目录名称> 以将目录中的文件符号链接到我的家目录。例如，在 vim 目录下，我有 .vimrc 和 .vim 目录。在每台机器上，我运行 stow -S vim 来创建符号链接 ~/.vimrc 和 ~/.vim。当我在一台计算机上更改 Vim 配置时，它会应用到我的所有机器上。

然而，有时候，我需要一些特定于机器的配置，这就是为什么我有如 msmtp-personal 和 msmtp-elastic（我的雇主）这样的目录。由于我的 msmtp SMTP 客户端需要知道要中继电子邮件服务器，并且每个服务器都有不同的设置和凭据，我会使用 -D 标志来取消链接，接着链接另外一个。

有时我要给配置添加文件。为此，有一个 -R 选项来“重新链接”。例如，我喜欢在图形化 Vim 中使用一种与控制台不同的特定字体。除了标准 .vimrc 文件，.gvimrc 文件能让我设置特定于图形化版本的选项。当我第一次设置它时，我移动 ~/.gvimrc 到 ~/myconfigs/vim 中，然后运行 stow -R vim，它取消链接并重新链接该目录中的所有内容。

Stow 让我使用一个简单的命令行在多种配置之间切换，并且，结合 Syncthing，我可以确保无论我身在何处或在哪里进行更改，我都有我喜欢的工具的设置。

via: https://opensource.com/article/20/1/configuration-management-stow

作者：Kevin Sonney 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

借助 Gitolite，你可以使用 Git 来管理 Git 服务器。在我们的系列文章中了解这些鲜为人知的 Git 用途。

正如我在系列文章中演示的那样，Git 除了跟踪源代码外，还可以做很多事情。信不信由你，Git 甚至可以管理你的 Git 服务器，因此你可以或多或少地使用 Git 本身来运行 Git 服务器。

当然，这涉及除日常使用 Git 之外的许多组件，其中最重要的是 Gitolite，该后端应用程序可以管理你使用 Git 的每个细微的配置。Gitolite 的优点在于，由于它使用 Git 作为其前端接口，因此很容易将 Git 服务器管理集成到其他基于 Git 的工作流中。Gitolite 可以精确控制谁可以访问你服务器上的特定存储库以及他们具有哪些权限。你可以使用常规的 Linux 系统工具自行管理此类事务，但是如果有好几个用户和不止一两个仓库，则需要大量的工作。

Gitolite 的开发人员做了艰苦的工作，使你可以轻松地为许多用户提供对你的 Git 服务器的访问权，而又不让他们访问你的整个环境 —— 而这一切，你可以使用 Git 来完成全部工作。

Gitolite 并不是图形化的管理员和用户面板。优秀的 Gitea 项目可提供这种体验，但是本文重点介绍 Gitolite 的简单优雅和令人舒适的熟悉感。

安装 Gitolite

假设你的 Git 服务器运行在 Linux 上，则可以使用包管理器安装 Gitolite（在 CentOS 和 RHEL 上为 yum，在 Debian 和 Ubuntu 上为 apt，在 OpenSUSE 上为 zypper 等）。例如，在 RHEL 上：

$ sudo yum install gitolite3

许多发行版的存储库提供的仍是旧版本的 Gitolite，但最新版本为版本 3。

你必须具有对服务器的无密码 SSH 访问权限。如果愿意，你可以使用密码登录服务器，但是 Gitolite 依赖于 SSH 密钥，因此必须配置使用密钥登录的选项。如果你不知道如何配置服务器以进行无密码 SSH 访问，请首先学习如何进行操作（Steve Ovens 的 Ansible 文章的设置 SSH 密钥身份验证部分对此进行了很好的说明）。这是加强服务器管理的安全以及运行 Gitolite 的重要组成部分。

配置 Git 用户

如果没有 Gitolite，则如果某人请求访问你在服务器上托管的 Git 存储库时，则必须向该人提供用户帐户。Git 提供了一个特殊的外壳，即 git-shell，这是一个仅执行 Git 任务的特别的特定 shell。这可以让你有个只能通过非常受限的 Shell 环境来过滤访问你的服务器的用户。

这个解决方案是一个办法，但通常意味着用户可以访问服务器上的所有存储库，除非你具有用于组权限的良好模式，并在创建新存储库时严格遵循这些权限。这种方式还需要在系统级别进行大量手动配置，这通常是只有特定级别的系统管理员才能做的工作，而不一定是通常负责 Git 存储库的人员。

Gitolite 通过为需要访问任何存储库的每个人指定一个用户名来完全回避此问题。默认情况下，该用户名是 git，并且由于 Gitolite 的文档中假定使用的是它，因此在学习该工具时保留它是一个很好的默认设置。对于曾经使用过 GitLab 或 GitHub 或任何其他 Git 托管服务的人来说，这也是一个众所周知的约定。

Gitolite 将此用户称为托管用户。在服务器上创建一个帐户以充当托管用户（我习惯使用 git，因为这是惯例）：

$ sudo adduser --create-home git

为了控制该 git 用户帐户，该帐户必须具有属于你的有效 SSH 公钥。你应该已经进行了设置，因此复制你的公钥（而不是你的私钥）添加到 git 用户的家目录中：

$ sudo cp ~/.ssh/id_ed25519.pub /home/git/
$ sudo chown git:git /home/git/id_ed25519.pub

如果你的公钥不以扩展名 .pub 结尾，则 Gitolite 不会使用它，因此请相应地重命名该文件。切换为该用户帐户以运行 Gitolite 的安装程序：

$ sudo su - git
$ gitolite setup --pubkey id_ed25519.pub

安装脚本运行后，git 的家用户目录将有一个 repository 目录，该目录（目前）包含存储库 git-admin.git 和 testing.git。这就是该服务器所需的全部设置，现在请登出 git 用户。

使用 Gitolite

管理 Gitolite 就是编辑 Git 存储库中的文本文件，尤其是 gitolite-admin.git 中的。你不会通过 SSH 进入服务器来进行 Git 管理，并且 Gitolite 也建议你不要这样尝试。在 Gitolite 服务器上存储你和你的用户的存储库是个裸存储库，因此最好不要使用它们。

$ git clone [email protected]:gitolite-admin.git gitolite-admin.git
$ cd gitolite-admin.git
$ ls -1
conf
keydir

该存储库中的 conf 目录包含一个名为 gitolite.conf 的文件。在文本编辑器中打开它，或使用 cat 查看其内容：

repo gitolite-admin
    RW+     =   id_ed22519

repo testing
    RW+     =   @all

你可能对该配置文件的功能有所了解：gitolite-admin 代表此存储库，并且 id_ed25519 密钥的所有者具有读取、写入和管理 Git 的权限。换句话说，不是将用户映射到普通的本地 Unix 用户（因为所有用户都使用 git 用户托管用户身份），而是将用户映射到 keydir 目录中列出的 SSH 密钥。

testing.git 存储库使用特殊组符号为访问服务器的每个人提供了全部权限。

添加用户

如果要向 Git 服务器添加一个名为 alice 的用户，Alice 必须向你发送她的 SSH 公钥。Gitolite 使用文件名的 .pub 扩展名左边的任何内容作为该 Git 用户的标识符。不要使用默认的密钥名称值，而是给密钥指定一个指示密钥所有者的名称。如果用户有多个密钥（例如，一个用于笔记本电脑，一个用于台式机），则可以使用子目录来避免文件名冲突。例如，Alice 在笔记本电脑上使用的密钥可能是默认的 id_rsa.pub，因此将其重命名为alice.pub 或类似名称（或让用户根据其计算机上的本地用户帐户来命名密钥），然后将其放入 gitolite-admin.git/keydir/work/laptop/ 目录中。如果她从她的桌面计算机发送了另一个密钥，命名为 alice.pub（与上一个相同），然后将其添加到 keydir/home/desktop/ 中。另一个密钥可能放到 keydir/home/desktop/ 中，依此类推。Gitolite 递归地在 keydir 中搜索与存储库“用户”相匹配的 .pub 文件，并将所有匹配项视为相同的身份。

当你将密钥添加到 keydir 目录时，必须将它们提交回服务器。这是一件很容易忘记的事情，这里有一个使用自动化的 Git 应用程序（例如 Sparkleshare）的真正的理由，因此任何更改都将立即提交给你的 Gitolite 管理员。第一次忘记提交和推送，在浪费了三个小时的你和你的用户的故障排除时间之后，你会发现 Gitolite 是使用 Sparkleshare 的完美理由。

$ git add keydir
$ git commit -m 'added alice-laptop-0.pub'
$ git push origin HEAD

默认情况下，Alice 可以访问 testing.git 目录，因此她可以使用该目录测试连接性和功能。

设置权限

与用户一样，目录权限和组也是从你可能习惯的的常规 Unix 工具中抽象出来的（或可从在线信息查找）。在 gitolite-admin.git/conf 目录中的 gitolite.conf 文件中授予对项目的权限。权限分为四个级别：

• R 允许只读。在存储库上具有 R 权限的用户可以克隆它，仅此而已。
• RW 允许用户执行分支的快进推送、创建新分支和创建新标签。对于大多数用户来说，这个基本上就像是一个“普通”的 Git 存储库。
• RW+ 允许可能具有破坏性的 Git 动作。用户可以执行常规的快进推送、回滚推送、变基以及删除分支和标签。你可能想要或不希望将其授予项目中的所有贡献者。
• - 明确拒绝访问存储库。这与未在存储库的配置中列出的用户相同。

通过调整 gitolite.conf 来创建一个新的存储库或修改现有存储库的权限。例如，授予 Alice 权限来管理一个名为 widgets.git 的新存储库：

repo gitolite-admin
    RW+     =   id_ed22519

repo testing
    RW+     =   @all

repo widgets
    RW+     =   alice

现在，Alice（也仅有 Alice 一个人）可以克隆该存储库：

[alice]$ git clone [email protected]:widgets.git
Cloning into 'widgets'...
warning: You appear to have cloned an empty repository.

在第一次推送时，Alice 必须使用 -u 选项将其分支发送到空存储库（如同她在任何 Git 主机上做的一样）。

为了简化用户管理，你可以定义存储库组：

@qtrepo = widgets
@qtrepo = games

repo gitolite-admin
    RW+     =   id_ed22519

repo testing
    RW+     =   @all

repo @qtrepo
    RW+     =   alice

正如你可以创建组存储库一样，你也可以对用户进行分组。默认情况下存在一个用户组：@all。如你所料，它包括所有用户，无一例外。你也可以创建自己的组：

@qtrepo = widgets
@qtrepo = games

@developers = alice bob

repo gitolite-admin
    RW+     =   id_ed22519

repo testing
    RW+     =   @all

repo @qtrepo
    RW+     =   @developers

与添加或修改密钥文件一样，对 gitolite.conf 文件的任何更改都必须提交并推送以生效。

创建存储库

默认情况下，Gitolite 假设存储库的创建是从上至下进行。例如，有权访问 Git 服务器的项目经理创建了一个项目存储库，并通过 Gitolite 管理仓库添加了开发人员。

实际上，你可能更愿意向用户授予创建存储库的权限。Gitolite 称这些为“ 野生仓库（通配仓库） wild repos ”（我不确定这是关于仓库的形成方式的描述，还是指配置文件所需的通配符）。这是一个例子：

@managers = alice bob

repo foo/CREATOR/[a-z]..*
    C   =   @managers
    RW+ =   CREATOR
    RW  =   WRITERS
    R   =   READERS

第一行定义了一组用户：该组称为 @managers，其中包含用户 alice 和 bob。下一行设置了通配符允许创建尚不存在的存储库，放在名为 foo 的目录下的创建该存储库的用户名的子目录中。例如：

[alice]$ git clone [email protected]:foo/alice/cool-app.git
Cloning into cool-app'...
Initialized empty Git repository in /home/git/repositories/foo/alice/cool-app.git
warning: You appear to have cloned an empty repository.

野生仓库的创建者可以使用一些机制来定义谁可以读取和写入其存储库，但是他们是有范围限定的。在大多数情况下，Gitolite 假定由一组特定的用户来管理项目权限。一种解决方案是使用 Git 挂钩来授予所有用户对 gitolite-admin 的访问权限，以要求管理者批准将更改合并到 master 分支中。

了解更多

Gitolite 具有比此介绍性文章所涵盖的更多功能，因此请尝试一下。其文档非常出色，一旦你通读了它，就可以自定义 Gitolite 服务器，以向用户提供你喜欢的任何级别的控制。Gitolite 是一种维护成本低、简单的系统，你可以安装、设置它，然后基本上就可以将其忘却。

via: https://opensource.com/article/19/4/server-administration-git

作者：Seth Kenlon 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

2020 年，在我们的 20 个使用开源提升生产力的系列文章中，首先了解如何使用 Syncthing 同步文件。

去年，我在 19 天里给你介绍了 19 个新（对你而言）的生产力工具。今年，我换了一种方式：使用你在使用或者还没使用的工具，构建一个使你可以在新一年更加高效的环境。

使用 Synthing 同步文件

设置新机器很麻烦。我们都有在机器之间复制的“标准设置”。多年来，我使用了很多方法来使它们在计算机之间同步。在过去（这会告诉你我年纪有多大了），曾经是软盘、然后是 Zip 磁盘、U 盘、SCP、Rsync、Dropbox、ownCloud，你想到的都试过。但这些似乎对我都不够好。

然后我偶然发现了 Syncthing。

Syncthing 是一个轻量级的点对点文件同步系统。你不需要为服务付费，也不需要第三方服务器，而且速度很快。以我的经验，比文件同步中的许多“大牌”要快得多。

Syncthing 可在 Linux、MacOS、Windows 和多种 BSD 中使用。还有一个 Android 应用（但尚无官方 iOS 版本）。以上所有终端都有方便的图形化前端（尽管我不会在这里介绍）。在 Linux 上，大多数发行版都有可用的软件包，因此安装非常简单。

首次启动 Syncthing 时，它将启动 Web 浏览器以配置守护程序。第一台计算机上没有太多要做，但是这是一个很好的机会来介绍一下用户界面 （UI）。最重要的是在右上方的 “Actions” 菜单下的 “System ID”。

设置第一台计算机后，请在第二台计算机上重复安装。在 UI 中，右下方将显示一个按钮，名为 “Add Remote Device”。单击该按钮，你将会看到一个要求输入 “Device ID and a Name” 的框。从第一台计算机上复制并粘贴 “Device ID”，然后单击 “Save”。

你应该会在第一台上看到一个请求添加第二台的弹出窗口。接受后，新机器将显示在第一台机器的右下角。与第二台计算机共享默认目录。单击 “Default Folder”，然后单击 “Edit” 按钮。弹出窗口的顶部有四个链接。单击 “Sharing”，然后选择第二台计算机。单击 “Save”，然后查看第二台计算机。你会看到一个接受共享目录的提示。接受后，它将开始在两台计算机之间同步文件。

测试从一台计算机上复制文件到默认目录（“/你的家目录/Share”）。它应该很快会在另一台上出现。

你可以根据需要添加任意数量的目录，这非常方便。如你在第一张图中所看到的，我有一个用于保存配置的 myconfigs 文件夹。当我买了一台新机器时，我只需安装 Syncthing，如果我在一台机器上调整了配置，我不必更新所有，它会自动更新。

via: https://opensource.com/article/20/1/sync-files-syncthing

作者：Kevin Sonney 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

检查一下你的系统所使用的 Linux 内核版本，你十有八九会发现，按照 Linux 内核官网提供的信息，该内核版本已经达到使用寿命终期（EOL）了。

一个软件一旦达到了使用寿命终期，那么就意味着它再也不会得到 bug 修复和维护了。

这自然会引发一连串问题：为什么我的 Linux 发行版会使用一个已经达到使用寿命终期的内核呢？这样做有没有安全风险？我的系统还安全吗？

下面将逐一解答这些问题。

总结

上游内核维护与你的发行版的内核维护是两个不同的概念。

例如，根据 Linux 内核官网，Linux 内核 4.15 版本可能已经达到使用寿命终期了，但是在 2023 年 4 月之前，Ubuntu 18.04 长期维护版本将会继续使用这个版本，并通过向后移植安全补丁和修复 bug 来提供维护。

检查 Linux 内核版本，以及是否达到使用寿命终期

首先，查看你的系统所使用的 Linux 内核版本：

uname -r

我使用的是 Ubuntu 18.04，输出的 Linux 内核版本如下：

abhishek@itsfoss:~$ uname -r
5.0.0-37-generic

接下来，可以到 Linux 内核官网上看看哪些 Linux 内核版本仍然在维护状态。在网站主页上就可以看到相关信息。

你看到的内核版本状态应该类似于下图：

如果你的内核版本没有列在内核官网主页上，就说明该版本已经达到了使用寿命终期。

可以看到，5.0 内核版本并不在列，这说明该内核版本已经不再得到维护。事实上，该版本在 2019 年 6 月就已经达到使用寿命终期了。

不幸的是，Linux 内核的生命周期没有任何规律可循。不是说常规的内核稳定发布版可以得到 X 月的维护、长期维护版本（LTS）可以得到 Y 年的维护。没有这回事。

根据实际需求，可能会存在内核的多个 LTS 版本，其使用寿命终期各不相同。在这个页面上可以查到这些 LTS 版本的相关信息，包括计划的使用寿命终期。

那么问题来了：既然 Linux 内核官网上明确表示 5.0 版本的内核已经达到了使用寿命终期，Ubuntu 为什么还在提供这个内核版本呢？

你的发行版使用的 Linux 内核已经达到了使用寿命终期，但是没关系！

你是否想过，为什么 Ubuntu/Debian/Fedora 等发行版被称为 Linux “发行版”？这是因为，它们“发行” Linux 内核。

这些发行版会对 Linux 内核进行不同的修改，并添加各种 GUI 元素（包括桌面环境、显示服务器等）以及软件，然后再呈现给用户。

按照通常的工作流，Linux 发行版会选择一个内核，提供给其用户，然后在接下来的几个月、几年中，甚至是达到内核的使用寿命终期之后，仍然会继续使用该内核。

这样能够保障安全吗？其实是可以的，因为 发行版会通过向后移植全部的重要修补来维护内核。

换句话说，你的 Linux 发行版会确保 Linux 内核没有漏洞和 bug，并且已经通过向后移植获得了重要的新特性。在“过时的旧版本 Linux 内核”上，其实有着数以千计的改动。

如果 Linux 内核网站上说某个内核版本已经达到了使用寿命终期，那么就意味着 Linux 内核的核心维护团队不会再对该内核版本进行升级和打补丁了。

但与此同时，Debian/Ubuntu 或者其他发行版的开发者们会继续工作，通过从（由内核核心团队维护的）更新的内核版本中迁移相关的修改，维持这个老版本的生命力。

重点在于，即使你的发行版看上去是在使用一个已经过时的 Linux 内核，其实该内核也得到了良好的维护，并非是真的过时了。

你是否应该使用最新的稳定内核版本？

新的 Linux 内核稳定版本每隔 2 到 3 个月发布一次，有不少用户跃跃欲试。

实话说，除非有十分充分的理由，否则不应该使用最新版本的稳定内核。你使用的发行版并不会提供这个选项，你也不能指望通过在键盘上敲出 sudo apt give-me-the-latest-stable-kernel 解决问题。

此外，手动安装主流 Linux 内核版本本身就是一个挑战。即使安装成功，之后每次发布 bug 修复的时候，负责更新内核的就会是你了。此外，当新内核达到使用寿命终期之后，你就有责任将它升级到更新的内核版本了。和常规的 Ubuntu 更新不同，内核升级无法通过 apt upgrade 完成。

同样需要记住的是，切换到主流内核之后，可能就无法使用你的发行版提供的一些驱动程序和补丁了。

正如 Greg Kroah-Hartman所言，“你能使用的最好的内核，就是别人在维护的内核。”除了你的 Linux 发行版之外，又有谁更胜任这份工作呢！

希望你对这个主题已经有了更好的理解。下回发现你的系统正在使用的内核版本已经达到使用寿命终期的时候，希望你不会感到惊慌失措。

欢迎在下面的评论区中留下你的疑问或建议。

via: https://itsfoss.com/why-distros-use-old-kernel/

作者：Abhishek Prakash 选题：lujun9972 译者：chen-ni 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出