Re: [PATCH] git-subtree.sh: Use --allow-unrelated-histories when splitting with --rejoin

[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

[PATCH v10 08/12] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C

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

Re: [PATCH] submodule: do no re-read name in shell script

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

[PATCH] submodule--helper: correct index computation

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

[PATCH] git-subtree.sh: Use --allow-unrelated-histories when splitting with --rejoin

--- 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 @@

Re: [PATCH] config.mak.uname: set PERL_PATH for FreeBSD 5.0+

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

Re: [PATCH] submodule: do no re-read name in shell script

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|

[PATCH] contrib/persistent-https: use Git version for build label

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

[PATCH] contrib/persistent-https: update ldflags syntax for Go 1.7+

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

[PATCH] submodule: do no re-read name in shell script

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

Re: How to generate feature branch statistics?

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. > >

Re: [PATCH v4 3/4] submodule: support running in multiple worktree setup

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(-) > >

Re: How to generate feature branch statistics?

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

[PATCH v10 09/12] bisect--helper: `bisect_write` shell function in C

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,

[PATCH v10 07/12] bisect--helper: `bisect_reset` shell function in C

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

Re: [PATCH 2/3] difftool: avoid $GIT_DIR and $GIT_WORK_TREE

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

Re: [PATCH v4 0/8] Name for A..B ranges?

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

[PATCH v10 03/12] bisect--helper: `write_terms` shell function in C

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

Re: [PATCH v4] config: add conditional include

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

[PATCH v10 02/12] bisect: rewrite `check_term_format` shell function in C

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

Re: [PATCH v4 2/4] submodule: update core.worktree using git-config

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.

[PATCH v10 05/12] t6030: explicitly test for bisection cleanup

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

[PATCH v10 04/12] bisect--helper: `bisect_clean_state` shell function in C

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

Re: Complex gitweb URL

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

Re: [PATCH v1 5/6] Add porcelain V2 documentation to status manpage

Jeff Hostetler writes: > +A series of lines are then displayed for the tracked entries. > + > + R > [\t] > + > +Field Meaning > + > +The staged and unstaged values described

[PATCH v10 11/12] bisect--helper: `bisect_next_check` shell function in C

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,

[PATCH v10 10/12] bisect--helper: `check_and_set_terms` shell function in C

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

[PATCH v10 12/12] bisect--helper: `get_terms` & `bisect_terms` shell function in C

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

[PATCH v10 01/12] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

`--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

[PATCH v10 06/12] wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()

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

Re: Complex gitweb URL

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

Re: Complex gitweb URL

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

Re: [PATCH v1 3/6] Per-file output for Porcelain Status V2

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(); > } > > + > +/* Copy

Re: Complex gitweb URL

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

[PATCH v4 1/8] doc: use 'symmetric difference' consistently

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 ---

[PATCH v4 5/8] doc: gitrevisions - use 'reachable' in page description

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 +++

[PATCH v4 4/8] doc: give headings for the two and three dot notations

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

[PATCH v4 7/8] doc: revisions - define `reachable`

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

[PATCH v4 6/8] doc: gitrevisions - clarify 'latter case' is revision walk

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

[PATCH v4 8/8] doc: revisions - clarify reachability examples

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

[PATCH v4 3/8] doc: show the actual left, right, and boundary marks

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

[PATCH v4 2/8] doc: revisions - name the left and right sides

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

[PATCH v4 0/8] Name for A..B ranges?

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.

Re: Fast-forward able commit, otherwise fail

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

Re: [PATCH v1 0/6] Porcelain Status V2

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

Re: [PATCH v1 4/6] Expanded branch header for Porcelain Status V2

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)". >

Re: [ANNOUNCE] GitRev News edition 17

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". >> >>

Re: git-prompt.sh incompatible with non-basic global grep.patternType

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

Re: [PATCH v1 3/6] Per-file output for Porcelain Status V2

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

Re: [PATCH v1 1/6] Allow --porcelain[=] in status and commit commands

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

Re: [ANNOUNCE] GitRev News edition 17

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 : > >

Re: [ANNOUNCE] GitRev News edition 17

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: >> >>

Re: git-prompt.sh incompatible with non-basic global grep.patternType

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

Complex gitweb URL

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

Re: [PATCH v1 0/6] Porcelain Status V2

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

Re: Git and SHA-1 security (again)

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

Re: [PATCH] contrib/persistent-https: update ldflags syntax for Go 1.7+

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

Re: How to generate feature branch statistics?

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

Re: [PATCH v1 4/6] Expanded branch header for Porcelain Status V2

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

Re: How to generate feature branch statistics?

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

Re: [PATCH] config.mak.uname: set PERL_PATH for FreeBSD 5.0+

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.

Re: [PATCH] config.mak.uname: set PERL_PATH for FreeBSD 5.0+

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

Re: [ANNOUNCE] GitRev News edition 17

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".

Re: [PATCH v1 2/6] Status and checkout unit tests for --porcelain[=]

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 && +

Re: [PATCH v1 2/6] Status and checkout unit tests for --porcelain[=]

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

Re: [PATCH v1 1/6] Allow --porcelain[=] in status and commit commands

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) {

[PATCH v4 4/4] t2029: some really basic tests for submodules in multi worktree

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

[PATCH v4 2/4] submodule: update core.worktree using git-config

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

[PATCH v4 0/4] Split .git/config in multiple worktree setup

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 >

[PATCH v4 3/4] submodule: support running in multiple worktree setup

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

[PATCH v4 1/4] worktree: add per-worktree config files

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

Re: Git and SHA-1 security (again)

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

Re: [PATCH v4] config: add conditional include

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

Re: [PATCH v1 0/6] Porcelain Status V2

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

Re: [PATCH] worktree: add: introduce the --name option

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

Re: [PATCH v1 4/6] Expanded branch header for Porcelain Status V2

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? > + */ > +

Re: [PATCH v1 2/6] Status and checkout unit tests for --porcelain[=]

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 >

Re: [PATCH v1 6/6] Unit tests for V2 porcelain status

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 && >>> +

Re: [PATCH 0/9] Resend of gitster/pb/bisect

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

Re: [PATCH v1 2/6] Status and checkout unit tests for --porcelain[=]

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

Re: [PATCH v1 1/6] Allow --porcelain[=] in status and commit commands

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 =

Re: What's cooking in git.git (Jul 2016, #06; Tue, 19)

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:

Re: [PATCH v1 5/6] Add porcelain V2 documentation to status manpage

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

Re: [PATCH v1 2/6] Status and checkout unit tests for --porcelain[=]

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

Re: [PATCH v1 6/6] Unit tests for V2 porcelain status

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 && +

Re: [PATCH v1 5/6] Add porcelain V2 documentation to status manpage

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

Re: [PATCH v1 1/6] Allow --porcelain[=] in status and commit commands

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 =

Re: [PATCH v1 6/6] Unit tests for V2 porcelain status

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 && > +

Re: [PATCH v1 5/6] Add porcelain V2 documentation to status manpage

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. > + >

Re: [PATCH v1 2/6] Status and checkout unit tests for --porcelain[=]

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

Re: [PATCH v1 1/6] Allow --porcelain[=] in status and commit commands

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

Re: t7063 failure on FreeBSD 10.3 i386/amd64

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

Re: [PATCH] worktree: add: introduce the --name option

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: >> >>

Re: Git and SHA-1 security (again)

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

Re: Git and SHA-1 security (again)

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

Re: How to generate feature branch statistics?

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

Re: Looking for help to understand external filter driver code

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 >

Re: git-prompt.sh incompatible with non-basic global grep.patternType

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"

Re: [PATCH v2] fetch-pack: grow stateless RPC windows exponentially

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

Re: [PATCH v4] config: add conditional include

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 slightly more worried > about

  1   2   >