On 20 Jul 2016, at 13:32, Jeff King wrote:
> On Wed, Jul 20, 2016 at 10:20:33AM +0200, Lars Schneider wrote:
>
>>> * jk/push-scrub-url (2016-07-14) 1 commit
>>> (merged to 'next' on 2016-07-19 at 6ada3f1)
>>> + push: anonymize URL in status output
>>
>> t5541-http-push-smart.sh "push status ou
[cc'd Roberto for submitGit q's]
On Thu, Jul 21, 2016 at 12:56:51AM +, Brett Cundal wrote:
> ---
The message on the pull request[1] has a better justification
for this change, which would have been nice in the commit
message itself:
Git 2.9 added a check against merging unrelated
Reimplement `is_expected_rev` & `check_expected_revs` shell function in
C and add a `--check-expected-revs` subcommand to `git bisect--helper` to
call it from git-bisect.sh .
Using `--check-expected-revs` subcommand is a temporary measure to port
shell functions to C so as to use the existing test
On Wed, Jul 20, 2016 at 6:00 PM, Jonathan Nieder wrote:
>> - needs_cloning, ce->name);
>> + needs_cloning, sub->name, sub->path);
>
> Are there any restrictions on what characters a submodule name can
> contain? Does this need e.g. to be quoted with sq_quo
In 665b35eccd39 (2016-06-09, submodule--helper: initial clone learns
retry logic), the index computation for the second round is wrong; it
should make use of the index that was handed in via the idx_task_cb
pointer. When that commit was introduced, I wrote:
> I wonder how we can test this properly
---
contrib/subtree/git-subtree.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 7a39b30..556cd92 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -661,7 +661,7 @@ cmd_spl
On Wed, Jul 20, 2016 at 11:10:40AM -0700, Junio C Hamano wrote:
> On Wed, Jul 20, 2016 at 11:07 AM, Eric Wong wrote:
> > Also, my use of a numeric comparison may be more future-proof
> > in case FreeBSD decides to have /usr/bin/perl again.
> >
> > I also wonder why we don't use `which` to search f
Stefan Beller wrote:
> Instead of making another call to a submodule helper (name), just
> propagate the value when we know it (in the update-clone helper) already.
>
> Signed-off-by: Stefan Beller
> ---
> builtin/submodule--helper.c | 4 ++--
> git-submodule.sh| 3 +--
> 2 files cha
From: Parker Moore
The previous method simply used the UNIX timestamp of when the binary was
built as its build label.
$ make && ./git-remote-persistent-http -print_label
1469061546
This patch aims to align the label for this binary with the Git version
contained in the GIT-VERSION-FILE
From: Parker Moore
This fixes contrib/persistent-https builds for Go v1.7+ and is
compatible with Go v1.0+.
Running `make all` in `contrib/persistent-https` results in a failure
on Go 1.7 and above.
Specifically, the error is:
go build -o git-remote-persistent-https \
-ldflags "-X main.
Instead of making another call to a submodule helper (name), just
propagate the value when we know it (in the update-clone helper) already.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 4 ++--
git-submodule.sh| 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
On Wed, Jul 20, 2016 at 4:10 PM, Jakub Narębski wrote:
> W dniu 2016-07-20 o 20:49, Junio C Hamano pisze:
>
>> For our own history and workflow, the duration between the inception
>> of a topic branch and the time it gets merged to 'master' is not all
>> that interesting.
>
> Nb. if I haven't mess
On Wed, Jul 20, 2016 at 10:24 AM, Nguyễn Thái Ngọc Duy
wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/git-worktree.txt | 8
> git-submodule.sh | 8
> 2 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-worktree.
W dniu 2016-07-20 o 20:49, Junio C Hamano pisze:
> For our own history and workflow, the duration between the inception
> of a topic branch and the time it gets merged to 'master' is not all
> that interesting.
Nb. if I haven't messed something up (the git history is not simple
merging of topic b
Reimplement the `bisect_write` shell function in C and add a
`bisect-write` subcommand to `git bisect--helper` to call it from
git-bisect.sh
Using `--bisect-write` subcommand is a temporary measure to port shell
function in C so as to use the existing test suite. As more functions
are ported, this
Reimplement `bisect_reset` shell function in C and add a `--bisect-reset`
subcommand to `git bisect--helper` to call it from git-bisect.sh .
Using `bisect_reset` subcommand is a temporary measure to port shell
functions to C so as to use the existing test suite. As more functions
are ported, this
On Tue, Jul 19, 2016 at 02:06:35PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > It is not wrong per-se, but as you are in a subshell, you do not
> > have to unset these, I would think. Not worth a reroll, but unless
> > I am overlooking something (in which case please holler) I'm
Philip Oakley writes:
> No change in the number of patches. Interdiff below.
>
> The patches carefully tease out the clarification of
> reachability. Reachability is defined relative the ancestry chain thus
> (hopefully) avoiding misunderstandings.
>
> The final patch updates the summary examples
Reimplement the `write_terms` shell function in C and add a `write-terms`
subcommand to `git bisect--helper` to call it from git-bisect.sh . Also
remove the subcommand `--check-term-format` as it can now be called from
inside the function write_terms() C implementation.
Also `|| exit` is added whe
Jeff King writes:
> On Sun, Jul 17, 2016 at 10:15:55AM +0200, Johannes Schindelin wrote:
>
>> FWIW I am slightly less worried about the conditional includes (it is
>> already a horrible mess to figure out too-long include chains now, before
>> having conditional includes, for example). I am sligh
Reimplement the `check_term_format` shell function in C and add
a `--check-term-format` subcommand to `git bisect--helper` to call it
from git-bisect.sh
Using `--check-term-format` subcommand is a temporary measure to port
shell function to C so as to use the existing test suite. As more
functions
On Wed, Jul 20, 2016 at 10:24 AM, Nguyễn Thái Ngọc Duy
wrote:
> To access a separate repository, the first step should be read its
> config file to determine if this repository layout is supported or
> not, or if we understand all repo extensions, of it is a linked
> worktree. Only then should kno
Add test to explicitly check that 'git bisect reset' is working as
expected. This is already covered implicitly by the test suite.
Mentored-by: Lars Schneider
Mentored-by: Christian Couder
Signed-off-by: Pranit Bauva
---
I faced this problem while converting `bisect_clean_state` and the tests
Reimplement `bisect_clean_state` shell function in C and add a
`bisect-clean-state` subcommand to `git bisect--helper` to call it from
git-bisect.sh .
Using `--bisect-clean-state` subcommand is a measure to port shell
function to C so as to use the existing test suite. As more functions
are ported
On 20 July 2016 at 23:35, CLOSE Dave wrote:
> Thanks, Jakub, for the quick response.
>
> On 07/20/16 02:20 PM, Jakub Narębski wrote:
>
>>> If I replace the hb=SHA argument with hb=HEAD, the URL still works. But
>>> I have no idea what I can use to replace the h=SHA argument.
>>
>> You can remove i
Jeff Hostetler writes:
> +A series of lines are then displayed for the tracked entries.
> +
> + R
> [\t]
> +
> +Field Meaning
> +
> +The staged and unstaged values described earlier, with
> +
Reimplement `bisect_next_check` shell function in C and add
`bisect-next-check` subcommand to `git bisect--helper` to call it from
git-bisect.sh .
Using `--bisect-next-check` is a temporary measure to port shell
function to C so as to use the existing test suite. As more functions
are ported, this
Reimplement the `check_and_set_terms` shell function in C and add
`check-and-set-terms` subcommand to `git bisect--helper` to call it from
git-bisect.sh
Using `--check-and-set-terms` subcommand is a temporary measure to port
shell function in C so as to use the existing test suite. As more
functio
Reimplement the `get_terms` and `bisect_terms` shell function in C and
add `bisect-terms` subcommand to `git bisect--helper` to call it from
git-bisect.sh .
In the shell version, the terms were identified by strings but in C
version its done by bit manipulation and passing the integer value to
the
`--next-all` is meant to be used as a subcommand to support multiple
"operation mode" though the current implementation does not contain any
other subcommand along side with `--next-all` but further commits will
include some more subcommands.
Helped-by: Johannes Schindelin
Mentored-by: Lars Schne
is_empty_file() can help to refactor a lot of code. This will be very
helpful in porting "git bisect" to C.
Suggested-by: Torsten Bögershausen
Mentored-by: Lars Schneider
Mentored-by: Christian Couder
Signed-off-by: Pranit Bauva
---
builtin/am.c | 20 ++--
cache.h | 3 ++
On 07/20/16 02:20 PM, Jakub Narębski wrote:
> See e.g. http://repo.or.cz/?p=git/zerocommit.git;a=tree;hb=master;f=t
Ah! You have the branch in the hb= parameter whereas I had HEAD in that
one. Since HEAD is the default, I suppose I don't really need it.
Indeed, if I use a URL like
"http://site
Thanks, Jakub, for the quick response.
On 07/20/16 02:20 PM, Jakub Narębski wrote:
>> If I replace the hb=SHA argument with hb=HEAD, the URL still works. But
>> I have no idea what I can use to replace the h=SHA argument.
>
> You can remove it. 'hb' (hash_base) and 'f' (filename) identify target
Jeff Hostetler writes:
> diff --git a/wt-status.c b/wt-status.c
> index c19b52c..2d4829e 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -406,6 +406,89 @@ static void wt_status_print_change_data(struct wt_status
> *s,
> strbuf_release(&twobuf);
> }
>
> +
> +/* Copy info for both sid
W dniu 2016-07-20 o 21:24, CLOSE Dave pisze:
> I'm trying to create a URL that will always refer to the latest version
> of a file stored under Gerrit. gitweb access is available. The man page
> specification doesn't seem to work for me. Instead, I seem to need to
> put most of the information i
Signed-off-by: Philip Oakley
---
Documentation/gitk.txt | 2 +-
Documentation/rev-list-options.txt | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 6ade002..6c3eb15 100644
--- a/Documentation/gitk.txt
+++ b/
Signed-off-by: Philip Oakley
---
Documentation/gitrevisions.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitrevisions.txt b/Documentation/gitrevisions.txt
index e903eb7..33039c6 100644
--- a/Documentation/gitrevisions.txt
+++ b/Documentation/gitrevisio
While there, also break out the other shorthand notations and
add a title for the revision range summary (which also appears
in git-rev-parse, so keep it mixed case).
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 58 -
1 file changed,
Do not self-define `reachable`, which can lead to misunderstanding.
Instead define `reachability` explictly.
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/revisions.txt b/Documentatio
The prior sentence has too many clauses for easy parsing.
Replace 'the latter case' with a direct quote.
Signed-off-by: Philip Oakley
---
Documentation/gitrevisions.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitrevisions.txt b/Documentation/gitrevis
For the r1..r2 case, the exclusion of r1, rather than inclusion of r2,
would be the unexpected case in natural language for a simple linear
development, i.e. start..end excludes start.
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 11 ++-
1 file changed, 6 insertions(
Signed-off-by: Philip Oakley
---
Found while checking the 'symmetric difference' documentation
---
Documentation/pretty-formats.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 29b19b9..10719e1 100644
The terms left and right side originate from the symmetric
difference. Name them there.
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 19314e3..6e9cd4
This is the V4 re-roll of the po/range-doc (2016-07-01) 3 commits and its
follow on patch.
Capitalisation has been fixed.
Heading levels for man pages has been fixed.
Quoting of the caret has been fixed.
The extra width wise 'caret' shorthands now mention their applicability to
merge commits.
No
From: "Stefan Haller"
Junio C Hamano wrote:
Another thing to consider is that the proposed workflow would not
scale if your team becomes larger. Requiring each and every commit
on the trunk to be a merge commit, whose second parent (i.e. the tip
of the feature branch) fast-forwards to the fi
On Wed, Jul 20, 2016 at 03:27:45PM -0400, Jeff Hostetler wrote:
> > A totally reasonable response is "haha no. Please stop moving the
> > goalposts". I just wanted to throw it out there as an option (and in
> > case you are interested, to let you think about it before any more work
> > goes into t
On Wed, Jul 20, 2016 at 02:20:24PM -0400, Jeff Hostetler wrote:
> > IIRC, it happens when HEAD points to a broken ref. So something like:
> >
> >git init
> >echo broken >.git/refs/heads/master
> >
> > would cause resolving HEAD to return NULL.
>
> That worked and I see "(unknown)".
>
>
On Wed, Jul 20, 2016 at 10:40 PM, Junio C Hamano wrote:
> On Wed, Jul 20, 2016 at 1:38 PM, Christian Couder
> wrote:
>>> Micronit. 2.9.1 (or 2.9.2) would not be a "major release". 2.9.0 was,
>>> and x.y.z (z > 0) are "maintenance releases".
>>
>> Yeah, I wondered about that when I saw :
>>
>> htt
On Wed, Jul 20, 2016 at 01:10:42PM -0700, Junio C Hamano wrote:
> This may fix it. I think the root cause is that logic to smear
> "pattern type" into various broken-down fields in grep_opt for the
> short-hands like --basic-regexp option needs to leave "I am setting
> this short-hand" mark to al
Jeff Hostetler writes:
Just to avoid later headaches... please look at your commit titles
and imagine how they will look when listed among 400+ other changes
when they are included in a future release in "git shortlog" output.
> Subject: Re: [PATCH v1 3/6] Per-file output for Porcelain Status V
Jeff Hostetler writes:
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index b0a294d..0791573 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -104,7 +104,7 @@ OPTIONS
> --branch::
> Show the branch and tracking info even in
On Wed, Jul 20, 2016 at 1:38 PM, Christian Couder
wrote:
>> Micronit. 2.9.1 (or 2.9.2) would not be a "major release". 2.9.0 was,
>> and x.y.z (z > 0) are "maintenance releases".
>
> Yeah, I wondered about that when I saw :
>
> https://github.com/git/git.github.io/commit/d2eb8fbbb30594d19fcda731c3
On Wed, Jul 20, 2016 at 8:05 PM, Junio C Hamano wrote:
> On Wed, Jul 20, 2016 at 5:58 AM, Christian Couder
> wrote:
>> Hi everyone,
>>
>> I'm happy announce that the 17th edition of Git Rev News is now published:
>>
>> https://git.github.io/rev_news/2016/07/20/edition-17/
>
> Micronit. 2.9.1 (or
Jeff King writes:
> On Mon, Jul 18, 2016 at 03:56:09PM -0700, Richard Soderberg wrote:
>
>> ps. git log --basic-regexp does not fix the issue, as for unknown
>> reasons (I'll start another thread) the command-line option doesn't
>> override grep.patternType.
>
> Dscho gave a fix for your immediat
I'm trying to create a URL that will always refer to the latest version
of a file stored under Gerrit. gitweb access is available. The man page
specification doesn't seem to work for me. Instead, I seem to need to
put most of the information into arguments (after the '?').
For example, the repo
On 07/20/2016 12:15 PM, Jeff King wrote:
One final bit of food for thought.
Just yesterday somebody asked me about renewing the old idea of using a
more standardized format for machine-readable output, like --json.
That's obviously something that would exist alongside the existing
formats for
Stefan Beller writes:
>> to follow the above, in my view, interaction with sha1 repos go
>> through some conversion bridges like what we have with hg and svn. I
>> don't know if we are going this route. It's certainly simpler and
>> people already have experiences (from previous migration) to pre
Parker Moore writes:
>> the logical place to pull that information from would be
>> ../../GIT-VERSION-FILE,
>
> I agree. It would make more sense to build this to a specific version
> or git revision rather
> than a time. Perhaps that would be a different patch?
It would definitely be a separat
Jeff King writes:
> In a workflow that merges feature branches to master, you can generally
> recognize them by looking for merges along the first-parent chain of
> commits:
>
> git log --first-parent --merges master
>
> (Depending on your workflow, some feature branches may be fast-forwards
>
On 07/20/2016 12:06 PM, Jeff King wrote:
On Tue, Jul 19, 2016 at 06:10:56PM -0400, Jeff Hostetler wrote:
+ } else {
+ /*
+* TODO All of various print routines allow for s->branch to be
null.
+* TODO When can this happen and what should we r
W dniu 2016-07-20 o 15:56, Jakub Narębski pisze:
> W dniu 2016-07-20 o 10:05, Ernesto Maserati pisze:
>
>> I assume that feature branches are not frequently enough merged into
>> master. Because of that we discover bugs later than we could with a more
>> continuous code integration. I don't want t
On Wed, Jul 20, 2016 at 11:07 AM, Eric Wong wrote:
> Also, my use of a numeric comparison may be more future-proof
> in case FreeBSD decides to have /usr/bin/perl again.
>
> I also wonder why we don't use `which` to search for somewhat
> standard path components, instead. Something like:
Because
Johannes Schindelin wrote:
> Hi Eric,
>
> On Wed, 20 Jul 2016, Eric Wong wrote:
>
> > diff --git a/config.mak.uname b/config.mak.uname
> > index a88f139..6c29545 100644
> > --- a/config.mak.uname
> > +++ b/config.mak.uname
> > @@ -202,6 +202,11 @@ ifeq ($(uname_S),FreeBSD)
> > NO_UIN
On Wed, Jul 20, 2016 at 5:58 AM, Christian Couder
wrote:
> Hi everyone,
>
> I'm happy announce that the 17th edition of Git Rev News is now published:
>
> https://git.github.io/rev_news/2016/07/20/edition-17/
Micronit. 2.9.1 (or 2.9.2) would not be a "major release". 2.9.0 was,
and x.y.z (z > 0)
On 07/20/2016 12:03 PM, Jeff King wrote:
On Wed, Jul 20, 2016 at 10:00:07AM -0600, Jeff King wrote:
On Tue, Jul 19, 2016 at 06:10:54PM -0400, Jeff Hostetler wrote:
+test_expect_failure '--porcelain=bogus with stuff to commit returns ok' '
+ echo bongo bongo bongo >>file &&
+ git
On 07/20/2016 12:00 PM, Jeff King wrote:
On Tue, Jul 19, 2016 at 06:10:54PM -0400, Jeff Hostetler wrote:
+test_expect_failure '--porcelain=bogus with stuff to commit returns ok' '
+ echo bongo bongo bongo >>file &&
+ git commit -m next -a --porcelain=bogus
+'
Hrm. That seems une
On 07/20/2016 11:58 AM, Jeff King wrote:
On Tue, Jul 19, 2016 at 06:10:53PM -0400, Jeff Hostetler wrote:
+static int opt_parse_porcelain(const struct option *opt, const char *arg, int
unset)
+{
+ enum wt_status_format *value = (enum wt_status_format *)opt->value;
+ if (unset) {
+
Signed-off-by: Nguyễn Thái Ngọc Duy
---
t/t2029-worktree-submodule.sh (new +x) | 166 +
1 file changed, 166 insertions(+)
create mode 100755 t/t2029-worktree-submodule.sh
diff --git a/t/t2029-worktree-submodule.sh b/t/t2029-worktree-submodule.sh
new file mode 100
To access a separate repository, the first step should be read its
config file to determine if this repository layout is supported or
not, or if we understand all repo extensions, of it is a linked
worktree. Only then should know where to update the config file.
Unfortunately, our C code base is n
On Wed, Jul 20, 2016 at 6:14 AM, Duy Nguyen wrote:
>> If yes, do you know if someone is working on this? If nobody is working on
>> this, do
>> you have some pointers for me what the main problems are?
>
> The blocker is config file being shared (you do not want to share
> core.worktree and submo
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-worktree.txt | 8
git-submodule.sh | 8
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 41350db..2a5661d 100644
--- a/Doc
A new repo extension is added, worktreeConfig. When it is present:
- Repository config reading by default includes $GIT_DIR/config _and_
$GIT_DIR/config.worktree. "config" file remains shared in multiple
worktree setup.
- The special treatment for core.bare and core.worktree, to stay
e
On Wed, Jul 20, 2016 at 7:44 AM, Duy Nguyen wrote:
> On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin
> wrote:
>> But that strategy *still* ignores the distributed nature of Git. Just
>> because *you* make that merge at a certain point does not necessarily mean
>> that I make it at that point
W dniu 2016-07-16 o 18:47, Jeff King pisze:
> Heh. Don't get me wrong, I do think there's room for digging ourselves a
> deep hole with conditional includes, because anything dynamic opens up a
> question of _when_ it is evaluated, and in what context. So any
> condition should be something that w
On Tue, Jul 19, 2016 at 06:10:52PM -0400, Jeff Hostetler wrote:
> This patch series adds porcelain V2 format to status.
> This provides detailed information about file changes
> and about the current branch.
>
> The new output is accessed via:
> git status --porcelain=2 [--branch]
>
> An ear
On Wed, Jul 20, 2016 at 04:54:40PM +0200, Duy Nguyen wrote:
> On Tue, Jul 19, 2016 at 9:35 PM, Antoine Tenart wrote:
> >
> > Hmm, so if I understand correctly my use case still won't be supported,
> > as adding a new worktree with the same basename will fail. Or did I miss
> > something?
>
> Hm..
On Tue, Jul 19, 2016 at 06:10:56PM -0400, Jeff Hostetler wrote:
> + } else {
> + /*
> + * TODO All of various print routines allow for s->branch to be
> null.
> + * TODO When can this happen and what should we report here?
> + */
> +
On Wed, Jul 20, 2016 at 10:00:07AM -0600, Jeff King wrote:
> On Tue, Jul 19, 2016 at 06:10:54PM -0400, Jeff Hostetler wrote:
>
> > +test_expect_failure '--porcelain=bogus with stuff to commit returns ok' '
> > + echo bongo bongo bongo >>file &&
> > + git commit -m next -a --porcelain=bogus
>
On 20 July 2016 at 17:47, Jeff Hostetler wrote:
> On 07/20/2016 11:30 AM, Jakub Narębski wrote:
>> W dniu 2016-07-20 o 00:10, Jeff Hostetler pisze:
>>>
>>> +test_expect_success pre_initial_commit_0 '
>>> + printf "## branch: (initial) master\n" >expected &&
>>> + printf "?? actual\n" >
On Wed, Jul 13, 2016 at 4:05 AM, Pranit Bauva wrote:
> Hey Junio,
>
> A small mistake got unnoticed by me which Lars recently pointed out.
> The naming convention is "git_path_" and underscore
> instead of spaces.
>
> Thanks!
>
> The interdiff is:
> diff --git a/builtin/bisect--helper.c b/builtin/
On Tue, Jul 19, 2016 at 06:10:54PM -0400, Jeff Hostetler wrote:
> +test_expect_failure '--porcelain=bogus with stuff to commit returns ok' '
> + echo bongo bongo bongo >>file &&
> + git commit -m next -a --porcelain=bogus
> +'
Hrm. That seems unexpected to me. Shouldn't it complain about
On Tue, Jul 19, 2016 at 06:10:53PM -0400, Jeff Hostetler wrote:
> +static int opt_parse_porcelain(const struct option *opt, const char *arg,
> int unset)
> +{
> + enum wt_status_format *value = (enum wt_status_format *)opt->value;
> + if (unset) {
> + *value = STATUS_FORMAT_UN
Hey Junio,
On Wed, Jul 20, 2016 at 4:24 AM, Junio C Hamano wrote:
> * pb/bisect (2016-07-12) 9 commits
> - bisect--helper: `bisect_write` shell function in C
> - bisect--helper: `is_expected_rev` & `check_expected_revs` shell function
> in C
> - bisect--helper: `bisect_reset` shell function
On 20 July 2016 at 17:42, Jeff Hostetler wrote:
> On 07/20/2016 11:29 AM, Jakub Narębski wrote:
>> W dniu 2016-07-20 o 00:10, Jeff Hostetler pisze:
>>
>>> +Porcelain Format Version 2
>>> +~~
>>> +
>>> +
>>> +If `--branch` is given, a header line showing branch tracking
>>>
On 07/20/2016 11:19 AM, Johannes Schindelin wrote:
Hi Jeff,
On Tue, 19 Jul 2016, Jeff Hostetler wrote:
Simple unit tests to validate the argument parsing.
Signed-off-by: Jeff Hostetler
They are simple alright, but do we really need so many of them? I would
like to keep the ones in t7060,
On 07/20/2016 11:30 AM, Jakub Narębski wrote:
W dniu 2016-07-20 o 00:10, Jeff Hostetler pisze:
+test_expect_success pre_initial_commit_0 '
+ printf "## branch: (initial) master\n" >expected &&
+ printf "?? actual\n" >>expected &&
+ printf "?? dir1/\n" >>expected &&
+ pr
On 07/20/2016 11:29 AM, Jakub Narębski wrote:
W dniu 2016-07-20 o 00:10, Jeff Hostetler pisze:
+Porcelain Format Version 2
+~~
+
+
+If `--branch` is given, a header line showing branch tracking information
+is printed. This line begins with "### branch: ". Fields are
On 07/20/2016 11:08 AM, Johannes Schindelin wrote:
On Tue, 19 Jul 2016, Jeff Hostetler wrote:
diff --git a/builtin/commit.c b/builtin/commit.c
+ } else if (arg) {
+ int n = strtol(arg, NULL, 10);
+ if (n == 1)
+ *value = STATUS_FORMAT_POR
W dniu 2016-07-20 o 00:10, Jeff Hostetler pisze:
> +test_expect_success pre_initial_commit_0 '
> + printf "## branch: (initial) master\n" >expected &&
> + printf "?? actual\n" >>expected &&
> + printf "?? dir1/\n" >>expected &&
> + printf "?? expected\n" >>expected &&
> + printf
W dniu 2016-07-20 o 00:10, Jeff Hostetler pisze:
> +Porcelain Format Version 2
> +~~
> +
> +
> +If `--branch` is given, a header line showing branch tracking information
> +is printed. This line begins with "### branch: ". Fields are separated
> +by a single space.
> +
>
Hi Jeff,
On Tue, 19 Jul 2016, Jeff Hostetler wrote:
> Simple unit tests to validate the argument parsing.
>
> Signed-off-by: Jeff Hostetler
They are simple alright, but do we really need so many of them? I would
like to keep the ones in t7060, but I do not think that we necessarily
have to add
Hi Jeff,
On Tue, 19 Jul 2016, Jeff Hostetler wrote:
> Update the --porcelain argument to take an optional
> version number. This will allow us to define new
> porcelain formats in the future.
>
> This default to 1 and represents the existing porcelain
> format.
>
> Signed-off-by: Jeff Hostetle
On Wed, Jul 20, 2016 at 5:02 AM, Eric Wong wrote:
> Duy Nguyen wrote:
>> On Tue, Jul 19, 2016 at 12:54 AM, Eric Wong wrote:
>> > Oops, forgot to Cc some folks who worked on this :x
>> >
>> > Filesystem is ufs and it fails regardless of whether
>> > soft-updates is enabled or not.
>>
>> Nothing s
On Tue, Jul 19, 2016 at 9:35 PM, Antoine Tenart wrote:
> On Tue, Jul 19, 2016 at 09:04:11PM +0200, Duy Nguyen wrote:
>> On Tue, Jul 19, 2016 at 8:54 PM, Antoine Tenart
>> wrote:
>> > On Tue, Jul 19, 2016 at 08:23:58PM +0200, Duy Nguyen wrote:
>> >> On Tue, Jul 19, 2016 at 8:04 PM, Junio C Hamano
On Tue, Jul 19, 2016 at 8:58 PM, Herczeg Zsolt wrote:
> 2016-07-19 20:04 GMT+02:00 Duy Nguyen :
>> On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote:
>>> On Tue, 19 Jul 2016, Duy Nguyen wrote:
>>>
On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote:
>
> On Tue, 19 Jul 2016, Duy Nguyen
On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin
wrote:
> But that strategy *still* ignores the distributed nature of Git. Just
> because *you* make that merge at a certain point does not necessarily mean
> that I make it at that point, too.
>
> Any approach that tries to have one single point
W dniu 2016-07-20 o 10:05, Ernesto Maserati pisze:
> I assume that feature branches are not frequently enough merged into
> master. Because of that we discover bugs later than we could with a more
> continuous code integration. I don't want to discuss here whether feature
> branches are good or ba
On Tue, Jul 19, 2016 at 02:33:09PM -0700, Junio C Hamano wrote:
> > Git writes --> 4 byte content length
> > Git writes --> content string
> > Git reads <-- 4 byte filtered content length
> > Git reads <-- filtered content
>
> Do you really need to force the sender to know the length in
> advance
On Mon, Jul 18, 2016 at 03:56:09PM -0700, Richard Soderberg wrote:
> ps. git log --basic-regexp does not fix the issue, as for unknown
> reasons (I'll start another thread) the command-line option doesn't
> override grep.patternType.
Dscho gave a fix for your immediate issue, but this "ps" defini
On Tue, Jul 19, 2016 at 12:53:47PM -0700, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
> > Even if it is conservative, I wonder if it is truly a good idea to
> > make it exponentially grow forever from that point of view. Would
> > it give essentially the same result to you if we discard the
1 - 100 of 117 matches
Mail list logo
