On Sun, Jun 19, 2016 at 03:52:04PM -0700, Junio C Hamano wrote:
> Here are the list of topics that are in the "private edition" I use
> for every day work, grouped by where they sit in the the near-term
> plan of merging them up to 'next' and then to 'master'.
By the way, I wondered if you had th
On Wed, Jun 22, 2016 at 08:25:59AM +0100, Philip Oakley wrote:
> Is there a common name for the A..B range format (two dots) that would
> complement the A...B (three dots) symmetric range format's name?
>
> I was looking at the --left-right distinctions and noticed that the trail
> back to the sy
On Fri, Jun 24, 2016 at 06:38:55PM +0200, Johannes Sixt wrote:
> Am 24.06.2016 um 01:20 schrieb Jeff King:
> > +# We expect git to die with SIGPIPE here (otherwise we
> > +# would generate the whole 64GB).
> > +test_expect_failure BUNZIP 'g
On Thu, Jun 02, 2016 at 01:11:56PM +0200, Michael Haggerty wrote:
> On 06/01/2016 11:07 PM, Jeff King wrote:
> > On Wed, Jun 01, 2016 at 03:42:18AM -0400, Jeff King wrote:
> >
> >> I have no idea if those ideas would work. But I wouldn't want to start
> >&g
On Fri, Jun 24, 2016 at 09:54:21AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... It's
> > not a flag day for either, of course; we'll build in all of the usual
> > backwards-compatibility flags. But it's convenient for users to remember
>
On Fri, Jun 24, 2016 at 07:45:04PM +0200, Johannes Schindelin wrote:
> > $ git grep -A2 IMPORTANT color.h
> > color.h: * IMPORTANT: Due to the way these color codes are emulated on
> > Windows,
> > color.h- * write them only using printf(), fprintf(), and fputs(). In
> > particular,
> >
On Fri, Jun 24, 2016 at 11:56:19AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The ustar format only has room for 11 (or 12, depending on
> > some implementations) octal digits for the size and mtime of
> > each file. After this, we have to add pax extended he
On Fri, Jun 24, 2016 at 12:01:16PM -0700, Junio C Hamano wrote:
> > @@ -267,7 +281,13 @@ static int write_tar_entry(struct archiver_args *args,
> > memcpy(header.linkname, buffer, size);
> > }
> >
> > - prepare_header(args, &header, mode, size);
> > + size_in_header =
On Fri, Jun 24, 2016 at 12:06:59PM -0700, Junio C Hamano wrote:
> > + if (args->time > 0777UL) {
> > + strbuf_append_ext_header_uint(&ext_header, "mtime",
> > + args->time);
> > + args->time = 0777UL;
> > + }
> > +
> >
On Fri, Jun 24, 2016 at 07:05:14PM +0200, Johannes Sixt wrote:
> Am 24.06.2016 um 18:46 schrieb Jeff King:
> > On Fri, Jun 24, 2016 at 06:38:55PM +0200, Johannes Sixt wrote:
> > > It's going to be 269 with ksh, and who-knows-what on Windows (due to lack
> > > of
eave it as generic as
possible.
Signed-off-by: Jeff King
---
I didn't get into the weirdness of SIGPIPE on Windows here, but I think
this is probably a first step toward handling it better. E.g., it may be
that test_match_signal should respect 128 (or even any code) when we are
checking for SIGPIPE.
The first test already uses this more portable construct
(that was where it was factored from initially), but the
later tests do a raw comparison against 141 to look for
SIGPIPE, which can fail on some shells and platforms.
Signed-off-by: Jeff King
---
Again, I couldn't test these. Th
hecking.
Signed-off-by: Jeff King
---
t/test-lib-functions.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 51d3775..91d3b58 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -612,7 +612
x this by using test_match_signal.
Signed-off-by: Jeff King
---
t/lib-git-daemon.sh | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh
index 340534c..f9cbd47 100644
--- a/t/lib-git-daemon.sh
+++ b/t/lib-git-daemon.sh
@@ -82,8 +82,7 @@
On Fri, Jun 24, 2016 at 12:45:05PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So if anything, I would put a comment here, explaining that ustar cannot
> > handle anything larger than this, and POSIX mandates it (but I didn't
> > because the commit messag
On Fri, Jun 24, 2016 at 03:39:24PM -0400, Jeff King wrote:
> Anyway. Here's a series that I think makes things better, and it is not
> too painful to do.
>
> [1/4]: tests: factor portable signal check out of t0005
> [2/4]: t0005: use test_match_signal as appropriate
>
On Fri, Jun 24, 2016 at 03:07:44PM -0400, Jeff King wrote:
> > "dd bs=1 count=4096" is hopefully more portable.
>
> Hmm. I always wonder whether dd is actually very portable, but we do use
> it already, at least.
>
> Perhaps the perl monstrosity in t9300 could b
On Fri, Jun 24, 2016 at 10:52:32PM +0200, Johannes Sixt wrote:
> Am 24.06.2016 um 21:43 schrieb Jeff King:
> > In POSIX shells, a program which exits due to a signal
> > generally has an exit code of 128 plus the signal number.
> > However, some platforms do other thin
On Fri, Jun 24, 2016 at 04:58:58PM -0400, Eric Sunshine wrote:
> On Fri, Jun 24, 2016 at 3:07 PM, Jeff King wrote:
> > On Fri, Jun 24, 2016 at 11:56:19AM -0700, Junio C Hamano wrote:
> >> Jeff King writes:
> >> > +tar_info () {
> >> > + "$TAR&qu
On Fri, Jun 24, 2016 at 03:41:47PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The difference in time between the two is measurable on my system, but
> > it's only a few milliseconds (for 4096 bytes). So maybe it's not worth
> > worrying about (thou
On Sat, Jun 25, 2016 at 01:14:50AM +, Eric Wong wrote:
> I'm not sure if this is the best approach, or if changing
> too_many_packs can be done without causing problems for
> hosts of big repos.
>
> ---8<-
> Subject: [PATCH] gc: correct gc.autoPackLimit documentation
>
> I want to en
her words, "foo"
>matches any directory component in $GIT_DIR.
>
> The combination of the first two is used to group repositories by
> path. While the last one could be used to match worktree's basename.
This is a nice description, but it probably belongs in the
do
On Sun, Jun 26, 2016 at 11:21:11PM +, Eric Wong wrote:
> We should continue to loop after EAGAIN/EWOULDBLOCK as the
> intent of xread is to read as much as possible until an
> EOF or real error occurs.
>
> Fixes: 1079c4be0b720 ("xread: poll on non blocking fds")
>
> Signed-off-by: Eric Wong
On Sun, Jun 26, 2016 at 11:21:12PM +, Eric Wong wrote:
> write(2) can hit the same EAGAIN/EWOULDBLOCK errors as read(2),
> so busy-looping on a non-blocking FD is a waste of resources.
>
> Currently, I do not know of a way for this happen:
>
> * the NonBlocking directive in systemd does not
On Sun, Jun 26, 2016 at 11:21:11PM +, Eric Wong wrote:
> We should continue to loop after EAGAIN/EWOULDBLOCK as the
> intent of xread is to read as much as possible until an
> EOF or real error occurs.
BTW, a minor nit here. xread() does _not_ read as much as possible until
EOF. It tries unti
On Mon, Jun 27, 2016 at 06:02:12AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I also wondered how we managed to miss such an obvious point in review
> > of the original patch. Sadly, we _did_ notice it[1] but it looks like we
> > never fixed the problem. That
On Mon, Jun 27, 2016 at 08:54:22AM -0700, Junio C Hamano wrote:
> It's just you used xwrite() there that introduced a different issue.
> Wouldn't replacing it with fwrite(stderr) without changing anything
> else solve that?
I am having trouble actually seeing how the ANSI-emulation code gets
trig
On Mon, Jun 27, 2016 at 06:14:17PM +0200, Duy Nguyen wrote:
> >> + } else if (!strchr(pattern.buf, '/')) {
> >> + /* no slashes match one directory component */
> >> + strbuf_insert(&pattern, 0, "**/", 3);
> >> + strbuf_addstr
On Mon, Jun 27, 2016 at 06:51:26AM +, Greg Werbin wrote:
> I was in the middle of a big messy rebase when the following
> happened:
>
> $ git rebase --continue
> /usr/local/Cellar/git/2.9.0/libexec/git-core/git-rebase--interactive:
> line 238: 60305
> Segmentation fault: 11 "$@"
> Could not
On Mon, Jun 27, 2016 at 06:32:39PM +0200, Duy Nguyen wrote:
> On Mon, Jun 27, 2016 at 6:20 PM, Jeff King wrote:
> > You do allow distinguishing the suffix thing with "/" at the end in the
> > rule above, though. So between the two rules:
> >
> >
On Sun, Jun 26, 2016 at 07:58:05AM +0200, Nguyễn Thái Ngọc Duy wrote:
> v4 is a cleaned up version of v3. Tests are added. Typos in
> git-fetch.txt are corrected. The "{ -> origin/}master" format is
> dropped.
Thanks for continuing to look into this.
I tried it on my most-horrible example case,
On Mon, Jun 27, 2016 at 07:46:18PM +0200, Matthieu Moy wrote:
> It was common in our documentation to surround short option names with
> forward quotes, which renders as italic in HTML. Instead, use backquotes
> which renders as monospace. This is one more step toward conformance to
> Documentatio
On Mon, Jun 27, 2016 at 07:46:19PM +0200, Matthieu Moy wrote:
> Similarly to the previous commit, use backquotes instead of
> forward-quotes, for long options.
>
> This was obtained with:
>
> perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt
>
> and manual tweak to remove false positive i
On Mon, Jun 27, 2016 at 07:46:20PM +0200, Matthieu Moy wrote:
> Subject: Re: [PATCH 3/6] doc: typeset -- as litteral
s/litteral/literal/
I can hardly blame you, though. I think English stole the word from
French and then switched its spelling. :)
You may also want put quotes around "--" to make
On Mon, Jun 27, 2016 at 09:49:06AM -0700, Stefan Beller wrote:
> Quite a while ago, when I started doing code reviews professionally, I
> wondered if the code review procedure can be semi-automated, as
> automation helps keeping the error rate low. By that I mean having a
> check list which I can
On Sun, Jun 26, 2016 at 07:16:16PM +0200, Nguyễn Thái Ngọc Duy wrote:
> The difference with --relative option is, this option does not filter
> paths outside cwd. You can add two more chars " ." on your command
> line for that.
Another difference seems to be that it applies only to --name-only, a
On Sun, Jun 26, 2016 at 01:16:35PM +0200, Nguyễn Thái Ngọc Duy wrote:
> Similar to $GIT_ASKPASS or $GIT_PROXY_COMMAND, we also read from
> config file first then fall back to $GIT_SSH_COMMAND.
>
> This is useful for selecting different private keys targetting the
> same host (e.g. github)
>
> Si
On Mon, Jun 27, 2016 at 09:33:18PM +0200, Duy Nguyen wrote:
> On Mon, Jun 27, 2016 at 9:24 PM, Jeff King wrote:
> > On Sun, Jun 26, 2016 at 07:16:16PM +0200, Nguyễn Thái Ngọc Duy wrote:
> >
> >> The difference with --relative option is, this option does not filter
> &g
On Sat, Jun 25, 2016 at 06:46:47AM +, Eric Wong wrote:
> This matches the documentation and allows gc.autoPackLimit=1
> to maintain a single pack without attempting a repack on every
> "git gc --auto" invocation.
>
> Signed-off-by: Eric Wong
> ---
> builtin/gc.c | 2 +-
> 1 file changed, 1
On Mon, Jun 27, 2016 at 12:43:32PM -0700, Stefan Beller wrote:
> There are a few issues:
>
> 1) How did you spot the bug? ("Experience/Logical thinking" is the hand
> wavy answer, but if you had a list like
> [ ] check for mem leak
> [ ] check for futureproof design
>
On Mon, Jun 27, 2016 at 08:13:11PM +, Eric Wong wrote:
> > Quite a while ago, when I started doing code reviews professionally, I
> > wondered
> > if the code review procedure can be semi-automated, as automation helps
> > keeping
> > the error rate low. By that I mean having a check list wh
On Mon, Jun 27, 2016 at 05:49:48PM -0400, Jeff King wrote:
> So in general I would say that handing non-blocking descriptors to git
> is not safe. I think it's possible to loop on getdelim() when we see
> EAGAIN, but I'm not sure if it's worth it.
The patch for that is be
On Tue, Jun 28, 2016 at 06:24:05PM +0200, Johannes Schindelin wrote:
> Essentially, the caveat in color.h that one should use fprintf() and
> printf() when outputting color sequences to a terminal no longer holds
> true. fwrite() or write() work just as well.
Cool. One less thing to worry about.
On Tue, Jun 28, 2016 at 07:26:39PM +0200, Nguyễn Thái Ngọc Duy wrote:
> There's a surprise about core.ignorecase. We are matching paths, so we
> should match case-insensitively if core.ignorecase tells us so. And it
> gets a bit tricky if core.ignorecase is defined in the same config
> file. I don
On Tue, Jun 28, 2016 at 07:26:41PM +0200, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 58673cf..c8ad0bf 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -91,6 +91,46 @@ found at the location of the include direc
On Tue, Jun 28, 2016 at 10:51:15PM +0200, Matthieu Moy wrote:
> Jeff King writes:
>
> > On Tue, Jun 28, 2016 at 07:26:39PM +0200, Nguyễn Thái Ngọc Duy wrote:
> >
> >> There's a surprise about core.ignorecase. We are matching paths, so we
> >> should ma
On Tue, Jun 28, 2016 at 04:36:25PM -0700, Junio C Hamano wrote:
> * jk/test-match-signal (2016-06-24) 4 commits
> - t/lib-git-daemon: use test_match_signal
> - test_must_fail: use test_match_signal
> - t0005: use test_match_signal as appropriate
> - tests: factor portable signal check out of t
On Wed, Jun 29, 2016 at 01:39:17PM -0700, Junio C Hamano wrote:
> > Would it make sense to refuse creating commits that have a commit date
> > prior to its parents commit date (except when the user gives a
> > `--dammit-I-know-I-break-a-wildy-used-heuristic`)?
>
> I think that has also been discu
On Wed, Jun 29, 2016 at 02:37:17PM -0700, Stefan Beller wrote:
> On Wed, Jun 29, 2016 at 1:54 PM, Stefan Beller wrote:
> > Chances are that the 10 years of history may be correct time wise as long
> > as people don't introduce a bad date malevolently.
> >
>
> To answer my own speculation:
> Even
On Wed, Jun 29, 2016 at 11:49:35PM +0200, Jakub Narębski wrote:
> > So this is the ideal case for generation numbers (the worst cases are
> > when the things you are looking for are in branchy, close history where
> > the generation numbers don't tell you much; but in such cases the
> > walking is
On Wed, Jun 29, 2016 at 03:11:39PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes, though generation numbers can help with more questions (e.g., "what
> > is the merge base").
>
> Hmm, how? I have two commits, with generation number 38 and 47
On Wed, Jun 29, 2016 at 12:48:33PM +0100, Laszlo Papp wrote:
> Old releases are maintained with important bug fixes or even new features
> in our case. It sometimes means that we need to cherry-pick commits across
> branches, like from master to a specific release branch.
>
> Cherry-picking chang
On Wed, Jun 29, 2016 at 01:47:31PM +0200, Johannes Schindelin wrote:
> On Tue, 28 Jun 2016, Junio C Hamano wrote:
>
> > * jk/ansi-color (2016-06-23) 7 commits
> > (merged to 'next' on 2016-06-28 at 354989c)
> > + color: support strike-through attribute
> > + color: support "italic" attribute
On Tue, Jun 28, 2016 at 01:40:08PM +0200, Matthieu Moy wrote:
> This should address all comments from Peff.
Thanks. The review is mind-numbing enough that I didn't do a complete
read-through again, but just spot-checked a few places. This version
looks good to me.
-Peff
--
To unsubscribe from th
On Wed, Jun 29, 2016 at 09:02:37AM +0200, Johannes Schindelin wrote:
> It is the most convenient way to determine which tests failed after
> running the entire test suite, in parallel, to look for left-over "trash
> directory.t*" subdirectories in the t/ subdirectory.
As Junio noted, this doesn't
On Wed, Jun 29, 2016 at 07:41:36AM +0200, Johannes Sixt wrote:
> Am 29.06.2016 um 03:43 schrieb Jeff King:
> > Another is to just put the posix/ksh schemes into the helper function,
> > and let Windows people sort it out later if they want to.
>
> Let's do this.
OK, he
This is a re-roll of the jk/big-and-future-archive-tar topic. It
addresses all but one of the review comments, and I hope should be
pretty polished.
The changes are:
- the dependency on bunzip2 is dropped; instead, we just provide a
partial object for the 64GB blob. See the first commit mes
We never do any error checks, and so never return anything
but "0". Let's just drop this to simplify the code.
Signed-off-by: Jeff King
---
archive-tar.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c
index d671bc3.
3. Your tar implementation _does_ parse 12-byte sizes from
the ustar header without a delimiter.
It's probably not worth worrying about such an obscure set
of conditions, but I'm documenting it here just in case.
Helped-by: René Scharfe
Signed-off-by: Jeff King
---
archive-ta
ve timestamps at all, I didn't bother here.
After writing the extended header, we munge the timestamp in
the ustar headers to the maximum-allowable size. This is
wrong, but it's the least-wrong thing we can provide to a
tar implementation that doesn't understand pax headers (it's
rns out not to be portable,
though, it would be easy for us to handle it.
That makes the perl solution the least bad (because we
conveniently omitted "length of code" as a criterion).
It's also what t9300 is currently using, so we can just pull
the implementati
On Thu, Jun 30, 2016 at 05:06:14AM -0400, Jeff King wrote:
> The one thing that isn't fixed is the use of "141" to test for sigpipe
> death. That should use test_match_signal, but that topic just got
> re-rolled, too.
And here's what the patch for that looks like
er and actually verify the result.
Helped-by: Robin H. Johnson
Signed-off-by: Jeff King
---
t/t5000-tar-tree.sh | 74 +++
t/t5000/19f9c8273ec45a8938e6999cb59b3ff66739902a | Bin 0 -> 2048 bytes
t/t5000/huge-and-future.tar
On Thu, Jun 30, 2016 at 10:42:37AM +0200, Johannes Schindelin wrote:
> > > The vast majority of error messages in Git's source code which report a
> > > bug use the convention to prefix the message with "BUG:".
> >
> > Good thing to do.
> >
> > But if we were to review and apply a 200+ line patc
On Thu, Jun 30, 2016 at 11:12:52AM -0700, Linus Torvalds wrote:
> I do think that it's ok to cache generation numbers somewhere if there
> is an algorithm that can make use of them, but every time this comes
> up, it's just not been important enough to make a big deal and a new
> incompatible obje
On Thu, Jun 30, 2016 at 03:24:41PM -0600, d...@ucar.edu wrote:
> Carson:part2: git push
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> A s s e r t i o n f a i l e d !
>
> P r o g r a m :
On Fri, Jul 01, 2016 at 12:07:15AM -0400, Jeff King wrote:
> Interesting. It's failing on the assert(argv0_path) in system_path().
>
> That's part of the RUNTIME_PREFIX code which is built only on Windows,
> so this is a Windows-specific issue.
>
> I can guess the r
argv strings as const
anyway, and now all programs conform to the same signature
(which also matches the way builtins are defined).
Signed-off-by: Jeff King
---
I waffled between the two mechanisms. Opinions welcome.
Makefile | 17 +
common-ma
that actually
cares about the result of the function, and not the
side-effect of setting up argv0_path. We can accommodate
that by simply replacing the value of argv[0] in the array
we hand down to cmd_main().
Signed-off-by: Jeff King
---
common-main.c| 3 +++
daemon.c | 3 ---
f
descriptors we
opened, but that's not a big deal (it's not wrong to do so,
nor is it really less optimal than the case where our parent
process redirected us from /dev/null ahead of time).
Signed-off-by: Jeff King
---
common-main.c | 9 -
daemon.c | 3 +--
git.c
s
somebody calling git-upload-pack directly via ssh, or
scripts which use dashed external commands directly.
Signed-off-by: Jeff King
---
common-main.c | 23 +++
git.c | 23 ---
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/commo
This should be part of every program, as otherwise users do
not get translated error messages. However, some external
commands forgot to do so (e.g., git-credential-store). This
fixes them, and eliminates the repeated code in programs
that did remember to use it.
Signed-off-by: Jeff King
On Thu, Jun 30, 2016 at 06:16:09PM +0200, Duy Nguyen wrote:
> > I've shrunk it a bit to fit in the email; my actual "long" name was much
> > larger. And the average length for the shorter ones is, too, but the
> > overall effect is the same; almost every line has a huge run of
> > whitespace. And
On Thu, Jun 30, 2016 at 09:38:45PM +0200, Steffen Nurpmeso wrote:
> For some time (currently with 2.9.0) know see that a single commit
> gives a longer hash than necessary, even though there is no
> ambiguity:
>
> ?0[steffen@wales ]$ git longca|
> awk 'BEGIN{l7=0;l8=0}\
> /^[[:alnum:]]{7}
On Thu, Jun 30, 2016 at 06:39:42PM +0200, Nguyễn Thái Ngọc Duy wrote:
> Commit 76c61fb (log: decorate HEAD with branch name under
> --decorate=full, too - 2015-05-13) adds "HEAD -> branch" decoration to
> show current branch vs detached HEAD. The sign of whether HEAD is
> detached or not is "->" (
On Thu, Jun 30, 2016 at 05:14:15PM +0200, Duy Nguyen wrote:
> > So we could describe how Git handles pathspecs and pathspec magic
> > in the new manual page named gitpathspec(7), or gitpaths(7). The
> > former has the advantage of the name being identical to the entry
> > in gitglossary(7). The la
On Thu, Jun 30, 2016 at 12:30:31PM +0200, Jakub Narębski wrote:
> > This is one of the open questions. My older patches turned them off when
> > replacements and grafts are in effect.
>
> Well, if you store the cache of generation numbers in the packfile, or in
> the index of the packfile, or in
On Wed, Jun 29, 2016 at 05:59:48PM -0700, Stefan Beller wrote:
> The environment variable GIT_PUSH_OPTION_FILE is set to the push options
> separated by new line.
>
> The code is not executed as the push options are set to NULL, nor is the
> new capability advertised.
>
> The rationale for keepi
On Wed, Jun 29, 2016 at 05:59:47PM -0700, Stefan Beller wrote:
> Allow a user to pass information along a push to the pre/post-receive hook
> on the remote.
Seems like a reasonable thing to want, and related to:
http://thread.gmane.org/gmane.comp.version-control.git/285124
which was specifica
On Fri, Jul 01, 2016 at 09:38:33AM +0200, Johannes Schindelin wrote:
> it is sad when bug reporters simply delete the part of our bug reporting
> template that says: "I searched for existing bug reports but did not find
> any".
>
> It saves the reporters a few minutes... and spends the time of yo
ff-by: Jeff King
---
Just a cleanup I noticed while working on the common-main series.
Makefile | 8
1 file changed, 8 deletions(-)
diff --git a/Makefile b/Makefile
index de5a030..22815a2 100644
--- a/Makefile
+++ b/Makefile
@@ -2225,16 +2225,8 @@ perf: all
.PHONY: test perf
-t/h
We have an abstracted variable; let's use it consistently.
Signed-off-by: Jeff King
---
On top of the cleanup earlier in the thread.
I actually wonder if we should drop the vcs-svn code entirely. The last
update that wasn't just part of a "I'm grepping the whole code
On Fri, Jul 01, 2016 at 10:04:44AM +0200, Johannes Schindelin wrote:
> Hi Peff,
>
> On Fri, 1 Jul 2016, Jeff King wrote:
>
> > I waffled between the two mechanisms. Opinions welcome.
>
> I am happy you took the cmd_main() approach: we do have to play some
> tricks o
On Fri, Jul 01, 2016 at 10:07:10AM -0700, Stefan Beller wrote:
> > So you'd probably want some client tool to help the user figure out what
> > to put in the PR, and of course that already exists, because GitHub has
> > an HTTP API that it can talk to. Shoe-horning it into Git doesn't buy
> > much
On Fri, Jul 01, 2016 at 10:20:32AM -0700, Stefan Beller wrote:
> >> The rationale for keeping the actual options inside a file instead of
> >> putting them directly into an environment variable has multiple reasons:
> >
> > Thanks for including this rationale; my first thought on seeing the
> > pa
On Fri, Jul 01, 2016 at 10:23:05AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > In shell scripts it is sometimes useful to be able to read
> > exactly N bytes from a pipe. Doing this portably turns out
> > to be surprisingly difficult.
>
> I
On Fri, Jul 01, 2016 at 11:03:06AM -0700, Junio C Hamano wrote:
> On Fri, Jul 1, 2016 at 10:59 AM, Jeff King wrote:
> > If you give up on having multiple incarnations of each variable, then I
> > think:
> >
> > GIT_PUSH_VAR_foo=value_for_foo
> > GIT_PUSH
On Fri, Jul 01, 2016 at 03:51:33PM +0200, Johannes Schindelin wrote:
> > > If the idea is to make it easier to find, I would wager a guess that
> > > 'die("BUG:' would be just as good a search term. Even better, I think,
> > > because 'BUG' would also match comments.
> >
> > I have been tempted t
On Fri, Jul 01, 2016 at 12:25:39PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Compare to:
> >
> > if test "$GIT_PUSH_VAR_force" = true
> > ...
>
> OK. As this is a new feature, I guess it is not too bad if we tell
> users th
On Fri, Jul 01, 2016 at 11:25:40AM -0700, Stefan Beller wrote:
> > So a litmus test for me would be something like:
> >
> > Can you get the same effect with:
> >
> > git push $remote my-branch &&
> > curl https://$remote/api/do-the-thing?q=my-branch
> >
> > as you would with:
> >
> >
On Fri, Jul 01, 2016 at 03:39:03PM +0200, Johannes Schindelin wrote:
> > The description was sufficiently long that I didn't want to try
> > repeating it, and opted for a reference instead. If you're planning to
> > fix mingw_main(), I'd be happy to do that as a preparatory patch, and
> > then jus
On Fri, Jul 01, 2016 at 03:19:37PM -0700, Junio C Hamano wrote:
> > Here they are:
> >
> > [1/5]: add an extra level of indirection to main()
> > [2/5]: common-main: call git_extract_argv0_path()
> > [3/5]: common-main: call sanitize_stdfds()
> > [4/5]: common-main: call restore_sigpipe_to
On Tue, Jul 05, 2016 at 01:58:51PM +0200, Johannes Schindelin wrote:
> This developer stumbled over repeated OPT_END entries and was *so
> close* (almost touches his thumb with his index finger) to collapse
> them into a single one. Only inspecting the file's history with
> `git log -p -SOPT_END`
On Tue, Jul 05, 2016 at 04:28:20PM -0400, Jeff King wrote:
> I wonder if parse_options_concat should simply allocate a new list
> (after computing the total required size). I guess this is the only
> caller, though, so perhaps it's not the end of the world. In the
> meanti
On Wed, Jul 06, 2016 at 09:03:44AM +0200, Johannes Schindelin wrote:
> > By the way, I notice that the error message when concat fails is just:
> >
> > if (parse_options_concat(options, ARRAY_SIZE(options), cp_extra))
> > die(_("program error"));
> >
> > Should this become:
> >
> >
On Wed, Jul 06, 2016 at 11:23:51AM -0700, Junio C Hamano wrote:
> > -test_expect_success 'temporary filenames are used with
> > mergetool.writeToTemp' '
> > +test_lazy_prereq MKTEMP '
> > + tempdir=$(mktemp -d -t foo.XXX) &&
> > + test -d "$tempdir"
> > +'
>
> This makes me wonder what would
On Wed, Jul 06, 2016 at 06:42:19PM +0200, Andreas Schwab wrote:
> Peter writes:
>
> > I am a lightweigt git user so by all means not a reference, but I was
> > wondering why exactly does "git rm" also delete the file (remove it
> > from the working tree). I see it as an unintended behaviour as g
e it
does not give the actual filename).
Let's convert that site to use the non-gentle form. At that
point the gentle form has no callers, and we can simplify
the implementation of write_file.
Signed-off-by: Jeff King
---
As a fun aside, this patch was generated using "--patience"
On Thu, Jul 07, 2016 at 10:08:30PM +0200, René Scharfe wrote:
> Use the open(2) flag O_EXCL to ensure the file doesn't already exist
> instead of (racily) calling stat(2) through file_exists(). While at it
> switch to xopen() to reduce code duplication and get more consistent
> error messages.
T
On Thu, Jul 07, 2016 at 10:09:17PM +0300, Kirill Smelkov wrote:
> Starting from 6b8fda2d (pack-objects: use bitmaps when packing objects)
> if a repository has bitmap index, pack-objects can nicely speedup
> "Counting objects" graph traversal phase. That however was done only for
> case when resul
701 - 800 of 15671 matches
Mail list logo
