Some places assumed .git is the GIT_DIR, resulting heads and
tags not showing when it was run like GIT_DIR=. gitk --all.
This is not a contrived example --- I rely on it to verify
my private copy of git.git repository before pushing it out.
Define a single procedure gitdir and use it.
Hi, Junio C Hamano wrote:
The Debian build is not affected because it does not produce
separate git-core and doc-git-core packages[*1*]; probably this
was the reason you did not notice this.
git-core-doc, actually.
Debian does that only if the documentation is substantial. Even then,
Dear diary, on Thu, Jul 28, 2005 at 12:07:07AM CEST, I got a letter
where A Large Angry SCM [EMAIL PROTECTED] told me that...
Junio C Hamano wrote:
While I do not have strong objections to make the build process
go faster, it is somewhat disturbing that the Makefile pieces
maintained in
Hi,
Patches that add new files don't work correctly if git reports them
with the 'A' flag. StGIT claims there are unresolved conflicts. This
patch fixes it.
Signed-off-by: Peter Osterlund [EMAIL PROTECTED]
diff --git a/stgit/git.py b/stgit/git.py
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -274,7
Peter Osterlund [EMAIL PROTECTED] wrote:
Patches that add new files don't work correctly if git reports them
with the 'A' flag. StGIT claims there are unresolved conflicts. This
patch fixes it.
Thanks. Applied (together with the one below).
diff --git a/stgit/git.py b/stgit/git.py
---
git-prune-script still contained that non-portable option.
Signed-off-by: Johannes Schindelin [EMAIL PROTECTED]
---
git-prune-script |2 +-
1 files changed, 1 insertion, 1 deletion
diff --git a/git-prune-script b/git-prune-script
--- a/git-prune-script
+++ b/git-prune-script
@@ -20,6
Test t6002 unnecessarily fails when bc is a bit older than average.
Signed-off-by: Johannes.Schindelin [EMAIL PROTECTED]
---
t/t6002-rev-list-bisect.sh |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
ccea5a568914eafc07caf0c291afe5f962672cd3
diff --git
Hi,
On Thu, 28 Jul 2005, Petr Baudis wrote:
Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
where Johannes Schindelin [EMAIL PROTECTED] told me that...
On Thu, 28 Jul 2005, Petr Baudis wrote:
See above. I would much rather see more flexible git-send-pack. Junio,
Dear diary, on Mon, Jul 25, 2005 at 10:27:36PM CEST, I got a letter
where Junio C Hamano [EMAIL PROTECTED] told me that...
Linus Torvalds [EMAIL PROTECTED] writes:
On Mon, 25 Jul 2005, Junio C Hamano wrote:
I personally do not have preference either way, but am slightly
biased towards
Matthias Urlichs [EMAIL PROTECTED] writes:
However, I *would* segregate gitk into its own Debian package, because
it requires wish et al., which would pull a large chunk of X11 stuff,
which people may not want on their server.
While I agree gitk should not come as part of git package, this
On Thu, Jul 28, 2005 at 07:32:55PM +0200, Johannes Schindelin wrote:
Is it possible that those plans only mean to centralize .git/objects/ and
leave the rest in single repositories? Seems much more sensible to me.
I think that's accurate. It can be done without the repositories even
really
On Thursday 28 July 2005 17:56, Johannes Schindelin wrote:
localhead=remotehead. BTW, this whole multihead mess applies only to Jeffs
anyway :-)
GIT/Cogito usage is not about linux kernel only.
I actually try to work with a scenario for a project with a few developers,
where each one should
Hi, A Large Angry SCM wrote:
So you're arguing for last match wins versus first match wins. I,
personally, find the former more natural and easier to debug by hand.
You know, up until five minutes ago, I thought so too.
However ... as a human being, I liik for meaning, not for processing
Dear diary, on Thu, Jul 28, 2005 at 05:56:21PM CEST, I got a letter
where Johannes Schindelin [EMAIL PROTECTED] told me that...
Hi,
Hello,
On Thu, 28 Jul 2005, Petr Baudis wrote:
Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
where Johannes Schindelin [EMAIL
Dear diary, on Sat, Jul 23, 2005 at 12:27:31PM CEST, I got a letter
where Catalin Marinas [EMAIL PROTECTED] told me that...
Agreed. What Cogito uses:
.git/author Default author information in format
Person Name [EMAIL PROTECTED]
What about
Hi,
On Thu, 28 Jul 2005, Matthias Urlichs wrote:
Hi, Johannes Schindelin wrote:
Since git is better than all of these, we should be able to easily write a
SVN-like porcelain, so ... ;-)
Sorry, you're correct.
IMHO, if you need a central repository, you should also have
one central
In the tutorial the user is instructed to create two files: a and b.
Then when the user diffs the files, they see this:
diff --git a/a b/a
That really confused somebody and I had to untangle their brain. :-) I
don't have a patch for it, but thought I'd point out: perhaps a and b
aren't the best
Junio,
I just ran git clone against the mainline git repository using both http
and rsync. http was still quite slow compared to rsync. I expected that
the http time would be much faster than in the past due to the pack
file.
Is there something simple I'm missing?
--
Darrin
-
To unsubscribe
Hi, Petr Baudis wrote:
If you fear making mistakes, better use something which attempts to do
some babysitting for you, like Cogito. ;-)
Some babysitting needs to be part of the core push protocol; anything else
would be prone to race conditions in a multiuser setting, esp. when people
use
I have verified that successful close() after failed mmap() won't reset
the output of perror() to Success.
Does $standard guarantee that?
In general, successful libc calls can set errno to whatever they
please, except zero. And they sometimes do. This follows from
C99.
Morten
-
To
On Thu, 28 Jul 2005, Morten Welinder wrote:
I have verified that successful close() after failed mmap() won't reset
the output of perror() to Success.
Does $standard guarantee that?
In general, successful libc calls can set errno to whatever they
please, except zero. And they
Linux 2.6 tree has one of those tree tags.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
server-info.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
42fa3ca33f92381a73c08ab98dc4b54e6a6412cc
diff --git a/server-info.c b/server-info.c
--- a/server-info.c
+++
Johannes Schindelin [EMAIL PROTECTED] writes:
On older Mac OS X (10.2.8), no socklen_t is defined, and therefore
daemon.c does not compile. However, Mac OS X 10.4 seems to define
socklen_t differently.
Also, linking fails due to some symbols defined in libssl (not just
libcrypto).
Hmph.
Johannes Schindelin [EMAIL PROTECTED] writes:
Some newer features of libcurl are used which are not strictly necessary
for http-pull. Use them only if libcurl is new enough to know about them.
Do you need to check against that many versions? Especially
cleanup and init not depending on the
Petr Baudis [EMAIL PROTECTED] writes:
The committer field generally identifies the committer physically, and
isn't usually overriden. You'll find [EMAIL PROTECTED] in my
committer field, e.g.
I do not want to get involved in policy decisions, but for the
record I always hated your commit log
Darrin Thompson [EMAIL PROTECTED] writes:
I just ran git clone against the mainline git repository using both http
and rsync. http was still quite slow compared to rsync. I expected that
the http time would be much faster than in the past due to the pack
file.
Is there something simple I'm
While I agree there should be a graceful way to go back to the
original head from a failed merge situation, I do not think
committing the current HEAD is the right model for the end
user to think about it.
Wouldn't using checkout -f to revert to the version you would
want to go back work as
On Thu, 28 Jul 2005, Junio C Hamano wrote:
I do not want to get involved in policy decisions, but for the
record I always hated your commit log for that identifies the
committer physically approach.
Well, I have to say that I find it quite useful myself. I try to commit
x86 patches to the
Darrin Thompson [EMAIL PROTECTED] writes:
In the tutorial the user is instructed to create two files: a and b.
Then when the user diffs the files, they see this:
diff --git a/a b/a
That really confused somebody and I had to untangle their brain. :-)
Yes I was confused when I read it for
29 matches
Mail list logo