On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras
wrote:
>>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
>>> 'master@'.
>>
>> I'm a bit reluctant to this. It looks like incomplete syntax to me as
>> '@' has always been followed by '{'. Can we have the lone '@' candy
On Tue, Apr 30, 2013 at 1:17 AM, Duy Nguyen wrote:
> On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras
> wrote:
>> On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen wrote:
>>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
>>> wrote:
So we can type '@' instead of 'HEAD@', or rather 'HEAD'. S
On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras
wrote:
> On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen wrote:
>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
>> wrote:
>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>>> use 'git show @~1', and all that goody good
On Tue, Apr 30, 2013 at 1:07 AM, Duy Nguyen wrote:
> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
> wrote:
>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
>>
>> This patch allows 'HEAD@' to be the
On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen wrote:
> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
> wrote:
>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>> use 'git show @~1', and all that goody goodness.
>
> I like this. I haven't spent a lot of time on thinking
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
wrote:
> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
>
> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
> 'master@'.
>
> So
On Mon, Apr 29, 2013 at 11:42 PM, Nguyễn Thái Ngọc Duy
wrote:
> This patch separates submodule odb sources from ordinary alternate
> sources. The new sources can be accessed with ODB_EXTALT (e.g. via
> read_sha1_file_extended).
>
> ODB_EXTALT is only added to odb_default in certain cases. Basicall
On Mon, Apr 29, 2013 at 11:42 PM, Nguyễn Thái Ngọc Duy
wrote:
> A submodule's object database may be imported to in-core object pool
> for a quick peek without paying the price of running a separate git
> command. These databases are marked in for stricter checks later to
s/marked in/marked/ perh
On Mon, Apr 29, 2013 at 11:42 PM, Nguyễn Thái Ngọc Duy
wrote:
> diff --git a/cache.h b/cache.h
> index 94ca1ac..bed403a 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -744,12 +744,33 @@ char *strip_path_suffix(const char *path, const char
> *suffix);
> int daemon_avoid_alias(const char *path);
> i
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
wrote:
> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
> use 'git show @~1', and all that goody goodness.
I like this. I haven't spent a lot of time on thinking about
ambiguation. But I think we're safe there. '@' is not o
Junio C Hamano writes:
> A much larger issue is that the current setup_revisions()
> infrastructure does not let us express an operation that involves
> two or more DAGs. People sometimes wish to say an equivalent of
>
> git show $(git rev-list A..B) $(git rev-list C..D)
>
> but obviously
>
Hi all,
Since Git v1.8.3-rc0 had already been released, it's time to start new round
of git l10n. This time there are 44 new messages need to be translated.
A new "git.pot" is generated in commit v1.8.3-rc0-20-gc6bc7:
l10n: git.pot: v1.8.3 round 2 (44 new, 12 removed)
Generate po/git.po
Those in ODB_EXTALT are temporary and will be gone soon. Make a
permanent copy for safety.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
sha1_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index b8f2afe..ce3698a 100644
--- a/sha1_file.c
+++ b/sha1_
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/mktag.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/builtin/mktag.c b/builtin/mktag.c
index 640ab64..2284280 100644
--- a/builtin/mktag.c
+++ b/builtin/mktag.c
@@ -23,7 +23,10 @@ static int verify_object(const unsigned ch
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache-tree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cache-tree.c b/cache-tree.c
index 37e4d00..478da88 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -343,7 +343,8 @@ static int update_one(struct cache_tree *it,
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 1 +
commit.c| 9 +
sha1_file.c | 7 +++
3 files changed, 17 insertions(+)
diff --git a/cache.h b/cache.h
index bc3ccd8..57b6d30 100644
--- a/cache.h
+++ b/cache.h
@@ -804,6 +804,7 @@ extern int move_temp_to_file(const char *t
A submodule's object database may be imported to in-core object pool
for a quick peek without paying the price of running a separate git
command. These databases are marked in for stricter checks later to
avoid accidentially refering to a submodule's SHA-1 from main repo
(except in gitlinks).
Sign
This patch separates submodule odb sources from ordinary alternate
sources. The new sources can be accessed with ODB_EXTALT (e.g. via
read_sha1_file_extended).
ODB_EXTALT is only added to odb_default in certain cases. Basically:
- External commands do not access submodule odb by default
- unpac
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 2 +-
cache.h | 3 ++-
fast-import.c| 2 +-
sha1_file.c | 15 +--
4 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 79dfe47.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 29 +--
fast-import.c | 2 +-
pack-check.c | 2 +-
sha1_file.c | 165 +++---
streaming.c | 4 +-
5 files changed, 141 insertions(+), 61 deletions(-)
diff --git a/cache
The idea behind this series is, after add_submodule_odb, odb may have
new temporary objects that only appear after the call. These temporary
objects may lead to repo corruption (e.g. some new objects are created
and point to these temporary objects). This series attempts to catch
those cases. It wo
On Mon, Apr 29, 2013 at 3:15 PM, Marc Branchaud wrote:
> --- a/Documentation/RelNotes/1.8.3.txt
> +++ b/Documentation/RelNotes/1.8.3.txt
> @@ -8,23 +8,22 @@ When "git push [$there]" does not say what to push, we have
> used the
> traditional "matching" semantics so far (all your branches were se
In this particular code path, we add "base" to the delta base
cache. Then decide to free it, but we forgot about a dangling pointer
in the cache. Invalidate that entry when we free "base".
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Some of my changes triggered a double free fault at "free(base);" i
Junio C Hamano wrote:
> Felipe Contreras writes:
>> Never-mind, now I see the difference, still, I don't think it's
>> relevant for this patch.
>
> I don't either. With the precedence of @{u}, @ does not need to have
> anything to do with a reflog. It is just a random letter that casts
> a magic
On Tue, Apr 30, 2013 at 02:32:33AM +0200, Johan Herland wrote:
> On Mon, Apr 29, 2013 at 11:40 PM, Adam Spiers wrote:
[snipped]
> > IMHO the more similar the merge's user experience is to a standard
> > merge, the better, since that would minimise the number of merging
> > workflows the user nee
On Mon, Apr 29, 2013 at 11:40 PM, Adam Spiers wrote:
> On Mon, Apr 29, 2013 at 10:13:32AM -0700, Junio C Hamano wrote:
>> Adam Spiers writes:
>> > static struct notes_tree *init_notes_check(const char *subcommand)
>> > ...
>> > Can we relax this to "refs/", to allow better isolation of na
On Tue, Apr 30, 2013 at 1:05 AM, Robert Zeh wrote:
> The call to lstat is only there for testing and should not be in there for
> the final version. Is there an easy way to only enable it for tests?
The usual trick is invent a new GIT_ environment variable. Then check
it and do something differen
(resending since the attachment seems to make vger sad)
Hi,
I'm running git rev-list | git cherry-pick --stdin on a range of about
300 commits. Eventually the chery-pick dies with:
error: cannot fork() for commit: Cannot allocate memory
Running valgrind shows me that the tree traversal code
René Scharfe wrote:
> Am 28.04.2013 21:31, schrieb Junio C Hamano:
>> René Scharfe writes:
>>
>>> Why not take the opposite direction with a patch like this?
>>> ...
>>> diff --git a/compat/mingw.h b/compat/mingw.h
>>> index 389ae01..74e7b87 100644
>>> --- a/compat/mingw.h
>>> +++ b/compat/mingw.h
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Ramsay Jones wrote:
[snip]
> While I really like seeing an unfinished topic completed by tying
> its loose ends like this patch does, it feels a bit too late for the
> cycle, especially given that we _know_ the changes still need to be
> tested
Jonathan Nieder wrote:
> Hi,
>
> Ramsay Jones wrote:
>
>> --- a/compat/nedmalloc/malloc.c.h
>> +++ b/compat/nedmalloc/malloc.c.h
>> @@ -484,6 +484,10 @@ MAX_RELEASE_CHECK_RATE default: 4095 unless not
>> HAVE_MMAP
>> #define DLMALLOC_VERSION 20804
>> #endif /* DLMALLOC_VERSION */
>>
>> +#if
Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> On linux, when the build variable USE_NED_ALLOCATOR is set, gcc
>> issues the following warnings:
>>
>> In file included from compat/nedmalloc/nedmalloc.c:63:
>> .../malloc.c.h: In function 'mmap_resize':
>> .../malloc.c.h:3762: warnin
Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> On MinGW, sparse issues an "'get_st_mode_bits' not declared. Should
>> it be static?" warning. The MinGW and MSVC builds do not see the
>> declaration of this function, within git-compat-util.h, due to it's
>> placement within an preprocessor cond
Torsten Bögershausen wrote:
> On 2013-04-27 20.42, Ramsay Jones wrote:
>>
>> On MinGW, sparse issues an "'get_st_mode_bits' not declared. Should
>> it be static?" warning. The MinGW and MSVC builds do not see the
>> declaration of this function, within git-compat-util.h, due to it's
>> placement wi
René Scharfe wrote:
> Am 27.04.2013 21:19, schrieb Ramsay Jones:
>> In order to suppress these warnings, since both of the main
>> functions need to be declared with the same prototype, we
>> change the declaration of the 9 main functions, thus:
>>
>> int main(int argc, char **argv)
>
> Why n
Duy Nguyen wrote:
> On Sun, Apr 28, 2013 at 2:43 AM, Ramsay Jones
> wrote:
>> The truncation support was implemented with the assistance of a
>> new strbuf function (strbuf_utf8_replace). This function contains
>> the following code:
>>
>>strbuf_attach(sb_src, strbuf_detach(&sb_dst, NULL),
On Mon, Apr 29, 2013 at 6:06 PM, Junio C Hamano wrote:
> --- a/t/t1503-rev-parse-verify.sh
> +++ b/t/t1503-rev-parse-verify.sh
> @@ -115,13 +115,18 @@ test_expect_success 'master@{n} for various n' '
> test_must_fail git rev-parse --verify master@{$Np1}
> '
>
> -test_expect_success 'empt
The following message is a courtesy copy of an article
that has been posted to gmane.comp.version-control.git as well.
Felipe Contreras writes:
> On Mon, Apr 29, 2013 at 5:38 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> diff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-par
sleeps in the check-ignore test suite are not ideal since they can
fail when the system is under load, or when a tool like valgrind is
used which drastically alters the timing. Therefore we replace them
with a more robust solution using a named pipe (FIFO).
Thanks to Jeff King for coming up with
Felipe Contreras writes:
> Never-mind, now I see the difference, still, I don't think it's
> relevant for this patch.
I don't either. With the precedence of @{u}, @ does not need to have
anything to do with a reflog. It is just a random letter that casts
a magic spell.
--
To unsubscribe from th
On Mon, Apr 29, 2013 at 5:38 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> diff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh
>> index 813cc1b..426c63f 100755
>> --- a/t/t1503-rev-parse-verify.sh
>> +++ b/t/t1503-rev-parse-verify.sh
>> @@ -115,4 +115,13 @@ test_exp
Felipe Contreras writes:
> diff --git a/t/t1503-rev-parse-verify.sh b/t/t1503-rev-parse-verify.sh
> index 813cc1b..426c63f 100755
> --- a/t/t1503-rev-parse-verify.sh
> +++ b/t/t1503-rev-parse-verify.sh
> @@ -115,4 +115,13 @@ test_expect_success 'master@{n} for various n' '
> test_must_fail
John Keeping writes:
> On Mon, Apr 29, 2013 at 08:04:10PM +0200, Thomas Rast wrote:
>> John Keeping writes:
>>
>> > On Mon, Apr 29, 2013 at 07:35:01PM +0530, Ramkumar Ramachandra wrote:
>> >> On a related note, one place that IO parallelism can provide massive
>> >> benefits is in executing she
Antoine Pelisse writes:
> Should we think about adding some commands for that ?
>
> On the very top of my head (there is certainly more than that):
> - Save such a change: By basically creating a ref to HEAD (HEAD being
> the commit, HEAD^ the fixed merge) with merge-fix/HEAD^^1-HEAD^^2
> - Apply
On Mon, Apr 29, 2013 at 10:13:32AM -0700, Junio C Hamano wrote:
> Adam Spiers writes:
>
> > static struct notes_tree *init_notes_check(const char *subcommand)
> > ...
> > Can we relax this to "refs/", to allow better isolation of namespaces
> > for remote notes? Also, the check is applie
On Mon, Apr 29, 2013 at 3:23 PM, Felipe Contreras
wrote:
> On Mon, Apr 29, 2013 at 3:02 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>>> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
>>
>>
Marc Branchaud writes:
> Signed-off-by: Marc Branchaud
>
> ---
>
> This started out as an attempt to make the backward compatibility notes
> more parsable, but then I just kept going...
Thanks; everything other than the "bundle" thing looked sensible.
--
To unsubscribe from this list: send the
Junio C Hamano writes:
> Marc Branchaud writes:
>
>> This started out as an attempt to make the backward compatibility notes
>> more parsable, but then I just kept going...
>
> Thanks.
>
>> * "git bundle" did not like a bundle created using a commit without
>> - any message as its one of the
Marc Branchaud writes:
> This started out as an attempt to make the backward compatibility notes
> more parsable, but then I just kept going...
Thanks.
> * "git bundle" did not like a bundle created using a commit without
> - any message as its one of the prerequistes.
> + any message, as
Junio C Hamano wrote:
> Have you ever seen me saying "it sounds like a good idea" to a
> solution that is looking for a problem? ;-)
I'll try to avoid that approach in the future.
> "diff A...B" works already, and stopping to refer to "diff A..B"
> (the documentation patch you sent out) hopefully
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
There are a few more topics in flight that look sane and trivially
correct that I would feel safe to merge down to 'master', but what
we have in
Felipe Contreras writes:
> It shouldn't matter if @{u} is buggy or not (which I doubt),
Oh, it wouldn't make any difference to this topic; it is just
something we may want to fix if it were broken.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majo
On Mon, Apr 29, 2013 at 3:24 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> But @ is not used just for reflogs, there's @{now}, @{-1}, @{upstream}.
>
> True. @{now} is a reflog, @{-1} is also but @{u} is not. It is a
> kitchen sink and you shouldn't have to have reflog on a branch in
Felipe Contreras writes:
> But @ is not used just for reflogs, there's @{now}, @{-1}, @{upstream}.
True. @{now} is a reflog, @{-1} is also but @{u} is not. It is a
kitchen sink and you shouldn't have to have reflog on a branch in
order to use @{upstream} (I didn't check---I wouldn't be surpris
On Mon, Apr 29, 2013 at 3:02 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
>
> Another technical issue, even if you have reflogs.
>
> HEAD@{0} a
On Mon, Apr 29, 2013 at 3:01 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
>> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
>>
>> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and sim
Felipe Contreras writes:
> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
Another technical issue, even if you have reflogs.
HEAD@{0} and @{0} are referring to two different reflogs, and means
different
Felipe Contreras writes:
> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
> remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
>
> This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
> 'master@'.
>
> So we can type '@' instead of 'HEA
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Wait. What does "lists H G D A..C" even mean? H, G and D I would
>> understand, but how does "log" ever "list" A..C???
>>
>> Now you really confused me.
>
> What you said was technically correct. I was pointing out that the
> graph was mi
Felipe Contreras wrote:
> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
> use 'git show @~1', and all that goody goodness.
Good one. This is what I didn't think of.
The implementation looks beautiful, and I have nothing more to say
about the patch.
--
To unsubscribe from
git-1.8.2.2
glibc-2.17
gettext-0.18.2.1
Recent gettext versions install several libraries:
/usr/lib/libgettextlib-0.18.2.so
/usr/lib/libgettextsrc-0.18.2.so
/usr/lib/libintl.so.8.1.2
/usr/include/autosprintf.h
/usr/include/gettext-po.h
while glibc installs
/usr/include/libintl.h
git reports:
So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
remove '~0', and we can remove 'HEAD', but we can't remove '{0}'?
This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
'master@'.
So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
us
Junio C Hamano wrote:
> * Where the bottom of the DAG being replayed is (i.e. X);
> * What refs are the top of the DAG (i.e. A and B);
> * Where the new bottom of the replayed DAG (i.e. Y).
Okay, so can I start writing a series that will make git rebase accept
one negative commit (N) and one po
Signed-off-by: Marc Branchaud
---
This started out as an attempt to make the backward compatibility notes
more parsable, but then I just kept going...
M.
Documentation/RelNotes/1.8.3.txt | 145 +++
1 file changed, 72 insertions(+), 73 delet
Ramkumar Ramachandra wrote:
> What are your thoughts on overloading it for rebase? git rebase
> master~ to rebase onto the merge-base of master and HEAD?
I just realized that I meant
git rebase master..
and not
git rebase master~
I want to rebase the merge commit, not the merge-base a
Junio C Hamano wrote:
> Compare these (gitk will give you nicer picture):
>
>$ git log --oneline --graph --left-right A...B
>$ git log --oneline --graph --left-right B...A
Darn. I didn't realize that rev-list had a --left-right to mark
commits with <, >, or - before giving it to the comma
Should we think about adding some commands for that ?
On the very top of my head (there is certainly more than that):
- Save such a change: By basically creating a ref to HEAD (HEAD being
the commit, HEAD^ the fixed merge) with merge-fix/HEAD^^1-HEAD^^2
- Apply the merge-fix: On top of a merge, fi
Junio C Hamano wrote:
> Wait. What does "lists H G D A..C" even mean? H, G and D I would
> understand, but how does "log" ever "list" A..C???
>
> Now you really confused me.
What you said was technically correct. I was pointing out that the
graph was misleading because it didn't show any commit
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> As far as I am concerned, there is no A~B issue.
>
> You don't have to remind me about how hostile you are towards new
> proposals. I already know.
That's not "hostile" or "new". I only express strong doubt against
"ideas" (or non-"ideas"
Ramkumar Ramachandra writes:
>>> $ git log rebase.autostash ^$(git merge-base rebase.autostash master)
>>
>> Depending on which one of B or C is chosen it is either one of these:
>>
>> - range "^B H" which lists "H G D C"
>> - range "^C H" which lists "H G D B"
>>
>> neither of which is more us
On Mon, Apr 29, 2013 at 09:32:51AM -0700, Junio C Hamano wrote:
> *1* Instead, you have a separate integration branch for testing that
> merges other's work and your topic.
I wrote a script to help manage this [1]. It doesn't do everything I
want it to yet but I'm using it on a daily basis to m
Junio C Hamano wrote:
> As far as I am concerned, there is no A~B issue.
You don't have to remind me about how hostile you are towards new
proposals. I already know.
> Please don't let it take good changes hostage.
Those are my changes, and I will not check them in until I'm happy
with them. H
John Keeping writes:
> This is identical to the interdiff of what I posted at the same time, so
> it obviously looks good to me.
Thanks. I've replaced the old tip with your version.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kern
Junio C Hamano wrote:
> Please don't. All of these clayoven, LICENSE, foom, loom are mere
> distraction.
>
> ... goes and draws the diagram himself ...
Sorry, I'm finding it hard to draw this thing. I'm only becoming
comfortable with reading it now.
>> $ git log rebase.autostash ^master
On Mon, Apr 29, 2013 at 07:34:27PM +0200, Steffen Jaeckel wrote:
> lately I used git-subtree to integrate a submodule directly into a
> repository. Now I wanted to push the changes back to the original
> repository of the submodule and I was a bit surprised by what
> happened...
>
>
> snip -
On Mon, Apr 29, 2013 at 11:17:00AM -0700, Junio C Hamano wrote:
> Thomas Rast writes:
>
> > John Keeping writes:
> >> diff --git a/t/test-lib.sh b/t/test-lib.sh
> >> index ca6bdef..70ad085 100644
> >> --- a/t/test-lib.sh
> >> +++ b/t/test-lib.sh
> >> @@ -54,8 +54,8 @@ done,*)
> >># do not re
> "Junio" == Junio C Hamano writes:
> Yann Hodique writes:
>>> "Junio" == Junio C Hamano writes:
>>
>>> Yann Hodique writes:
$ git checkout next; git diff-files; git checkout next; git diff-files
Already on 'next'
:100644 100644 bd774cccaa14e061c3c26996567ee28f4f77ec80
Thomas Rast writes:
> John Keeping writes:
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> index ca6bdef..70ad085 100644
>> --- a/t/test-lib.sh
>> +++ b/t/test-lib.sh
>> @@ -54,8 +54,8 @@ done,*)
>> # do not redirect again
>> ;;
>> *' --tee '*|*' --va'*)
>> -mkdir -p test-results
Most test results go in $TEST_OUTPUT_DIRECTORY, but the output files for
tests run with --tee or --valgrind just use bare "test-results".
Changes these so that they do respect $TEST_OUTPUT_DIRECTORY.
As a result of this, the valgrind/analyze.sh script may no longer
inspect the correct files so it
Kevin Bracey writes:
> At present, either query will show lots of really boring merge commits
> of topic branches at the boundary, with 1 INTERESTING parent that
> they're TREESAME too, and 1 UNINTERESTING parent that they may or may
> not be TREESAME to, depending on how old the base of that top
On Mon, Apr 29, 2013 at 08:04:10PM +0200, Thomas Rast wrote:
> John Keeping writes:
>
> > On Mon, Apr 29, 2013 at 07:35:01PM +0530, Ramkumar Ramachandra wrote:
> >> On a related note, one place that IO parallelism can provide massive
> >> benefits is in executing shell scripts. Accordingly, I al
John Keeping writes:
> On Mon, Apr 29, 2013 at 07:35:01PM +0530, Ramkumar Ramachandra wrote:
>> On a related note, one place that IO parallelism can provide massive
>> benefits is in executing shell scripts. Accordingly, I always use the
>> following commands to compile and test git respectively
Yann Hodique writes:
>> "Junio" == Junio C Hamano writes:
>
>> Yann Hodique writes:
>>> $ git checkout next; git diff-files; git checkout next; git diff-files
>>> Already on 'next'
>>> :100644 100644 bd774cccaa14e061c3c26996567ee28f4f77ec80
>>> M m
John Keeping writes:
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index ca6bdef..70ad085 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -54,8 +54,8 @@ done,*)
> # do not redirect again
> ;;
> *' --tee '*|*' --va'*)
> - mkdir -p test-results
> - BASE=test-results/$(b
Hi,
Ramsay Jones wrote:
> Some systems experience failures in t4205-*.sh (tests 18-20, 27)
> which all relate to the use of truncation with the %< padding
> placeholder. This capability was added in the commit a7f01c6b
> ("pretty: support truncating in %>, %< and %><", 19-04-2013).
This is repro
> "Junio" == Junio C Hamano writes:
> Yann Hodique writes:
>> $ git checkout next; git diff-files; git checkout next; git diff-files
>> Already on 'next'
>> :100644 100644 bd774cccaa14e061c3c26996567ee28f4f77ec80
>> M magit.el
>> Already on 'next'
On 28/04/2013 21:38, Junio C Hamano wrote:
@@ -773,6 +861,9 @@ static void limit_to_ancestry(struct
commit_list *bottom, struct commit_list *li
* NEEDSWORK: decide if we want to remove parents that are
* not marked with TMP_MARK from commit->parents for commits
* i
From: Johannes Sixt
Signed-off-by: Johannes Sixt
---
git-remote-testgit | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/git-remote-testgit b/git-remote-testgit
index 643e4ae..b528949 100755
--- a/git-remote-testgit
+++ b/git-remote-testgit
@@ -1,4 +1,4 @@
-#!/u
Just like all the other shell scripts, replace the shebang line to
make sure it runs under the shell the user specified.
As this no longer depends on bashisms, t5801 does not have to say
bash must be available somewhere on the system.
Signed-off-by: Junio C Hamano
---
.gitignore
From: Johannes Sixt
The implementation of bash on Windows does not offer process substitution.
Signed-off-by: Johannes Sixt
Signed-off-by: Junio C Hamano
---
git-remote-testgit | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/git-remote-testgit b/git-remote-te
The two from J6t are what were discussed on the list. The last one
is to teach git-remote-testgit to honor SHELL_PATH like all the
other shell scripts.
Johannes Sixt (2):
git-remote-testgit: avoid process substitution
git-remote-testgit: further remove some bashisms
Junio C Hamano (1):
git
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> I had an impression that many of them, with the suggested fix-ups,
>> were improvements, with or without the A~B discussion. It seems
>> that the entire review wasted many braincycles if you are to drop
>> the ball at this point, which is v
Junio C Hamano wrote:
> That is not a problem.
> [...]
> A more important reason to have them as separate entries is to avoid
> giving a wrong impression that "--" is somehow related to ,
Okay, makes sense then. Queue it for this and shortlog; we can write
it for the other manpages gradually.
--
Johannes Sixt writes:
> The patch below doesn't remove the bash dependency, yet, but it addresses
> the problematic mismatch you noticed without the need for $LF. Can you
> please queue it to move the topic forward?
I'll send three-patch series I have (including the two discussed in
the thread)
Hi,
lately I used git-subtree to integrate a submodule directly into a
repository. Now I wanted to push the changes back to the original
repository of the submodule and I was a bit surprised by what
happened...
snip
sjaeckel@T7400-003 /h/projects/my_project (develop)
$ GIT_TRACE=2 git
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> That world view is broken, isn't it? Perhaps you forgot to consider
>> symmetric differences, where left positives and right positives have
>> to be treated differently.
>
> No, I did consider symmetric difference. How is git log A B --not
Junio C Hamano wrote:
> I had an impression that many of them, with the suggested fix-ups,
> were improvements, with or without the A~B discussion. It seems
> that the entire review wasted many braincycles if you are to drop
> the ball at this point, which is very dissapointing.
No, I don't meant
Junio C Hamano wrote:
> That world view is broken, isn't it? Perhaps you forgot to consider
> symmetric differences, where left positives and right positives have
> to be treated differently.
No, I did consider symmetric difference. How is git log A B --not
$(git merge-base --all A B) different
Adam Spiers writes:
> static struct notes_tree *init_notes_check(const char *subcommand)
> ...
> Can we relax this to "refs/", to allow better isolation of namespaces
> for remote notes? Also, the check is applied for GIT_NOTES_REF and
> core.notesRef, but not for values passed via --ref
Ramkumar Ramachandra writes:
> [Corrected Felipe's email id; sorry, I'm having a bad day]
They all look trivial enough, so I'll directly apply to the
integration branches.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel
1 - 100 of 135 matches
Mail list logo
