Jeff Epler jep...@unpythonic.net writes:
If it's dependent on eval `dircolors`, it suggests it might be
dependent on the size of the environment. Maybe try with FOO=`perl -e
'print xx1000'` for various values of 1000...
It's not this, but I could reduce the problem to a slightly simpler
On Mon, Mar 11, 2013 at 09:10:04PM -0400, Jeff King wrote:
On Mon, Mar 11, 2013 at 09:03:42PM -0400, Andrew Wong wrote:
On 03/11/13 21:01, Jeff King wrote:
From git help config:
core.trustctime
If false, the ctime differences between the index and the working
tree are
On Tue, Mar 12, 2013 at 01:01:08AM +0530, Ramkumar Ramachandra wrote:
But it was pointed out that you could also just do:
$ git config include.ref upstream-config
$ git show origin/config ;# make sure it looks reasonable
$ git show origin/config .git/upstream-config
and so
Heiko Voigt wrote:
While talking about platform independence. How about Windows? AFAIK
there are no file based sockets. How about using shared memory, thats
available, instead? It would greatly reduce the needed porting effort.
What about the git credential helper: it uses UNIX sockets, no?
On Tue, Mar 12, 2013 at 10:43 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Heiko Voigt wrote:
While talking about platform independence. How about Windows? AFAIK
there are no file based sockets. How about using shared memory, thats
available, instead? It would greatly reduce the needed
On Tue, Mar 12, 2013 at 03:13:39PM +0530, Ramkumar Ramachandra wrote:
Heiko Voigt wrote:
While talking about platform independence. How about Windows? AFAIK
there are no file based sockets. How about using shared memory, thats
available, instead? It would greatly reduce the needed porting
Paul, I'm not quite sure where I should go from here...
should I send you a patch so you make it a V3 of your patch ? should I
send a patch superseeding yours ?
I have also found a similar problem in git-subtree pull, which needs
the same fix.
in the mean time, attached is the current
On Sat, Mar 09, 2013 at 01:52:37PM -0800, Jonathan Nieder wrote:
Here's a reroll along the lines described at
http://thread.gmane.org/gmane.comp.version-control.git/216229
As before, this series is meant to give users of basic 'git shell'
setups a chance to imitate some nice behaviors that
On Sun, Mar 10, 2013 at 05:57:53PM +0100, Heiko Voigt wrote:
Because a config callback may start parsing a new file, the
global context regarding the current config file is stored
as a stack. Currently we only need to manage that stack from
git_config_from_file. Let's factor it out to allow
On Sun, Mar 10, 2013 at 05:58:57PM +0100, Heiko Voigt wrote:
The only location where cf is set in this file is in do_config_from().
This function has only one callsite which is config_from_file(). In
config_from_file() its ensured that the f member is set to non-zero.
[...]
- if (cf ((f
On Sun, Mar 10, 2013 at 05:59:40PM +0100, Heiko Voigt wrote:
diff --git a/config.c b/config.c
index f55c43d..fe1c0e5 100644
--- a/config.c
+++ b/config.c
@@ -10,20 +10,42 @@
#include strbuf.h
#include quote.h
-typedef struct config_file {
- struct config_file *prev;
- FILE
On Sun, Mar 10, 2013 at 04:49:09PM +0100, Matthieu Moy wrote:
Junio C Hamano gits...@pobox.com writes:
As promised in 0fa2eb530fb7 (add: warn when -u or -A is used without
pathspec, 2013-01-28), git add -u/-A that is run without pathspec
in a subdirectory will stop working sometime
Hot read_directory() codepaths are tracked. This could be helpful to
see how changes affect read_directory() performance.
Results are printed when environment variable GIT_MEASURE_EXCLUDE is set.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
dir.c | 109
This reduces git status user time by a little bit. This is the
sorted results of 10 consecutive runs of git ls-files
--exclude-standard -o on webkit.git, compiled with gcc -O2:
treat_leading_path: 0.000 0.000
read_directory: 4.102 3.674
+treat_one_path: 2.843 2.427
++is_excluded:
Result of today. I cherry-picked nd/read-directory-recursive-optim to
see how far I can get after pulling all the tricks. This is a slower
machine so time is longer. Anyway, read_directory time is reduced
about 70% in the end.
function before after
--
Like the previous patch, this cuts down the number of str*cmp calls in
read_directory (which does _a lot_). Again sorted results on webkit.git:
treat_leading_path: 0.000 0.000
read_directory: 3.674 3.558
+treat_one_path: 2.427 2.305
++is_excluded:2.221 2.098
strncmp provides length information, compared to strcmp, which could
be taken advantage by the implementation. Even better, we could check
if the lengths are equal before calling strncmp, eliminating a bit of
strncmp calls.
treat_leading_path: 0.000 0.000
read_directory: 3.558 3.578
treat_leading_path: 0.000 0.000
read_directory: 3.578 3.501
+treat_one_path: 2.323 2.257
++is_excluded:2.117 2.056
+++prep_exclude: 0.224 0.216
+++matching: 1.544 1.493
++dir_exist: 0.035 0.035
++index_name_exists: 0.290 0.292
prep_exclude is only necessary when we enter or leave a directory. Now
it's called for every entry in a directory. With this patch, the
number of prep_exclude calls in webkit.git goes from 188k down to
11k. This patch does not make exclude any faster, but it prepares for
making prep_exclude
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
attr.c | 4 +++-
dir.c | 19 ++-
dir.h | 6 +-
3 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/attr.c b/attr.c
index 1818ba5..b89da33 100644
--- a/attr.c
+++ b/attr.c
@@ -249,12 +249,14 @@ static
.gitignore files are spread over directories (*) so that when we check
for ignored files at foo, we are not bothered by foo/bar/.gitignore,
which contains ignore rules for foo/bar only.
This is not enough. foo/.gitignore can contain the pattern
foo/bar/*.c. When we stay at foo, we know that the
read_directory() (and its friendly wrapper fill_directory) collects
untracked/ignored files by traversing through the whole worktree,
feeding every entry to treat_one_path(), where each entry is checked
against .gitignore patterns.
One may see that tracked files can't be excluded and we do not
This avoids unnecessary allocations and reinsertions. On webkit.git
(i.e. about 100k inserts to the name hash table), this reduces about
100ms out of 3s user time.
treat_leading_path: 0.000 0.000
read_directory: 1.299 1.305
+treat_one_path: 0.599 0.599
++is_excluded:0.103
index_name_exists_base() differs from index_name_exists() in how the
hash is calculated. It uses the base hash as the seed and skips the
baselen part.
The intention is to reduce hashing cost during directory traversal,
where the hash of the directory is calculated once, and used as base
hash for
Instead of index_name_exists() calculating a hash for full pathname
for every entry, we calculate partial hash per directory, use it as a
seed. The number of characters that icase_hash has to chew will
reduce.
treat_leading_path: 0.000 0.000
read_directory: 1.296 1.235
+treat_one_path:
Hi All,
I have a question if there is a posibility tu update a branch which is not
actual working copy.
I have following situation:
A - B - C - I - J master
\ - D - E - F feature 1
\ G - H feature 2 (working
Jeff King p...@peff.net writes:
PS I wonder how others are finding the warning? I'm finding it slightly
annoying. Perhaps I just haven't retrained my fingers yet. But one
problem with that retraining is that I type git add -u from the
root _most_ of the time, and it just works. But
On Tue, 12 Mar 2013 14:22:00 +0100
Jan Pešta jan.pe...@certicon.cz wrote:
I have a question if there is a posibility tu update a branch which
is not actual working copy.
I have following situation:
A - B - C - I - J master
\ - D - E - F
Am 09.03.2013 20:28, schrieb Paul Campbell:
From 7dcd40ab8687a588b7b0c6ff914a7cfb601b6774 Mon Sep 17 00:00:00 2001
From: Herman van Rink r...@initfour.nl
Date: Tue, 27 Mar 2012 13:59:16 +0200
Subject: [PATCH 14/19] Document pull-all and push-all
---
contrib/subtree/git-subtree.txt | 8
On Wed, Feb 6, 2013 at 4:11 PM, Jens Lehmann jens.lehm...@web.de wrote:
With git submodule init the user is able to tell git he cares about one
or more submodules and wants to have it populated on the next call to git
submodule update. But currently there is no easy way he could tell git he
On Tue, Mar 12, 2013 at 06:52:00AM -0400, Jeff King wrote:
On Sun, Mar 10, 2013 at 05:57:53PM +0100, Heiko Voigt wrote:
Because a config callback may start parsing a new file, the
global context regarding the current config file is stored
as a stack. Currently we only need to manage that
On Tue, Mar 12, 2013 at 07:00:03AM -0400, Jeff King wrote:
On Sun, Mar 10, 2013 at 05:58:57PM +0100, Heiko Voigt wrote:
The only location where cf is set in this file is in do_config_from().
This function has only one callsite which is config_from_file(). In
config_from_file() its ensured
On Sat, Mar 9, 2013 at 1:18 PM, Jens Lehmann jens.lehm...@web.de wrote:
Am 05.03.2013 22:17, schrieb Phil Hord:
On Tue, Mar 5, 2013 at 3:51 PM, Jens Lehmann jens.lehm...@web.de wrote:
Am 05.03.2013 19:34, schrieb Junio C Hamano:
Eric Cousineau eacousin...@gmail.com writes:
...
I am not
Jan Pešta jan.pe...@certicon.cz writes:
I have following situation:
A - B - C - I - J master
\ - D - E - F feature 1
\ G - H feature 2 (working copy)
I would like tu update whole tree with latest
On Tue, Mar 12, 2013 at 05:00:56PM +0100, Heiko Voigt wrote:
On Tue, Mar 12, 2013 at 07:00:03AM -0400, Jeff King wrote:
On Sun, Mar 10, 2013 at 05:58:57PM +0100, Heiko Voigt wrote:
The only location where cf is set in this file is in do_config_from().
This function has only one
Phil Hord phil.h...@gmail.com writes:
I think this would be clearer if 'git deinit' said
rm 'submodule/*'
or maybe
Removed workdir for 'submodule'
Is it just me?
The latter may probably be better.
After cloning the superproject, you show interest in individual
submodules by
On Tue, Mar 12, 2013 at 07:03:55AM -0400, Jeff King wrote:
On Sun, Mar 10, 2013 at 05:59:40PM +0100, Heiko Voigt wrote:
diff --git a/config.c b/config.c
index f55c43d..fe1c0e5 100644
--- a/config.c
+++ b/config.c
@@ -10,20 +10,42 @@
#include strbuf.h
#include quote.h
On Tue, Mar 12, 2013 at 07:18:06AM -0400, Jeff King wrote:
On Sun, Mar 10, 2013 at 06:00:52PM +0100, Heiko Voigt wrote:
This can be used to read configuration values directly from gits
database.
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
This is lacking motivation. IIRC, the rest
[ Added Junio and git to the recipients, and leaving a lot of stuff
quoted due to that... ]
On Mon, Mar 11, 2013 at 9:16 PM, Theodore Ts'o ty...@mit.edu wrote:
On Tue, Mar 12, 2013 at 03:10:53PM +1100, James Morris wrote:
On Tue, 12 Mar 2013, Stephen Rothwell wrote:
The top commit in the
--- a/dir.c
+++ b/dir.c
@@ -636,12 +636,14 @@ int match_basename(const char *basename, int
basenamelen,
int flags)
{
if (prefix == patternlen) {
- if (!strcmp_icase(pattern, basename))
+ if (patternlen == basenamelen
+
On Tue, Mar 12, 2013 at 6:13 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
Why not just force the head of the security tree to be v3.9-rc2? Then
you don't end up creating a completely unnecessary merge commit, and
users who were at the previous head of the security tree will
On Tue, Nov 27, 2012 at 7:41 AM, Matt McClure matthewlmccl...@gmail.com wrote:
On Tuesday, November 27, 2012, David Aguilar wrote:
It seems that there is an edge case here that we are not
accounting for: unmodified worktree paths, when checked out
into the temporary directory, can be edited
On Tue, Mar 12, 2013 at 04:44:35PM +0100, Heiko Voigt wrote:
Can we throw in a comment at the top here with the expected usage? In
particular, do_config_from is expecting the caller to have filled in
certain fields (at this point, top-f and top-name), but there is
nothing to make that
On Tue, Mar 12, 2013 at 05:00:56PM +0100, Heiko Voigt wrote:
That is, every path to get_next_char happens while we are in
git_config_from_file, and that function guarantees that cf = top, and
that top.f != NULL. We do not have to even do any analysis of the
conditions for each call,
On Tue, Mar 12, 2013 at 12:09 PM, John Keeping j...@keeping.me.uk wrote:
On Tue, Mar 12, 2013 at 02:12:29PM -0400, Matt McClure wrote:
On Tue, Nov 27, 2012 at 7:41 AM, Matt McClure matthewlmccl...@gmail.com
wrote:
Your thoughts on the change?
Please include the patch in your message so that
difftool -d formerly knew how to symlink to the work tree when the work
tree contains uncommitted changes. In practice, prior to this change, it
would not symlink to the work tree in case there were no uncommitted
changes, even when the user invoked difftool with the form:
git difftool
On Tue, Mar 12, 2013 at 05:27:35PM +0100, Heiko Voigt wrote:
Would a union be more appropriate here? We do not ever have to pass it
directly as a parameter, since we pass the struct config_source to the
method functions.
It's still possible to screw up using a union, but it's slightly
On Tue, Mar 12, 2013 at 05:42:54PM +0100, Heiko Voigt wrote:
Your series does not actually add any callers of the new function. The
obvious patch 5/4 would be to plumb it into git config --blob, and
then we can just directly test it there (there could be other callers
besides reading from
Linus Torvalds torva...@linux-foundation.org writes:
One is simple:
git config alias.sync=pull --ff-only
Heh, I just wrote that myself after reading the early part of this
message ;-)
which works fine, but forces submaintainers to be careful when doing
things like this, and using a
Junio C Hamano gits...@pobox.com writes:
Then under the --no-ff activates the magic rule:
git merge v3.9-rc2
will fast-forward, but this
git merge --no-ff v3.9-rc2
creates a real merge with the mergetag signature block. The one
that caused trouble in the security tree, i.e.
David Aguilar dav...@gmail.com writes:
Interesting approach. While this does get the intended behavior
for difftool, I'm afraid this would be a grave regression for
existing git diff --raw users who cannot have such behavior.
The 0{40} in RHS of --raw output is to say that we do not know
John Keeping j...@keeping.me.uk writes:
How about something like --symlink-all where the everything in the
right-hand tree is symlink'd?
Does it even have to be conditional? What is the situation when you
do not want symbolic links?
--
To unsubscribe from this list: send the line unsubscribe
Duy Nguyen pclo...@gmail.com writes:
glibc's C strncmp version does 4-byte comparison at a time when n =4,
then fall back to 1-byte for the rest. I don't know if it's faster
than a plain always 1-byte comparison though. There's also the hand
written assembly version that compares n from
On Tue, Mar 12, 2013 at 01:39:17PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
How about something like --symlink-all where the everything in the
right-hand tree is symlink'd?
Does it even have to be conditional? What is the situation when you
do not want
What if we added the ability to do something like this:
[remote origin]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/heads/master
mergeoptions = --ff-only
This would be an analog to branch.name.mergeoptions,
John Keeping j...@keeping.me.uk writes:
Does it even have to be conditional? What is the situation when you
do not want symbolic links?
When you're not comparing the working tree.
OK, so what you want is essentially:
* If you see 0{40} in diff --raw, you *know* you are showing the working
On Tue, Mar 12, 2013 at 2:20 PM, Theodore Ts'o ty...@mit.edu wrote:
What if we added the ability to do something like this:
[remote origin]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/heads/master
Theodore Ts'o ty...@mit.edu writes:
What if we added the ability to do something like this:
[remote origin]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/heads/master
mergeoptions = --ff-only
This would be an
On Tue, Mar 12, 2013 at 5:06 PM, John Keeping j...@keeping.me.uk wrote:
On Tue, Mar 12, 2013 at 01:39:17PM -0700, Junio C Hamano wrote:
What is the situation when you do not want symbolic links?
When you're not comparing the working tree.
If we can reliably say the RHS is the working tree
Linus Torvalds torva...@linux-foundation.org writes:
- I do think that we might want a --no-signatures for the specific
case of merging signed tags without actually taking the signature
(because it's a upstream repo). The --ff-only thing is *too*
strict. Sometimes you really do want to merge
On Tue, Mar 12, 2013 at 2:47 PM, Junio C Hamano gits...@pobox.com wrote:
I agree that --ff-only thing is too strict and sometimes you would
want to allow back-merges, but when you do allow such a back-merge,
is there a reason you want it to be --no-signatures merge? When a
subtree maintainer
Linus Torvalds torva...@linux-foundation.org writes:
That said, adding the signature from an upstream tag doesn't really
seem to be hugely useful. I'm not seeing much of an upside, in other
words. I'd *expect* that people would pick up upstream tags
regardless, no?
Yes, their git fetch will
On Tue, Mar 12, 2013 at 5:43 PM, Matt McClure matthewlmccl...@gmail.com wrote:
On Tue, Mar 12, 2013 at 5:06 PM, John Keeping j...@keeping.me.uk wrote:
is it sufficient to say
there is no more than one non-option to the left of '--' and '--cached'
is not among the options?
An alternative
Matt McClure matthewlmccl...@gmail.com writes:
An alternative approach would be to reuse git-diff's option parsing
and make it tell git-difftool when git-diff sees the working tree
case. At this point, I haven't seen an obvious place in the source
where git-diff makes that choice, but if
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@student.ethz.ch writes:
To save the user a lookup of the last line number, introduce $ as a
shorthand for the last line. This is mostly useful to spell until
the end of the file as '-Lbegin,$'.
Doesn't -L begin or -L begin, do
On Mar 12, 2013, at 4:16 PM, Junio C Hamano gits...@pobox.com wrote:
Matt McClure matthewlmccl...@gmail.com writes:
An alternative approach would be to reuse git-diff's option parsing
I do not think you want to go there. That wouldn't solve the third
case in my previous message, no?
I
On Mar 12, 2013, at 1:25 PM, John Keeping j...@keeping.me.uk wrote:
When I tried this I got the expected behaviour even without this patch.
git diff --raw commit
emits the null SHA1 if the working tree file's stat differs from the
blob corresponding to commit. Is that the case you
On Tue, Mar 12, 2013 at 9:04 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
The algorithm implemented here is a naive one. Patterns can be either
active or passive:
- When we enter a new directory (e.g. from root to foo), currently
active patterns may no longer be applicable and can be
Am 10.03.2013 21:17, schrieb Ramkumar Ramachandra:
git operations are slow on repositories with lots of files, and lots
of tiny filesystem calls like lstat(), getdents(), open() are
reposible for this. On the linux-2.6 repository, for instance, the
numbers for git status look like this:
git tag --force is used to replace an existing tag with
a new reference. Git helpfully tells the user the old
ref when this happens. But if the tag name is new and does
not exist, git tells the user the old ref anyway (00).
Teach git to ignore --force if the tag is new. Add a test
for this
On Tue, Mar 12, 2013 at 05:12:28PM -0600, Matt McClure wrote:
On Mar 12, 2013, at 1:25 PM, John Keeping j...@keeping.me.uk wrote:
When I tried this I got the expected behaviour even without this patch.
git diff --raw commit
emits the null SHA1 if the working tree file's stat differs
On Tue, Mar 12, 2013 at 10:02 AM, Jeremy Rosen jeremy.ro...@openwide.fr wrote:
Paul, I'm not quite sure where I should go from here...
should I send you a patch so you make it a V3 of your patch ? should I
send a patch superseeding yours ?
I have also found a similar problem in git-subtree
On Tue, Mar 12, 2013 at 3:12 PM, Holger Hellmuth (IKS)
hellm...@ira.uka.de wrote:
Am 09.03.2013 20:28, schrieb Paul Campbell:
From 7dcd40ab8687a588b7b0c6ff914a7cfb601b6774 Mon Sep 17 00:00:00 2001
From: Herman van Rink r...@initfour.nl
Date: Tue, 27 Mar 2012 13:59:16 +0200
Subject: [PATCH
On Tue, Mar 12, 2013 at 04:48:16PM -0600, Matt McClure wrote:
On Mar 12, 2013, at 4:16 PM, Junio C Hamano gits...@pobox.com wrote:
Matt McClure matthewlmccl...@gmail.com writes:
* If you are comparing two trees, and especially if your RHS is not
HEAD, you will send everything to a
On Tue, Mar 12, 2013 at 3:24 PM, John Keeping j...@keeping.me.uk wrote:
When I tried this I got the expected behaviour even without this patch.
It turns out that an uncommitted, but *staged* change emits the SHA1 of
the blob rather than the null SHA1. Do you get the desired behaviour if
you
On Wed, Mar 13, 2013 at 6:21 AM, Karsten Blees karsten.bl...@gmail.com wrote:
Hmmm...I don't see how filesystem changes since last invocation can solve the
problem, or am I missing something? I think what you mean to say is that the
daemon should keep track of the filesystem *state* of the
On Wed, Mar 13, 2013 at 12:40 AM, Antoine Pelisse apeli...@gmail.com wrote:
--- a/dir.c
+++ b/dir.c
@@ -636,12 +636,14 @@ int match_basename(const char *basename, int
basenamelen,
int flags)
{
if (prefix == patternlen) {
- if
On Wed, Mar 13, 2013 at 3:59 AM, Junio C Hamano gits...@pobox.com wrote:
strncmp is provided length information which could be taken advantage
by the underlying implementation.
After all, strcmp() could also be optimized to fetch word-at-a-time
while being careful about not overstepping the
Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:
p4merge $LOCAL $LOCAL $REMOTE $MERGED
Commit 0a0ec7bd changed this to:
p4merge empty file $LOCAL $REMOTE $MERGED
to avoid the problem of being unable to save in some circumstances with
similar inputs.
Unfortunately this
Commit 718135e improved the merge error reporting for the resolve
strategy's merge conflict and permission conflict cases, but led to a
malformed ERROR: in myfile.c message in the case of a file added
differently.
This commit reverts that change, and uses an alternative approach without
this
On Tue, Mar 12, 2013 at 8:04 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
+static inline int memequal_icase(const char *a, const char *b, int n)
+{
+ if (!memcmp(a, b, n))
+ return 1;
+
+ if (!ignore_case)
+ return 0;
+
+ /*
+*
Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
the incoming branch is now in the left-hand, blue triangle pane, and the
current branch is in the right-hand, green circle pane.
This change makes use of P4Merge consistent with its built-in help, its
reference documentation,
Der müde Nike Free Run 4.0 http://www.nikefreeoutletkaufen.org/ Nacht
ohne Lanna, wie Bohnen Randeng.
Smoke verschwommenes Monaten Yu Xuefei micro.
Ich stand Xianting Central, Rauch Januar weiß gefärbt frost sehen, hören den
Schnee von der Schulter, die Brise in eine Blume Blüte im Ohr, wie ein
On Tue, Mar 12, 2013 at 6:12 PM, Kevin Bracey ke...@bracey.fi wrote:
Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
the incoming branch is now in the left-hand, blue triangle pane, and the
current branch is in the right-hand, green circle pane.
This change makes use of
On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote:
Theodore Ts'o ty...@mit.edu writes:
[remote origin]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/heads/master
mergeoptions = --ff-only
Is
Theodore Ts'o ty...@mit.edu writes:
On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote:
Theodore Ts'o ty...@mit.edu writes:
[remote origin]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/heads/master
Phil Hord ho...@cisco.com writes:
git tag --force is used to replace an existing tag with
a new reference. Git helpfully tells the user the old
ref when this happens. But if the tag name is new and does
not exist, git tells the user the old ref anyway (00).
Teach git to ignore --force
On Tue, Mar 12, 2013 at 02:58:44PM +0100, Matthieu Moy wrote:
I guess we already rejected the idea of being able to shut off the
warning and just get the new behavior, in favor of having people
specify it manually each time?
Somehow, but we may find a way to do so, as long as it
This behavior is due to change in the future, but let's test
it anyway. That helps make sure we do not accidentally
switch the behavior too soon while we are working in the
area, and it means that we can easily verify the change when
we do make it.
Signed-off-by: Jeff King p...@peff.net
---
We
The `git add -u` command operates on the current subdir of
the repository, but is transitioning to operate on the whole
repository (see commit 0fa2eb5 for details). During the
transition period, we issue a warning. For users who have
read and accepted the warning, there is no way to jump
directly
On Tue, Mar 12, 2013 at 11:33 PM, Junio C Hamano gits...@pobox.com wrote:
Phil Hord ho...@cisco.com writes:
git tag --force is used to replace an existing tag with
a new reference. Git helpfully tells the user the old
ref when this happens. But if the tag name is new and does
not exist,
91 matches
Mail list logo
