On Mon, Feb 15, 2016 at 06:42:30PM +0100, Thomas Gummerer wrote:
> Both remote add and remote rename use a slightly different hand-rolled
> check if the remote exits. The hand-rolled check may have some subtle
> cases in which it might fail to detect when a remote already exists.
> One such case
On Mon, Feb 15, 2016 at 06:42:29PM +0100, Thomas Gummerer wrote:
> When converting the git remote command to a builtin in 211c89 ("Make
> git-remote a builtin"), a few calls to check if a remote exists were
> converted from:
>if (!exists $remote->{$name}) {
> [...]
> to:
>
On Mon, Feb 15, 2016 at 06:42:28PM +0100, Thomas Gummerer wrote:
> The remote_is_configured() function allows checking whether a remote
> exists or not. The function however only works if remote_get() wasn't
> called before calling it. In addition, it only checks the configuration
> for remotes,
On Mon, Feb 15, 2016 at 06:42:27PM +0100, Thomas Gummerer wrote:
> 95b567c7 ("use skip_prefix to avoid repeating strings") transformed
> calls using starts_with() and then skipping the length of the prefix to
> skip_prefix() calls. In remote.c there are a few calls like:
>
> if (starts_with(fo
On Mon, Feb 15, 2016 at 9:29 AM, Carlos Martín Nieto wrote:
> These were silly from the beginning, but we have to support them for
It might be helpful to cite some reference to support the claim that
they are "silly" since it's not necessarily obvious to readers who did
not following the discussi
On Mon, Feb 15, 2016 at 11:17:46AM +0100, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
>
> If config values are queried using 'git config' (e.g. via --get,
> --get-all, --get-regexp, or --list flag) then it is sometimes hard to
> find the configuration file where the values were define
On Mon, Feb 15, 2016 at 11:17:43AM +0100, larsxschnei...@gmail.com wrote:
> I like the idea of a "test set up block" within a test script. In order
> to clean up nicely before any subsequent tests I would like to propose
> a "tear down" block. Would that work as a compromise in our "test cases
> d
On 15/02/16 05:50, Junio C Hamano wrote:
Torsten Bögershausen writes:
* tb/conversion (2016-02-10) 6 commits
(merged to 'next' on 2016-02-12 at 6faf27b)
Could we keep it in next for a while ?
I found issues that needs to be fixed before going to master,
updates follow soonish.
Hmph, I
95b567c7 ("use skip_prefix to avoid repeating strings") transformed
calls using starts_with() and then skipping the length of the prefix to
skip_prefix() calls. In remote.c there are a few calls like:
if (starts_with(foo, "bar"))
foo += 3
These calls weren't touched by the commit mention
When converting the git remote command to a builtin in 211c89 ("Make
git-remote a builtin"), a few calls to check if a remote exists were
converted from:
if (!exists $remote->{$name}) {
[...]
to:
remote = remote_get(argv[1]);
if (!remote)
[...]
The new chec
Both remote add and remote rename use a slightly different hand-rolled
check if the remote exits. The hand-rolled check may have some subtle
cases in which it might fail to detect when a remote already exists.
One such case was fixed in fb86e32 ("git remote: allow adding remotes
agreeing with url.
The remote_is_configured() function allows checking whether a remote
exists or not. The function however only works if remote_get() wasn't
called before calling it. In addition, it only checks the configuration
for remotes, but not remotes or branches files.
Make use of the origin member of stru
In builtin/remote.c there are a few cases which check whether a remote
exists or not. These checks are however done inconsistently, and in a
few cases they don't check anything at all. This patch series tries
to improve the situation.
I stumbled upon this when I mistyped the remote name in git r
On Mon, Feb 15, 2016 at 11:17:45AM +0100, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
>
> Use the config type to print more detailed error messages that inform
> the user about the origin of a config error (file, stdin, blob).
>
> Signed-off-by: Lars Schneider
> ---
> cache.h
On Mon, Feb 15, 2016 at 11:17:44AM +0100, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
>
> Git should not be on the left-hand side of a pipe, because it hides the exit
> code, and we want to make sure git does not fail.
I think this is a nice cleanup.
> There is one more occurrence o
Hi Andreas,
I am looking into a similar issue with SourceTree on Windows right now.
However, in my case it only happens when I switch branches. I investigated the
Git commands that SourceTree triggers and it looks like it is doing something
like this:
(1) Run checkout command
git.exe --no-page
On Mon, Feb 15, 2016 at 09:18:50AM -0600, Robert Dailey wrote:
> As you know, I can checkout the Nth checked out branch via this syntax:
>
> $ git checkout @{-N}
>
> Is there a built-in mechanism to get a listing of previously checked
> out refs? Basically, this would be similar to 'history' com
As you know, I can checkout the Nth checked out branch via this syntax:
$ git checkout @{-N}
Is there a built-in mechanism to get a listing of previously checked
out refs? Basically, this would be similar to 'history' command in
linux where instead of actual commands, it lists like this:
HEAD@{-
你的老朋友邀你来Q群:343257759
These were silly from the beginning, but we have to support them for
compatibility. That doesn't mean we have to show them in the
documentation. These were already left out of the main list, but a
reference in the main manpage was left, so remove that.
Also add a note to discourage their use if an
Add the http.pinnedpubkey configuration option for public key
pinning. It allows any string supported by libcurl --
base64(sha256(pubkey)) or filename of the full public key.
If cURL does not support pinning (is too old) output a warning to the
user.
Signed-off-by: Christoph Egger
---
This ver
Jeff King writes:
> We can't do this perfectly, because older versions of git do not yet
> know about the option, and will therefore just silently ignore it. And
> for consistency there, we usually do the same for features that we know
> about but are unsupported.
Jep that's why I originally did
Current code does not update "symref" when -B is used. This string
contains the new HEAD. Because it's empty "git worktree add -B" fails at
symbolic-ref step.
Because branch creation is already done before calling add_worktree(),
-B is equivalent to -b from add_worktree() point of view. We do not
If --force is not given but -B is, we should not proceed if the given
branch is already checked out elsewhere. add_worktree() has this test,
but it kicks in too late when "git branch --force" is already
executed. As a result, even though we correctly refuse to create a new
worktree, we have already
Felipe Gonçalves Assis writes:
> However, if you do find this approach acceptable/desirable
> (rename-threshold > 100%), I can work on the issues pointed out and
> propose a proper patch.
The caller asks diffcore-rename to detect rename, and the algorithm
compares things to come up with a simila
On 15 February 2016 at 06:06, Johannes Schindelin
wrote:
> Hi Felipe,
>
> On Sun, 14 Feb 2016, Felipe Gonçalves Assis wrote:
>
>> Attached is a quick and dirty patch that emulates the effect by
>> allowing greater than 100% rename thresholds to mean "no-renames".
>
> It is really hard to comment o
From: Lars Schneider
Use the config type to print more detailed error messages that inform
the user about the origin of a config error (file, stdin, blob).
Signed-off-by: Lars Schneider
---
cache.h| 6 --
config.c | 36 +---
su
From: Lars Schneider
If config values are queried using 'git config' (e.g. via --get,
--get-all, --get-regexp, or --list flag) then it is sometimes hard to
find the configuration file where the values were defined.
Teach 'git config' the '--show-origin' option to print the source
configuration f
From: Lars Schneider
diff to v3:
* pass type as parameter to "git_config_from_mem" (renamed from
"git_config_from_buf") and "do_config_from_file"
* split current_config_type_name into two functions
* explain usage of fwrite with a comment
* use tabs instead of spaces to fix indentation error
*
From: Lars Schneider
Git should not be on the left-hand side of a pipe, because it hides the exit
code, and we want to make sure git does not fail.
There is one more occurrence of this pattern in t9010-svn-fe.sh which is to
evolved to change it easily.
Helped-by: Jeff King
Signed-off-by: Lars
On 15-02-16, 02:06, Junio C Hamano wrote:
> Viresh Kumar writes:
>
> > linux...@vger.kernel.org) (open list:OPERATING PERFORMANCE POINTS
> > (OPP),
>
> Hmm
>
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/2014-July/011343.html
>
> comes to mind. It tells you not to blindly automate
Viresh Kumar writes:
> linux...@vger.kernel.org) (open list:OPERATING PERFORMANCE POINTS
> (OPP),
Hmm
http://lists.kernelnewbies.org/pipermail/kernelnewbies/2014-July/011343.html
comes to mind. It tells you not to blindly automate this process.
I do not offhand know if it was even designed t
Tim Ringenbach wrote:
> Hi,
>
> 'git svn dcommit' doesn't seem to honor the --username argument when
> my svn repository url is a file:/// url. It doesn't complain either,
> it just seems to silently ignore the option. My dcommits show up as
> the user I'm logged in as. The only way I found to c
Hi,
is there a reason why those messages for pull are sent to stdout and
for push are sent to stderr?
flo@p3:~$ git pull
Already up-to-date.
flo@p3:~$ git pull >/dev/null
flo@p3:~$ git push
Everything up-to-date
flo@p3:~$ git push >/dev/null
Everything up-to-date
I am regularly trying to build
Johannes Schindelin writes:
> On Sun, 14 Feb 2016, Junio C Hamano wrote:
>
>> Felipe Gonçalves Assis writes:
>>
>> > The usual workaround is using the resolve strategy, but apparently it
>> > ignores the custom merge driver.
>>
>> Hmph.
>>
>> Indeed, git-merge-file seems to call xdl_merge() d
On Sun, Feb 14, 2016 at 7:04 PM, Duy Nguyen wrote:
> On Sat, Feb 6, 2016 at 2:44 AM, David Turner wrote:
>> +static char *get_refdb_path(const char *base)
>> +{
>> + static struct strbuf path_buf = STRBUF_INIT;
>> + strbuf_reset(&path_buf);
>> + strbuf_addf(&path_buf, "%s/refdb"
On Tue, Feb 09, 2016 at 05:54:01PM +0300, Kirill Likhodedov wrote:
> Git doesn’t allow me to execute
> git worktree add -B
> where already exists in the repository.
>
> The command prints the following:
> Preparing (identifier )
> fatal: Refusing to point HEAD outside of refs/
>
On 13 Feb 2016, at 19:15, Jeff King wrote:
> On Sat, Feb 13, 2016 at 01:04:12PM -0500, Jeff King wrote:
>
>> On Sat, Feb 13, 2016 at 12:44:49PM -0500, Jeff King wrote:
>>
+test_expect_success '--show-origin' '
>>> [...]
>>> I see you split this up more, but there's still quite a bit going
If there is a pattern "!foo/bar", this patch makes it not exclude
"foo" right away. This gives us a chance to examine "foo" and
re-include "foo/bar".
Helped-by: brian m. carlson
Helped-by: Micha Wiedenmann
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/gitignore.txt | 1
Given path "a" and the pattern "a", it's matched. But if we throw path
"a/b" to pattern "a", the code fails to realize that if "a" matches
"a" then "a/b" should also be matched.
When the pattern is matched the first time, we can mark it "sticky", so
that all files and dirs inside the matched path
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-check-ignore.txt | 1 +
Documentation/git.txt | 5 +
dir.c | 20
3 files changed, 26 insertions(+)
diff --git a/Documentation/git-check-ignore.txt
b/Documentation/git-c
Given the pattern "1/2/3/4" and the path "1/2/3/4/f", the pattern
prefix is "1/2/3/4". We will compare and remove the prefix from both
pattern and path and come to this code
/*
* If the whole pattern did not have a wildcard,
* then our prefix match is all we need; we
Take one was bad and reverted in commit 8c72236. Take two provides a
more complete solution to the pair of rules
exclude/this
!exclude/this/except/this
3/4 should do a better job at stopping regressions in take 1. 4/4
provides the solution. I think I have tested (and wrote tests) for all
the
Hi Guys,
I am facing a strange issue with git send-email, with cccmd and was
looking for some help.
I am using it with Linux Kernel..
I used get-maintainers today to submit few patches for OPP framework
and that is defined as below in MAINTAINERS:
OPERATING PERFORMANCE POINTS (OPP)
M: Vire
On Mon, Feb 15, 2016 at 12:52:26AM -0500, Eric Sunshine wrote:
> Yes, dropping 'const' was implied. I didn't examine it too deeply, but
> it did not appear as if there would be any major fallout from dropping
> 'const'. It feels a bit cleaner to keep it all self-contained than to
> have that somewh
Hi Junio,
On Sun, 14 Feb 2016, Junio C Hamano wrote:
> Felipe Gonçalves Assis writes:
>
> > The usual workaround is using the resolve strategy, but apparently it
> > ignores the custom merge driver.
>
> Hmph.
>
> Indeed, git-merge-file seems to call xdl_merge() directly, bypassing
> the ll_me
Hi Felipe,
On Sun, 14 Feb 2016, Felipe Gonçalves Assis wrote:
> Attached is a quick and dirty patch that emulates the effect by
> allowing greater than 100% rename thresholds to mean "no-renames".
It is really hard to comment on attached patches.
First comment: the commit message is awfully emp
Good day! Dear Sir or Madam!
please at the top of any page of site click once on the advertising banner,
so that we could pay for hosting our school site,
Thank you
ad...@bilokaminsky-nvk.pp.ua
http://bilokaminsky-nvk.pp.ua/
добрий день,
просимо на будь-якій сторінці вгорі один раз натиснути на
On Tue, Feb 9, 2016 at 4:09 AM, Junio C Hamano wrote:
>> + is_repository_shallow(); /* make sure shallows are read */
>> +
>> + init_revisions(&revs, NULL);
>> + save_commit_buffer = 0;
>> + setup_revisions(ac, av, &revs, NULL);
>> +
>> + /* Mark all reachable commits as NOT_SH
101 - 149 of 149 matches
Mail list logo
