Am 5/7/2014 0:59, schrieb dtur...@twopensource.com:
From: David Turner dtur...@twitter.com
Make it possible to change the case of a filename on a
case-insensitive filesystem using git mv. Change git mv to allow
moves where the destination file exists if either the destination file
has the
ssoma is a git-based mail archiver and transport. Email is injected via
ssoma-mda(1) (MDA: mail delivery agent) on a server and may be shared
(via git) and extracted to mbox, Maildir, or IMAP via ssoma(1). ssoma
exists primarily as the mechanism (not policy) for public-inbox but may
easily be
Junio C Hamano:
But why does the workflow need --date=now in the first place?
I tend to do this quite a lot, after fixing up a commit using rebase,
I notice that the commit date is when I first started fixing the
issue, even if that was a week or so ago. I then like to reset the
commit
On 07/05/14 00:10, Pat Thoyts wrote:
Chris Packham judge.pack...@gmail.com writes:
On Tue, Apr 29, 2014 at 2:56 PM, Chris Packham judge.pack...@gmail.com
wrote:
Hi Pat,
I'm running git 2.0.0-rc0 (haven't got round to pulling down rc1 yet)
which includes gitgui-0.19.0 and I'm getting a
On 07/05/14 19:28, Chris Packham wrote:
On 07/05/14 00:10, Pat Thoyts wrote:
Chris Packham judge.pack...@gmail.com writes:
On Tue, Apr 29, 2014 at 2:56 PM, Chris Packham judge.pack...@gmail.com
wrote:
Hi Pat,
I'm running git 2.0.0-rc0 (haven't got round to pulling down rc1 yet)
which
Display the tag name about to be added to the user during interactive
editing.
Signed-off-by: Thorsten Glaser t...@debian.org
Signed-off-by: Richard Hartmann ric...@debian.org
---
builtin/tag.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/tag.c
On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
I'd like to register my opposition to moving git-remote-{bzr,hg} out of
contrib/.
I am not convinced that tools for interoperating with other VCSs need to
be part of core Git; as
John Keeping wrote:
I also think that there should be a way to make it really easy to
install these third-party tools to augment the installed version of
Git without having the source tree of Git. We have ways for them to
ask us where things are expected to be, e.g.
$ git
It's better if all our scripts use the same '/usr/bin/env python'.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/hooks/multimail/README | 6 +++---
contrib/hooks/multimail/git_multimail.py| 2 +-
contrib/hooks/multimail/migrate-mailhook-config |
Felipe Contreras wrote:
Yes, *if* they have been packaging them, they have a way. But what if
they haven't been doing so?
And for the ones that have a way, now they need one hack less.
As an example of all the hacks needed by a real distribution package,
here's the stuff ArchLinux packagers
On Wed, May 7, 2014 at 12:03 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
It's better if all our scripts use the same '/usr/bin/env python'.
Only if they are source compatible with both Python2 and Python3. See
PEP394 URL: http://legacy.python.org/dev/peps/pep-0394/ . Otherwise
(for
Ping Yin
On Mon, May 5, 2014 at 8:29 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Hi,
== git update ==
Another proposed solution is to have a new command: `git update`. This
command would be similar to `git pull --ff-only` by default, but it
could be configured to do merges
Johan Herland wrote:
On Wed, May 7, 2014 at 12:03 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
It's better if all our scripts use the same '/usr/bin/env python'.
Only if they are source compatible with both Python2 and Python3. See
PEP394 URL:
Junio C Hamano gits...@pobox.com writes:
You raised a good point on the issue of external dependencies may
impact Git as a whole, even for those who are not interested in the
particular remote helpers at all. I'll have to think about it.
(As I'm sure you know, but starting from the
On 05/07/2014 12:45 AM, Ronnie Sahlberg wrote:
This is a series adds two new functions to try to hide the reflog
implementation details from the callers in checkout.c and reflog.c.
It adds new functions to test if a reflog exists and to delete it, thus
allowing checkout.c to perform this
On 7 May 2014 21:11:53 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com
wrote:
Johan Herland wrote:
On Wed, May 7, 2014 at 12:03 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
It's better if all our scripts use the same '/usr/bin/env python'.
Only if they are source
On Wed, May 7, 2014 at 1:11 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Johan Herland wrote:
On Wed, May 7, 2014 at 12:03 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
It's better if all our scripts use the same '/usr/bin/env python'.
Only if they are source compatible
On 07.05.2014 15:23, Duy Nguyen wrote:
I need some big Java repos (over 100k files) to test git status.
Actually any repos with long path names and deep/wide directory
structure are fine, not only Java ones. Right now I'm aware of
gentoo-x86 and webkit. Let me know if you know some others. I'm
I need some big Java repos (over 100k files) to test git status.
Actually any repos with long path names and deep/wide directory
structure are fine, not only Java ones. Right now I'm aware of
gentoo-x86 and webkit. Let me know if you know some others. I'm afraid
my Google-foo is not strong enough
On Wed, May 7, 2014 at 3:23 PM, Duy Nguyen pclo...@gmail.com wrote:
I need some big Java repos (over 100k files) to test git status.
Actually any repos with long path names and deep/wide directory
structure are fine, not only Java ones. Right now I'm aware of
gentoo-x86 and webkit. Let me know
On 07.05.2014 15:38, Stefan Beller wrote:
On 07.05.2014 15:23, Duy Nguyen wrote:
I need some big Java repos (over 100k files) to test git status.
Actually any repos with long path names and deep/wide directory
structure are fine, not only Java ones. Right now I'm aware of
gentoo-x86 and
On 07.05.2014 16:01, Ævar Arnfjörð Bjarmason wrote:
On Wed, May 7, 2014 at 3:23 PM, Duy Nguyen pclo...@gmail.com wrote:
I need some big Java repos (over 100k files) to test git status.
Actually any repos with long path names and deep/wide directory
structure are fine, not only Java ones. Right
---
dir.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/dir.c b/dir.c
index eb6f581..7a83f70 100644
--- a/dir.c
+++ b/dir.c
@@ -553,8 +553,7 @@ int add_excludes_from_file_to_list(const char *fname,
buf = xrealloc(buf, size+1);
This is not used anywhere yet. But the goal is to compare quickly if a
.gitignore file has changed when one has SHA-1 of the old .gitignore.
---
dir.c | 51 ---
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/dir.c b/dir.c
index
There is no actual nested struct here. Move it out for clarity.
---
dir.h | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/dir.h b/dir.h
index 55e5345..02e3710 100644
--- a/dir.h
+++ b/dir.h
@@ -15,6 +15,27 @@ struct dir_entry {
First of all, thanks for pointing to many more big repos. I'll look at
them tomorrow. End-of-day report (or ranting :D) time.
The series now looks good enough for public eyes. I haven't run the
test suite with untracked cache on by default so confidence level is
not so high. Although I suspect
---
dir.c | 115 --
dir.h | 3 ++
2 files changed, 115 insertions(+), 3 deletions(-)
diff --git a/dir.c b/dir.c
index 34a10b2..a198aa8 100644
--- a/dir.c
+++ b/dir.c
@@ -568,6 +568,22 @@ static struct untracked_cache_dir
It's easy to see that if an existing .gitignore changes, its SHA-1
would be different and invalidate_gitignore() is called.
If .gitignore is removed, add_excludes() will treat it like an empty
.gitignore, which again should invalidate the cached directory data.
if .gitignore is added,
FIXME: load check_only
---
dir.c| 107 +++
dir.h| 1 +
read-cache.c | 3 ++
3 files changed, 111 insertions(+)
diff --git a/dir.c b/dir.c
index b7d394a..3c61b42 100644
--- a/dir.c
+++ b/dir.c
@@ -2256,3 +2256,110 @@ void
The main readdir loop in read_directory_recursive() is replaced with a
new one that checks if cached results of a directory is still valid.
If a file is added or removed from the index, the containing directory
is invalidated (but not its subdirs). If directory's mtime is changed,
the same
Suppose untracked cache stores that in directory A we need to recurse
in A/B and A/C. Then A/B is removed. When read_directory() is executed
again, of course we detect that we only need to recurse in A/C when in
A, not A/B any more.
We need a way though to let the write phase know not to write
This cuts down a signficant number of open(.gitignore) because most
directories usually don't have .gitignore files.
---
dir.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index 63fa960..b5bfda8 100644
--- a/dir.c
+++ b/dir.c
@@
FIXME: save check_only
---
cache.h | 3 ++
dir.c| 91
dir.h| 1 +
read-cache.c | 12
4 files changed, 107 insertions(+)
diff --git a/cache.h b/cache.h
index 107ac61..06fcb6b 100644
--- a/cache.h
+++
The idea is if we can capture all input and output of
read_directory_recursive() and verify at a later time that all the
input is the same, then read_directory_recursive() should produce the
same output, so we can bypass read_directory_recursive() and reuse the
cached output for the directory in
Ideally we should replace untracked_cache_invalidate_path() with
untracked_cache_remove_from_index() and untracked_cache_add_to_index(),
and the two last functions will update untracked cache right away
instead of invalidating it and wait for read_directory() next time to
deal with it. But that
---
builtin/commit.c | 8
wt-status.c | 6 ++
2 files changed, 14 insertions(+)
diff --git a/builtin/commit.c b/builtin/commit.c
index 9cfef6c..1e45ff0 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1327,6 +1327,14 @@ int cmd_status(int argc, const char **argv, const
This could be used to verify correct behavior in tests
---
dir.c | 12
1 file changed, 12 insertions(+)
diff --git a/dir.c b/dir.c
index 18fe44c..58303ca 100644
--- a/dir.c
+++ b/dir.c
@@ -14,6 +14,8 @@
#include pathspec.h
#include varint.h
+#define TRACE_KEY GIT_TRACE_UNTRACKED
When a directory is updated within the same second that its timestamp
is last saved, we cannot realize the directory has been updated by
checking timestamps. Assume the worst (something is update). See
29e4d36 (Racy GIT - 2005-12-20) for more information.
---
cache.h | 2 ++
dir.c| 6
---
read-cache.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 66c2279..72adcd6 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -258,20 +258,26 @@ static int ce_match_stat_basic(const struct cache_entry
*ce, struct
---
builtin/update-index.c | 144 +
1 file changed, 144 insertions(+)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 003e28e..f18076b 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -46,6 +46,145 @@ static
---
.gitignore | 1 +
Makefile | 1 +
t/t7063-status-untracked-cache.sh (new +x) | 352 +
test-dump-untracked-cache.c (new) | 61 +
4 files changed, 415 insertions(+)
create mode
Some numbers below. In short, the saving on wt_status_collect_untracked()
is about 80%. There are some overhead on read/write_cache, but it seems
lower than 50ms, while the .._untracked() saving is in the 500ms range
(except linux-2.6, about 150ms). git status time saving ranges from
33% to 42%.
On 05/05/2014 09:48 AM, Chris Packham wrote:
Hi,
I know there are a few people on this list that do git training in
various forms. At $dayjob I've been asked to run a few training
sessions in house. The initial audience is SW developers so they are
fairly clued up on VCS concepts and most have
During my initial self-education I came across the maxim don't pull,
fetch+merge instead and have been doing that. I think I followed most of the
pull is (mostly) evil discussion but one facet still puzzles me: the idea
that pull will do a merge in the wrong direction sometimes.
Do I
Jim Garrison jim.garri...@nwea.org writes:
During my initial self-education I came across the maxim don't pull,
fetch+merge instead and have been doing that. I think I followed
most of the pull is (mostly) evil discussion but one facet still
puzzles me: the idea that pull will do a merge in
On Wed, 2014-05-07 at 08:17 +0200, Johannes Sixt wrote:
} else if (cache_name_pos(src, length) 0)
bad = _(not under version control);
- else if (lstat(dst, st) == 0) {
+ else if (lstat(dst, dst_st) == 0
+
On Wed, May 07, 2014 at 03:40:28PM +, Jim Garrison wrote:
During my initial self-education I came across the maxim don't pull,
fetch+merge instead and have been doing that. I think I followed
most of the pull is (mostly) evil discussion but one facet still
puzzles me: the idea that pull
Jeff King p...@peff.net writes:
On Tue, May 06, 2014 at 08:49:22PM +0200, Matthieu Moy wrote:
...
The idea of having a separate default value for pager.blame (or set
$LESS differently for blame) crossed my mind, but I actually don't like
it, as it would make it harder for a user to fine-tune
Tolga Ceylan tolga.cey...@gmail.com writes:
When applying binary patches a full index is required. format-patch
already handles this, but diff-tree needs '--full-index' argument
to always output full index. When git-p4 runs git-apply to test
the patch, git-apply rejects the patch due to
Felipe Contreras felipe.contre...@gmail.com writes:
As an example of all the hacks needed by a real distribution package,
here's the stuff ArchLinux packagers have to do:
# bash completion
mkdir -p $pkgdir/usr/share/bash-completion/completions/
install -m644
David Turner dtur...@twopensource.com writes:
This causes my test to pass and generally seems correct to me.
Yes, this approach is very sensible, and I'll queue.
But watchman support _should_ be prepared for a program that does
not do this. Developing your support in on a codebase with this
David Turner dtur...@twopensource.com writes:
On Wed, 2014-05-07 at 08:17 +0200, Johannes Sixt wrote:
} else if (cache_name_pos(src, length) 0)
bad = _(not under version control);
- else if (lstat(dst, st) == 0) {
+ else if (lstat(dst,
Junio C Hamano gits...@pobox.com writes:
While I fully agree with the above conclusion, I just noticed that I
will be irritated enough to eventually set pager.blame myself, after
running a short git blame -L1311,+7 git-p4.py, which is one of the
standard first steps for me to start reading
dtur...@twopensource.com writes:
+if ! test_have_prereq CASE_INSENSITIVE_FS
+then
+ skip_all='skipping case insensitive tests - case sensitive file system'
+ test_done
+fi
+
+test_expect_success 'merge with case-changing rename' '
+ test $(git config core.ignorecase) = true
On Wed, 2014-05-07 at 10:46 -0700, Junio C Hamano wrote:
David Turner dtur...@twopensource.com writes:
On Wed, 2014-05-07 at 08:17 +0200, Johannes Sixt wrote:
} else if (cache_name_pos(src, length) 0)
bad = _(not under version control);
-
Felipe Contreras felipe.contre...@gmail.com writes:
It's better if all our scripts use the same '/usr/bin/env python'.
Why?
Using python2 for git_multimail.py is a deliberate decision:
https://github.com/mhagger/git-multimail/pull/2
(also, contrib/hooks/multimail/README says:
The
Felipe Contreras felipe.contre...@gmail.com writes:
Here's a bunch of tests more, and a fixes for Mercurial v3.0.
I think the discussion with John Keeping hints that we shouldn't be
rushing fc/remote-helpers-hg-bzr-graduation and this does not appear
to assume the presense of that series, which
Jeff King p...@peff.net writes:
On Sun, May 04, 2014 at 07:01:22PM +, brian m. carlson wrote:
On Sun, May 04, 2014 at 01:12:55AM -0500, Felipe Contreras wrote:
This is in gcc 4.9.0:
wt-status.c: In function ‘wt_status_print_unmerged_header’:
wt-status.c:191:2: warning:
Junio C Hamano wrote:
dtur...@twopensource.com writes:
+test -e testcase
Please make it a habit to use test -f when you expect the path
exists as a file, not merely something exists there I do not care
if it is a file or a directory, for which test -e is perfectly
appropriate.
Or,
Nathan Collins nathan.coll...@gmail.com writes:
More concretely, what I had in mind was that if 'diff.noprefix=true'
is set in the user's config, and the patch is in '-p0' format, then
Git could suggest to the user that the 'diff.noprefix' setting *might*
be causing them to generate '-p0'
Hi,
On Mon, Apr 28, 2014 at 04:29:31PM +0200, Stepan Kasal wrote:
this is another patch that lives in msysGit for a long time.
Originally, it had two parts:
(Cf https://github.com/msysgit/git/commit/64a8a03 )
1) adding alias pwd='pwd -W' to git-sh-setup.sh
This one went upstream, though
John Keeping j...@keeping.me.uk writes:
On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
...
Another thing to keep in mind is that we need to ensure that we give
a good way for these third-party tools to integrate well with the
core Git tools to form a single toolchest for the
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Plus this one which has been completely ignored:
completion: move out of contrib
It is not about ignored. It is about running out of time before
concluding
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Here's a bunch of tests more, and a fixes for Mercurial v3.0.
I think the discussion with John Keeping hints that we shouldn't be
rushing fc/remote-helpers-hg-bzr-graduation
Really? Based on what reasoning? I have
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
It's better if all our scripts use the same '/usr/bin/env python'.
Why?
Using python2 for git_multimail.py is a deliberate decision:
If you want to use python2, then use '/usr/bin/env python2'.
The git-multimail
On 2014-05-05 23.46, Jeff King wrote:
[]
2. Do all index filename comparisons under Mac OS X using a UTF-8 aware
comparison function regardless if core.precomposeunicode is set.
This would probably have bad performance, and somewhat
defeats the point of converting the
On Wed, May 07, 2014 at 11:56:18AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
...
Another thing to keep in mind is that we need to ensure that we give
a good way for these third-party tools to
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
As an example of all the hacks needed by a real distribution package,
here's the stuff ArchLinux packagers have to do:
# bash completion
mkdir -p $pkgdir/usr/share/bash-completion/completions/
install
John Keeping wrote:
Having thought about it a bit more after reading Felipe's reply, it
would be nice if there were some way for third-party tools to install
HTML documentation without relying on `git --html-path` but I cannot
see an obvious way to do that as there isn't a standard $HTML_PATH
Greg Troxel wrote:
In a packaging system, dependencies are much more troublesome.
Dependencies have to be declared, and the build limited to use only
those declared dependencies, in order to get repeatable builds and
binary packages that can be used on other systems. Dependencies that
really
On Wed, May 07, 2014 at 11:19:09AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Sun, May 04, 2014 at 07:01:22PM +, brian m. carlson wrote:
On Sun, May 04, 2014 at 01:12:55AM -0500, Felipe Contreras wrote:
This is in gcc 4.9.0:
wt-status.c: In function
Jim Garrison jim.garri...@nwea.org writes:
During my initial self-education I came across the maxim don't
pull, fetch+merge instead and have been doing that. I think I
followed most of the pull is (mostly) evil discussion but one
facet still puzzles me: the idea that pull will do a merge in
Michael Haggerty mhag...@alum.mit.edu writes:
+1 Looks good to me. Thanks!
Will queue with your Ack; thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Felipe Contreras felipe.contre...@gmail.com writes:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
It's better if all our scripts use the same '/usr/bin/env python'.
Why?
Using python2 for git_multimail.py is a deliberate decision:
If you want to use
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Here's a bunch of tests more, and a fixes for Mercurial v3.0.
I think the discussion with John Keeping hints that we shouldn't be
rushing
-Original Message-
From: Junio C Hamano
Sent: Wednesday, May 07, 2014 1:16 PM
Subject: Re: Beginner question on Pull is mostly evil
No. This is most often true for people who use a single repository as a
place for everybody to meet, in the same way as SVN.
[snip lots of excellent
Heiko Voigt hvo...@hvoigt.net writes:
On Wed, May 07, 2014 at 11:19:09AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
...
Yeah, this started last summer when we added __attribute__((format)) to
the status_printf_ln calls, and I posted essentially the same patch. We
kind
Junio C Hamano wrote:
That when I manually part is what I meant by we give a good way for
these third-party tools above, and make it really easy to install
these third-party tools in the remaining part of the message you are
responding to.
We need two things:
1) Provied a pkg-config, as
Heiko Voigt hvo...@hvoigt.net writes:
On Mon, Apr 28, 2014 at 04:29:31PM +0200, Stepan Kasal wrote:
this is another patch that lives in msysGit for a long time.
Originally, it had two parts:
(Cf https://github.com/msysgit/git/commit/64a8a03 )
1) adding alias pwd='pwd -W' to git-sh-setup.sh
Matthieu Moy matthieu@grenoble-inp.fr writes:
Perhaps it deserves a mention in the doc, e.g. squashing this on top of
my patch:
Thanks, will do.
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b7f92ac..ebd1676 100644
--- a/Documentation/config.txt
+++
On Wed, May 07, 2014 at 03:26:15PM -0500, Felipe Contreras wrote:
Junio C Hamano wrote:
Your git-integrate might turn into something I could augment my
workflow with with some additions.
- specifying a merge strategy per branch being merged;
git-reintegrate[1] supports this.
-
n Tue, May 6, 2014 at 9:08 PM, Jeff Sipek jef...@josefsipek.net wrote:
On Sun, Mar 23, 2014 at 10:03:48PM +0100, Per Cederqvist wrote:
On Sun, Mar 23, 2014 at 6:09 PM, Jeff Sipek jef...@josefsipek.net wrote:
On Fri, Mar 21, 2014 at 08:31:44AM +0100, Per Cederqvist wrote:
When extracting the
On Tue, May 6, 2014 at 8:23 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 05/06/2014 12:57 AM, Ronnie Sahlberg wrote:
This is a single patch that adds two new functions to try to hide the reflog
implementation details from the callers in checkout.c and reflog.c.
It adds new functions to
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Really? Based on what reasoning? I have proven his reasoning to be
basically wrong.
Perhaps s/proven/convinced myself only/; you didn't prove it to me
and I doubt you proved it to John.
And you are still
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
If you want to use python2, then use '/usr/bin/env python2'.
Err, yes, this is what the code does before your patch.
Not for all the instances.
If you are going to follow practices different than git.git, then
Hi,
I am getting this in Ubuntu, something wrong with my env?
Thanks
root@HDUBVM01:~/builds/git/t# ./t5539-fetch-http-shallow.sh
ok 1 - setup shallow clone
not ok 2 - clone http repository
#
#git clone --bare --no-local shallow
$HTTPD_DOCUMENT_ROOT_PATH/repo.git
#git clone
Hi,
I've looked more attentively, here are my observations and the
resulting suggestions:
- Suggest only to check *string-wise* the given path against
$GIT_DIR. Both or one of them may be relative paths (but comparison
best be performed when converted to absolute paths). That's the only
Jim Garrison jim.garri...@nwea.org writes:
-Original Message-
From: Junio C Hamano
Sent: Wednesday, May 07, 2014 1:16 PM
Subject: Re: Beginner question on Pull is mostly evil
No. This is most often true for people who use a single repository as a
place for everybody to meet, in
Jonathan Nieder jrnie...@gmail.com writes:
Please make it a habit to use test -f when you expect the path
exists as a file, not merely something exists there I do not care
if it is a file or a directory, for which test -e is perfectly
appropriate.
Or, better in tests,
On Wed, 2014-05-07 at 10:42 -0700, Junio C Hamano wrote:
David Turner dtur...@twopensource.com writes:
This causes my test to pass and generally seems correct to me.
Yes, this approach is very sensible, and I'll queue.
But watchman support _should_ be prepared for a program that does
On Tue, May 6, 2014 at 9:40 PM, Jeff Sipek jef...@josefsipek.net wrote:
On Fri, Mar 21, 2014 at 08:31:45AM +0100, Per Cederqvist wrote:
Test that we can combine any combination of patches with empty and
non-empty messages, both with and without guilt.diffstat. (All
patches are empty.)
I
Felipe Contreras felipe.contre...@gmail.com writes:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
If you want to use python2, then use '/usr/bin/env python2'.
Err, yes, this is what the code does before your patch.
Not for all the instances.
Well, I guess not
On Wed, May 07, 2014 at 10:59:56PM +0200, Per Cederqvist wrote:
On Tue, May 6, 2014 at 9:40 PM, Jeff Sipek jef...@josefsipek.net wrote:
On Fri, Mar 21, 2014 at 08:31:45AM +0100, Per Cederqvist wrote:
Test that we can combine any combination of patches with empty and
non-empty messages, both
Signed-off-by: Josef 'Jeff' Sipek jef...@josefsipek.net
On Fri, Mar 21, 2014 at 08:32:05AM +0100, Per Cederqvist wrote:
Fix remove_topic() in t-061.sh so that it doesn't print a git hash.
Signed-off-by: Per Cederqvist ced...@opera.com
---
regression/t-061.out | 1 -
regression/t-061.sh |
On Fri, Mar 21, 2014 at 08:32:02AM +0100, Per Cederqvist wrote:
Only one invocation of disp or _disp actually needed backslash
processing. In quite a few instances, it was wrong to do backslash
processing, as the message contained data derived from the user.
Created the new function disp_e
Thorsten Glaser t...@debian.org writes:
Display the tag name about to be added to the user during interactive
editing.
Signed-off-by: Thorsten Glaser t...@debian.org
Signed-off-by: Richard Hartmann ric...@debian.org
---
Sounds sensible from a first glance. Will queue; thanks.
Fabio D'Alfonso fabio.dalfo...@fabiodalfonso.com writes:
Hi,
I am getting this in Ubuntu, something wrong with my env?
Thanks
root@HDUBVM01:~/builds/git/t# ./t5539-fetch-http-shallow.sh
ok 1 - setup shallow clone
not ok 2 - clone http repository
#
#git clone --bare --no-local
John Keeping wrote:
On Wed, May 07, 2014 at 03:26:15PM -0500, Felipe Contreras wrote:
Junio C Hamano wrote:
Your git-integrate might turn into something I could augment my
workflow with with some additions.
- specifying a merge strategy per branch being merged;
On 4 May 2014 16:33:32 GMT+10:00, James Denholm nod.h...@gmail.com wrote:
cmd_add_commit() is passed FETCH_HEAD by cmd_add_repository, which is
then rev-parsed into an object ID. However, if the user is fetching a
tag rather than a branch HEAD, such as by executing:
$ git subtree add -P oldGit
On Fri, Mar 21, 2014 at 08:32:03AM +0100, Per Cederqvist wrote:
This makes it easier to script operations on the entire queue, for
example run the test suite on each patch in the queue:
guilt pop -a;while guilt push; do make test||break; done
This brings guilt push in line with the
1 - 100 of 121 matches
Mail list logo
