Hello git devs!
The Open Invention Network has recently expanded the definition of the
Linux system it seeks to defend from patent aggression.
We're also actively reaching out to the open source community to invite as
many projects and related organisations to join us. There's strength in
number
I'm not altogether sure the best way to update the internal usage
from git-log -h, but this at least updates the man page.
Signed-off-by: Lawrence Siebert
---
Documentation/git-log.txt | 2 ++
Documentation/rev-list-options.txt | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
di
This should fix the whitespace issues this had previously.
Lawrence Siebert (4):
list-object: add get_commit_count function
log: add --count option to git log
log --count: added test
git-log: update man documentation for --count
Documentation/git-log.txt | 2 ++
Documentation
adds --count from git rev-list to git log, without --use-bitmap-index
for the moment.
Signed-off-by: Lawrence Siebert
---
builtin/log.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/builtin/log.c b/builtin/log.c
index 8781049..4aaff3a 100644
--- a/builtin/log
added test comparing output between git log --count HEAD and
git rev-list --count HEAD
Signed-off-by: Lawrence Siebert
---
t/t4202-log.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 1b2e981..35f8d82 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-lo
Moving commit counting from rev-list into list-object which is a step
toward letting git log do counting as well.
Signed-off-by: Lawrence Siebert
---
builtin/rev-list.c | 12 ++--
list-objects.c | 14 ++
list-objects.h | 1 +
3 files changed, 17 insertions(+), 10 del
Thanks. I've modified my vim config to avoid this happening again,
and i'll submit a fixed version of these patches.
I'd love if there was a precommit hook to test for this.
Lawrence
On Thu, Jul 2, 2015 at 2:14 AM, Remi Galan Alfonso
wrote:
> Lawrence Siebert writes:
>> +prepa
On Fri, Jul 3, 2015 at 12:06 AM, Eric Sunshine wrote:
>> Unless we want to borrow fancy checkout options for "git worktree
>> add", we probably should just export checkout() function from clone.c
>> and use it instead of "git checkout". Much more lightweight and
>> simpler (it's one-way merge). Th
On Thu, Jul 2, 2015 at 3:00 PM, Eric Sunshine wrote:
> On Thu, Jul 2, 2015 at 2:45 PM, Eric Sunshine wrote:
>> There's another instance: 3473ad0 (checkout: don't require a work tree
>> when checking out into a new one, 2014-11-30) added this:
>>
>> if (!new_worktree)
>> setup_work_tre
On Thu, Jul 2, 2015 at 2:45 PM, Eric Sunshine wrote:
> There's another instance: 3473ad0 (checkout: don't require a work tree
> when checking out into a new one, 2014-11-30) added this:
>
> if (!new_worktree)
> setup_work_tree();
>
> which the "worktree add" patch changed to:
>
> s
On Wed, Jul 1, 2015 at 10:52 PM, Eric Sunshine wrote:
> However, there are still a few bits of
> code which want to know that the checkout is happening in a new
> worktree. I haven't examined them closely yet to diagnose if this
> specialized knowledge can be eliminated. Perhaps you can weight in.
On Wed, 2015-07-01 at 14:19 -0700, Junio C Hamano wrote:
> Matthieu Moy writes:
>
> > So activating --follow for all "git log" calls would prevent log from
> > being used with several pathspecs.
> >
> > Or, do you have a preparation patch that allows --follow with multiple
> > pathspecs? ;-)
> >
On 02/07/2015 20:16, Paul Tan wrote:
> Since a078f73 (git-am: add --message-id/--no-message-id, 2014-11-25),
> the am.messageid setting determines whether the --message-id option is
> set by default.
>
> Add a test for this.
>
> Cc: Paolo Bonzini
> Signed-off-by: Paul Tan
> ---
> t/t4150-am.
Since 8389b52 (git-rerere: reuse recorded resolve., 2006-01-28), git-am
will call git-rerere to re-use recorded merge conflict resolutions if
any occur in a threeway merge.
Add a test to ensure that git-rerere is called by git-am (which handles
the non-interactive rebase).
Cc: Junio C Hamano
Sig
Since 017678b (am/mailinfo: Disable scissors processing by default,
2009-08-26), git-am supported the --[no-]scissors option, passing it to
git-mailinfo.
Add tests to ensure that git-am will pass the --scissors option to
git-mailinfo, and that --no-scissors will override the configuration
setting
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am
supported the --utf8 and --no-utf8 options, and if set, would pass the
-u flag and the -k flag respectively.
git mailinfo -u will re-code the commit log message and authorship info
in the charset specified by i18n.commitencodin
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07),
git-am.sh will invoke the post-applypatch hook after the patch is
applied and a commit is made. The exit code of the hook is ignored.
Add tests for this hook.
Cc: Junio C Hamano
Signed-off-by: Paul Tan
---
t/t4150-am.sh | 42 +
Since 6d28644 (git-am: do not allow empty commits by mistake.,
2006-02-23), git-am --resolved will check to see if the index has any
changes to prevent the user from creating an empty commit by mistake.
Add a test for this.
Cc: Junio C Hamano
Signed-off-by: Paul Tan
---
t/t4150-am.sh | 12
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am
will invoke the applypatch-msg hooks just after extracting the patch
message. If the applypatch-msg hook exits with a non-zero status, git-am
abort before even applying the patch to the index.
Add tests for this hook.
Cc: Juni
Since c1d1128 (git-am --resolved: more usable error message.,
2006-04-28), git-am --resolved will check to see if there are any
unmerged entries, and will error out with a user-friendly error message
if there are.
Add a test for this.
Cc: Junio C Hamano
Signed-off-by: Paul Tan
---
t/t4150-am.s
Since c95b138 (Fix git-am safety checks, 2006-09-15), when there is a
session in progress, git-am will check the command-line arguments and
standard input to ensure that the user does not pass it any patches.
Add a test for this.
Cc: Junio C Hamano
Signed-off-by: Paul Tan
---
t/t4150-am.sh | 1
Since a078f73 (git-am: add --message-id/--no-message-id, 2014-11-25),
the am.messageid setting determines whether the --message-id option is
set by default.
Add a test for this.
Cc: Paolo Bonzini
Signed-off-by: Paul Tan
---
t/t4150-am.sh | 11 +++
1 file changed, 11 insertions(+)
diff
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07),
git-am.sg will invoke the pre-applypatch hook after applying the patch
to the index, but before a commit is made. Should the hook exit with a
non-zero status, git am will exit.
Add tests for this hook.
Cc: Junio C Hamano
Signed-off-
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am
will ensure that the index is clean before applying the patch. This is
to prevent changes unrelated to the patch from being committed.
Add a test for this check.
Cc: Junio C Hamano
Signed-off-by: Paul Tan
---
t/t4150-am.sh
Since 7b3b7e3 (am --abort: keep unrelated commits since the last failure
and warn, 2010-12-21), git-am --abort will not touch the index if on the
previous invocation, git-am failed because the index is dirty. This is
to ensure that the user's modifications to the index are not discarded.
Add a tes
Increase test coverage of git-am.sh to help prevent regressions that could arise
from the rewrite of git-am.sh to C. This patch series, along with
pt/am-foreign, improved test coverage as measured by kcov from 56.5%[1] to
67.3%[2].
No tests for git-am's interactive mode, though, as test_terminal d
On Thu, Jul 2, 2015 at 10:42 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> 'tag -l' and 'branch -l' have two different ways of finding
>> out if a certain ref contains a commit. Implement both these
>> methods in ref-filter and give the caller of ref-filter API
>> the option to pick which
On Thu, Jul 2, 2015 at 10:38 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> --- a/parse-options.h
>> +++ b/parse-options.h
>> @@ -246,5 +246,12 @@ extern int parse_opt_noop_cb(const struct option *,
>> const char *, int);
>> OPT_COLOR_FLAG(0, "color", (var), (h))
>> #define OPT_COLU
On Thu, Jul 2, 2015 at 10:36 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> +/* Macros for checking --merged and --no-merged options */
>> +#define _OPT_MERGED_NO_MERGED(option, filter, h)
>> \
>
> Detail: there's a weird large space before \. Is it an attempt
Karthik Nayak writes:
> +/* Macros for checking --merged and --no-merged options */
> +#define _OPT_MERGED_NO_MERGED(option, filter, h)
> \
Detail: there's a weird large space before \. Is it an attempt to align
the \ with a non-standard tab-width?
--
Matthieu Moy
Karthik Nayak writes:
> 'tag -l' and 'branch -l' have two different ways of finding
> out if a certain ref contains a commit. Implement both these
> methods in ref-filter and give the caller of ref-filter API
> the option to pick which implementation to be used.
You are reusing some code, but un
Karthik Nayak writes:
> --- a/parse-options.h
> +++ b/parse-options.h
> @@ -246,5 +246,12 @@ extern int parse_opt_noop_cb(const struct option *,
> const char *, int);
> OPT_COLOR_FLAG(0, "color", (var), (h))
> #define OPT_COLUMN(s, l, v, h) \
> { OPTION_CALLBACK, (s), (l), (v), N_("
On Thu, Jul 2, 2015 at 8:50 AM, Duy Nguyen wrote:
> On Thu, Jul 2, 2015 at 7:41 PM, Duy Nguyen wrote:
>>> merge_working_tree:
>>> tree = parse_tree_indirect(old->commit &&
>>> !opts->new_worktree_mode ?
>>> old->commit->object.sha1 :
>>> EMPTY_TREE_SHA1_BIN);
>
Karthik Nayak writes:
> Add the '--points-at' option provided by 'ref-filter'. The
> option lets the user to list only refs which pertain to the
> given object.
You are using "pertain to" (here, in git-for-each-ref.txt and in the
docstring), while the common use it to talk about "point to" or "p
On Thu, Jul 2, 2015 at 8:41 AM, Duy Nguyen wrote:
> On Thu, Jul 2, 2015 at 9:52 AM, Eric Sunshine wrote:
>> The recursion protection is indeed no longer needed and gets removed
>> by the "worktree add" patch. However, there are still a few bits of
>> code which want to know that the checkout is h
'tag -l' and 'branch -l' have two different ways of finding
out if a certain ref contains a commit. Implement both these
methods in ref-filter and give the caller of ref-filter API
the option to pick which implementation to be used.
'branch -l' uses 'is_descendant_of()' from commit.c which is
left
In 'branch -l' we have '--merged' option which only lists refs (branches)
merged into the named commit and '--no-merged' option which only lists
refs (branches) not merged into the named commit. Implement these two
options in ref-filter.{c,h} so that other commands can benefit from this.
Based-on-
Rename parse_opt_with_commit() to parse_opt_commits() to show
that it can be used to obtain a list of commits and is not
constricted to usage of '--contains' option.
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
builtin/branch.c | 4 ++--
builtin/ta
Add the '--contains' option provided by 'ref-filter'. The '--contains'
option lists only refs which contain the mentioned commit (HEAD if no
commit is explicitly given).
Add documentation and tests for the same.
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Naya
Add the '--merged' and '--no-merged' options provided by 'ref-filter'.
The '--merged' option lets the user to only list refs merged into the
named commit. The '--no-merged' option lets the user to only list refs
not merged into the named commit.
Add documentation and tests for the same.
Based-on-
Rename 'parse_opt_points_at()' to 'parse_opt_object_name()' and
move it from 'tag.c' to 'parse-options'. This now acts as a common
parse_opt function which accepts an objectname and stores it into
a sha1_array.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Add 'parse_opt_merge_filter()' to parse '--merged' and '--no-merged'
options and write macros for the same.
This is copied from 'builtin/branch.c' which will eventually be removed
when we port 'branch.c' to use ref-filter APIs.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored
In 'tag -l' we have '--points-at' option which lets users
list only tags of a given object. Implement this option in
'ref-filter.{c,h}' so that other commands can benefit from this.
This is duplicated from tag.c, we will eventually remove that
when we port tag.c to use ref-filter APIs.
Based-on-p
Add a macro for using the '--contains' option in parse-options.h
also include an optional '--with' option macro which performs the
same action as '--contains'.
Make tag.c and branch.c use this new macro.
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
Add the '--points-at' option provided by 'ref-filter'. The
option lets the user to list only refs which pertain to the
given object.
Add documentation and tests for the same.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
v6 of this patch series can be found here :
http://article.gmane.org/gmane.comp.version-control.git/272641
This is a continuation of my GSoC project to unify git tag -l, git
branch -l and for-each-ref. Continued from this patch series :
http://thread.gmane.org/gmane.comp.version-control.git/271563
Add a test suite for testing the ref-filter APIs used
by for-each-ref. We just intialize the test suite for now.
More tests will be added in the following patches as more
options are added to for-each-ref.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Sign
The --force option was modified in 356e91f (branch: allow -f with -m and
-d, 2014-12-08), but the documentation was not updated.
Signed-off-by: Matthieu Moy
---
Documentation/git-branch.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/git-branch.txt b/Documentation/git-b
Now that we have proper documentation for --force's interaction with -d
and -m, we can avoid duplication and consider -M and -D as convenience
aliases for -m --force and -d --force.
Signed-off-by: Matthieu Moy
---
I'm not 100% sure it's a good idea (too many levels of indirections in
a documentat
Answers and new response below.
Thomas Vieten wrote:
On 2015-06-30 16.12, Thomas Vieten wrote:
We face a very inconvenient problem with end-of-line diffs which are
not "real".
We know the end-of-line problem very well as we thought.
But now we found a new phenomenon and nobody mentioning it.
On Wed, Jul 01, 2015 at 01:39:49PM -0700, Junio C Hamano wrote:
> There is a slight complication on sending an empty line without any
> termination, though ;-) The reader that calls packet_read() cannot
> tell such a payload from a flush packet, I think.
>
> *That* may be something we want to do
If filter-branch removes a commit which an annotated tag points to,
and that tag is in the list of refs to be rewritten, we die with an
error like this:
error: Ref refs/tags/a1t is at 699cce2774f79a0830d8c5f631deca12d4b1ee8c but
expected ba247450492030b03e3d2a9d5fef7ef67519483e
Could not
If filter-branch removes a commit which an annotated tag points to,
and that tag is in the list of refs to be rewritten, we die with an
error like this:
error: Ref refs/tags/a1t is at 699cce2774f79a0830d8c5f631deca12d4b1ee8c but
expected ba247450492030b03e3d2a9d5fef7ef67519483e
Could not
On Thu, Jul 2, 2015 at 7:41 PM, Duy Nguyen wrote:
>> merge_working_tree:
>> tree = parse_tree_indirect(old->commit &&
>> !opts->new_worktree_mode ?
>> old->commit->object.sha1 :
>> EMPTY_TREE_SHA1_BIN);
>
> I think it's to make sure empty sha-1 is used with --to
On Thu, Jul 2, 2015 at 9:52 AM, Eric Sunshine wrote:
> On Wed, Jul 1, 2015 at 9:07 PM, Duy Nguyen wrote:
>> On Thu, Jul 2, 2015 at 12:13 AM, Eric Sunshine
>> wrote:
I noticed GIT_CHECKOUT_NEW_WORKTREE environment variabl that does
not seem to be documented. Is this something we
Hello.
Command:
git log --graph --date-order --all
Tested in 2.0.0.rc2, 2.1.4 and latest
master(cbed29f37b690e0a497bd2b6ca9a5bdd7e6ea5aa Git 2.5.0-rc1)
Importance: some software that works with generated tree could crash.
(For example, https://github.com/bluef/gitgraph.js crashes)
When I execute t
Junio C Hamano writes:
> * ad/bisect-terms (2015-06-29) 10 commits
> - bisect: allow setting any user-specified in 'git bisect start'
> - bisect: add 'git bisect terms' to view the current terms
> - bisect: add the terms old/new
> - bisect: sanity check on terms
> - bisect: don't mix option
Since e481af06 (rebase: Handle cases where format-patch fails) we
notice if format-patch fails and return immediately from
git-rebase--am. We save the return value with ret=$?, but then we
return $?, which is usually zero in this case.
Fix this by returning $ret instead.
Cc: Andrew Wong
Signed-o
Lawrence Siebert writes:
> +prepare_revision_walk(rev);
There's trailing whitespace here.
(See my message in 3/4)
Rémi
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
Lawrence Siebert writes:
> +get_commit_count(&revs);
There's trailing whitespace here.
(See my message in 3/4)
Rémi
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel
Hi Lawrence,
Lawrence Siebert writes:
> +test_expect_success 'log --count' '
> +git log --count HEAD > actual &&
> +gitrev-list --count HEAD > expect &&
Why the huge space here between 'git' and 'rev-list'?
Also no space after the redirection ('>'), it should be '>actual'
Junio C Hamano writes:
> In any case, I wouldn't have much time during the remainder of the
> day to requeue and/or comment; please check what I push out on 'pu'.
BTW, I do agree with this hunk:
@@ -1068,18 +1064,20 @@ static void abbrev_sha1_in_line(struct strbuf *line)
static void read_rebas
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Actually, we can do simpler: we still have the original line available,
>> ...
>>
>> I took this (modulo s/line.len[0]/line.buf[0]/, and s/rtrim/trim/ to be
>> robust to leading whitespace (not really important, but doesn't harm).
>
> I'd prefer
63 matches
Mail list logo
