Frank Sorenson <[EMAIL PROTECTED]> writes:
> Is this something we want to consider, or am I out in left field? :)
I do not think so. You just more clearly and explicitly stated
what I wanted to see; we share the same vision of the ideal
world.
I do however think your sights are probably focused
On Mon, Jul 18, 2005 at 04:43:32PM -0400, Bryan Larsen wrote:
> Hi gitsters,
>
> I'm currently living in Ottawa, and will be attending OLS. I would like
> to meet people involved with git. I can offer my house (walking
> distance from OLS), my BBQ, my beer or my recommendations on good
> rest
A bit more usability enhancement related to the recent URL
short-hand support in .git/branches, while retaining Cogito
compatibility.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
git-clone-script | 41 +++--
1 files changed, 23 insertions(+), 18 del
Update the recommended workflow for individual developers.
While they are tracking the origin, refs/heads/origin is updated
by "git fetch", so there is no need to manually copy FETCH_HEAD
to refs/heads/ anywhere.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Documentation/tutorial.txt |
Catalin Marinas <[EMAIL PROTECTED]> writes:
> I don't see git going towards stgit at all. Indeed, it gets closer to
> cogito but I still like cogito over plain git since it's easier to use
> (my goal, though, is to add pull/clone commands to stgit so that one
> doesn't need to rely on directly usi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Junio C Hamano wrote:
> Catalin Marinas <[EMAIL PROTECTED]> writes:
>
>>I don't see git going towards stgit at all. Indeed, it gets closer to
>>cogito but I still like cogito over plain git since it's easier to use
>>(my goal, though, is to add pull/c
Junio C Hamano wrote:
I fully agree that supporting C-level linkage is worthy, and
should be one of our longer term goals.
Excellent.
A similar 1.0 goal would be to document porcelain's use of the .git
directory. For instance, stacked git uses .git/patches,
.git/patchdescr.tmpl and .git/p
> I certainly don't think the lib interface is anywhere near stable:
> Linus accepted my change to index_fd far too easily.
Noted, thanks for the info.
(This makes a lot of sense, Git is evolving very fast. I haven't
looked at Git since mid-April, and I'm very much impressed at the
difference be
Bryan Larsen <[EMAIL PROTECTED]> writes:
> ... Darcs and git work together to determine the minimal amount
> that needs to go into libgit1.so. It gets blessed by being
> documented, and doesn't change until libgit2.so.
>
> I'd like to see this added to Junio's list of "1.0" goals.
I should menti
Hi gitsters,
I'm currently living in Ottawa, and will be attending OLS. I would like
to meet people involved with git. I can offer my house (walking
distance from OLS), my BBQ, my beer or my recommendations on good
restaurants to facilitate an informal BOF.
Bryan
-
To unsubscribe from this
The git-rev-parse command uses LF to separate each arguments it
parses, so its users at least need to set IFS to LF to be able
to handle filenames with embedded SPs and TABs. Some commands,
however, can take and do expect arguments with embedded LF
(notably, -Spickaxe of diff family), so even this
Darcs and git work together to determine the minimal amount
that needs to go into libgit1.so.
Hold on... Nobody is speaking about *binary* compatibility, it's
source-level compatibility that we need. There is absolutely no
reason to introduce the complexities of shared libraries into the
pi
Can you please test if this patch fixes it?
-Andi
Don't compare linux processor index with APICID
Fixes boot up lockups on some machines where CPU apic ids
don't start with 0
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/arch/x86_64/kernel/smpboot.c
=
On Saturday 25 June 2005 02:20, Linus Torvalds wrote:
> On Wed, 22 Jun 2005, Alexander Y. Fomichev wrote:
> > I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8
> > GHz [ MoBo: Intel E7520, intel 82801 ]
> > but kernel hangs on boot right after records:
> >
> > Booting processor
Bryan Larsen <[EMAIL PROTECTED]> wrote:
> Any lack of porcelain momentum is probably due to git having better
> documentation than the current porcelains, such as cogito and stacked
> git. The documentation, like tutorial.txt and Jeff Garzik's git
> kernel howto give the impression that most kerne
Alexey Nezhdanov <[EMAIL PROTECTED]> writes:
> But this should not be user's problem - it's just the UI that doesn't
> understands when transcoding should be done.
I disagree.
Yes, while you _could_ do something like this to feed text in
local encoding to the VISUAL/EDITOR, and convert it back
16 matches
Mail list logo
