I have several requests to people who are interested in merges
and read-tree changes.
I am pretty much set to use the recent read-tree updates Daniel
has been working on. The only reason it has not hit the
"master" branch yet, except that it still has known leaks that
have not been plugged, is be
Using git-core-0.99.6 I tried to locate a bug using git's bisection
searching.
It gave the wrong answer. It ended up claiming the bug was in
tree ea7b1763aa0e0d36b52fa245449c79338fe735b3
parent e9f86e351fda5b3c40192fc3990453613f160779
author Zachary Amsden <[EMAIL PROTECTED]> Sun, 04 Sep 2005
Thanks for the note. If somebody else does not get around to it
before me, I'll take a look later today after work.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Junio C Hamano <[EMAIL PROTECTED]> writes:
> The "master" branch post 0.99.6 already has the renamed tools
> with backward compatibility symlinks. I'll be sending a
> patch to address an issue raised by some people separately to
> see what the list thinks, and also will attempt to send out a
> pa
Junio C Hamano <[EMAIL PROTECTED]> writes:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
>> I'd still like to revive my idea of having projects overlaid on each
>> other, where the commits in the project that absorbed the other project
>> say, essentially, "also include this other commit, but an
There was a lingering reference to the git-*-scripts in
the tutorial. This patch reworks that paragraph a bit.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
---
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.
Junio C Hamano wrote:
A Large Angry SCM <[EMAIL PROTECTED]> writes:
Junio C Hamano wrote:
A Large Angry SCM <[EMAIL PROTECTED]> writes:
Naming and Directory Structure
--
Annotations are named by appending ".txt" to the basename of the
repository component it descr
The good news:
There is now some usable documentation for all the git commands except
for the following:
git-archimport (Martin?)
gitk(Paul?)
The bad news:
Some, if not most, of the command documentation is incomplete or
possibly incorrect. Mostly it's a case o
Fix a minor typo in the tutorial.txt.
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
---
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -742,7 +742,7 @@ git commit -m 'Some work.' hello
--
On Fri, 9 Sep 2005, Junio C Hamano wrote:
> I have several requests to people who are interested in merges
> and read-tree changes.
>
> I am pretty much set to use the recent read-tree updates Daniel
> has been working on. The only reason it has not hit the
> "master" branch yet, except that it
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> I'd actually been thinking it would just go into the the "resolve" driver,
> with that going back to before it chose among merge-base outputs and just
> sending the whole list to read-tree.
>
> This is no good: the current 'resolve' can generate wron
Thanks. Will apply both.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Sep 08, 2005 at 05:58:18PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 8 Sep 2005, Greg KH wrote:
> >
> > Or am I missing some option to 'git applymbox' that I can't seem to
> > find?
>
> No. git-apply wants an exact bit-for-bit match. Partly because fuzz is
> hard, but mostly because I
On Fri, 9 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > It tries to make sure that there is room to put stuff for resolving a
> > conflict without messing with modified files in the directory.
>
> I agree it can be used that way, but nobody seems to use it
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> In case #16, I'm not sure what I should produce. I think the best thing
> might be to not leave anything in stage 1. The desired end effect is that
> the user is given a file with a section like:
>
> {
> *t = NULL;
> *m = 0;
>
>
Remove duplicate git-send-email-perl target in Makefile.
When WITH_SEND_EMAIL was defined, as in the Debian 'deb' target,
git-send-email-perl was added twice to SCRIPT_PERL, leading to a
duplicate definition in the Makefile. Creating a ".deb" then failed.
Signed-off-by: Marco Roeland <[EMAIL PROT
Thanks for noticing. Will apply.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 9 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > In case #16, I'm not sure what I should produce. I think the best thing
> > might be to not leave anything in stage 1. The desired end effect is that
> > the user is given a file with a section like:
>
And Patrick Mauritz writes:
-
- --- git-core-0.99.5.orig/convert-cache.c Wed Aug 17 09:55:00 2005
- +++ git-core-0.99.5/convert-cache.c Wed Aug 17 09:58:48 2005
- @@ -1,4 +1,5 @@
- #define _XOPEN_SOURCE /* glibc2 needs this */
- +#define __EXTENSIONS__ /* solaris needs this */
To be h
19 matches
Mail list logo
