Junio C Hamano gitster at pobox.com writes:
* kb/status-ignored-optim-2 (2013-05-29) 1 commit
- dir.c: fix ignore processing within not-ignored directories
Fix 1.8.3 regressions in the .gitignore path exclusion logic.
Hi,
I see that the Tested-by line in kb/status-ignored-optim-2
Thomas Rast wrote:
diff --git a/commit.c b/commit.c
index 888e02a..00e8d4a 100644
--- a/commit.c
+++ b/commit.c
@@ -31,8 +31,12 @@ static struct commit *check_commit(struct object *obj,
struct commit *lookup_commit_reference_gently(const unsigned char *sha1,
Patches are now expected to be dropped iff they are on upstream. I've
also followed all of Johannes's other suggestions except for the one
about topo-order.
Martin von Zweigbergk (7):
add simple tests of consistency across rebase types
add tests for rebasing with patch-equivalence present
Helped-by: Johannes Sixt j...@kdbg.org
---
t/lib-rebase.sh | 15
t/t3420-rebase-topology-linear.sh | 78 +++
2 files changed, 93 insertions(+)
create mode 100755 t/t3420-rebase-topology-linear.sh
diff --git a/t/lib-rebase.sh
---
t/t3401-rebase-partial.sh | 24
t/t3420-rebase-topology-linear.sh | 58 +++
2 files changed, 58 insertions(+), 24 deletions(-)
diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh
index 58f4823..7ba1797 100755
---
---
t/lib-rebase.sh | 17
t/t3420-rebase-topology-linear.sh | 85 +++
2 files changed, 102 insertions(+)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 62b3887..16eeb1c 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@
t3406 is supposed to test messages from rebase operation, so let's
move tests in t3400 that fit that description into 3406. Most of the
functionality they tested, except for the messages, has now been
subsumed by t3420.
---
t/t3400-rebase.sh | 22 --
---
t/t3400-rebase.sh | 31 +
t/t3401-rebase-partial.sh | 45 ---
t/t3404-rebase-interactive.sh | 10 +-
t/t3409-rebase-preserve-merges.sh | 53
t/t3425-rebase-topology-merges.sh | 252 ++
5 files changed, 254
---
t/t3420-rebase-topology-linear.sh | 129 ++
1 file changed, 129 insertions(+)
diff --git a/t/t3420-rebase-topology-linear.sh
b/t/t3420-rebase-topology-linear.sh
index 81e3d59..659a7b3 100755
--- a/t/t3420-rebase-topology-linear.sh
+++
Update the following:
- Quote 'setup'
- Remove blank lines within test case body
- Use test_commit instead of custom quick_one
- Create branch topic from tag created by test_commit
---
t/t3406-rebase-message.sh | 30 +-
1 file changed, 9 insertions(+), 21
For example master..feature-a.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/related/git-related | 38 --
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/contrib/related/git-related b/contrib/related/git-related
index
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/related/git-related | 16
1 file changed, 16 insertions(+)
diff --git a/contrib/related/git-related b/contrib/related/git-related
index 1b9b1e7..bde5b99 100755
--- a/contrib/related/git-related
+++
Hi,
Since there hasn't been any comments of importance this is basically the same
as v7, plus a few other patches to make it actually usable (for me).
Unfortunately it turns out Ruby's optparse is not suitable for our needs, so I
implemented a very small parser that is.
Felipe Contreras (6):
Ruby's option parser is not extensible enough to keep unknown options.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/related/git-related | 83 ++---
1 file changed, 71 insertions(+), 12 deletions(-)
diff --git
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/related/git-related | 35 +++
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/contrib/related/git-related b/contrib/related/git-related
index bde5b99..0de1c6c 100755
---
Hi,
I changed my mind, this is the same as v9 but minus some potentially
controversial changes.
Felipe Contreras (4):
Add new git-related helper to contrib
contrib: related: add support for multiple patches
contrib: related: add option to parse from committish
contrib: related: parse
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/related/git-related | 15 +++
1 file changed, 15 insertions(+)
diff --git a/contrib/related/git-related b/contrib/related/git-related
index 20eb456..bded6f6 100755
--- a/contrib/related/git-related
+++
This script find people that might be interested in a patch, by going
back through the history for each single hunk modified, and finding
people that reviewed, acknowledge, signed, or authored the code the
patch is modifying.
It does this by running 'git blame' incrementally on each hunk, and
For example master..feature-a.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/related/git-related | 38 --
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/contrib/related/git-related b/contrib/related/git-related
index
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/related/git-related | 35 +++
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/contrib/related/git-related b/contrib/related/git-related
index 1b9b1e7..3379982 100755
---
On Fri, May 31, 2013 at 2:37 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Since there hasn't been any comments of importance this is basically the same
as v7, plus a few other patches to make it actually usable (for me).
Unfortunately it turns out Ruby's optparse is not suitable for
On Thu, May 30, 2013 at 6:31 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, May 30, 2013 at 4:01 AM, Ramkumar Ramachandra
Not a single one of these comments makes a difference at all, all of
them can wait until after the patch is merged, many of them are a
matter of
Felipe Contreras wrote:
I was going to make these stylistic changes to make you happy, but
then I realized the only that does really make sense is to change msg
= nil to msg = false, and it's not even worth to waste a thought on
changes like that.
We don't have existing Ruby code in git.git
Jeff King p...@peff.net writes:
On Thu, May 30, 2013 at 10:00:23PM +0200, Thomas Rast wrote:
lookup_commit_reference_gently unconditionally parses the object given
to it. This slows down git-describe a lot if you have a repository
with large tagged blobs in it: parse_object() will read the
On Fri, May 31, 2013 at 3:03 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
I was going to make these stylistic changes to make you happy, but
then I realized the only that does really make sense is to change msg
= nil to msg = false, and it's not even worth to
On 30 May 2013 20:30, John Keeping j...@keeping.me.uk wrote:
On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote:
Alex Bennée kernel-hac...@bennee.com writes:
On 30 May 2013 16:33, Thomas Rast tr...@inf.ethz.ch wrote:
Alex Bennée kernel-hac...@bennee.com writes:
snip
Will it be
Ramkumar Ramachandra artag...@gmail.com writes:
Thomas Rast wrote:
+ struct object *obj;
+ int type = sha1_object_info(sha1, NULL);
+ /* If it's neither tag nor commit, parsing the object is wasted
effort */
+ if (type != OBJ_TAG type != OBJ_COMMIT)
+
On Thu, May 30, 2013 at 10:13 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 30.05.2013 15:34, schrieb Felipe Contreras:
We don't free 'istate-cache' properly.
Apparently 'initialized' doesn't really mean initialized, but loaded, or
rather 'not-empty', and the cache can be used even
Alex Bennée kernel-hac...@bennee.com writes:
On 30 May 2013 20:30, John Keeping j...@keeping.me.uk wrote:
On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote:
Alex Bennée kernel-hac...@bennee.com writes:
On 30 May 2013 16:33, Thomas Rast tr...@inf.ethz.ch wrote:
Alex Bennée
read_cache() already does that check.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
submodule.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/submodule.c b/submodule.c
index e728025..1821a5b 100644
--- a/submodule.c
+++ b/submodule.c
@@ -603,9 +603,8
On Fri, May 31, 2013 at 09:14:49AM +0100, Alex Bennée wrote:
On 30 May 2013 20:30, John Keeping j...@keeping.me.uk wrote:
On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote:
Alex Bennée kernel-hac...@bennee.com writes:
On 30 May 2013 16:33, Thomas Rast tr...@inf.ethz.ch wrote:
On 31 May 2013 09:24, Thomas Rast tr...@inf.ethz.ch wrote:
Alex Bennée kernel-hac...@bennee.com writes:
On 30 May 2013 20:30, John Keeping j...@keeping.me.uk wrote:
On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote:
Alex Bennée kernel-hac...@bennee.com writes:
On 30 May 2013 16:33,
Alex Bennée kernel-hac...@bennee.com writes:
I think you are right. I was brave (well I assumed the tags would come
back from the upstream repo) and ran:
git for-each-ref | grep refs/tags | grep commit | cut -d '/' -f 3
| xargs git tag -d
So that deleted all unannotated tags pointing at
On 31 May 2013 09:32, John Keeping j...@keeping.me.uk wrote:
On Fri, May 31, 2013 at 09:14:49AM +0100, Alex Bennée wrote:
On 30 May 2013 20:30, John Keeping j...@keeping.me.uk wrote:
On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote:
Alex Bennée kernel-hac...@bennee.com writes:
On Fri, May 31, 2013 at 09:49:57AM +0100, Alex Bennée wrote:
On 31 May 2013 09:32, John Keeping j...@keeping.me.uk wrote:
Thomas is suggesting that you might have a tag that does not point at a
commit but instead points to a blob object.
It's looking like I just have some very heavy
On 31 May 2013 09:46, Thomas Rast tr...@inf.ethz.ch wrote:
Alex Bennée kernel-hac...@bennee.com writes:
I think you are right. I was brave (well I assumed the tags would come
back from the upstream repo) and ran:
git for-each-ref | grep refs/tags | grep commit | cut -d '/' -f 3
| xargs git
Thomas Rast tr...@inf.ethz.ch writes:
However, if that turns out to be the culprit, it's not fixable
currently[1]. Having commits with insanely long messages is just, well,
insane.
[1] unless we do a major rework of the loading infrastructure, so that
we can teach it to load only the
The documentation of -S and -G is very sketchy. Completely rewrite the
sections in Documentation/diff-options.txt and
Documentation/gitdiffcore.txt.
References:
52e9578 ([PATCH] Introducing software archaeologist's tool pickaxe.)
f506b8e (git log/diff: add -Gregexp that greps in the patch text)
Currently, diffcore-pickaxe reports two distinct errors for the same
user error:
$ git log --pickaxe-regex -S'\1'
fatal: invalid pickaxe regex: Invalid back reference
$ git log -G'\1' # --pickaxe-regex is implied
fatal: invalid log-grep regex: Invalid back reference
Since the
Junio had some suggestions in the previous round. The inter-diff
follows.
Yeah, word-diff is a bit messy. Which brings me to: is it possible to
turn on word-diff only where heuristically appropriate? word-diff
applied on the rewrite of the first paragraph of gitdiffcore.txt is a
disaster, but
Am 31.05.2013 08:49, schrieb Martin von Zweigbergk:
+# f
+# /
+# a---b---c---g---h
+# \
+# d---G---i
+#\ \
+# e---u
+#
+# uppercase = cherry-picked
+# h = reverted g
...
+test_expect_success rebase -p --onto in merged history drops patches
Hello,
We are another team from Ensimag (Célestin MATTE Benoit PERSON) who
will contribute to Git and more specifically to Git-Mediawiki for our
one-month school project - and possibly more. We already have a couple
of basic patches in local and will submit them in the upcoming days.
After that,
On Fri, May 31, 2013 at 10:08:06AM +0200, Thomas Rast wrote:
Have you measured the impact of this on normal operations? During a
traversal, we spend a measurable amount of time looking up commits in
packfiles, and this would presumably double it.
I don't think so, but admittedly I didn't
On Fri, May 31, 2013 at 12:27:11PM +0200, Thomas Rast wrote:
Thomas Rast tr...@inf.ethz.ch writes:
However, if that turns out to be the culprit, it's not fixable
currently[1]. Having commits with insanely long messages is just, well,
insane.
[1] unless we do a major rework of the
On Thu, May 30, 2013 at 09:23:40PM +0200, Jens Lehmann wrote:
Am 30.05.2013 01:58, schrieb Junio C Hamano:
* jk/submodule-subdirectory-ok (2013-04-24) 3 commits
(merged to 'next' on 2013-04-24 at 6306b29)
+ submodule: fix quoting in relative_path()
(merged to 'next' on 2013-04-22 at
Hi,
I'm trying to test this new feature and having problems getting any
results in the following scenario:
i have a repo in local folder
/home/users/myuser/repos/projectA/.git
i start the daemon with the following:
git daemon --export-all --base-path=/home/users/myuser/repos
Hi,
the gitignore rules work so that if a directory is ignored, all files
in that directory are ignored. While that behavior isn't clearly
documented in gitignore, this behavior is consistent across all git
tools (status, ls-files, ...).
An exception is that listing the ignored files using
On Fri, May 31, 2013 at 04:22:37PM -0400, Roland Schulz wrote:
Hi,
the gitignore rules work so that if a directory is ignored, all files
in that directory are ignored. While that behavior isn't clearly
documented in gitignore, this behavior is consistent across all git
tools (status,
Hi,
Is there a way to prevent reflog deletion when the branch is deleted?
The last entry could simply be a line where the second SHA is all 0's.
--
Sitaram
--
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
On 06/01/2013 03:31 AM, Sitaram Chamarty wrote:
Is there a way to prevent reflog deletion when the branch is deleted?
The last entry could simply be a line where the second SHA is all 0's.
This is a known problem. The technical reason that this is not trivial
to solve is the possibility of a
On Sat, Jun 01, 2013 at 05:00:07AM +0200, Michael Haggerty wrote:
This is a known problem. The technical reason that this is not trivial
to solve is the possibility of a directory/file conflict between old
reflog files and references that might be created subsequently (which in
turn is a
51 matches
Mail list logo
