On Tue, May 14, 2019 at 10:30 PM Junio C Hamano wrote:
>
> "Eric Rannaud" writes:
>
> > We now keep track of whether branches and tags have been changed by this
> > fast-import process since our last checkpoint (or startup). At the next
> > checkpoint, only refs and tags that new commands have ch
Hi Peff,
On 15/05/2019 02:53, Jeff King wrote:
On Tue, May 14, 2019 at 05:17:17PM -0700, Emily Shaffer wrote:
const char git_more_info_string[] =
N_("'git help -a' and 'git help -g' list available subcommands and
some\n"
"concept guides. See 'git help ' or 'git help '\n"
Hi Emily,
On 15/05/2019 01:17, Emily Shaffer wrote:
On Tue, May 14, 2019 at 04:24:50PM +0100, Philip Oakley wrote:
It is not immediately obvious how to use the `git help` system
to show the git(1) page, with all its background and ccordinating
material, such as environment variables.
Let's sim
On Wed, May 15, 2019 at 1:57 PM Johannes Sixt wrote:
>
> Am 11.05.19 um 06:13 schrieb Boxuan Li:
> > Octave pattern is almost the same as matlab. Besides,
> > octave also uses '%%%' or '##' to begin code sections.
> >
>
> > @@ -60,6 +60,11 @@ PATTERNS("java",
> > PATTERNS("matlab",
> >"^[
Am 11.05.19 um 06:13 schrieb Boxuan Li:
> Octave pattern is almost the same as matlab. Besides,
> octave also uses '%%%' or '##' to begin code sections.
>
> @@ -60,6 +60,11 @@ PATTERNS("java",
> PATTERNS("matlab",
>"^[[:space:]]*((classdef|function)[[:space:]].*)$|^%%[[:space:]].*$",
>
Octave pattern is almost the same as matlab, except
that '%%%' and '##' can also be used to begin code sections,
in addition to '%%' that is understood by both.
Signed-off-by: Boxuan Li
---
Thanks to all the reviewers above, this is the fourth version:
v1: use matlab pattern for octave
v2: add a
Boxuan Li writes:
> Octave pattern is almost the same as matlab. Besides,
> octave also uses '%%%' or '##' to begin code sections.
My reading of the above hiccupped at around "Besides, octave also
uses...".
Checking the differences in patterns, I think
... the same as matlab, except th
"Eric Rannaud" writes:
> We now keep track of whether branches and tags have been changed by this
> fast-import process since our last checkpoint (or startup). At the next
> checkpoint, only refs and tags that new commands have changed are
> written to disk.
And when we notice that we have been
"Mike Mueller via GitGitGadget" writes:
> From: Mike Mueller
>
> git p4 unshelve was failing with these errors on Windows:
>
> fatal: Not a valid object name HEAD0
> Command failed: git cat-file commit HEAD^0
>
> (git version 2.21.0.windows.1, python 2.7.16)
>
> The pOpen call used by git-p4 to
Jeff King writes:
> Also from my earlier message, if you missed it:
>
> I also wondered if we should simply allocate an empty index whenever
> we have a non-toplevel "struct repository", which might be less
> surprising to other callers. I don't have a strong opinion either way.
> I did g
Hi Junio,
Junio C Hamano 於 2019年5月15日 週三 上午8:48寫道：
>
> 林自均 writes:
>
> > I was not talking about the messages in the editor session. I was
> > talking about "git commit" without "git add" anything.
> >
> > For example:
> >
> > ```
> > $ touch newfile.txt
> > $ git commit
> > On branch master
> >
Johannes Schindelin writes:
>> +test_expect_success 'merge --quit' '
>> +git reset --hard c2 &&
>> +test_must_fail git -c rerere.enabled=true merge master &&
>
> This makes me really worried. It is the same `master` (i.e. *not* a tag)
> that broke this test case in the previous round.
I'
Nguyễn Thái Ngọc Duy writes:
> diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
> index 106148254d..d453710ef6 100755
> --- a/t/t7600-merge.sh
> +++ b/t/t7600-merge.sh
> @@ -822,4 +822,18 @@ test_expect_success EXECKEEPSPID 'killed merge can be
> completed with --continue'
> verify_parent
Todd Zullinger writes:
>> This guards against cases where jgit is present on the system, but
>> will fail to run, e.g. because of some JRE issue, or missing Java
>> dependencies. Seeing if it gets far enough to process the
>> "--version" argument isn't perfect, but seems to be goo
Duy Nguyen writes:
> Technically 'one' is still tracked (even if it's a directory) so what
> we're doing is right. I'm just not sure if there's some big surprise
> factor here. And whether it's better to pause and double check with
> the user before deleting everything.
I agree to all of the abo
On Tue, May 14, 2019 at 05:17:17PM -0700, Emily Shaffer wrote:
> > const char git_more_info_string[] =
> > N_("'git help -a' and 'git help -g' list available subcommands and
> > some\n"
> >"concept guides. See 'git help ' or 'git help '\n"
> > - "to read about a specific subcomm
Philip Oakley writes:
> It is a 'branch which tracks a remote', and it is has the 'last time I
> looked' state of the branch that is on the remote server, which may
> have, by now, advanced or changed.
Yup, I thought we long time ago decided to discourage use of "remote
branch(es)" in our docume
On Wed, May 15, 2019 at 08:24:34AM +0700, Duy Nguyen wrote:
> On Tue, May 14, 2019 at 8:54 PM Jeff King wrote:
> > diff --git a/sha1-name.c b/sha1-name.c
> > index 775a73d8ad..455e9fb1ea 100644
> > --- a/sha1-name.c
> > +++ b/sha1-name.c
> > @@ -1837,7 +1837,7 @@ static enum get_oid_result
> > g
On Wed, May 15, 2019 at 10:42:35AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I do have a slight preference for going the _other_ way. There is no
> > need to mark the parameter as const in the definition. It is passed by
> > value, so nobody except the function body cares either way
Jeff King writes:
> I do have a slight preference for going the _other_ way. There is no
> need to mark the parameter as const in the definition. It is passed by
> value, so nobody except the function body cares either way. And we have
> many function bodies where value-passed parameters (or loca
The JGIT prereq uses `type jgit` to determine whether jgit is present.
While this is usually sufficient, it won't help if the jgit found is
badly broken. This wastes time running tests which fail due to no fault
of our own.
Use `jgit --version` instead, to guard against cases where jgit is
presen
Johannes Schindelin writes:
> Hi Junio,
>
> On Tue, 14 May 2019, Junio C Hamano wrote:
>
>> * js/difftool-no-index (2019-05-09) 1 commit
>> - difftool --no-index: error out on --dir-diff (and don't crash)
>>
>> The "--dir-diff" mode of "git difftool" is not useful in "--no-index"
>> mode; they
Hi,
Jeff King wrote:
> On Tue, May 14, 2019 at 02:14:19AM +, brian m. carlson wrote:
>
>> On Mon, May 13, 2019 at 10:05:20PM -0400, Todd Zullinger wrote:
>>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>>> index 908ddb9c46..599fd70e14 100644
>>> --- a/t/test-lib.sh
>>> +++ b/t/test-lib.sh
>>>
Ævar Arnfjörð Bjarmason writes:
>> if test -s "$GIT_DIR/MERGE_RR"
>>
>> It's not clear if that is an internal implementation detail, or a
>> mistaken use of a historic path name. Can anyone enlighten me?
>
> Historic? No, this is path.c now on master:
>
> path.c:1454:REPO_GIT_PATH_FUNC(me
On Tue, May 14, 2019 at 8:54 PM Jeff King wrote:
> diff --git a/sha1-name.c b/sha1-name.c
> index 775a73d8ad..455e9fb1ea 100644
> --- a/sha1-name.c
> +++ b/sha1-name.c
> @@ -1837,7 +1837,7 @@ static enum get_oid_result
> get_oid_with_context_1(struct repository *repo,
> if (flags
Hi,
Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, May 14 2019, Jonathan Nieder wrote:
>
>> Todd Zullinger wrote:
>>
>>> The JGIT prereq uses 'type jgit' to determine whether jgit is present.
>>> While this should be sufficient, if the jgit found is broken we'll waste
>>> time running tests which fa
Ævar Arnfjörð Bjarmason writes:
> Thanks for following up on this. LGTM.
Yeah, thanks, both.
Jeff King writes:
> All that said, I think Todd's patch makes perfect sense even without
> wanting to avoid "type".
Same here. t/lib-bash.sh seems to use "if type bash" to see if one
is available on $PATH; I've never felt the need to avoid "type".
林自均 writes:
> I was not talking about the messages in the editor session. I was
> talking about "git commit" without "git add" anything.
>
> For example:
>
> ```
> $ touch newfile.txt
> $ git commit
> On branch master
> Untracked files:
> newfile.txt
>
> nothing added to commit but untrac
On Tue, May 14, 2019 at 7:53 AM Cosmin Polifronie wrote:
>
> Hello! I am trying to run 'git worktree add HEAD' in the
> 'pre-commit' hook, more specifically in a Python script that is being
> called from the hook. When doing so, I am greeted with the following
> error:
>
> On Windows 10:
> Prepar
Ævar Arnfjörð Bjarmason wrote:
> Aside from this change, I wonder if making "fetch" optionally "exit 1"
> if no refs were updated would be useful, as in the below WIP. Of course
> it would be better to distinguish errors from "no refs to update".
Yes, we should've had this feature all along :)
A
On Tue, May 14, 2019 at 04:24:50PM +0100, Philip Oakley wrote:
> It is not immediately obvious how to use the `git help` system
> to show the git(1) page, with all its background and ccordinating
> material, such as environment variables.
>
> Let's simply list it as the last few words of the last
Jeff King wrote:
> +++ b/sha1-name.c
> @@ -1837,7 +1837,7 @@ static enum get_oid_result
> get_oid_with_context_1(struct repository *repo,
> if (flags & GET_OID_RECORD_PATH)
> oc->path = xstrdup(cp);
>
> - if (!repo->index->cache)
> + i
Hi Ævar,
On 14/05/2019 09:21, Ævar Arnfjörð Bjarmason wrote:
On Tue, May 14 2019, Philip Oakley wrote:
Hi All,
On 10/05/2019 15:59, Philip Oakley wrote:
You can publish your merged branch somewhere, and others can use
contrib/rerere-train.sh to learn from the resolution.
Supposedly, I've ne
In function 'finish_request',
inlined from 'process_response' at http-push.c:248:2:
http-push.c:587:4: warning: '%s' directive argument is null [-Wformat-overflow=]
587 |fprintf(stderr, "Unable to get pack file %s\n%s",
|^
588 |
A subsequent patch will perform the same packfile replacement that is
already done twice, so refactor it into its own function. Also, the same
subsequent patch will use, in another way, part of the packfile
replacement functionality, so extract those out too.
Signed-off-by: Jonathan Tan
---
t/t5
There is an issue when fetching into a partial clone, and the server
sends a REF_DELTA object that is based on a missing promisor object.
Here is a fix; more details are in the commit message of patch 2.
Jonathan Tan (2):
t5616: refactor packfile replacement
index-pack: prefetch missing REF_DE
When fetching, the client sends "have" commit IDs indicating that the
server does not need to send any object referenced by those commits,
reducing network I/O. When the client is a partial clone, the client
still sends "have"s in this way, even if it does not have every object
referenced by a comm
On Tue, May 14, 2019 at 5:19 AM Johannes Schindelin via GitGitGadget
wrote:
> The stash.useBuiltin variable introduced in 90a462725e ("stash:
> optionally use the scripted version again", 2019-02-25) was turned on by
> default, but had no documentation.
>
> Let's document it so that users who run
On 13/05/2019 22:12, Ævar Arnfjörð Bjarmason wrote:
On Mon, May 13 2019, Ben Avison wrote:
+ if (option_remote_submodules == 1) {
I see you copied this from code above the context, but to check a bool
variable just use "if (var)" not "if (var == 1)".
OK. Would you prefer I ed
In anticipation of the expire subcommand, refactor the way we sort
the packfiles by name. This will greatly simplify our approach to
dropping expired packs from the list.
First, create 'struct pack_info' to replace 'struct pack_pair'.
This struct contains the necessary information about a pack,
in
To repack with a non-zero batch-size, first sort all pack-files by
their modified time. Second, walk those pack-files from oldest
to newest, compute their expected size, and add the packs to a list
if they are smaller than the given batch-size. Stop when the total
expected size is at least the batc
The 'git multi-pack-index repack' command can take a batch size of
zero, which creates a new pack-file containing all objects in the
multi-pack-index. The first 'repack' command will create one new
pack-file, and an 'expire' command after that will delete the old
pack-files, as they no longer conta
The 'git multi-pack-index expire' subcommand may delete packs that
are not needed from the perspective of the multi-pack-index. If
a pack has a .keep file, then we should not delete that pack. Add
a test that ensures we preserve a pack that would otherwise be
expired. First, create a new pack that
The multi-pack-index provides a fast way to find an object among a large list
of pack-files. It stores a single pack-reference for each object id, so
duplicate objects are ignored. Among a list of pack-files storing the same
object, the most-recently modified one is used.
Create new subcommands fo
The multi-pack-index tracks objects in a collection of pack-files.
Only one copy of each object is indexed, using the modified time
of the pack-files to determine tie-breakers. It is possible to
have a pack-file with no referenced objects because all objects
have a duplicate in a newer pack-file.
During development of the multi-pack-index expire subcommand, a
version went out that improperly computed the pack order if a new
pack was introduced while other packs were being removed. Part of
the subtlety of the bug involved the new pack being placed before
other packs that already existed in t
Before writing the multi-pack-index, we compute the length of the
pack-index names concatenated together. This forms the data in the
pack name chunk, and we precompute it to compute chunk offsets.
The value is also modified to fit alignment needs.
Previously, this computation was coupled with addi
The repack builtin deletes redundant pack-files and their
associated .idx, .promisor, .bitmap, and .keep files. We will want
to re-use this logic in the future for other types of repack, so
pull the logic into 'unlink_pack_path()' in packfile.c.
The 'ignore_keep' parameter is enabled for the use i
In an environment where the multi-pack-index is useful, it is due
to many pack-files and an inability to repack the object store
into a single pack-file. However, it is likely that many of these
pack-files are rather small, and could be repacked into a slightly
larger pack-file without too much eff
The 'git multi-pack-index expire' subcommand looks at the existing
mult-pack-index, counts the number of objects referenced in each
pack-file, deletes the pack-fils with no referenced objects, and
rewrites the multi-pack-index to no longer reference those packs.
Refactor the write_midx_file() meth
We will add new subcommands to the multi-pack-index, and that will
make the documentation a bit messier. Clean up the 'verb'
descriptions by renaming the concept to 'subcommand' and removing
the reference to the object directory.
Helped-by: Stefan Beller
Helped-by: Szeder Gábor
Signed-off-by: De
From: Phillip Wood
If rebase --quit cannot remove the state directory then it dies. However
when rebase finishes normally or the user runs rebase --abort any errors
that occur when removing the state directory are ignored. That is fixed
by this commit.
All of the callers of finish_rebase() excep
From: Phillip Wood
If there is an error when removing the state directory then we should
report it. This matches what the non-interactive rebase does.
Signed-off-by: Phillip Wood
---
sequencer.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/sequencer.c b/seque
From: Phillip Wood
buf was never freed.
Signed-off-by: Phillip Wood
---
builtin/rebase.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/rebase.c b/builtin/rebase.c
index 82bd50a1b4..90037c9c45 100644
--- a/builtin/rebase.c
+++ b/builtin/rebase.c
@@ -2168,6 +2168,7 @@ int cmd_rebas
From: Phillip Wood
refs/rewritten/ is now cleaned up on --quit as well as --abort. I've
also added a patch to make sequencer_remove_state() to return any
errors, so rebase now always reports any errors that occur when
cleaning up the state directory.
These patches are still based on pw/rebase-i-
From: Phillip Wood
When `rebase -r` finishes it removes any refs under refs/rewritten that
it has created. However if the user aborts or quits the rebase refs are
not removed. This can cause problems for future rebases. For example I
recently wanted to merge a updated version of a topic branch in
Am 14.05.19 um 14:56 schrieb Duy Nguyen:
> On Tue, May 14, 2019 at 7:24 AM brian m. carlson
> wrote:
>> diff --git a/builtin/am.c b/builtin/am.c
>> index 912d9821b1..340eacbd44 100644
>> --- a/builtin/am.c
>> +++ b/builtin/am.c
>> @@ -441,24 +441,8 @@ static int run_applypatch_msg_hook(struct am_s
Hi Junio,
On Mon, May 13, 2019 at 11:44:21AM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > @@ -864,6 +866,20 @@ static int git_format_config(const char *var, const
> > char *value, void *cb)
> > from = NULL;
> > return 0;
> > }
> > + if (!strcmp(v
It is not immediately obvious how to use the `git help` system
to show the git(1) page, with all its background and ccordinating
material, such as environment variables.
Let's simply list it as the last few words of the last usage line.
Signed-off-by: Philip Oakley
---
This follows from the disc
Hi brian,
On Tue, 14 May 2019, brian m. carlson wrote:
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 833ecb316a..29bf80e0d1 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -943,7 +943,7 @@ static int prepare_to_commit(const char *index_file,
> const char *prefix,
>
Hello! I am trying to run 'git worktree add HEAD' in the
'pre-commit' hook, more specifically in a Python script that is being
called from the hook. When doing so, I am greeted with the following
error:
On Windows 10:
Preparing worktree (detached HEAD cbfef18)
fatal: Unable to create 'C:/Users/me
On Tue, 14 May 2019 at 13:34, Duy Nguyen wrote:
>
> On Mon, May 13, 2019 at 7:55 PM Shaheed Haque wrote:
> > The original code used the more obvious "git worktree remove" rather
> > than "git worktree prune" but I switched partly because remove seemed
> > slow (I cannot now quantify what caused m
On Tue, May 14, 2019 at 10:43:06AM -0400, Jeff King wrote:
> On Tue, May 14, 2019 at 02:57:01PM +0200, Johannes Schindelin wrote:
>
> > > But the parameter treated as a constant without getting modified
> > > during the invocation of the function is an implementation detail of
> > > the function;
On Tue, May 14, 2019 at 02:57:01PM +0200, Johannes Schindelin wrote:
> > But the parameter treated as a constant without getting modified
> > during the invocation of the function is an implementation detail of
> > the function; there is no point exposing that implementation detail
> > to its call
Hi Junio,
On 13/05/2019 23:44, Junio C Hamano wrote:
Philip Oakley writes:
On GfW I commonly use the `git --help` when things go wrong, so
making the response to that give the right advice would be good.
There are three levels of details ;-) "git --help" is meant as a
shorter and sweeter ver
Hi Ævar,
On Tue, 14 May 2019, Ævar Arnfjörð Bjarmason wrote:
> On Tue, May 14 2019, Johannes Schindelin wrote:
>
> > On Tue, 14 May 2019, Ævar Arnfjörð Bjarmason wrote:
> >
> >> On Tue, May 14 2019, Johannes Schindelin wrote:
> >>
> >> > What would you think about a mode where random test cases a
On Sat, May 11, 2019 at 07:02:05PM -0400, Jeff King wrote:
> But regardless, I think it makes sense to load the index on demand when
> we need it here, which makes Antonio's original test pass (like the
> patch below).
>
> The segfault ultimately comes from repo_get_oid(); we feed it
> ":.gitmodu
Hi Duy,
On Tue, 14 May 2019, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
> index 106148254d..d453710ef6 100755
> --- a/t/t7600-merge.sh
> +++ b/t/t7600-merge.sh
> @@ -822,4 +822,18 @@ test_expect_success EXECKEEPSPID 'killed merge can be
> completed with --cont
On Tue, May 14 2019, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Tue, 14 May 2019, Ævar Arnfjörð Bjarmason wrote:
>
>> On Tue, May 14 2019, Johannes Schindelin wrote:
>>
>> > What would you think about a mode where random test cases are skipped?
>> > It would have to make sure to provide a way
On Tue, May 14, 2019 at 7:24 AM brian m. carlson
wrote:
> +It is possible to provide multiple hooks for a single function. If the
> +main hook file is absent,
If I remember 1/7 correctly, if the hook "file" is a directory, you
ignore it and check for hook.d too.
Which makes me think, can we just
On Tue, May 14, 2019 at 7:23 AM brian m. carlson
wrote:
>
> This series introduces multiple hook support.
>
> I've thought a lot about the discussion over whether this series should
> use the configuration as the source for multiple hooks. Ultimately, I've
> come to the decision that it's not a go
On Tue, May 14, 2019 at 7:24 AM brian m. carlson
wrote:
>
> There are a variety of situations in which a user may want an error
> behavior for multiple hooks other than the default. Add a config option,
> hook..errorBehavior to allow users to customize this behavior on a
An alternative name is on
On Tue, May 14, 2019 at 7:24 AM brian m. carlson
wrote:
> diff --git a/builtin/am.c b/builtin/am.c
> index 912d9821b1..340eacbd44 100644
> --- a/builtin/am.c
> +++ b/builtin/am.c
> @@ -441,24 +441,8 @@ static int run_applypatch_msg_hook(struct am_state
> *state)
> */
> static int run_post_rewr
Hi Junio,
On Tue, 14 May 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > When this function was changed in a97d00799a19 (remote-curl: use
> > post_rpc() for protocol v2 also, 2019-02-21) from file-local to global,
> > the de
On Tue, May 14, 2019 at 7:24 AM brian m. carlson
wrote:
> -int run_hook_ve(const char *const *env, const char *name, va_list args)
> +int find_hooks(const char *name, struct string_list *list)
> {
> - struct child_process hook = CHILD_PROCESS_INIT;
> - const char *p;
> + struct
Hi Ævar,
On Tue, 14 May 2019, Ævar Arnfjörð Bjarmason wrote:
> On Tue, May 14 2019, Johannes Schindelin wrote:
>
> > What would you think about a mode where random test cases are skipped?
> > It would have to make sure to provide a way to recreate the problem,
> > e.g. giving a string that define
On Mon, May 13, 2019 at 7:55 PM Shaheed Haque wrote:
> The original code used the more obvious "git worktree remove" rather
> than "git worktree prune" but I switched partly because remove seemed
> slow (I cannot now quantify what caused me to think that), and partly
> because I was having other i
On Tue, May 14, 2019 at 02:19:36PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Aside from this change, I wonder if making "fetch" optionally "exit 1"
> if no refs were updated would be useful, as in the below WIP. Of course
> it would be better to distinguish errors from "no refs to update".
That see
On Tue, May 14, 2019 at 12:13:50PM +, Eric Wong wrote:
> I'm not sure when/if I'll have time for this; but this ought to
> be possible:
>
> GIT_DIR=$HTTP_URL git
>
> And possible without existing admins to setup or change
> anything on their server.
> [...]
> git doesn't need mmap; an
Hi Junio,
On Tue, 14 May 2019, Junio C Hamano wrote:
> * "git diff --no-index" may still want to access Git goodies like
>--ext-diff and --textconv, but so far these have been ignored,
>which has been corrected.
>(merge 287ab28bfa jk/diff-no-index-initialize later to maint).
How abo
On Tue, May 14 2019, Eric Wong wrote:
> Jeff King wrote:
>> Yeah, I think there's sort of an open question here of who is calling
>> update-server-info when nothing got updated. I think the only place we
>> call it automatically is via receive-pack, but I'd guess Eric runs it as
>> part of publ
On Tue, May 14, 2019 at 06:29:41PM +0700, Duy Nguyen wrote:
> On Tue, May 14, 2019 at 07:21:15AM -0400, Jeff King wrote:
> > I also think the "warning: refname ... is ambiguous" message would
> > probably be a bit more helpful if it showed _which_ candidates it found
> > (and which one it chose!).
Eric Wong wrote:
> Jeff King wrote:
> > That's my reading, too, but I didn't want to be responsible for
> > regressing some obscure case. At least Eric seems to _use_
> > update-server-info. ;)
>
> I also have something else on my mind for abusing info files with :>
> (another email)
I'm not su
When the user asks to merge "foo" and we suggest "origin/foo" instead,
we do so by simply chopping off "refs/remotes/" from the front of the
suggested ref. This is usually fine, but it's possible that the
resulting name is ambiguous (e.g., you have "refs/heads/origin/foo",
too).
Let's use shorten_
When "git merge" sees an unknown refname, we iterate through the refs to
try to suggest some possible alternates. We do so with for_each_ref(),
and in the callback we add some of the refnames we get to a
string_list that is declared with NODUP, directly adding a pointer into
the refname string our
On Tue, May 14, 2019 at 07:21:15AM -0400, Jeff King wrote:
> But I agree we could be more helpful in the messages.
>
> The "did you mean?" advice just blindly says "oh, you asked for X and
> refs/remotes/ABC/X exists, so let's suggest ABC/X", without checking for
> ambiguities. It should probably
On Tue, May 14 2019, Jeff King wrote:
> On Tue, May 14, 2019 at 12:33:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > I think it would work because any update-server-info, whether from A or
>> > B, will take into account the full current repo state (and we don't look
>> > at that state until w
Jeff King wrote:
> Yeah, I think there's sort of an open question here of who is calling
> update-server-info when nothing got updated. I think the only place we
> call it automatically is via receive-pack, but I'd guess Eric runs it as
> part of public-inbox scripts.
Correct. post-update doesn'
Hi!
The confusing part actually is for me:
"git clone" does NOT "Clone a repository into a new directory", but "clone the
current branch into a new directory" (IMHO).
So I was surprised that I couldn't merge branches under the same name in the
cloned "repository".
Only "git clone --bare" actuall
On Tue, May 14, 2019 at 07:21:15AM -0400, Jeff King wrote:
> I also think the "warning: refname ... is ambiguous" message would
> probably be a bit more helpful if it showed _which_ candidates it found
> (and which one it chose!).
Alternatively, just refuse to resolve ambiguous refs. It's not alwa
On Tue, May 14, 2019 at 12:33:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I think it would work because any update-server-info, whether from A or
> > B, will take into account the full current repo state (and we don't look
> > at that state until we take the lock). So you might get an interleav
From: Johannes Schindelin
Update a code comment that referred to those files as if they were still
there.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index f88a97fb10..334de14542 100644
--- a/s
From: Johannes Schindelin
The only remaining scripted part of `git rebase` is the
`--preserve-merges` backend. Meaning: there is little reason to keep the
"library of common rebase functions" as a separate file.
While moving the functions to `git-rebase--preserve-merges.sh`, we also
drop the `mo
From: Johannes Schindelin
One test case's title mentioned the then-current implementation detail
that the `--am` backend was implemented in `git-rebase--am.sh`.
This is no longer the case, so let's update the title to reflect the
current reality.
Signed-off-by: Johannes Schindelin
---
t/t3400
From: Johannes Schindelin
This went away in 0609b741a4 (rebase -i: combine rebase--interactive.c
with rebase.c, 2019-04-17).
Signed-off-by: Johannes Schindelin
---
.gitignore | 1 -
1 file changed, 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index 875f3fc6e8..bcee4fda81 100644
--- a/.g
From: Johannes Schindelin
Since 21853626ea (built-in rebase: call `git am` directly, 2019-01-18),
the built-in rebase already uses the built-in `git am` directly.
Now that d03ebd411c (rebase: remove the rebase.useBuiltin setting,
2019-03-18) even removed the scripted rebase, there is no longer a
Technically, there is still one part that is scripted: git rebase
--preserve-merges. But that is already deprecated, and the remaining parts
really are no longer scripted.
Meaning that we do not need git-rebase--am.sh.
While at it, clean up a few other places that reference the scripted rebase,
a
On Tue, May 14, 2019 at 11:54:43AM +0200, Ulrich Windl wrote:
> > git branch --track origin/f-gcc-4.8
> Branch origin/f-gcc-4.8 set up to track local branch next.
> > git fetch
> > git branch
> f-systemd
> integration
> master
> * next
> origin/f-gcc-4.8
> > git merge f-gcc-4.8
> merge: f-
Hi,
Am 2019-05-14 um 00:17 schrieb Ævar Arnfjörð Bjarmason:
Update sha1dc from the latest version by the upstream
maintainer[1]. See 07a20f569b ("Makefile: fix unaligned loads in
sha1dc with UBSan", 2019-03-12) for the last update.
This fixes an issue where HP-UX IA64 was wrongly detected as a
1 - 100 of 132 matches
Mail list logo
