On Thu, Aug 2, 2018 at 9:39 PM Jeff King wrote:
>
> On Sun, Jul 29, 2018 at 05:46:17PM +0200, Duy Nguyen wrote:
>
> > tOn Sun, Jul 29, 2018 at 5:36 PM Nguyễn Thái Ngọc Duy
> > wrote:
> > >
> > > These extra comments should be make it easier to understand how to use
> > > locks in pack-objects
With the new cache-tree, we could mostly avoid I/O (due to odb access)
the code mostly becomes a loop of "check this, check that, add the
entry to the index". We could skip a couple checks in this giant loop
to go faster:
- We know here that we're copying entries from the source index to the
This is a minor update to address Ben's comments and add his
measurements in the commit message of 2/4 for the record.
I've also checked about the lookahead thing in unpack_trees() to see
if we accidentally break something there, which is my biggest worry.
See [1] and [2] for context, but I
From: Duy Nguyen
In order to merge one or many trees with the index, unpack-trees code
walks multiple trees in parallel with the index and performs n-way
merge. If we find out at start of a directory that all trees are the
same (by comparing OID) and cache-tree happens to be available for
that
We're going to optimize unpack_trees() a bit in the following
patches. Let's add some tracing to measure how long it takes before
and after. This is the baseline ("git checkout -" on gcc.git, 80k
files on worktree)
0.018239226 s: read cache .git/index
0.052541655 s: preload index
This is a micro optimization that probably only shines on repos with
deep directory structure. Instead of allocating and freeing a new
cache_entry in every iteration, we reuse the last one and only update
the parts that are new each iteration.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by:
Reviewer bandwidth is limited, so let's have the machine of the
(potentially new) contributor warn about issues with the code by default.
As setting DEVELOPER, the compiler is stricter and we may run into problems
on some architectures. But packagers of said platforms are knowledgeable
enough to
Reviewer bandwidth is limited, so let's have the machine of the
(potentially new) contributor warn about issues with the code by default.
As setting DEVELOPER, the compiler is stricter and we may run into problems
on some architectures. But packagers of said platforms are knowledgeable
enough to
Try it out via
./git-format-patch --mark-moved 15ef69314d^..15ef69314d
to see if you like it.
This separates the coloring decision from the detection of moved lines.
When giving --mark-moved, move detection is still performed and the output
markers are adjusted to */~ for new and old code.
This will prove useful in range-diff in a later patch as we will be able to
differentiate between adding a new file (that line is starting with +++
and then the file name) and regular new lines.
It could also be useful for experimentation in new patch formats, i.e.
we could teach git to emit
This just renames a variable to make the next patch easier to review.
Signed-off-by: Stefan Beller
---
diff.c | 28 ++--
diff.h | 2 +-
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/diff.c b/diff.c
index 2e711809700..d3829c7d086 100644
--- a/diff.c
This builds on top of sb/range-diff-colors, which builds on js/range-diff.
As Thomas seemed happy with the range-diff and said
"and fwiw I didn't think there's anything major that needs to be addressed."
I found it reasonable to build more on top of those series.
[1]
This change itself only changes the internal communication and should
have no visible effect to the user. We instruct the diff code that produces
the inner diffs to use X, Y, Z instead of the usual markers for new, old
and context lines
Signed-off-by: Stefan Beller
---
range-diff.c | 15
The range-diff coloring is a bit fuzzy when it comes to special lines of
a diff, such as indicating new and old files with +++ and ---, as it
would pickup the first character and interpret it for its coloring, which
seems annoying as in regular diffs, these lines are colored bold via
By providing a string as the first part of the emission we can extend
it later more easily.
While at it, document emit_line_0.
Signed-off-by: Stefan Beller
---
diff.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/diff.c b/diff.c
index
Factoring out code that determines color for both the new and old code
even saves some lines, though minuscule. However we introduce an offset
computation in the color array.
Signed-off-by: Stefan Beller
---
diff.c | 88 +-
1 file changed,
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
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
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
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 returned
non-zero. Fix the test
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
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 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
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
5. Compare these commits with
Stefan Beller writes:
> * 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
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
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
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
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 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
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
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: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".
On Fri, Aug 03, 2018 at 05:33:17PM -0400, Eric Sunshine wrote:
> > +OPTIONS_SPEC="\
> > +doc-diff [-- diff options]
>
> Should this be?
>
> doc-diff [] [-- ]
I suppose so. Frankly I only added that line to appease git-sh-options
anyway.
> > +--
> > +j parallel argument to pass to
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
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
On Fri, Aug 3, 2018 at 1:07 PM Junio C Hamano wrote:
>
> 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
"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;
> +
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
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:
> >>> >>
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 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
> >
"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
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
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
> >
"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
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
"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.
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
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 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 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
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, 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
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 --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
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
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
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
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
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
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
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 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
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
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
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
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
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 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
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
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
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:
> 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
> > 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
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
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
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
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
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 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 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
>
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:
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 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, 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
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
> >
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 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...
> > +
> > +/*
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
> >
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
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
1 - 100 of 121 matches
Mail list logo
