Hello, git enthusiasts,
I’d like to report what I suspect is a bug in Git, tested in 2.18 and 2.14.
(I’d be delighted to be corrected if it is my own misunderstanding.) I’m
reporting it here based on guidance from https://git-scm.com/community.
I created a minimal testcase with a detailed
+cc: Stefan, who has been looking at fetch --recurse-submodules recently
Hi,
Jonathon Reinhart wrote:
> I've narrowed it down to an observation that the [http] config seems
> to be ignored by 'git submodule update'. Shouldn't those options be
> respected by submodules?
>
> Given a .git/config
On Thu, Aug 09, 2018 at 11:40:27AM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: [PATCH] gpg-interface: propagate exit status from gpg back to the
> callers
>
> When gpg-interface API unified support for signature verification
> codepaths for signed tags and signed commits in mid 2015 at
Hi,
Jeff King wrote:
> Bartosz Konikiewicz wrote:
>> Steps to reproduce:
>>
>> 1. Create a new file.
>> 2. Stage the file.
>> 3. Add the file to .gitignore.
>> 4. Stage the .gitignore.
>> 5. Commit changes.
[...]
> As far as I know, that is not an intentionally supported workflow. It is
> merely
> @@ -209,7 +210,8 @@ static inline void finish_object__ma(struct object *obj)
>*/
> switch (arg_missing_action) {
> case MA_ERROR:
> - die("missing blob object '%s'", oid_to_hex(>oid));
> + die("missing %s object '%s'",
> +
> Teach list-objects the "only:commits" filter which allows for filtering
> out all non-commit and non-annotated tag objects (unless other objects
> are explicitly specified by the user). The purpose of this patch is to
> allow smaller partial clones.
>
> The name of this filter - only:commits -
Signed-off-by: Stefan Beller
---
range-diff.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/range-diff.c b/range-diff.c
index a977289b7dc..fbabce5f91f 100644
--- a/range-diff.c
+++ b/range-diff.c
@@ -264,6 +264,8 @@ static void get_correspondences(struct string_list *a,
struct
I instrumented range-diff to use different diff algorithms for the patches,
(I chose default-myers and patience) and then run on the same range,
via ./git-range-diff v2.10.0..HEAD v2.10.0..HEAD
and I found 5245 same, 304 slightly different and 4 completely different
patches in that range.
Looking
We can use the range-diff on the same range to examine differences in the
diff algorithm.
Signed-off-by: Stefan Beller
---
range-diff.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/range-diff.c b/range-diff.c
index 347b4a79f25..a977289b7dc 100644
---
On Thu, Aug 9, 2018 at 2:59 PM Jeff King wrote:
> On Thu, Aug 09, 2018 at 02:53:42PM -0700, Elijah Newren wrote:
>
> > On Thu, Aug 9, 2018 at 2:44 PM Jeff King wrote:
> > > > The error message isn't quite as good, but does the user really need
> > > > all the names of the file? If so, we gave
I've been trying to track down an issue with the GitLab CI Runner:
https://gitlab.com/gitlab-org/gitlab-runner/issues/3497
Note that I'm using "git version 2.7.2.windows.1".
I've narrowed it down to an observation that the [http] config seems
to be ignored by 'git submodule update'. Shouldn't
Abandon the previous approach of mutating all new objects implicitly in
add_pending_object by inverting the meaning of the bit (it is now
NOT_USER_GIVEN) and only setting the flag when we need to.
This more accurately tracks if a tree was provided directly by the user.
Without this patch, the
This will be used in a follow-up patch to reduce indentation needed when
invoking the logic conditionally. i.e. rather than:
if (foo) {
while (...) {
/* this is very indented */
}
}
we will have:
if (foo)
process_tree_contents(...);
Signed-off-by:
Teach list-objects the "only:commits" filter which allows for filtering
out all non-commit and non-annotated tag objects (unless other objects
are explicitly specified by the user). The purpose of this patch is to
allow smaller partial clones.
The name of this filter - only:commits - is a bit
This patch series does two things:
a. (patches 1-2) introduces "--filter=only:commits" which filters trees and
blobs
b. (patches 3-5) better support for promisor trees in the rev-list command
The intention is to enable initial partial clones to be very tiny by only
including commits.
Previously, we assumed only blob objects could be missing. This patch
makes rev-list handle missing trees like missing blobs. A missing tree
will cause an error if --missing indicates an error should be caused,
and the hash is printed even if the tree is missing.
Signed-off-by: Matthew DeVore
This will make utility functions easier to create, as done by the next
patch.
Signed-off-by: Matthew DeVore
---
list-objects.c | 152 +++--
1 file changed, 71 insertions(+), 81 deletions(-)
diff --git a/list-objects.c b/list-objects.c
index
On Thu, Aug 9, 2018 at 2:56 PM Jeff King wrote:
>
> I think you could have helpers to spell the two lines above even more
> nicely:
>
> while (list->nr) {
> work_on(list_top(list));
> list_pop(list); /* note this doesn't return anything! */
> }
>
> But yes, it's not possible
Elijah Newren writes:
> A possibly crazy idea: Don't bother reporting the other filename; just
> report the OID instead.
>
> "Error: Foo.txt cannot be checked out because another file with hash
> is in the way." Maybe even add a hint for the user: "Run
> `git ls-files -s` to see see all files
On Wed, Aug 8, 2018 at 4:25 PM, Jeff King wrote:
> Even if you just use the oid to do a separate lookup in the object
> database, there's still a benefit in accessing the objects in pack
> order.
You're probably right, but I don't immediately see what the benefit is.
On a not completely
Stefan Beller writes:
> All callers use oid_to_hex to convert the desired oid to a string before
> calling submodule_move_head. Defer the conversion to the
> submodule_move_head as it will turn out to be useful in a bit.
>
> Signed-off-by: Stefan Beller
> ---
> entry.c| 6 +++---
>
On Thu, Aug 09, 2018 at 02:53:42PM -0700, Elijah Newren wrote:
> On Thu, Aug 9, 2018 at 2:44 PM Jeff King wrote:
> > > The error message isn't quite as good, but does the user really need
> > > all the names of the file? If so, we gave them enough information to
> > > figure it out, and this is
On Thu, Aug 09, 2018 at 02:52:29PM -0700, Stefan Beller wrote:
> > In many cases you can just do:
> >
> > while (list->nr) {
> > work_on(list->items[list->nr - 1]);
> > list_remove(list, list->nr - 1);
> > }
> >
> > and then all of those memory ownership issues like:
>
>
On Thu, Aug 9, 2018 at 2:44 PM Jeff King wrote:
> > The error message isn't quite as good, but does the user really need
> > all the names of the file? If so, we gave them enough information to
> > figure it out, and this is a really unusual case anyway, right?
> > Besides, now we're back to
On Thu, Aug 9, 2018 at 2:41 PM Jeff King wrote:
> >
> > while (list->nr)
> > work_on(list_pop(list));
> >
> > which is not so bad.
>
> In many cases you can just do:
>
> while (list->nr) {
> work_on(list->items[list->nr - 1]);
> list_remove(list, list->nr -
Jeff King writes:
> Even with keeping the order this can be done in a single linear pass.
> See filter_string_list() for an example.
Heh, I just wasted a few minutes saying the same; I should have
pointed him at these two lines ;-)
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
> sha1-array.c | 39 +++
> sha1-array.h | 3 +++
> 2 files changed, 42 insertions(+)
>
> diff --git a/sha1-array.c b/sha1-array.c
> index 265941fbf40..10eb08b425e 100644
> --- a/sha1-array.c
> +++
On Thu, Aug 09, 2018 at 02:40:58PM -0700, Elijah Newren wrote:
> > I worry that the false positives make this a non-starter. I mean, if
> > clone creates files 'A' and 'B' (both equal) and then tries to create
> > 'b', would the collision code reports that 'b' collided with 'A' because
> > that
On Thu, Aug 09, 2018 at 02:29:32PM -0700, Junio C Hamano wrote:
> >> +struct string_list_item *string_list_pop(struct string_list *list)
> >> +{
> >> + if (list->nr == 0)
> >> + return 0;
> >
> > return NULL, not 0.
>
> It is OK to return NULL, which may make the caller a bit
On Thu, Aug 9, 2018 at 2:16 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > It is a debugging aid, so it should print to the debugging channel.
>
> Who says?
The comment in the header file?
/**
* Dump a string_list to stdout, useful mainly for debugging
* purposes. It can take
On Thu, Aug 9, 2018 at 2:14 PM Jeff Hostetler wrote:
> On 8/9/2018 10:23 AM, Jeff King wrote:
> > On Wed, Aug 08, 2018 at 05:41:10PM -0700, Junio C Hamano wrote:
> >> If we found that there is something when we tried to write out
> >> "Foo.txt", if we open "Foo.txt" on the working tree and
On Thu, Aug 09, 2018 at 05:14:16PM -0400, Jeff Hostetler wrote:
> > Clever. You might still run into false positives when there is
> > duplicated content in the repository (especially, say, zero-length
> > files). But the fact that you only do the hashing on known duplicates
> > helps with that.
On Thu, Aug 09, 2018 at 02:08:56PM -0700, Junio C Hamano wrote:
> > Correct. But I am more worried about the "mixed/overwriting"
> > breakage, if there is one; it means we may need to be prepared for
> > systems that lack O_APPEND that works correctly. I initially just
> > assumed that it was
Martin Ågren writes:
> On 9 August 2018 at 00:17, Stefan Beller wrote:
>> A string list can be used as a stack, but should we? A later patch shows
>> how useful this will be.
>>
>> Signed-off-by: Stefan Beller
>> ---
>> string-list.c | 8
>> string-list.h | 6 ++
>> 2 files
On Thu, Aug 9, 2018 at 1:54 PM Junio C Hamano wrote:
> Elijah Newren writes:
>
> >> Of course, "git rm" and "git mv" must work sensibly, if we want this
> >> change to be truly helpful--but if not, they need to be fixed ;-)
> >
> > That actually brings up an interesting question. Right now, if
On Wed, Aug 08, 2018 at 03:33:23PM -0700, Brandon Williams wrote:
> Commit 0383bbb901 (submodule-config: verify submodule names as paths,
> 2018-04-30) introduced some checks to ensure that submodule names don't
> include directory traversal components (e.g. "../").
>
> This addresses the
Stefan Beller writes:
> It is a debugging aid, so it should print to the debugging channel.
Who says? In-tree code may say so, and I do not think any in-flight
topic up to 'pu' uses this to produce non-debugging output, but I do
not think it is healthy attitude to assume that you can take over
On 8/9/2018 10:23 AM, Jeff King wrote:
On Wed, Aug 08, 2018 at 05:41:10PM -0700, Junio C Hamano wrote:
If we have an equivalence-class hashmap and feed it inodes (or again,
some system equivalent) as the keys, we should get buckets of
collisions.
I guess one way to get "some system
Junio C Hamano writes:
> Jeff King writes:
>
>> Are you sure that it's not well-defined? We open the path with O_APPEND,
>> which means every write() will be atomically positioned at the end of
>> file. So we would never lose or overwrite data.
>>
>> We do our own buffering in a strbuf, writing
Paul-Sebastian Ungureanu writes:
>> Good to see that the right way to forward a patch from another
>> person is used, but is this a GSoC project?
>
> Yes, it is. I forgot to add the [GSoC] tag in the last series of patches.
The reason I asked was because IIRC GSoC was not supposed to be team
Elijah Newren writes:
>> Of course, "git rm" and "git mv" must work sensibly, if we want this
>> change to be truly helpful--but if not, they need to be fixed ;-)
>
> That actually brings up an interesting question. Right now, if given
> a path that appears in the index but at a stage greater
Jeff King writes:
> Are you sure that it's not well-defined? We open the path with O_APPEND,
> which means every write() will be atomically positioned at the end of
> file. So we would never lose or overwrite data.
>
> We do our own buffering in a strbuf, writing the result out in a single
>
Hello,
On 08.08.2018 23:18, Junio C Hamano wrote:
Paul-Sebastian Ungureanu writes:
From: Joel Teichroeb
Add a builtin helper for performing stash commands. Converting
all at once proved hard to review, so starting with just apply
lets conversion get started without the other commands being
On Thu, Aug 09, 2018 at 01:04:43PM +0200, Bartosz Konikiewicz wrote:
> Hi there!
>
> I hope that the subject of my message (i.e. the question) is
> exhaustive enough, so I'll just stick to reproducing my issue.
>
> Steps to reproduce:
>
> 1. Create a new file.
> 2. Stage the file.
> 3. Add the
On Mon, Aug 6, 2018 at 4:18 PM Jonathan Nieder wrote:
> > +DIFF ALGORITHMS
> > +---
>
> Please add some introductory words about what the headings refer to.
ok.
>
> > +the shortest output.
>
> Trivia: the `minimal` variant of Myers doesn't guarantee shortest
> output, either: what
On Thu, Aug 09, 2018 at 11:40:27AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I guess leaving it serves as a sort of cross-check if gpg would return a
> > zero exit code but indicate in the status result that the signature was
> > not good. Sort of a belt-and-suspenders, I guess
On Thu, Aug 09, 2018 at 10:35:24AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> The culprit is that two processes try simultaneously to write to the same
> file specified via GIT_TRACE_PACKET, and it is not well defined how that
> should work, even on Linux.
Are you sure that it's not
On Thu, Aug 9, 2018 at 5:55 PM, Christian Couder
wrote:
> The following changes have been made since the previous iteration:
>
> * suggested by Duy: move the code computing the write order for a
> layer to a new separate function called compute_layer_order() in
> builtin/pack-objects.c in
On Thu, Aug 9, 2018 at 10:36 AM Junio C Hamano wrote:
> Elijah Newren writes:
>
> > File/directory conflicts are somewhat difficult to resolve; by way of
> > contrast, renames are much easier to handle. For file/directory
> > conflicts, we already have to record the file under a different name
On Tue, Aug 7, 2018 at 8:56 AM Junio C Hamano wrote:
>
> Jonathan Nieder writes:
>
> > Both don't seem quite right, since they have an extra space before the
> > period. The git-diff(1) seems especially not quite right --- does it
> > intend to say something like "See the DIFF ALGORITHMS
On Thu, Aug 09, 2018 at 10:25:52AM -0700, Stefan Beller wrote:
> On Thu, Aug 9, 2018 at 12:39 AM Martin Ågren wrote:
> >
> > On 9 August 2018 at 00:17, Stefan Beller wrote:
> > > +int oid_array_remove_if(struct oid_array *array,
> > > + for_each_oid_fn fn,
> > > +
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> This function will be used to make write accesses in trace_write() a bit
> safer.
> ...
> To set a precedent for a better approach, let's introduce a proper
> abstraction: a function that says in its name precisely
On Thu, Aug 9, 2018 at 10:52 AM Junio C Hamano wrote:
> Elijah Newren writes:
>
> > 1) Representative example: A modify/delete conflict; the path in question
> > in the working tree would have conflict information at the top of the file
> > followed by the normal file contents; thus it could be
Jeff King writes:
> I guess leaving it serves as a sort of cross-check if gpg would return a
> zero exit code but indicate in the status result that the signature was
> not good. Sort of a belt-and-suspenders, I guess (which might not be
> that implausible if we think about somebody wrapping gpg
On Thu, Aug 9, 2018 at 10:05 AM, Junio C Hamano wrote:
> Hmm, it is clever to auto-start the pack-objects (and notice there
> wasn't anything needing to pack). Two things that are worth noting
> are:
>
> - The code takes advantage of the fact that cmd.in being left as -1
>is a sign that
Elijah Newren writes:
> 1) Representative example: A modify/delete conflict; the path in question
> in the working tree would have conflict information at the top of the file
> followed by the normal file contents; thus it could be of the form:
>
> HEAD
> Conflict hint: This
On Thu, Aug 9, 2018 at 12:50 AM Martin Ågren wrote:
>
> On 9 August 2018 at 00:17, Stefan Beller wrote:
> > Currently when git-fetch is asked to recurse into submodules, it dispatches
> > a plain "git-fetch -C " (and some submodule related options
> > such as prefix and recusing strategy, but)
Elijah Newren writes:
> File/directory conflicts are somewhat difficult to resolve; by way of
> contrast, renames are much easier to handle. For file/directory
> conflicts, we already have to record the file under a different name in
> the working copy due to the directory being in the way; if
From: Johannes Schindelin
For some reason, t/t5552-skipping-fetch-negotiator.sh fails particularly
often on Windows due to racy tracing where the `git upload-pack` and the
`git fetch` processes compete for the same file.
We just introduced a remedy that uses fcntl(), but Windows does not have
From: Johannes Schindelin
This function will be used to make write accesses in trace_write() a bit
safer.
Note: this patch takes a very different approach for cross-platform
support than Git is historically taking: the original approach is to
first implement everything on Linux, using the
From: Johannes Schindelin
When multiple processes try to write to the same file, it is not
guaranteed that everything works as expected: those writes can overlap,
and in the worst case even lose messages.
This happens in t/t5552-skipping-fetch-negotiator.sh, where we abuse the
`GIT_TRACE`
I reported a couple of times that t5552 is not passing reliably. It has now
reached next, and will no doubt infect master soon.
Turns out that it is not a Windows-specific issue, even if it occurs a lot
more often on Windows than elsewhere.
The culprit is that two processes try simultaneously
From: Johannes Schindelin
Recently, t5552 introduced a pattern where two processes try to write to
the same GIT_TRACE file in parallel. This is not safe, as the two
processes fighting over who gets to append to the file can cause garbled
lines and may even result in data loss on Windows (where
On Thu, Aug 9, 2018 at 12:39 AM Martin Ågren wrote:
>
> On 9 August 2018 at 00:17, Stefan Beller wrote:
> > +int oid_array_remove_if(struct oid_array *array,
> > + for_each_oid_fn fn,
> > + void *data)
> > +{
> > + int i, j;
> > + char
On Thu, Aug 09, 2018 at 08:30:25AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > There was a patch at the start of this thread, but it specifically
> > checks for "sigc->result == U". That's probably OK, since I think it
> > restores the behavior in earlier versions of Git. But I
On Wed, Aug 08, 2018 at 10:45:49PM -0400, Paul Smith wrote:
> On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote:
> > If so, can you try running it under gdb and getting a stack trace?
> > Something like:
> >
> > gdb git
> > [and then inside gdb...]
> > set args pack-objects --all --reflog
Jonathan Tan writes:
> +/*
> + * Write oid to the given struct child_process's stdin, starting it first if
> + * necessary.
> + */
> +static int write_oid(const struct object_id *oid, struct packed_git *pack,
> + uint32_t pos, void *data)
> +{
> + struct child_process *cmd =
Le 09/08/2018 à 16:22, Phillip Wood a écrit :
>> +int complete_action(struct replay_opts *opts, unsigned flags,
>> + const char *shortrevisions, const char *onto_name,
>> + const char *onto, const char *orig_head, const char *cmd,
>> + unsigned autosquash)
>> +{
Hi Alban
On 09/08/18 16:35, Phillip Wood wrote:
Hi Alban
On 09/08/18 14:30, Alban Gruin wrote:
Hi Phillip,
Le 08/08/2018 à 18:04, Phillip Wood a écrit :
+int edit_todo_list(unsigned flags)
+{
+ struct strbuf buf = STRBUF_INIT;
+ const char *todo_file = rebase_path_todo();
+ FILE
From: Jeff King
Hosting providers that allow users to "fork" existing
repos want those forks to share as much disk space as
possible.
Alternates are an existing solution to keep all the
objects from all the forks into a unique central repo,
but this can have some drawbacks. Especially when
From: Jeff King
Signed-off-by: Jeff King
Signed-off-by: Christian Couder
---
t/t5319-delta-islands.sh | 143 +++
1 file changed, 143 insertions(+)
create mode 100755 t/t5319-delta-islands.sh
diff --git a/t/t5319-delta-islands.sh b/t/t5319-delta-islands.sh
From: Jeff King
Implement simple support for --delta-islands option and
repack.useDeltaIslands config variable in git repack.
This allows users to setup delta islands in their config and
get the benefit of less disk usage while cloning and fetching
is still quite fast and not much more CPU
This reduces the size of 'struct object_entry' and therefore
makes packing objects more efficient.
This also renames cmp_tree_depth() into tree_depth_compare(),
as it is more modern to have the name of the compare functions
end with "compare".
Helped-by: Jeff King
Helped-by: Duy Nguyen
This reduces the size of 'struct object_entry' from 88 bytes
to 80 and therefore makes packing objects more efficient.
For example on a Linux repo with 12M objects,
`git pack-objects --all` needs extra 96MB memory even if the
layer feature is not used.
Helped-by: Jeff King
Helped-by: Duy Nguyen
From: Jeff King
Implement support for delta islands in git pack-objects
and document how delta islands work in
"Documentation/git-pack-objects.txt" and Documentation/config.txt.
This allows users to setup delta islands in their config and
get the benefit of less disk usage while cloning and
In a following commit, as we will use delta islands, we will
have to compute the write order for different layers, not just
for one.
Let's prepare for that by refactoring the code that will be
used to compute the write order for a given layer into a new
compute_layer_order() function.
This will
From: Jeff King
As get_delta_base() will be used outside 'packfile.c' in
a following commit, let's make it non static and let's
declare it in 'packfile.h'.
Signed-off-by: Jeff King
Signed-off-by: Christian Couder
---
packfile.c | 10 +-
packfile.h | 7 +++
2 files changed, 12
This patch series is upstreaming work made by GitHub and available in:
https://github.com/peff/git/commits/jk/delta-islands
The above work has been already described in the following article:
https://githubengineering.com/counting-objects/
The above branch contains only one patch. In this
Nicholas Guriev writes:
> It allows for uniformity with the --untracked-files option. Also
> the new short flag saves the number of keys to press for the
> typically git-status command.
Unlike "-u', "-i" is supported by "git commit" which shares the
underlying implementation, and that is the
Hi Alban
On 09/08/18 14:30, Alban Gruin wrote:
Hi Phillip,
Le 08/08/2018 à 18:04, Phillip Wood a écrit :
+int edit_todo_list(unsigned flags)
+{
+ struct strbuf buf = STRBUF_INIT;
+ const char *todo_file = rebase_path_todo();
+ FILE *todo;
+
+ if (strbuf_read_file(, todo_file, 0) <
Jeff King writes:
> There was a patch at the start of this thread, but it specifically
> checks for "sigc->result == U". That's probably OK, since I think it
> restores the behavior in earlier versions of Git. But I wonder if we
> should simply be storing the fact that gpg exited non-zero and
On 8/3/2018 11:26 AM, Ben Peart wrote:
On 7/13/2018 12:55 PM, g...@jeffhostetler.com wrote:
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
Documentation/technical/structured-logging.txt | 816
+
1 file changed, 816 insertions(+)
create mode 100644
On Thu, Aug 09, 2018 at 01:43:02AM +, brian m. carlson wrote:
> On Wed, Aug 08, 2018 at 05:59:43PM -0700, Junio C Hamano wrote:
> > "brian m. carlson" writes:
> >
> > >> FWIW, I'm on board with returning non-zero in any case where gpg would.
> > >
> > > I think that's probably the best
On Thu, Aug 09, 2018 at 01:58:05AM -0400, Eric Sunshine wrote:
> On Wed, Aug 8, 2018 at 6:50 PM Jeff King wrote:
> > On Tue, Aug 07, 2018 at 04:21:31AM -0400, Eric Sunshine wrote:
> > > +# Swallowing here-docs with arbitrary tags requires a bit of finesse.
> > > When a
> > > +# line such as
On Wed, Aug 08, 2018 at 05:41:10PM -0700, Junio C Hamano wrote:
> > If we have an equivalence-class hashmap and feed it inodes (or again,
> > some system equivalent) as the keys, we should get buckets of
> > collisions.
>
> I guess one way to get "some system equivalent" that can be used as
>
Hi Alban
Its nice to see things coming together so that the rebase happens in the
same process as the some of the todo file preparation. I've ended up
making quite a few comments on the new implementation, but they're all
little things, the basic idea looks sound to me.
On 31/07/18 18:59,
On Thu, 2 Aug 2018 11:15:03 -0700
Stefan Beller wrote:
> On Thu, Aug 2, 2018 at 9:41 AM SZEDER Gábor wrote:
> >
[...]
> > >
> > > Note that test_when_finished is not used here, both to keep the current
> > > style
> > > and also because it does not work in sub-shells.
> >
> > That's true, but
Hi Phillip,
Le 08/08/2018 à 18:04, Phillip Wood a écrit :
+int edit_todo_list(unsigned flags)
+{
+ struct strbuf buf = STRBUF_INIT;
+ const char *todo_file = rebase_path_todo();
+ FILE *todo;
+
+ if (strbuf_read_file(, todo_file, 0) < 0)
+
Hi Phillip,
On Thu, 9 Aug 2018, Phillip Wood wrote:
> On 09/08/18 10:22, Johannes Schindelin wrote:
> >
> > On Mon, 6 Aug 2018, Phillip Wood wrote:
> >
> >> On 06/08/18 10:52, Johannes Schindelin via GitGitGadget wrote:
> >>>
> >>> + else if (is_fixup(command)) {
> >>> +
Hi Junio,
On Sat, 4 Aug 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Thu, 2 Aug 2018, Junio C Hamano wrote:
> >
> >> * pk/rebase-in-c (2018-07-30) 3 commits
> >> - builtin/rebase: support running "git rebase "
> >> - rebase: refactor common shell functions into their
Hi Eric,
On Tue, 7 Aug 2018, Eric Sunshine wrote:
> On Tue, Aug 7, 2018 at 9:54 AM Andrei Rybak wrote:
> > line-log.[ch] use left-closed, right-open interval logic. Change comment
> > and debug output to square brackets+parentheses notation to help
> > developers avoid off-by-one errors.
> >
Hi there!
I hope that the subject of my message (i.e. the question) is
exhaustive enough, so I'll just stick to reproducing my issue.
Steps to reproduce:
1. Create a new file.
2. Stage the file.
3. Add the file to .gitignore.
4. Stage the .gitignore.
5. Commit changes.
I imagined that the file
On Thu, 2 Aug 2018 11:05:02 -0700
Stefan Beller wrote:
> On Thu, Aug 2, 2018 at 6:47 AM Antonio Ospite wrote:
> >
[...]
> > +extern int print_config_from_gitmodules(const char *key);
>
> The only real pushback for this patch I'd have is lack of documentation
> in public functions, though this
On 08/08/18 10:39, Eric Sunshine wrote:
> On Tue, Aug 7, 2018 at 5:35 AM Phillip Wood wrote:
>> Single quotes should be escaped as \' not \\'. The bad quoting breaks
>> the interactive version of 'rebase --root' (which is used when there
>> is no '--onto' even if the user does not specify
Hi Eric
On 08/08/18 09:43, Eric Sunshine wrote:
> On Tue, Aug 7, 2018 at 9:54 AM Phillip Wood wrote:
>> On 07/08/18 11:23, Eric Sunshine wrote:
>>> On Tue, Aug 7, 2018 at 5:35 AM Phillip Wood
>>> wrote:
+ if (n > 0 && s[n] != '\'')
+ return 1;
>>>
>>> To be
Hi Junio
On 08/08/18 17:01, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> What does concern me is that read_env_script() doesn't seem to care
>> about such a malformed file; it doesn't do any validation at all.
>> Contrast that with read_author_ident() which is pretty strict about
>> the
On 09/08/18 10:22, Johannes Schindelin wrote:
> Hi Phillip,
>
> On Mon, 6 Aug 2018, Phillip Wood wrote:
>
>> On 06/08/18 10:52, Johannes Schindelin via GitGitGadget wrote:
>>>
>>> From: Johannes Schindelin
>>>
>>> The idea of `--exec` is to append an `exec` call after each `pick`.
>>>
>>> Since
It was reported via IRC that the exec lines are inserted in the wrong spots
when using --rebase-merges.
The reason is that we used a simple, incorrect implementation that happened
to work as long as the generated todo list only contains pick, fixup and
squash commands. Which is not the case
From: Johannes Schindelin
The --exec option's implementation is not really well-prepared for
--rebase-merges. Demonstrate this.
Signed-off-by: Johannes Schindelin
---
t/t3430-rebase-merges.sh | 17 +
1 file changed, 17 insertions(+)
diff --git a/t/t3430-rebase-merges.sh
From: Johannes Schindelin
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a fixup/squash chain", i.e. an
exec would not be inserted between a `pick` and any of
1 - 100 of 108 matches
Mail list logo
