On Thu, Jan 18, 2018 at 11:18 PM, brian m. carlson
wrote:
> There are various git subcommands (among them, clone) which don't set up
> the repository (that is, they lack RUN_SETUP or RUN_SETUP_GENTLY) but
> end up needing to have information about the hash algorithm
On Fri, Jan 19, 2018 at 12:31:58PM +0700, Duy Nguyen wrote:
> On Fri, Jan 19, 2018 at 10:40 AM, brian m. carlson
> > I'm still extremely puzzled as to why this doesn't fail on Linux. If
> > it's failing in this case, it should very, very clearly fail all the
> > time we access an empty blob or an
On Fri, Jan 19, 2018 at 10:40 AM, brian m. carlson
wrote:
> On Thu, Jan 18, 2018 at 10:06:10PM -0500, Eric Sunshine wrote:
>> > I have a guess about what the problem might be. Can you try this patch
>> > and see if it fixes things?
>>
>> That does fix the crash.
Hello ,
facebook is given out 14,000,000.USD (Fourteen Million Dollars) its all about
14 Please, respond with your Unique Code (FB/BF14-13M5250UD)
using your registration email, to the Verification Department at;
dustinmoskovitz.faceb...@gmail.com
Dustin Moskovitz
Facebook Team
Copyright
There are various git subcommands (among them, clone) which don't set up
the repository (that is, they lack RUN_SETUP or RUN_SETUP_GENTLY) but
end up needing to have information about the hash algorithm in use.
Because the hash algorithm is part of struct repository and it's only
initialized in
On Thu, Jan 18, 2018 at 10:06:10PM -0500, Eric Sunshine wrote:
> > I have a guess about what the problem might be. Can you try this patch
> > and see if it fixes things?
>
> That does fix the crash. Thanks for the quick diagnosis.
>
> Can the commit message go into more detail as to why this
On January 18, 2018 10:06 PM, Eric Sunshine wrote:
> On Thu, Jan 18, 2018 at 9:47 PM, brian m. carlson
> wrote:
> > On Thu, Jan 18, 2018 at 07:15:56PM -0500, Eric Sunshine wrote:
> >> On Thu, Jan 18, 2018 at 3:55 PM, Александр Булаев
> >>
On Thu, Jan 18, 2018 at 9:47 PM, brian m. carlson
wrote:
> On Thu, Jan 18, 2018 at 07:15:56PM -0500, Eric Sunshine wrote:
>> On Thu, Jan 18, 2018 at 3:55 PM, Александр Булаев
>> wrote:
>> > I found that git 2.16.0 segfaults on clone of
On Thu, Jan 18, 2018 at 07:15:56PM -0500, Eric Sunshine wrote:
> [+cc:brian]
>
> On Thu, Jan 18, 2018 at 3:55 PM, Александр Булаев
> wrote:
> > I found that git 2.16.0 segfaults on clone of vim-colorschemes repo.
> >
> > (lldb) run
> > Process 25643 launched:
On January 18, 2018 7:11 PM, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Jan 18 2018, Stefan Beller jotted:
> > On Thu, Jan 18, 2018 at 2:42 PM, wrote:
> >> Further: there are 6 known breakages that have been reported. The
> >> perl issues relating to completion codes
On Thu, Jan 18, 2018 at 7:00 PM, Ævar Arnfjörð Bjarmason
wrote:
> Add a new section to canonically explain how remote reference pruning
> works, and how users should be careful about using it in conjunction
> with tag refspecs in particular.
>
> A subsequent commit will update
On Fri, Jan 19, 2018 at 5:32 AM, SZEDER Gábor wrote:
> On Thu, Jan 18, 2018 at 10:37 PM, Jeff King wrote:
>> On Thu, Jan 18, 2018 at 10:00:14PM +0700, Duy Nguyen wrote:
>>
>>> The test suite was run as root, no wonder why my removing write access
>>> has no
Thanks, Eric. Changes in v2:
- documented all environment variables introduced
- made test more clear by ensuring that no cookie keys are suffixes or
prefixes of others
- tested empty value
As far as I can tell, it does not seem possible that Git generates a
cookie with no equals sign (like
GIT_TRACE_CURL provides a way to debug what is being sent and received
over HTTP, with automatic redaction of sensitive information. But it
also logs data transmissions, which significantly increases the log file
size, sometimes unnecessarily. Add an option "GIT_TRACE_CURL_NO_DATA" to
allow the
When using GIT_TRACE_CURL, Git already redacts the "Authorization:" and
"Proxy-Authorization:" HTTP headers. Extend this redaction to a
user-specified list of cookies, specified through the
"GIT_REDACT_COOKIES" environment variable.
Signed-off-by: Jonathan Tan
---
On Fri, Jan 19, 2018 at 5:48 AM, Jeff King wrote:
> On Thu, Jan 18, 2018 at 05:05:46PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
>> This is partly inspired by gerrit web interface which shows diffstat
>> like this, e.g. with commit 0433d533f1 (notice the "A" column on the
>> third
[+cc:brian]
On Thu, Jan 18, 2018 at 3:55 PM, Александр Булаев
wrote:
> I found that git 2.16.0 segfaults on clone of vim-colorschemes repo.
>
> (lldb) run
> Process 25643 launched: '/usr/local/bin/git' (x86_64)
> Cloning into 'vim-colorschemes'...
> remote: Counting
On Thu, Jan 18 2018, Stefan Beller jotted:
> On Thu, Jan 18, 2018 at 2:42 PM, wrote:
>> Further: there are 6 known breakages that have been reported. The perl
>> issues relating to completion codes are being examined at present by the
>> platform support teams so
Git Merge 2018 is happening on March 8th; there will be a Contributor's
Summit the day before. Here are the details:
When: Wednesday, March 7, 2018. 10am-5pm.
Where: Convent Dels Àngels[1], Barcelona, Spain
What: Round-table discussion about Git
Who: All contributors to Git or related
On Fri, Jan 19, 2018 at 4:23 AM, Ævar Arnfjörð Bjarmason
wrote:
> Wait, isn't there a bug here in the existing --summary code, its
> documentation says it'll show information "such as creations, renames
> and mode changes".
>
> But even though your --compact-summary shows that
Re-arrange the arguments to the test_configured_prune() function used
in this test to pass the arguments to --fetch last. A subsequent
change will test for more elaborate fetch arguments, including long
refspecs. It'll be more readable to be able to wrap those on a new
line of their own.
Add a new section to canonically explain how remote reference pruning
works, and how users should be careful about using it in conjunction
with tag refspecs in particular.
A subsequent commit will update the git-remote documentation to refer
to this section, and details the motivation for writing
[WIP: This doesn't (yet) work as advertised, see further WIP note
below]
Add a --fetch-prune option to git-fetch along with fetch.pruneTags
config option. This allows for doing:
git fetch origin -p -P
Or simply:
git config fetch.prune true &&
git config fetch.pruneTags true &&
Michael Giuffrida noted that the git-remote docs were very confusing,
and upthread I said I wanted this shiny related thing in 11/11.
Along the way I fixed up fetch tests & documentation to hopefully be a
lot less confusing.
I think 1-10/11 of this makes sense for inclusion as-is (pending
review
In a subsequent commit this function will learn to test for tag
pruning, prepare for that by making space for more variables, and
making it clear that "expected" here refers to branches.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t5510-fetch.sh | 9 ++---
1 file changed,
Amend the documentation for fetch.prune, fetch..prune and
--prune to link to the recently added PRUNING section.
I'd have liked to link directly to it with "<>" from
fetch-options.txt, since it's included in git-fetch.txt (git-pull.txt
also includes it, but doesn't include that option). However
On Fri, Jan 19, 2018 at 1:57 AM, Eric Sunshine wrote:
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> @@ -188,6 +188,17 @@ and accumulating child directory counts in the parent
>> directories:
>> +--compact-summary::
>> + Output a
The "git remote prune " command uses the same machinery as "git
fetch --prune", and shares all the same caveats, but its
documentation has suggested that it'll just "delete stale
remote-tracking branches under ".
This isn't true, and hasn't been true since at least v1.8.5.6 (the
oldest version I
Add a test for the interaction between explicitly provided refspecs
and fetch.prune.
There's no point in adding this boilerplate to every combination of
unset/false/true, it's instructive and sufficient to show that no
matter if the variable is unset, false or true the refspec on the
command-line
Stop redundantly NULL-ing the last element of the refs structure,
which was retrieved via calloc() and is thus guaranteed to be
pre-NULL'd.
This code dates back to b888d61c83 ("Make fetch a builtin",
2007-09-10), where wasn't any reason to do this back then either, it's
just something left over
If the $cmdline variable contains multiple arguments they won't be
interpolated correctly since the body of the test is single quoted. I
don't know what part of test-lib.sh is expanding variables within
single-quoted strings, but interpolating this inline is the desired
behavior here.
This will
The fetch.pruneTags configuration doesn't exist yet, but will be added
in a subsequent commit. Since testing for it requires adding new
parameters to the test_configured_prune function it's easier to review
this patch first to assert that no functional changes are introduced
yet.
Signed-off-by:
Add a tag to be deleted to the fetch --prune tests. The tag is always
kept for now, which is the expected behavior, but now I can add a test
for tag pruning in a later commit.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t5510-fetch.sh | 93
> On 18 Jan 2018, at 23:40, SZEDER Gábor wrote:
>
> On Thu, Jan 18, 2018 at 10:40 PM, René Scharfe wrote:
>> Am 16.01.2018 um 18:11 schrieb SZEDER Gábor:
>>> Unfortunately, most of the changes coming from 'strbuf.cocci' don't
>>> make any sense, they appear
On Thu, Jan 18, 2018 at 2:42 PM, wrote:
> From: "Randall S. Becker"
>
> Explanation: I'm looking for comments on how best to handle the changes
> below that are needed for the NonStop port.
Ideally you'd send them as single patches, each of
On Thu, Jan 18, 2018 at 05:05:46PM +0700, Nguyễn Thái Ngọc Duy wrote:
> This is partly inspired by gerrit web interface which shows diffstat
> like this, e.g. with commit 0433d533f1 (notice the "A" column on the
> third line):
>
> Documentation/merge-config.txt | 4 +
>
From: "Randall S. Becker"
Explanation: I'm looking for comments on how best to handle the changes
below that are needed for the NonStop port. The hashmap.h and
transport-helper.c will not be included in the final patch as they have
already been communicated but did not
On Thu, Jan 18, 2018 at 10:40 PM, René Scharfe wrote:
> Am 16.01.2018 um 18:11 schrieb SZEDER Gábor:
>> Unfortunately, most of the changes coming from 'strbuf.cocci' don't
>> make any sense, they appear to be the mis-application of the "use
>> strbuf_addstr() instead of
On January 18, 2018 2:17 PM, I wrote:
> What Im trying to do is to format a patch based on a single commit from
> 2.16.0 representing the NonStop port, for review and comments to the team.
> Here is a partial (somewhat familiar) tree:
>
> * f1a482cd8 (HEAD -> randall_2.16, ituglib_release)
On Thu, Jan 18, 2018 at 10:37 PM, Jeff King wrote:
> On Thu, Jan 18, 2018 at 10:00:14PM +0700, Duy Nguyen wrote:
>
>> The test suite was run as root, no wonder why my removing write access
>> has no effect. I got the test to pass with this, but then it fails
>> with
>>
>> Can't
On Thu, 18 Jan 2018 09:56:50 +0100
Christian Couder wrote:
> I am still not very happy with fetch_object() not returning anything.
> I wonder what happens when that function is used to fetch from a repo
> that cannot provide the requested object.
My idea was to save
Dear Git users,
It is my pleasure to announce that Git for Windows 2.16.0(2) is available from:
https://git-for-windows.github.io/
Changes since Git for Windows v2.15.1(2) (November 30th 2017)
Git for Windows now has a new homepage: https://gitforwindows.org/ (it
is still graciously
On Thu, Jan 18, 2018 at 2:08 PM, Philip Oakley wrote:
> From: "Jacob Keller"
>>
>> On Thu, Jan 18, 2018 at 10:36 AM, Stefan Beller
>> wrote:
>>>
>>> Jake suggested using "x false" instead of "edit" for some corner cases.
>>>
>>>
On Thu, Jan 18, 2018 at 2:00 PM, Johannes Schindelin
wrote:
>> + TODO_STOP,
>
> I see that your original idea was "stop", but then you probably realized
> that there would be no good abbreviation for that, and changed your mind.
>
> Personally, I would have called
From: "Jacob Keller"
On Thu, Jan 18, 2018 at 10:36 AM, Stefan Beller
wrote:
Jake suggested using "x false" instead of "edit" for some corner cases.
I do prefer using "x false" for all kinds of things such as stopping
before a commit (edit only
From: "Johannes Schindelin"
This one is a bit tricky to explain, so let's try with a diagram:
C
/ \
A - B - E - F
\ /
D
To illustrate what this new mode is all about, let's consider what
happens upon `git rebase -i --recreate-merges B`, in
Hi Stefan,
On Thu, 18 Jan 2018, Stefan Beller wrote:
> Jake suggested using "x false" instead of "edit" for some corner cases.
>
> I do prefer using "x false" for all kinds of things such as stopping
> before a commit (edit only let's you stop after a commit), and the
> knowledge that "x false"
On Thu, Jan 18, 2018 at 1:36 PM, Johannes Schindelin
wrote:
> Good idea! I would rather do it as an introductory patch (that only
> converts the existing list).
That makes sense.
>
> As to `merge`: it is a bit more complicated ;-)
>
> m, merge ( | "..." )
Friendly ping on this series now that 2.16 is out :) Is there anything
in this series (up to 3/3, 4/3 can be dropped now that Duy fixed it in
a nicer way) that still needs updating? It fixes a few bugs in split
index mode with submodules/worktrees, so it would be nice to get this
reviewed/merged.
Am 16.01.2018 um 18:11 schrieb SZEDER Gábor:
> Unfortunately, most of the changes coming from 'strbuf.cocci' don't
> make any sense, they appear to be the mis-application of the "use
> strbuf_addstr() instead of strbuf_addf() to add a single string" rule:
>
>- strbuf_addf(_repo,
From: "Johannes Schindelin"
The sequencer just learned a new commands intended to recreate branch
structure (similar in spirit to --preserve-merges, but with a
substantially less-broken design).
Let's allow the rebase--helper to generate todo lists making use of
On Thu, Jan 18, 2018 at 10:00:14PM +0700, Duy Nguyen wrote:
> The test suite was run as root, no wonder why my removing write access
> has no effect. I got the test to pass with this, but then it fails
> with
>
> Can't write .prove (Permission denied) at
> /usr/share/perl/5.22/App/Prove.pm
Hi Stefan,
On Thu, 18 Jan 2018, Stefan Beller wrote:
> Up to now each command took a commit as its first argument and ignored
> the rest of the line (usually the subject of the commit)
>
> Now that we have commands that take different arguments, clarify each
> command by giving the argument
>> Same for the test here, I can't figure out why this is necessary in
>> this patch as opposed to the patch which first introduced the
>> refs/rewritten/ refs.
>
> Woops. This was its own commit, and must have been accidentally squashed
> during one of my rebases. Will re-introduce it;
Yep that
Hi Jake,
On Thu, 18 Jan 2018, Jacob Keller wrote:
> On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin
> wrote:
> > In the previous patches, we implemented the basic functionality of the
> > `git rebase -i --recreate-merges` command, in particular the `merge`
> >
On Thu, Jan 18, 2018 at 1:24 PM, Philip Oakley wrote:
> From: "Jacob Keller"
>
>> On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin
>> wrote:
>>>
>>> This commit implements the commands to label, and to reset to, given
On Thu, Jan 18, 2018 at 1:22 PM, Johannes Schindelin
wrote:
>> Would it be possible to open the editor with the supplied text when
>> there's no commit? The text after must be oneline only..
>
> I actually want to avoid that because my main use case is
From: "Jacob Keller"
On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin
wrote:
This commit implements the commands to label, and to reset to, given
revisions. The syntax is:
label
reset
As a convenience shortcut, also
On Thu, Jan 18 2018, Nguyễn Thái Ngọc Duy jotted:
> This is partly inspired by gerrit web interface which shows diffstat
> like this, e.g. with commit 0433d533f1 (notice the "A" column on the
> third line):
>
>
> Documentation/merge-config.txt | 4 +
> builtin/merge.c
Hi Jake,
On Thu, 18 Jan 2018, Jacob Keller wrote:
> On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin
> wrote:
> > This patch is part of the effort to reimplement `--preserve-merges` with
> > a substantially improved design, a design that has been developed in the
On Thu, Jan 18, 2018 at 1:13 PM, Johannes Schindelin
wrote:
> Hi Jake,
>
> On Thu, 18 Jan 2018, Jacob Keller wrote:
>
>> On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin
>> wrote:
>> > This commit implements the commands to label, and
On Thu, Jan 18, 2018 at 10:36 AM, Stefan Beller wrote:
> Jake suggested using "x false" instead of "edit" for some corner cases.
>
> I do prefer using "x false" for all kinds of things such as stopping
> before a commit (edit only let's you stop after a commit), and the
>
On Thu, Jan 18, 2018 at 10:36 AM, Stefan Beller wrote:
> Up to now each command took a commit as its first argument and ignored
> the rest of the line (usually the subject of the commit)
>
> Now that we have commands that take different arguments, clarify each
> command by
Hi Jake,
On Thu, 18 Jan 2018, Jacob Keller wrote:
> On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin
> wrote:
> > This commit implements the commands to label, and to reset to, given
> > revisions. The syntax is:
> >
> > label
> > reset
> >
> >
On January 18, 2018 3:56 PM, Aleks wrote:
> I found that git 2.16.0 segfaults on clone of vim-colorschemes repo.
Just tested on NonStop NSE and works fine here. Just an FYI now that we're on
2.16.0.
Cheers,
Randall
-- Brief whoami:
NonStop developer since approximately
I found that git 2.16.0 segfaults on clone of vim-colorschemes repo.
See the log below.
alexbool@alexbool-osx ~/Documents> lldb -- git clone
https://github.com/flazz/vim-colorschemes.git
(lldb) target create "git"
Current executable set to 'git' (x86_64).
(lldb) settings set -- target.run-args
On 2018-01-18 09:47 AM, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Jan 18 2018, raikrishna jotted:
>
>> Hi Team,
>>
>> I have an urgent requirement to install Git client for Aix 6 and 7, could
>> you please help send me or navigate me to the correct url.
>> My present infrastructure comprise of
Hi all,
What Im trying to do is to format a patch based on a single commit from
2.16.0 representing the NonStop port, for review and comments to the team.
Here is a partial (somewhat familiar) tree:
* f1a482cd8 (HEAD -> randall_2.16, ituglib_release) NonStop port changes
for git 2.16.0.
|\
|
On Thu, Jan 18, 2018 at 5:05 AM, Nguyễn Thái Ngọc Duy wrote:
> [...]
> The new option --compact-summary implements this with a tweak to support
> mode change, which is shown in --summary too.
>
> For mode changes, executable bit is denoted as "M+x" or "M-x" when it's
> added or
Up to now each command took a commit as its first argument and ignored
the rest of the line (usually the subject of the commit)
Now that we have commands that take different arguments, clarify each
command by giving the argument list.
Signed-off-by: Stefan Beller
---
I thought of writing a reply, but instead I wrote it in patch form.
Stefan Beller (2):
[DO NOT APPLY, but squash?] git-rebase--interactive: clarify arguments
[DO NOT APPLY, but improve?] rebase--interactive: introduce "stop"
command
git-rebase--interactive.sh | 23
Jake suggested using "x false" instead of "edit" for some corner cases.
I do prefer using "x false" for all kinds of things such as stopping
before a commit (edit only let's you stop after a commit), and the
knowledge that "x false" does the least amount of actions behind my back.
We should have
On Wed, Jan 17, 2018 at 7:34 PM, Jonathan Tan wrote:
> GIT_TRACE_CURL provides a way to debug what is being sent and received
> over HTTP, with automatic redaction of sensitive information. But it
> also logs data transmissions, which significantly increases the log file
On Wed, Jan 17, 2018 at 7:34 PM, Jonathan Tan wrote:
> When using GIT_TRACE_CURL, Git already redacts the "Authorization:" and
> "Proxy-Authorization:" HTTP headers. Extend this redaction to a
> user-specified list of cookies, specified through the
> "GIT_REDACT_COOKIES"
On Thu, 18 Jan 2018 15:50:52 +0100
Patryk Obara wrote:
> Patch 1 is not directly related to object_id conversions but helped with
> debugging t5540, which kept failing on master for me (spoiler: it was Fedora
> fault). It helps with debugging of failing git-push over
On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin
wrote:
> Once upon a time, I dreamt of an interactive rebase that would not
> flatten branch structure, but instead recreate the commit topology
> faithfully.
>
> My original attempt was --preserve-merges, but that
On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin
wrote:
> In the previous patches, we implemented the basic functionality of the
> `git rebase -i --recreate-merges` command, in particular the `merge`
> command to create merge commits in the sequencer.
>
> The
On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin
wrote:
> This patch is part of the effort to reimplement `--preserve-merges` with
> a substantially improved design, a design that has been developed in the
> Git for Windows project to maintain the dozens of
[adding Chris to the Cc list - this is about the awful ext3 data=ordered
behavior of syncing the whole file system data and metadata on each
fsync]
On Wed, Jan 17, 2018 at 03:57:53PM -0800, Linus Torvalds wrote:
> On Wed, Jan 17, 2018 at 3:52 PM, Theodore Ts'o wrote:
> >
> > Well,
On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin
wrote:
> This commit implements the commands to label, and to reset to, given
> revisions. The syntax is:
>
> label
> reset
>
> As a convenience shortcut, also to improve readability of the
Hi, just following up on this bug report. I have not heard back. Is
there additional information that's needed? Is there a better place to
file bug reports?
Thanks
On Sat, Jan 6, 2018 at 5:45 PM, Stephen R Guglielmo
wrote:
> Hi all,
>
> I've noticed an issue regarding the
This one is a bit tricky to explain, so let's try with a diagram:
C
/ \
A - B - E - F
\ /
D
To illustrate what this new mode is all about, let's consider what
happens upon `git rebase -i --recreate-merges B`, in particular to
the commit `D`. In the default mode, the new
In the previous patches, we implemented the basic functionality of the
`git rebase -i --recreate-merges` command, in particular the `merge`
command to create merge commits in the sequencer.
The interactive rebase is a lot more these days, though, than a simple
cherry-pick in a loop. For example,
Once upon a time, this here developer thought: wouldn't it be nice if,
say, Git for Windows' patches on top of core Git could be represented as
a thicket of branches, and be rebased on top of core Git in order to
maintain a cherry-pick'able set of patch series?
The original attempt at an answer
Just like with regular `pick` commands, if we are trying to recreate a
merge commit, we now test whether the parents of said commit match HEAD
and the commits to be merged, and fast-forward if possible.
This is not only faster, but also avoids unnecessary proliferation of
new objects.
The sequencer just learned a new commands intended to recreate branch
structure (similar in spirit to --preserve-merges, but with a
substantially less-broken design).
Let's allow the rebase--helper to generate todo lists making use of
these commands, triggered by the new --recreate-merges option.
In the upcoming commits, we will teach the sequencer to recreate merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label`,
Once upon a time, I dreamt of an interactive rebase that would not
flatten branch structure, but instead recreate the commit topology
faithfully.
My original attempt was --preserve-merges, but that design was so
limited that I did not even enable it in interactive mode.
Subsequently, it *was*
On Thu, Jan 18, 2018 at 08:36:32PM +0700, Duy Nguyen wrote:
> On Thu, Jan 18, 2018 at 8:29 PM, Jeff King wrote:
> > On Thu, Jan 18, 2018 at 07:47:50PM +0700, Duy Nguyen wrote:
> >
> >> I may need help getting that log (or even better the trash directory
> >> of t1700). I tried -m32
Convert the declaration and definition of pretend_sha1_file to use
struct object_id and adjust all usages of this function.
Signed-off-by: Patryk Obara
---
blame.c | 2 +-
cache.h | 3 ++-
sha1_file.c | 8
3 files changed, 7 insertions(+), 6 deletions(-)
Convert the declaration and definition of hash_sha1_file to use
struct object_id and adjust all function calls.
Signed-off-by: Patryk Obara
---
apply.c | 4 ++--
builtin/index-pack.c | 3 +--
builtin/replace.c| 2 +-
Convert the definitions and declarations of commit_tree and
commit_tree_extended to use struct object_id and adjust all usages of
these functions.
Signed-off-by: Patryk Obara
---
builtin/am.c | 4 ++--
builtin/commit-tree.c | 4 ++--
builtin/commit.c | 5
This patch series puts some mundane groundwork for experimentation with a new
hashing algorithm in git-hash-object.
Some time has passed since my last patches, and I see, that work on new
hashing algorithm progressed nicely since then:
* brian m. carlson implemented vtable for hash algorithm
Convert the definition and declaration of write_notes_tree to
struct object_id and adjust usage of this function.
Additionally, improve style of small part of this function, as old
formatting made it hard to understand at glance what this part of
code is doing.
Signed-off-by: Patryk Obara
Convert the definition and declarations of combine_notes_* functions
to struct object_id and adjust usage of these functions.
Signed-off-by: Patryk Obara
---
notes.c | 46 +++---
notes.h | 25 +++--
2 files
The penalty of 5 makes clang-format very eager to put even short type
declarations (e.g. "extern int") into a separate line, even when
breaking parameters list is sufficient.
Signed-off-by: Patryk Obara
---
.clang-format | 2 +-
1 file changed, 1 insertion(+), 1
Convert the definition and declaration of write_sha1_file to
struct object_id and adjust usage of this function.
This commit also converts static function write_sha1_file_prepare, as it
is closely related.
Replace sha1_to_hex, hashcpy and hashclr with their oid equivalents
wherever possible.
When git push fails due to server-side WebDAV error, it's not easy to
point to the main culprit. Additional information about exact cURL
error and HTTP server response is helpful for debugging purpose.
New error log helped me pinpoint failing test t5540-http-push-webdav
to a missing Apache
Convert the declaration of struct sha1_stat. Adjust all usages of this
struct and replace hash{clr,cmp,cpy} with oid{clr,cmp,cpy} wherever
possible.
Remove macro EMPTY_BLOB_SHA1_BIN, as it's no longer used.
Signed-off-by: Patryk Obara
---
cache.h
1 - 100 of 132 matches
Mail list logo