Matthieu Moy:
One option is to have the symlink in the other direction: make
/etc/foo a symlink to $GIT_WORKTREE/foo and version the later.
I do that for the software that supports it, but ssh, for instance, is
very picky that ~/.ssh is a directory and such. And at least one of
the other
Hi, Junio
Please merge the following updates on l10n, and after your merge
another round of l10n will start in order to translate one extra message
introduced by commit b861e23 (repack: propagate pack-objects
options as strings).
The following changes since commit
I'm still in the process of finishing the rewrite of the builtin/blame.c
internals. Now there are various questions regarding the final patch
proposals and commit messages.
Point 1) signing off implies that I'm fine with the licensing of the
file. builtin/blame.c merely states
/*
* Blame
*
On 01/31/2014 04:56 AM, Peter Krefting wrote:
Matthieu Moy:
One option is to have the symlink in the other direction: make
/etc/foo a symlink to $GIT_WORKTREE/foo and version the later.
I do that for the software that supports it, but ssh, for instance, is
very picky that ~/.ssh is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ick,
today I run again into a problem with the git tree of the BOINC project:
http://boinc.berkeley.edu/git/boinc-v2.git
A git pull won't work any longer due to:
$ git pull
Updating 089459d..01f0ead
error: Your local changes to the following
Duy Nguyen pclo...@gmail.com writes:
On Thu, Jan 30, 2014 at 2:25 AM, Junio C Hamano gits...@pobox.com wrote:
On Tue, Jan 28, 2014 at 02:51:45PM -0800, Junio C Hamano wrote:
This however shows that the existing test *KNEW* that it was enough
to check just a few cases (especially, there is no
Hi,
David Kastrup wrote:
builtin/blame.c merely states
/*
* Blame
*
* Copyright (c) 2006, Junio C Hamano
*/
I think you planned to make substantial changes, so
/*
* Blame
*
* Copyright (c) 2006--2014, Junio C Hamano and others
* Licensed under GPLv2. See Git's
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
chrisc...@tuxfamily.org wrote:
This patch parses the trailer command line arguments
and put the result into an arg_tok doubly linked
list.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
diff --git a/trailer.c b/trailer.c
index
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
chrisc...@tuxfamily.org wrote:
This patch reads trailers from an input file, parses
them and puts the result into a doubly linked list.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
trailer.c | 62
Jonathan Nieder jrnie...@gmail.com writes:
Also keep in mind that you don't need a copyright notice to own
copyright, that it would be crazy for someone to claim you've assigned
copyright on your changes without an explicit reassignment,
Not at all crazy: Documentation/SubmittingPatches
Jonathan Nieder jrnie...@gmail.com writes:
Otherwise there is a race: if 'git log' finishes writing before the
pager terminates and closes the pipe, all is well, and if the pager
finishes quickly enough then 'git log' terminates with SIGPIPE.
died of signal 13 at
Peter Krefting pe...@softwolves.pp.se writes:
...if I have the time, maybe I can come up with a patch. There is
already some hacks in the core.symlinks setting, so I guess it
should be possible.
That is totally unrelated. The variable only says on this platform
and/or filesystem, you cannot
Benoit Sigoure tsuna...@gmail.com writes:
When we detect that vsnprintf / snprintf are broken, we #define them to
an alternative implementation. On OS X, stdio.h already #define's them,
which causes a warning to be issued at the point we re-define them in
`git-compat-util.h'.
---
Makes
When we detect that vsnprintf / snprintf are broken, we #define them to
an alternative implementation. On OS X, stdio.h already #define's them,
which causes a warning to be issued at the point we re-define them in
`git-compat-util.h'.
Signed-off-by: Benoit Sigoure tsuna...@gmail.com
---
Hi ,
I’ve just setup a variable expansion scheme via the attribues filters for our
versioning purposes.
I do realise there is much debate on whether to do this or not but it is an
indispensable part for our code.
However i just realised the filters are not executed if we update the code via
Peter Krefting pe...@softwolves.pp.se writes:
Oh, well, if I have the time, maybe I can come up with a patch. There
is already some hacks in the core.symlinks setting, so I guess it
should be possible.
I'd love to have a way to follow symlinks, but this needs to be done
with care: when
Torsten Bögershausen tbo...@web.de writes:
But, look at
https://www.kernel.org/pub/software/scm/git/docs/git-add.html
This page seems to need an update too, and I wonder why:
a) The makefile did'nt re-generate html even if it should have
b) That page is not owned or updated by the git.git
Hi,
David Kastrup wrote:
Also whether or not this implies an assignment of copyright, it is a
reasonable assumption for
[...]
Since I think we've completely gone off the rails:
I assume the problem you're trying to solve is that files don't have
clear enough notices of their licensing. That
In order to extract the part of an absolute path which lies inside the
repo, it is not possible to directly use real_path, since that would
dereference symlinks both outside and inside the work tree.
Add an 'abspath_part_inside_repo' function which incrementally checks
each path level by
When symlinks in the working tree are manipulated using the absolute
path, git dereferences them, and tries to manipulate the link target
instead.
This is a regression introduced by 18e051a:
setup: translate symlinks in filename when using absolute paths
(which did not take symlinks in the work
The 'prefix_path_gently' function currently applies real_path to
everything if given an absolute path, dereferencing symlinks both
outside and inside the work tree. In order to manipulate symlinks in the
work tree using absolute paths, symlinks should only be dereferenced
outside the work tree.
The current behaviour of prefix_path is to return an empty string if
prefixing and absolute path that only contains exactly the work tree.
This behaviour is a potential regression point.
Signed-off-by: Martin Erik Werner martinerikwer...@gmail.com
---
t/t0060-path-utils.sh | 6 ++
1 file
On Mon, Jan 27, 2014 at 08:31:37AM -0800, Junio C Hamano wrote:
Martin Erik Werner martinerikwer...@gmail.com writes:
In order to manipulate symliks in the
work tree using absolute paths, symlinks should only be dereferenced
outside the work tree.
I agree 100% with this reasoning
At work, we recently upgraded our git version from 1.8.3.4 to 1.8.5.3.
We've noticed a significant performance regression in git fetch. The
numbers below are for an up-to-date branch (that is, no data is actually
being fetched) for a git-over-ssh remote on our gitorious server.
This is an
Jonathan Nieder jrnie...@gmail.com writes:
I assume the problem you're trying to solve is that files don't have
clear enough notices of their licensing.
No, just the file that I'm contributing to. It has a single copyright
attribution that arguably is already less than accurate _unless_ the
On Fri, Jan 31, 2014 at 09:02:15PM +, brian m. carlson wrote:
At work, we recently upgraded our git version from 1.8.3.4 to 1.8.5.3.
We've noticed a significant performance regression in git fetch. The
numbers below are for an up-to-date branch (that is, no data is actually
being
On 2014-01-31 21.22, Martin Erik Werner wrote:
In order to extract the part of an absolute path which lies inside the
repo, it is not possible to directly use real_path, since that would
dereference symlinks both outside and inside the work tree.
Add an 'abspath_part_inside_repo' function
A release candidate Git v1.9-rc2 is now available for testing at
the usual places.
I've heard rumours that various third-party tools do not like the
two-digit version numbers (e.g. Git 2.0) and started barfing left
and right when the users install v1.9-rc1. While it is tempting to
laugh at them
We wanted to call the upcoming release Git 1.9, with its
maintenance track being Git 1.9.1, Git 1.9.2, etc., but various
third-party tools are reported to assume that there are at least
three dewey-decimal components in our version number.
Adjust the plan so that vX.Y.0 are feature releases while
when relicensing, people use git blame, not header copyright notices to track
down the authors.
if you are bothered by the copyright notice at the top, modify it as part of
your patchset, it's very unlikely that anyone will care enough to object.
But copyright assignment has very strict
On Fri, Jan 31, 2014 at 04:35:05PM -0500, Jeff King wrote:
On Fri, Jan 31, 2014 at 09:02:15PM +, brian m. carlson wrote:
At work, we recently upgraded our git version from 1.8.3.4 to 1.8.5.3.
We've noticed a significant performance regression in git fetch. The
numbers below are for
On Mon, Jan 27, 2014 at 03:31:36PM -0800, Junio C Hamano wrote:
... but here it is used as if it is properly quoted so that later
eval $eval will take it as a single argument.
git pull --gpg-sign='foo bar'
will probably ask the command to use 'foo' as the signer key id,
with 'bar'
On Fri, Jan 31, 2014 at 11:37:29PM +0100, Torsten Bögershausen wrote:
On 2014-01-31 21.22, Martin Erik Werner wrote:
In order to extract the part of an absolute path which lies inside the
repo, it is not possible to directly use real_path, since that would
dereference symlinks both outside
From: Nicolas Vigier bo...@mars-attacks.org
Remove a check on the number of arguments for --onto and -x options.
It is not possible for $# to be = 2 at this point :
- if --onto or -x has an argument, git rev-parse --parseopt will
provide something like this :
set -- --onto 'x' --
From: Nicolas Vigier bo...@mars-attacks.org
There is no functionnal change. The reason for this change is to be able
to add a new option taking an optional argument.
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
From: Nicolas Vigier bo...@mars-attacks.org
There is no functional change. The reason for this change is to be able
to add a new option taking an optional argument.
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
git-am.sh |
From: Nicolas Vigier bo...@mars-attacks.org
If the variable $OPTIONS_STUCKLONG is not empty, then rev-parse
option parsing is done in --stuck-long mode.
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
contrib/git-resurrect.sh
From: Nicolas Vigier bo...@mars-attacks.org
The -M option does not exist in OPTIONS_SPEC, so there is no use to try
to find it.
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
git-rebase.sh | 2 +-
1 file changed, 1
This series was posted to the list some time back. This is a re-send of
Nicolas Vigier's work with an additional patch that adds --gpg-sign to
pull as well, as well as the fixes that Junio suggested in review.
Since the parsed option value for --gpg-sign=value is used not only as
an argument to
From: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
Documentation/git-cherry-pick.txt | 7 ++-
Documentation/git-revert.txt | 6 +-
builtin/revert.c | 2
git merge already allows us to sign commits, and git rebase has recently
learned how to do so as well. Teach git pull to parse the -S/--gpg-sign
option and pass this along to merge or rebase, as appropriate.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
git-pull.sh | 13
From: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
Documentation/git-rebase.txt | 4
git-rebase--am.sh| 8 +---
git-rebase--interactive.sh | 32
From: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
Documentation/git-am.txt | 6 +-
git-am.sh| 9 -
2 files changed, 13 insertions(+), 2 deletions(-)
diff
On Sat, Feb 1, 2014 at 3:22 AM, Martin Erik Werner
martinerikwer...@gmail.com wrote:
diff --git a/setup.c b/setup.c
index 5432a31..e606846 100644
--- a/setup.c
+++ b/setup.c
@@ -77,6 +77,69 @@ int path_inside_repo(const char *prefix, const char *path)
return 0;
}
+/*
+ * It is
44 matches
Mail list logo
