On Wed, Jul 27, 2005 at 02:50:55PM -0700, Junio C Hamano wrote:
> Ryan Anderson <[EMAIL PROTECTED]> writes:
>
> > 003afd3ed1f83b4533b628182fa16c9ab0dc0467
> > diff --git a/Documentation/Makefile.inc b/Documentation/Makefile.inc
> > new file mode 100644
> > --- /dev/null
> > +++ b/Documentation/Mak
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
Petr Baudis <[EMAIL PROTECTED]> writes:
> You generally don't say "I never want this ignored, but I want
> the rest of that ignored", but "I want that ignored, except
> this".
OK.
> But more importantly,
>
> .gitignore: *.txt
> Documentation/.gitignore: !*.txt
>
> will not work, whic
When git-apply was printing out long filenames, it used to just truncate
them to show the last "max_len" characters of the filename. Which can be
really quite ugly (note the two filenames that have just been silently
truncated from the beginning - it looks even worse when there are lots
of them,
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
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 ex
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 simp
Petr Baudis <[EMAIL PROTECTED]> writes:
> One of the Cogito design bits is that branch name is something local to
> the repository. When you are adding a branch, the local name you assign
> it is your private thing repository-wise, and doesn't have to have any
> correlation to other repositories y
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 com
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).
H
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
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
+++ b/
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
> 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 unsubs
Hello!
I have reviewed all occurrences of mmap() in git and fixed three types
of errors/defects:
1) The result is not checked.
2) The file descriptor is closed if mmap() succeeds, but not when it
fails.
3) Various casts applied to -1 are used instead of MAP_FAILED, which is
specifically defined t
On Thu, 2005-07-28 at 15:20 -0500, Darrin Thompson wrote:
> 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
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 di
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 fr
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
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 centr
Hi, Johannes Schindelin wrote:
> Are you really sure you want to slave git into being a "better
> Subversion"?
Since git is better than all of these, we should be able to easily write a
SVN-like porcelain, so ... ;-)
> IMHO, if you need a central repository, you should also have
> one central HE
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 abo
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
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 processin
Dear diary, on Thu, Jul 28, 2005 at 08:53:56PM CEST, I got a letter
where Josef Weidendorfer <[EMAIL PROTECTED]> told me that...
> So why not put the name of the remote repository into the local branch name?
> A remote branch "host1:path#branch1" could be named "host1:path#branch1".
> The shorthand
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 h
Hi,
On Thu, 28 Jul 2005, Ryan Anderson wrote:
> 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
Hi,
On Thu, 28 Jul 2005, Petr Baudis wrote:
> For that particular thing, this is only part of the motivation. The much
> bigger part of the motivation are projects which don't have a central
> maintainer but where group of people needs to be equal in access to a
> central repository. That's actua
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 no
Dear diary, on Thu, Jul 28, 2005 at 06:52:45PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Petr Baudis <[EMAIL PROTECTED]> writes:
>
> > AFAIK the plan is to centralize all the kernel repositories to a single
> > one. For that, developers would generally push in
Hi,
On Thu, 28 Jul 2005, Junio C Hamano wrote:
> Petr Baudis <[EMAIL PROTECTED]> writes:
>
> > AFAIK the plan is to centralize all the kernel repositories to a single
> > one. For that, developers would generally push into branches with name
> > different that "master".
>
> I did not know about t
Junio C Hamano wrote:
...
While I agree gitk should not come as part of git package, this
brings up a different issue.
Ideally, I'd want to see gitk packaged from its repository
kernel.org:/pub/scm/gitk/git.git/ Paul Mackerras maintains, not
from GIT one which _will_ lag behind.
...
While I
Petr Baudis <[EMAIL PROTECTED]> writes:
> AFAIK the plan is to centralize all the kernel repositories to a single
> one. For that, developers would generally push into branches with name
> different that "master".
I did not know about that plan, but that is interesting and now
I understand why yo
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, thi
Dear diary, on Thu, Jul 28, 2005 at 06:14:17PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> My gut feeling is that Johannes is right here, at least about
> the send-pack side. Storing "master" pulled from a remote under
> a name different from the remote is a dif
Petr Baudis <[EMAIL PROTECTED]> writes:
> Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
> where Johannes Schindelin <[EMAIL PROTECTED]> told me that...
>> IMHO this opens the door for shooting in your own foot. Isn't it much too
>> easy to make a mistake with that syntax?
>
>
Petr Baudis wrote:
I think this is wrong, and my brief experiments confirm that. I think
that the actually useful semantics of exclusion would be for
_subsequent_ exclusions, not preliminary ones. You generally don't say
"I never want this ignored, but I want the rest of that ignored", but
"I w
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
> >>
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.
Hello,
after skimming through it, I think I completely like what you have
shown here. I'm only concerned about this:
Dear diary, on Mon, Jul 25, 2005 at 12:49:33AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> $ cat Documentation/.gitignore
> # ignore
Dear diary, on Thu, Jul 28, 2005 at 02:08:07PM CEST, I got a letter
where Petr Baudis <[EMAIL PROTECTED]> told me that...
> See above. I would much rather see more flexible git-send-pack. Junio,
> what about changing its [heads]* parameter e.g. to
> [remotehead[:localhead]]* ?
Ok, I was thinking b
Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
where Johannes Schindelin <[EMAIL PROTECTED]> told me that...
> Hi,
Hello,
> On Thu, 28 Jul 2005, Petr Baudis wrote:
>
> > See above. I would much rather see more flexible git-send-pack. Junio,
> > what about changing its [heads
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).
Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---
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.
Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---
http-pull.c |6 ++
1 files changed, 6 insertions
diff --git a/http-pull.c b/htt
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 a/t/t6002-rev-list-bi
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 +2
Sometimes a failed automatic merge means that we do not want those
changes. In this case, it is desirable to commit the current HEAD (as if
actually something was merged).
Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---
git-commit-script |8 ++--
1 files changed, 6 insertion
Hi,
On Thu, 28 Jul 2005, Petr Baudis wrote:
> See above. I would much rather see more flexible git-send-pack. Junio,
> what about changing its [heads]* parameter e.g. to
> [remotehead[:localhead]]* ?
IMHO this opens the door for shooting in your own foot. Isn't it much too
easy to make a mistake
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
--- a/s
Dear diary, on Wed, Jul 27, 2005 at 02:58:42PM CEST, I got a letter
where Josef Weidendorfer <[EMAIL PROTECTED]> told me that...
> Hi,
Hello,
> if I clone a remote head other than master via Cogito with
>
> cg-clone host:path#remoteHead,
>
> work on this branch, and try to push back my ch
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
Hi, Petr Baudis wrote:
> having all the targets for all the subdirectories in a
> single file sounds nightmarish
which is why you'd include Makefile[.inc] snippets from subdirectories
instead.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was
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 i
Dear diary, on Thu, Jul 28, 2005 at 01:08:03AM CEST, I got a letter
where Brian O'Mahoney <[EMAIL PROTECTED]> told me that...
> First, congratulations Junio, on taking over this stuff, and all the best.
>
> Second, the killer argument, in the 'Recursive Make ... harmful' is the
> basic one that Re
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,
manpa
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.
Signed-
Ryan, I am dropping this patch, at least for now, after keeping
it in the "pu" (proposed updates) branch and using it myself.
There are two complaints from me.
I am used to "make bin=$HOME/bin/i386 install install-tools",
which the patch breaks (I do not want to build docs for myself).
This is min
57 matches
Mail list logo
