* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-12 22:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, sean
In-Reply-To: <43C6CFC5.5010902@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>
>> ... let's say an
>> office-mate edited things for you and said "this should work.
>> test it out and if it is OK commit it for me."...
>
> This happens from time to time where I work, but I think it would be
> more useful to have
>
> --from="Some User <some.user@theoffice.org>"
>
I agree this would be more useful, direct, easy to understand
and explain way to do it.
^ permalink raw reply
* Re: git-bisect is magical
From: Sytse Wielinga @ 2006-01-12 21:59 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dq3hgn$maf$1@sea.gmane.org>
On Wed, Jan 11, 2006 at 10:07:19AM -0800, walt wrote:
> [...]
> After I did the 'git checkout origin' yesterday, I didn't (yet) know
> what I was doing, so I made the following pilot-errors while still
> in 'origin': I did 'git-reset --hard origin' and then very early
> this morning I did cg-update, both of which seemed to work fine and
> gave no error messages, and I compiled a new kernel from the result.
>
> After reading the three essays from you guys :o) I realized that I
> had made these two mistakes, and tried to switch back to master:
> $git-branch
> bisect
> master
> * origin
> $git-checkout master
> fatal: Entry 'Documentation/kernel-parameters.txt' would be overwritten
> by merge. Cannot merge.
>
> So I cloned a fresh copy of your repository and built a new kernel.
Funny thing about git is, at least in my experience, that you generally never
really have to do this. Because objects are immutable, and basically the only
thing git -really- cares about is objects, you can always tell git to just
ignore anything you've done (or that anybody else has done, for that matter).
Just point it to an object somebody else made and it won't see any of your
local changes. If you're not satisfied with the way a branch worked out, just
remove it, or point it to another object.
By the way, you can always just move away a broken origin; git-fetch (or
git-pull of course, because it uses git-fetch), will just create a new one. If
git-branch shows that you currently have origin checked out, do
# Create a new branch named 'bad-bad-origin' based on HEAD (which equals
# origin at the moment) and check it out
git-checkout -b bad-bad-origin
otherwise do (because it is faster, as it doesn't touch your index file or
your working tree)
# Create a new branch named 'bad-bad-origin' based on origin
git-branch bad-bad-origin origin
... and finally remove the old origin:
git-branch -d origin
After this, a git-fetch will just recreate origin, and unlike git-pull does
nothing that could give you more headbreaks again, so that fixes your broken
origin. Then optionally backup your master by saying
git-branch old-master master
and get yourself a nice and clean repository again by typing:
git-checkout master
# Reset the current HEAD (namely, master) to origin
git-reset --hard origin
Before executing any git command that will check out a different tree, though,
you will want to make sure you know what you have done to your working tree and
what git will do to your edits when you execute that command. git-diff*,
git-ls-files, and git-status are your friends. If either git-ls-files -m or
git-ls-files -u (or the combination git-ls-files -m -u, naturally) shows any
files, git will refuse to switch branches if it has to touch any of these
files.
If you're sure you don't want these changes anymore, you can undo any changes
with 'git-reset --hard'. If you wish to save these changes however, you can
either take the classic approach of saving a diff with git-diff HEAD (just a
plain git-diff won't do for files in git-ls-files -u, that is, files that you
already ran git-update-index on) or you can make a commit and save it in a
temporary branch.
For example, you can make a commit before or after the 'git-checkout -b
bad-bad-origin' in the beginning of this mail, and the diff will be in
bad-bad-origin for your later reference by using git-diff-tree -p
bad-bad-origin.
By the way, if you really don't know what to do anymore, there always is the
last resort of fixing things up manually. I'm not recommending you to go this
way, but it has helped me out a couple of times before I knew all the basic
commands, so it seems good to at least mention how you do it.
All branches are in .git/refs/heads/, so you can just go there and move master
and origin or any other branch that you like to another name, or remove them,
or overwrite them with references you pick from other files in .git/refs/heads/
or git log. Just make sure all they contain is a full sha1-hash, so no names,
just the hash. And that .git/HEAD is a symlink pointing to one of the files in
refs/heads/.
The drawback, and the reason you should generally not do this unless you don't
know any better way to do what you want, is that you can leave the index file
and the working tree in a state that doesn't correspond to the current HEAD
anymore. To be sure, you can always go back to the top directory and do a
'git-reset --hard', and then a 'git-ls-files -z -o |xargs -0 rm --'. This will
remove any extra files that you have in your working tree, mind you, so make
sure you move those you still need out of the working tree before doing this.
> What I learned from this was that the new fixes to Makefile and
> setlocalversion (at a minimum) were not actually applied to the
> checked-out sources in my 'origin' misadventure. (I watched the
> commits being listed by cg-update, so I know the fixes were really
> downloaded -- but they were not applied to the checked-out sources
> as they normally would be.)
>
> Would these anomalous results be expected -- given the, um, unusual
> circumstances?
Yes. If git tries a merge, but fails, it will leave the results in the working
tree for you to fix, so that you can finish the merge. If you don't wish to
finish the merge, just do a git-reset --hard and your tree is clean again.
> Thanks again!
No thank _you_, for explaining so well what exactly you didn't understand! :-)
Sytse Wielinga
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Andreas Ericsson @ 2006-01-12 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sean, git
In-Reply-To: <7vzmm1mcfz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> If you typed that line, why somebody else's change ended up in
> your working tree is a mystery to me, but let's say an
> office-mate edited things for you and said "this should work.
> test it out and if it is OK commit it for me." I have seen this
> kind of thing done in real life.
>
This happens from time to time where I work, but I think it would be
more useful to have
--from="Some User <some.user@theoffice.org>"
which would save even more typing.
I had thought of coupling this with some translation-scheme thingie, so
that "--from=jd" would be automagically converted to the proper name and
email address. I first came to think about this when I imported most of
our projects from CVS, but I ended up doing a quick-hack to
git-cvsimport instead.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git pull request email's
From: Jeff Garzik @ 2006-01-12 21:46 UTC (permalink / raw)
To: Kumar Gala, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.44.0601121527220.23584-100000@gate.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 318 bytes --]
Kumar Gala wrote:
> How do you produce the git pull request emails that you sent to Linus?
I hope you don't mind me answering you in public.
Attached is the simple script I use to create the pull emails. I
manually include the emails inside mutt, rather than letting the script
send the emails directly.
Jeff
[-- Attachment #2: mkmsg.sh --]
[-- Type: application/x-sh, Size: 524 bytes --]
^ permalink raw reply
* Re: git in HP-UX PA-RISC
From: Joan Ripoll Balaguer @ 2006-01-12 19:33 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43C6AB95.2020507@op5.se>
2006/1/12, Andreas Ericsson <ae@op5.se>:
> Joan Ripoll Balaguer wrote:
> > How I can build git on HP-UX 11.11 (PA-RISC)?
> >
> > I have build openSSL and zlib libraries, plus GNU make utility, but I
> > haven't gcc compiler. I have native ANSI C compiler.
> >
> > I search in the archives of that mail list, but I find nothing.
> >
>
> If you could tell us what particular problems you're experiencing you
> would increase your own chance of getting help.
>
Ok, Tomorrow, from office, I will post a hardcopy of de output.
^ permalink raw reply
* [wish] Auto-generate gitk's pretty pictures
From: Martin Langhoff @ 2006-01-12 21:02 UTC (permalink / raw)
To: Git Mailing List
Being an ignorant in matters Tk, I am wondering whether it'd be
possible to hack gitk so that it renders the top canvas into a file.
gitweb doesn't give people any hints of how the heads are related, so
I am working on the idea of running an hourly cron on the server that
does
gitk -d --all --max-count=1000 --prettypic=foo.png
and link to the png from gitweb. Is it easier to trick gitk to do it,
or should I be thinking of porting the logic to some other script?
(Possibly in Perl using GD).
cheers,
martin
^ permalink raw reply
* Re: git in HP-UX PA-RISC
From: Kyle McMartin @ 2006-01-12 20:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joan Ripoll Balaguer, git
In-Reply-To: <7v1wzdmbrd.fsf@assigned-by-dhcp.cox.net>
On Thu, Jan 12, 2006 at 12:28:38PM -0800, Junio C Hamano wrote:
>
> I do not think we had a thread on bootstrapping GCC on HP-UX on
> this list ;-).
>
> Your build log that shows compilation error messages, or if you
> can identify what GCC extension we use that HP-UX C compiler
> does not like then a short summary of the problem, would be
> helpful (of course the latter is preferred).
>
> One thing I know we deliberately use GCC extension is flex
> array. "make CFLAGS=-DFLEX_ARRAY=1" might help. Maybe not.
>
An HP-UX user can fairly trivially install GCC... HP provides
the packages.
http://h21007.www2.hp.com/dspp/tech/tech_TechSoftwareDetailPage_IDX/1,1703,547,00.html
^ permalink raw reply
* Re: git in HP-UX PA-RISC
From: Junio C Hamano @ 2006-01-12 20:28 UTC (permalink / raw)
To: Joan Ripoll Balaguer; +Cc: git
In-Reply-To: <5c08a49c0601121105u519fe02fq@mail.gmail.com>
Joan Ripoll Balaguer <joan.ripsa@gmail.com> writes:
> How I can build git on HP-UX 11.11 (PA-RISC)?
>
> I have build openSSL and zlib libraries, plus GNU make utility, but I
> haven't gcc compiler. I have native ANSI C compiler.
>
> I search in the archives of that mail list, but I find nothing.
I do not think we had a thread on bootstrapping GCC on HP-UX on
this list ;-).
Your build log that shows compilation error messages, or if you
can identify what GCC extension we use that HP-UX C compiler
does not like then a short summary of the problem, would be
helpful (of course the latter is preferred).
One thing I know we deliberately use GCC extension is flex
array. "make CFLAGS=-DFLEX_ARRAY=1" might help. Maybe not.
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-12 20:22 UTC (permalink / raw)
To: Joel Becker; +Cc: git
In-Reply-To: <20060112190031.GH14196@ca-server1.us.oracle.com>
Joel Becker <Joel.Becker@oracle.com> writes:
> On Thu, Jan 12, 2006 at 09:37:00AM -0500, sean wrote:
>> Use the author name and email information given as the
>> first line of the commit message in the form of:
>>
>> From: name <email>
>>
> If we do this, can we have it populated up front? That is, when
> the edit opens, the current idea of author is in the comments as "From:"
> so I can see what the author would be if I changed nothing. This would
> catch surprises where I'd forgotten to set AUTHOR_*, etc.
Committing somebody else's changes by hand ought to be a rare
event. Otherwise that is an indication that there needs to be a
"git am/applymbox" equivalent for the mythical transport medium
(other than e-mail) that feeds you somebody else's changes to
you and have you commit. If something is a regular event in a
workflow, we would want to be able to automate things, and
having the user type in whom the changes have come from is not
the way to do it.
Most of the time when I use "git commit", I'll be committing my
own changes; I do not want to see "From: me" every time I
commit.
"Populate upfront, only if it is different from yourself" is
perhaps acceptable, but that is probably hard to arrange. There
is no reliable way to know what is "yourself", and that was why
we have GIT_AUTHOR_* environment variables to override things to
begin with.
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Alex Riesen @ 2006-01-12 20:16 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <20060112093700.1d3d25db.seanlkml@sympatico.ca>
sean, Thu, Jan 12, 2006 15:37:00 +0100:
>
> Mostly just for comment to see if there is any support
> for this feature....
>
> Sean
>
> ---
> Use the author name and email information given as the
> first line of the commit message in the form of:
>
> From: name <email>
>
Isn't this what git-am expect (as a part of mbox) and handle?
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-12 20:13 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP117A18814EAAFACFE0F31DAE270@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> Mostly just for comment to see if there is any support
> for this feature....
>
> Sean
>
> ---
> Use the author name and email information given as the
> first line of the commit message in the form of:
>
> From: name <email>
>
> as the author's name and email address in the resulting
> commit object. This makes committing foreign patches
> a little less cumbersome to handle for some workflows.
Actually, I've considered this a couple of times in the past,
but I ended up saying no.
If the workflow is driving "git commit" from a script (i.e. your
own Porcelain), the script can set GIT_AUTHOR_* environment
variables, so this is a non issue.
Which means that this 'From: ' thing is coming from the end
user. Either you as the end user pasted it from some text file,
or typed that line because you knew that the change was made by
that person, not by you.
If you pasted that line from somewhere else, I wonder what that
"somewhere else" file is -- and what else that file contained.
If the change came in an e-mail message, we already have tools
for that (am/applymbox), and they do not lose the author-date
information as your change to git-commit does, so I think it is
a non issue.
And I do not think of anything else that would have author name
but does not have a patch text that you can feed git-apply with.
Pasting from your address book just to save typing does not
count as "pasting" --- that is still typing in this context.
If you typed that line, why somebody else's change ended up in
your working tree is a mystery to me, but let's say an
office-mate edited things for you and said "this should work.
test it out and if it is OK commit it for me." I have seen this
kind of thing done in real life.
If that is what happened, then what you are adding is a more
convenient way than setting two GIT_AUTHOR_* environment
variables. Maybe you forgot about preserving author date, in
which case you would add 'Date: ' as well to your patch, and
that would save your user from setting three environment
variables.
So the matter really is how much this patch is better than
setting GIT_AUTHOR_* environment variables, unless it simplifies
things for other programs (one possibility I have not looked
into is that we _might_ be able to use "git commit" with this
modification from "git am/applimbox/revert/cherry-pick").
^ permalink raw reply
* Re: git in HP-UX PA-RISC
From: Andreas Ericsson @ 2006-01-12 19:18 UTC (permalink / raw)
To: Joan Ripoll Balaguer; +Cc: git
In-Reply-To: <5c08a49c0601121105u519fe02fq@mail.gmail.com>
Joan Ripoll Balaguer wrote:
> How I can build git on HP-UX 11.11 (PA-RISC)?
>
> I have build openSSL and zlib libraries, plus GNU make utility, but I
> haven't gcc compiler. I have native ANSI C compiler.
>
> I search in the archives of that mail list, but I find nothing.
>
If you could tell us what particular problems you're experiencing you
would increase your own chance of getting help.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git binary size...
From: H. Peter Anvin @ 2006-01-12 19:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601121033020.3535@g5.osdl.org>
Linus Torvalds wrote:
>
>>Repeat after me: "autoconf is crap".
>
> .. which is not to say that some _other_ autoconf-like thing might not be
> good.
>
> The problem I have with autoconf is that it adds absolutely horrendous
> #ifdef's etc all over the place, and the resulting makefile (and the
> config file itself) is just completely unreadable.
>
> The reason autoconf sucks *ss is that it doesn't try to abstract out any
> of the differences between systems, it tries to basically "fix up" the
> differences.
>
> A real abstraction library would be a lot more preferable than autoconf.
> It's kind of the way the git stuff works (ie using things like
> "gitstrcasestr()" and "gitfakemmap()"), but for many of the same reasons
> that autoconf never did a good job, git itself doesn't do a good job (it
> uses "#if" hackery to then do things like "#define mmap gitfakemmap").
>
> But I think the git kind of hackish #ifdef thing is better than the
> _insitutionalized_ horrible autoconf hackery.
>
You can use autoconf in this way, though. See my previous post on the
matter.
-hpa
^ permalink raw reply
* git in HP-UX PA-RISC
From: Joan Ripoll Balaguer @ 2006-01-12 19:05 UTC (permalink / raw)
To: git
How I can build git on HP-UX 11.11 (PA-RISC)?
I have build openSSL and zlib libraries, plus GNU make utility, but I
haven't gcc compiler. I have native ANSI C compiler.
I search in the archives of that mail list, but I find nothing.
Thank.
(Sorry for my english).
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Joel Becker @ 2006-01-12 19:00 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <20060112093700.1d3d25db.seanlkml@sympatico.ca>
On Thu, Jan 12, 2006 at 09:37:00AM -0500, sean wrote:
> Use the author name and email information given as the
> first line of the commit message in the form of:
>
> From: name <email>
>
> as the author's name and email address in the resulting
> commit object. This makes committing foreign patches
> a little less cumbersome to handle for some workflows.
If we do this, can we have it populated up front? That is, when
the edit opens, the current idea of author is in the comments as "From:"
so I can see what the author would be if I changed nothing. This would
catch surprises where I'd forgotten to set AUTHOR_*, etc.
Joel
--
Life's Little Instruction Book #182
"Be romantic."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: [RFD] what should "git push remote.host:path" do?
From: Junio C Hamano @ 2006-01-12 19:00 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP099ED34B41FFA02EDEEF25AE270@CEZ.ICE>
"Sean" <seanlkml@sympatico.ca> writes:
> What about assuming a refspec of "current-branch:current-branch" ?
> That is, if the branch name that is currently checked out locally
> also exists upstream, push into it (only if fast forward).
>
> This should allow multiple branches to be updated locally, and pushed
> upstream selectively.
Requiring at least one refspec to be given to the command has
the same property. Ways to give refspec to the command are:
(1) give one or more from the command line
(2) give --all from the command line
(3) give none from the command line, but in this case you need
at least one "Push:" the "remotes" file you use.
So it really boils down to "is pushing the current branch a
better default"?
Even if a project uses CVS style shared repository setup,
individual developers would want to use topic branches to
prepare things that they eventually push to the shared common,
and I suspect that it would lead to more mistakes if we default
the push to push the current branch. "Push: master" in the
remotes/ file to publish your results to the shared repository
would be safer; "git push" when you are still in your topic
branch and have not merged things up into your master branch for
publication would be no-op, as opposed to pushing the topic
branch, probably resulting in the topic branch in the shared
repository, even though the topic was meant to be internal to
his repository.
^ permalink raw reply
* Re: [RFD] what should "git push remote.host:path" do?
From: Junio C Hamano @ 2006-01-12 18:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Nick Hengeveld
In-Reply-To: <Pine.LNX.4.64.0601121006040.3535@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Well, especially if you want to use "git push" to basically back up your
> own repo, you do want the "--all" flag. Otherwise you will then forget to
> add a branch name to every remotes file whenyou create a new branch.
Sorry, I was unclear in my original message, but I meant to
require at least one refspec to be given to the command. Ways
to give refspec to the command are:
(1) give one or more from the command line
(2) give --all from the command line
(3) give none from the command line, but in this case you need
at least one "Push:" the "remotes" file you use.
We already have --all, but your "git push --tags $remote" makes
sense. For backups, "only matching things" is not good enough,
and we need --all.
^ permalink raw reply
* Re: git binary size...
From: Linus Torvalds @ 2006-01-12 18:46 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601121013030.3535@g5.osdl.org>
On Thu, 12 Jan 2006, Linus Torvalds wrote:
>
> Repeat after me: "autoconf is crap".
.. which is not to say that some _other_ autoconf-like thing might not be
good.
The problem I have with autoconf is that it adds absolutely horrendous
#ifdef's etc all over the place, and the resulting makefile (and the
config file itself) is just completely unreadable.
The reason autoconf sucks *ss is that it doesn't try to abstract out any
of the differences between systems, it tries to basically "fix up" the
differences.
A real abstraction library would be a lot more preferable than autoconf.
It's kind of the way the git stuff works (ie using things like
"gitstrcasestr()" and "gitfakemmap()"), but for many of the same reasons
that autoconf never did a good job, git itself doesn't do a good job (it
uses "#if" hackery to then do things like "#define mmap gitfakemmap").
But I think the git kind of hackish #ifdef thing is better than the
_insitutionalized_ horrible autoconf hackery.
There are real abstraction layers out there, but they usually do a lot
more than just simple autoconf things. They do full system abstraction,
usually with support for graphical GUI stuff too: layers like Qt,
wxVidgets, whatever..
Now THAT is a good approach.
Sadly, for the git kind of area, I don't know of any sane toolkits like
that. The "gnulib" project could have been something, but it has been
corrupted by the autoconf disease, as far as I can tell.
Anyway, it _should_ be possible to make a nice "extended posix wrapper"
with just a single
#include "libposix.h"
and having a per-system "posix header" that resolves all the stupid header
file differences, and a "posix library" that adds (or fixes) all the posix
problems for each platform.
Instead, people still use autoconf ;(
Linus
^ permalink raw reply
* Re: git binary size...
From: Johannes Schindelin @ 2006-01-12 18:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601121013030.3535@g5.osdl.org>
Hi,
On Thu, 12 Jan 2006, Linus Torvalds wrote:
> Repeat after me: "autoconf is crap".
I tried to hold my breath for that mail, but you disappointed me. What
took you so long?
Ciao,
Dscho
P.S.: Note that I am not at all detesting autoconf, but I know Linus does.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.1.1
From: Eric Sandall @ 2006-01-12 18:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64or1ii9.fsf@assigned-by-dhcp.cox.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 10 Jan 2006, Junio C Hamano wrote:
> The latest maintenance release GIT 1.1.1 is available at the usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.1.1.tar.{gz,bz2} (tarball)
> RPMS/$arch/git-*-1.1.1-1.$arch.rpm (RPM)
>
> This is primarily to fix the build problems with RPM and tarball
> releases. I owe a big thanks to Peter Anvin for the fix.
<snip>
Updated the Source Mage GNU/Linux package.
- -sandalle
- --
Eric Sandall | Source Mage GNU/Linux Developer
eric@sandall.us | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDxqHMHXt9dKjv3WERAku5AJ48fxnKU8hdtFzWkARrU3fvzwlDXQCgj9xu
eNEYSaYtJfaSGWXLPRpbEnw=
=lrwn
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: git binary size...
From: Linus Torvalds @ 2006-01-12 18:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <43C65E70.7090702@op5.se>
On Thu, 12 Jan 2006, Andreas Ericsson wrote:
>
> git is already fairly portable without the autoconf hackery. It's easy enough
> to move some of the conditional stuff out of the Makefile without autoconf,
> but it would still require GNU Make, so there's no real point in doing so.
More importantly, autoconf is a worse hack than _any_ of the config hacks
we do currently.
Repeat after me: "autoconf is crap".
Linus
^ permalink raw reply
* Re: git binary size...
From: Linus Torvalds @ 2006-01-12 18:12 UTC (permalink / raw)
To: Coywolf Qi Hunt; +Cc: Andreas Ericsson, Junio C Hamano, Git Mailing List
In-Reply-To: <2cd57c900601120215pdb5da27l@mail.gmail.com>
On Thu, 12 Jan 2006, Coywolf Qi Hunt wrote:
> >
> > With stripped binaries, you can't really do _anything_. You get a
> > core-file, and you're screwed.
>
> Are you sure?
I'm sure.
> In gdb:
>
> No symbol table is loaded. Use the "file" command.
> (gdb) bt
> #0 0xb7f16445 in ext2fs_mark_generic_bitmap () from /lib/libext2fs.so.2
Note where the debug info comes from. It comes from the _library_.
> So with stripped binary, I still get the backtrace to locate the buggy
> function.
No you don't. With the _non-stripped_ library you get the backtrace.
There's no backtrace at all for the binary itself.
Linus
^ permalink raw reply
* Re: [RFD] what should "git push remote.host:path" do?
From: Linus Torvalds @ 2006-01-12 18:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nick Hengeveld
In-Reply-To: <7vslrtq05h.fsf@assigned-by-dhcp.cox.net>
On Thu, 12 Jan 2006, Junio C Hamano wrote:
>
> Nevertheless, exposing the default behaviour of "git send-pack"
> to "git push" was probably a mistake. I'd propose to require at
> least one refspec to be specified, either on the command line or
> via $GIT_DIR/remotes mechanism. So my answer to the "Subject: "
> line question is "Barf".
Well, I don't have objections, but from ym usage schenario, I'd at least
then want flags for "all tags" (--tags - like "pull") and "all branches"
(--all).
Having to list all tags/branches is slightly painful. I currently push out
all my tags with
./push-all $(cd .git/refs ; find -type f tags)
which works but isn't exactly user-friendly ("push-all" is just a script
that uses "git push" to push to multiple repositories).
> Unlike pull that can happen pretty much promiscuously, people
> will push into the same set of a limited number of remote
> repositories repeatedly over the life of the project, so it is
> reasonable to assume they would want to keep a $GIT_DIR/remotes/
> entry for those repositories to save typing. Then always
> requiring one or more refspecs for push is not too much to ask
> for.
Well, especially if you want to use "git push" to basically back up your
own repo, you do want the "--all" flag. Otherwise you will then forget to
add a branch name to every remotes file whenyou create a new branch.
Linus
^ permalink raw reply
* Re: git binary size...
From: H. Peter Anvin @ 2006-01-12 17:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <43C65E70.7090702@op5.se>
Andreas Ericsson wrote:
>>
>> To make git not tight to Linux, but cross platform, consider autoconf.
>
> git is already fairly portable without the autoconf hackery. It's easy
> enough to move some of the conditional stuff out of the Makefile without
> autoconf, but it would still require GNU Make, so there's no real point
> in doing so.
>
The problem is that one really at some point end up reinventing a whole
lot of autoconf.
Now, a lot of autoconf ugliness comes from two sources:
- Not abstracting appropriately (#ifdef mess)
- Not using GNU make features
Once you require GNU make, you can have a top-level Makefile and have
configure generating MCONFIG and config.h, and have conventional
dependencies on those rules. Pretty much the whole autoconstipation
should be confined to those two files.
I might eventually try to make a clean patch for autoconf with git, and
hopefully show that when done correctly, it's probably cleaner than the
increasing Makefile mess, plus it's automatic.
-hpa
^ permalink raw reply
* Re: [RFD] what should "git push remote.host:path" do?
From: Nick Hengeveld @ 2006-01-12 16:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslrtq05h.fsf@assigned-by-dhcp.cox.net>
On Thu, Jan 12, 2006 at 01:13:30AM -0800, Junio C Hamano wrote:
> BTW, Nick, what does http-push do with "git push http://foo"
> without refspecs?
It won't push anything unless refspecs are specified. If there are
none, it will still verify remote DAV locking is available and then
exit quietly.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox