Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-43.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub is
On Mon, Sep 17, 2018 at 5:21 AM, Jeff King wrote:
> On Sun, Sep 16, 2018 at 03:15:20AM -0700, David Aguilar wrote:
>> The "Git Cola" project[1][2] provides two fully-featured Git porcelains,
>> "git-cola" and "git-dag". The DAG tool is never referred to as a
>> separate project, so shouldn't be
Hi,
On Windows, when using multiple workspaces and git 2.19.0.windows.1,
'git show HEAD' and 'git show head' return different results when
executed from a secondary workspace (the one without the .git
directory).
'git show HEAD' shows the HEAD of the current workspace, while git
show head shows t
On Sep-16-18, Jonathan Nieder wrote:
On Mon, Sep 17, 2018 at 03:27:21AM +0200, Chris Coutinho wrote:
On Sep-16-18, Jonathan Nieder wrote:
Chris Coutinho wrote:
Currently my gitconfig contains the following line:
sendemail.smtpserveroption=-a
Whereas, the following results in an 'ac
perusing "man git-clone" and, from the first part of the OPTIONS
section, it's not immediately obvious what the difference is between
using --no-local versus --no-hardlinks when cloning a local repo. both
seem to suggest that the local git transport mechanism will be used,
so what is the differ
On Sep-16-18, Jonathan Nieder wrote:
On Mon, Sep 17, 2018 at 03:27:21AM +0200, Chris Coutinho wrote:
On Sep-16-18, Jonathan Nieder wrote:
Chris Coutinho wrote:
Currently my gitconfig contains the following line:
sendemail.smtpserveroption=-a
Whereas, the following results in an 'ac
On Fri, Sep 14, 2018 at 5:03 PM Matthew DeVore wrote:
>
> This fixes various places where the ordering was obviously wrong and it
> was either related to other patches in this patchset or was easy
> find with grep.
>
> Signed-off-by: Matthew DeVore
> ---
The clause about "related to other patches
On Mon, Sep 17 2018, Nikola Milekic wrote:
> Hi,
>
> On Windows, when using multiple workspaces and git 2.19.0.windows.1,
> 'git show HEAD' and 'git show head' return different results when
> executed from a secondary workspace (the one without the .git
> directory).
>
> 'git show HEAD' shows th
Ups, my bad, didn't realize that. Apologies for spamming. Would love
to help but unfortunately I have no C background.
On Mon, Sep 17, 2018 at 3:23 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Mon, Sep 17 2018, Nikola Milekic wrote:
>
> > Hi,
> >
> > On Windows, when using multiple workspaces and gi
On Sun, Sep 16, 2018 at 12:56:04AM -0700, David Aguilar wrote:
> Combining changes is inherently file-format specific, and I suspect
> that native authoring tools are best used in those scenarios.
> Maybe LFS can help deal with binary conflicts by having short and sweet
> ways to grab the "base", "
On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote:
> In the hypothetical git-annex-like case (simplifying a bit for the
> purposes this explanation), for every FILE in your tree you have a
> corresponding FILE.lock file, but it's not a boolean, but a log of who's
> asked for l
On Sun, Sep 16, 2018 at 03:05:48PM -0700, Jonathan Nieder wrote:
> Hi,
>
> On Sun, Sep 16, 2018 at 11:17:27AM -0700, John Austin wrote:
> > Taylor Blau wrote:
>
> >> Right, though this still subjects the remote copy to all of the
> >> difficulty of packing large objects (though Christian's work to
Jeff King writes:
> (Also, to be clear, this is all _only_ about "Git Cola". The "git-cola"
> command is explicitly OK in the policy because that's how commands
> work).
These match my understanding. Thanks for spelling them out. That
project is an example of being a good ecosystem citizen who
On September 17, 2018 9:55 AM Taylor Blau wrote:
> On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > In the hypothetical git-annex-like case (simplifying a bit for the
> > purposes this explanation), for every FILE in your tree you have a
> > corresponding FILE.lock file,
Good Day
I am Matheus Gustavo The Director Account Services Operations Unit in my BANK,
l Am contacting you for an urgent beneficial transaction, I have the
opportunity of transferring Nine Million Three Hundred Thousand United States
Dollars( $9.3m) from an account that belong to one of our
Introduce a helper function named is_writing_gitmodules_ok() to verify
that the .gitmodules file is safe to write.
The function name follows the scheme of is_staging_gitmodules_ok().
The two symbolic constants GITMODULES_INDEX and GITMODULES_HEAD are used
to get help from the C preprocessor in pr
Use the 'submodule--helper config' command in git-submodules.sh to avoid
referring explicitly to .gitmodules by the hardcoded file path.
This makes it possible to access the submodules configuration in a more
controlled way.
Signed-off-by: Antonio Ospite
---
git-submodule.sh | 8
1 fil
Tests 5 and 7 in t/t7411-submodule-config.sh add two commits with
invalid lines in .gitmodules but then only the second commit is removed.
This may affect future subsequent tests if they assume that the
.gitmodules file has no errors.
Remove both the commits as soon as they are not needed anymore
When the .gitmodules file is not available in the working tree, try
using the content from the index and from the current branch. This
covers the case when the file is part of the repository but for some
reason it is not checked out, for example because of a sparse checkout.
This makes it possible
Introduce a new config_set_in_gitmodules_file_gently() function to write
config values to the .gitmodules file.
This is in preparation for a future change which will use the function
to write to the .gitmodules file in a more controlled way instead of
using "git config -f .gitmodules".
The purpos
Tests 5 and 6 check for the effects of the same commit, merge the two
tests to make it more straightforward to clean things up after the test
has finished.
The cleanup will be added in a future commit.
Signed-off-by: Antonio Ospite
---
t/t7411-submodule-config.sh | 18 +-
1 file
Add a new print_config_from_gitmodules() helper function to print values
from .gitmodules just like "git config -f .gitmodules" would.
This will be used by a new submodule--helper subcommand to be able to
access the .gitmodules file in a more controlled way.
Signed-off-by: Antonio Ospite
---
su
In t/t7506-status-submodule.sh at some point a new scenario is set up to
test different things, in particular new submodules are added which are
meant to completely replace the previous ones.
However before calling the "git submodule add" commands for the new
layout, the .gitmodules file is remove
Add a new 'config' subcommand to 'submodule--helper', this extra level
of indirection makes it possible to add some flexibility to how the
submodules configuration is handled.
Signed-off-by: Antonio Ospite
---
builtin/submodule--helper.c | 14 ++
t/t7411-submodule-config.sh | 27
Hi,
this series teaches git to try and read the .gitmodules file from the
index (:.gitmodules) or from the current branch (HEAD:.gitmodules) when
the file is not readily available in the working tree.
This can be used, together with sparse checkouts, to enable submodule
usage with programs like v
On 9/16/2018 3:17 AM, Eric Sunshine wrote:
On Fri, Sep 14, 2018 at 7:29 PM Ramsay Jones
wrote:
At one time, the POSIX standard required the type used to represent
a thread handle (pthread_t) be an arithmetic type. This is no longer
the case, probably because different platforms used to regul
On 9/15/2018 6:02 AM, Duy Nguyen wrote:
default:
if (*ext < 'A' || 'Z' < *ext)
return error("index uses %.4s extension, which we do not
understand",
@@ -1889,6 +1893,11 @@ static size_t estimate_cache_size(size_t ondisk_size,
unsigned int e
"Robert P. J. Day" writes:
> perusing "man git-clone" and, from the first part of the OPTIONS
> section, it's not immediately obvious what the difference is between
> using --no-local versus --no-hardlinks when cloning a local repo. both
> seem to suggest that the local git transport mechanism
On Mon, Sep 17 2018, Taylor Blau wrote:
> On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> In the hypothetical git-annex-like case (simplifying a bit for the
>> purposes this explanation), for every FILE in your tree you have a
>> corresponding FILE.lock file, but it's
"brian m. carlson" writes:
> On Fri, Sep 14, 2018 at 02:56:36PM -0700, Junio C Hamano wrote:
>> * bc/hash-independent-tests (2018-09-13) 12 commits
>> - t5318: use test_oid for HASH_LEN
>> - t1407: make hash size independent
>> - t1406: make hash-size independent
>> - t1405: make hash size in
Antonio Ospite writes:
> I did send a v4 addressing this:
> https://public-inbox.org/git/20180824132951.8000-1-...@ao2.it/
>
> In case you missed it I might as well send a v5 with some minor
> cosmetic touches suggested by Ævar:
> https://public-inbox.org/git/87wosfesxl@evledraar.gmail.com/
For the reasons explained in the "commit-graph write: add progress
output" commit leading up to this one, emit progress on "commit-graph
verify". Since e0fd51e1d7 ("fsck: verify commit-graph", 2018-06-27)
"git fsck" has called this command if core.commitGraph=true, but
there's been no progress outp
Before this change the "commit-graph write" command didn't report any
progress. On my machine this command takes more than 10 seconds to
write the graph for linux.git, and around 1m30s on the
2015-04-03-1M-git.git[1] test repository (a test case for a large
monorepository).
Furthermore, since the
Micro change since v2: Missing _() in 2/2 pointed out by Duy.
Ævar Arnfjörð Bjarmason (2):
commit-graph write: add progress output
commit-graph verify: add progress output
builtin/commit-graph.c | 5 ++--
builtin/gc.c | 3 +-
commit-graph.c | 65 ++
Tim Schumacher writes:
> On 08.09.18 15:28, Duy Nguyen wrote:
>> On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:
>>> + /*
>>> +* It could be an alias -- this works around the insanity
>>> * of overriding "git log" with "git show" by having
>>
On Mon, Sep 17, 2018 at 05:00:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > 2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z
> > together." This isn't possible in Git LFS today with the existing "git
> > lfs lock" command (I had to check, but it takes only _one_ filename
Taylor Blau wrote:
> On Sun, Sep 16, 2018 at 03:05:48PM -0700, Jonathan Nieder wrote:
> > On Sun, Sep 16, 2018 at 11:17:27AM -0700, John Austin wrote:
> > > Taylor Blau wrote:
Right, though this still subjects the remote copy to all of the
difficulty of packing large objects (though Chri
On Mon, Sep 17, 2018 at 4:55 PM Ben Peart wrote:
> On 9/15/2018 6:02 AM, Duy Nguyen wrote:
>
> >> default:
> >> if (*ext < 'A' || 'Z' < *ext)
> >> return error("index uses %.4s extension, which we
> >> do not understand",
> >> @@ -1889,6 +1893,11
On September 17, 2018 11:58 AM, Taylor Blau wrote:
> On Mon, Sep 17, 2018 at 05:00:10PM +0200, Ævar Arnfjörð Bjarmason
> wrote:
> > > 2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z
> > > together." This isn't possible in Git LFS today with the existing
"git
> > > lfs loc
Nguyễn Thái Ngọc Duy writes:
> This function calls do_diff_cache() which eventually needs to set this
> "istate" to unpack_options->src_index (*). This is an unfortunate fact
> that unpack_trees() _will_ destroy src_index so we can't really pass a
Wasn't the whole point of introducing src_index
On 9/15/2018 6:22 AM, Duy Nguyen wrote:
+index.threads::
+ Specifies the number of threads to spawn when loading the index.
+ This is meant to reduce index load time on multiprocessor machines.
+ Specifying 0 or 'true' will cause Git to auto-detect the number of
+ CPU's
On 17/09/18 15:15, Ben Peart wrote:
>
>
> On 9/16/2018 3:17 AM, Eric Sunshine wrote:
>> On Fri, Sep 14, 2018 at 7:29 PM Ramsay Jones
>> wrote:
>>> At one time, the POSIX standard required the type used to represent
>>> a thread handle (pthread_t) be an arithmetic type. This is no longer
>>> t
On Mon, Sep 17, 2018 at 3:55 AM wrote:
>
> The following:
>
> git add -u :\(glob,attr:-someAttr\):src/**
>
> Produces an error that, according to the source code, should never be visible
> to the user. This attribute/pathspec *should* be supported according to the
> documentation provided by git
Matthew DeVore wrote:
> Subject: t/*: fix pipe placement and remove \'s
>
> Where ever there was code in the tests like this:
>
> foo \
> | bar
Language nits:
- s/Where ever/Wherever/
- Git's commit messages use the present tense to describe the existing
previous state of th
Nguyễn Thái Ngọc Duy writes:
> The current naming convention for 'struct repository *' is 'r' for
> temporary variables or arguments. I did not notice this. Since we're
> updating blame.c again in the next patch, let's fix this.
It is likely that we end up having to refer to an in-core reposito
On 9/15/2018 6:24 AM, Duy Nguyen wrote:
On Sat, Sep 15, 2018 at 12:22 PM Duy Nguyen wrote:
@@ -1944,6 +1993,26 @@ int do_read_index(struct index_state *istate, const char
*path, int must_exist)
istate->cache = xcalloc(istate->cache_alloc, sizeof(*istate->cache));
istate->i
David Aguilar writes:
> While I do see the utility, it would be just as easy to configure a 2nd
> and 3rd variant of the same difftool and use those as needed instead.
>
> "git difftool -t ccdiff2" or "-t ccdiff3" is the simplest, and there's
> nothing stopping the user from creating aliases to s
On Mon, Sep 17, 2018 at 6:26 PM Ben Peart wrote:
>
>
>
> On 9/15/2018 6:22 AM, Duy Nguyen wrote:
> >> +index.threads::
> >> + Specifies the number of threads to spawn when loading the index.
> >> + This is meant to reduce index load time on multiprocessor machines.
> >> + Specify
On Mon, Sep 17, 2018 at 6:25 PM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > This function calls do_diff_cache() which eventually needs to set this
> > "istate" to unpack_options->src_index (*). This is an unfortunate fact
> > that unpack_trees() _will_ destroy src_index so we ca
On 17/09/18 17:27, Ramsay Jones wrote:
>
>
> On 17/09/18 15:15, Ben Peart wrote:
>>
>>
>> On 9/16/2018 3:17 AM, Eric Sunshine wrote:
>>> On Fri, Sep 14, 2018 at 7:29 PM Ramsay Jones
>>> wrote:
At one time, the POSIX standard required the type used to represent
a thread handle (pthre
Ævar Arnfjörð Bjarmason wrote:
> There's surely other aspects of that square peg of large file tracking
> not fitting the round hole of file locking, the point of my write-up was
> not that *that* solution is perfect, but there's prior art here that's
> very easily adopted to distributed locking if
Nguyễn Thái Ngọc Duy writes:
> This is about mixing "git add -p" and "git commit -a" (or "git commit
> ") where you may accidentally lose staged changes. After the
> discussion with Jonathan, I'm going with a bit different approach than
> v1, this behavior now becomes default, and if the user wa
Duy Nguyen writes:
> On Sat, Sep 15, 2018 at 12:22 PM Duy Nguyen wrote:
>> Wait there's no way to disable this parallel reading? Does not sound
>> right. And if ordinary numbers mean the number of threads then 0
>> should mean no threading. Auto detection could have a new keyword,
>> like 'auto
On Mon, Sep 17 2018, Joey Hess wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> There's surely other aspects of that square peg of large file tracking
>> not fitting the round hole of file locking, the point of my write-up was
>> not that *that* solution is perfect, but there's prior art here that's
>
On 9/15/2018 6:31 AM, Duy Nguyen wrote:
On Wed, Sep 12, 2018 at 6:18 PM Ben Peart wrote:
This patch helps address the CPU cost of loading the index by creating
multiple threads to divide the work of loading and converting the cache
entries across all available CPU cores.
It accomplishes th
On Mon, Sep 17, 2018 at 7:09 PM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > This is about mixing "git add -p" and "git commit -a" (or "git commit
> > ") where you may accidentally lose staged changes. After the
> > discussion with Jonathan, I'm going with a bit different approac
Duy Nguyen writes:
> But it _is_ available now. If you need it, you write the extension
> out.
Are you arguing for making it omitted when it is not needed (e.g.
small enough index file)? IOW, did you mean "If you do not need it,
you do not write it out" by the above?
I do not think overhead of
Contact Account Officer For Claims:
Mr Eric Elliot Francis
Email: claim...@gmail.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
On Mon, Sep 17, 2018 at 7:31 PM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > But it _is_ available now. If you need it, you write the extension
> > out.
>
> Are you arguing for making it omitted when it is not needed (e.g.
> small enough index file)? IOW, did you mean "If you do not need i
[Sorry about the double send in private, forgot to CC the list]
On Mon, Sep 17 2018, Duy Nguyen wrote:
> Brandon, b0db704652[...]
I noticed a few days ago that CC's to bmw...@google.com bounce. Has he
left Google, and if so is he still interested in being CC'd on Git stuff
(maybe he'll chime i
Jeff King writes:
>> > What's the donness of this one?
>> > cf. <20180717201348.gd26...@sigill.intra.peff.net>
>>
>> This topic has stayed in 'pu' for a long time. I thought it was
>> concluded that this was a good change? Jeff, Jonathan?
>
> I read over the thread again. I don't think I actua
On Mon, Sep 17, 2018 at 10:51 AM Ævar Arnfjörð Bjarmason
wrote:
>
> Aside from that particular address bouncing [...] it would be nice if git
> {format-patch,send-email,check-contacts} & the .mailmap format would
> support and understand some way to map addresses to
> e.g. nore...@example.com, and
On Mon, Sep 17, 2018 at 07:29:26PM +0200, Duy Nguyen wrote:
> > On the other hand, if I am keeping some change that should never be
> > in a commit in the working tree file, and building the contents in
> > the index using "add -p" to incrementally, it would be the same
> > disaster as you are try
v2.18.0-rc0~70^2 (mailmap: update brian m. carlson's email address,
2018-05-08) changed the mailmap to map
sand...@crustytoothpaste.ath.cx
-> brian m. carlson
instead of
sand...@crustytoothpaste.net
-> brian m. carlson
That means the mapping
Brian M. Carlson
-> brian m. car
On Mon, Sep 17, 2018 at 10:51:35AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> > What's the donness of this one?
> >> > cf. <20180717201348.gd26...@sigill.intra.peff.net>
> >>
> >> This topic has stayed in 'pu' for a long time. I thought it was
> >> concluded that this was a good
Jeff King wrote:
> Let me inject some more uncertainty, then. ;)
>
> If we are not going to do 3/3, then should 2/3 simply avoid passing "-1"
> back via return from main? I guess I don't have a strong opinion, but
> one of the things I noted was that we converted those die() calls
> introduced in
Hi,
Eric Sunshine wrote:
> doc-diff creates a temporary working tree (git-worktree) and generates a
> bunch of temporary files which it does not remove since they act as a
> cache to speed up subsequent runs. Although doc-diff's working tree and
> generated files are not strictly build products o
On Tue, Jul 17, 2018 at 03:59:47PM -0400, Jeff King wrote:
> On Mon, Jul 16, 2018 at 11:54:16PM -0700, Jonathan Nieder wrote:
>
> > A value of -1 returned from cmd_gc gets propagated to exit(),
> > resulting in an exit status of 255. Use die instead for a clearer
> > error message and a controll
On 9/14/2018 5:56 PM, Junio C Hamano wrote:
* ds/format-commit-graph-docs (2018-08-21) 2 commits
- commit-graph.txt: improve formatting for asciidoc
- Docs: Add commit-graph tech docs to Makefile
Design docs for the commit-graph machinery is now made into HTML as
well as text.
Will di
Hi,
Jeff King wrote:
> On Tue, Jul 17, 2018 at 03:59:47PM -0400, Jeff King wrote:
>> On Mon, Jul 16, 2018 at 11:54:16PM -0700, Jonathan Nieder wrote:
>>> A value of -1 returned from cmd_gc gets propagated to exit(),
>>> resulting in an exit status of 255. Use die instead for a clearer
>>> error
On Mon, Sep 17, 2018 at 8:15 PM Jeff King wrote:
> On Mon, Sep 17, 2018 at 07:29:26PM +0200, Duy Nguyen wrote:
> > I don't see a good way to get to recover this situation. I could go
> > back to the "index log" idea, where we keep a log of index changes (or
> > just "interesting" changes). That wa
Thomas Gummerer wrote:
> Currently the 'compute_assignment()' function may read memory out
> of bounds, even if used correctly. Namely this happens when we only
> have one column.
[...]
> Reported-by: ryenus
> Helped-by: Derrick Stolee
> Signed-off-by: Thomas Gummerer
> ---
> linear-assignmen
On 9/15/2018 7:09 AM, Duy Nguyen wrote:
On Sat, Sep 15, 2018 at 01:07:46PM +0200, Duy Nguyen wrote:
12:50:00.084237 read-cache.c:1721 start loading index
12:50:00.119941 read-cache.c:1943 performance: 0.034778758 s: loaded all
extensions (1667075 bytes)
12:50:00.185352 read-cache
Derrick Stolee writes:
>> Replaced with a newer version.
>
> I think this has been the same note for a few weeks now. What does it
> mean? Did I send a new version out that you haven't picked up?
It just means that I didn't bother to look at the current status
message for the topic that had no
Duy Nguyen writes:
> I get annoyed by the "ignoring unknown extension xxx" messages while
> testing though (not just this extension) and I think it will be the
> same for other git implementations. But perhaps other implementations
> just silently drop the extension. Most of the extensions we hav
Duy Nguyen writes:
> On Mon, Sep 17, 2018 at 6:25 PM Junio C Hamano wrote:
>>
>> Nguyễn Thái Ngọc Duy writes:
>>
>> > This function calls do_diff_cache() which eventually needs to set this
>> > "istate" to unpack_options->src_index (*). This is an unfortunate fact
>> > that unpack_trees() _wil
In t5551 we check that we save cookies correctly to a file when
http.cookiefile and http.savecookies are set. To do so we create an
expect file that expects the cookies in a certain order.
However after e2ef8d6fa ("cookies: support creation-time attribute for
cookies", 2018-08-28) in curl.git (re
Hi All,
Does anyone know whether it is practical to rework git-lfs under a language
other than "go"? GCC is not even close to being possible to port to my
NonStop platform (may have tried, some have died - joke - trying). I would
like to convert this directly to C or something more widely portabl
Duy Nguyen writes:
> On Mon, Sep 17, 2018 at 7:09 PM Junio C Hamano wrote:
>> ...
>> On the other hand, if I am keeping some change that should never be
>> in a commit in the working tree file, and building the contents in
>> the index using "add -p" to incrementally, it would be the same
>> dis
Hi,
Randall S. Becker wrote:
> Does anyone know whether it is practical to rework git-lfs under a language
> other than "go"? GCC is not even close to being possible to port to my
> NonStop platform (may have tried, some have died - joke - trying). I would
> like to convert this directly to C or
Jonathan Nieder writes:
>> +'$(SHELL_PATH_SQ)' ./doc-diff --clean
>
> This means I need a copy of git in order to run "make clean". That
> was never required before. It makes bootstrapping difficult --- do we
> really need it?
Gahh, you are absolutely right. Also "doc-diff --clean", if I
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Eric Sunshine wrote:
>>> + '$(SHELL_PATH_SQ)' ./doc-diff --clean
>>
>> This means I need a copy of git in order to run "make clean". That
>> was never required before. It makes bootstrapping difficult --- do we
>> really need it?
>
> Gahh, yo
Jonathan Nieder writes:
> I'd rather that we revert this change altogether. I have nothing
> against a convenient command to do this kind of non build related
> cleanup, but it shouldn't be spelled as "make clean".
OK, let's do this for now as I wanted to merge the remainder to
'master' today.
Thomas Gummerer writes:
> In t5551 we check that we save cookies correctly to a file when
> http.cookiefile and http.savecookies are set. To do so we create an
> expect file that expects the cookies in a certain order.
>
> However after e2ef8d6fa ("cookies: support creation-time attribute for
>
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> I'd rather that we revert this change altogether. I have nothing
>> against a convenient command to do this kind of non build related
>> cleanup, but it shouldn't be spelled as "make clean".
>
> OK, let's do this for now as I wanted to merge the
On 9/14/2018 7:26 PM, Ramsay Jones wrote:
Signed-off-by: Ramsay Jones
---
Hi Derrick,
If you need to re-roll your 'ds/multi-pack-verify' branch, could you
please squash this into the relevant patch (commit 64cbf3df21,
"multi-pack-index: add 'verify' verb", 2018-09-13).
[noticed by sparse].
T
Please try the following:
mmatrosov@Mikhail-PC:~/test$ git init --bare server
Initialized empty Git repository in /home/mmatrosov/test/server/
mmatrosov@Mikhail-PC:~/test$ git clone server local
Cloning into 'local'...
warning: You appear to have cloned an empty repository.
done.
mmatrosov@Mikhail
On Mon, Sep 17, 2018 at 3:36 PM Junio C Hamano wrote:
> Jonathan Nieder writes:
> >> +'$(SHELL_PATH_SQ)' ./doc-diff --clean
> >
> > This means I need a copy of git in order to run "make clean". That
> > was never required before. It makes bootstrapping difficult --- do we
> > really need it
Derrick Stolee writes:
> ds/multi-pack-verify is currently queued for 'next', so I wasn't
> planning on sending another version.
>
> Junio, could you add this commit to the tip, or squash it into
> 64cbf3df2 "multi-pack-index: add 'verify' verb"?
I think it makes sense to queue this on top. Tha
Derrick Stolee writes:
> Thanks for catching this, Ramsay. Sorry for the mistake.
>
> ds/multi-pack-verify is currently queued for 'next', so I wasn't
> planning on sending another version.
Marked for 'next' does not mean we cannot touch it. It merely means
"so far no issue that requires a rero
On Mon, Sep 17, 2018 at 4:43 PM Eric Sunshine wrote:
> I did consider this case and felt that it would be reasonable for it
> to error out and ignore the error if git was missing or if the
> directory was not a repository. And, I _thought_ I had prefixed the
> line with "-" to handle just such a c
On 09/17, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > In t5551 we check that we save cookies correctly to a file when
> > http.cookiefile and http.savecookies are set. To do so we create an
> > expect file that expects the cookies in a certain order.
> >
> > However after e2ef8d6fa ("c
Thomas Gummerer wrote:
> On 09/17, Junio C Hamano wrote:
>> The other
>> effort implicitly depends on the expected output is kept sorted, but
>> this one is more explicit---I tend to prefer this approach as tools
>> and automation is easier t
Duy Nguyen writes:
>> diff --git a/read-cache.c b/read-cache.c
>> index 858935f123..b203eebb44 100644
>> --- a/read-cache.c
>> +++ b/read-cache.c
>> @@ -23,6 +23,10 @@
>> #include "split-index.h"
>> #include "utf8.h"
>> #include "fsmonitor.h"
>> +#ifndef NO_PTHREADS
>> +#include
>> +#include
Helped-by: Junio C Hamano
Signed-off-by: Stefan Beller
---
sha1-array.c | 17 +
sha1-array.h | 9 +
2 files changed, 26 insertions(+)
diff --git a/sha1-array.c b/sha1-array.c
index 265941fbf40..67db5eeec9a 100644
--- a/sha1-array.c
+++ b/sha1-array.c
@@ -77,3 +77,20 @@
v2:
* extended commit messages,
* plugged a memory leak
* rewrote the patch "sha1-array: provide oid_array_filter" to be much more like
object_array_fiter
* fixed a typo pointed out by Ramsay.
The range diff is below.
Thanks,
Stefan
v1:
Currently when git-fetch is asked to recurse into subm
The submodule subsystem is really bad at staying within 80 characters.
Fix it while we are here.
Signed-off-by: Stefan Beller
---
submodule.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/submodule.c b/submodule.c
index a2b266fbfae..d29dfa3d1f5 100644
--- a/submodu
We can string_list_insert() to maintain sorted-ness of the
list as we find new items, or we can string_list_append() to
build an unsorted list and sort it at the end just once.
To pick which one is more appropriate, we notice the fact
that we discover new items more or less in the already
sorted o
Add a few functions to allow a string-list to be used as a stack:
- string_list_last() lets a caller peek the string_list_item at the
end of the string list. The caller needs to be aware that it is
borrowing a pointer, which can become invalid if/when the
string_list is resized.
- str
Gerrit, the code review tool, has a different workflow than our mailing
list based approach. Usually users upload changes to a Gerrit server and
continuous integration and testing happens by bots. Sometimes however a
user wants to checkout a change locally and look at it locally. For this
use case,
1 - 100 of 149 matches
Mail list logo
