[PATCH] gitk: Update Bulgarian translation (311t)

Signed-off-by: Alexander Shopov --- po/bg.po | 656 --- 1 file changed, 336 insertions(+), 320 deletions(-) diff --git a/po/bg.po b/po/bg.po index 909a564..99aa77a 100644 --- a/po/bg.po +++ b/po/bg.po @@ -8,8 +8,8

Re: Odd rebase behavior

On Fri, Dec 18, 2015 at 06:05:49PM +, John Keeping wrote: > On Fri, Dec 18, 2015 at 11:43:16AM -0600, David A. Greene wrote: > > John Keeping writes: > > > > > It seems that the problem is introduces by --preserve-merges (and > > > -Xsubtree causes something interesting

Re: [RFC] Malicously tampering git metadata?

> I assume you are assuming here that the "push to upstream" doesn't > involve some kind of human verification? If someone tried pushing > something like this to Linus, he would be checking the git diff stats > and git commit structure for things that might look like "developer > negligence".

Re: git leaves behind .git/COMMIT_EDITMSG non-shared in --shared non-bare repo

Hi Gábor, On Sat, 19 Dec 2015, SZEDER Gábor wrote: > > On Fri, 18 Dec 2015, Yaroslav Halchenko wrote: > > > > > Not sure for what batch operations that file is actually useful, > > > > None. This file is written when you commit interactively. It is deleted > > afterwards, unless aborted in a

[PATCH] commit: ensure correct permissions of the commit message

It was pointed out by Yaroslav Halchenko that the file containing the commit message had the wrong permissions in a shared setting. Let's fix that. Signed-off-by: Johannes Schindelin --- builtin/commit.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 3/4] create_symref: modernize variable names

Once upon a time, create_symref() was used only to point HEAD at a branch name, and the variable names reflect that (e.g., calling the path git_HEAD). However, it is much more generic these days (and has been for some time). Let's update the variable names to make it easier to follow: -

[PATCH v2 3/3] git.c: make sure we do not leak GIT_* to alias scripts

The unfortunate commit d95138e (setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR - 2015-06-26) exposes another problem, besides git-clone that's described in the previous commit. If GIT_WORK_TREE (or even GIT_DIR) is exported to an alias script, it may mislead git commands in the

[PATCH v2 2/3] setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when ..

Commit d95138e [1] fixes a .git file problem by setting GIT_WORK_TREE whenever GIT_DIR is set. It sounded harmless because we handle GIT_DIR and GIT_WORK_TREE side by side for most commands, with two exceptions: git-init and git-clone. "git clone" is not happy with d95138e. This command ignores

[PATCH v2 1/3] git.c: make it clear save_env() is for alias handling only

Signed-off-by: Nguyễn Thái Ngọc Duy --- git.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/git.c b/git.c index 6ed824c..6ce7043 100644 --- a/git.c +++ b/git.c @@ -25,14 +25,14 @@ static const char *env_names[] = {

[PATCH v2 0/3] nd/clear-gitenv-upon-use-of-alias

Changes since v1: - make sure we save/restore env for external commands in 2/3 - fix t0001 test in 3/3 Interdiff: diff --git b/git.c a/git.c index 83b6c56..da278c3 100644 --- b/git.c +++ a/git.c @@ -229,7 +229,6 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)

[PATCH 4/4] create_symref: use existing ref-lock code

The create_symref() function predates the existence of "struct lock_file", let alone the more recent "struct ref_lock". Instead, it just does its own manual dot-locking. Besides being more code, this has a few downsides: - if git is interrupted while holding the lock, we don't clean up the

Re: Forcing git to pack objects

On Sat, Dec 19, 2015 at 2:03 AM, Edmundo Carmona Antoranz wrote: > Hi! > > Recently I was running manually a git gc --prune command (wanted to > shrink my 2.8G .git directory by getting rid of loose objects) and I > ended up running out of space on my HD. After freaking out a

Re: Forcing git to pack objects

On Fri, Dec 18, 2015 at 07:03:39PM -0600, Edmundo Carmona Antoranz wrote: > Recently I was running manually a git gc --prune command (wanted to > shrink my 2.8G .git directory by getting rid of loose objects) and I > ended up running out of space on my HD. After freaking out a little > bit

Re: [RFC] Malicously tampering git metadata?

On Sat, Dec 19, 2015 at 12:30:18PM -0500, Santiago Torres wrote: > > Now, the crazy behavior where github users randomly and promiscuously > > do pushes and pull without doing any kind of verification may very > > well be dangerous. > > Yes, we were mostly familiar with this workflow before

[PATCH 1/4] symbolic-ref: propagate error code from create_symref()

If create_symref() fails, git-symbolic-ref will still exit with code 0, and our caller has no idea that the command did nothing. This appears to have been broken since the beginning of time (e.g., it is not a regression where create_symref() stopped calling die() or something similar).

[PATCH 0/4] improve symbolic-ref robustness

I noticed that an interrupt "git symbolic-ref" will not clean up "HEAD.lock". So I started this series as an attempt to convert create_symref() to "struct lock_file" to get the usual tempfile cleanup. But I found a few other points of interest. The biggest is that git-symbolic-ref does not

[PATCH 2/4] t1401: test reflog creation for git-symbolic-ref

The current code writes a reflog entry whenever we update a symbolic ref, but we never test that this is so. Let's add a test to make sure upcoming refactoring doesn't cause a regression. Signed-off-by: Jeff King --- t/t1401-symbolic-ref.sh | 16 1 file changed,

Re: [PATCH] commit: ensure correct permissions of the commit message

On Sat, Dec 19, 2015 at 07:21:59PM +0100, Johannes Schindelin wrote: > It was pointed out by Yaroslav Halchenko that the file containing the > commit message had the wrong permissions in a shared setting. > > Let's fix that. > > Signed-off-by: Johannes Schindelin I

[PATCHv2 2/3] git-p4: support multiple depot paths in p4 submit

From: Sam Hocevar When submitting from a repository that was cloned using a client spec, use the full list of paths when ruling out files that are outside the view. This fixes a bug where only files pertaining to the first path would be included in the p4 submit.

Re: [PATCH v2 07/11] ref-filter: introduce align_atom_parser()

On Thu, Dec 17, 2015 at 3:24 AM, Eric Sunshine wrote: > On Wed, Dec 16, 2015 at 10:29 AM, Karthik Nayak wrote: >> Introduce align_atom_parser() which will parse an "align" atom and >> store the required alignment position and width in the

Re: [PATCH v2 07/11] ref-filter: introduce align_atom_parser()

On Fri, Dec 18, 2015 at 11:20 AM, Eric Sunshine wrote: > On Wed, Dec 16, 2015 at 10:29 AM, Karthik Nayak wrote: >> Introduce align_atom_parser() which will parse an "align" atom and >> store the required alignment position and width in the

Re: git leaves behind .git/COMMIT_EDITMSG non-shared in --shared non-bare repo

> On Fri, 18 Dec 2015, Yaroslav Halchenko wrote: > > > Not sure for what batch operations that file is actually useful, > > None. This file is written when you commit interactively. It is deleted > afterwards, unless aborted in a fatal manner. Is it? I have a COMMIT_EDITMSG lying around in

[PATCHv2 0/3] git-p4: fixing p4ChangesForPaths

James Farwell found a bug in p4ChangesForPaths() when handling changes across multiple depot paths. Sam Hocevar had already submitted a change to the same function to get P4 to do queries across all of the depot paths, in order to reduce server queries, which had the side effect of fixing James'

[PATCHv2 1/3] git-p4: failing test case for skipping changes with multiple depots

James Farwell reported that with multiple depots git-p4 would skip changes. http://article.gmane.org/gmane.comp.version-control.git/282297 Add a failing test case demonstrating the problem. Signed-off-by: Luke Diamand --- t/t9818-git-p4-block.sh | 28

[PATCHv2 3/3] git-p4: reduce number of server queries for fetches

From: Sam Hocevar When fetching changes from a depot using a full client spec, there is no need to perform as many queries as there are top-level paths in the client spec. Instead we query all changes in chronological order, also getting rid of the need to sort the results and

Re: git leaves behind .git/COMMIT_EDITMSG non-shared in --shared non-bare repo

Hi Yaroslav, On Fri, 18 Dec 2015, Yaroslav Halchenko wrote: > Not sure for what batch operations that file is actually useful, None. This file is written when you commit interactively. It is deleted afterwards, unless aborted in a fatal manner. So I would try to find out who the heck is

Re: git leaves behind .git/COMMIT_EDITMSG non-shared in --shared non-bare repo

fwiw that file is created not only by interactive tasks by with a regular commit -m msg as well. On December 19, 2015 5:40:43 AM EST, Johannes Schindelin wrote: >Hi Yaroslav, > >On Fri, 18 Dec 2015, Yaroslav Halchenko wrote: > >> Not sure for what batch operations