Giter VIP home page Giter VIP logo

clog-cli's Introduction

clog-cli

Join the chat at https://gitter.im/thoughtram/clog

Build Status

A conventional changelog for the rest of us

About

clog creates a changelog automatically from your local git metadata. See the clogs changelog.md for an example.

The way this works, is every time you make a commit, you ensure your commit subject line follows the conventional format. Then when you wish to update your changelog, you simply run clog inside your local repository with any options you'd like to specify.

NOTE: clog also supports empty components by making commit messages such as alias: message or alias(): message (i.e. without the component)

Usage

There are two ways to use clog, as a binary via the command line or as a library in your applications via clog-lib.

Binary (Command Line)

In order to use clog via the command line you must first obtain a binary by either compiling it yourself, or downlading and installing one of the precompiled binaries.

cargo install

If you want to both compile and install clog using cargo you can simply run

cargo install clog-cli

Compiling

Follow these instructions to compile clog, then skip down to Installation.

  1. Ensure you have current version of cargo and Rust installed
  2. Clone the project $ git clone https://github.com/clog-tool/clog-cli && cd clog-cli
  3. Build the project $ cargo build --release
  4. Once complete, the binary will be located at target/release/clog

Using a Precompiled Binary

Currently there are no precompiled binaries available.

Note: The Mac distribution is available on npm via clog-cli.

Installation

Once you have downloaded, or compiled, clog you simply need to place the binary somewhere in your $PATH. If you are not familiar with $PATH read-on; otherwise skip down to Using clog.

Arch Linux

You can use clog-bin from the AUR, or follow the instructions for Linux / OS X

Linux / OS X

You have two options, place clog into a directory that is already located in your $PATH variable (To see which directories those are, open a terminal and type echo "${PATH//:/\n}", the quotation marks are important), or you can add a custom directory to your $PATH

Option 1 If you have write permission to a directory listed in your $PATH or you have root permission (or via sudo), simply copy the clog to that directory # sudo cp clog /usr/local/bin

Option 2 If you do not have root, sudo, or write permission to any directory already in $PATH you can create a directory inside your home directory, and add that. Many people use $HOME/.bin to keep it hidden (and not clutter your home directory), or $HOME/bin if you want it to be always visible. Here is an example to make the directory, add it to $PATH, and copy clog there.

Simply change bin to whatever you'd like to name the directory, and .bashrc to whatever your shell startup file is (usually .bashrc, .bash_profile, or .zshrc)

$ mkdir ~/bin
$ echo "export PATH=$PATH:$HOME/bin" >> ~/.bashrc
$ cp clog ~/bin
$ source ~/.bashrc
Windows

On Windows 7/8 you can add directory to the PATH variable by opening a command line as an administrator and running

C:\> setx path "%path%;C:\path\to\clog\binary"

Otherwise, ensure you have the clog binary in the directory which you operating in the command line from, because Windows automatically adds your current directory to PATH (i.e. if you open a command line to C:\my_project\ to use clog ensure clog.exe is inside that directory as well).

Using clog from the Command Line

clog works by reading your git metadata and specially crafted commit messages and subjects to create a changelog. clog has the following options availble.

USAGE:
    clog [FLAGS] [OPTIONS]

FLAGS:
    -F, --from-latest-tag    use latest tag as start (instead of --from)
    -h, --help               Prints help information
    -M, --major              Increment major version by one (Sets minor and patch to 0)
    -m, --minor              Increment minor version by one (Sets patch to 0)
    -p, --patch              Increment patch version by one
    -V, --version            Prints version information

OPTIONS:
    -C, --changelog <changelog>    A previous changelog to prepend new changes to (this is like
                                   using the same file for both --infile and --outfile and
                                   should not be used in conjuction with either)
    -c, --config <config>          The Clog Configuration TOML file to use (Defaults to
                                   '.clog.toml')**
    -T, --format <format>          The output format, defaults to markdown
                                   (valid values: markdown, json)
    -f, --from <from>              e.g. 12a8546
    -g, --git-dir <gitdir>         Local .git directory (defaults to current dir + '.git')*
    -i, --infile <infile>          A changelog to append to, but *NOT* write to (Useful in
                                   conjunction with --outfile)
    -o, --outfile <outfile>        Where to write the changelog (Defaults to stdout when omitted)
    -r, --repository <repo>        Repository used for generating commit and issue links
                                   (without the .git, e.g. https://github.com/clog-tool/clog-cli)
    -l, --link-style <style>       The style of repository link to generate
                                   (Defaults to github) [values: Github Gitlab Stash]
    -s, --subtitle <subtitle>      e.g. "Crazy Release Title"
    -t, --to <to>                  e.g. 8057684 (Defaults to HEAD when omitted)
        --setversion <ver>         e.g. 1.0.1
    -w, --work-tree <workdir>      Local working tree of the git project
                                   (defaults to current dir)*

* If your .git directory is a child of your project directory (most common, such as
/myproject/.git) AND not in the current working directory (i.e you need to use --work-tree or
--git-dir) you only need to specify either the --work-tree (i.e. /myproject) OR --git-dir (i.e.
/myproject/.git), you don't need to use both.

** If using the --config to specify a clog configuration TOML file NOT in the current working
directory (meaning you need to use --work-tree or --git-dir) AND the TOML file is inside your
project directory (i.e. /myproject/.clog.toml) you do not need to use --work-tree or --git-dir.

Try it!

In order to see it in action, you'll need a repository that already has some of those specially crafted commit messages in it's history. For this, we'll use the clog repository itself.

  1. Clone the repo git clone https://github.com/clog-tool/clog-cli && cd clog-cli

  2. Ensure you already clog binary from any of the steps above

  3. There are many, many ways to run clog. Note, in these examples we will be typing the same options over and over again, in times like that we could a clog TOML configuration file to specify those options that don't normally change. Also note, all these CLI options have short versions as well, we're using the long version because they're easier to understand.

  4. Let's start by picking up only new commits since our last release (this may not be a lot...or none)

  5. Run clog -r https://github.com/clog-tool/clog-cli --outfile only_new.md

  6. By default, clog outputs to stdout unless you have a file set inside a TOML configuration file. (Note, we could have used the shell > operator instead of --outfile)

  7. Anything options you set via the CLI will override anything you set the configuration file.

  8. Let's now tell clog where it can find our old changelog, and prepend any new commits to that old data

  9. Run clog -r https://github.com/clog-tool/clog-cli --infile changelog.md --outfile new_combined.md

  10. Finally, let's assume like most projects we just want to use one file, and prepend all new data to our old changelog (most useful)

  11. First make a backup of the changelog.md so you can compare it later cp changelog.md changelog.md.bak

  12. Run clog -r https://github.com/clog-tool/clog-cli --changelog changelog.md

  13. Try viewing any of the only_new.md, new_combined.md, changelog.md.bak, or changelog.md in your favorite markdown viewer to compare them.

As a Library

See the documentation or clog-lib for information on using clog in your applications. You can also see the clog crates.io page.

Default Options

clog can also be configured using a default configuration file so that you don't have to specify all the options each time you want to update your changelog. To do this add a .clog.toml file to your repository.

[clog]
# A repository link with the trailing '.git' which will be used to generate
# all commit and issue links
repository = "https://github.com/clog-tool/clog-cli"
# A constant release title
subtitle = "my awesome title"

# specify the style of commit links to generate, defaults to "github" if omitted
link-style = "github"

# The preferred way to set a constant changelog. This file will be read for old changelog
# data, then prepended to for new changelog data. It's the equivilant to setting
# both infile and outfile to the same file.
#
# Do not use with outfile or infile fields!
#
# Defaults to stdout when omitted
changelog = "mychangelog.md"

# This sets an output file only! If it exists already, new changelog data will be
# prepended, if not it will be created.
#
# This is useful in conjunction with the infile field if you have a separate file
# that you would like to append after newly created clog data
#
# Defaults to stdout when omitted
outfile = "MyChangelog.md"

# This sets the input file old! Any data inside this file will be appended to any
# new data that clog picks up
#
# This is useful in conjunction with the outfile field where you may wish to read
# from one file and append that data to the clog output in another
infile = "My_old_changelog.md"

# This sets the output format. There are two options "json" or "markdown" and
# defaults to "markdown" when omitted
output-format = "json"

# If you use tags, you can set the following if you wish to only pick
# up changes since your latest tag
from-latest-tag = true

Now you can update your MyChangelog.md with clog --patch (assuming you want to update from the latest tag version, and increment your patch version by 1).

Note: Any options you specify at the command line will override options set in your .clog.toml

Custom Sections

By default, clog will display three sections in your changelog, Features, Performance, and Bug Fixes. You can add additional sections by using a .clog.toml file. To add more sections, simply add a [sections] table, along with the section name and aliases you'd like to use in your commit messages:

[sections]
MySection = ["mysec", "ms"]

Now if you make a commit message such as mysec(Component): some message or ms(Component): some message there will be a new "MySection" section along side the "Features" and "Bug Fixes" areas.

NOTE: Sections with spaces are suppported, such as "My Special Section" = ["ms", "mysec"]

Companion Projects

  • Commitizen - A command line tool that helps you writing better commit messages.

LICENSE

clog is licensed under the MIT Open Source license. For more information, see the LICENSE file in this repository.

clog-cli's People

Contributors

0x-r4bbit avatar badboy avatar benaryorg avatar cburgdorf avatar chills42 avatar gitter-badger avatar kbknapp avatar killercup avatar klausi avatar nvanheuverzwijn avatar orclev avatar perlun avatar ryman avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

clog-cli's Issues

Split clog into lib and bin

It's currently a bit unfortunate that clog's core functionality isn't available as a lib. If I want to write another app that wants to use clog I would have to find a way to bundle the binary with my app and call it as another process. But that doesn't seem to be easily supported by cargo yet.

//cc @kbknapp

Relicense under dual MIT/Apache-2.0

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it
.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 clog-cli Developers
//
// Licensed under the Apache License, Version 2.0, <LICENSE-APACHE or
// http://apache.org/licenses/LICENSE-2.0> or the MIT license <LICENSE-MIT or
// http://opensource.org/licenses/MIT>, at your option. This file may not be
// copied, modified, or distributed except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT OR Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

chore: add more default sections

Currently we ship with only Bug Fixes and Features the angular conventions we link to uses quite a few more sections as well. It'd be nice to ship with a few more of the default sections, perhaps not all of them, but at least a few that are nice to display in a changelog (such as performance, test, docs, etc.)

Windows Build

Hi,
I just downloaded clog-v0.7.0_windows-x64.zip binary and when I executed I get the following error:

clog thread '<main>' panicked at 'index 0 and/or 8 in``do not lie on character boundary', C:/bot/slave/stable-dist-rustc-win-64/build/src/libcore\str/mod.rs:1

Do you know how to solve it? I have Win 10 and I don't have installed Rust.

Thanks

Docs in the cargo package source

clog 0.8.1 has 17MB of ./docs in their cargo package source. Since this is 17 MB users shouldn't have to download to depend on the package, consider releasing a new clean version.

This is a reminder that cargo includes all non-ignored files in your working directory when you publish โ€” look at git status before you publish.

(I downloaded all crates.io crates and I started to grep for junk)

feat(lib): allow users to use custom conventions

@vyp came up with the great point of allowing users to define custom conventions that can be consumed by clog.

This issue should help us discussing this feature and how we want to implement it. It's clear that we need an AST in order to understand any convention, but therefore we also need a lexer/tokenizer that consumes a context free grammar that is defined by the user.

I'll think about what it could look like from a user perspective when hooking up a custom convention. Any thoughts regarding this implementation are very welcome!

Fails to build

My versions, installed about a day (24 hours) ago:

$ rustc --version
rustc 0.13.0-nightly (99d6956c3 2014-12-18 20:32:07 +0000)

$ cargo --version
cargo 0.0.1-pre-nightly (5af754d 2014-12-18 01:50:48 +0000)

If it matters, I'm on arch linux, using the rust-nightly-bin and cargo-nightly-bin AUR packages.


cargo build in this repository gives (what looks like) syntax errors when attempting to build docopt. Their latest commits and release (0.6.16) fixes this.

So cargo update -p docopt, and then cargo build --verbose results in the following error:

       Fresh docopt v0.6.16 (https://github.com/docopt/docopt.rs#3f39bcc7)
       Fresh docopt_macros v0.6.16 (https://github.com/docopt/docopt.rs#3f39bcc7)
   Compiling clog v0.2.0 (file:///home/rws/code/gen/clog2)
     Running `rustc /home/rws/code/gen/clog2/src/main.rs --crate-name clog --crate-type bin -g --out-dir /home/rws/code/gen/clog2/target --dep-info /home/rws/code/gen/clog2/target/.fingerprint/clog-76bd6c1d8f39f9ac/dep-bin-clog -L /home/rws/code/gen/clog2/target -L /home/rws/code/gen/clog2/target/deps --extern docopt_macros=/home/rws/code/gen/clog2/target/deps/libdocopt_macros-c59a259f9c0bfb33.so --extern docopt=/home/rws/code/gen/clog2/target/deps/libdocopt-29a30eb0650840d7.rlib`
/home/rws/code/gen/clog2/src/main.rs:41:34: 41:35 error: macros that expand to items must either be surrounded with braces or followed by a semicolon
/home/rws/code/gen/clog2/src/main.rs:41   flag_setversion: Option<String>)
                                                                         ^
error: aborting due to previous error
Could not compile `clog`.

Caused by:
  Process didn't exit successfully: `rustc /home/rws/code/gen/clog2/src/main.rs --crate-name clog --crate-type bin -g --out-dir /home/rws/code/gen/clog2/target --dep-info /home/rws/code/gen/clog2/target/.fingerprint/clog-76bd6c1d8f39f9ac/dep-bin-clog -L /home/rws/code/gen/clog2/target -L /home/rws/code/gen/clog2/target/deps --extern docopt_macros=/home/rws/code/gen/clog2/target/deps/libdocopt_macros-c59a259f9c0bfb33.so --extern docopt=/home/rws/code/gen/clog2/target/deps/libdocopt-29a30eb0650840d7.rlib` (status=101)

So add in a semicolon at the end of line 41 in src/main.rs, and then cargo build --verbose results in the following error:

       Fresh docopt v0.6.16 (https://github.com/docopt/docopt.rs#3f39bcc7)
       Fresh docopt_macros v0.6.16 (https://github.com/docopt/docopt.rs#3f39bcc7)
   Compiling clog v0.2.0 (file:///home/rws/code/gen/clog2)
     Running `rustc /home/rws/code/gen/clog2/src/main.rs --crate-name clog --crate-type bin -g --out-dir /home/rws/code/gen/clog2/target --dep-info /home/rws/code/gen/clog2/target/.fingerprint/clog-76bd6c1d8f39f9ac/dep-bin-clog -L /home/rws/code/gen/clog2/target -L /home/rws/code/gen/clog2/target/deps --extern docopt_macros=/home/rws/code/gen/clog2/target/deps/libdocopt_macros-c59a259f9c0bfb33.so --extern docopt=/home/rws/code/gen/clog2/target/deps/libdocopt-29a30eb0650840d7.rlib`
/home/rws/code/gen/clog2/src/log_writer.rs:1:5: 1:39 error: unresolved import `std::collections::hashmap::HashMap`. Could not find `hashmap` in `std::collections`
/home/rws/code/gen/clog2/src/log_writer.rs:1 use std::collections::hashmap::HashMap;
                                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/rws/code/gen/clog2/src/common.rs:2:5: 2:39 error: unresolved import `std::collections::hashmap::HashMap`. Could not find `hashmap` in `std::collections`
/home/rws/code/gen/clog2/src/common.rs:2 use std::collections::hashmap::HashMap;
                                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/rws/code/gen/clog2/src/section_builder.rs:1:5: 1:39 error: unresolved import `std::collections::hashmap::HashMap`. Could not find `hashmap` in `std::collections`
/home/rws/code/gen/clog2/src/section_builder.rs:1 use std::collections::hashmap::HashMap;
                                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/rws/code/gen/clog2/src/section_builder.rs:2:5: 2:30 error: unresolved import `std::collections::hashmap`. There is no `hashmap` in `std::collections`
/home/rws/code/gen/clog2/src/section_builder.rs:2 use std::collections::hashmap;
                                                      ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/rws/code/gen/clog2/src/section_builder.rs:3:37: 3:44 error: unresolved import `common::Feature`. There is no `Feature` in `common`
/home/rws/code/gen/clog2/src/section_builder.rs:3 use common::{ LogEntry, SectionMap, Feature, Fix };
                                                                                      ^~~~~~~
/home/rws/code/gen/clog2/src/section_builder.rs:3:46: 3:49 error: unresolved import `common::Fix`. There is no `Fix` in `common`
/home/rws/code/gen/clog2/src/section_builder.rs:3 use common::{ LogEntry, SectionMap, Feature, Fix };
                                                                                               ^~~
/home/rws/code/gen/clog2/src/git.rs:3:26: 3:33 error: unresolved import `common::Feature`. There is no `Feature` in `common`
/home/rws/code/gen/clog2/src/git.rs:3 use common:: { LogEntry, Feature, Fix, Unknown };
                                                               ^~~~~~~
/home/rws/code/gen/clog2/src/git.rs:3:35: 3:38 error: unresolved import `common::Fix`. There is no `Fix` in `common`
/home/rws/code/gen/clog2/src/git.rs:3 use common:: { LogEntry, Feature, Fix, Unknown };
                                                                        ^~~
/home/rws/code/gen/clog2/src/git.rs:3:40: 3:47 error: unresolved import `common::Unknown`. There is no `Unknown` in `common`
/home/rws/code/gen/clog2/src/git.rs:3 use common:: { LogEntry, Feature, Fix, Unknown };
                                                                             ^~~~~~~
/home/rws/code/gen/clog2/src/main.rs:17:5: 17:23 error: unresolved import `docopt::FlagParser`. There is no `FlagParser` in `docopt`
/home/rws/code/gen/clog2/src/main.rs:17 use docopt::FlagParser;
                                            ^~~~~~~~~~~~~~~~~~
error: aborting due to 10 previous errors
Could not compile `clog`.

Caused by:
  Process didn't exit successfully: `rustc /home/rws/code/gen/clog2/src/main.rs --crate-name clog --crate-type bin -g --out-dir /home/rws/code/gen/clog2/target --dep-info /home/rws/code/gen/clog2/target/.fingerprint/clog-76bd6c1d8f39f9ac/dep-bin-clog -L /home/rws/code/gen/clog2/target -L /home/rws/code/gen/clog2/target/deps --extern docopt_macros=/home/rws/code/gen/clog2/target/deps/libdocopt_macros-c59a259f9c0bfb33.so --extern docopt=/home/rws/code/gen/clog2/target/deps/libdocopt-29a30eb0650840d7.rlib` (status=101)

This is where I decided to stop and open this issue, because I have little to no knowledge of rust yet (just started).

Add support for Stash as a repository

Stash and github are largely compatible but differ in very slight ways. It would be nice if clog could generate links not only for github, but also for stash. In order to support this there should be an option to provide the flavor of repository links should be generated for.

I've implemented this in a fork and can do a pull request assuming you don't have any changes you want me to implement. My current implementation adds a new CLI parameter --repoflavor and a TOML option repo-flavor, both of which accept either "github" or "stash" as arguments (case insensitive). This new parameter controls two aspects of the changelog generation. Firstly it changes the commit links to follow the proper convention for the respective repository flavor. Secondly it changes the issue links to not be generated in the case of stash (because it doesn't have built in issue tracking). This approach is flexible and it should be relatively trivial to add support for other kinds of repository flavor down the line (bitbucket maybe?).

Always append to file if it exists

I wonder if we should use a flag like --file-mode=append / --file-mode=new for that. But then on the other hand, it's trivial to rm changelog if one wants to have a new file. It seems to be more aligned with the UNIX way of thinking to just always append and use rm if one wants the opposite.

Bring in npm publication repo to clog org

I don't mind maintaining the repo I'm using to distribute clog via npm, but do you think it would make more sense as part of the clog-tool org? I'd happily transfer it to this org and change it's name to npm-distribution or something (so it doesn't conflict with what's being discussed in #70).

Should clog allow reading old changelog without writing to it?

With the new #64 PR I realized that clog cannot currently read an old changelog and save to a new location. If it reads from an old changelog, it always writes back out to that location. It may be useful to allow reading from an old changelog and outputting to a new one, or arbitrary location.

Imagine wanting to run clog and suck up all the old data, but output to stdout? Currently you can't. It either reads everything from the old one, and writes back out to it, or doesn't read the old one and prints to stdout.

What do you think?

Add instructions on how to install the binaries

Love the work that is happening here.

However, whereas the readme describes how I can use clog as a library, there's no information on how I can install and use the binaries. I know, it might be obvious to a lot of people, but to make it even easier for everyone, It'd be nice if there was a n instruction that tells you where to download the binary, where to put it on your system and finally, that you might have to configure your $PATH and how.

quesion: split repo into lib and cli

As far as I can see, the code base is already structured and spit into library and cli code. Now that we moved the code to this organisation, we could also consider having a dedicated cli and lib repo.

Thoughts?

Allow user defined sections and aliases

Currently only two sections become viewable in the changelog, Features and Fixes. I'd propose allowing users to define additional sections, and the aliases of those sections in their .clog.toml

This issue would allow adding sections (and aliases) only, i.e. not taking away of the standard sections and aliases.

I'm thinking something like

[clog]
# ...

[sections]
MyCustom = ["mc", "mycust"]

fix(log_writer): generate list for component even for one commit

I encountered a behaviour which I consider a bug, but I might be wrong. This is my commit history:

* 2970d06 (HEAD, tag: 1.1, master) fix(lexer): tokenize more strict
* 083c40b (tag: 1.0) fix(compiler): adds missing constructor parameter
* ecc200d fix(compiler): adds missing constructor
* c5c2471 feat(compiler): implements lexer
* 6603503 chore: initial commit

As we can see, there's only one commit for lexer. Generating a changelog, gives me this output:

screen shot 2015-07-13 at 14 51 20

Component lexer doesn't have a list. IMO even if there's only a single message for a component, a list should be generated.

feat(website): create website

Hey everyone,

I'm currently working on a nice little website for the project so we can promote it a little bit better and also because, awesome projects deserve awesome websites. It's really just about making a nice landing page with all the needed information to get started and some links to the GitHub repo and the docs (which we will publish on gh-pages through this repo).

Here's a screenshot of the work-in-progress:

screen shot 2015-07-08 at 16 53 19

Would love to hear your thoughts! Feedback is highly welcome. Also, it'd be nice if we could brainstorm a little bit about the content of the site. Maybe you have some cool ideas.

In addition to that, @Nevraeka is so kind to help us out and works on a very nice logo too, based on this scribble:
screen shot 2015-07-08 at 22 50 12

ui/ux(cli): create and update message

This is really just for better UX:

Whenever I create or update a changelog with clog the output I get is always:

$ changelog updated (took xx ms)

I think it'd be nicer if the tools states that it created a changelog, if that's the case and only updates if that's the case.

Empty changelog

Hello everybody @kbknapp

I am not sure what i am doing wrong. I use Arch Linux and i have installed clog-git from the AUR, I have proved too with git-bin but the result is the same.

After execute

clog -r https://github.com/clog-tool/clog-cli --outfile only_new.md

I always obtain a file with only two lines
only_new.md.zip

Could someone help me to find out where is my mistake?

Thanks in advance

Parsing pull request message

Is there any way clog-cli can parse a github PR commit message ? In our workflow, we do use feature/branch and are using PR only. When we merge the PR, we set the conventional commit message into the long commit message of the PR but clog fails to parse this part of the commit.

Implement aliases

ft(x) should expand to feat(x)
fx(x) should expand to fix(x)
rf(x) should expand to refactor(x)
ch(x) should expand to chore(x)

Can't compile with latest Cargo + Rust

% cargo --version
cargo 0.0.1-pre-nightly (9788700 2014-10-15 20:14:53 +0000)
% rustc --version
rustc 0.13.0-nightly (1600e0b93 2014-10-17 00:17:25 +0000)
% cargo build --verbose
   Compiling docopt v0.6.3 (https://github.com/docopt/docopt.rs#00422e3e)
     Running `rustc /Users/luca/.cargo/git/checkouts/docopt.rs-643e15305361a76f/master/src/lib.rs --crate-name docopt --crate-type lib -g -C metadata=c165ee05d1fe3dd7 -C extra-filename=-c165ee05d1fe3dd7 --out-dir /Users/luca/Code/clog/target/deps --dep-info /Users/luca/Code/clog/target/.fingerprint/docopt-c165ee05d1fe3dd7/dep-lib-docopt -L /Users/luca/Code/clog/target/deps -L /Users/luca/Code/clog/target/deps`
/Users/luca/.cargo/git/checkouts/docopt.rs-643e15305361a76f/master/src/lib.rs:196:1: 196:20 error: can't find crate for `debug`
/Users/luca/.cargo/git/checkouts/docopt.rs-643e15305361a76f/master/src/lib.rs:196 extern crate debug;
                                                                                  ^~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
Could not compile `docopt`.

Caused by:
  Process didn't exit successfully: `rustc /Users/luca/.cargo/git/checkouts/docopt.rs-643e15305361a76f/master/src/lib.rs --crate-name docopt --crate-type lib -g -C metadata=c165ee05d1fe3dd7 -C extra-filename=-c165ee05d1fe3dd7 --out-dir /Users/luca/Code/clog/target/deps --dep-info /Users/luca/Code/clog/target/.fingerprint/docopt-c165ee05d1fe3dd7/dep-lib-docopt -L /Users/luca/Code/clog/target/deps -L /Users/luca/Code/clog/target/deps -Awarnings` (status=101)

Breaking changes

The conventional changelog description lists:

Breaking Changes are detected as such if the footer contains a line starting with BREAKING CHANGE: (with optional newlines) The rest of the commit message is then used for this.

I couldn't find anything in the repo referencing 'breaking', and the tool hasn't been picking them up, so I'm assuming this is unimplemented. Is this a missing feature, or have I overlooked something?

Error in an untagged repository

When create a new repo, clog -p(or -M, -m), it fails as this:

error: Failed to parse version into valid SemVer. Ensure the version is in the X.Y.Z format.

And, --setversion is not funtional in this case.

Provide Arch AUR package

@vyp

To alleviate some of the discussion from #20 I've started this issue.

I've uploaded a rust-beta-bin package to the AUR which you can use in your makedepends array since we're targeting stable Rust (even though clog should also build just fine with nightly). This provides cargo and rust so you won't need to specify those as a make-dep any more.

Let me publish to npm?

Do you mind if I publish the binary to npm? Unless you have some auto-update magic going on that I'm not aware of, it would make getting updates easier (I'd be happy to keep the module updated). I did this with cloc (coincidentally a similar name) and it's been handy to be able to simply install it globally using the same package manager that I'm used to. I think it would help adoption as well.

Let me know what you think.

Version should probably be required

If no version is supplied and no repository link (e.g. cargo run) then the output is:

<a name=""</a>
##  (2014-09-26)

compared to something with a version & repository link:

## 0.2.0 (2014-09-23)

So, other than the minor bug in the anchor tag (unclosed tag and I think the logic is reversed?).

I think the version should be a required value, or print the date without brackets, or print a branch+sha1 as a version number. Either way something's fishy about that a tag and I'm not sure what's intended.

RFC: Adding bots

In clap we've been using Rust-highfive and Homu to assist with contributions. Rust-highfive (@yo-bot) automatically assigns a reviewer to PRs from a pool of contributors and allows things like reassigning to another reviewer with r? @user which is nice for things like replying from e-mail.

Homu (@homu) on the other hand tests and auto-merges PRs once a reviewer has reviewed and accepted a PR by using @homu r+.

Thoughts on adding these for the clog repos? Homu is a hosted service (free), and Rust-highfive is a free service hosted on a VPS I've got.

Explicit Changelog Standard

I am not sure if Clog or Clog-CLI currently aggrees on an explicit standard for the change logs it generates, but I think that would have a tremendious impact on the Rust crate ecosystem.

Many points are pointed out in this post. But to summarize a standard on how a change log should look (as well as the file name e.g. CHANGELOG.md), would lead to a parseable crate ecosystem and would help spreading best practices faster.

A lot of work on standarizing was already done by http://keepachangelog.com/ and https://github.com/tech-angels/vandamme/ . Basing Clog on such a standard would bring the Rust crate system forward. Happy to discuss thoughts on this :)

An agreed standard would help to resolve some minor issues I would propose such as:

  • Referencing Issues in the changelog (e.g. CLOSED)
  • Referencing the authors
  • Adding semantic versioning support
  • And discussing the overall structure/outline. KeepAChangelog, proposeses e.g. also deprecation and security notes

chore: consider moving clog to it's own organisation

Clog repositories are piling up in the thoughtram organisation, which is not a deal breaker, but it might be nicer to have an organisation for that project. We currently have repos for the cli tool (maybe even the library get's it's own repo in the future? @kbknapp), the website, logo media and so on and so forth. We might even end up with corresponding server repositories.

What do you think?

Add ability to specify changlog file name

It would be nice if there was both a command line option, and a config file parameter to specify the name of the changelog file. In particular it seems it's very common to call the file "CHANGELOG.md", where as the filename in clog is hard coded currently to "changelog.md".

docs: add usage examples to readme

clog's readme is quite comprehensive, which is great. However, it still misses the most simple example on how to use it. We already display the output of clog --help but it'd be great to see how I can generate a changelog from a single command.

Missing --to implementation and wrong documented --from?

I wanted to create a CHANGELOG for a repo, that already had some history and releases - thankfully the commits were all in the same style. Let's assume the repo already had two releases: 0.1.0 and 0.2.0.

So I expcted, that after the execution of the following commands, I would have a CHANGELOG file with the correct history.

clog --setversion 0.1.0 --from 123 --to 456 -C CHANGELOG.md
clog --setversion 0.2.0 --from 456 --to 789 -C CHANGELOG.md

As the docu stated --from and --to assume a commit hash. But after frustation of why clog didn't found the commit hash, I looked into the code and found, that --from works only with a version tag - which it then did. But for --to neither a version tag nor a commit hash worked and I couldn't find any actual implementation for that CLI option, either.

Generate binaries for windows

@Ryman do you have any experience with Rust on windows? Especially how to automate it? Does it make sense to put windows on a vagrant box and somehow script it to auto generate windows builds?

chore: clog should write to stdout

Currently, clog creates a markdown file by default. As discussed in #57, I think it'd make sense if writers could be swapped out.

This raises my next question: Unix commands usually write to stdout by default. If we implement a writer abstraction, so we can plug more into clog, we shouldn't prefer one over the other. Which brings me to the point, that it might be better if clog writes to stdout by default.

Of course, this adds the complexity that you always have to provide a writer option in case you don't want to write to stdout, but this is how most/all UNIX commands work.

Thoughts on this?

feat(writer): add writer abstraction so they can be swapped out

Clog creates and writes markdown files by default. I think there are also use cases, where don't want markdown as output, but rather JSON. It'd be cool if we could plug in any writer, as long as it implements a certain interface. The writer could then be configurable through .clog.toml and cli options.

LogWriter would then just be another writer that can be plugged into clog.

@kbknapp @cburgdorf wdyt?

docs(website): deploy generated docs on gh-pages branch

With the release of clog's new website, we should also make the documentation of the project accessible. AFAIK, the documentation is already generated automatically (which is awesome). We now need to deploy it to gh-pages branch, so it can be served by GitHub.

Update README.md to include .clog.toml options

This should probably go either in the README.md or the documentation somewhere.

I would also recommend putting a manual --from <hash> in the Try it section. Because right now, the .clog.toml for this project uses from-latest-tag = true which won't show a whole lot to the user trying it if not much has changed.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.