On Wed, May 16, 2018 at 03:21:07PM -0700, Stefan Beller wrote:
> > If you have time, yes translate them all. I don't see how any of these
> > strings are meant for script. If not, just _() the new string you
> > added is fine.
>
> > With a majority of call sites dying like this though, I wonder if
On Wed, May 16, 2018 at 03:27:33PM -0700, Brandon Williams wrote:
> Maybe we can kill read_cache() while at it?
I took this out of context. But with the move to repo_* stuff,
eventually these macros around the_index should die. Not today though.
--
Duy
On Wed, May 16, 2018 at 03:21:18PM -0700, Stefan Beller wrote:
This commit may need some more explanation. It's not always safe to
replace "read_cache();" with "repo_read_index_or_die();" and you do
sometimes avoid that variant.
While I agree _or_die() is the right thing to do most of the time. Y
On Wed, May 16, 2018 at 03:21:09PM -0700, Stefan Beller wrote:
> A common pattern with the repo_read_index function is to die if the return
> of repo_read_index is negative. Move this pattern into a function.
>
> This patch replaces the calls of repo_read_index with its _or_die version,
> if the
On 19 May 2018 at 03:02, Jeff King wrote:
> On Fri, May 18, 2018 at 03:30:44PM -0700, Elijah Newren wrote:
>
>> > would become:
>> >
>> > msgs[ERROR_WOULD_OVERWRITE] = msgs[ERROR_NOUPTODATE_FILE] =
>> > string_list_appendf(&opts->msgs_to_free, msg, cmd, cmd)->string;
>> >
>> > I don't kn
On Thu, May 17, 2018 at 5:31 AM, Jeff King wrote:
> On Thu, May 17, 2018 at 06:13:55AM +0530, Sitaram Chamarty wrote:
>
>> I may have missed a few of the earlier messages, but in the last
>> 20 or so in this thread, I did not see namespaces mentioned by
>> anyone. (I.e., apologies if it was addres
On Mon, May 14, 2018 at 8:14 PM, Derrick Stolee wrote:
> I disagree with the removal of "generation". My intention is to make the
> commit-graph feature a standard feature that most repos (of reasonable size)
> want to have. In that case, 'graph_pos' and 'generation' will be set during
> every par
It's done so that commit->util can be removed. See more explanation in
the commit that removes commit->util.
---
builtin/name-rev.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 387ddf85d2..0eb440359d 1006
It's done so that commit->util can be removed. See more explanation in
the commit that removes commit->util.
---
blame.c | 42 +++---
blame.h | 2 ++
builtin/blame.c | 2 +-
3 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/blame
It's done so that commit->util can be removed. See more explanation in
the commit that removes commit->util.
While at there, plug a leak for keeping track of depth in this code.
---
shallow.c | 40
1 file changed, 28 insertions(+), 12 deletions(-)
diff --
It's done so that commit->util can be removed. See more explanation in
the commit that removes commit->util.
---
sequencer.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 4ce5120e77..3af296db3b 100644
--- a/sequencer.c
+++ b/sequen
It's done so that commit->util can be removed. See more explanation in
the commit that removes commit->util.
---
builtin/merge.c | 25 +
commit.c | 12 ++--
commit.h | 2 +-
merge-recursive.c | 8 +---
4 files changed, 29 insertions(+), 18
The struct declaration and implementation macros are moved to
commit-slab-hdr.h and commit-slab-impl.h respectively.
This right now is not needed for current users but if we make a public
commit-slab type, we may want to avoid including the slab
implementation in a header file which gets replicate
It's done so that commit->util can be removed. See more explanation in
the commit that removes commit->util.
---
builtin/show-branch.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index 6
It's done so that commit->util can be removed. See more explanation in
the commit that removes commit->util.
---
builtin/log.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index d017e57475..967fbc5caa 100644
--- a/builtin/log.c
+++ b/
If you have come this far, you probably have seen that this 'util'
pointer is used for many different purposes. Some are not even
contained in a command code, but buried deep in common code with no
clue who will use it and how.
The move to using commit-slab gives us a much better picture of how
so
define_shared_commit_slab() could be used in a header file to define a
commit-slab. One of these C files must include commit-slab-impl.h and
"call" implement_shared_commit_slab().
---
commit-slab-decl.h | 13 +
commit-slab-impl.h | 22 ++
commit-slab.h | 2 +-
v3 fixes Junio's comments on v2:
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index b08e5ea0e3..5aaf5c8e59 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -592,7 +592,7 @@ static void handle_commit(struct commit *commit, struct
rev_info *rev,
if (!S
It's done so that commit->util can be removed. See more explanation in
the commit that removes commit->util.
---
builtin/describe.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/builtin/describe.c b/builtin/describe.c
index b5afc45846..1b6ca42553 100644
---
It's done so that commit->util can be removed. See more explanation in
the commit that removes commit->util.
---
bisect.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/bisect.c b/bisect.c
index a579b50884..6de1abd407 100644
--- a/bisect.c
+++ b/bisect.c
@@ -12,6
It's done so that commit->util can be removed. See more explanation in
the commit that removes commit->util.
---
sequencer.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 3af296db3b..3b6d56d085 100644
--- a/sequencer.c
+++ b/sequen
Instead of relying on commit->util to store the source string, let the
user provide a commit-slab to store the source strings in.
It's done so that commit->util can be removed. See more explanation in
the commit that removes commit->util.
---
builtin/fast-export.c | 14 +-
builtin/log
This is another candidate for commit-slab. Keep Junio's observation in
code so we can search it later on when somebody wants to improve the
code.
---
builtin/show-branch.c | 5 +
object.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/builtin/show-branch.c b/builtin/show-br
On Mon, May 14, 2018 at 8:45 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> It's done so that commit->util can be removed. See more explanation in
>> the commit that removes commit->util.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> builtin/show-branch.c | 39
On Fri, May 18, 2018 at 02:50:21PM -0700, Taylor Blau wrote:
> [...]
>
> > Another might be to pick "foo" in the first and "bar" in the second
> > line, as that is the "first hit" on the line, which is consistent
> > with how "git grep -e foo" would say about "a foo b foo c foo" (I
> > expect that
Switch from gcc-4.8 to gcc-8. Newer compilers come with more warning
checks (usually in -Wextra). Since -Wextra is enabled in developer
mode (which is also enabled in travis), this lets travis report more
warnings before other people do it.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
v2 switches fr
Instead of maintaining a separate list of command classification,
which often could go out of date, let's centralize the information
back in git.
While the function in git-completion.bash implies "list porcelain
commands", that's not exactly what it does. It gets all commands (aka
--list-cmds=main
This is intended to help anybody who needs to update command-list.txt.
It gives a brief introduction of all attributes a command can take.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
command-list.txt | 45 +
1 file changed, 45 insertions(+)
diff --git a/c
Instead of printing the command directly one by one, keep them in a
list and print at the end. This allows more modification before we
print out (e.g. sorting, removing duplicates or even excluding some
items).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
git.c | 22 +-
1 file cha
The current generate-cmds.sh generates just enough to print "git help"
output. That is, it only extracts help text for common commands.
The script is now updated to extract help text for all commands and
keep command classification a new file, command-list.h. This will be
useful later:
- "git hel
The following commands are removed from the complete list:
- annotate obsolete, discouraged to use
- filter-branchnot often used
- get-tar-commit-idnot often used
- imap-sendnot often used
- interpreter-trailers not for interactive use
- p4 too
After the last patch, common-cmds.h is no longer used (and it was
actually broken). Remove all related code. command-list.h will take
its place from now on.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
.gitignore | 1 -
Makefile| 17 ++---
generate-cmdlist.sh | 46 ++
Even if these are hidden options, let's make them a bit more generic
since we're introducing more listing types shortly. The code is
structured to allow combining multiple listing types together because
we will soon add more types the 'builtins'.
'parseopt' remains separate because it has separate
This makes it easier to reuse the same code in another place (very
soon).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
generate-cmdlist.sh | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index eeea4b67ea..31b6d886cb 100
This is part of the effort to break down and provide commands by
category in machine-readable form. This could be helpful later on when
completion script switches to use --list-cmds for selecting
completable commands. It would be much easier for the user to choose
to complete _all_ commands instead
The previous commit added code generation for all_cmd_desc[] which
includes almost everything we need to generate common command list.
Convert help code to use that array instead and drop common_cmds[] array.
The description of each common command group is removed from
command-list.txt. This keeps
The help command currently hard codes the list of guides and their
summary in C. Let's move this list to command-list.txt. This lets us
extract summary lines from Documentation/git*.txt. This also
potentially lets us list guides in git.txt, but I'll leave that for
now.
Signed-off-by: Nguyễn Thái N
This lists all recognized commands [1] by category. The group order
follows closely git.txt.
[1] We may actually show commands that are not built (e.g. if you set
NO_PERL you don't have git-instaweb but it's still listed here). I
ignore the problem because on Linux a git package could be split
any
This should be the final update before nd/command-list hits 'next',
hopefully.
Besides the interdiff below, the old 12/13 is split into two: 12/14
keeps the complete output as close as possible to the base version and
13/14 removes some commands from the completion list.
interdiff
diff --git a/c
This allows us to select any group of commands by a category defined
in command-list.txt. This is an internal/hidden option so we don't
have to be picky about the category name or worried about exposing too
much.
This will be used later by git-completion.bash to retrieve certain
command groups.
S
By default we show porcelain, external commands and a couple others
that are also popular. If you are not happy with this list, you can
now customize it. See the big comment block for details.
PS. perhaps I should make aliases a group too, which makes it possible
to _not_ complete aliases by omitt
Check this out; I merge another branch successfully:
$ git merge -m F $othersha; echo $?
0
This is just a simple test repo:
$ git log --oneline
18f5e65 (HEAD -> master) F
7472b46 E
ea0d801 D
4486f96 C
7727e3b B
ee47c13 A
Below it is important to note that one commit was made at
These functions were added because processing of these conflicts needed
to be deferred until process_entry() in order to get D/F conflicts and
such right. The number of these has grown over time, and now include
some whose name is misleading:
* conflict_rename_normal() is for handling normal fil
We had an enum of rename types which included RENAME_DIR; this name felt
misleading since it was not about an entire directory but was a status for
each individual file add that occurred within a renamed directory. Since
this type is for signifying that the files in question were being renamed
due
Signed-off-by: Elijah Newren
---
merge-recursive.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 35df695fa4..c430fd72bc 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -531,7 +531,7 @@ static void record_df_conflict_files
Various refactorings throughout the code have left lots of alignment
issues that were driving me crazy; fix them.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 47 ---
1 file changed, 24 insertions(+), 23 deletions(-)
diff --git a/merge-recursi
This patch series contains several small code cleanups for merge-recursive.
I have removed a couple small cleanup chunks in order to avoid conflicts
with any other in-flight topics in pu (namely, nd/commit-util-to-slab and
sb/submodule-merge-in-merge-recursive). I may resend those later
separately
There is really no need for four branches of nearly identical messages
when we can store the differences into small variables before printing.
It does require a few allocations this way, but makes the code much
easier to parse for human readers.
Signed-off-by: Elijah Newren
---
merge-recursive.c
Functions like die_errno() use fmt_with_err() to combine the
caller-provided format with the strerror() string. We use a
fixed stack buffer because we're already handling an error
and don't have any way to report another one. Our buffer
should generally be big enough to fit this, but if it's not,
t
We convert the ref_rev_parse_rules array into scanf formats
on the fly, and use snprintf() to write into each string. We
should have enough memory to hold everything because of the
earlier total_len computation. Let's use xsnprintf() to
give runtime confirmation that this is the case, and to make
i
These formatted integers should always fit into their
64-byte buffers. Let's use xsnprintf() to add an assertion
that this is the case, which makes auditing for other
unchecked snprintfs() easier.
Signed-off-by: Jeff King
---
fsmonitor.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
When we write a MIME attachment, we write the mime headers
into fixed-size buffers. These are likely to be big enough
in practice, but technically the input could be arbitrarily
large (e.g., if the caller provided a lot of content in the
extra_headers string), in which case we'd quietly truncate
it
We keep the names of incoming packs and objects in fixed
PATH_MAX-size buffers, and snprintf() into them. This is
unlikely to end up with truncated filenames, but it is
possible (especially on systems where PATH_MAX is shorter
than actual paths can be). Let's switch to using strbufs,
which makes th
I happened today to be looking at a piece of code that used a bare
snprintf() without checking for truncation, and I got annoyed enough to
root out the last few cases in our codebase. After this series, looking
over the results of:
git grep '[^vxn]snprintf' '*.c' :^compat
is pretty pleasant.
T
Attention
I am an American citizen, My name is Leonard Pakker, a member of the
U.S. ARMY medical team apart from being surprise you may be skeptical
to reply me based on what is happening around world on the internet. I
have just deployed to Syria.
I just discover One trunks of consignment boxes
On Fri, May 18, 2018 at 03:30:44PM -0700, Elijah Newren wrote:
> > would become:
> >
> > msgs[ERROR_WOULD_OVERWRITE] = msgs[ERROR_NOUPTODATE_FILE] =
> > string_list_appendf(&opts->msgs_to_free, msg, cmd, cmd)->string;
> >
> > I don't know if that's worth it or not (I suspect that there a
Hi Peff,
On Fri, 18 May 2018, Jeff King wrote:
> I stumbled across a BUG() today. But interestingly, in the current tip
> of master it actually segfaults instead! This fixes the segfault (back
> into a BUG(), and then fixes the caller to avoid the BUG() in the first
> place).
>
> [1/2]: get_ma
On Fri, May 18, 2018 at 3:25 PM, Jeff King wrote:
> If we don't have a repository, then we can't initialize the
> ref store. Prior to 64a741619d (refs: store the main ref
> store inside the repository struct, 2018-04-11), we'd try to
> access get_git_dir(), and outside a repository that would
> t
On Fri, May 18, 2018 at 03:27:04PM -0700, Jeff King wrote:
> If you run "config --blob" outside of a repository, then we
> eventually try to resolve the blob name and hit a BUG().
> Let's catch this earlier and provide a useful message.
I think that this approach is sensible. Let's (1) fix a SIGSE
On Fri, May 18, 2018 at 2:33 PM, Jeff King wrote:
> On Fri, May 18, 2018 at 11:23:27PM +0200, Martin Ågren wrote:
>
>> diff --git a/unpack-trees.c b/unpack-trees.c
>> index 79fd97074e..60293ff536 100644
>> --- a/unpack-trees.c
>> +++ b/unpack-trees.c
>> @@ -103,6 +103,8 @@ void setup_unpack_trees_
If you run "config --blob" outside of a repository, then we
eventually try to resolve the blob name and hit a BUG().
Let's catch this earlier and provide a useful message.
Note that we could also catch this much lower in the stack,
in git_config_from_blob_ref(). That might cover other
callsites, t
If we don't have a repository, then we can't initialize the
ref store. Prior to 64a741619d (refs: store the main ref
store inside the repository struct, 2018-04-11), we'd try to
access get_git_dir(), and outside a repository that would
trigger a BUG(). After that commit, though, we directly use
th
I stumbled across a BUG() today. But interestingly, in the current tip
of master it actually segfaults instead! This fixes the segfault (back
into a BUG(), and then fixes the caller to avoid the BUG() in the first
place).
[1/2]: get_main_ref_store: BUG() when outside a repository
[2/2]: config
Thanks for your thoughtful response. I answered in detail below, but I
think that we're in agreement about the semantics, with a few
corrections on my part. I'd like to push forward with this series,
including the proposed changes below, but feel that sending it as v7
would be asking too much of a
On Mon, May 14, 2018 at 12:28:12PM +0200, SZEDER Gábor wrote:
> The last two tests 'editor with a space' and 'core.editor with a
> space' in 't7005-editor.sh' need the SPACES_IN_FILENAMES prereq to
> ensure that they are only run on filesystems that allow, well, spaces
> in filesnames. However, w
On Fri, May 18, 2018 at 11:23:27PM +0200, Martin Ågren wrote:
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 79fd97074e..60293ff536 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -103,6 +103,8 @@ void setup_unpack_trees_porcelain(struct
> unpack_trees_options *opts,
> con
Hi Leif,
On Fri, May 18, 2018 at 12:48 PM, Leif Middelschulte
wrote:
> From: Leif Middelschulte
>
> Silent fast-forwarding might lead to inconveniences in cases where
> submodules are expected to have a certain revision, because 'more recent'
> (therefore fast-forwardable) versions might break b
The strings allocated in `setup_unpack_trees_porcelain()` are never
freed. Provide a function `clear_unpack_trees_porcelain()` to do so and
call it where we use `setup_unpack_trees_porcelain()`. The only
non-trivial user is `unpack_trees_start()`, where we should place the
new call in `unpack_trees
From: Elijah Newren
Rename `git_merge_trees()` to `unpack_trees_start()` and extract the
call to `discard_index()` into a new function `unpack_trees_finish()`.
As a result, these are called early resp. late in `merge_trees()`,
making the resource handling clearer. The next commit will expand on
t
After we initialize the various fields in `opts` but before we actually
use them, we might return early. Move the initialization further down,
to immediately before we use `opts`.
This limits the scope of `opts` and will help a later commit fix a
memory leak without having to worry about those ear
This is a reroll of my attempt at freeing the memory allocated by
`setup_unpack_trees_porcelain()`. The first two patches are identical to
v2. The third patch no longer relies on rather intimate knowledge of
which strings are on the heap and which pointers are duplicates.
Instead, as suggested by J
On Fri, 18 May 2018, Sybille Peters wrote:
> My 2c on this:
>
> 1) "If the --keep-index option is used, all changes already added to
>the index are left intact" (manpage git stash)
>
> That appears to be correct and clear
>
>
> 2) "$ git stash push --keep-index # save *all other* changes to th
From: Leif Middelschulte
This is a follow-up on Junio C Hamano's comments [0] and Stefan Beller's request
[1] for a more explainatory/elaborate commit message.
[0] https://public-inbox.org/git/xmqqk1s474vx@gitster-ct.c.googlers.com/
[1] https://public-inbox.org/git/20180517184008.25445-1-sbe
From: Leif Middelschulte
Silent fast-forwarding might lead to inconveniences in cases where
submodules are expected to have a certain revision, because 'more recent'
(therefore fast-forwardable) versions might break behavior/contain regressions.
A use-case is the integration (merge) phase as par
From: Leif Middelschulte
This is a follow-up on Junio C Hamano's comments [0] and Stefan Beller's request
[1] for a more explainatory/elaborate commit message.
[0] https://public-inbox.org/git/xmqqk1s474vx@gitster-ct.c.googlers.com/
[1] https://public-inbox.org/git/20180517184008.25445-1-sbe
On Fri, May 18, 2018 at 10:17 AM, SZEDER Gábor wrote:
> The tests added in 2f271cd9cf (t9902-completion: add tests
> demonstrating issues with quoted pathnames, 2018-05-08) and in
> 2ab6eab4fe (completion: improve handling quoted paths in 'git
> ls-files's output, 2018-03-28) have a few shortcomin
On Thu, May 17, 2018 at 9:00 PM, Simon Ruderich wrote:
> On Thu, May 17, 2018 at 12:46:51PM -0700, Stefan Beller wrote:
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> index bb9f1b7cd82..7b2527b9a19 100644
>> --- a/Documentation/diff-options.txt
>> +++ b/Document
Здравствуйте, дорогой, мне нужен ваш срочный ответ. У меня есть
хорошая новость для вас.
Мишель
благодаря
I've been trying to hook together a build script and a GIT repo.
At one points it makes the following calls:
git diff --find-copies-harder --find-renames=101% --name-only
--diff-filter=ACMRT 'refs/tags/0.0.25' 'refs/tags/0.0.27' > modified.txt
git diff --find-copies-harder --find-renames=101% -
How about a hook to ignore certain files? Then you could ignore based on the
contents of the fail instead of just the extension. It’d be very flexible.
> On May 18, 2018, at 2:09 PM, Jacob Keller wrote:
>
> On Fri, May 18, 2018 at 4:31 AM, Anmol Sethi wrote:
>> This definitely works but it wou
On Fri, May 18, 2018 at 4:31 AM, Anmol Sethi wrote:
> This definitely works but it would be more clean to just have git ignore the
> binary files from the get go.
>
Sure it'd be more convenient for you. But there are loads of possible
combinations, and the idea of what constitutes unwanted files
On 18/05/18 03:16, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> diff --git a/commit.c b/commit.c
>> index 57049118a5..8202067cd5 100644
>> --- a/commit.c
>> +++ b/commit.c
>> @@ -1574,13 +1574,21 @@ int commit_tree_extended(const char *msg, size_t
>> msg_len,
>> return resul
On 18 May 2018 at 17:43, Robert P. J. Day wrote:
> On Fri, 18 May 2018, Sybille Peters wrote:
>
>> My 2c on this:
>>
>> 1) "If the --keep-index option is used, all changes already added to
>>the index are left intact" (manpage git stash)
>>
>> That appears to be correct and clear
>
> yup, th
Git guidelines states that I should leave cc intact. I have altered
it, as I wanted to reply to both of you. I hope that my approach can
be considered acceptable.
Johannes, I see the following line in the piece of code you quoted:
EditorAvailable[GE_NotepadPlusPlus]:=RegQueryStringValue(HKEY_LO
On Fri, 18 May 2018, Sybille Peters wrote:
> My 2c on this:
>
> 1) "If the --keep-index option is used, all changes already added to
>the index are left intact" (manpage git stash)
>
> That appears to be correct and clear
yup, that's not the issue.
> 2) "$ git stash push --keep-index # sav
On May 18, 2018 7:31 AM, Anmol Sethi
> That works but most binaries do not have a file extension. Its just not
> standard on linux.
>
> > On May 17, 2018, at 8:37 AM, Randall S. Becker
> wrote:
> >
> > On May 16, 2018 11:18 PM, Jacob Keller
> >> On Wed, May 16, 2018 at 5:45 PM, Anmol Sethi wrot
My 2c on this:
1) "If the --keep-index option is used, all changes already added to the
index are left intact" (manpage git stash)
That appears to be correct and clear
2) "$ git stash push --keep-index # save *all other* changes to the
stash" (manpage git stash)
That is either not corr
On 15.05.18 20:04, Frank Schäfer wrote:
> Am 14.05.2018 um 20:13 schrieb Torsten Bögershausen:
>> ^M is the representation of a "Carriage Return" or CR.
>> Under Linux/Unix/Mac OS X a line is terminated with a single
>> "line feed", LF.
>>
>> Windows typically uses CRLF at the end of the line.
>> "
In __gitcomp_file_direct() we tell Bash that it should handle our
possible completion words as filenames with the following piece of
cleverness:
# use a hack to enable file mode in bash < 4
compopt -o filenames +o nospace 2>/dev/null ||
compgen -f /non-existing-dir/ > /dev/null
Unfortunatel
> > So, I think for v2 I will rewrite these tests to call
> > __git_complete_index_file() directly instead of using
> > 'test_completion', and will include a test with spaces in path names.
>
> Quite well thought-out reasoning. Thanks.
Unfortunately I couldn't get around to it soon enough, and n
The tests added in 2f271cd9cf (t9902-completion: add tests
demonstrating issues with quoted pathnames, 2018-05-08) and in
2ab6eab4fe (completion: improve handling quoted paths in 'git
ls-files's output, 2018-03-28) have a few shortcomings:
- All these test use the 'test_completion' helper functi
On 18 May 2018 at 12:51, Robert P. J. Day wrote:
> On Fri, 18 May 2018, Martin Ågren wrote:
>
>> On 18 May 2018 at 11:37, Robert P. J. Day wrote:
>> >
>> > toward the bottom of "man git-stash", one reads part of an example:
>> >
>> > # ... hack hack hack ...
>> > $ git add --patch foo
On 9 May 2018 at 16:32, Romain Merland wrote:
> On a daily work with multiple local git branches, the usual way to submit
> only a
> specified commit was to cherry-pick the commit on master then run git-p4
> submit.
> It can be very annoying to switch between local branches and master, only to
>
This definitely works but it would be more clean to just have git ignore the
binary files from the get go.
> On May 16, 2018, at 11:18 PM, Jacob Keller wrote:
>
> On Wed, May 16, 2018 at 5:45 PM, Anmol Sethi wrote:
>> I think it’d be great to have an option to have git ignore binary files. My
That works but most binaries do not have a file extension. Its just not
standard on linux.
> On May 17, 2018, at 8:37 AM, Randall S. Becker wrote:
>
> On May 16, 2018 11:18 PM, Jacob Keller
>> On Wed, May 16, 2018 at 5:45 PM, Anmol Sethi wrote:
>>> I think it’d be great to have an option to ha
On Fri, 18 May 2018, Martin Ågren wrote:
> On 18 May 2018 at 11:37, Robert P. J. Day wrote:
> >
> > toward the bottom of "man git-stash", one reads part of an example:
> >
> > # ... hack hack hack ...
> > $ git add --patch foo# add just first part to the index
> > $ git stash
On 18 May 2018 at 11:37, Robert P. J. Day wrote:
>
> toward the bottom of "man git-stash", one reads part of an example:
>
> # ... hack hack hack ...
> $ git add --patch foo# add just first part to the index
> $ git stash push --keep-index# save all other changes to the sta
Здравствуйте, дорогой, мне нужен ваш срочный ответ. У меня есть
хорошая новость для вас.
Мишель
благодаря
toward the bottom of "man git-stash", one reads part of an example:
# ... hack hack hack ...
$ git add --patch foo# add just first part to the index
$ git stash push --keep-index# save all other changes to the stash
^ ???
Start using oid_object_info_extended(). So, if info from this function
is enough, we do not need to get and parse whole object (as it was before).
It's good for 3 reasons:
1. Some Git commands potentially will work faster.
2. It's much easier to add support for objectsize:disk and deltabase.
(I
1 - 100 of 104 matches
Mail list logo
