Mailing List Archive: GnuPG: devel

[PATCH 0/2] gitignore and string.h updates for GPGME

Index | Next | Previous | View Threaded

wking at drexel

Apr 12, 2012, 10:51 AM

Post #1 of 5 (322 views)
Permalink

[PATCH 0/2] gitignore and string.h updates for GPGME

While I'm waiting for the go-ahead for more major socket changes to
GPGME, here are a few more minor cleanups. I think I got the ChangeLog
commit message format right this time ;).

W. Trevor King (2):
.gitignore: flesh out rules and add subdirectory-.gitignores.
status-table.c: include string.h for strcmp.

.gitignore | 13 ++++++++-----
doc/.gitignore | 5 +++++
lang/cl/.gitignore | 1 +
src/.gitignore | 7 +++++++
src/status-table.c | 1 +
tests/.gitignore | 10 ++++++++++
tests/gpg/.gitignore | 30 ++++++++++++++++++++++++++++++
tests/gpgsm/.gitignore | 17 +++++++++++++++++
tests/opassuan/.gitignore | 3 +++
9 files changed, 82 insertions(+), 5 deletions(-)
create mode 100644 doc/.gitignore
create mode 100644 lang/cl/.gitignore
create mode 100644 src/.gitignore
create mode 100644 tests/.gitignore
create mode 100644 tests/gpg/.gitignore
create mode 100644 tests/gpgsm/.gitignore
create mode 100644 tests/opassuan/.gitignore

--
1.7.3.4

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wk at gnupg

Apr 13, 2012, 1:17 AM

Post #2 of 5 (298 views)
Permalink

Re: [PATCH 0/2] gitignore and string.h updates for GPGME [In reply to]

Hi!
On Thu, 12 Apr 2012 19:51, wking [at] drexel said:
> While I'm waiting for the go-ahead for more major socket changes to
> GPGME, here are a few more minor cleanups. I think I got the ChangeLog
> commit message format right this time ;).

Kind of:

* .gitignore: ignore object files and libtool files. Move
subdir-specific rules to subdir-specific .gitignores.

That one is fine.

* doc/.gitignore, lang/cl/.gitignore, src/.gitignore,
tests/.gitignore, tests/gpg/.gitignore, tests/gpgsm/.gitignore,
tests/opassuan/.gitignore: Add subdir-specific ignore rules, so `git
status` can focus on interesting changes.

According to the GNU standards, this should be:

* doc/.gitignore, lang/cl/.gitignore, src/.gitignore
* tests/.gitignore, tests/gpg/.gitignore, tests/gpgsm/.gitignore
* tests/opassuan/.gitignore: Add subdir-specific ignore rules, so `git
status` can focus on interesting changes.

The backticks are a nice idea, but $(git status) is more POSIXly ;-).

Two more comments:

.gitignore is nothing really important and will even not be distributed
in a tarball. Thus I would not mention them at all in the ChangeLog. I
would have used this commit message:

flesh out rules and add subdirectory-.gitignores.

--
If you feel like explaining it, do it here. Everything after
the tearoff line won't be copied to the CHnageLog. If the tear-off
line is the first in the body, no entry will be created at all.

I also prefer to have just one .gitignore in the top directory. The
reason why you need the new items is that you don't do a VPATH build.
Marcus and me prefer VPATH builds, because they keep the source
directory clean and best of all, you can do several build using
different configure options. For example, I have one work directory and
several build directories:

cd ~/b/gnupg
~/w/gnupg/configure .....
make
cd ~/b-w32/gnupg
~/w/gnupg/autogen.sh --build-w32
make
cd ~/b-w32ce/gnupg
~/w/gnupg/autogen.sh --build-w32ce
make

It is also possible to keep build directores for other branches, like

cd ~/b/gnupg-2.0
~/w/gnupg/configure .....
make

Nevertheless, havig rules for non-VPATH buils in .gitignore is fine.

I applied :status-table.c: include string.h for strcmp.".

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

marcus.brinkmann at ruhr-uni-bochum

Apr 13, 2012, 3:59 AM

Post #3 of 5 (298 views)
Permalink

Re: [PATCH 0/2] gitignore and string.h updates for GPGME [In reply to]

On 04/13/2012 10:17 AM, Werner Koch wrote:
> * doc/.gitignore, lang/cl/.gitignore, src/.gitignore,
> tests/.gitignore, tests/gpg/.gitignore, tests/gpgsm/.gitignore,
> tests/opassuan/.gitignore: Add subdir-specific ignore rules, so `git
> status` can focus on interesting changes.
>
> According to the GNU standards, this should be:
>
> * doc/.gitignore, lang/cl/.gitignore, src/.gitignore
> * tests/.gitignore, tests/gpg/.gitignore, tests/gpgsm/.gitignore
> * tests/opassuan/.gitignore: Add subdir-specific ignore rules, so `git
> status` can focus on interesting changes.

Are you sure? This looks wrong to me, as a "*" starts a new item, and
every item should have a file (or list of files), followed by a location
within the file in () if useful and then a colon and the description of
the change.

Just putting * in front of every line because there is a line break
doesn't seem right to me, and I never did that. It's also not how emacs
fill-paragraph formats it when confronted with the situation...

Thanks,
Marcus

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wk at gnupg

Apr 13, 2012, 5:58 AM

Post #4 of 5 (298 views)
Permalink

Re: [PATCH 0/2] gitignore and string.h updates for GPGME [In reply to]

On Fri, 13 Apr 2012 12:59, marcus.brinkmann [at] ruhr-uni-bochum said:
>> * doc/.gitignore, lang/cl/.gitignore, src/.gitignore
>> * tests/.gitignore, tests/gpg/.gitignore, tests/gpgsm/.gitignore
>> * tests/opassuan/.gitignore: Add subdir-specific ignore rules, so `git
>> status` can focus on interesting changes.
>
> Are you sure? This looks wrong to me, as a "*" starts a new item, and

Yes. The asterisk indicates a list of files. The missing colon at the
end of the line indcates that more lines for this item will follow. You
don't use an asterisk if it is another function:

* foo.c (usage_1, usage_2, usage)
(help): Add help strings.

> doesn't seem right to me, and I never did that. It's also not how emacs
> fill-paragraph formats it when confronted with the situation...

That has never worked correctly ;) The standards file doesn't tell it
explicitly, probably because the case of only new files with no function
names is rare. However it states:

Separate unrelated change log entries with blank lines. When two
entries represent parts of the same change, so that they work together,
then don't put blank lines between them. Then you can omit the file
name and the asterisk when successive entries are in the same file.

At least this is my interpretation.

BTW, did anyone worked on Magit's 'C' command so work more similar to
C-x a 4 ?

>
> Thanks,
> Marcus
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel [at] gnupg
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

wking at drexel

Apr 13, 2012, 7:35 AM

Post #5 of 5 (298 views)
Permalink

Re: [PATCH 0/2] gitignore and string.h updates for GPGME [In reply to]

On Fri, Apr 13, 2012 at 10:17:37AM +0200, Werner Koch wrote:
> The backticks are a nice idea, but $(git status) is more POSIXly ;-).

Alright. I mostly use the backticks because it's also Markdown. I'm
fine with $($()) though ;).

> .gitignore is nothing really important and will even not be distributed
> in a tarball. Thus I would not mention them at all in the ChangeLog.

Ok.

> I also prefer to have just one .gitignore in the top directory. The
> reason why you need the new items is that you don't do a VPATH build.

That's a good reason. I was mostly responding to "top-level gitignore
considered harmful" [1], but with the limited number of files in the
GPGME repo, I don't expect Git efficiency to become an issue. I'll
send over a single-gitignore version of that patch (off list), once I
write it up.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/194294/focus=194341

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Attachments:

signature.asc (0.48 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads