Add a new function that appends the strings from one string_list onto
another string_list.
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-string-list.txt | 10 --
string-list.c | 9 +
string-list.h | 8
This will soon be used to allow the user to tell what reference
namespaces should be subjected to pruning. But since the callers of
these functions still use PARSE_OPT_NOARG, the new functionality is
not yet visible.
Signed-off-by: Michael Haggerty
---
remote.c | 35
Signed-off-by: Michael Haggerty
---
builtin/remote.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index c08dfa8..09b965a 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -1372,10 +1372,12 @@ static int get_remote_defaul
Allow optional arguments to be passed to "git remote update --prune"
to choose which references are subject to pruning. The default, if no
argument is specified, is to prune all references as before.
Signed-off-by: Michael Haggerty
---
Documentation/git-remote.txt | 7 +--
builtin/remote.c
Allow "--prune=" options to be provided to "git remote prune"
to specify which reference namespaces should be pruned. "--prune"
without an argument and "--no-prune" are disallowed here as they make
no sense.
Signed-off-by: Michael Haggerty
---
Documentation/git-remote.txt | 5 +++-
builtin/rem
Add a "patterns" argument to get_stale_heads(). If it is non-NULL,
then only refnames matching one of the glob patterns in the string
list will be included in the output.
Signed-off-by: Michael Haggerty
---
builtin/fetch.c | 3 ++-
builtin/remote.c | 3 ++-
remote.c | 26
This patch series applies on top of
mh/fetch-tags-in-addition-to-normal-refs
and has some minor conflicts with that branch (mostly related to
documentation).
Let me state in advance that I personally think that the features
implemented in this patch series are overkill. But since it was
alr
Signed-off-by: Michael Haggerty
---
builtin/fetch.c | 36
1 file changed, 8 insertions(+), 28 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 9a04512..fcc06a4 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -30,8 +30,7 @@ enum {
Add two new configuration settings,
fetch.pruneRef
remote..pruneRef
via which prune patterns (i.e., the equivalent of --prune=)
can be configured globally or for particular remotes. The default
remains the same, namely "*".
Signed-off-by: Michael Haggerty
---
Documentation/config.txt
Allow optional arguments to be passed to "git fetch --prune" to choose
which references are subject to pruning. The default, if no argument
is specified, is to prune all references as before.
Signed-off-by: Michael Haggerty
---
Documentation/fetch-options.txt | 6 +-
builtin/fetch.c
By default, show the remote-tracking references that could be pruned.
But if the user specifies --prune=, then limit the output to
those matching pattern. And if the user specified --no-prune, then do
not look for stale remote-tracking references at all.
Signed-off-by: Michael Haggerty
---
Docu
For now, only handle --prune/--no-prune. But handle the option via a
callback so that in the future --prune=PATTERN can be implemented.
The new functions are not yet used.
Signed-off-by: Michael Haggerty
---
remote.c | 62 ++
remote.h
Диагноз не имеет значения, изумительный итог гарантирован http://goo.gl/CQX4we
On Tue, Dec 3, 2013 at 8:26 PM, Zoltan Klinger wrote:
> diff --git a/diff.c b/diff.c
> index e34bf97..c4078af 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -2899,11 +2899,18 @@ static void run_external_diff(const char *pgm,
> struct diff_filespec *one,
>
When --prompt option is set, git-difftool displays a prompt for each modified
file to be viewed in an external diff program. At that point it could be useful
to display a counter and the total number of files in the diff queue.
Below is the current difftool prompt for the first of 5 modified files
On Wed, Dec 4, 2013 at 3:13 AM, Thomas Rast wrote:
> Paweł Sikora writes:
>>
>
> Umm, there's a gem here that the thread missed so far:
>
>> my git repo isn't very big[1] but it's checked out on the linear lvm
>> where random i/o generally hurts and strace shows that current git version
>> perfor
The command line arguments given to "git push" are massaged into
a list of refspecs in set_refspecs() function. This was implemented
using xmalloc, strcpy and friends, but it is much easier to read if
done using strbuf.
Signed-off-by: Junio C Hamano
---
builtin/push.c | 35 ++
Since f2690487 (fetch: opportunistically update tracking refs,
2013-05-11), we stopped taking a non-storing refspec given on the
command line of "git fetch" literally, and instead started mapping
it via remote.$name.fetch refspecs. This allows
$ git fetch origin master
from the 'origin' repo
When the user is using the 'upstream' mode, these commands:
$ git push
$ git push origin
would find the 'upstream' branch for the current branch, and then
push the current branch to update it. However, pushing a single
branch explicitly, i.e.
$ git push origin $(git symbolic-ref --s
Earlier, Peff taught "git fetch origin master" to update a
remote-tracking branch by internally mapping the colon-less refspec
'master' to '+refs/heads/master:refs/remotes/origin/master'. Both
git fetch origin
git fetch origin master
would update the same refs/remotes/origin/mast
On Tue, Dec 3, 2013 at 5:44 PM, Martin Langhoff
wrote:
> As they have not been skipped, they are fully fleshed out. By this, I
> mean that we have the whole tree in place. So these 22 commits appear
> with foo/bar pulled out to the root of the project, in the midst of
> 1500 commits with a full tr
When using git filter-branch --prune-empty --directory-filter foo/bar
to extract the history of the foo/bar directory, I am getting a very
strange result.
Directory foo/bar is "slow moving". Say, 22 commits out of several
thousand. I would like to extract just those 22 commits.
Instead, I get ~15
A maintenance release Git v1.8.4.5 is now available at the
usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
b43c0cc46749ad62b8ac74237ceca00c8e386edb git-1.8.4.5.tar.gz
bd66db8c9528e53d2b93e88ef8e96164e597333f
When submodule.$name.update is given as hint from the upstream in
the .gitmodules file, we used to blindly copy it to .git/config,
unless there already is a value defined for the submodule.
However, there is no reason to expect that the update mode hinted by
the upstream is available in the versio
The latest maintenance release Git v1.8.5.1 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
dcd244c7198e8afe42ab223f7b3c9b1ae01749c3 git-1.8.5.1.tar.gz
16cd5fdf486aa880c4fcb297d769070c6
From: Jeff King
>
> On Sat, Nov 30, 2013 at 02:51:18PM +0100, Christian Couder wrote:
>
>> Here is a patch series to improve the way sha1_object_info_extended()
>> behaves when it is passed a replaced object.
>
> Overall looks OK to me.
Thanks for reviewing it.
[...]
> I checked the resultin
From: Junio C Hamano
>
> Jeff King writes:
>
>> On Mon, Dec 02, 2013 at 09:52:25AM -0500, Jeff King wrote:
>>
>>> I find it a little funny that we reuse the READ_SHA1_FILE_REPLACE flag
>>> directly in lookup_replace_object. That means that it is now a
>>> meaningful flag for sha1_object_info_ext
Hi,
On Tue, Dec 03, 2013 at 10:39:36AM -0800, Junio C Hamano wrote:
> OK, thanks, then let's do this.
Yes, sounds good.
Cheers Heiko
> -- >8 --
> From: Nick Townsend
> Date: Mon, 25 Nov 2013 15:31:09 -0800
> Subject: [PATCH] ref-iteration doc: add_submodule_odb() returns 0 for success
>
> The
On Tue, Dec 3, 2013 at 9:15 PM, Junio C Hamano wrote:
> Krzesimir Nowak writes:
>
>> @@ -626,6 +640,17 @@ sub feature_avatar {
>> return @val ? @val : @_;
>> }
>>
>> +sub feature_extra_branch_refs {
>> + my (@branch_refs) = @_;
>> + my $values = git_get_project_config('extra_branch
On Tue, Dec 3, 2013 at 1:46 PM, Jeff King wrote:
>
> This made it through to me, but not the list. There are at least two
> things going on:
>
> 1. The message is 172K, which is over the 100K limit imposed by vger;
> the list is silently dropping it.
>
> 2. In my case, the direct mail was
On Mon, Dec 02, 2013 at 03:37:10PM -0800, Jonathan Nieder wrote:
> When the built-in "git tar-tree" command (a thin wrapper around "git
> archive") was removed in 925ceccf (tar-tree: remove deprecated
> command, 2013-11-10), the build continued to install a non-functioning
> git-tar-tree command in
Krzesimir Nowak writes:
> @@ -626,6 +640,17 @@ sub feature_avatar {
> return @val ? @val : @_;
> }
>
> +sub feature_extra_branch_refs {
> + my (@branch_refs) = @_;
> + my $values = git_get_project_config('extra_branch_refs');
Hmph. Three points.
* Almost all callers of this fu
Paweł Sikora writes:
>
Umm, there's a gem here that the thread missed so far:
> my git repo isn't very big[1] but it's checked out on the linear lvm
> where random i/o generally hurts and strace shows that current git version
> performs 2x{lstat}+1x{open,read,close} [2] on whole checkout before
Nguyễn Thái Ngọc Duy wrote:
> Mark strings like "[up to date]" passed to print_ref_status() for
> translation with N_() instead of _() so they can remain untranslated
> in porcelain mode.
Makes sense.
[...]
> --- a/builtin/push.c
> +++ b/builtin/push.c
Perhaps it would make sense to send these
Junio C Hamano writes:
> * Paul, I forgot to forward this to you. Could you apply it to
>your tree? I see you have updates up to ce2c58cd (gitk:
>Recognize -L option, 2013-11-16), which I'll be pulling into my
>tree shortly.
When you pull, can you pick up the "other half" of the s
Amit Bakshi writes:
> I was getting core dumps (bus error 7) with git 1.7.1 when doing a
> git checkout. I tried git fsck, and same thing. I got the same with
> precompiled rpms of 1.7.12, and with a locally compiled version of git
> 1.8.5.
[...]
> $ git fsck
> Checking pack-0ccb5ee4f60003a7ea47
Jakub Narębski writes:
> Stricly speaking pure refactoring (no functional change, e.g. no assign
> to $input) would be "check_ref_format($input) or return undef;", or even
> "return check_ref_format($input);" if we keep check_ref_format() passthru
> on valid refname.
Exactly.
--
To unsubscribe
On Tue, Dec 3, 2013 at 8:02 PM, Junio C Hamano wrote:
> Krzesimir Nowak writes:
>> +sub check_ref_format {
>> + my $input = shift || return undef;
>> +
>> + # restrictions on ref name according to git-check-ref-format
>> + if ($input =~ m!(/\.|\.\.|[\000-\040\177 ~^:?*\[]|/$)!) {
>>
On Monday 25 of November 2013 09:26:40 Junio C Hamano wrote:
> Paweł Sikora writes:
> > On Sunday 24 of November 2013 19:47:10 Duy Nguyen wrote:
> >> On Sun, Nov 24, 2013 at 5:45 PM, Paweł Sikora
wrote:
> >> > i've recently reinstalled a fresh system (fc20-beta) on my workstation
> >> > and obse
> Martin Fick writes:
> > * Setup 1:
> > Do a full repack. All loose and packed objects are
> > added
...
> > * Scenario 1:
> > Start with Setup 1. Nothing has changed on the repo
> > contents (no new object/packs, refs all the same), but
> > repacking config options have changed (for exam
I will start to rebase all feature branches because I have no real
dependency on those, but master needs to have a linear history, as I
build from it regularly, and I need to assure that people can get a
previous version of master.
The problem with that is that I wouldn't be able to have a linear
Hi,
Ralf Thielow wrote:
> I've fetched from the current git.git on GitHub minutes ago and got a
> segfault. I could reproduce it with the Git version of the current "next"
> branch
> (1.8.5.392.gf545f4d) with the steps below. The segfault does not appear with
> version 1.8.5.
Yep, I can reprodu
Javier Domingo writes:
> Hi,
>
> I have been using a very basic workflow for branching, features each
> in a branch.
>
> My branches would be:
> - develop <= Main upstream branch
> - feature/* fix/* <= Feature and fix branches
> - master <= Integration of the whole feature and fi
Hi John!,
Thanks a lot for your tip, but I have the problem that I would need to
have a linear history in master (forgot to mention it explicitly) ;(
I build on master branch, and getting to a previous version is hereby needed.
I had thought about the revert workflow, but using --no-commit. I
wo
Junio C Hamano wrote:
> Karsten Blees writes:
>> If we don't want to support this, though, I think it would be more
>> approrpiate to issue a warning if GIT_DIR points to a worktree
>> location.
>
> But how do tell what is and isn't a "worktree location"? Having the
> path in the index would be
Krzesimir Nowak writes:
> This check will be used in more than one place later.
>
> Signed-off-by: Krzesimir Nowak
> Reviewed-by: Junio C Hamano
> Reviewed-by: Jakub Narębski
> Reviewed-by: Eric Sunshine
> ---
> gitweb/gitweb.perl | 17 +
> 1 file changed, 13 insertions(+), 4
Am 03.12.2013 19:32, schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> So I figure that GIT_DIR is not meant to _rename_ the ".git" dir,
>> but to point somewhere _outside_ the worktree (or somewhere within
>> the .git dir).
>
> Correct.
>
>> If we don't want to support this, though, I think
Hi,
I've fetched from the current git.git on GitHub minutes ago and got a
segfault. I could reproduce it with the Git version of the current "next" branch
(1.8.5.392.gf545f4d) with the steps below. The segfault does not appear with
version 1.8.5.
Steps to reproduce:
git init tmp
cd tmp
git remote
Krzesimir Nowak writes:
> Allow extra-branch-refs feature to tell gitweb to show refs from
> additional hierarchies in addition to branches in the list-of-branches
> view.
>
> Signed-off-by: Krzesimir Nowak
> Reviewed-by: Junio C Hamano
Please do not add "Reviewed-by:" like this; I've never re
On Tue, Dec 03, 2013 at 07:06:20PM +0100, Javier Domingo wrote:
> I have been using a very basic workflow for branching, features each
> in a branch.
>
> My branches would be:
> - develop <= Main upstream branch
> - feature/* fix/* <= Feature and fix branches
> - master <= Integration of the whol
Heiko Voigt writes:
> On Mon, Dec 02, 2013 at 04:14:37PM -0800, Nick Townsend wrote:
>> diff --git a/submodule.c b/submodule.c
>> index 1905d75..1ea46be 100644
>> --- a/submodule.c
>> +++ b/submodule.c
>> @@ -143,7 +143,7 @@ void stage_updated_gitmodules(void)
>> die(_("staging updat
Hi,
On Mon, Dec 02, 2013 at 03:55:36PM -0800, Nick Townsend wrote:
>
> On 29 Nov 2013, at 14:38, Heiko Voigt wrote:
> > FYI, I already started to implement this lookup of submodule paths early
> > this year[1] but have not found the time to proceed on that yet. I am
> > planning to continue on t
Karsten Blees writes:
>So I figure that GIT_DIR is not meant to _rename_ the ".git" dir,
>but to point somewhere _outside_ the worktree (or somewhere within
>the .git dir).
Correct.
> If we don't want to support this, though, I think it would be more
> approrpiate to issue a warning if GIT_DIR
On Mon, Dec 02, 2013 at 04:14:37PM -0800, Nick Townsend wrote:
> diff --git a/submodule.c b/submodule.c
> index 1905d75..1ea46be 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -143,7 +143,7 @@ void stage_updated_gitmodules(void)
> die(_("staging updated .gitmodules failed"));
>
On Tue, Dec 03, 2013 at 03:40:41PM +0100, Karsten Blees wrote:
> IMO, trying to improve khash isn't worth the trouble.
>
> With smaller-than-pointer types, khash _may_ actually save a few bytes
> compared to hash.[ch] or hashmap.[ch]. E.g. a set of 'int's would be a
> perfect use case for khash.
Jeff King writes:
> There are a few options I see:
>
> 1. Drop $GZIP variable, and hard-code the prerequisite check to
> "gzip", which is what is being tested.
>
> 2. Keep $GZIP (but rename it to $GIT_GZIP), and explicitly set up
> tar.tgz.command as "$GIT_GZIP -cn".
>
> 3. Teach
Hi,
I have been using a very basic workflow for branching, features each
in a branch.
My branches would be:
- develop <= Main upstream branch
- feature/* fix/* <= Feature and fix branches
- master <= Integration of the whole feature and fix branches
So I have now came up with a very difficult t
Eric Sunshine writes:
>> +test_expect_success 'archive subtree from subdir' '
>> + cd a &&
>> + git archive --format=tar HEAD >../asubtree.tar &&
>> + cd .. &&
>> + make_dir extract &&
>> + "$TAR" xf asubtree.tar -C extract &&
>> + check_dir extract af b b/bf b
Nick Townsend writes:
> From: Nick Townsend
> Date: Mon, 25 Nov 2013 15:31:09 -0800
> Subject: [PATCH 1/2] submodule: add_submodule_odb() usability
Please do not add these; instead, drop From/Date (because we can see
them in the mail header from your MUA) and replace the mail header
Subject wit
Duy Nguyen writes:
> Reading Martin's mail again I wonder how we just
> "grab all objects and skip history traversal". Who will decide object
> order in the new pack if we don't traverse history and collect path
> information.
I vaguely recall raising a related topic for "quick repack, assuming
That is a new detail (SMB 1 vs. 2) that can be used to debug this further.
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
> Behalf Of Phil Wiffen
> Sent: Tuesday, December 03, 2013 11:48 AM
> To: git@vger.kernel.org
> Subject: Re: trouble on wi
Did anyone ever get to the bottom of this? I'm seeing this exact issue on
both NetApp storage systems with SMB 2.x enabled and also on Windows 7 and
Server 2008 R2 shares (which also use SMB 2.x). If we use SMB 1.x (such as
XP), things work fine.
--
To unsubscribe from this list: send the line "
Am 01.12.2013 20:04, schrieb Dennis Kaarsemaker:
> We always ignore anything named .git, but we should also ignore the git
> directory if the user overrides it by setting $GIT_DIR
>
> Reported-By: Ingy döt Net
> Signed-off-by: Dennis Kaarsemaker
> ---
> dir.c | 2 +-
> t/t7508-statu
First patch just splits some code to a function, second patch adds the
extra-branch-refs feature and third one adds some visual
differentation of branches from non-standard ref directories.
Krzesimir Nowak (3):
gitweb: Move check-ref-format code into separate function
gitweb: Add a feature for
On Tue, 2013-12-03 at 14:02 +0100, Jakub Narębski wrote:
> On Tue, Dec 3, 2013 at 11:53 AM, Krzesimir Nowak
> wrote:
> > On Mon, 2013-12-02 at 18:34 +0100, Jakub Narębski wrote:
> >> W dniu 2013-12-02 13:06, Krzesimir Nowak pisze:
> >>> On Mon, 2013-12-02 at 01:21 +0100, Jakub Narębski wrote:
> >
Allow extra-branch-refs feature to tell gitweb to show refs from
additional hierarchies in addition to branches in the list-of-branches
view.
Signed-off-by: Krzesimir Nowak
Reviewed-by: Junio C Hamano
Reviewed-by: Jakub Narębski
Reviewed-by: Eric Sunshine
---
Documentation/gitweb.conf.txt | 2
Given two branches residing in refs/heads/master and refs/wip/feature
the list-of-branches view will present them in following way:
master
feature (wip)
When getting a snapshot of a 'feature' branch, the tarball is going to
have name like 'project-wip-feature-.tgz'.
Signed-off-by: Krzesimir Nowak
This check will be used in more than one place later.
Signed-off-by: Krzesimir Nowak
Reviewed-by: Junio C Hamano
Reviewed-by: Jakub Narębski
Reviewed-by: Eric Sunshine
---
gitweb/gitweb.perl | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.p
Am 28.11.2013 11:38, schrieb Jeff King:
> On Wed, Nov 27, 2013 at 10:08:56AM +0100, Karsten Blees wrote:
>
>> Khash is OK for sha1 keys, but I don't think it should be advertised
>> as a second general purpose hash table implementation. Its far too
>> easy to shoot yourself in the foot by using 's
In t5000, we test the built-in ".tar.gz" config for
git-archive. To make our tests portable, we check that we
have a way to both gzip and gunzip, and we respected
environment variables to point to alternate commands for
doing these operations.
However, the $GZIP variable did not actually do anythi
On Tue, Dec 03, 2013 at 04:49:06AM -0500, Eric Sunshine wrote:
> > -if $GZIP --version >/dev/null 2>&1; then
> > - test_set_prereq GZIP
> > +if $GZIPCMD --version >/dev/null 2>&1; then
> > + test_set_prereq GZIPCMD
>
> test_set_prereq is not actually operating on an environment variab
On Tue, Dec 3, 2013 at 11:53 AM, Krzesimir Nowak wrote:
> On Mon, 2013-12-02 at 18:34 +0100, Jakub Narębski wrote:
>> W dniu 2013-12-02 13:06, Krzesimir Nowak pisze:
>>> On Mon, 2013-12-02 at 01:21 +0100, Jakub Narębski wrote:
On Thu, Nov 28, 2013 at 12:44 PM, Krzesimir Nowak
wrote:
>>
On Tue, Dec 03, 2013 at 08:03:39AM +0100, Christian Couder wrote:
> I am trying to forward this patch from my gmail address, as it doesn't
> seem to go through when I send it from my home machine.
This made it through to me, but not the list. There are at least two
things going on:
1. The mess
My wife and I won the Euro Millions Lottery & will be donating 1.5 Million
Pounds to you in our ongoing lucky draws donations. Please get back to us with
your Name, Age, Tel, Country and i will send you more details how your funds
will be sent to you.
Please read the article -
http://news.sky.
On Mon, 2013-12-02 at 18:34 +0100, Jakub Narębski wrote:
> W dniu 2013-12-02 13:06, Krzesimir Nowak pisze:
> > On Mon, 2013-12-02 at 01:21 +0100, Jakub Narębski wrote:
> >> On Thu, Nov 28, 2013 at 12:44 PM, Krzesimir Nowak
> >> wrote:
> >>
> >>> Allow @additional_branch_refs configuration variabl
Signed-off-by: John Szakmeister
---
The gnome-keyring credential backend had a number of coding style
violations. I believe this fixes all of them.
.../gnome-keyring/git-credential-gnome-keyring.c | 55 ++
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/con
Mark strings like "[up to date]" passed to print_ref_status() for
translation with N_() instead of _() so they can remain untranslated
in porcelain mode.
While at there, mark some error strings in git push for translation
too.
Signed-off-by: Nguyễn Thái Ngọc Duy
Reviewed-by: Jonathan Nieder
---
On Tue, Dec 3, 2013 at 2:17 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>>> If nothing else has happened in the repository, perhaps, but I
>>> suspect that the real problem is how you would prove it. For
>>> example, I am guessing that your Scenario 4 could be something like:
>>>
>>> :
Hey,
I use the following commands to receive the list of tags together with hashes
the point to:
git log --tags --no-walk --format=%H%d%x01 --decorate=full
Generally it works fine, however a user reported that for his repository this
command returns the list containing several hashes wit
On Tue, Dec 3, 2013 at 3:32 PM, Matthieu Moy wrote:
> Git used to trim the trailing slash, and make the command equivalent to
> 'git mv file no-such-dir', which created the file no-such-dir (while the
> trailing slash explicitly stated that it could only be a directory).
>
> This patch skips the t
[cc'ing Peff, the author of these tests]
On Tue, Dec 3, 2013 at 3:57 AM, Christian Hesse wrote:
> In t/t5000-tar-tree.sh the variable GZIP is used for the command name.
> From man gzip:
>
>> The environment variable GZIP can hold a set of default options for
>> gzip. These options are interpreted
On Mon, Dec 2, 2013 at 7:16 PM, Nick Townsend wrote:
> From: Nick Townsend
> Date: Sat, 30 Nov 2013 16:54:20 -0800
> Subject: [PATCH 2/2] Additional git-archive tests
>
> Interplay between paths specified in three ways now tested:
> * After a : in the tree-ish,
> * As a pathspec in the command,
>
In t/t5000-tar-tree.sh the variable GZIP is used for the command name.
>From man gzip:
> The environment variable GZIP can hold a set of default options for
> gzip. These options are interpreted first and can be overwritten by
> explicit command line parameters.
So using any other variable name f
On Tue, Dec 3, 2013 at 9:45 AM, Markus Trippelsdorf
wrote:
> Should be fixed in gcc soon. For the curious, here is the assembler diff
> (bad vs. good):
Cool, Thanks. Good to know this has nothing to do with Git :-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
On 2013.12.02 at 16:05 +0100, Markus Trippelsdorf wrote:
> On 2013.12.02 at 15:15 +0100, Antoine Pelisse wrote:
> > Would that mean that gcc is doing some steps in the wrong order ? That
> > is setting xecfg.hunk_func and then emptying the structure ? I've
> > already had a similar bug, but that's
Git used to trim the trailing slash, and make the command equivalent to
'git mv file no-such-dir', which created the file no-such-dir (while the
trailing slash explicitly stated that it could only be a directory).
This patch skips the trailing slash removal for the destination path. The
path with
86 matches
Mail list logo
