On Saturday, April 20, 2019 3:33 PM, Philipp Hagemeister <phihag@phihag.de> wrote:
> https://drewdevault.com/2019/02/25/Using-git-with-discipline.html> One
> workflow I find myself commonly using is to make some changes to a file,
> commit a “fixup” commit (git commit -m fixup), then use git rebase -i to
> squash it into an earlier commit.

For this, there is `git commit --fixup <commit>`. After that
`git rebase -i` will automatically squash the fixup commit.

> If it's just one simple change of the latest commit (for example fixing
> a small linting bug), you can also use git commit --amend - this does
> commiting and squashing/rebasing in one step!

Yeah, I also use `git commit --amend` all the time.

On Friday, April 19, 2019 12:31 AM, Dragnel <dragnel@protonmail.com> wrote:
> What is this style, gnu ? Maybe I can add an option in vim to force
> the style. It will be easier to me because this style is completly
> unnatural to me. I didn't see any guidelines either. Do you plan to
> add one ?

This is the sway/wlroots style [1]. Yes, I plan on adding a
CONTRIBUTING.md file, I just haven't gotten around to it yet.

[1]: https://github.com/swaywm/wlroots/blob/master/CONTRIBUTING.md

Hi,

Thanks for your updated patch! A few more comments.

On Tuesday, April 16, 2019 4:24 PM, dragnel <dragnel@protonmail.com> wrote:
> ---
> Hi, thx for review.
> I have a little problem through, test is passing only if I remove
> the echos in test/command.sh
>
>  builtin/builtin.c |  1 +
>  builtin/command.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/builtin.h |  1 +
>  meson.build       |  1 +

Hi,

Thanks for your patch! Here are some comments.

We use tabs for indentation. I see your whole patch uses spaces. Can you convert
spaces to tabs?

On Sunday, April 14, 2019 1:09 AM, dragnel <dragnel@protonmail.com> wrote:
> ---
>  builtin/builtin.c |   1 +
>  builtin/command.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/builtin.h |   1 +
>  meson.build       |   1 +
>  test/command.sh   |  20 +++++++++

I just ran `go mod tidy`.
---
 go.mod | 6 +-----
 go.sum | 5 -----
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/go.mod b/go.mod
index 1e38cf1..be5fd7e 100644
--- a/go.mod
+++ b/go.mod
@@ -2,8 +2,4 @@ module git.sr.ht/~sircmpwn/go-libvterm
 
 go 1.12
 
[message trimmed]

fd.o seems to somewhat agree with you [1]. tl;dr send a mail with
In-Reply-To if there's a single v2 patch, but start a completely
different thread if your do a v2 of the whole series.

As a side note, the current lists.sr.ht UI doesn't accommodate well for
multiple versions of the same patchset in the same thread.

[1]: https://patchwork-freedesktop.readthedocs.io/en/latest/manual.html#new-patch

To git.sr.ht:~emersion/mrsh
   a263f96..04937ee  master -> master

Thanks!

On Friday, March 29, 2019 1:27 AM, Drew DeVault <sir@cmpwn.com> wrote:
> Since we have to use specific numbered exit codes in some places, would
> you advocate a mixed approach, using EXIT_* when appropriate, and
> integers when necessary, or using only integers?

I'm not feeling strongly about this, but maybe we should drop EXIT_*
altogether.

To git.sr.ht:~emersion/mrsh
   05fed9a..a263f96  master -> master

Thanks!

On Friday, March 29, 2019 1:32 AM, Julian P Samaroo <jpsamaroo@jpsamaroo.me> wrote:
> -	file, err := ini.Load(path.Join(*root, "aerc.conf"))
> +	if _, err := os.Stat(*root); os.IsNotExist(err) {
> +		_err := errors.New("~/.config/aerc/ does not exist, please create it")

No need for a new variable:

    err = errors.New("~/.config/aerc/ does not exist, please create it")

> +		return nil, _err
> +	}