On Thu, Feb 28, 2019 at 08:54:23AM +0300, Sergey Organov wrote:
> Hello,
>
> How do I configure git to handle tags from remotes in a manner similar
> to branches?
>
> Specifically, I want tag 'tag_name' from remote 'origin' to have local
> name 'origin/tag_name', not 'tag_name', as it is by defau
Thanks for the answers. So it seems it's not a bug, but may lead to new merge
options. I worked around it anyway, so it was not a real problem.
Med vänlig hälsning
Linus Nilsson
-Original Message-
From: Elijah Newren
Sent: Wednesday, 27 February 2019 18:32
To: Jeff King
Cc: Phillip Wo
On Thu, 28 Feb 2019 at 03:44, Kyle Meyer wrote:
> Change it to "linkgit" so that the reference is properly rendered.
> have `` as direct ancestor will keep their original branch point,
> -i.e. commits that would be excluded by gitlink:git-log[1]'s
> +i.e. commits that would be excluded by linkg
Hi!
If there are colons in the beginning of a patch subject line `git-am'
will drop them.
Consider the following patch:
$ cat 0001-four-colons-prepended.patch
From e8213a2d10a61c9dc75521d88d656b8d5330e6bb Mon Sep 17 00:00:00 2001
From: Max Filenko
Date: Tue, 12 Feb 2019 12:21:21
Hi Nazri,
On Wed, 27 Feb 2019, Nazri Ramliy wrote:
> On Wed, Jan 9, 2019 at 10:08 PM Johannes Schindelin
> wrote:
Oh wow. Better late than never, eh?
> > Having said that, it is an unintended regression in the built-in
> > rebase. Markus, could you come up with a minimal test case, preferably
Replace test -(d|f|e) calls in t3600-rm.sh. Previously we were using test
-(d|f|e) to verify the presence of a directory/file, but we already have
helper functions, viz, test_path_is_dir, test_path_is_file and
test_path_is_missing with better functionality.
Rohit Ashiwal (1):
t3600: use test_pat
From: Rohit Ashiwal
Replace `test -(d|f|e)` calls in t3600-rm.sh
Previously we were using `test -(d|f|e)` to verify
the presence of a directory/file, but we already
have helper functions, viz, `test_path_is_dir`,
`test_path_is_file` and `test_path_is_missing`
with better functionality.
These he
Hey Duy
>
> On the Git mailing list, Duy Nguyen wrote (reply to this):
>
> I was a bit worried that the "test ! something" could be incorrectly
> converted because for example, "test ! -d foo" is not always the same
> as "test_path_is_missing". If "foo" is intended to be a file, then the
> convers
Hey Duy
Sorry for late reply.
>
> On the Git mailing list, Duy Nguyen wrote (reply to this):
>
> I was a bit worried that the "test ! something" could be incorrectly
> converted because for example, "test ! -d foo" is not always the same
> as "test_path_is_missing". If "foo" is intended to be a fi
On Thu, Feb 28, 2019 at 11:02:11AM +0100, Max Filenko wrote:
> Subject: [PATCH] four colons prepended
> [...]
> There will be no colons in the beginning of a commit message if I apply
> this patch:
>
> $ git am 0001-four-colons-prepended.patch
> Applying: four colons prepended
I
<<< No Message Collected >>>
From: Johannes Schindelin
The ORIG_HEAD pseudo ref is supposed to refer to the original,
pre-rebase state after a successful rebase. Let's add a regression test
to prove that this regressed: With GIT_TEST_REBASE_USE_BUILTIN=false,
this test case passes, with GIT_TEST_REBASE_USE_BUILTIN=true (or u
From: Johannes Schindelin
Technically, the scripted version set ORIG_HEAD only in two spots (which
really could have been one, because it called `git checkout $onto^0` to
start the rebase and also if it could take a shortcut, and in both cases
it called `git update-ref $orig_head`).
Practically,
It was reported by Nazri Ramliy that ORIG_HEAD was set incorrectly again,
this time caused by the shortcut to call git am directly, without detouring
to a Unix shell script.
Patch 2/4 might look like something completely unrelated, but without it,
the update to HEAD might use an incorrect reflog m
From: Johannes Schindelin
By mistake, we used the reflog intended for ORIG_HEAD.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/rebase.c b/builtin/rebase.c
index 813ec284ca..aa469ec964 100644
--- a/builtin/reb
From: Johannes Schindelin
In the case that the rebase boils down to a fast-forward, the built-in
rebase reset the working tree twice: once to start the rebase at `onto`,
then realizing that the original HEAD was an ancestor, `reset_head()`
was called to update the original ref and to point HEAD b
Hey people
I had a discussion with Rafael over the #git irc channel and Thanks to
him I was able to find these minute mistakes:
1. Commit message was less than 50 chars which should be around 72 chars
according to coding guide lines. Should I change this to match 72?
2. My changes had some un
We have something much better now: a real Azure Pipeline. Not only is it a
lot faster (due to parallelizing the test suite), it also won't time out
waiting for the Windows job to start.
Johannes Schindelin (1):
travis: remove the hack to build the Windows job on Azure Pipelines
.travis.yml
From: Johannes Schindelin
Since Travis did not support Windows (and now only supports very limited
Windows jobs, too limited for our use, the test suite would time out
*all* the time), we added a hack where a Travis job would trigger an
Azure Pipeline (which back then was still called VSTS Build)
After we set up a `struct repository_format`, it owns various pieces of
allocated memory. We then either use those members, because we decide we
want to use the "candidate" repository format, or we discard the
candidate / scratch space. In the first case, we transfer ownership of
the memory to a fe
This is a follow-up to v3 [1] from about a month ago. Patch 1 is
unchanged; patch 2 provides some additional documentation of the
initialization that is required, plus I've gotten rid of the compound
literal. Range-diff below.
Thanks Peff and brian for very helpful comments and discussion.
Martin
Before assigning to `data->work_tree` in `read_worktree_config()`, free
any value we might already have picked up, so that we do not leak it.
Signed-off-by: Martin Ågren
Signed-off-by: Junio C Hamano
---
setup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/setup.c b/setup.c
index 1be5037
Hi Johannes
On 28/02/2019 15:27, Johannes Schindelin via GitGitGadget wrote:
From: Johannes Schindelin
In the case that the rebase boils down to a fast-forward, the built-in
rebase reset the working tree twice: once to start the rebase at `onto`,
then realizing that the original HEAD was an an
On Wed, Feb 27, 2019 at 10:46:49PM -0400, Brandon Richardson wrote:
> > If we are going to go this route, I think you might actually want macros
> > that take both "unset" and "args" and make sure that we're not in a
> > situation the callback doesn't expect (e.g., "!unset && !arg"). That
> > lets
On Fri, Feb 22, 2019 at 04:05:45PM +, Olga Telezhnaya wrote:
> Start using ref_format struct instead of simple char*.
> Need that for further reusing of formatting logic from ref-filter.
Makes sense.
> struct batch_options {
> + struct ref_format format;
> int enabled;
> int
On Fri, Feb 22, 2019 at 04:05:45PM +, Olga Telezhnaya wrote:
> Rename objectname field to oid in struct ref_array_item.
> We usually use objectname word for string representation
> of object id, so oid explains the content better.
OK. I suspect the original was selected to match the %(objectn
On Fri, Feb 22, 2019 at 04:05:45PM +, Olga Telezhnaya wrote:
> Add rest option that allows to add string into ref_array_item
> and then put it into specific place of the output.
> We are using it now in cat-file command: user could put anything
> in the input after objectname, and it will appe
On Fri, Feb 22, 2019 at 04:05:45PM +, Olga Telezhnaya wrote:
> Add tests for new formatting atom %(rest).
> We need this atom for cat-file command.
While I do normally encourage splitting up commits, in this case I think
it would make sense to squash this together with patch 3. There's
nothin
Hi, Ævar
I'm finishing the required changes in this series to send a v4, but
when submitting to travis ci, I got some errors on the
t5604-clone-reference test:
https://travis-ci.org/MatheusBernardino/git/builds/57587
Do you have any idea why?
Best,
Matheus Tavares
On Tue, Feb 26, 2019 at 9:
On Fri, Feb 22, 2019 at 04:05:45PM +, Olga Telezhnaya wrote:
> Get rid of split_on_whitespace field in struct expand_data.
> expand_data may be global further as we use it in ref-filter also,
> so we need to remove cat-file specific fields from it.
OK, that makes some sense.
> diff --git a/b
On Fri, Feb 22, 2019 at 04:05:45PM +, Olga Telezhnaya wrote:
> Get rid of mark_query field in struct expand_data.
> expand_data may be global further as we use it in ref-filter also,
> so we need to remove cat-file specific fields from it.
>
> All globals that I add through this patch will be
On Fri, Feb 22, 2019 at 04:05:45PM +, Olga Telezhnaya wrote:
> Get rid of skip_object_info field in struct expand_data.
> expand_data may be global further as we use it in ref-filter also,
> so we need to remove cat-file specific fields from it.
>
> All globals that I add through this patch w
On Fri, Feb 22, 2019 at 04:05:45PM +, Olga Telezhnaya wrote:
> Get rid of rest field in struct expand_data.
> expand_data may be global further as we use it in ref-filter also,
> so we need to remove cat-file specific fields from it.
>
> All globals that I add through this patch will be delet
On Fri, Feb 22, 2019 at 04:05:45PM +, Olga Telezhnaya wrote:
> Put struct expand_data into global scope to reuse it
> in cat-file.
So this is the payoff for moving all those things out of expand_data.
Instead of just replicating the bits it needs in ref-filter, we're
making it globally availa
On Fri, Feb 22, 2019 at 04:05:45PM +, Olga Telezhnaya wrote:
> Inline function stream_blob, it simplifies further
> migrating process.
I'd have to see what exactly gets simplified later on, but I'm mildly
negative on this by itself. The reason this function was added in
98f425b453 (cat-file:
On Fri, Feb 22, 2019 at 06:50:06PM +0300, Olga Telezhnaya wrote:
> It was a long way for me, I got older (by 1 year) and smarter
> (hopefully), and maybe I will finish my Outreachy Internship task for
> now. (I am doing it just for one year and a half, that's OK)
Welcome back!
Sorry to be a bit
On Fri, Feb 22, 2019 at 06:50:06PM +0300, Olga Telezhnaya wrote:
> In my opinion, it still has some issues. I mentioned all of them in
> TODOs in comments. All of them considered to be separate tasks for
> other patches. Some of them sound easy and could be great tasks for
> newbies.
One other th
I accidentally executed git reset —hard in a project that doesn’t have any
commits yet. git erased everything, everything I’ve worked the past week, I
believe this is not a desired behavior, considering I’m not able to undo that
action, because git doesn’t have any history whatsoever.
Hi, everyone
I've been in the mailing list for a couple weeks now, mainly working
on my gsoc micro-project[1] and in other patches that derived from it.
I also have been contributing to the Linux Kernel for half an year,
but am now mainly just supporting other students here at USP.
I have read th
Gooday To You,
Please i need your kind Assistance. I will be very glad if you can
assist me to receive this sum of ( $22. Million US dollars.) into your
bank account for the benefit of our both families, reply me if you are
ready to receive this fund.
Hi Matheus,
On Thu, Feb 28, 2019 at 10:46 PM Matheus Tavares Bernardino
wrote:
>
> I've been in the mailing list for a couple weeks now, mainly working
> on my gsoc micro-project[1] and in other patches that derived from it.
> I also have been contributing to the Linux Kernel for half an year,
>
Hi,
I was playing with the completion.commands config added in
6532f3740b ("completion: allow to customize the completable
command list", 2018-05-20) and noticed an issue removing
multiple commands.
I wanted to remove completion for cherry and mergetool, so I
added them both to the config:
g
Dear Friend,
I am Mrs Clara David. am sending you this brief letter to solicit your
partnership to transfer $18.5 million US Dollars.I shall send you more
information and procedures when I receive positive response from you.
please send me a message in my Email box (mrsclarada...@gmail.com)
as i w
On Thu, Feb 28, 2019 at 05:31:23PM -0500, Todd Zullinger wrote:
> Hi,
>
> I was playing with the completion.commands config added in
> 6532f3740b ("completion: allow to customize the completable
> command list", 2018-05-20) and noticed an issue removing
> multiple commands.
>
> I wanted to remov
On Thu, Feb 28, 2019 at 05:31:23PM -0500, Todd Zullinger wrote:
> I was playing with the completion.commands config added in
> 6532f3740b ("completion: allow to customize the completable
> command list", 2018-05-20) and noticed an issue removing
> multiple commands.
>
> I wanted to remove completi
Hi,
Sorry for the slow followup. Thanks for probing into the design ---
this should be useful for getting the docs to be clear.
Christian Couder wrote:
> So it's likely that users will want a way to host on such sites
> incomplete repos using CDN offloading to a CDN on another site. And
> then
On Wed, Feb 27, 2019 at 07:17:51PM +0100, Martin Ågren wrote:
> Just like v1 [1], this v2 removes a spurious space which shows up in a
> large number of places in our manpages when Asciidoctor expands the
> linkgit:foo[bar] macro. The only difference is a new paragraph in the
> commit message of th
On 2019.02.23 15:39, Jonathan Tan wrote:
> Teach upload-pack to send part of its packfile response as URIs.
>
> An administrator may configure a repository with one or more
> "uploadpack.blobpackfileuri" lines, each line containing an OID and a
> URI. A client may configure fetch.uriprotocols to b
> So we process the packfile URIs one by one as we receive them from the
> server? If we expect these packfiles to be large (otherwise why are we
> bothering to offload them to the CDN), is there a risk that the
> connection to the server might time out while we're downloading from the
> CDN?
You'
Jeff King writes:
> I'm actually a little torn on this. We could consider this a bug, and
> the "option" to disable it when you want things to go fast is to say
> "--no-dangling". That leaves no way to say "show me the list of
> unreachable objects, but don't bother spending extra time on danglin
Rohit Ashiwal writes:
> 1. Commit message was less than 50 chars which should be around 72 chars
>according to coding guide lines. Should I change this to match 72?
Simple things do not need that many letters to tell ;-) The
suggestion of 72 is about the maximum.
If you are doing somethi
As you know that I've always been skeptical to this rename-directory
business, this probably won't come as a surprise, but I seriously
think directory renames should be made opt-in, and as a separate
option, making the option three-way. I.e.
- do we do any renames (yes/no)?
- if we do do renam
Ævar Arnfjörð Bjarmason writes:
> I swear I'm not just on a mission to ruin everyone's GSOC projects. This
> patch definitely looks good, and given that we have this / document it
> makes sense.
>
> However. I wonder in general if we've re-visited the utility of these
> wrappers and maybe other s
Alban Gruin writes:
>> Was still being worked on, but seems to have stalled.
>> cf.
>> cf. <97f77aca-bd19-f763-349a-de40c4b94...@talktalk.net>
>
> I’m still working on this. I sent a v7 shortly after the release of v2.21.0-
> rc0, and I almost finished the v8.
Thanks for an update. Perhaps
пт, 1 мар. 2019 г. в 00:11, Jeff King :
>
> On Fri, Feb 22, 2019 at 04:05:45PM +, Olga Telezhnaya wrote:
>
> > Add tests for new formatting atom %(rest).
> > We need this atom for cat-file command.
>
> While I do normally encourage splitting up commits, in this case I think
> it would make sens
пт, 1 мар. 2019 г. в 00:41, Jeff King :
>
> On Fri, Feb 22, 2019 at 06:50:06PM +0300, Olga Telezhnaya wrote:
>
> > It was a long way for me, I got older (by 1 year) and smarter
> > (hopefully), and maybe I will finish my Outreachy Internship task for
> > now. (I am doing it just for one year and a
пт, 1 мар. 2019 г. в 00:43, Jeff King :
>
> On Fri, Feb 22, 2019 at 06:50:06PM +0300, Olga Telezhnaya wrote:
>
> > In my opinion, it still has some issues. I mentioned all of them in
> > TODOs in comments. All of them considered to be separate tasks for
> > other patches. Some of them sound easy an
Hi,
I have a problem with fast-import on an NTFS drive: If I try to import tags
which are identical apart from their casing a failure due to identical lock
file names occurs.
I am running git for windows 2.15.1.2 x64 on a Windows 10 machine (10.0.15063):
$ git --version --build-options
git vers
Am 28.02.19 um 22:43 schrieb Manuel Guilamo:
> I accidentally executed git reset —hard in a project that doesn’t
> have any commits yet. git erased everything, everything I’ve worked
> the past week, I believe this is not a desired behavior, considering
> I’m not able to undo that action, because g
59 matches
Mail list logo
