Hi, Junio C Hamano wrote:
> I do not have preference either way, and I've already merged
> them, but why char[] not char*?
A char* is a variable which points to the char[].
That's four (or eight) bytes we don't need. ;-)
C conflates the two concepts somewhat, which is one of the reasons
optimizi
I've been missing for a couple of weeks due to my server dying and needing
to be replaced; I think stuff is mostly back in order now. (But I'm not
yet resubscribed, and I suspect only dumb mailers are currently willing
to talk to my mail server, for some reason I don't yet understand; I'm
sort
Linus Torvalds <[EMAIL PROTECTED]> writes:
> This doesn't work at least in the form that Junio merged it (and from
> what I can tell, he merged your patch as-is):
>
> [EMAIL PROTECTED]:~/src/git> make NO_OPENSSL=1
> cc -g -O2 -Wall '-DNO_OPENSSL' '-DSHA1_HEADER="mozilla-sha1/sha1.h"' -o
> gi
Paul Mackerras <[EMAIL PROTECTED]> writes:
> Linus, could you do a pull from the usual place to pick this up?
> (rsync://rsync.kernel.org/pub/scm/gitk/gitk.git). I also included a
> patch from Junio.
In case you did not notice, /pub/scm/git/git.git/ repository is
under the care of yours truly st
Linus Torvalds <[EMAIL PROTECTED]> writes:
> This doesn't work at least in the form that Junio merged it (and from
> what I can tell, he merged your patch as-is):
Slipped my filter. Sorry. Will fix.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [
This doesn't work at least in the form that Junio merged it (and from
what I can tell, he merged your patch as-is):
[EMAIL PROTECTED]:~/src/git> make NO_OPENSSL=1
cc -g -O2 -Wall '-DNO_OPENSSL' '-DSHA1_HEADER="mozilla-sha1/sha1.h"' -o
git-rev-list rev-list.o libgit.a -lz -lssl
/usr/lib/gc
Petr Baudis <[EMAIL PROTECTED]> writes:
>> > How would that document anything normal push wouldn't?
>>
>> git-merge?
>
> You have to git-merge anyway if remote head is not your ancestor yet,
> otherwise the push cannot proceed.
Indeed. And if git-merge fast forwards, then you would not get
any
Darrin Thompson <[EMAIL PROTECTED]> writes:
> Ok... so lets check my assumptions:
>
> 1. Pack files should reduce the number of http round trips.
> 2. What I'm seeing when I check out mainline git is the acquisition of a
> single large pack, then 600+ more recent objects. Better than before,
> but
After failing to apply a patch, when operating under -q (query)
flag, give the user an opportunity to fix up the patch in a
separate window and retry.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
tools/git-applymbox | 56 +--
1 files cha
Petr Baudis <[EMAIL PROTECTED]> writes:
> Note that I really _loved_ the Daniel's tools while they lasted. What I
> loved most about them was that they really only pulled objects I needed
> and not a single worthless one. Does the current HTTP transport share
> this property?
I am a big fan of Ba
I've been trying to streamline my workflow since I took it over
from Linus, and I think I am getting used to it. So here is a
short summary of what I am doing in the git.git repository.
Right now, there are two branches on kernel.org git.git
repository. I would not rewind "master" so if I find o
Petr Baudis <[EMAIL PROTECTED]> writes:
> Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter
> where Catalin Marinas <[EMAIL PROTECTED]> told me that...
>> Petr Baudis <[EMAIL PROTECTED]> wrote:
>> > The committer field generally identifies the committer "physically", and
>> > isn
Petr Baudis <[EMAIL PROTECTED]> writes:
> git-merge-cache reporting failed merge program is undesirable for
> Cogito, since it emits its own more appropriate error message in that
> case. However, I want to show other possible git-merge-cache error
> messages. So -q will just silence this particul
Petr Baudis <[EMAIL PROTECTED]> writes:
> All usage strings are now declared as static const char [].
I do not have preference either way, and I've already merged
them, but why char[] not char*?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL
On Fri, 29 Jul 2005, Linus Torvalds wrote:
>
> , but any time we _depend_ on dates
> one way or the other that would be a good.
"_not_ be a good _thing_". I don't know what strange brain-glitch I had
there.
I had kind of hoped my kids would be all grown up before their dad starte
On Fri, 29 Jul 2005, Ryan Anderson wrote:
>
> Maybe it'd make sense to have the commits refuse to add a commit when it
> would be younger than one of it's parents?
No, the git-rev-list thing really was a bug, it was just that I hadn't
thought things through when I wrote it, and the "normal" ca
Ryan Anderson wrote:
Maybe it'd make sense to have the commits refuse to add a commit when it
would be younger than one of it's parents?
Better not to trust timestamps in distributed federations since you
can't guarantee any kind of accuracy across administrative boundaries.
-
To unsubscribe
On Fri, Jul 29, 2005 at 03:50:30PM -0700, Linus Torvalds wrote:
>
> This corner-case was triggered by a kernel commit that was not in date
> order, due to a misconfigured time zone that made the commit appear three
> hours older than it was.
Maybe it'd make sense to have the commits refuse to add
Hi, Junio C Hamano wrote:
> Porcelain can keep track of
> mapping between b00:b24 for you,
Exactly.
> but you still need to keep
> track of b00:XYZ and b24:XYZ mapping in your head.
This is why I name my local branch "XYZ". ;-)
XYZ may not be an appropriate name for the remote branch, or maybe
This corner-case was triggered by a kernel commit that was not in date
order, due to a misconfigured time zone that made the commit appear three
hours older than it was.
That caused git-rev-list to traverse the commit tree in a non-obvious
order, and made it parse several of the _parents_ of the
Dear diary, on Sat, Jul 16, 2005 at 07:46:00PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> I do not know what release plan Linus has in mind, and also
> expect things to be quieter next week during OLS and kernel
> summit, but I think we are getting really really
On Fri, Jul 29, 2005 at 04:29:41AM -0400, Ryan Anderson wrote:
> Source Code Management with Git
The article should include a HOWTO part alos. So people can see how to
edit a file, pull from a remote repository etc.
Since you have introduced core and porcelains it would be most logical
to use
Dear diary, on Fri, Jul 29, 2005 at 05:48:26PM CEST, I got a letter
where Petr Baudis <[EMAIL PROTECTED]> told me that...
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -1,33 +1,53 @@
> +# Define NO_OPENSSL environment variable if you do not have OpenSSL. You will
> +# mi
Document new (and not-so-new) flags of git-rev-list.
Signed-off-By: Matthias Urlichs <[EMAIL PROTECTED]>
---
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -9,14 +9,35 @@ git-rev-list - Lists
Separate the process of building the commands to compilation and
linkage. This makes it more consistent with the library objects, is the
traditional thing to do, and significantly speeds up the subsequent
rebuilds, especially for us the people who develop git on 300MHz
notebooks.
Ported from Cogit
On Fri, Jul 29, 2005 at 03:30:15PM +0200, Petr Baudis wrote:
> git has $dest in its Makefile while Cogito uses $DESTDIR. I'd like to
> ask the potential users of those variables (probably mostly distribution
> package maintainers) what's easier for them and what do they prefer, as
> I would like
Support for completely OpenSSL-less builds. FSF considers distributing GPL
binaries with OpenSSL linked in as a legal problem so this is trouble
e.g. for Debian, or some people might not want to install OpenSSL
anyway. If you
make NO_OPENSSL=1
you get completely OpenSSL-less build, disabl
The Makefile rules were massively reordered so that they are actually
logically grouped now. Captions were added to separate the sections. No
rule contents was touched during the process.
Signed-off-by: Petr Baudis <[EMAIL PROTECTED]>
---
commit 656a66fe63898954dbc40854dd049dc76eb9b841
tree a5b29
Describe variables which make itself takes and adjusts compilation
accordingly (MOZILLA_SHA1, NO_OPENSSL, PPC_SHA1), and make adding
defines more convenient through the $DEFINES variable. $COPTS includes
-g as well now and is not overriden if it was already declared in the
environment. Also, $CFLAG
Remove about one gazillion of explicit dependency rules with few lines
describing the general dependency pattern and then the exceptions. This
noticably shortens the Makefile and makes it easier to touch it.
This is part of the Cogito Makefile changes port.
Signed-off-by: Petr Baudis <[EMAIL PROT
On Fri, 2005-07-29 at 17:08 +0200, Radoslaw AstralStorm Szkodzinski
wrote:
> On Fri, 29 Jul 2005 09:57:36 -0500
> Darrin Thompson <[EMAIL PROTECTED]> wrote:
>
> > Can't see the code.
> >
> > http://www.kernel.org/pub/software/scm/gitweb/gitweb.cgi
> >
> > Internal Server Error
> >
>
> Use FTP.
On Fri, 29 Jul 2005 09:57:36 -0500
Darrin Thompson <[EMAIL PROTECTED]> wrote:
> Can't see the code.
>
> http://www.kernel.org/pub/software/scm/gitweb/gitweb.cgi
>
> Internal Server Error
>
Use FTP.
--
AstralStorm
GPG Key ID = 0xD1F10BA2
GPG Key fingerprint = 96E2 304A B9C4 949A 10A0 9105 9
On Fri, 2005-07-29 at 10:48 -0400, Ryan Anderson wrote:
> On Fri, Jul 29, 2005 at 09:03:41AM -0500, Darrin Thompson wrote:
> >
> > Where is the code for gitweb? (i.e. http://kernel.org/git ) Seems like
> > it could benefit from some git-send-pack superpowers.
>
> http://www.kernel.org/pub/softwar
Hi, Linus!
On Thu, 2005-07-28 at 17:30 -0700, Linus Torvalds wrote:
> _always_ save the value of errno before doing any other calls. Even
> successful calls are perfectly allowed to change errno.
OK. Fixed patch below.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
diff --git a/diff.c b/diff
On Fri, Jul 29, 2005 at 09:03:41AM -0500, Darrin Thompson wrote:
>
> Where is the code for gitweb? (i.e. http://kernel.org/git ) Seems like
> it could benefit from some git-send-pack superpowers.
http://www.kernel.org/pub/software/scm/gitweb/
It occurs to me that pulling this into the main git r
On Thu, 2005-07-28 at 22:35 -0700, Junio C Hamano wrote:
> 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 someb
On Fri, 29 Jul 2005 15:40:11 +0200
Petr Baudis <[EMAIL PROTECTED]> wrote:
> What I would propose:
>
> -COPTS=-g -O2
> -CFLAGS=$(COPTS) -Wall
> +CFLAGS?=-g -O2
> +CFLAGS+=-Wall
Sounds good. I've never heard of anyone using COPTS variable before. And
"-g -O2" seems to be
On Thu, 2005-07-28 at 19:24 -0700, Junio C Hamano wrote:
> The thing is, the base pack for the git repository is 1.8MB
> currently containing 4500+ objects, while we accumulated 600+
> unpacked objects since then which is about ~5MB. The commit
> walker needs to fetched the latter one by one in th
Petr Baudis wrote:
Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter
where Matthias Urlichs <[EMAIL PROTECTED]> told me that...
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 easi
Hello,
one more thing - should we keep the $COPTS variable? Most projects
(including Cogito) have the C flags controlled by the $CFLAGS variable.
What I would propose:
-COPTS=-g -O2
-CFLAGS=$(COPTS) -Wall
+CFLAGS?=-g -O2
+CFLAGS+=-Wall
That is, if user do
Hello,
git has $dest in its Makefile while Cogito uses $DESTDIR. I'd like to
ask the potential users of those variables (probably mostly distribution
package maintainers) what's easier for them and what do they prefer, as
I would like to unify this.
Thanks,
--
git-merge-cache reporting failed merge program is undesirable for
Cogito, since it emits its own more appropriate error message in that
case. However, I want to show other possible git-merge-cache error
messages. So -q will just silence this particular error.
Signed-off-by: Petr Baudis <[EMAIL PRO
Petr Baudis <[EMAIL PROTECTED]> wrote:
> Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter
> where Catalin Marinas <[EMAIL PROTECTED]> told me that...
>> The latest StGIT snapshot uses, by default, the committer's details
>> for the From: line when sending patches by e-mail, assum
Dear diary, on Fri, Jul 29, 2005 at 02:26:51PM CEST, I got a letter
where Johannes Schindelin <[EMAIL PROTECTED]> told me that...
> Hi,
>
> On Fri, 29 Jul 2005, Petr Baudis wrote:
>
> > Dear diary, on Fri, Jul 29, 2005 at 12:57:50PM CEST, I got a letter
> > where Johannes Schindelin <[EMAIL PROTE
Hi,
On Fri, 29 Jul 2005, Petr Baudis wrote:
> Dear diary, on Fri, Jul 29, 2005 at 12:57:50PM CEST, I got a letter
> where Johannes Schindelin <[EMAIL PROTECTED]> told me that...
>
> > git-switch-tree remotehead
> > git-merge master
> > git-push remoteside remotehead
> >
> > which woul
Dear diary, on Fri, Jul 29, 2005 at 12:57:50PM CEST, I got a letter
where Johannes Schindelin <[EMAIL PROTECTED]> told me that...
> Hi,
Hello,
> On Fri, 29 Jul 2005, Petr Baudis wrote:
>
> > You might get the push access rather lately in the process (this "lazy
> > development privileges grantin
Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter
where Catalin Marinas <[EMAIL PROTECTED]> told me that...
> Petr Baudis <[EMAIL PROTECTED]> wrote:
> > The committer field generally identifies the committer "physically", and
> > isn't usually overriden. You'll find <[EMAIL PROTEC
Hi,
On Thu, 28 Jul 2005, Junio C Hamano wrote:
> 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" t
I like it!
Ciao,
Dscho
-
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
Hi,
On Fri, 29 Jul 2005, Petr Baudis wrote:
> You might get the push access rather lately in the process (this "lazy
> development privileges granting" is one of the point of distributed
> VCSes), at point where other people are used to pull from you and
> renaming your branch locally might mean
Hi,
On Thu, 28 Jul 2005, Junio C Hamano wrote:
> I'll keep this in the proposed updates queue until somebody
> comes up with a bit cleaner solution.
Agreed. That's why I put in "RFD", not "PATCH"
> By the way, Johannes, what mailer do you use? Many of your
> patches seem to be whitespace damag
Hi,
On Thu, 28 Jul 2005, Junio C Hamano wrote:
> 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
Petr Baudis <[EMAIL PROTECTED]> wrote:
> 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 thought GIT_COMMITTER_{NAME,EMAIL} were added to be able to override
the defaults like [EMAIL
Dear diary, on Fri, Jul 29, 2005 at 10:54:07AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> I however still suspect that you might be spreading chaos under the
> name of more flexibility.
I'm such a villain! ;-))
> The fact that you can push into it by definitio
On Fri, 29 Jul 2005 09:46:14 +0200
Petr Baudis <[EMAIL PROTECTED]> wrote:
> FWIW, I made tiny "build system" (inspired by kconfig) for smaller
> projects I work on:
Me too! :)
http://onion.dynserv.net/~timo/index.php?page=Projects/build
It also has configuration system written in bash.
--
htt
Hi,
On Friday 29 July 2005 09:48, you wrote:
> Petr Baudis <[EMAIL PROTECTED]> writes:
> > So, what do you mean by "clone" here? And what command should I use for
> > pushing then?
...
> Now, A may happen to be on my home machine and B may happen be
> on my notebook, meaning the owner of A and B a
All usage strings are now declared as static const char [].
This is carried over from my old git-pb branch.
Signed-off-by: Petr Baudis <[EMAIL PROTECTED]>
---
commit 1e02de8f49a8fca696b3cb363545fad3c98fd662
tree feee1ccdea90d33fae2bf41621a876c5aa2ecfe5
parent 83b1762040b111b4736d108cd91b8a9d75aa
Simple whitespace-related tidyups ensuring style consistency.
This is carried over from my old git-pb branch.
Signed-off-by: Petr Baudis <[EMAIL PROTECTED]>
---
commit 83b1762040b111b4736d108cd91b8a9d75aad3a9
tree e07192546e9bd6a972e3945dd941fc7a29ec1a4b
parent d854f783af2a441827d66b4b70e9d0d9e3
Hi,
those two bits were long kept local to git-pb. You can either apply
the patches or pull:
www.kernel.org/pub/scm/cogito/git-pb.git
The bits are mostly cosmetic but I want to get rid of them. :-)
I'd like to know what to do with the git-pb branch in the future.
Based on what do
Petr Baudis <[EMAIL PROTECTED]> writes:
> Exactly. I want much more freedom in pushing, the only requirement being
> that "the to-be-replaced remote head is ancestor of the to-be-pushed
> local head". I think (am I wrong?) git-send-pack localhead:remotehead
> would work just fine for me, the only
Umm. I just discovered a portion of mailing list I somehow completely
missed. :/ Sorry for the delayed replies.
Dear diary, on Wed, Jun 15, 2005 at 03:45:21AM CEST, I got a letter
where Pavel Roskin <[EMAIL PROTECTED]> told me that...
> Hello!
Hi,
> I believe the documented behavior of cg-restor
Dear diary, on Fri, Jul 29, 2005 at 10:24:54AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> In the meantime, the current one is clearly broken as you
> pointed out, so let's replace it with the updated "generic rule
> with the following exceptions" one.
That's fi
Source Code Management with Git
"git" can mean anything, depending on your mood.
- random three-letter combination that is pronounceable, and not
actually used by any common UNIX command. The fact that it is a
mispronunciation of "get" may or may not be relevant.
- stupid. contemptible
On Wed, Jul 27, 2005 at 03:13:18PM -0700, Junio C Hamano wrote:
> > Git results from the inspiration and frustration of Linus Torvalds, and
> > the enthusiastic help of over 300 participants on the development
> > mailing list.[1] It is maintained by Junio C Hamano <[EMAIL PROTECTED]>.
>
> Please
Petr Baudis <[EMAIL PROTECTED]> writes:
> Hmm. What about just excluding the files according to the order of
> parameters on the command line?
>
> Here, the question is whether the GIT Core tools should provide full
> flexibility and friendness to custom use, or rather serve as tighter
> unifying
Dear diary, on Fri, Jul 29, 2005 at 09:48:57AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Petr Baudis <[EMAIL PROTECTED]> writes:
>
> > Aha, so it seems our problem is hopefully only in terminology, great.
> >
> > So, what do you mean by "clone" here? And what
Dear diary, on Fri, Jul 29, 2005 at 09:31:34AM CEST, I got a letter
where Sam Ravnborg <[EMAIL PROTECTED]> told me that...
> > > While I do not have strong objections to make the build process
> > > go faster, it is somewhat disturbing that the Makefile pieces
> > > maintained in subdirectories nee
Pasky and others raised many valid points on the problems
initial exclude pattern enhancement work had. Based on the
list discussion, rework the exclude logic to use "last match
determines its fate" rule, and order the list by exclude-from
(the fallback default pattern file), exclude-per-directory
Petr Baudis <[EMAIL PROTECTED]> writes:
> Aha, so it seems our problem is hopefully only in terminology, great.
>
> So, what do you mean by "clone" here? And what command should I use for
> pushing then?
Notice I never used the word "clone" in what I said.
What I mean by "a semantically equivale
Update the tests and documentation to match the new "last one
determines its fate" semantics.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Documentation/git-ls-files.txt | 27 ++-
t/t3001-ls-files-others-exclude.sh | 23 ++-
2 files ch
Hi,
Petr Baudis:
> Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter
> where Matthias Urlichs <[EMAIL PROTECTED]> told me that...
> > Hi, A Large Angry SCM wrote:
> >
> > > So you're arguing for "last match wins" versus "first match wins". I,
> > > personally, find the former m
Dear diary, on Fri, Jul 29, 2005 at 07:04:36AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> * When checking a file to see if it is excluded, we first look
>at "exclude-from patterns" list, then "per directory
>patterns" list, and then "command line patter
> > While I do not have strong objections to make the build process
> > go faster, it is somewhat disturbing that the Makefile pieces
> > maintained in subdirectories need to name things they touch
> > using paths that include the subdirectory names. I do not have
> > a better alternative to sugge
Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter
where Matthias Urlichs <[EMAIL PROTECTED]> told me that...
> 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 debu
Dear diary, on Thu, Jul 28, 2005 at 11:13:38PM CEST, I got a letter
where Matthias Urlichs <[EMAIL PROTECTED]> told me that...
> Then, you'd kill porcelain writers who don't verify that the old head is
> a(n indirect) parent of the new one. ;-)
send-pack.c:
if (!ref_newer(new_sha1, ref->o
Dear diary, on Thu, Jul 28, 2005 at 10:14:35PM CEST, I got a letter
where Johannes Schindelin <[EMAIL PROTECTED]> told me that...
> Hi,
Hello,
> Naming the remote HEAD differently than the local HEAD is just *wrong*
> when you want to push back to them.
But you might not know that in advance. Th
Dear diary, on Fri, Jul 29, 2005 at 04:24:40AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> 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
77 matches
Mail list logo
