Thanks, applied.
-
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
Mark Allen <[EMAIL PROTECTED]> writes:
> This trivial patch creates $(LIBS) and sets it to iconv in
> tools/Makefile because MacOS 10.4 [gcc 4.0] gets cranky about
> libiconv routines referenced in mailinfo.c (convert_to_utf8)
> and no library pointer to link the symbols against.
I'd do this slig
[PATCH] Add $(LIBS) and set libiconv in tools/Makefile for Darwin
This trivial patch creates $(LIBS) and sets it to iconv in tools/Makefile
because MacOS
10.4 [gcc 4.0] gets cranky about libiconv routines referenced in mailinfo.c
(convert_to_utf8) and no library pointer to link the symbols again
Martin Langhoff wrote:
On 9/7/05, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
This patch changes git-cvsimport-script so that it creates tag objects
instead of refs to commits, and adds an option, -u, to convert
underscores in branch and tag names to dots (since CVS doesn't allow
dots in branches
On 9/7/05, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> This patch changes git-cvsimport-script so that it creates tag objects
> instead of refs to commits, and adds an option, -u, to convert
> underscores in branch and tag names to dots (since CVS doesn't allow
> dots in branches and tags.)
looks
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> H. Peter Anvin wrote:
>>>
> OK, now later in the day I could not reproduce this on another box.
> Either the situation was different enough, or I did something else wrong.
One thing that comes to mind, which may or may not be relevant
to your situat
H. Peter Anvin wrote:
So, C surely has its head updated? Does cg-update "fail" silently, or
does it utter anything?
C has its head updated, yes. cg-update says "Branches already fully
merged."
OK, now later in the day I could not reproduce this on another box.
Either the situation was d
Robert Fitzsimons <[EMAIL PROTECTED]> writes:
> No problem I know it's a controversial change.
Not really controversial anymore, as long as --ignore-applied is
used only when appropriate.
>>> Yes my change has a bug with a copy patch which modifies the same file.
> I'll send on a fix now.
Here
> By the way, I'm not sure how the 'git' script is supposed to be used.
> I know that if there is a git-foo-script file in your path, you can
> run it as 'git foo'. But what about e.g. git-init-db? You can run
> that as 'git init-db' today. And 'git read-cache' should work too.
> And 'git ls-fil
Petr Baudis wrote:
Dear diary, on Tue, Sep 06, 2005 at 11:01:25PM CEST, I got a letter
where "H. Peter Anvin" <[EMAIL PROTECTED]> told me that...
I just found a bug in cogito-0.13, at least to the best of my
understanding of the situation.
Simplified, the problem looks like this: two sides, A
Martin Langhoff wrote:
My style has always be to use tags for merges; tag the origin branch as
well as before and after on the receiving branch.
Do you move the tags with cvs tag -F? If that's the case, the data you
need to merge is lost... otherwise, you could hack an alternative
merge detec
Dear diary, on Tue, Sep 06, 2005 at 11:01:25PM CEST, I got a letter
where "H. Peter Anvin" <[EMAIL PROTECTED]> told me that...
> I just found a bug in cogito-0.13, at least to the best of my
> understanding of the situation.
>
> Simplified, the problem looks like this: two sides, A and B, pull fr
On 9/7/05, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Martin Langhoff wrote:
> >
> > Tell me more about how you are trying the 'recognize merge'. It is a
> > pretty unsophisticated thing, as it trusts the commit message in the
> > first place. But when it works, it works.
> >
>
> Perhaps it would
On Tue, 6 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > Good. (Although that patch doesn't seem to be directly on top of my
> > version; I can tell what it's doing anyway)
>
> That one was against the proposed updates head. I've updated it
> again to inclu
"Luck, Tony" <[EMAIL PROTECTED]> writes:
> This is valid (I really did make all those commits, they happen every
> time I merge the "linus" branch into my release branch, which I like to
> do quite often so I'm working near the bleeding edge), but it doesn't
> seem all that useful in the "short" l
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> Good. (Although that patch doesn't seem to be directly on top of my
> version; I can tell what it's doing anyway)
That one was against the proposed updates head. I've updated it
again to include the patch.
> I'm happy with the content in "pu"; the
Looking at the shortlog information for 2.6.13 there are a lot (eleven)
of changes attributed to me that look like:
Auto merge with /home/aegl/GIT/linus
This is valid (I really did make all those commits, they happen every
time I merge the "linus" branch into my release branch, which I like to
Martin Langhoff wrote:
Tell me more about how you are trying the 'recognize merge'. It is a
pretty unsophisticated thing, as it trusts the commit message in the
first place. But when it works, it works.
Perhaps it would be good to know what it expects in the commit message?
My style has alwa
On 9/7/05, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> > I should probably point out that there are still bugs in
> > git-cvsimport-script; for one thing, it seems to fail to register a tag
> > associated with the head, and I have yet to get the "recognize merge"
> > feature to actually work. It's
Jeff Carr <[EMAIL PROTECTED]> writes:
> ... If I remember
> correctly, there was some threads at the beginning of git about how
> datestamps were not accurate so there was no point in setting them(?) Or
> maybe I mis-understood.
The point of those thread was that clocks on machines tend to be
not
I just found a bug in cogito-0.13, at least to the best of my
understanding of the situation.
Simplified, the problem looks like this: two sides, A and B, pull from
repository C. The head of this pull we call 0.
Now commit 1 is added to A. B pulls commit 1 from A, not though C.
Later, A pu
On 08/22/2005 10:15 PM, Junio C Hamano wrote:
> Jeff Carr <[EMAIL PROTECTED]> writes:
>
>
>>Something simple like the perl script at the bottom would be useful for
>>showing files that haven't been added via git-update-cache --add already.
>
>
> If I am not mistaken, you just reinvented:
>
>
H. Peter Anvin wrote:
H. Peter Anvin wrote:
This patch changes git-cvsimport-script so that it creates tag objects
instead of refs to commits, and adds an option, -u, to convert
underscores in branch and tag names to dots (since CVS doesn't allow
dots in branches and tags.)
Pullable tree at
On Tue, 6 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > Do you know if there's anything like case #16 in there? I'd be interested
> > to know if there's anything that gets handled automatically in different
> > ways depending on which single base is used, a
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> Do you know if there's anything like case #16 in there? I'd be interested
> to know if there's anything that gets handled automatically in different
> ways depending on which single base is used, and doesn't require manual
> intervention with multip
On Mon, 5 Sep 2005, Linus Torvalds wrote:
> On Mon, 5 Sep 2005, Fredrik Kuivinen wrote:
> >
> > After a quick look through the diff source I didn't find anything
> > else. It's quite possible that I haved missed something though. Most
> > of the translated messages are related to error reporting,
Signed-off-by: Rene Scharfe <[EMAIL PROTECTED]>
---
Documentation/git-get-tar-commit-id.txt | 23 +++
get-tar-commit-id.c |3 +++
2 files changed, 14 insertions(+), 12 deletions(-)
5144a0393d17d721c83a42ce743d2ce46909f222
diff --git a/Documentation/
On 08/22/2005 11:48 PM, Johannes Schindelin wrote:
>
>>patch:
>
> "git diff"
>
>
>>push:
>
> "git push origin" (or maybe "git push HEAD:origin")
>
>
>>pull:
>
> "git pull origin"
>
>
>>commit:
>> vi changelog.txt
>> GIT_AUTHOR_NAME="$(GIT_AUTHOR_NAME)" \
>> GIT_AUTHOR_EMAIL
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> This patch changes git-cvsimport-script so that it creates tag objects
> instead of refs to commits, and adds an option, -u, to convert
> underscores in branch and tag names to dots (since CVS doesn't allow
> dots in branches and tags.)
Looks good
H. Peter Anvin wrote:
This patch changes git-cvsimport-script so that it creates tag objects
instead of refs to commits, and adds an option, -u, to convert
underscores in branch and tag names to dots (since CVS doesn't allow
dots in branches and tags.)
Pullable tree at master.kernel.org:/home
On Mon, 5 Sep 2005, Linus Torvalds wrote:
> On Mon, 5 Sep 2005, Wayne Scott wrote:
> >
> > A recent commit in linux-2.6 looks like this:
>
> It hopefully shouldn't happen any more with the improved and fixed
> git-merge-base.
Couldn't it also happen if there's stale data in MERGE_HEAD when you
On Mon, 5 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > I've got a version of read-tree which accepts multiple ancestors and does
> > a merge using information from all of them.
>
> After disabling the debugging printf(), I used this read-tree to
> try reso
This patch changes git-cvsimport-script so that it creates tag objects
instead of refs to commits, and adds an option, -u, to convert
underscores in branch and tag names to dots (since CVS doesn't allow
dots in branches and tags.)
Pullable tree at master.kernel.org:/home/hpa/git/cvsimport.git/
Horst von Brand wrote:
Junio C Hamano <[EMAIL PROTECTED]> wrote:
Tim Ottinger <[EMAIL PROTECTED]> writes:
git-update-cache for instance?
I am not sure which 'cache' commands need to be 'index' now.
Logically you are right, but I suspect that may not fly well in practice. Too
On Mon, Sep 05, 2005 at 12:37:58PM -0700, Junio C Hamano wrote:
> Carl Baldwin <[EMAIL PROTECTED]> writes:
>
> > The function get_repo_base seems to break with this CDPATH.
>
> Sorry, your message somehow slipped my filtering. Thanks for
> the analysis. Of course, CDPATH would break it.
>
> Is
Santi Béjar wrote:
[...]
One thing I'm missing is a way to describe a branch. It can be
done in the $GIT_DIR/description, the first line for the whole
repository and the rest for the branches. So description file
for the git.git repository could be:
[description]
On 9/5/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > Really 'git commit' should detect problems like this automatically and
> > prevent them from getting in the tree.
>
> Well, that would depend on having the fixed git-merge-base in the first
> place, which in turn would mean that such a commi
Junio C Hamano <[EMAIL PROTECTED]> writes:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
>> What's the upside?
>>
>> I can point to one downside: "git". That script right now is simple. If
>> you rewrite git-cvsimport-script from shell to perl, it looks the same to
>> git.
>
> What I've been w
Linus Torvalds <[EMAIL PROTECTED]> writes:
> What's the upside?
>
> I can point to one downside: "git". That script right now is simple. If
> you rewrite git-cvsimport-script from shell to perl, it looks the same to
> git.
What I've been working on was to:
* have git-cvsimport.perl in the so
On Tue, 6 Sep 2005, Junio C Hamano wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > The point is, naming things as being "scripts" is useful. Grep is just an
> > example. Naming things as being ".pl" or ".sh" is _not_ useful.
>
> Sorry, but why not?
What's the upside?
I can point t
On 9/6/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> That wasn't the _point_.
Agreed - sorry I should have qualified my comment.
I agree with having useful extensions for ease of development. And I
agree with the suggestion of installing them with stripped extensions
-- to extend the abstractio
Linus Torvalds <[EMAIL PROTECTED]> writes:
> The point is, naming things as being "scripts" is useful. Grep is just an
> example. Naming things as being ".pl" or ".sh" is _not_ useful.
Sorry, but why not?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message
On Tue, 6 Sep 2005, Martin Langhoff wrote:
>
> Grep knows how to ignore binary files.
That wasn't the _point_.
The point is, naming things as being "scripts" is useful. Grep is just an
example. Naming things as being ".pl" or ".sh" is _not_ useful.
So with grep you can use -I, but what about
43 matches
Mail list logo
