Previously, git-credential-store only supported storing credentials in a
single file: ~/.git-credentials. In order to support the XDG base
directory specification[1], git-credential-store needs to be able to
lookup and erase credentials from multiple files, as well as to pick the
appropriate file t
Add $XDG_CONFIG_HOME/git/credentials to the default credential search
path of git-credential-store. This allows git-credential-store to
support user-specific configuration files in accordance with the XDG
base directory specification[1].
[1] http://standards.freedesktop.org/basedir-spec/basedir-sp
t0302 now tests git-credential-store's support for the XDG user-specific
configuration file $XDG_CONFIG_HOME/git/credentials. Specifically:
* Ensure that the XDG file is strictly opt-in. It should not be created
by git at all times if it does not exist.
* Conversely, if the XDG file exists, ~/.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Why does gitk -g master not work? I would expect gitk to load up the
master branch reflog and show each of the previous heads that master
has transitioned through, but it doesn't. Instead I have to run gitk
master@{1} master@{2}, etc, and then, whi
On Mon, Mar 23, 2015 at 9:00 PM, Duy Nguyen wrote:
> On Sun, Mar 22, 2015 at 10:33 AM, Eric Sunshine
> wrote:
>> On Fri, Mar 20, 2015 at 6:36 AM, wrote:
>>> Any idea what I am doing wrong?
>>
>> The fourth bullet point of the "Pattern Format" section of the
>> gitignore man page has this to sa
On Fri, Mar 20, 2015 at 6:07 AM, Philip Oakley wrote:
> Hi, I was expecting that sparse checkout could be used to avoid the checking
> out, by git, of files which have colons in their name into the worktree when
> on Windows.
>
> Yue Lin Ho reported on the Msygit list [1] that he had a repo where
On Thu, Mar 19, 2015 at 1:00 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Ah, wait.
>>
>> I suspect that it all cancels out.
>> ...
>> Now, as you mentioned, there _may_ be codepaths that uses the same
>> definition of "what's in the index" as what diff-cache used to take
>> before you
On Sun, Mar 22, 2015 at 10:33 AM, Eric Sunshine wrote:
> On Fri, Mar 20, 2015 at 6:36 AM, wrote:
>> I am trying to setup my git ignore (resp. .git/info/exclude) so that I
>> exclude
>> all directories and files except the content of directories that I
>> specifically include (incl. anything wi
At the first look, a user may think the default version is "23". Even
with UNIX background, there's no reference anywhere close that may
indicate this is glob or regex.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --g
On Tue, Mar 17 2015 at 06:16:38 PM, Junio C Hamano wrote:
>
> I also notice that handle_revision_arg() would die() by calling it
> directly or indirectly via verify_non_filename(), etc., but the
> caller actually is expecting it to silently return non-zero when it
> finds an argument that cannot b
[jc: I usually do this at the major release, but because we are
seeing many new folks due to GSoC, and also the newsletter is
getting closer to reality, so here is a special edition.]
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
proje
The latest maintenance release Git v2.3.4 is now available at the
usual places. It is comprised of 22 non-merge commits since v2.3.3,
contributed by 9 people, 1 of which is a new face. All these fixes
have already been in the 'master' branch for some time.
The tarballs are found at:
https:/
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
This cycle is turning out to be a "shoot for product excellence"
release. About half of the commits that have been merged to the
'master' so fa
Am 17.03.2015 um 08:56 schrieb Patrick Steinhardt:
On Mon, Mar 16, 2015 at 01:03:53PM -0700, Jonathan Nieder wrote:
(+cc: Jens and Heiko, submodule experts)
Hi,
Patrick Steinhardt wrote:
This proposal is just for discussion. If there is any interest I
will implement the feature and send some
On Mon, Mar 23, 2015 at 5:46 PM, David A. Wheeler wrote:
> Junio C Hamano:
>>An approach that checks only the top-level directory for fixed
>>filename pattern would not be an effective way to protect the
>>cloners, either.
>
> I disagree, I think it's remarkably effective. *Many* proje
Junio C Hamano writes:
> Ah, wait.
>
> I suspect that it all cancels out.
> ...
> OK, so I think I can see how the result could work without
> invalidating the cache-tree entry that contains i-t-a entries.
>
> It might be even the right thing to do in general. We can view that
> invalidation a w
Am 20.03.2015 um 01:13 schrieb Trevor Saunders:
On Thu, Mar 19, 2015 at 02:15:19PM -0700, Junio C Hamano wrote:
Trevor Saunders writes:
I have a feeling that an optional feature that allows "git submodule
update" to happen automatically from this codepath might be
acceptable by the submodule fo
Eric Wong writes:
> Correct, it's a good time to pull and I don't expect to have more time
> to work on new features (lazy load) for a bit. I was under the
> impression you already pulled:
>
> http://mid.gmane.org/xmqq61aol44q@gitster.dls.corp.google.com
Indeed I did. I was fooled by my ow
Junio C Hamano wrote:
> Eric Wong writes:
> > "Kyle J. McKay" wrote:
> >> The updated patch with the additional fix is below.
> >
> > Thanks, signed-off and pushed to master on git://bogomips.org/git-svn
> > I've dropped my "destroy all tempfiles..." patch.
>
> I think I missed this exchange.
Eric Wong writes:
> "Kyle J. McKay" wrote:
>> The updated patch with the additional fix is below.
>
> Thanks, signed-off and pushed to master on git://bogomips.org/git-svn
> I've dropped my "destroy all tempfiles..." patch.
I think I missed this exchange. I see these two patches:
e0b4cad
I see you queued several patches and pushed out the following on the
'master' branch in your git://ozlabs.org/~paulus/gitk.git repository:
c846920 gitk: Update .po files
f7fa39b gitk: l10n: Add Catalan translation
66e3f01 gitk: Fix typo in Russian translation
8a1692f gitk: Remove t
Hi all,
I have attempted a microproject [1][2] and this is my first draft of
the proposal.I have included only the matter regarding my approach
to solving the problem and shall add my personal details later.
Please be kind enough to go through my proposal and suggest modifications
or detailing wh
Stefan Beller writes:
> `ce` is allocated in make_cache_entry and should be freed if it is not
> used any more. refresh_cache_entry as a wrapper around refresh_cache_ent
> will either return `ce` or a new updated cache entry which is allocated
> to new memory. In that case we need to free `ce` ou
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
>
> I have reread your remarks from the weekend, and I agree
> this looks more intuitive. Thanks for pointing out the subtle details
> to make programming an art!
Heh, Our mails crossed, I guess. I've done this myself like this
--
Signed-off-by: Stefan Beller
---
I have reread your remarks from the weekend, and I agree
this looks more intuitive. Thanks for pointing out the subtle details
to make programming an art!
read-cache.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/read-cach
`ce` is allocated in make_cache_entry and should be freed if it is not
used any more. refresh_cache_entry as a wrapper around refresh_cache_ent
will either return `ce` or a new updated cache entry which is allocated
to new memory. In that case we need to free `ce` ourselfs.
Helped-by: Junio C Hama
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
>
>> By the way, aren't the following also leaking here?
>>
>> - the strbuf newlines that starts out as "size"
>> - line[] arrays of preimage and postimage
>>
>
> yes :(
>
> I think a viable replacement may be below.
Yeah, that looks
Signed-off-by: Stefan Beller
---
> By the way, aren't the following also leaking here?
>
> - the strbuf newlines that starts out as "size"
> - line[] arrays of preimage and postimage
>
yes :(
I think a viable replacement may be below.
That way the returned value of the function is not -1, but
Stefan Beller writes:
> ... though I do not understand
> why. This passes the test suite, so I wonder if this patch would be a subtle
> bug
> now.
I recall the last time I traced the code I noticed that the ce can
get passed to a codepath that causes its removal from update_one(),
and then the
Signed-off-by: Stefan Beller
---
On Fri, Mar 20, 2015 at 8:40 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> `old` is not used outside the loop and would get lost
>> once we reach the goto.
>>
>> Signed-off-by: Stefan Beller
>> ---
>> builtin/update-index.c | 1 +
>> 1 file changed, 1
Junio C Hamano:
>An open source hosting site can help better by checking at the
> project creation time, because the people who interact with that
>interface are solely in the position to set and publish licensing terms.
That doesn't help with the many projects that have *already* been c
On Fri, Mar 20, 2015 at 8:26 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> `ce` is allocated in make_cache_entry and should be freed if it is not
>> used any more. refresh_cache_entry as a wrapper around refresh_cache_ent
>> will either return `ce` or a new updated cache entry which is a
Hi guys,
git goes into an infinite loop due to broken symlink (minimal reproducer
[0]). Affected code is in function
"resolve_ref_unsafe" in file refs.c - notice 'stat_ref'. There is comment
about problem with race condition, hovewer in that case it's regular broken
symlink which cause infinite
Junio C Hamano venit, vidit, dixit 20.03.2015 23:38:
> Stefan Beller writes:
>
>> Thomas referencing reading the man page offline, made me wonder
>> why you wouldn't read the man pages itself as they can also be
>> carried around offline. But the striking point is "on an iPad", which
>> doesn't o
I inserted a size variable of int type and calculated size in each
cases of print_commit(). The function is
static void print_commit(git_commit *commit)
{
char buf[GIT_OID_HEXSZ + 1];
int i, count;
const git_signature *sig;
const char *scan, *eol;
int size=0;
git_oid_tostr
For those curious, the source of the broken behavior is npm's
completion script. It is modifying COMP_WORDBREAKS. There are two open
issues against npm for this bug.
https://github.com/npm/npm/issues/4530
https://github.com/npm/npm/issues/5820
Jason
--
To unsubscribe from this list: send the line
Signed-off-by: Marc Branchaud
---
I often open multiple gitk windows in the same working directory to examine
other branches or refs in the repo. This change allows me to distinguish
which window is showing what.
M.
gitk | 7 ++-
1 file changed, 6 insertions(+), 1 deletion
Signed-off-by: Marc Branchaud
---
I did a bit of googling but couldn't find some standard that says the
application name goes at the end of the title bar. But this is how all the
browsers and other apps I use regularly do things.
M.
gitk | 2 +-
1 file changed, 1 insertion(+),
On Sun, Mar 22, 2015 at 7:06 AM, SZEDER Gábor wrote:
>
> Hi,
>
> Quoting Jason Karns :
>
>> There appears to be a bug in the bash completion for git-branch when
>> attempting to complete the remote ref argument for --set-upstream-to=
>>
>> When:
>>
>> $ git branch --set-upstream-to=origin/mast
>>
Hello,
I have completed the micro project[1] and have also been working on
adding a "--literally" option
for cat-file[2]. I have left out the personal information part of the
proposal here, will fill that in while submitting my final proposal.
Currently, I have been reading about how "branch -
If I push straight to the other repo, it only pushes the 3 objects I'd
expect (instead of 10,000+). So it looks like that is the problem, but
I don't really understand why.
>From my point of view, there should be no difference, but I clearly
don't understand how it actually works. How does git dec
On Mon, Mar 23, 2015 at 5:35 PM, Graham Hay wrote:
> Hmm. I'm using a "private" fork of a repo, I pull from one and push to
> the other, e.g.
>
> git fetch foo
> git rebase foo/master
> git push --set-upstream origin bar
>
> It's quite possible my workflow is causing the problem, but I'm not
> sur
On Tue, Mar 10, 2015 at 1:53 PM, Michael J Gruber
wrote:
>
> So it didn't take too long to convince me after all :)
>
> Here comes Junio's version, preceded by a cleanup of the color
> setting and resetting for decorations.
>
> Junio C Hamano (1):
> log: decorate HEAD with branch name
>
> Michae
Hmm. I'm using a "private" fork of a repo, I pull from one and push to
the other, e.g.
git fetch foo
git rebase foo/master
git push --set-upstream origin bar
It's quite possible my workflow is causing the problem, but I'm not
sure what I could do differently. What do you mean by a "no-share
remot
On Sat, Mar 21, 2015 at 8:23 PM, Paul Tan wrote:
> I see git already has gcov support. For shell scripts, maybe kcov[1]
> could be used. With some slight code changes, I managed to generate a
> report for the git-pull tests[2] which should at least provide a good
> starting point for how the tests
Shanti Swarup Tunga writes:
> hey
> I am Shanti Swarup Tunga . I want to know is there any proposal
> format for Git .If not what should we focus in the proposal .
You probably already found http://git.github.io/SoC-2015-Ideas.html
There's no particular requirement on the format other th
On Thu, Mar 19, 2015 at 6:11 PM, Graham Hay wrote:
>> Try "fast-export --anonymize" as that would help us understand this.
>
> Attached.
The bad news is it seems to be working for me (I recreated the remote
repo from this dump). I notice that you have two remotes, one shares
many refs (the remote
hey
I am Shanti Swarup Tunga . I want to know is there any proposal
format for Git .If not what should we focus in the proposal .
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel
Jeff King venit, vidit, dixit 20.03.2015 21:13:
> On Fri, Mar 20, 2015 at 04:02:39PM -0400, Jeff King wrote:
>
>> Yeah, that was my impression, too. I don't have svn installed on my
>> system, so I missed those ones. I don't have CVS either. That might be
>> worth following up on.
>
> Hmm, that t
Hi Paul,
On 2015-03-22 18:39, Paul Tan wrote:
> The code coverage tools can help here as well. The kcov output clearly
> shows which options of git-pull are currently not being tested. But
> yes, I agree that the test suite shouldn't be relied too much on
> compared to code inspection and review.
On Fri, Mar 20, Junio C Hamano wrote:
> Olaf Hering writes:
>
> > What does it take to send the cover letter to all people which are
> > listed in the Cc: list of the following patches? Each patch has a
> > different Cc: list. The "git send-email --help" command suggests that
> > this cmdline sh
51 matches
Mail list logo