As discovered on the mailing list, some of the descriptions of the
ff-related options were unclear. Try to be more precise with what these
options do.
Signed-off-by: Elijah Newren
---
Changes since v3:
* Shorten the leading paragraph, as suggested by Junio (and Eric).
Documentation/merge-opt
Hi Dscho,
On Fri, Aug 30, 2019 at 1:40 PM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
>
> On Wed, 28 Aug 2019, Elijah Newren wrote:
>
> > Hi Sergey,
> >
> > On Wed, Aug 28, 2019 at 1:52 AM Sergey Organov wrote:
> > >
> > > Elijah Newren writes:
> > >
> > > > On Tue, Aug 27, 2019 at 1:43 AM Serg
Hi Elijah,
On Wed, 28 Aug 2019, Elijah Newren wrote:
> Hi Sergey,
>
> On Wed, Aug 28, 2019 at 1:52 AM Sergey Organov wrote:
> >
> > Elijah Newren writes:
> >
> > > On Tue, Aug 27, 2019 at 1:43 AM Sergey Organov wrote:
> > >>
> > >> Eric Wong writes:
> > >>
> > >>
> > >> [...]
> > >>
> > >> >
Elijah Newren writes:
> On Fri, Aug 30, 2019 at 12:45 PM Junio C Hamano wrote:
>>
>> Martin Ågren writes:
>>
>> >> +--ff::
>> >> + Whether to only allow resolving the merge as a fast forward
>> >> + (only updating the branch pointer to match the merged branch
>> >> + and not c
On Fri, Aug 30, 2019 at 3:57 PM Junio C Hamano wrote:
> If we want to dedicate one paragraph for each of these options, we
> can and should make the introductory paragraph lighter by saying
> something like
>
> Specifies how a merge is handled when the merged-in history
> is alread
Ben Wijen writes:
> @@ -1968,13 +1968,6 @@ int cmd_rebase(int argc, const char **argv, const char
> *prefix)
> state_dir_path("autostash", &options);
> struct child_process stash = CHILD_PROCESS_INIT;
> struct object_id oi
Ben Wijen writes:
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index 670096c065..abcbfb8f01 100644
> --- a/builtin/rebase.c
> +++ b/builtin/rebase.c
> @@ -1968,9 +1968,13 @@ int cmd_rebase(int argc, const char **argv, const char
> *prefix)
> state_dir_path("
Hi Gábor,
On Wed, 28 Aug 2019, SZEDER Gábor wrote:
> Implement find_unique_prefixes() by sorting the prefix items
> lexicographically and then looking for unique prefixes in adjacent
> pairs. It's definitely shorter than the current hashmap-based
> implementation (101 vs 149 lines), subjectively
Signed-off-by: David Turner
---
Documentation/gitremote-helpers.txt | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitremote-helpers.txt
b/Documentation/gitremote-helpers.txt
index 43f80c8068..a5c3c04371 100644
--- a/Documentation/gitremote-helpers.t
Elijah Newren writes:
> diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
> index 79a00d2a4a..ed3804650b 100644
> --- a/Documentation/merge-options.txt
> +++ b/Documentation/merge-options.txt
> @@ -40,20 +40,26 @@ set to `no` at the beginning of them.
> case of
Phillip Wood wrote:
> Hi Eric
>
> On 27/08/2019 10:49, Eric Wong wrote:
> > Johannes Schindelin wrote:
> > > Hi Eric,
> > >
> > > On Mon, 26 Aug 2019, Eric Wong wrote:
> > >
> > > > By renaming the "hash" field to "_hash", it's easy to spot
> > > > improper initialization of hashmap_entry stru
ATTENTION SIR BENEFICIARY SIR / MA
YOU HAVE BEEN COMPENSATE BY THE UN WORLD BANK ORGANIZATION WITH THE SUM OF
$850.000.00 USD ONLY,
I AM WAITING TO HEAR FROM YOU SO THAT YOU WILL RECEIVE YOUR COMPENSATION FUNDS
$850.000.00 USD ONLY FROM UN WORLD BANK ORGANIZATION AND MORE DETAILS CONTACT
ME T
On Fri, Aug 30, 2019 at 12:45 PM Junio C Hamano wrote:
>
> Martin Ågren writes:
>
> >> +--ff::
> >> + Whether to only allow resolving the merge as a fast forward
> >> + (only updating the branch pointer to match the merged branch
> >> + and not creating a merge commit), to never
Johannes Schindelin wrote:
> Hi Stolee,
>
> On Tue, 27 Aug 2019, Derrick Stolee wrote:
>
> > On 8/25/2019 10:43 PM, Eric Wong wrote:
> > > C compilers do type checking to make life easier for us. So
> > > rely on that and update all hashmap_entry_init callers to take
> > > "struct hashmap_entry
Hi Kasper,
On Fri, 30 Aug 2019, van den Berg, Kasper wrote:
> `git range-diff ` prints "segmentation fault" to the
> console and nothing else. It happens in git version 2.23.0.windows.1
> and only occurs for some branches in my repository.
Maybe you can come up with a Minimal, Complete and Ver
Hi brian,
On Thu, 29 Aug 2019, brian m. carlson wrote:
> On 2019-08-28 at 11:30:53, Johannes Schindelin wrote:
> > > diff --git a/convert.c b/convert.c
> > > index 94ff837649..0e6e9d2d75 100644
> > > --- a/convert.c
> > > +++ b/convert.c
> > > @@ -8,6 +8,7 @@
> > > #include "pkt-line.h"
> > > #
Martin Ågren writes:
>> +--ff::
>> + Whether to only allow resolving the merge as a fast forward
>> + (only updating the branch pointer to match the merged branch
>> + and not creating a merge commit), to never allow it (always
>> + creating a merge commit), or to prefer i
Derrick Stolee wrote:
> On 8/25/2019 10:43 PM, Eric Wong wrote:
> > + * container_of - Get the address of an object containing a field.
> > + *
> > + * @ptr: pointer to the field.
> > + * @type: type of the object.
> > + * @member: name of the field within the object.
> > + */
> > +#define contain
Derrick Stolee wrote:
> On 8/25/2019 10:43 PM, Eric Wong wrote:
> > --- a/diff.c
> > +++ b/diff.c
> > @@ -1035,8 +1035,10 @@ static void pmb_advance_or_null_multi_match(struct
> > diff_options *o,
> > {
> > int i;
> > char *got_match = xcalloc(1, pmb_nr);
> > + struct hashmap_entry *en
David Turner writes:
> The only other restriction I see is: in order for the connectivity-skipping
> optimization to be used, the file with s/.keep/.idx/, and the corresponding
> pack, must exist. Do you think that's worth mentioning? It seems to be
> implied by the rest of the text.
Perhaps
Michal Suchánek writes:
>> But requiring an additional single "f" when doing "rm -rf .git"? Is
>> that realy too much of a hassle? The option "-f" is to allow people
>> deal with an unusual situation, while preventing everyday use from
>> doing something harmful unintendedly. And removing a cl
On Fri, 30 Aug 2019 09:38:11 -0700
Junio C Hamano wrote:
> Albert Vaca Cintora writes:
>
> > On Tue, Aug 27, 2019 at 9:35 PM Junio C Hamano wrote:
> >>
> >> Ah, your "rm" command needs to learn "-f" option, too, then?
> >
> > The whole point of this thread was to remove the need of -f forc
Jon Simons writes:
> diff --git a/list-objects-filter-options.c b/list-objects-filter-options.c
> index 1cb20c659c..aaba312edb 100644
> --- a/list-objects-filter-options.c
> +++ b/list-objects-filter-options.c
> @@ -71,7 +71,8 @@ static int gently_parse_list_objects_filter(
>* com
> -Original Message-
> From: Junio C Hamano
> Sent: Friday, August 30, 2019 1:35 PM
> To: David Turner
> Cc: Martin Ågren ; Git Mailing List
>
> Subject: Re: [PATCH] clarify documentation for remote helpers
>
> David Turner writes:
>
> > I was confused, because I read "a file under GI
David Turner writes:
> I was confused, because I read "a file under GIT_DIR/objects/pack"
> to mean "just the filename". Some of the things that deal with
> packs take just the filename (e.g. --keep-pack for git repack).
> I'll fix the under under and add $, but I do want to clarify that
> it's
Taylor Blau writes:
> I wholeheartedly agree with this, and pledge my $.02 towards it as well.
> Now with a combined total of $.04, I think that this patch is ready for
> queueing as-is.
;-)
Martin Ågren writes:
> There's a difference in behavior that I'm not sure about: We used
> to ignore the return value of `refresh_cache()`, i.e. we didn't care
> whether it had any errors. I have no idea whether that's safe to do --
> especially as we go on to write the index. So I don't know whe
On 8/29/2019 8:43 PM, Taylor Blau wrote:
> Hi Elijah,
>
> On Thu, Aug 29, 2019 at 05:19:44PM -0700, Elijah Newren wrote:
>> Personally, although I understand the desire to support any possible
>> cases in general, *this is a performance hack*. As such, it should be
>> as simple and localized as p
Albert Vaca Cintora writes:
> On Tue, Aug 27, 2019 at 9:35 PM Junio C Hamano wrote:
>>
>> Ah, your "rm" command needs to learn "-f" option, too, then?
>
> The whole point of this thread was to remove the need of -f forcing the
> removal.
OK, I misunderstood what you wanted to do.
If an implem
René Scharfe writes:
> Subject: [PATCH] tree: simplify parse_tree_indirect()
>
> Reduce code duplication by turning parse_tree_indirect() into a wrapper
> of repo_peel_to_type(). This avoids a segfault when handling a broken
> tag where ->tagged is NULL. The new version also checks the return
>
SZEDER Gábor writes:
> Another Python 2 vs 3 issue, perhaps?
>
> # Python2, good:
>...
>'f8fd6737fbe5a45c97ba9c9de495dc46ff11eccd',
>'100644',
>'file1-mv.txt',
>'similarity index 90%\nrename from file1.txt\nrename to
> file1-mv.txt\nindex 2bef330..f8fd673 100644\n']
> #
I've figured it out. It's not a bug, it's a peculiarity of pprint().
It splits strings to avoid long lines and abuses the fact that in
Python strings split with whitespace are concatenated by the parser.
Also, in my example newlines are not parsed correctly in the shell.
Escaping them, I get the e
On Fri, 30 Aug 2019 at 17:27, Jeff King wrote:
> I think you have an extra "old-filename" in the second list.
Agreed. My misunderstanding was that I had thought that when
documentation said "path", it meant "argv[0], the path to the diff
executable".
> Interesting. I _don't_ see that splitting w
On Thu, Aug 29, 2019 at 10:58 AM Matthew McClure
wrote:
>
> On Thu, Aug 29, 2019 at 1:04 PM Elijah Newren wrote:
> >
> > Perhaps put all the changes in a specific branch and run:
> > git config branch.${personalBranchName}.pushRemote
> > Do.Not.Push.Changes.From.This.Branch
> > ? (And make sur
When doing 'git rebase --autostash ' with a dirty worktree
a 'HEAD is now at ...' message is emitted, which is pointless as it refers to
the old active branch which isn't actually moved.
This commit removes the 'HEAD is now at...' message.
Signed-off-by: Ben Wijen
---
builtin/rebase.c
When doing 'git rebase --autostash ' with a dirty worktree
a 'HEAD is now at ...' message is emitted, which is pointless as it refers to
the old active branch which isn't actually moved.
This commit removes the 'HEAD is now at...' message.
Signed-off-by: Ben Wijen
---
builtin/rebase.c
Consider the following scenario:
git checkout not-the-master
work work work
git rebase --autostash upstream master
Here 'rebase --autostash ' incorrectly moves the
active branch (not-the-master) to master (before the rebase).
The expected behavior: (58794775:/git-rebase.sh:526)
A
Here are my "fix things without making unnecessary changes"
Fixing a copy-paste fault which I missed in v5...
Ben Wijen (2):
builtin/rebase.c: make sure the active branch isn't moved when
autostashing
builtin/rebase.c: Remove obsolete message
builtin/rebase.c| 13 +--
On Thu, 29 Aug 2019 at 20:28, Thomas Gummerer wrote:
> +int repo_refresh_and_write_index(struct repository *repo,
> +unsigned int refresh_flags,
> +unsigned int write_flags,
> +const struct pathspec *p
> -Original Message-
> From: Martin Ågren
> Sent: Friday, August 30, 2019 10:09 AM
> To: David Turner
> Cc: Git Mailing List
> Subject: Re: [PATCH v2] clarify documentation for remote helpers
>
> On Fri, 30 Aug 2019 at 16:00, David Turner wrote:
> >
> > Signed-off-by: David Turner
>
On Fri, Aug 30, 2019 at 04:23:13PM +0300, Dmitry Nikulin wrote:
> On Fri, 30 Aug 2019 at 13:16, Phillip Wood wrote:
> > I'm not sure why the last argument is being split in
> > your example. It is not split in the example below
>
> I have replicated the splitting issue on my small demo repo [1]:
On Fri, Aug 30, 2019 at 04:23:13PM +0300, Dmitry Nikulin wrote:
> On Fri, 30 Aug 2019 at 13:16, Phillip Wood wrote:
> > I'm not sure why the last argument is being split in
> > your example. It is not split in the example below
>
> I have replicated the splitting issue on my small demo repo [1]:
On 30/08/2019 14:23, Dmitry Nikulin wrote:
On Fri, 30 Aug 2019 at 13:16, Phillip Wood wrote:
I'm not sure why the last argument is being split in
your example. It is not split in the example below
I have replicated the splitting issue on my small demo repo [1]:
$ env GIT_EXTERNAL_DIFF=./prin
On Fri, 30 Aug 2019 at 16:00, David Turner wrote:
>
> Signed-off-by: David Turner
> ---
> Documentation/gitremote-helpers.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gitremote-helpers.txt
> b/Documentation/gitremote-helpers.txt
> index 43f80c
Signed-off-by: David Turner
---
Documentation/gitremote-helpers.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitremote-helpers.txt
b/Documentation/gitremote-helpers.txt
index 43f80c8068..f4a165387f 100644
--- a/Documentation/gitremote-helpers.txt
++
I was confused, because I read "a file under GIT_DIR/objects/pack" to mean
"just the filename". Some of the things that deal with packs take just the
filename (e.g. --keep-pack for git repack). I'll fix the under under and add
$, but I do want to clarify that it's the full path.
> -Origin
On Fri, 30 Aug 2019 at 13:16, Phillip Wood wrote:
> I'm not sure why the last argument is being split in
> your example. It is not split in the example below
I have replicated the splitting issue on my small demo repo [1]:
$ env GIT_EXTERNAL_DIFF=./print_argv.py git diff -M origin/branch1
origin
On Tue, Aug 27, 2019 at 9:35 PM Junio C Hamano wrote:
>
> Ah, your "rm" command needs to learn "-f" option, too, then?
The whole point of this thread was to remove the need of -f forcing the removal.
On Fri, Aug 30, 2019 at 12:06:30AM +0200, SZEDER Gábor wrote:
> On Thu, Aug 29, 2019 at 11:58:18PM +0200, SZEDER Gábor wrote:
> > On Thu, Aug 29, 2019 at 10:38:05AM -0400, Jeff King wrote:
> > > So any fixes there have to happen on the client side. I am still
> > > confused about why the client is
Hello
My name is Joe Akaba I am a lawyer by profession. I wish to offer you
the next of kin to my client. You will inherit the sum of ($8.5 Million)
dollars my client left in the bank before his death.
My client is a citizen of your country who died in auto crash with his wife
and only son. I wil
Hi Dmitry
On 29/08/2019 15:36, Dmitry Nikulin wrote:
Thank you for the reply.
[...]
However, for the original repository where I first faced this problem
(https://github.com/yandexdataschool/Practical_RL), Git passes a very
weird set of args to the external diff:
$ env GIT_EXTERNAL_DIFF=./print
On 08/30, van den Berg, Kasper wrote:
> Hello,
>
> `git range-diff ` prints "segmentation fault" to
> the console and nothing else. It happens in git version
> 2.23.0.windows.1 and only occurs for some branches in my repository.
> I have not exactly determined when it does happen and when it does
On Thu, Aug 29, 2019 at 11:44 PM Matheus Tavares Bernardino
wrote:
> > I'm sure there are other gotchas in the config code, though, related to
> > things for which we _do_ need a repository. E.g., include_by_branch()
> > looks at the_repository, and should use a repository struct matching the
> >
Hello,
`git range-diff ` prints "segmentation fault" to the console
and nothing else. It happens in git version 2.23.0.windows.1 and only occurs
for some branches in my repository. I have not exactly determined when it does
happen and when it does not (I'm not familiar with git's codebase).
54 matches
Mail list logo
