On Mon, Dec 12, 2016 at 10:02 PM, Markus Hitter wrote:
> Am 12.12.2016 um 09:34 schrieb Chris Packham:
>> Teach 'git merge' the --continue option which allows 'continuing' a
>> merge by completing it. The traditional way of completing a merge after
>> resolving conflicts is to use 'git commit'. No
Hi all,
I encountered the following assertion failure when running in a local
clone of the https://github.com/nodejs/node.git repository:
$ git log -L:writeFileSync:lib/fs.js -L:appendFileSync:lib/fs.js aa67b1^..aa67b1
git: line-log.c:71: range_set_append: Assertion `rs->nr == 0 ||
rs->ranges[rs
Teach 'git merge' the --continue option which allows 'continuing' a
merge by completing it. The traditional way of completing a merge after
resolving conflicts is to use 'git commit'. Now with commands like 'git
rebase' and 'git cherry-pick' having a '--continue' option adding such
an option to 'gi
Add 'git merge --continue' option when completing.
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
- new.
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-c
Add cppcheck target to Makefile. Cppcheck is a static
analysis tool for C/C++ code. Cppcheck primarily detects
the types of bugs that the compilers normally do not detect.
It is an useful target for doing QA analysis.
Based-on-patch-by: Elia Pinto
Signed-off-by: Chris Packham
---
I had been play
On Tue, Dec 13, 2016 at 10:22 PM, Chris Packham wrote:
> Add cppcheck target to Makefile. Cppcheck is a static
> analysis tool for C/C++ code. Cppcheck primarily detects
> the types of bugs that the compilers normally do not detect.
> It is an useful target for doing QA analysis.
>
> Based-on-patc
Am 13.12.2016 um 10:32 schrieb Chris Packham:
> On Tue, Dec 13, 2016 at 10:22 PM, Chris Packham
> wrote:
>> Add cppcheck target to Makefile. Cppcheck is a static
>> analysis tool for C/C++ code. Cppcheck primarily detects
>> the types of bugs that the compilers normally do not detect.
>> It is an
A Sáb, 10-12-2016 às 14:09 -0800, Junio C Hamano escreveu:
> We only update comment_line_char from the default "#" when the
> configured value is a single-byte character and we ignore incorrect
> values in the configuration file. So I think the patch you sent is
> correct after all.
I am still no
On Sun, Dec 11, 2016 at 2:19 PM, Luke Diamand wrote:
> On 10 December 2016 at 21:57, Luke Diamand wrote:
>> git-p4 would attempt to find the git directory using
>> its own specific code, which did not know about git
>> worktrees. This caused git operations to fail needlessly.
>>
>> Rework it to u
On Tue, Dec 13, 2016 at 2:52 AM, Jeff King wrote:
> Instead, let's treat names as unquoted unless they begin
> with a double-quote, in which case they are interpreted via
> our usual C-stylke quoting rules. This also breaks
> backwards-compatibility, but in a smaller way: it only
> matters if your
On Mon, Dec 12, 2016 at 09:53:11PM +0100, Johannes Sixt wrote:
> > The appropriate check there would be ";" anyway, but I am not
> > sure _that_ is allowed in paths, either.
>
> That was also my line of thought. I tested earlier today whether a file name
> can have ";", and the OS did not reject
On Mon, Dec 12, 2016 at 02:37:08PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > So here are patches that do that. It kicks in only when the first
> > character of a path is a double-quote, and then expects the usual
> > C-style quoting.
>
> The quote being per delimited component is w
On Tue, Dec 13, 2016 at 06:30:15PM +0700, Duy Nguyen wrote:
> On Tue, Dec 13, 2016 at 2:52 AM, Jeff King wrote:
> > Instead, let's treat names as unquoted unless they begin
> > with a double-quote, in which case they are interpreted via
> > our usual C-stylke quoting rules. This also breaks
> > b
On Tue, Dec 13, 2016 at 09:48:58PM +1300, Chris Packham wrote:
> + if (continue_current_merge) {
> + int nargc = 1;
> + const char *nargv[] = {"commit", NULL};
> +
> + if (argc)
> + usage_msg_opt("--continue expects no arguments",
> +
On Tue, Dec 13, 2016 at 10:22:25PM +1300, Chris Packham wrote:
> $ make cppcheck
> cppcheck --force --quiet --inline-suppr .
> [compat/nedmalloc/malloc.c.h:4093]: (error) Possible null pointer
> dereference: sp
> [compat/nedmalloc/malloc.c.h:4106]: (error) Possible null pointer
> dereference: s
On Tue, Dec 13, 2016 at 07:15:10AM -0500, Jeff King wrote:
> I think these last two are a good sign that we need to be feeding the
> list of source files to cppcheck. I tried your patch and it also started
> looking in t/perf/build, which are old versions of git built to serve
> the performance-te
Thank you for reviewing this series, Philip.
Philip Oakley writes:
> This looks good to me.
I'll add this header:
Acked-by: Philip Oakley
To the commit message of this patch in the next review round (version 2
of the patch series).
Let me know if I should add another header, or do somet
Philip Oakley writes:
> Looks like a reasonable emphasis to me
I'll add this header:
Acked-by: Philip Oakley
To the commit message of this patch in the next review round (version 2
of the patch series).
Let me know if I should add another header, or do something different
than this.
--
With the commits f2f02675 and 5096d490 we have been converted in some files the
call from snprintf/sprintf/strcpy to xsnprintf. This patch supersedes the
snprintf with several calls that make use of the heap rather than fixed
length buffers (eg. PATH_MAX) that may be incorrect on some systems.
S
On Tue, Dec 13, 2016 at 01:27:17PM +, Elia Pinto wrote:
> With the commits f2f02675 and 5096d490 we have been converted in some files
> the call from snprintf/sprintf/strcpy to xsnprintf. This patch supersedes the
> snprintf with several calls that make use of the heap rather than fixed
> le
The 'exec' command is a little special among rebase -i's commands, as it
does *not* have a SHA-1 as first parameter. Instead, everything after the
`exec` command is treated as command-line to execute.
Let's reuse the arg/arg_len fields of the todo_item structure (which hold
the oneline for pick/ed
When calling `git rebase -i -v`, the user wants to see some statistics
after the commits were rebased. Let's show some.
The strbuf we use to perform that task will be used for other things
in subsequent commits, hence it is declared and initialized in a wider
scope than strictly needed here.
Sign
In the interactive rebase, commands that were successfully processed are
not simply discarded, but appended to the 'done' file instead. This is
used e.g. to display the current state to the user in the output of
`git status` or the progress.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 2
This patch is a straight-forward reimplementation of the `edit`
operation of the interactive rebase command.
Well, not *quite* straight-forward: when stopping, the `edit`
command wants to write the `patch` file (which is not only the
patch, but includes the commit message and author information).
In the upcoming patch, we will support rebase -i's progress
reporting. The progress skips comments but counts 'noop's.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 1f314b2743
This is a huge patch, and at the same time a huge step forward to
execute the performance-critical parts of the interactive rebase in a
builtin command.
Since 'fixup' and 'squash' are not only similar, but also need to know
about each other (we want to reduce a series of fixups/squashes into a
sin
When a cherry-pick continues without a "todo script", the intention is
simply to pick a single commit.
However, when an interactive rebase is continued without a "todo
script", it means that the last command has been completed and that we
now need to clean up.
This commit guards the revert/cherry
An interactive rebase operates on a detached HEAD (to keep the reflog
of the original branch relatively clean), and updates the branch only
at the end.
Now that the sequencer learns to perform interactive rebases, it also
needs to learn the trick to update the branch before removing the
directory
The parsing part of a 'drop' command is almost identical to parsing a
'pick', while the operation is the same as that of a 'noop'.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 0
When doing an interactive rebase, we want to leave a 'patch' file for
further inspection by the user (even if we never tried to actually apply
that patch, since we're cherry-picking instead).
Signed-off-by: Johannes Schindelin
---
sequencer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
When the last command of an interactive rebase fails, the user needs to
resolve the problem and then continue the interactive rebase. Naturally,
the todo script is empty by then. So let's not complain about that!
To that end, let's move that test out of the function that parses the
todo script, an
The interactive rebase has the very special magic that a cherry-pick
that exits with a status different from 0 and 1 signifies a failure to
even record that a cherry-pick was started.
This can happen e.g. when a fast-forward fails because it would
overwrite untracked files.
In that case, we must
Git's `rebase` command inspects the `rebase.autostash` config setting
to determine whether it should stash any uncommitted changes before
rebasing and re-apply them afterwards.
As we introduce more bits and pieces to let the sequencer act as
interactive rebase's backend, here is the part that adds
This will be needed to hide the output of `git commit` when the
sequencer handles an interactive rebase's script.
Signed-off-by: Johannes Schindelin
---
run-command.c | 23 +++
run-command.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/run-command.c b/run-command.c
The sequencer already has an idea about using different merge
strategies. We just piggy-back on top of that, using rebase -i's
own settings, when running the sequencer in interactive rebase mode.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 26 +-
1 file changed,
This makes the code DRYer, with the obvious benefit that we can enhance
the code further in a single place.
We can also reuse the functionality elsewhere by calling this new
function.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 33 ++---
1 file changed, 26 i
When continuing after a `pick` command failed, we want that commit
to show up in the rewritten-list (and its notes to be rewritten), too.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sequencer.c b/sequencer.c
index 7ab533abd9..02
We already used the same reflog message as the scripted version of rebase
-i when finishing. With this commit, we do that also for all the commands
before that.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 4
1 file changed, 4 insertions(+)
diff --git a/sequencer.c b/sequencer.c
in
The interactive rebase keeps the user informed about its progress.
If the sequencer wants to do the grunt work of the interactive
rebase, it also needs to show that progress.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 32
1 file changed, 32 insertions(+
When rebasing commits that have commit notes attached, the interactive
rebase rewrites those notes faithfully at the end. The sequencer must
do this, too, if it wishes to do interactive rebase's job.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 76
Signed-off-by: Johannes Schindelin
---
sequencer.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/sequencer.c b/sequencer.c
index 0233999389..cafd945e83 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1947,6 +1947,8 @@ static int pick_commits(struct todo_list *todo_list,
stru
This is now trivial, as all the building blocks are in place: all we need
to do is to flip the "edit" switch when committing.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 4361fe0e94
The sequencer already knew how to fast-forward instead of
cherry-picking, if possible.
We want to continue to do this, of course, but in case of the 'reword'
command, we will need to call `git commit` after fast-forwarding.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 25 +++
The 'noop' command is probably the most boring of all rebase -i commands
to support in the sequencer.
Which makes it an excellent candidate for this first stab to add support
for rebase -i's commands to the sequencer.
For the moment, let's also treat empty lines and commented-out lines as
'noop';
This patch introduces a new action for the sequencer. It really does not
do a whole lot of its own right now, but lays the ground work for
patches to come. The intention, of course, is to finally make the
sequencer the work horse of the interactive rebase (the original idea
behind the "sequencer" c
This marks the count down to '3': two more patch series after this
(really tiny ones) and we have a faster rebase -i.
The idea of this patch series is to teach the sequencer to understand
all of the commands in `git-rebase-todo` scripts, to execute them and to
behave pretty much very the same as `
For users' convenience, most rebase commands can be abbreviated, e.g.
'p' instead of 'pick' and 'x' instead of 'exec'. Let's teach the
sequencer to handle those abbreviated commands just fine.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 36 ++--
1 file ch
The scripted version of the interactive rebase already does that.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index 855d3ba503..abffaf3b40 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -183
When the interactive rebase aborts, it writes out an author-script file
to record the author information for the current commit. As we are about
to teach the sequencer how to perform the actions behind an interactive
rebase, it needs to write those author-script files, too.
Signed-off-by: Johannes
When an interactive rebase is interrupted, the user may stage changes
before continuing, and we need to commit those changes in that case.
Please note that the nested "if" added to the sequencer_continue() is
not combined into a single "if" because it will be extended with an
"else" clause in a la
This is the behavior of the shell script version of the interactive
rebase, by using the `output` function defined in `git-rebase.sh`.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 6
This is the behavior of the shell script version of the interactive
rebase, by using the `output` function defined in `git-rebase.sh`.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 4
1 file changed, 4 insertions(+)
diff --git a/sequencer.c b/sequencer.c
index dfa4fab98b..edc213a2c8
Hi Junio,
On Mon, 12 Dec 2016, Junio C Hamano wrote:
> * js/mingw-isatty (2016-12-11) 1 commit
> (merged to 'next' on 2016-12-12 at 60c1da6676)
> + mingw: intercept isatty() to handle /dev/null as Git expects it
>
> We often decide if a session is interactive by checking if the
> standard I
For the benefit of e.g. the shell prompt, the interactive rebase not
only displays the progress for the user to see, but also writes it into
the msgnum/end files in the state directory.
Teach the sequencer this new trick.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 30 +
The shell script version of the interactive rebase has a very specific
final message. Teach the sequencer to print the same.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sequencer.c b/sequencer.c
index cb5e7f35fc..41be4cde16 100644
---
This is the same behavior as known from `git rebase -i`.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index edc213a2c8..498dd028d1 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1355,8 +1355,
Hi Junio,
On Mon, 12 Dec 2016, Junio C Hamano wrote:
> * jc/bundle (2016-03-03) 6 commits
> - index-pack: --clone-bundle option
> - Merge branch 'jc/index-pack' into jc/bundle
> - bundle v3: the beginning
> - bundle: keep a copy of bundle file name in the in-core bundle header
> - bundle: pl
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 12 Dec 2016, Junio C Hamano wrote:
>
>> * js/mingw-isatty (2016-12-11) 1 commit
>> (merged to 'next' on 2016-12-12 at 60c1da6676)
>> + mingw: intercept isatty() to handle /dev/null as Git expects it
>>
>> We often decide if a session is int
Johannes Schindelin writes:
>> While I think it would make it easier for people to experiment and
>> build on if the topic is merged to 'next', I am at the same time a
>> bit reluctant to merge an unproven new topic that introduces a new
>> file format, which we may end up having to support t
On Wed, Nov 30, 2016 at 11:36 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> For now there should be one odb ref per blob. Each ref name should be
>> refs/odbs// where is the sha1 of the blob stored
>> in the external odb named .
>>
>> These odb refs should all point to a blob that sh
On Sat, Dec 3, 2016 at 7:47 PM, Lars Schneider wrote:
>
>> On 30 Nov 2016, at 22:04, Christian Couder
>> wrote:
>>
>> Goal
>>
>>
>> Git can store its objects only in the form of loose objects in
>> separate files or packed objects in a pack file.
>>
>> To be able to better handle some kind
On Mon, Dec 12, 2016 at 09:31:03PM +0100, Stephan Beyer wrote:
> I am also a "git add -p"-only user (except for new files and merges).
> However, I usually keep a lot of untracked files in my repositories.
> Files that I do not (git)ignore because I want to see them when I type
> "git status".
>
On Mon, Dec 12, 2016 at 7:28 PM, brian m. carlson
wrote:
> On Mon, Dec 12, 2016 at 05:40:55PM -0800, Stefan Beller wrote:
>> When deleting a submodule we need to keep the actual git directory around,
>> such that we do not lose local changes in there and at a later checkout
>> of the submodule we
On Mon, Dec 12, 2016 at 11:28 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> The "checkout --recurse-submodules" series got too large to comfortably send
>> it out for review, so I had to break it up into smaller series'; this is the
>> first subseries, but it makes sense on its own.
>>
>
Chris Packham writes:
> +'git merge' --continue
>
> DESCRIPTION
> ---
> @@ -61,6 +62,9 @@ reconstruct the original (pre-merge) changes. Therefore:
> discouraged: while possible, it may leave you in a state that is hard to
> back out of in the case of a conflict.
>
> +The fourth sy
> -Original Message-
> From: Stefan Beller [mailto:sbel...@google.com]
> Sent: Monday, December 12, 2016 8:41 PM
> To: gits...@pobox.com
> Cc: git@vger.kernel.org; David Turner; bmw...@google.com; Stefan Beller
> Subject: [PATCH 6/6] rm: add absorb a submodules git dir before deletion
>
>
Duy Nguyen writes:
> At least attr has the same problem and is going the same direction
> [1]. Cool. (I actually thought the patch was in and evidence that this
> kind of backward compatibility breaking was ok, turns out the patch
> has stayed around for years)
>
> [1]
> http://public-inbox.org/
Jeff King writes:
> The naive conversion is just:
> ...
> -# MINGW does not allow colons in pathnames in the first place
> -test_expect_success !MINGW 'push to repo path with colon' '
> +if test_have_prereq MINGW
> +then
> + path_sep=';'
> +else
> + path_sep=':'
> +fi
> ...
> - git cl
Jeff King writes:
> On Mon, Dec 12, 2016 at 02:37:08PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > So here are patches that do that. It kicks in only when the first
>> > character of a path is a double-quote, and then expects the usual
>> > C-style quoting.
>>
>> The quote bein
Kristoffer Haugsbakk writes:
> Thank you for reviewing this series, Philip.
>
> Philip Oakley writes:
>
>> This looks good to me.
>
> I'll add this header:
>
> Acked-by: Philip Oakley
>
> To the commit message of this patch in the next review round (version 2
> of the patch series).
>
> Let
Vasco Almeida writes:
>> We only update comment_line_char from the default "#" when the
>> configured value is a single-byte character and we ignore incorrect
>> values in the configuration file. So I think the patch you sent is
>> correct after all.
>
> I am still not sure what version do we pre
On Tue, Dec 13, 2016 at 10:10:04AM -0800, Junio C Hamano wrote:
> > - git clone --bare . xxx:yyy.git &&
> > + git clone --bare . xxx${path_sep}yyy.git &&
>
> Don't you want to dq the whole thing to prevent the shell from
> splitting this into two commands at ';'? The other one below is OK.
On Tue, Dec 13, 2016 at 10:10:54AM -0800, Junio C Hamano wrote:
> > We do support non-absolute paths, both in alternates files and
> > environment variables. It's a nice feature if you want to have a
> > relocatable family of shared repositories. I'd imagine that most cases
> > start with "../", t
Jeff King writes:
> Right, but we also support relative paths via environment variables. I
> don't think that changes the conclusion though. I'm not convinced
> relative paths via the environment aren't slightly insane in the first
> place,
Sorry, a triple negation is above my head. "relative p
Jeff King writes:
>> I am also not really sure what problem this feature is trying to solve.
>> If the "problem"(?) is that it should act more like "git add" instead of
>> "git add -u", for whatever reason, this may be fine (but the
>> configuration option is a must-have then).
>
> I think the pr
On Tue, Dec 13, 2016 at 10:42:39AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Right, but we also support relative paths via environment variables. I
> > don't think that changes the conclusion though. I'm not convinced
> > relative paths via the environment aren't slightly insane in
Stefan Beller writes:
> On Mon, Dec 12, 2016 at 11:28 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> The "checkout --recurse-submodules" series got too large to comfortably send
>>> it out for review, so I had to break it up into smaller series'; this is the
>>> first subseries, but
On Tue, Dec 13, 2016 at 10:48:07AM -0800, Junio C Hamano wrote:
> > I think the problem is just that "add -p" does not give the whole story
> > of what you might want to do before making a commit.
>
> The same is shared by "git diff [HEAD]", by the way. It is beyond
> me why people use "add -p",
Jeff King writes:
>> +argv_array_pushf(&env, "GIT_INDEX_FILE=%s", index_file);
>> +if (launch_editor(git_path_commit_editmsg(), NULL, env.argv)) {
>> fprintf(stderr,
>> _("Please supply the message using either -m or -F
>> option.
On Tue, Dec 13, 2016 at 10:53 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Mon, Dec 12, 2016 at 11:28 PM, Junio C Hamano wrote:
>>> Stefan Beller writes:
>>>
The "checkout --recurse-submodules" series got too large to comfortably
send
it out for review, so I had to
To perform the test case on Windows in a way that corresponds to the
POSIX version, inject the semicolon in a directory name.
Typically, an absolute POSIX style path, such as the one in $PWD, is
translated into a Windows style path by bash when it invokes git.exe.
However, the presence of the semi
On Tue, Dec 13, 2016 at 11:03:53AM -0800, Junio C Hamano wrote:
> >> @@ -1525,12 +1526,10 @@ static int git_commit_config(const char *k, const
> >> char *v, void *cb)
> >> static int run_rewrite_hook(const unsigned char *oldsha1,
> >>const unsigned char *newsha1)
> >> {
Stefan Beller writes:
>> I do not think there is no dispute about what embedding means.
>
> double negative: You think we have a slight dispute here.
Sorry, I do not think there is any dispute on that.
>> A
>> submodule whose .git is inside its working tree has its repository
>> embedded.
>>
>
Jeff King writes:
>> Perhaps the latter is not advertised well enough? "add -p" does not
>> even page so it is not very useful way to check what is being added
>> if you are adding a new file (unless you are doing a toy example to
>> add a 7-line file).
>
> I use "add -p" routinely for my final
On Tue, Dec 13, 2016 at 08:09:31PM +0100, Johannes Sixt wrote:
> Am 12.12.2016 um 20:53 schrieb Jeff King:
> > Johannes, please let me know if I am wrong about skipping the test on
> > !MINGW. The appropriate check there would be ";" anyway, but I am not
> > sure _that_ is allowed in paths, either
Hi Junio,
On Mon, 12 Dec 2016, Junio C Hamano wrote:
> * bw/grep-recurse-submodules (2016-11-22) 6 commits
> - grep: search history of moved submodules
> - grep: enable recurse-submodules to work on objects
> - grep: optionally recurse into submodules
> - grep: add submodules as a grep sourc
Johannes Sixt writes:
> To perform the test case on Windows in a way that corresponds to the
> POSIX version, inject the semicolon in a directory name.
>
> Typically, an absolute POSIX style path, such as the one in $PWD, is
> translated into a Windows style path by bash when it invokes git.exe.
Johannes Schindelin writes:
> ok 13 - grep tree and more pathspecs
>
> expecting success:
> git init parent &&
> test_when_finished "rm -rf parent" &&
> echo "foobar" >"parent/fi:le" &&
> git -C parent add "fi:le" &&
> git -C parent commit -m "add fi:le" &&
> ...
>
Hi,
While we're on the topic that "git add -p" should behave like the
"normal" "git add" (not "git add -u"): what about unmerged changes?
When I have merge conflicts, I almost always use my aliases
"edit-unmerged" and "add-unmerged":
$ git config --global --list | grep unmerged
alias.list-unmerg
On Tue, Dec 13, 2016 at 11:13 AM, Stefan Beller wrote:
> On Tue, Dec 13, 2016 at 11:11 AM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
I do not think there is no dispute about what embedding means.
>>>
>>> double negative: You think we have a slight dispute here.
>>
>> Sorry, I do not
Johannes Schindelin writes:
> This marks the count down to '3': two more patch series after this
> (really tiny ones) and we have a faster rebase -i.
Nice.
> Apart from mostly cosmetic patches (and the occasional odd bug that I
> fixed promptly), I used these patches since mid May to perform al
On Tue, Dec 13, 2016 at 11:11 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> I do not think there is no dispute about what embedding means.
>>
>> double negative: You think we have a slight dispute here.
>
> Sorry, I do not think there is any dispute on that.
>
>>> A
>>> submodule whose
Stefan Beller writes:
> The desired standard for submodules is to have the git dir inside the
> superprojects git dir (since 501770e, Aug 2011, Move git-dir for
> submodules), which is why I think an "embedded submodule git dir"
> is inside the superproject already.
Think how you start a new su
On Tue, Dec 13, 2016 at 08:21:59PM +0100, Stephan Beyer wrote:
> While we're on the topic that "git add -p" should behave like the
> "normal" "git add" (not "git add -u"): what about unmerged changes?
I agree that's a related part of the workflow, though the implementation
is a bit harder.
> Whe
Stefan Beller writes:
> I guess the latter is the case, so embedding is actually inside
> the working tree and un-embedding is the relocation to the
> superproject.
Another reason why I personally see a .git in each submodule working
tree is "embedded" has nothing to do with Git. It is an analo
Stephan Beyer writes:
> While we're on the topic that "git add -p" should behave like the
> "normal" "git add" (not "git add -u"): what about unmerged changes?
>
>
> When I have merge conflicts, I almost always use my aliases
> "edit-unmerged" and "add-unmerged":
>
> $ git config --global --list
Christian Couder writes:
> In general I think that having a lot of refs is really a big problem
> right now in Git as many big organizations using Git are facing this
> problem in one form or another.
> So I think that support for a big number of refs is a separate and
> important problem that sh
On Tue, Dec 13, 2016 at 11:47 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> The desired standard for submodules is to have the git dir inside the
>> superprojects git dir (since 501770e, Aug 2011, Move git-dir for
>> submodules), which is why I think an "embedded submodule git dir"
>> i
Jeff King writes:
> On Tue, Dec 13, 2016 at 10:10:04AM -0800, Junio C Hamano wrote:
>
>> > - git clone --bare . xxx:yyy.git &&
>> > + git clone --bare . xxx${path_sep}yyy.git &&
>>
>> Don't you want to dq the whole thing to prevent the shell from
>> splitting this into two commands at ';'? Th
On Tue, Dec 13, 2016 at 12:09 PM, Stefan Beller wrote:
>
> So I will reroll it with "absorb" fixing some nits pointed out by David?
I got confused there, Davids nits are for this series, the absorb series itself
doesn't seem to have nits.
So I'll just reroll this series on top of the currently
s
1 - 100 of 161 matches
Mail list logo
