By the way, you can see my performance numbers here:
https://www.usenix.org/system/files/conference/atc18/atc18-lawall.pdf
Page 8, figures 4 and 5.
julia
On Fri, Aug 3, 2018 at 2:26 AM Jonathan Nieder wrote:
> Eric Sunshine wrote:
> > + if (fd < 0 || fd >= ARRAY_SIZE(want_auto))
> > + BUG("file descriptor out of range: %d", fd);
>
> The indentation looks wrong here.
Yep, that's weird. I can't figure out how that got indented with four
Hi,
Jeff King wrote:
> On Thu, Aug 02, 2018 at 02:01:55PM -0400, Jeff King wrote:
>> I suspect if we go with the one-spatch-per-source route, though, that we
>> could do this just with regular make rules.
>
> Yeah, it's pretty straightforward:
>
> diff --git a/Makefile b/Makefile
> index
Hi,
Eric Sunshine wrote:
> want_color_fd() is designed to work only with standard input, output,
> and error file descriptors, and stores information about each descriptor
> in an array. However, it doesn't verify that the passed-in descriptor
> lives within that set, which, with a buggy caller,
On Thu, 2 Aug 2018 14:15:54 -0700
Stefan Beller wrote:
> On Thu, Aug 2, 2018 at 6:47 AM Antonio Ospite wrote:
> >
> > In particular this makes it possible to really clean things up when
> > removing the last submodule with "git rm".
>
> This sentence is a continuation of the subject line, and
--
I Mr Richard Wahl donates $ 2 Million Dollars from part of my $533M In Mega
MillionsJackpot.WATCH ME HERE: https://www.youtube.com/watch?v=tne02ExNDrw
File for claims
Hi Derrick,
> The commit-graph file is a very helpful feature for speeding up git
> operations. In order to make it more useful, make it possible to
> write the commit-graph file during standard garbage collection
> operations.
>
> Add a 'gc.commitGraph' config setting that triggers writing a
On Thu, 2 Aug 2018 15:20:33 -0400
Jeff King wrote:
> On Thu, Aug 02, 2018 at 11:47:30AM -0700, Stefan Beller wrote:
>
> > > +static int module_config(int argc, const char **argv, const char *prefix)
> > > +{
> > > + if (argc < 2 || argc > 3)
> > > + die("submodule--helper
On Thu, Aug 2, 2018 at 1:27 PM Junio C Hamano wrote:
> Phillip Wood writes:
> > For other interactive rebases this only affects external scripts that
> > read the author script and users whose git is upgraded from the shell
> > version of rebase -i while rebase was stopped when the author
s/angular brackets/angle brackets/
I've never seen these called "angular brackets".
Richard Kerry
BNCS Engineer, SI SOL Telco & Media Vertical Practice
M: +44 (0)7812 325518
2nd Floor, MidCity Place, 71 High Holborn, London, WC1V 6EA
On Thu, 2 Aug 2018 13:50:55 -0700
Stefan Beller wrote:
> On Thu, Aug 2, 2018 at 6:47 AM Antonio Ospite wrote:
> >
> > The is_empty_file() function can be generally useful, move it to dir.c
> > and make it public.
> >
> > Signed-off-by: Antonio Ospite
>
> Makes sense,
>
> Thanks,
> Stefan
>
Dear Eric and Junio
On 03/08/18 08:59, Eric Sunshine wrote:
> On Thu, Aug 2, 2018 at 1:27 PM Junio C Hamano wrote:
>> Phillip Wood writes:
>>> For other interactive rebases this only affects external scripts that
>>> read the author script and users whose git is upgraded from the shell
>>>
Hi Ævar
Thanks for looking at this.
On 28/07/18 13:40, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Jul 26 2018, Phillip Wood wrote:
>
>> Unfortuantely v4 had test failures due to a suprious brace from a last
>> minute edit to a comment that I forgot to test. This version fixes
>> that, my
On Fri, Aug 3, 2018 at 5:33 AM Phillip Wood wrote:
> If there isn't some backward compatibility then if git gets upgraded
> while rebase is stopped then the author data will be silently corrupted
> if it contains "'". read_author_ident() will error out but that is only
> used for the root commit.
On Thu, Aug 2, 2018 at 7:20 AM Phillip Wood wrote:
> The calling code did not treat NULL as an error. Instead NULL caused
> it to fallback to using the default author when creating the new
> commit. This changed the date and potentially the author of the
> commit which corrupted the author data
Hi again,
Sorry for the slow review. I finally got a chance to look this over
again.
My main nits are about the commit message: I think it still focuses
too much on the process instead of the usual "knowing what I know now,
here's the clearest explanation for why we need this patch" approach.
I
On Fri, Aug 03 2018, Martin Mosegaard Amdisen wrote:
> The documentation for the "git describe --abbrev" flag says that the
> default value is 7 hexadecimal digits:
> https://github.com/git/git/blob/master/Documentation/git-describe.txt#L63
> and
> https://git-scm.com/docs/git-describe
>
> I
The documentation for the "git describe --abbrev" flag says that the
default value is 7 hexadecimal digits:
https://github.com/git/git/blob/master/Documentation/git-describe.txt#L63
and
https://git-scm.com/docs/git-describe
I have experienced that sometimes I see 7 digits, but other times more.
On Thu, Aug 02, 2018 at 11:21:44PM -0700, Jonathan Nieder wrote:
> > diff --git a/Makefile b/Makefile
> > index d616c0412..86fdcf567 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -2674,15 +2674,17 @@ COCCI_SOURCES = $(filter-out
> > sha1collisiondetection/%,$(C_SOURCES))
> > else
> >
Hello,
I'm trying to manually implement Github's *Squash *functionality.
After looking many forums like stackoverflow.com I'm still struggling with
the issue.
*The scenario is as follows*:
- master is a protected branch (configured on github)
- a service user *svc *is permitted to push to master
On Thu, Aug 02, 2018 at 08:29:48PM -0700, Jonathan Nieder wrote:
> (cc-ing peff, config whiz)
Actually, this is all about the configset caching layer, which I never
really worked on. This is mostly from Tanay Abhra ,
who was a GSoC student mentored by Matthieu Moy .
That said...
> > +
> > +/*
I have curl 7.35.0 installed on my ubuntu14.04, version infos is as below
I have recompiled git against openssl. the git version is 1.9.1. I
encountered this error "error: git-remote-http died of signal 13" when I
issue `git clone http://github.com/tensorflow/tensorflow.git`. Should I
upgrade
On Fri, Aug 03, 2018 at 02:56:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Any Git commands you run should therefore find objects from either
> > location, but any writes would go to the quarantine (most notably, Git's
> > own index-pack/unpack-objects processes, which is the point of the
> >
Hi Jonathan,
On Fri, 27 Jul 2018, Johannes Schindelin wrote:
> On Thu, 26 Jul 2018, Jonathan Tan wrote:
>
> > > On Mon, 16 Jul 2018, Jonathan Tan wrote:
> > >
> > > > t/t5552-skipping-fetch-negotiator.sh | 179 +++
> > >
> > > This test seems to be failing consistently in the
On Fri, Aug 03 2018, Jeff King wrote:
> On Fri, Aug 03, 2018 at 02:56:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > Any Git commands you run should therefore find objects from either
>> > location, but any writes would go to the quarantine (most notably, Git's
>> > own
s/angular brackets/angle brackets/
I've never seen these called "angular brackets". Maybe a non-native English
speaker issue.
Regards,
Richard.
PS. Please excuse my sending this twice, I don't seem to have default settings
that are compatible with the list.
Richard Kerry
BNCS
On Thu, 02 Aug 2018 11:57:14 -0700
Junio C Hamano wrote:
> Antonio Ospite writes:
>
> > Add a --stage option to the 'submodule--helper config' command so that
> > the .gitmodules file can be staged without referring to it explicitly by
> > its file path.
>
> Sorry, but I have no clue what the
On Thu, Aug 02 2018, Jeff King wrote:
> On Thu, Aug 02, 2018 at 12:58:52PM -0500, Liam Decker wrote:
>
>> I've been working on a git hook in golang recently. However, the library I
>> was using did not support a possible quarantine directory, which I would
>> use for my hook.
>>
>> I have been
On Mon, Jul 30, 2018 at 08:25:16PM +0200, SZEDER Gábor wrote:
> > diff --git a/sequencer.c b/sequencer.c
> > index 1c035ceec7..d257903db0 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
>
> > +int write_basic_state(struct replay_opts *opts, const char *head_name,
> > + const
On Fri, Aug 03, 2018 at 03:01:15PM +0300, Vadim Belov wrote:
> 1. This merges successfully without squash:
> git checkout origin/master
> git merge ${PR-Branch}
> git push origin HEAD:master
> git push origin --delete ${PR-Branch}
Right, this is a normal merge.
> 2. This closes the PR, but
On Fri, Aug 03, 2018 at 03:25:08PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I'd be a bit careful with that, though, as the definition of "new" is
> > vague there.
> >
> > For example, completing a thin pack may mean that the receiver creates a
> > copy of a base object found in the main repo.
On Tue, Jul 31, 2018 at 08:25:47PM -0400, Santiago Torres wrote:
> On Wed, Aug 01, 2018 at 12:19:42AM +, brian m. carlson wrote:
> > On Tue, Jul 31, 2018 at 10:05:22PM +0200, Vojtech Myslivec wrote:
> > > Hello,
> > >
> > > me and my colleague are struggling with automation of verifying git
>
On 7/13/2018 12:55 PM, g...@jeffhostetler.com wrote:
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
Documentation/technical/structured-logging.txt | 816 +
1 file changed, 816 insertions(+)
create mode 100644
Hi Eric
On 03/08/18 11:02, Eric Sunshine wrote:
On Fri, Aug 3, 2018 at 5:33 AM Phillip Wood wrote:
If there isn't some backward compatibility then if git gets upgraded
while rebase is stopped then the author data will be silently corrupted
if it contains "'". read_author_ident() will error out
On 2018-08-02 15:43, Duy Nguyen wrote:
> On Wed, Aug 1, 2018 at 11:20 PM Junio C Hamano wrote:
>>
>> Junio C Hamano writes:
>>
>>> Jeff King writes:
>>>
> Presumably we are already in an error codepath, so if it is
> absolutely necessary, then we can issue a lstat() to grab the inum
René Scharfe writes:
> Am 02.08.2018 um 22:36 schrieb Junio C Hamano:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> Thanks, FWIW that's fine by me, and also if you want to drop this "fake"
>>> patch of mine and replace it with something René came up with (I have
>>> not yet read his 1-6 patches
I was tweaking is_scissors_line function in mailinfo.c and tried writing
some tests for it. And discovered that existing test for git am option
--scissors is broken. I then confirmed that by intentionally breaking
is_scissors_line, like this:
--- 8< ---
Subject: [PATCH 1/2] mailinfo.c:
René Scharfe writes:
> Am 02.08.2018 um 22:01 schrieb Junio C Hamano:
>>
>> Straying sideways into a tangent, but do we know if any locale wants
>> to use something other than "<>" as an enclosing braket around a
>> placeholder?
>
> Bulgarian seems to use capitals instead; here are some
> > disable fetching keys from hkp servers. This way signature verification
> > should fail.
> >
> > Thanks,
> > -Santiago.
>
> This is not a deviation. GPG correctly recognizes difference between trusted,
> untrusted and unknown levels. git on the other hand does not. Well it did
> until
> the
Stefan Beller writes:
> And *technically* the two level is old style, so I figured it's ok.
If we call the bit not after the recentness of the style but after
what it is about, e.g. "is the section name as a whole (including
its possible subsection part) case insensitive?", then yes, a
Jeff King writes:
> This is returning the value of git_config_from_file(), which is 0/-1. I
> think it should be left where it is in the original, and not part of
> this block of functions.
>
> Other than that, the patch seems sane to me (I think the 0/1 return
> value from these "get" functions
Antonio Ospite writes:
> The rationale behind the change is to close the circle started with 04
> and 05 and stop referring to .gitmodules explicitly by file path in git
> commands. The change is not strictly needed for the series, it's for
> consistency sake.
Sorry, but I am still not quite
The error message and the value that caused that error should be
separated by a colon.
Signed-off-by: Ralf Thielow
---
builtin/config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/config.c b/builtin/config.c
index 2c93a289a7..862f870b58 100644
---
On Fri, Aug 3, 2018 at 9:40 AM Junio C Hamano wrote:
>
> > [...]
> >> - - 20-byte NewHash checksum of all of the above.
> >> + - 20-byte SHA-256 checksum of all of the above.
> >
> > Likewise.
>
> Hmph, I've always assumed since NewHash plan was written that this
> part was not about tamper
Eric Sunshine writes:
> I think this patch can be simplified considerably by shifting one's
> perspective. If we admit that read_author_ident() is already correctly
> reporting an error by returning NULL (which is exactly what it is
> doing), then the bug is is purely on the calling side;
Stefan Beller writes:
> On Thu, Aug 2, 2018 at 4:02 PM Junio C Hamano wrote:
>
>> * sb/config-write-fix (2018-08-01) 3 commits
>> - git-config: document accidental multi-line setting in deprecated syntax
>> - config: fix case sensitive subsection names on writing
>> - t1300: document current
On Fri, Aug 3, 2018 at 12:20 AM Jonathan Nieder wrote:
>
>
> Here I'd want to put a pile of acks, e.g.:
>
> Acked-by: Linus Torvalds
> ..
Sure, feel free to add my Ack for this.
Linus
On Thu, Aug 02, 2018 at 02:02:00PM -0400, Ben Peart wrote:
>
>
> On 8/1/2018 11:10 AM, Duy Nguyen wrote:
> > On Tue, Jul 31, 2018 at 7:03 PM Ben Peart wrote:
> >>
> >> From: Ben Peart
> >>
> >> Skip merging the commit, updating the index and working directory if and
> >> only if we are
On Fri, Aug 03, 2018 at 11:43:44AM -0400, Santiago Torres wrote:
> > This is not a deviation. GPG correctly recognizes difference between
> > trusted,
> > untrusted and unknown levels. git on the other hand does not. Well it did
> > until
> > the commit a4cc18f29. That one removed GPG exit code
Pratik Karki writes:
> Hi Junio,
>
> On Fri, Aug 3, 2018 at 4:47 AM Junio C Hamano wrote:
>>
>> * pk/rebase-in-c (2018-07-30) 3 commits
>> - builtin/rebase: support running "git rebase "
>> - rebase: refactor common shell functions into their own file
>> - rebase: start implementing it as a
Another friendly ping. I really need to know if I need to update (or
drop) this part before moving on to part 3.
On Sat, Jul 21, 2018 at 11:06 AM Duy Nguyen wrote:
>
> On Sat, Jun 30, 2018 at 11:20 AM Nguyễn Thái Ngọc Duy
> wrote:
> >
> > Like part 1 this is also boring. I wanted to drop these
Jonathan Nieder writes:
> Sorry for the slow review. I finally got a chance to look this over
> again.
>
> My main nits are about the commit message: I think it still focuses
> too much on the process instead of the usual "knowing what I know now,
> here's the clearest explanation for why we
Phillip Wood writes:
> ... [I'm beginning to see why all the other programs I tried while
> writing this (tig, gitg, gitk and mercurial's version of add -i)
> don't make any attempt to stage modified lines correctly, though I
> think git should have some way of doing it.]
Yes, this is a kind of
Duy Nguyen writes:
> Another friendly ping. I really need to know if I need to update (or
> drop) this part before moving on to part 3.
Easier is to resend and see if it sticks this time (that is how I
landed format-patch back when I was just an individual contributor
;-)
I will see if I can
Thanks, Peff!
I'm just doing the CI and the status check is for testing each commit to
the PR-Branch.
I'll try to get response from github on this as you suggested.
Thanks again,
Vadim
On Fri, Aug 3, 2018 at 4:49 PM Jeff King wrote:
> On Fri, Aug 03, 2018 at 03:01:15PM +0300, Vadim Belov
From: Johannes Schindelin
The --exec option's implementation is not really well-prepared for
--rebase-merges. Demonstrate this.
Signed-off-by: Johannes Schindelin
---
t/t3430-rebase-merges.sh | 17 +
1 file changed, 17 insertions(+)
diff --git a/t/t3430-rebase-merges.sh
It was reported via IRC that the exec lines are inserted in the wrong spots
when using --rebase-merges.
The reason is that we used a simple, incorrect implementation that happened
to work as long as the generated todo list only contains pick, fixup and
squash commands. Which is not the case
From: Johannes Schindelin
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a fixup/squash chain", i.e. an
exec would not be inserted between a `pick` and any of
On Fri, Aug 03, 2018 at 12:20:14AM -0700, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
> > Object format
> > ~
> > The content as a byte sequence of a tag, commit, or tree object named
> > -by sha1 and newhash differ because an object named by newhash-name refers
> > to
On Fri, Aug 03 2018, Phillip Wood wrote:
[snip (all made sense)]
> It seems clear for your comment and Junio's that I need to improve the
> documentation, I'm not sure if that will be enough though or do we need
> to change the behavior? [I'm beginning to see why all the other programs
> I
On Thu, Aug 02, 2018 at 04:02:36PM -0700, Junio C Hamano wrote:
> --
> [New Topics]
I had expected to see
<20180729192803.1047050-1-sand...@crustytoothpaste.net> (the refspec @
handling) in this list, but I don't. Were you expecting changes or
On 8/2/2018 5:28 PM, Jeff King wrote:
On Thu, Aug 02, 2018 at 02:14:30PM -0700, Junio C Hamano wrote:
Jeff King writes:
I also wonder if Windows could return some other file-unique identifier
that would work in place of an inode here. That would be pretty easy to
swap in via an #ifdef's
Santiago Torres writes:
> Now that I think about it though, verify tag can verify more than one
> tag. I assume that this would make it difficult to propagate individual
> errors in trusting. I honestly don't know what's the best way to modify
> this behavior then.
I am not sure if changing the
On Fri, Aug 03 2018, Jonathan Nieder wrote:
> Hi again,
>
> Sorry for the slow review. I finally got a chance to look this over
> again.
>
> My main nits are about the commit message: I think it still focuses
> too much on the process instead of the usual "knowing what I know now,
> here's the
I need assistance synchronize a fork with it's parent
https://github.com/DG12/ruuvitag_fw
This branch is 5 commits ahead, 29 commits behind ruuvi:master.
I want to revise main.c and the issue a pull request.
Sorry, but I am lost.
Seems that I am trying to do something simple.
Any help
On Fri, Aug 03, 2018 at 09:38:34PM +, Tacitus Aedifex wrote:
> I'm looking at the existing commit signing and verification
> integration and it is all GPG specific. I'm interested in refactoring
> the code to have a generic signing/verifying interface so that "drivers"
> for other signing
All other error messages in cmd_update are reporting the submodule based
on its path, so let's do that for invalid update modes, too.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
git-submodule.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
In a later patch we'll find this method handy.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
builtin/submodule--helper.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index
This chews off a bit of the shell part of the update command in
git-submodule.sh. When writing the C code, keep in mind that the
submodule--helper part will go away eventually and we want to have
a C function that is able to determine the submodule update strategy,
it as a nicety, make
* Introduce new patch
"submodule--helper: replace connect-gitdir-workingtree by
ensure-core-worktree"
that resolves the conflict with earlier versions of this series with
sb/submodule-core-worktree
* This series is based on master, which already contains
sb/submodule-core-worktree
The information that is printed for update_submodules in
'submodule--helper update-clone' and consumed by 'git submodule update'
is stored as a string per submodule. This made sense at the time of
48308681b07 (git submodule update: have a dedicated helper for cloning,
2016-02-29), but as we want
e98317508c0 (submodule: ensure core.worktree is set after update,
2018-06-18) was overly aggressive in calling connect_work_tree_and_git_dir
as that ensures both the 'core.worktree' configuration is set as well as
setting up correct gitlink file pointing at the git directory.
We do not need to
The 'mode' variable is not used in cmd_update for its original purpose,
rename it to 'dummy' as it only serves the purpose to abort quickly
documenting this knowledge.
The variable 'stage' is also not used any more in cmd_update, so remove it.
This went unnoticed as first each function used the
Separate the command line parsing from the actual execution of the command
within the repository. For now there is not a lot of execution as
most of it is still in git-submodule.sh.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
builtin/submodule--helper.c | 59
This test description looks like it was written with the originally
observed behavior ("causes segfault") rather than the desired and now
current behavior ("does not cause segfault"). Fix it.
Signed-off-by: Elijah Newren
---
t/t3031-merge-criscross.sh | 2 +-
1 file changed, 1 insertion(+), 1
On 08/03, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > "brian m. carlson" writes:
> >
> >> On Fri, Aug 03, 2018 at 11:40:08AM -0700, Junio C Hamano wrote:
> >>> "brian m. carlson" writes:
> >>>
> >>> > On Thu, Aug 02, 2018 at 04:02:36PM -0700, Junio C Hamano wrote:
> >>> >>
On August 3, 2018 5:39 PM, Tacitus Aedifex wrote:
> I'm looking at the existing commit signing and verification integration and
> it is
> all GPG specific. I'm interested in refactoring the code to have a generic
> signing/verifying interface so that "drivers"
> for other signing tools can be
On Fri, Aug 3, 2018 at 7:14 PM Elijah Newren wrote:
> A test making use of test_must_fail was failing like this:
> fatal: ambiguous argument '|': unknown revision or path not in the working
> tree.
> when the intent was to verify that a specific string was not found
> in the output of the git
After making a change to the documentation, it's easy to
forget to check the rendered version to make sure it was
formatted as you intended. And simply doing a diff between
the two built versions is less trivial than you might hope:
- diffing the roff or html output isn't particularly
Andrei Rybak writes:
> Tests for "git am --[no-]scissors" [1] work in the following way:
>
> 1. Create files with commit messages
> 2. Use these files to create expected commits
> 3. Generate eml file with patch from expected commits
> 4. Create commits using git am with these eml files
>
On 2018-08-04 01:04, Junio C Hamano wrote:
> Hmph, I am not quite sure what is going on. Is the only bug in the
> original that scissors-patch.eml and no-scissors-patch.eml files were
> incorrectly named? IOW, if we fed no-scissors-patch.eml (which has
> a scissors line in it) with --scissors
Brandon Williams writes:
> [1]
> https://public-inbox.org/git/cagz79kygs4dvoetygx01cinrxxlcqgxovsplhmgyz8b51lz...@mail.gmail.com/
> This mail seems to counter that indicating that the "What's Cooking"
> emails should not be used as a status update.
You are the second one who were negatively
"Johannes Schindelin via GitGitGadget"
writes:
> + /*
> + * Insert after every pick. Here, fixup/squash chains
> + * are considered part of the pick, so we insert the commands *after*
> + * those chains if there are any.
> + */
> + insert_final_commands = 1;
> +
Elijah Newren writes:
> This test description looks like it was written with the originally
> observed behavior ("causes segfault") rather than the desired and now
> current behavior ("does not cause segfault"). Fix it.
GOod.
>
> Signed-off-by: Elijah Newren
> ---
>
On Fri, Aug 3, 2018 at 7:40 PM Eric Sunshine wrote:
> git diff --raw >out &&
> ! grep "" out &&
> (where is a literal TAB)
>
> Since this script has a number of instances of Git commands upstream
> pipes, it may not make sense to fix just this one. So, either a
> preparatory cleanup
Elijah Newren writes:
> A test making use of test_must_fail was failing like this:
> fatal: ambiguous argument '|': unknown revision or path not in the working
> tree.
> when the intent was to verify that a specific string was not found
> in the output of the git diff command, i.e. that grep
On Fri, Aug 3, 2018 at 5:38 PM Jeff King wrote:
> On Fri, Aug 03, 2018 at 05:33:17PM -0400, Eric Sunshine wrote:
> I suppose so. Frankly I only added that line to appease git-sh-options
> anyway.
> > Should "j" and "f" be "-j" and "-f", respectively?
> No, they're input to "rev-parse --parseopt".
Stefan Beller writes:
> - The second part of having an immediate plan is *very* nice
> to see, though I would argue that it could be improved
> by having these updates in the thread instead of summarized
> unrelated to that thread.
>
> We do not do this for now due to tooling issues, I
On Fri, Aug 3, 2018 at 5:47 PM Junio C Hamano wrote:
> Eric Sunshine writes:
> > There doesn't seem to a usage() function defined anywhere (and
> > OPTIONS_SPEC doesn't seem to be used).
>
> Isn't this using the parse-options thing git-sh-setup gives us for
> free?
Yes. I saw that git-sh-setup
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The idea of `--exec` is to append an `exec` call after each `pick`.
>
> Since the introduction of fixup!/squash! commits, this idea was extended
> to apply to "pick, possibly followed by a fixup/squash chain", i.e.
Hello there,
We have a newly compiled list of Nurses contact information.
Contact Information such Name, Company's Name, Phone Number, Fax Number, Job
Title, Email address, Complete Mailing Address, SIC code, Company revenue,
size, Web address etc.
We also have other specialist such as
"brian m. carlson" writes:
> On Thu, Aug 02, 2018 at 04:02:36PM -0700, Junio C Hamano wrote:
>> --
>> [New Topics]
>
> I had expected to see
> <20180729192803.1047050-1-sand...@crustytoothpaste.net> (the refspec @
> handling) in this list, but I
On Fri, Aug 03, 2018 at 11:40:08AM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > On Thu, Aug 02, 2018 at 04:02:36PM -0700, Junio C Hamano wrote:
> >> --
> >> [New Topics]
> >
> > I had expected to see
> >
Jeff Hostetler writes:
> Another thing to keep in mind is that the collision could be because
> of case folding (or other such nonsense) on a directory in the path.
> I mean, if someone on Linux builds a commit containing:
>
> a/b/c/D/e/foo.txt
> a/b/c/d/e/foo.txt
>
> we'll get a similar
"brian m. carlson" writes:
> On Fri, Aug 03, 2018 at 11:40:08AM -0700, Junio C Hamano wrote:
>> "brian m. carlson" writes:
>>
>> > On Thu, Aug 02, 2018 at 04:02:36PM -0700, Junio C Hamano wrote:
>> >> --
>> >> [New Topics]
>> >
>> > I had
On Fri, Aug 03, 2018 at 02:23:17PM -0400, Jeff Hostetler wrote:
> > Maybe. It might not work as ino_t. Or it might be expensive to get. Or
> > maybe it's simply impossible. I don't know much about Windows. Some
> > searching implies that NTFS does have a "file index" concept which is
> >
Junio C Hamano writes:
> "brian m. carlson" writes:
>
>> On Fri, Aug 03, 2018 at 11:40:08AM -0700, Junio C Hamano wrote:
>>> "brian m. carlson" writes:
>>>
>>> > On Thu, Aug 02, 2018 at 04:02:36PM -0700, Junio C Hamano wrote:
>>> >> --
>>> >>
On Fri, Aug 3, 2018 at 4:52 PM Jeff King wrote:
> [...]
> Let's provide a script that builds and installs the manpages
> for two commits, renders the results using "man", and diffs
> the result. Since this is time-consuming, we'll also do our
> best to avoid repeated work, keeping intermediate
Eric Sunshine writes:
>> + shift; break ;;
>> + *)
>> + usage ;;
>
> There doesn't seem to a usage() function defined anywhere (and
> OPTIONS_SPEC doesn't seem to be used).
Isn't this using the parse-options thing git-sh-setup gives us for
free?
I'm looking at the existing commit signing and verification
integration and it is all GPG specific. I'm interested in refactoring
the code to have a generic signing/verifying interface so that "drivers"
for other signing tools can be created and other signing tools can be
used (e.g. OpenBSD
1 - 100 of 121 matches
Mail list logo
