On 10/22/2019 11:48 PM, Junio C Hamano wrote:
> Derrick Stolee writes:
>
>>> I'm slightly wary of changing the output of plumbing commands
>>> like this. If a script wants progress output it can already get
>>> it by passing --verbose. With this change a script that does not
>>> want that output
Derrick Stolee writes:
>> I'm slightly wary of changing the output of plumbing commands
>> like this. If a script wants progress output it can already get
>> it by passing --verbose. With this change a script that does not
>> want that output now has to pass --no-verbose.
>
> If a script is calli
On 10/21/2019 11:04 AM, Phillip Wood wrote:
> Hi Stolee
>
> On 21/10/2019 14:56, Derrick Stolee via GitGitGadget wrote:
>> From: Derrick Stolee
>>
>> The read-tree builtin has a --verbose option that signals to show
>> progress and other data while updating the
Hi Stolee
On 21/10/2019 14:56, Derrick Stolee via GitGitGadget wrote:
From: Derrick Stolee
The read-tree builtin has a --verbose option that signals to show
progress and other data while updating the index. Update this to
be on by default when stderr is a terminal window.
This will help
From: Derrick Stolee
The read-tree builtin has a --verbose option that signals to show
progress and other data while updating the index. Update this to
be on by default when stderr is a terminal window.
This will help tools like 'git sparse-checkout' to automatically
benefit fro
Peter Jones writes:
> Subject: Re: [PATCH v2 1/4] libgit: Add a read-only helper to test the
> worktree lock
Having a word "worktree" somewhere on the title is good, but have it
as the "I am changing this area"; "libgit" does not give readers the
hint th
Add the function is_worktree_locked(), which is a helper to tell if a
worktree is locked without having to be able to modify it.
Signed-off-by: Peter Jones
---
builtin/worktree.c | 2 +-
worktree.c | 16
worktree.h | 5 +
3 files changed, 22 insertions(+),
From: Derrick Stolee
The read-tree builtin has a --verbose option that signals to show
progress and other data while updating the index. Update this to
be on by default when stderr is a terminal window.
This will help tools like 'git sparse-checkout' to automatically
benefit fro
On 10/12/2019 6:16 PM, Elijah Newren wrote:
> On Mon, Oct 7, 2019 at 1:08 PM Derrick Stolee via GitGitGadget
> wrote:
>>
>> From: Derrick Stolee
>>
>> The read-tree builtin has a --verbose option that signals to show
>> progress and other data while updating t
On Mon, Oct 7, 2019 at 1:08 PM Derrick Stolee via GitGitGadget
wrote:
>
> From: Derrick Stolee
>
> The read-tree builtin has a --verbose option that signals to show
> progress and other data while updating the index. Update this to
> be on by default when stderr is a termina
From: Derrick Stolee
The read-tree builtin has a --verbose option that signals to show
progress and other data while updating the index. Update this to
be on by default when stderr is a terminal window.
This will help tools like 'git sparse-checkout' to automatically
benefit fro
Signed-off-by: Matheus Tavares
---
This is just a small fixup to be squashed into patch 6: with multiple
locks, the locking order must be consistent across all critical sections
to avoid dead-lock. Since grep_attr_lock() is called before
obj_read_lock() in grep_source_load_driver(), it must also
&size, NULL);
- grep_read_unlock();
-
if (!data)
die(_("unable to read tree (%s)"),
oid_to_hex(&object->oid));
@@ -586,7 +575,7 @@ static int grep_tree(struct grep_opt *opt, const stru
Hi Eugen,
On Thu, 12 Sep 2019, Eugen Konkov wrote:
> $ git --version
> git version 2.20.1
First thing to try is whether Git v2.23.0 still exposes that bug.
Ciao,
Johannes
rm -fr ".git/rebase-apply"
and run me again. I am stopping in case you still have something
valuable there.
$ git rebase --abort
error: could not read '.git/rebase-apply/head-name': No such file or directory
$ git --version
git version 2.20.1
$ rm -fr ".git/rebase-app
more often. But:
- this is test code that only ever loops twice in our test suite (we
do loop 1000 times in a t/perf test, but without using this option).
- a decent compiler ought to be able to hoist that out of the loop
anyway (though I wouldn't count on gcc 9.2.1 doing so!)
Re
This is done by removing namelen at all. It is only used once
and simply strlen(name), hence we use strlen(name) directly.
Suggested-by: Jeff King
Signed-off-by: Stephan Beyer
---
t/helper/test-read-cache.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/t/helper/test
Especially in 3rd-party tools, where the shape of the repository/worktree is
unpredictable, it is a wise thing to have an option to pass pathspec
parameters via stdin rather than via the command line, as the latter has
size restrictions that the former does not have.
Johannes Schindelin (1):
res
On Fri, Aug 30, 2019 at 9:25 PM Junio C Hamano wrote:
>
> But between these two:
>
> $ git clone --no-read-only-file-in-git https://github.com/foo/bar
> ...sightsee...
> $ rm -r bar
>
> to avoid "f" in "rm -r", vs.
>
&
de
> and then don't need them anymore. Some people may be in such situation
> more often or regularly.
But between these two:
$ git clone --no-read-only-file-in-git https://github.com/foo/bar
...sightsee...
$ rm -r bar
to avoid "f" in "rm -r&
t; The whole point of this thread was to remove the need of -f forcing the
> > removal.
>
> OK, I misunderstood what you wanted to do.
>
> If an implementation of Git were making everything under .git/
> read-only, including directories, then it is veriy much reasonable
>
misunderstood what you wanted to do.
If an implementation of Git were making everything under .git/
read-only, including directories, then it is veriy much reasonable
to complain against such an implementation. The usual "I know I am
doing something unusual and forcing it" safety given by &
On Tue, Aug 27, 2019 at 9:35 PM Junio C Hamano wrote:
>
> Ah, your "rm" command needs to learn "-f" option, too, then?
The whole point of this thread was to remove the need of -f forcing the removal.
Albert Vaca Cintora writes:
> It "works" for some definition of work, but it asks for confirmation
> for every file, which is a pain. I'm on Linux.
Ah, your "rm" command needs to learn "-f" option, too, then?
dows (under cygwin-bash) and
> > anything else POSIX-ish.
> >
>
> Wrapping `git clone` should work as a workaround. Although if that
> doesn't break anything... then why were those files read-only in the
> first place? :)
Those read-only object and pack files contain a
On Mon, Aug 26, 2019 at 4:38 PM Junio C Hamano wrote:
>
> And directories (e.g. .git/objects/) are not made read-only for
> obvious reasons. Read-only files inside a writeable directory can
> be deleted just like read-write ones can be (iow, the "delete
> permission&qu
ins what I want and delete the rest. Sometimes I want to
> >> write a patch for some software I don't develop regularly so I don't
need
> to keep a clone of it.
> >>
> >> In any case, it would be useful to know the reason those files are
> >> read-onl
some
>> software I don't develop regularly so I don't need to keep a clone of it.
>>
>> In any case, it would be useful to know the reason those files are read-only
>> in
>> the first place. Do you guys know who might know?
>
> Why don't you wrap yo
nsequence will be that such
> files are read-only.
And directories (e.g. .git/objects/) are not made read-only for
obvious reasons. Read-only files inside a writeable directory can
be deleted just like read-write ones can be (iow, the "delete
permission" comes from the "write permi
the rest. Sometimes I want to write a patch for some
> software I don't develop regularly so I don't need to keep a clone of it.
>
> In any case, it would be useful to know the reason those files are read-only
> in
> the first place. Do you guys know who might know?
Why
, or I clone several repos until I find the one
that contains what I want and delete the rest. Sometimes I want to
write a patch for some software I don't develop regularly so I don't
need to keep a clone of it.
In any case, it would be useful to know the reason those files are
read-only i
on't need it anymore, or I clone several repos until I find the one
that contains what I want and delete the rest. Sometimes I want to
write a patch for some software I don't develop regularly so I don't
need to keep a clone of it.
In any case, it would be useful to know the reason
Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora:
> However, I'm sure that a large percentage of developers out there will
> agree with me that having to use force (-f) to delete every cloned
> repo is annoying, and even worse, it creates the bad habit of always
> force-deleting everything.
IMO, t
On Sun, Aug 25, 2019 at 1:59 PM Kevin Daudt wrote:
>
> On Fri, Aug 23, 2019 at 10:43:45PM +0200, Albert Vaca Cintora wrote:
> > Hi git folks,
> >
> > Honestly I'm not aware of the reason behind .git being read-only, but
> > I'm sure there is one.
> >
On Fri, Aug 23, 2019 at 10:43:45PM +0200, Albert Vaca Cintora wrote:
> Hi git folks,
>
> Honestly I'm not aware of the reason behind .git being read-only, but
> I'm sure there is one.
>
> However, I'm sure that a large percentage of developers out there will
&
Hi git folks,
Honestly I'm not aware of the reason behind .git being read-only, but
I'm sure there is one.
However, I'm sure that a large percentage of developers out there will
agree with me that having to use force (-f) to delete every cloned
repo is annoying, and even worse,
6a71
> ("Use xmmap_gently instead of xmmap in use_pack", 2019-05-16).
Nice find and thanks for checking other callsites of xmmap().
>
> read-cache.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index 22e7
then invoking any command that reads from the
index.
Signed-off-by: Varun Naik
---
I believe this is the only place that calls xmmap() when it should be
calling xmmap_gently(). There is a related recent commit 3203566a71
("Use xmmap_gently instead of xmmap in use_pack", 2019-05-1
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 8
t/t3011-ls-files-json.sh | 13 ++
t/t3011/eoie (new) | 96
t/test-lib.sh| 4 ++
4 files changed, 121 insertions(+)
diff --git a/read-cache.c b/read-cache.c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 43 ---
t/t3011/eoie | 13 -
2 files changed, 48 insertions(+), 8 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 37491dd03d..c26edcc9d9 100644
--- a/read-cache.c
+++ b/read
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 49 +++--
1 file changed, 35 insertions(+), 14 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index db5147d088..4accd8bb08 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1694,8 +1694,26
ies is
>> based on a different commit?
>
> it's on 'master', a6a95cd1b4 (The second batch, 2019-06-17). There are
> a couple patches since v2.22.0 that touch read-cache.c, but they don't
> touch these lines explictly...
Thanks, I should have tried from master myself. Starting there worked.
ing this series on top of v2.22.0 and ran into an issue
> on this patch, and the message seemed to imply the problem was at this
> block. I couldn't figure out what was wrong, but maybe the series is
> based on a different commit?
it's on 'master', a6a95cd1b4 (The se
On 6/19/2019 5:58 AM, Nguyễn Thái Ngọc Duy wrote:> @@ -2266,7 +2271,7 @@ int
do_read_index(struct index_state *istate, const char *path, int must_exist)
>* to multi-thread the reading of the cache entries.
>*/
> if (extension_offset && nr_threads > 1)
> - ieot = r
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 04863c3853..200834e77e 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1911,7 +1911,7 @@ struct
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 3b5c63f53a..04863c3853 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1914,7 +1914,7 @@ struct
ave a method to keep track of recipients on a per-branch basis.
Currently, git-format-patch gets its To: headers from the `--to` options
and the `format.to` config variable. The Cc: header is derived
similarly.
In addition to the above, read To: and Cc: headers from
`format..to` and `format..cc` so
If a user wishes to have a per-branch output directory for patches, they
must manually specify this on the command-line with `-o` for each
invocation of format-patch. However, this can be cumbersome for a user
to keep track of.
Read `format..outputDirectory` to give a branch-specific
output
Matthew DeVore writes:
> url_decode_internal could have been tricked into reading past the length
> of the **query buffer if there are fewer than 2 characters after a % (in
> a null-terminated string, % would have to be the last character).
> Prevent this from happening by checking len before dec
url_decode_internal could have been tricked into reading past the length
of the **query buffer if there are fewer than 2 characters after a % (in
a null-terminated string, % would have to be the last character).
Prevent this from happening by checking len before decoding the %
sequence.
Helped-by:
On Tue, Jun 04, 2019 at 07:00:34AM +0200, René Scharfe wrote:
> Am 03.06.19 um 22:45 schrieb Matthew DeVore:
> > url_decode_internal could have been tricked into reading past the length
> > of the **query buffer if there are fewer than 2 characters after a % (in
> > a null-terminated string, % woul
Am 03.06.19 um 22:45 schrieb Matthew DeVore:
> url_decode_internal could have been tricked into reading past the length
> of the **query buffer if there are fewer than 2 characters after a % (in
> a null-terminated string, % would have to be the last character).
> Prevent this from happening by che
url_decode_internal could have been tricked into reading past the length
of the **query buffer if there are fewer than 2 characters after a % (in
a null-terminated string, % would have to be the last character).
Prevent this from happening by checking len before decoding the %
sequence.
Signed-off
Good day
Blessings to you,am contacting you based on a mutual benefit
inheritance transaction of ($10.5 million US dollars) that has to do
with your last name contact me for more details. Contact email [
barristergracefol...@gmail.com]
Regards,
Barrister Grace Folly
//
If a user wishes to have a per-branch output directory for patches, they
must manually specify this on the command-line with `-o` for each
invocation of format-patch. However, this can be cumbersome for a user
to keep track of.
Read `format..outputDirectory` to give a branch-specific
output
ave a method to keep track of recipients on a per-branch basis.
Currently, git-format-patch gets its To: headers from the `--to` options
and the `format.to` config variable. The Cc: header is derived
similarly.
In addition to the above, read To: and Cc: headers from
`format..to` and `format..cc` so
In the conversion of git-am from shell script to C, we switched to using
git_prompt(). Unlike the original shell command "read reply", this
doesn't read from stdin at all, but rather from /dev/tty.
In most cases this distinction wouldn't matter. We require (as the shell
scrip
ave a method to keep track of recipients on a per-branch basis.
Currently, git-format-patch gets its To: headers from the `--to` options
and the `format.to` config variable. The Cc: header is derived
similarly.
In addition to the above, read To: and Cc: headers from
`format..to` and `format..cc` so
Jeff King writes:
> I kind of hate "cmd_prefix"; I was tempted to just call it "prefix" so
> that all of the cmd_* functions were consistent, but I worried that it
> really would get confused with the local variables (even if those
> variables are renamed, as I do here).
I tend to agree with you
On 5/9/2019 5:27 PM, Jeff King wrote:
> I kind of hate "cmd_prefix"; I was tempted to just call it "prefix" so
> that all of the cmd_* functions were consistent, but I worried that it
> really would get confused with the local variables (even if those
> variables are renamed, as I do here).
cmd_pr
The load_cache_entries_threaded() function takes a src_offset parameter
that it doesn't use. This has been there since its inception in
77ff1127a4 (read-cache: load cache entries on worker threads,
2018-10-10).
Digging on the mailing list, that parameter was part of an earlier
iteration o
just call the parameter "prefix" now, but that invites
confusion in the other direction).
Signed-off-by: Jeff King
---
I kind of hate "cmd_prefix"; I was tempted to just call it "prefix" so
that all of the cmd_* functions were consistent, but I worried that i
On Tue, May 7, 2019 at 5:02 PM Phillip Wood wrote:
> > My (biased, obviously) view is that "git reset --hard" is very
> > dangerous and I'm not trying to change that, especially when its
> > behavior has been like this since forever and I'm sure it's used in
> > scripts.
> >
> > Instead "git resto
On 02/05/2019 11:53, Duy Nguyen wrote:
On Wed, May 1, 2019 at 9:58 PM Phillip Wood wrote:
On 01/05/2019 11:31, Duy Nguyen wrote:
On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
From: Phillip Wood
These two patches teach read-tree how to avoid overwriting untracked
files when doing
ave a method to keep track of recipients on a per-branch basis.
Currently, git-format-patch gets its To: headers from the `--to` options
and the `format.to` config variable. The Cc: header is derived
similarly.
In addition to the above, read To: and Cc: headers from
`branch..to` and `branch..cc` so
On 02/05/2019 11:38, Duy Nguyen wrote:
On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
From: Phillip Wood
Currently there is no way to get git to discard changes to the
worktree without overwriting untracked files. `reset --hard`,
`checkout --force`, `checkout :/` and `read-tree --reset
On Wed, May 1, 2019 at 9:58 PM Phillip Wood wrote:
>
>
>
> On 01/05/2019 11:31, Duy Nguyen wrote:
> > On Wed, May 1, 2019 at 5:14 PM Phillip Wood
> > wrote:
> >>
> >> From: Phillip Wood
> >>
> >> These two patches teach read-t
On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
>
> From: Phillip Wood
>
> Currently there is no way to get git to discard changes to the
> worktree without overwriting untracked files. `reset --hard`,
> `checkout --force`, `checkout :/` and `read-tree --reset -u`
"
On 01/05/2019 11:31, Duy Nguyen wrote:
On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
From: Phillip Wood
These two patches teach read-tree how to avoid overwriting untracked
files when doing '--reset -u' and also how to respect all of git's
standard excludes files.
On Wed, May 1, 2019 at 5:18 PM Duy Nguyen wrote:
>
> On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
> > diff --git a/unpack-trees.h b/unpack-trees.h
> > index d344d7d296..732b262c4d 100644
> > --- a/unpack-trees.h
> > +++ b/unpack-trees.h
> > @@ -41,9 +41,15 @@ void setup_unpack_trees_porcela
On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
>
> From: Phillip Wood
>
> These two patches teach read-tree how to avoid overwriting untracked
> files when doing '--reset -u' and also how to respect all of git's
> standard excludes files. I'd l
On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
> diff --git a/unpack-trees.h b/unpack-trees.h
> index d344d7d296..732b262c4d 100644
> --- a/unpack-trees.h
> +++ b/unpack-trees.h
> @@ -41,9 +41,15 @@ void setup_unpack_trees_porcelain(struct
> unpack_trees_options *opts,
> */
> void clear_un
From: Phillip Wood
Currently there is no way to get read-tree to respect
.git/info/exclude or core.excludesFile so scripts using `read-tree -u`
have subtly different behavior to porcelain commands like checkout
even when they use --exclude-per-directory. This new option is copied
from ls-tree&#
From: Phillip Wood
These two patches teach read-tree how to avoid overwriting untracked
files when doing '--reset -u' and also how to respect all of git's
standard excludes files. I'd like to see the porcelain commands stop
overwriting untracked files, this is a first step
From: Phillip Wood
Currently there is no way to get git to discard changes to the
worktree without overwriting untracked files. `reset --hard`,
`checkout --force`, `checkout :/` and `read-tree --reset -u`
will all overwrite untracked files. unpack_trees() has known how to
avoid overwriting
--
I am Ms.Ella Golan, I am the Executive Vice President Banking Division with
FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you
regarding an extremely important and urgent matter. If you would oblige me the
opportunity, I shall provide you with details upon your
On Sat, Apr 13, 2019 at 10:21:36AM +0100, Klaus Ethgen wrote:
> Finally, the error was a combination of 4 tools, git, vim, the mentioned
> vim-addon and task with a task-hook for committing pending.data.
>
> When I do a git commit which invokes vim, then the following variables
> are set:
> - GIT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I did a deep analysis of the problem and found that the trouble finally
was caused of some change in git (I did not search, when this changed.
But maybe you can tell me.)
Finally, the error was a combination of 4 tools, git, vim, the mentioned
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Forgot the link:
[0] https://github.com/farseer90718/vim-taskwarrior
Regards
Klaus
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen
Fingerprint: 85D4 CA42 952C 9
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I seems to have found the bug.
My last debugging gave the hint. pending.data is a concept of
taskwarrior and have the .task directory on git control. And I also use
a vim addon for it[0].
It seems that it introduces that troubles. As the last commi
e the problem that I get often "fatal: unable to
> > read ..." and a unclear repository after a git commit. The commit itself
> > is correct and so a git reset --hard helps to fix the issue.
>
> Could you tell us at least which Debian version and file system you use?
Hi,
On Thu, Apr 11, 2019 at 7:24 PM Klaus Ethgen wrote:
> I am a heavy user of git now at version 2.20.1 on debian.
>
> Since some weeks I have the problem that I get often "fatal: unable to
> read ..." and a unclear repository after a git commit. The commit itself
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi folks,
I am a heavy user of git now at version 2.20.1 on debian.
Since some weeks I have the problem that I get often "fatal: unable to
read ..." and a unclear repository after a git commit. The commit itself
is correct and so a
Hi Kapil,
On Sun, Apr 07, 2019 at 01:07:12PM +0530, Kapil Jain wrote:
> Signed-off-by: Kapil Jain
> ---
>
> In read-cache, the read_index_from() function had a TODO task,
> this patch completes that. There are some other functions in the same file
> where this exact TODO need
a
> > pointer to 'struct repository'). I'm pretty sure the purpose is to
> > _not_ pass the_repository (because it implies the default repo, which
> > is not always true). Which means you read-cache.c's functions need to
> > take 'struct repository
On Sun, Apr 07, 2019 at 05:00:11PM +0700, Duy Nguyen wrote:
> So, with something like a patch below (not tested), you should be able
> to write
>
> worktrees = repo_get_worktrees(revs->repo, 0);
> ...
> struct repository *r = repo_worktree_init(wt);
> if (re
On Sun, Apr 07, 2019 at 01:07:12PM +0530, Kapil Jain wrote:
> Signed-off-by: Kapil Jain
> ---
>
> In read-cache, the read_index_from() function had a TODO task, this
> patch completes that.
This line at least should be above the "---" line (i.e. part of the
commit messa
Signed-off-by: Kapil Jain
---
In read-cache, the read_index_from() function had a TODO task,
this patch completes that. There are some other functions in the same file
where this exact TODO needs to be done, will proceed to do them once this patch
is accepted.
running test gave 256 not okays
On Sat, Apr 6, 2019 at 8:30 PM Kapil Jain wrote:
>
> On Sat, Apr 6, 2019 at 5:49 PM Duy Nguyen wrote:
> >
> > On Sat, Apr 6, 2019 at 7:14 PM Kapil Jain wrote:
> > > > In some cases, it will be simple. For example, if you have a look at
> > > > repo_read_index(), it already knows what repo it han
On Sat, Apr 6, 2019 at 5:49 PM Duy Nguyen wrote:
>
> On Sat, Apr 6, 2019 at 7:14 PM Kapil Jain wrote:
> > > In some cases, it will be simple. For example, if you have a look at
> > > repo_read_index(), it already knows what repo it handles, so you can
> > > just extend read_index_from() to take '
On Sat, Apr 6, 2019 at 7:14 PM Kapil Jain wrote:
> > In some cases, it will be simple. For example, if you have a look at
> > repo_read_index(), it already knows what repo it handles, so you can
> > just extend read_index_from() to take 'struct repository *' and pass
> > 'repo' to it.
> >
> > Be c
ch
> is not always true). Which means you read-cache.c's functions need to
> take 'struct repository *' as an argument and let the caller decide
> what repo they want to use.
right, i mistyped.
> In some cases, it will be simple. For example, if you have a look at
> r
On Sat, Apr 6, 2019 at 6:42 PM Kapil Jain wrote:
>
> i found some TODO tasks inside `read-cache.c` in `read_index_from()`
> function. which says:
>
> /*
> * TODO trace2: replace "the_repository" with the actual repo instance
> that is associated with the given &q
i found some TODO tasks inside `read-cache.c` in `read_index_from()`
function. which says:
/*
* TODO trace2: replace "the_repository" with the actual repo instance
that is associated with the given "istate".
*/
this same TODO occurs at 4 other places in the same file.
This old code uses fgets with a fixed-size buffer. Let's use a strbuf
instead, so we don't have to wonder if "1000" is big enough, or what
happens if we see a long line.
This also lets us drop our custom code to trim the newline.
Probably nobody actually cares about the 1000-char limit (after all
This old code uses fgets with a fixed-size buffer. Let's use a strbuf
instead, so we don't have to wonder if "1000" is big enough, or what
happens if we see a long line.
This also lets us drop our custom code to trim the newline.
Probably nobody actually cares about the 1000-char limit (after all
The description of --reset stays true to the first implementation in
438195cced (git-read-tree: add "--reset" flag, 2005-06-09). That is,
--reset discards unmerged entries. Or at least true to the commit
message because I can't be sure about read-tree's behavior regarding
lo
On Mon, Apr 1, 2019 at 5:47 PM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > diff --git a/Documentation/git-read-tree.txt
> > b/Documentation/git-read-tree.txt
> > index 5c70bc2878..12a25bc954 100644
> > --- a/Documentation/git-read-tree.txt
Nguyễn Thái Ngọc Duy writes:
> diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
> index 5c70bc2878..12a25bc954 100644
> --- a/Documentation/git-read-tree.txt
> +++ b/Documentation/git-read-tree.txt
> @@ -38,8 +38,9 @@ OPTIONS
> start
The description of --reset stays true to the first implementation in
438195cced (git-read-tree: add "--reset" flag, 2005-06-09). That is,
--reset discards unmerged entries. Or at least true to the commit
message because I can't be sure about read-tree's behavior regarding
lo
1 - 100 of 2246 matches
Mail list logo
