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
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 GI
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[] = {
GIT_PREFIX_ENVIRONMENT
};
static char
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)
sta
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 think this is probably a ste
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 (didn't
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 loc
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:
- `ref_tar
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, 16 insertions(+)
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).
Signed-off
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 actuall
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 little
> bit (didn't
I think this might be a bug, albeit a minor one:
If you have a folder containing only files not tracked by git, and you try to
use “git mv” to relocate it, then (at least on my machine, running git version
2.6.3), I get this error message:
"fatal: source directory is empty, source=SRCDIR, desti
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 start
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 @@ msgid ""
msgstr ""
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 fa
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 a/builtin/commit.c b/builtin/commit.c
ind
> 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". He'
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 to happen as well). I
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 that file is actually useful,
> 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 just
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 "use_atom"
>> structure for further usage in 'populate_va
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 "use_atom"
>> structure for further usage in 'populate_val
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 working
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' p
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 +++-
1 file change
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 remove
duplicates.
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.
Signed-off-by: Sam Hocevar
Sig
28 matches
Mail list logo