Sunday 12 August 2005 04:13 Petr Baudis wrote:
> Hello,
>
> is anyone actually using the git daemon in practice, now that the
> other transfer methods can deal with packs? I ask since I wonder if I
> should actually bother with adding support for it to cg-pull.
Sorry for the very late answer -
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 resolving the parents of four commits Fredrik Kuivinen gave
u
On 9/6/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Grepping for strings.
>
> For example, when renaming a binary, the sane way to check that you fixed
> all users right now is
>
> grep old-binary-name *.c *.h *-scripts
>
> and you catch all users.
Grep knows how to ignore binary fil
Hi,
attached are two patches:
the first fixes some build issues on solaris10/x86 with sunpro (and some
that also happen with gcc), while the second adds a simple way to add
additional search and link paths for curl library and headers.
patrick mauritz
(not on the list, please Cc:)
diff -ur git-c
Hi Junio!
On Mon, Sep 05, 2005 at 12:01:40PM -0700, Junio C Hamano wrote:
> Zack Brown <[EMAIL PROTECTED]> writes:
>
> > It would be great if tags also allowed a brief description to go along with
> > them, that would show up in cg-tag-ls. Then I could seek to a tag that's
> > just
> > an easy-t
Martin Langhoff <[EMAIL PROTECTED]> writes:
> It shows that I was never familiar with the practices of linux
> hackers. I've always read the references to mboxes holding patchbombs
> meaning literally one mbox file with a zillion contatenated patches
> received via email.
To be fair to you, it is
On 9/6/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> Not really; --mbox output is one-file-per-patch and it is up to
> you which ones to pick and concatenate them in what order, if you
> want them in a single file.
Hr. Then I better hide away in a little cave, and shut my big mouth up. ;-)
Martin Langhoff <[EMAIL PROTECTED]> writes:
> Fair enough -- blame it on my primitive approach of only having 2
> working repositories, and having some patches in them that I'm not
> pushing upstream. Exporting to mbox would mean that I have to edit the
> mbox file to remove the patches I don't in
On 9/6/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> Ryan Anderson <[EMAIL PROTECTED]> writes:
> > Sorry about that - I always export using git-format-patch using --mbox,
> > and those work nicely. I'm a bit reluctant to do the [PATCH] fixup, but
> > I think I will:
Thanks Ryan for the clarific
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 there any good reason why somebody would want to have CDPATH
in his environment
Zack Brown <[EMAIL PROTECTED]> writes:
> It would be great if tags also allowed a brief description to go along with
> them, that would show up in cg-tag-ls. Then I could seek to a tag that's just
> an easy-to-type version number, and still have an idea of what's significant
> about that version b
Hi folks,
I've been using git on my new projects, and loving it!
When I use tags, I typically will use a name like "0.3_basic_description"
and "0.4_full_outline", because I want to know not only what version number I'm
considering, but also the reason why I chose to tag that particular version.
Ryan Anderson <[EMAIL PROTECTED]> writes:
> On Mon, Sep 05, 2005 at 11:16:57PM +1200, Martin Langhoff wrote:
>>
>> - reads "subject" from the first line of STDIN or file. If the line
>> doesn't start with [PATCH it provides the [PATCH] prefix. I found it
>> really confusing that it wants to get
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> One question, of course, is if one should simply keep additional
> metadata around to handle this sort of situations. One could, for
> example, keep a UUID for each file,...
If I am not mistaken, that is exactly what tla does. It seems
to work we
Junio C Hamano wrote:
But previous argument by Linus made in a distant (in git
timescale) past is now ingrained in my brain: "the additional
metadata" recorded at the commit time can only help us what we
envisioned in the past when the tool to record that metadata was
written. If we try to "tra
This script simply reports the version of git you have installed.
Signed-off-by: Martin Atukunda <[EMAIL PROTECTED]>
---
Documentation/git-version-script.txt | 36 ++
Makefile |9 +++--
git-version-script.in|
David K.ANegedal <[EMAIL PROTECTED]> writes:
> If the "-script" part is supposed to be hidden from me, why do I keep
> seeing it everywhere I turn?
>
>> So to users it doesn't matter, and to developers it _does_ matter (and
>> calling them ".pl" or ".sh" or something would be _bad_), why not pl
Linus Torvalds <[EMAIL PROTECTED]> writes:
> ... and I don't see _any_ point to naming
> by what _kind_ of interpreter you use. Why would _anybody_ care whether
> something is written in perl vs shell?
One possibility that comes to mind is to again help developers
who use an editor that is synt
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Of course, if you don't push it back, but keep the two trees separate and
> keep on modifying files that have different names in the other repository,
> you'll keep on getting into the situation that the trivial merge doesn't
> work. So we _do_ want
The following is the list of files in the Documentation directory that
have *NO* useful text in them at all.
git-build-rev-cache.txt
git-checkout-script.txt
git-diff-script.txt
git-format-patch-script.txt
git-get-tar-commit-id.txt
git-reset-script.
Linus Torvalds wrote:
It's a totally broken model. Really.
You think it solves issues, but it just creates more bugs and problems
than it solves.
Trust me. The whole point of git is that "content is the only thing that
matters", and that there isn't any other meta-data. If you break that
f
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 5 Sep 2005, David Kågedal wrote:
>>
>> But to the users (like myself), there's no point in naming it by
>> whether it's a script or a binary.
>
> So? There's no downside.
>
> To you, as a user, you never see the "-script" ending anyway. You'd
On Mon, 5 Sep 2005, David Kågedal wrote:
>
> But to the users (like myself), there's no point in naming it by
> whether it's a script or a binary.
So? There's no downside.
To you, as a user, you never see the "-script" ending anyway. You'd never
type it out, or you're already doing something
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.
> Author: Russell King <[EMAIL PROTECTED]>
> Date: Wed Aug 31 10:12:14 2005 +0100
I suspect rmk is using cogito-0.13, an
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, which I
> guess might be nice to have in the user
On Mon, 5 Sep 2005, H. Peter Anvin wrote:
>
> It would also hade the somewhat interesting possibility that one could
> "remove and recreate" a file and have it exist as a different entity.
> That probably needs to be a user option.
It's a totally broken model. Really.
You think it solves iss
On Mon, Sep 05, 2005 at 11:16:57PM +1200, Martin Langhoff wrote:
> Ryan,
>
> is it possible to fix the git-send-email script to "just work" reading
> in the emails that `git-format-patch-script -o patchdir origin`
> generates? I have a very ugly local patch to git-send-email-script
> that
>
> -
Junio C Hamano wrote:
1
/ \
0-2-3-5-7
\ /
4-6
It shouldn't matter to the merge at 7 if the 2-3 reorganization was done
locally, by applying a patch, or by merging.
There was another problem in my message that treated #3
specially. I did it that way primarily because I wanted to ha
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sun, 4 Sep 2005, Horst von Brand wrote:
>> > I had the same opinion. The counter-argument people raised when
>> > this topic came up on the list was that it would help grepping
>> > in the source tree.
>>
>> Grepping for what?
>
> Grepping for stri
This script simply reports the version of git you have installed.
Signed-off-by: Martin Atukunda <[EMAIL PROTECTED]>
---
Documentation/git-version-script.txt | 36 ++
Makefile |9 +++--
git-version-script.in|
On Sun, 4 Sep 2005, Horst von Brand wrote:
> > I had the same opinion. The counter-argument people raised when
> > this topic came up on the list was that it would help grepping
> > in the source tree.
>
> Grepping for what?
Grepping for strings.
For example, when renaming a binary, the sane
A recent commit in linux-2.6 looks like this:
commit b129a8ccd53f74c43e4c83c8e0031a4990040830
Merge: 6b39374a27eb4be7e9d82145ae270ba02ea90dc8
194d0710e1a7fe92dcf860ddd31fded8c3103b7a
Author: Russell King <[EMAIL PROTECTED]>
Date: Wed Aug 31 10:12:14 2005 +0100
[SERIAL] Clean up and fix tty
Ryan,
is it possible to fix the git-send-email script to "just work" reading
in the emails that `git-format-patch-script -o patchdir origin`
generates? I have a very ugly local patch to git-send-email-script
that
- reads "from" from git-var, can be overridden by passing an explicit --from
- rea
33 matches
Mail list logo
