On Sat, 31 Aug 2013, Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Incorporated suggestions by Nico and Junio. I went ahead and added
escape hatches for converting thin packs to full ones so the document
does not really match the code (I've been
On Tue, 3 Sep 2013, Duy Nguyen wrote:
On Tue, Aug 27, 2013 at 11:25 AM, Nicolas Pitre n...@fluxnic.net wrote:
This goes as follows:
- Tree reference: either variable length encoding of the index
into the SHA1 table or the literal SHA1 prefixed by 0 (see
add_sha1_ref()).
-
On Sat, Aug 31, 2013 at 10:22:50PM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 26, 2013 at 07:57:47PM +0300, Michael S. Tsirkin wrote:
Consider [anything]-by: a valid signature.
This includes Tested-by: Acked-by: Reviewed-by: etc.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
On Tue, 3 Sep 2013, Nicolas Pitre wrote:
On Sat, 31 Aug 2013, Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Incorporated suggestions by Nico and Junio. I went ahead and added
escape hatches for converting thin packs to full ones so the
On Mon, Sep 02, 2013 at 10:05:07AM +0700, Nguyen Thai Ngoc Duy wrote:
Current code peaks into the transfered pack's header, if the number of
objects is under a limit, unpack-objects is called to handle the rest,
otherwise index-pack is. This patch makes fetch-pack use index-pack
On Mon, Sep 02, 2013 at 01:42:31AM -0400, Richard Hansen wrote:
Complete the rev^{type} family of object specifiers by having
rev^{tag} dereference rev until a tag object is found (or fail if
unable).
At first glance this may not seem very useful, as commits, trees, and
blobs cannot be
The only changes in this new version are:
- removed useless redirections in 8/11
- improved commit message in 11/11 (s/litlle/little/)
I may add examples and more in a new patch series later.
Christian Couder (11):
replace: forbid replacing an object with one of a different
Users replacing an object with one of a different type were not
prevented to do so, even if it was obvious, and stated in the doc,
that bad things would result from doing that.
To avoid mistakes, it is better to just forbid that though.
If one object is replaced with one of a different type, the
On Mon, Sep 02, 2013 at 01:30:38AM -0500, Felipe Contreras wrote:
Just as 5 == X is weird, so is comparing first the expected value, and
then the value we are testing. So switch them around.
Actually, our normal comparison order for test output is test_cmp
expect actual, as it shows a test
A previous patch ensures that both the replaced and the replacement
objects passed to git replace must be of the same type.
While at it state that there is no other restriction on both objects.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-replace.txt | 7 ---
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t6050-replace.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 05be228..622b751 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -276,6 +276,12 @@ test_expect_success
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t6050-replace.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index decdc33..5c352c4 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -263,4 +263,17 @@
It is now standard practice in Git to have both short and long option
names. So let's give a long option name to the git replace options too.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
builtin/replace.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
If -f option, which means '--force', is used, we can allow an object
to be replaced with one of a different type, as the user should know
what (s)he is doing.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
builtin/replace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
So that they are tested a little bit too.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t6050-replace.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 622b751..1fe5c1b 100755
--- a/t/t6050-replace.sh
+++
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-replace.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index a2bd2ee..414000e 100644
--- a/Documentation/git-replace.txt
+++
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-replace.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 736b48c..a2bd2ee 100644
--- a/Documentation/git-replace.txt
+++
There were no hints in the documentation about how to create
replacement objects.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Documentation/git-replace.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/git-replace.txt
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t6050-replace.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 5c352c4..05be228 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -276,4 +276,10 @@ test_expect_success
On Tue, Sep 3, 2013 at 1:09 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Sat, 31 Aug 2013, Duy Nguyen wrote:
On Tue, Aug 27, 2013 at 11:26 AM, Nicolas Pitre n...@fluxnic.net wrote:
A bit crud but good enough for now.
I wonder if we should keep a short SHA-1 table in .idx. An entry in
the
When using git-svn in combination with serf-1.2.1 core dumps are
created on termination. This is caused by a bug in serf, a fix for
the bug exists (see https://code.google.com/p/serf/source/detail?r=2146).
Nevertheless, I think it makes sense to fix the issue within the
git perl module Ra.pm, too.
On Tue, Sep 3, 2013 at 1:30 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 3 Sep 2013, Duy Nguyen wrote:
On Tue, Aug 27, 2013 at 11:25 AM, Nicolas Pitre n...@fluxnic.net wrote:
This goes as follows:
- Tree reference: either variable length encoding of the index
into the SHA1 table
On Mon, Sep 02, 2013 at 10:27:48PM -0400, Dale R. Worley wrote:
I guess the else could and should be dropped. If you do so (and
possibly insert a blank line between the DEFAULT_PAGER case and the
pager = NULL case), you get a nice pattern
if (!pager)
try_something();
if
On Mon, Sep 2, 2013 at 9:39 AM, Nazri Ramliy ayieh...@gmail.com wrote:
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 83edf30..7a1369a 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -395,6 +395,20 @@ displayed. See linkgit:git-help[1] for more information,
Hi,
On Tue, Sep 03, 2013 at 03:12:56AM -0400, Jeff King wrote:
On Mon, Sep 02, 2013 at 01:30:38AM -0500, Felipe Contreras wrote:
Just as 5 == X is weird, so is comparing first the expected value, and
then the value we are testing. So switch them around.
Actually, our normal comparison
On Mon, Sep 02, 2013 at 10:37:45PM -0400, Dale R. Worley wrote:
I've noticed that Git by default puts long output through less as a
pager. I don't like that, but this is not the time to change
established behavior. But while tracking that down, I noticed that
the paging behavior is
On Tue, Sep 03, 2013 at 09:51:07AM +0200, SZEDER Gábor wrote:
I wonder if we should have a:
test_cmp_args () {
echo $1 expect
echo $1 actual
test_cmp expect actual
}
to let these remain one-liners like:
test_cmp_args $(git rev-parse
On Mon, Sep 2, 2013 at 1:48 PM, Brad King brad.k...@kitware.com wrote:
Extend t/t1400-update-ref.sh to cover cases using the --stdin option.
Signed-off-by: Brad King brad.k...@kitware.com
---
t/t1400-update-ref.sh | 256
+
1 file changed,
On Thu, Aug 29, 2013 at 11:41:56AM -0400, Dale R. Worley wrote:
I know I'm griping here, but I thought that part of the reward for
contributing to an open-source project was as a showcase of one's
work. Commenting your code is what you learn first in programming.
You will find that the best
On Tue, Sep 03, 2013 at 02:35:35AM -0400, Jeff King wrote:
On Sat, Aug 31, 2013 at 10:22:50PM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 26, 2013 at 07:57:47PM +0300, Michael S. Tsirkin wrote:
Consider [anything]-by: a valid signature.
This includes Tested-by: Acked-by: Reviewed-by:
On Mon, Sep 2, 2013 at 11:50 PM, Philip Oakley philipoak...@iee.org wrote:
From: Christian Couder chrisc...@tuxfamily.org
You mean something like the following:
$ cat ./graft2replace.sh
#!/bin/bash
while read orig parents
do
printf %s git cat-file commit $orig
printf %s
Are you in need of a financial assistant or you have been denied by Banks or
Financial firms of a loan.Contact E-mail: alliancewestfinanc...@wildblue.net
--
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 Tue, Sep 3, 2013 at 3:03 AM, Jeff King p...@peff.net wrote:
On Tue, Sep 03, 2013 at 09:51:07AM +0200, SZEDER Gábor wrote:
I wonder if we should have a:
test_cmp_args () {
echo $1 expect
echo $1 actual
test_cmp expect actual
}
to let these
On Tue, 03 Sep 2013 12:46:52 +, Andreas Krey wrote:
...
I have a strange behaviour from a bare repo I inherited;
when I clone from that one (ssh) the branch checked out
is *not* the one referenced in HEAD in the remote repo,
I now have a sample repo that reproduces this behaviour.
Unpack
On Tue, Sep 3, 2013 at 1:46 PM, Nicolas Pitre n...@fluxnic.net wrote:
So... looks like pack v4 is now functional.
However something is still wrong as it operates about 6 times slower
than pack v3.
Anyone wishes to investigate?
You recurse in decode_entries too deep.I check the first 1
On Tue, Sep 3, 2013 at 1:49 PM, Jeff King p...@peff.net wrote:
- by going through index-pack first, then unpack, we pay extra cost
for completing a thin pack into a full one. But compared to fetch's
total time, it should not be noticeable because unpack-objects is
only called when
On Tue, Sep 3, 2013 at 3:42 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
No wish to bike-shed, however, I find effective directory somewhat
difficult to digest due to its jargony feel. It also seems ambiguous
(to me) since previous effective directory may mean directory when
git was run or
On 09/03/2013 12:43 AM, Michael Haggerty wrote:
Hmmm, I see that you changed the signature of update_refs() to take an
array of pointers. My suggestion was unclear, but I didn't mean that
the function signature had to be changed.
[snip]
However, your approach is also fine.
Okay. Thanks for
On 09/03/2013 04:16 AM, Eric Sunshine wrote:
When you decomposed the monolithic test from v1 into individual tests,
you dropped a couple cases (fatal: unknown option' and fatal:
unterminated single-quote). Was this intentional?
Yes. The v3 patch 7 changed the set of error messages to be
On Tue, 03 Sep 2013 13:48:31 +, Andreas Krey wrote:
...
I now have a sample repo that reproduces this behaviour.
Unpack tar file, clone, see clone having 'wrong' branch
checked out, apparently independent of the transport:
Ouch, it looks like 'git clone' doesn't actually know
the 'current
On Tue, 03 Sep 2013 15:02:50 +, Michael Schubert wrote:
...
happen to have the HEAD *commit* as their tip.
Yes, it picks the first of those:
http://thread.gmane.org/gmane.comp.version-control.git/168144
Thanks for the pointer.
And pity, the patches didn't make it that time either...
On Tue, Sep 03, 2013 at 08:39:54AM -0500, Felipe Contreras wrote:
On Tue, Sep 3, 2013 at 6:10 AM, SZEDER Gábor sze...@ira.uka.de wrote:
On Tue, Sep 03, 2013 at 05:45:06AM -0500, Felipe Contreras wrote:
On Tue, Sep 3, 2013 at 3:03 AM, Jeff King p...@peff.net wrote:
On Tue, Sep 03, 2013 at
On Tue, Sep 3, 2013 at 6:49 PM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, Sep 3, 2013 at 1:46 PM, Nicolas Pitre n...@fluxnic.net wrote:
So... looks like pack v4 is now functional.
However something is still wrong as it operates about 6 times slower
than pack v3.
Anyone wishes to
On Tue, 20 Aug 2013 12:28:39 -0700 Junio C Hamano gits...@pobox.com wrote:
JCH Ted Zlatanov t...@lifelogs.com writes:
A while has passed since contrib/credential/netrc was added. Is it OK to
promote it to be part of the main installation?
JCH I gave it a quick glance, and it seems to be
On Tue, 27 Aug 2013 16:05:51 -0400 Jeff King p...@peff.net wrote:
JK On Mon, Aug 26, 2013 at 08:56:23PM -0700, Junio C Hamano wrote:
Antoine Pelisse apeli...@gmail.com writes:
I've tried to use the netrc credential with git-send-email
(v1.8.4-rc2), and I've had the following log (running
Andreas Krey a.k...@gmx.de writes:
On Tue, 03 Sep 2013 15:02:50 +, Michael Schubert wrote:
...
happen to have the HEAD *commit* as their tip.
Yes, it picks the first of those:
http://thread.gmane.org/gmane.comp.version-control.git/168144
Thanks for the pointer.
And pity, the
Felipe Contreras felipe.contre...@gmail.com writes:
On Fri, Aug 30, 2013 at 6:55 PM, Junio C Hamano gits...@pobox.com wrote:
People often find git log --branches etc. that includes _all_
branches is cumbersome to use when they want to grab most but except
some. The same applies to --tags,
Since 664059fb62 (Felipe Contreras, Apr 17 2013, transport-helper: update
remote helper namespace), a 'push' operation on a remote helper updates
the private ref by default. This is often a good thing, but it can also
be desirable to disable this update to force the next 'pull' to re-import
the
Johannes Sixt j...@kdbg.org writes:
Am 31.08.2013 01:55, schrieb Junio C Hamano:
People often find git log --branches etc. that includes _all_
branches is cumbersome to use when they want to grab most but except
some. The same applies to --tags, --all and --glob.
Teach the revision
Felipe Contreras felipe.contre...@gmail.com writes:
Subject: branch: use $curr_branch_short more
Why? I don't think that summary explains the reason for being for this
patch, also, it starts with branch: instead of pull:
Subject: pull: trivial simplification
With that summary, people
Hi,
I surprised myself trying to run git fetch --reference local directory
remote
in the hope git would use my local directory to resolve objects
present in remote but not
in my current repository ... just like git clone --reference local
directory URL:
--reference repository
If
SZEDER Gábor wrote:
On Tue, Sep 03, 2013 at 08:39:54AM -0500, Felipe Contreras wrote:
There are two ways to fix an inconsistency, the other way is to fix
test_cmp. But that would be a change, and change is not welcome in
Git.
It depends on the change, I suppose. I agree, changing 3k+ lines
From: Felipe Contreras felipe.contre...@gmail.com
Instead of cramming everything in one line, put the test body in an
indented block after the opening test_expect_success line and quote
and put the closing quote on a line by itself.
Use single-quote instead of double-quote to quote the test body
From: Felipe Contreras felipe.contre...@gmail.com
This way, if rev-parse segfaults then the test will fail instead
of treating it the same way as a controlled failure.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Michael S. Tsirkin m...@redhat.com writes:
On Tue, Sep 03, 2013 at 02:35:35AM -0400, Jeff King wrote:
On Sat, Aug 31, 2013 at 10:22:50PM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 26, 2013 at 07:57:47PM +0300, Michael S. Tsirkin wrote:
Consider [anything]-by: a valid signature.
This
Use test_cmp instead of passing two command substitutions to the
test builtin. This way:
- when tests fail, they can print a helpful diff if run with
--verbose
- the argument order test_cmp expect actual feels natural,
unlike test known = unknown that seems a little backwards
- the
Michael S. Tsirkin m...@redhat.com writes:
I always want my diffs to show header files first,
then .c files, then the rest. Make it possible to
set orderfile though a config option to achieve this.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
I admit that I was the guilty one who
From: Felipe Contreras felipe.contre...@gmail.com
Save the reader from learning specialized t6* setup functions
where familiar commands like test_commit, git checkout --orphan,
and git merge will do.
While at it, wrap the setup commands in a test assertion so errors can
be caught and stray
From: Felipe Contreras felipe.contre...@gmail.com
Save the reader from learning specialized t6* setup functions
where familiar commands like test_commit, git checkout --orphan,
and git merge will do.
While at it, wrap the setup commands in a test assertion so errors can
be caught and stray
On Tue, Sep 03, 2013 at 10:04:19AM -0700, Jonathan Nieder wrote:
It depends on the change, I suppose. I agree, changing 3k+ lines just
to avoid yoda conditions... I doubt the gain worth the code churn.
Especially when the idiom being changed is not even being made better.
;-)
Yes. IMHO
Felipe Contreras felipe.contre...@gmail.com writes:
Junio already sent a similar patch, but I think this is simpler.
I agree that this is simpler, but I am not sure if the behaviour is
necessarily better (note that this is different from saying I think
the behaviour of this patch is worse).
On Tue, Sep 03, 2013 at 06:56:23PM +0700, Nguyen Thai Ngoc Duy wrote:
...but the cost is paid by total pack size, not number of objects. So if
I am pushing up a commit with a large uncompressible blob, I've
effectively doubled my disk I/O. It would make more sense to me for
index-pack to
Yann Droneaud ydrone...@opteya.com writes:
So what's the best way to do a git fetch remote, copying objects from
another local repository
to resolve delta ?
IMHO the best way is to add a remote for the local repository, fetch
from it, then fetch from remote.
Andreas.
--
Andreas Schwab,
Jeff King p...@peff.net writes:
I'll venture my opinion. We should do this:
-- 8 --
Subject: pager: turn on cat optimization for DEFAULT_PAGER
If the user specifies a pager of cat (or the empty
string), whether it is in the environment or from config, we
automagically optimize it out to
Felipe Contreras felipe.contre...@gmail.com writes:
There are two ways to fix an inconsistency, the other way is to fix
test_cmp. But that would be a change, and change is not welcome in
Git.
If you want to do test_cmp $actual $expect, you would have to
first fix people's expectation that
Complete the rev^{type} family of object descriptors by having
rev^{tag} dereference rev until a tag object is found (or fail if
unable).
At first glance this may not seem very useful, as commits, trees, and
blobs cannot be peeled to a tag, and a tag would just peel to itself.
However, this can
On Tue, Sep 03, 2013 at 11:23:14AM -0400, Ted Zlatanov wrote:
Yes, you're right. Something like the following (untested) could work
and does the wildcards, which I will make into a proper patch and test
if it looks OK to you.
Ted
diff --git
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
There are two ways to fix an inconsistency, the other way is to fix
test_cmp. But that would be a change, and change is not welcome in
Git.
If you want to do test_cmp $actual $expect, you would
On Tue, Sep 03, 2013 at 01:37:33PM -0400, Richard Hansen wrote:
---
Changes since v2 (2013-09-02, see
http://thread.gmane.org/gmane.comp.version-control.git/233598):
* add a test case (hopefully I didn't go overboard)
Personally I was thinking just
test_must_fail git rev-parse
kazuki saitoh ksaitoh...@gmail.com writes:
Currently, git p4 does not support many of the view wildcards,
such as * and %%n. It only knows the common ... mapping, and
exclusions.
Redo the entire wildcard code around the idea of
directly querying the p4 server for the mapping. For each
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This makes reinitializing on a .git file repository work.
This is probably the only case that setup_git_env() (via
set_git_dir()) is called on a .git file. Other cases in
setup_git_dir_gently() and enter_repo() both cover .git file case
On 2013-09-03 03:05, Jeff King wrote:
FWIW, this makes sense to me.
Thank you for the feedback. I posted a reroll of the patch that you've
already replied to, but for the benefit of others searching the mailing
list archive, v3 can be found at
Felipe Contreras felipe.contre...@gmail.com writes:
This is useful to make sure we don't step outside the boundaries of what
we are interpreting at the moment. For example while interpreting
foobar@{u}~1, the job of interpret_branch_name() ends right before ~1,
but there's no way to figure
Felipe Contreras felipe.contre...@gmail.com writes:
diff --git a/sha1_name.c b/sha1_name.c
index 93197b9..b8ece6e 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1004,6 +1004,26 @@ int get_sha1_mb(const char *name, unsigned char *sha1)
return st;
}
+/* parse @something syntax,
On Tue, Sep 3, 2013 at 1:37 PM, Richard Hansen rhan...@bbn.com wrote:
diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
index eaefc77..5771cbd 100755
--- a/t/t1511-rev-parse-caret.sh
+++ b/t/t1511-rev-parse-caret.sh
@@ -54,6 +61,26 @@ test_expect_success 'ref^{tree}' '
The first three are trivially correct and good changes. I still have
to read the last one, but wanted to give a Thanks before doing so,
which would take more time.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
Felipe Contreras felipe.contre...@gmail.com writes:
After every test the environment should be as close as to how it was
before as possible.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Very good in general; a few points (not the patch breaks things,
but more like tests
Am 29.08.2013 21:54, schrieb Jens Lehmann:
Am 29.08.2013 15:05, schrieb Matthieu Moy:
The --for-status option was an undocumented option used only by
wt-status.c, which inserted a header and commented out the output. We can
achieve the same result within wt-status.c, without polluting the
On Tue, Sep 03, 2013 at 02:36:39PM -0400, Richard Hansen wrote:
I have a patch submission question: Is it OK that I didn't use the
'--in-reply-to' argument to 'git send-email' when I sent the v3 reroll?
Should I have marked it as a reply to the v2 email? Or should I have
marked it as a
Christopher Durkin cjdur...@gmail.com writes:
I submitted a small feature addition patch for gitweb (see
http://article.gmane.org/gmane.comp.version-control.git/232327/match=gitweb)
a couple of weeks ago.
I didn't get any responses, good or bad. Was there something wrong
with my submission
On 2013-09-03 15:03, Eric Sunshine wrote:
On Tue, Sep 3, 2013 at 1:37 PM, Richard Hansen rhan...@bbn.com wrote:
diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
index eaefc77..5771cbd 100755
--- a/t/t1511-rev-parse-caret.sh
+++ b/t/t1511-rev-parse-caret.sh
@@ -54,6 +61,26
Felipe Contreras felipe.contre...@gmail.com writes:
Split into a separate helper function get_commit() so that the part that
finds the relevant commit, and the part that does something with it
(handle tag object, etc.) are in different places.
No functional changes.
Actually, the old code
Am 03.09.2013 18:03, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
So I like the relative simplicity of this approach. Here is a bit of
documentation.
Oh, thanks for helping. An example or two may also help, and using
your original I have branches and wip/ situation would be
Jens, I see 1/2 is the same as the previous one you already acked.
Does this update to 2/2 look good to you? Sorry, but I lost track
of the discussion that led to this reroll, hence a ping.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Jonathan Nieder jrnie...@gmail.com writes:
Use test_cmp instead of passing two command substitutions to the
test builtin. This way:
- when tests fail, they can print a helpful diff if run with
--verbose
- the argument order test_cmp expect actual feels natural,
unlike test known
I submitted a small feature addition patch for gitweb (see
http://article.gmane.org/gmane.comp.version-control.git/232327/match=gitweb)
a couple of weeks ago.
I didn't get any responses, good or bad. Was there something wrong
with my submission in terms of formatting? Something else that I
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
Split into a separate helper function get_commit() so that the part that
finds the relevant commit, and the part that does something with it
(handle tag object, etc.) are in different places.
No
Complete the rev^{type} family of object descriptors by having
rev^{tag} dereference rev until a tag object is found (or fail if
unable).
At first glance this may not seem very useful, as commits, trees, and
blobs cannot be peeled to a tag, and a tag would just peel to itself.
However, this can
When we are parsing rev^{foo}, we check foo against the
various global type strings, like commit_type,
tree_type, etc. This is nicely abstracted, but then we
destroy the abstraction completely by using magic numbers
that must match the length of the type strings.
We can avoid these magic numbers
Am 01.09.2013 22:06, schrieb brian m. carlson:
git status prints information for submodules, but it should ignore the status
of
those which have submodule.name.ignore set to all. Fix it so that it does
properly ignore those which have that setting either in .git/config or in
.gitmodules.
Christopher Durkin cjdur...@gmail.com writes:
Add another item to the search drop-down (author/committer/etc)
to search for file names instead of file content. Output is similar
to the grep contents output, with each entry linking to the file.
---
Missing sign-off.
gitweb/gitweb.perl | 59
Richard Hansen rhan...@bbn.com writes:
diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh
index eaefc77..15973f2 100755
--- a/t/t1511-rev-parse-caret.sh
+++ b/t/t1511-rev-parse-caret.sh
@@ -54,6 +54,13 @@ test_expect_success 'ref^{tree}' '
test_must_fail git
When we are parsing rev^{foo}, we check foo against the
various global type strings, like commit_type,
tree_type, etc. This is nicely abstracted, but then we
destroy the abstraction completely by using magic numbers
that must match the length of the type strings.
We could avoid these magic
Jeff King p...@peff.net writes:
If you _really_ wanted to abstract it, you could make commit_type a
macro and use string concatenation along with prefixcmp. But that is
going in the direction of less readable, I think. :)
;-) we are on the same wave-length.
Thanks, will apply.
This has
On Tue, Sep 03, 2013 at 10:06:19AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Tue, Sep 03, 2013 at 02:35:35AM -0400, Jeff King wrote:
On Sat, Aug 31, 2013 at 10:22:50PM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 26, 2013 at 07:57:47PM +0300, Michael
On Wed, Sep 04, 2013 at 12:01:49AM +0300, Michael S. Tsirkin wrote:
The question of course is the first point Peff raised. I am not
sure offhand what the right per-project customization interface
would be. A starting point might be something like:
On Tue, Sep 03, 2013 at 10:12:18AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
I always want my diffs to show header files first,
then .c files, then the rest. Make it possible to
set orderfile though a config option to achieve this.
Signed-off-by: Michael
On Tue, Sep 03, 2013 at 05:03:52PM -0400, Jeff King wrote:
On Wed, Sep 04, 2013 at 12:01:49AM +0300, Michael S. Tsirkin wrote:
The question of course is the first point Peff raised. I am not
sure offhand what the right per-project customization interface
would be. A starting point
On Tue, Sep 3, 2013 at 12:07 PM, Jonathan Nieder jrnie...@gmail.com wrote:
test_expect_success 'start^0' '
- test $(cat .git/refs/tags/start) = $(git rev-parse start^0)
+ test_cmp_rev_output tags/start git rev-parse start^0
'
Backwards and yodaish this is.
--
Felipe Contreras
On Tue, Sep 3, 2013 at 12:04 PM, Jonathan Nieder jrnie...@gmail.com wrote:
SZEDER Gábor wrote:
On Tue, Sep 03, 2013 at 08:39:54AM -0500, Felipe Contreras wrote:
There are two ways to fix an inconsistency, the other way is to fix
test_cmp. But that would be a change, and change is not welcome
1 - 100 of 119 matches
Mail list logo
