On Sat, Feb 1, 2014 at 3:22 AM, Martin Erik Werner
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 ok if dst == src,
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
---
git-pull.sh | 13 -
1 file changed, 12
From: Nicolas Vigier
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
Documentation/git-rebase.txt | 4
git-rebase--am.sh| 8 +---
git-rebase--interactive.sh | 32
git-rebase--merge.sh | 2 +-
git-rebase.sh
From: Nicolas Vigier
The -M option does not exist in OPTIONS_SPEC, so there is no use to try
to find it.
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
git-rebase.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index d183
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= is used not only as
an argument to other
From: Nicolas Vigier
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
Documentation/git-cherry-pick.txt | 7 ++-
Documentation/git-revert.txt | 6 +-
builtin/revert.c | 2 ++
sequencer.c | 11 +++
sequencer.h
From: Nicolas Vigier
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
Documentation/git-am.txt | 6 +-
git-am.sh| 9 -
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 54d8461.
From: Nicolas Vigier
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' --
when parsing the "--onto"
From: Nicolas Vigier
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
Signed-off-by: brian m. carlson
---
git-rebase.sh | 50 ++
1 file change
From: Nicolas Vigier
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
Signed-off-by: brian m. carlson
---
git-am.sh | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
d
From: Nicolas Vigier
If the variable $OPTIONS_STUCKLONG is not empty, then rev-parse
option parsing is done in --stuck-long mode.
Signed-off-by: Nicolas Vigier
Signed-off-by: brian m. carlson
---
contrib/git-resurrect.sh | 1 +
git-am.sh| 1 +
git-instaweb.sh | 1 +
g
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 ou
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,
> w
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 ar
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 requi
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
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
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
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 fetc
Jonathan Nieder 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
respective authors
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 auxilia
On Mon, Jan 27, 2014 at 08:31:37AM -0800, Junio C Hamano wrote:
> Martin Erik Werner 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 (modulo s/symliks/syml
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
---
t/t0060-path-utils.sh | 6 ++
1 file changed, 6 insertions(+)
diff
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.
Mo
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 temporari
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. Tha
Torsten Bögershausen 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 maintaine
Peter Krefting 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 following symlinks, writ
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
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
---
git-compat-util.h | 6
Benoit Sigoure 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 perfect sense. P
Peter Krefting 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 symlink(2), so in
Jonathan Nieder 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 /build/buildd/git-1.9~rc1/t/test-terminal
Jonathan Nieder 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 states that adding a
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
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
> ---
> trailer.c | 62 ++
> 1 fil
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
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
> ---
> diff --git a/trailer.c b/trailer.c
> index d979a0f..f48fd94 100644
> --- a/trailer
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 G
Duy Nguyen writes:
> On Thu, Jan 30, 2014 at 2:25 AM, Junio C Hamano 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 reason to make
>> sure that
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
wrote:
> This patch adds the "git interpret-trailers" command.
> This command uses the previously added process_trailers()
> function in trailer.c.
>
> Signed-off-by: Christian Couder
> ---
> diff --git a/builtin/interpret-trailers.c b/builtin/int
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
wrote:
> This patch implements reading the configuration
> to get trailer information, and then processing
> it and storing it in a doubly linked list.
>
> The config information is stored in the list
> whose first item is pointed to by:
>
> static
-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 files
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
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
*
*
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 79fcbf7e703ca5805ebd46b2c7e09d07
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 fil
46 matches
Mail list logo
