delta/git.git, branch jc/ref-excludes

rev-parse: introduce --exclude= to tame wildcards

2013-11-01T20:09:45+00:00

Teach "rev-parse" the same "I'm going to glob, but omit the ones
that match these patterns" feature as "rev-list".

Signed-off-by: Junio C Hamano

rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API

2013-11-01T20:09:24+00:00

... while updating their function signature.  To be squashed into
the initial patch to rev-list.

Signed-off-by: Junio C Hamano

rev-list --exclude: tests

2013-11-01T20:09:23+00:00

Add tests for the --exclude= feature.

A few tests are added for cases where use of globbing and
"--exclude" results in no positive revisions:

 * "--exclude=" before "--all" etc. resulted in no results;

 * "--stdin" is used but no input was given;

 * "--all" etc. is used but no matching refs are found.

Currently, we fail such a request with the same error message we
would give to a command line that does not specify any positive
revision (e.g. "git rev-list").

We may want to treat these cases differently and not error out, but
the logic to detect that would be common to all of them, so I'd
leave it outside this topic for now, and stop at adding these tests
as food-for-thought.

Signed-off-by: Junio C Hamano

document --exclude option

2013-11-01T20:09:19+00:00

Signed-off-by: Johannes Sixt 
Signed-off-by: Junio C Hamano

revision: introduce --exclude= to tame wildcards

2013-08-30T23:37:55+00:00

People often find "git log --branches" etc. that includes _all_
branches is cumbersome to use when they want to grab most but except
some.  The same applies to --tags, --all and --glob.

Teach the revision machinery to remember patterns, and then upon the
next such a globbing option, exclude those that match the pattern.

With this, I can view only my integration branches (e.g. maint,
master, etc.) without topic branches, which are named after two
letters from primary authors' names, slash and topic name.

    git rev-list --no-walk --exclude=??/* --branches |
    git name-rev --refs refs/heads/* --stdin

This one shows things reachable from local and remote branches that
have not been merged to the integration branches.

    git log --remotes --branches --not --exclude=??/* --branches

It may be a bit rough around the edges, in that the pattern to give
the exclude option depends on what globbing option follows.  In
these examples, the pattern "??/*" is used, not "refs/heads/??/*",
because the globbing option that follows the -"-exclude="
is "--branches".  As each use of globbing option resets previously
set "--exclude", this may not be such a bad thing, though.

Signed-off-by: Junio C Hamano

Git 1.8.4

2013-08-23T18:49:46+00:00

Signed-off-by: Junio C Hamano

Typofix draft release notes to 1.8.4

2013-08-21T22:30:04+00:00

Signed-off-by: Junio C Hamano

Git 1.8.4-rc4

2013-08-19T17:34:14+00:00

As we had to revert two topics at the last minute, let's have
another (hopefully short) round of rc to make sure the final release
will be sound.

Signed-off-by: Junio C Hamano

Revert "Add new @ shortcut for HEAD"

2013-08-14T22:04:24+00:00

This reverts commit cdfd94837b27c220f70f032b596ea993d195488f, as it
does not just apply to "@" (and forms with modifiers like @{u}
applied to it), but also affects e.g. "refs/heads/@/foo", which it
shouldn't.

The basic idea of giving a short-hand might be good, and the topic
can be retried later, but let's revert to avoid affecting existing
use cases for now for the upcoming release.

Revert "git stash: avoid data loss when "git stash save" kills a directory"

2013-08-14T16:53:43+00:00

This reverts commit a73653130edd6a8977106d45a8092c09040f9132, as it
has been reported that "ls-files --killed" is too time-consuming in
a deep directory with too many untracked crufts (e.g. $HOME/.git
tracking only a few files).

We'd need to revisit it later but "ls-files --killed" needs to be
optimized before it happens.