Re: worktrees vs. alternates

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

Re: [PATCH v2 14/14] commit.h: delete 'util' field in struct commit

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

[PATCH v3 10/15] name-rev: use commit-slab for rev-name instead of commit->util

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

[PATCH v3 03/15] blame: use commit-slab for blame suspects instead of commit->util

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

[PATCH v3 05/15] shallow.c: use commit-slab for commit depth instead of commit->util

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

[PATCH v3 06/15] sequencer.c: use commit-slab to mark seen commits

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 +++

[PATCH v3 14/15] merge: use commit-slab in merge remote desc instead of commit->util

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

[PATCH v3 01/15] commit-slab.h: code split

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

[PATCH v3 15/15] commit.h: delete 'util' field in struct commit

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

[PATCH v3 02/15] commit-slab: support shared commit-slab

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 +-

[PATCH v3 11/15] show-branch: use commit-slab for commit-name instead of commit->util

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

[PATCH v3 13/15] log: use commit-slab in prepare_bases() instead of commit->util

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 +++

[PATCH v3 00/15] Die commit->util, die!

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

[PATCH v3 04/15] describe: use commit-slab for commit names instead of commit->util

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 ---

[PATCH v3 09/15] bisect.c: use commit-slab for commit weight instead of commit->util

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

[PATCH v3 07/15] sequencer.c: use commit-slab to associate todo items to commits

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 +++

[PATCH v3 08/15] revision.c: use commit-slab for show_source

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 +-

[PATCH v3 12/15] show-branch: note about its object flags usage

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

Re: [PATCH v2 11/14] show-branch: use commit-slab for commit-name instead of commit->util

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

Re: [PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

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

[PATCH v2] travis-ci: run gcc-8 on linux-gcc jobs

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

[PATCH 12/14] completion: let git provide the completable command list

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

[PATCH 11/14] command-list.txt: documentation and guide line

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

[PATCH 13/14] completion: reduce completable command list

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

[PATCH 04/14] Remove common-cmds.h

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 ++---

[PATCH 05/14] git.c: convert --list-* to --list-cmds=*

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

[PATCH 01/14] generate-cmds.sh: factor out synopsis extract code

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

[PATCH 06/14] git --list-cmds: collect command list in a string_list

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

[PATCH 02/14] generate-cmds.sh: export all commands to command-list.h

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

[PATCH 07/14] completion: implement and use --list-cmds=main,others

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

[PATCH 10/14] help: use command-list.txt for the source of guides

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

[PATCH 03/14] help: use command-list.h for common command list

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

[PATCH 14/14] completion: allow to customize the completable command list

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

[PATCH 09/14] help: add "-a --verbose" to list all commands with synopsis

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

[PATCH 00/14] nd/command-list updates

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

[PATCH 08/14] git: support --list-cmds=list-

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.

Fun puzzle: successful merge's contents depends on...commit timestamps?

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

[PATCH 4/5] merge-recursive: rename conflict_rename_*() family of functions

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

[PATCH 3/5] merge-recursive: clarify the rename_dir/RENAME_DIR meaning

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

[PATCH 1/5] merge-recursive: fix miscellaneous grammar error in comment

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

[PATCH 2/5] merge-recursive: fix numerous argument alignment issues

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

[PATCH 0/5] merge-recursive code cleanups

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

[PATCH 5/5] merge-recursive: simplify handle_change_delete

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 ---

[PATCH 5/5] fmt_with_err: add a comment that truncation is OK

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,

[PATCH 4/5] shorten_unambiguous_ref: use xsnprintf

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

[PATCH 3/5] query_fsmonitor: use xsnprintf for formatting integers

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(+),

[PATCH 2/5] log_write_email_headers: use strbufs

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

[PATCH 1/5] http: use strbufs instead of fixed buffers

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

[PATCH 0/5] snprintf truncation fixes

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.

FROM LEONARD PAKKER

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

Re: [PATCH v3 3/3] unpack_trees_options: free messages when done

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(>msgs_to_free, msg, cmd, cmd)->string; > > > > I don't know if that's worth it or not (I suspect that there are

Re: [PATCH 0/2] fix a segfault in get_main_ref_store()

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]:

Re: [PATCH 1/2] get_main_ref_store: BUG() when outside a repository

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

Re: [PATCH 2/2] config: die when --blob is used outside a repository

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

Re: [PATCH v3 3/3] unpack_trees_options: free messages when done

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

[PATCH 2/2] config: die when --blob is used outside a repository

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,

[PATCH 1/2] get_main_ref_store: BUG() when outside a repository

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

[PATCH 0/2] fix a segfault in get_main_ref_store()

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]:

Re: [PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

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

Re: [PATCH] t7005-editor: get rid of the SPACES_IN_FILENAMES prereq

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,

Re: [PATCH v3 3/3] unpack_trees_options: free messages when done

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, >

Re: [PATCH 1/1] Inform about fast-forwarding of submodules during merge

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

[PATCH v3 3/3] unpack_trees_options: free messages when done

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

[PATCH v3 2/3] merge-recursive: provide pair of `unpack_trees_{start,finish}()`

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

[PATCH v3 1/3] merge: setup `opts` later in `checkout_fast_forward()`

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

[PATCH v3 0/3] unpack_trees_options: free messages when done

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

Re: error(?) in "man git-stash" regarding "--keep-index"

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

[PATCH v3 0/1] rebased: inform about auto submodule ff

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]

[PATCH 1/1] Inform about fast-forwarding of submodules during merge

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

[PATCH v2 0/1] rebased: inform about auto submodule ff

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]

Re: [PATCH 2/2] t9902-completion: exercise __git_complete_index_file() directly

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,

Re: [PATCH 6/8] diff.c: decouple white space treatment from move detection algorithm

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 >> ---

благодаря

Здравствуйте, дорогой, мне нужен ваш срочный ответ. У меня есть хорошая новость для вас. Мишель благодаря

--diff-filter could use option for pre-rename files

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%

Re: Add option to git to ignore binary files unless force added

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

Re: Add option to git to ignore binary files unless force added

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

Re: [PATCH v2 13/14] merge: use commit-slab in merge remote desc instead of commit->util

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,

Re: error(?) in "man git-stash" regarding "--keep-index"

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

Re: Troubles with picking an editor during Git update

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:

Re: error(?) in "man git-stash" regarding "--keep-index"

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 #

RE: Add option to git to ignore binary files unless force added

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,

Re: error(?) in "man git-stash" regarding "--keep-index"

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

Re: git diff: meaning of ^M at line ends ?

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. >>

[PATCH 1/2] completion: don't return with error from __gitcomp_file_direct()

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

[PATCH 0/2] Test improvements for 'sg/complete-paths'

> > 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

[PATCH 2/2] t9902-completion: exercise __git_complete_index_file() directly

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

Re: error(?) in "man git-stash" regarding "--keep-index"

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

Re: [PATCH] git-p4: add options --commit and --disable-rebase

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

Re: Add option to git to ignore binary files unless force added

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

Re: Add option to git to ignore binary files unless force added

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

Re: error(?) in "man git-stash" regarding "--keep-index"

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

Re: error(?) in "man git-stash" regarding "--keep-index"

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

благодаря

Здравствуйте, дорогой, мне нужен ваш срочный ответ. У меня есть хорошая новость для вас. Мишель благодаря

error(?) in "man git-stash" regarding "--keep-index"

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 ^ ???

[PATCH RFC v2 1/4] ref-filter: start using oid_object_info

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

[PATCH RFC v2 2/4] ref-filter: add objectsize:disk formatting option

Add %(objectsize:disk) support. It is still not working for deref: I am thinking how to support it in a more elegant way. Signed-off-by: Olga Telezhnaia --- ref-filter.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) diff --git

[PATCH RFC v2 3/4] ref-filter: add tests for objectsize:disk

Add tests for %(objectsize:disk) atom. Signed-off-by: Olga Telezhnaia --- t/t6300-for-each-ref.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh index 295d1475bde01..570bb606045d7 100755 ---

[PATCH RFC v2 4/4] ref-filter: add deltabase formatting option

Add %(deltabase) support. It is still not working for deref: I am thinking how to support it in a more elegant way. Signed-off-by: Olga Telezhnaia --- ref-filter.c | 12 1 file changed, 12 insertions(+) diff --git a/ref-filter.c b/ref-filter.c index

[PATCH RFC v2 0/4] ref-filter: start using oid_object_info

Hello, Discussion starts here: [1], [2]. Updates: I fixed memory leaks, now we use data from oid_object_info() OR from grab_commom_values() - not both as it was before. I added support for "%(objectsize:disk)" atom (with tests) and for "%(deltabase)" atom (without tests yet). I didn't support

Re: [PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

Taylor Blau writes: > * `git grep --and -e foo -e bar`. This binary operation should recur > on its sub-expressions and take the minimum of the starting offset > and the maximum of the ending offset. We use infix notation, so the above is "git grep -e foo --and -e

  1   2   >