* [PATCH] git-push: avoid falling back on pushing "matching" refs.
From: Junio C Hamano @ 2006-01-13 1:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0601121006040.3535@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> 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).
So here it is, to add --tags and avoid falling back to
"matching" default.
-- >8 --
The underlying "git send-pack remote.host:path" pushes all the
matching refs that both local and remote have, and "git push"
blindly inherits this property. Which probably was a mistake.
A typical cloned repository (e.g. a subsystem repository cloned
from Linus repository) has at least two branches, "master" to
keep the subsystem and "origin" that records tip of Linus
"master" when the repository was cloned. If this is the public
repository for the subsystem, then subsystem developers would
clone it, and then cloned ones have "master" and "origin". When
developers use this public subsystem repository as a shared
repository, pushing into it via "git push subsys:/path/name"
would try to push the matching refs, "master" and "origin", from
the developers' repositories. The "origin" in the public shared
repository does not have much relevance, yet pushing into
"origin" would cause "not a fast forward" checks to be
triggered. Arguably "git push subsys:/path/name master" would
work it around, but having them to say it explicitly to avoid
pushing into "origin" as well is bad.
This commit requires you to give at least one refspec to
git-push. You could "give" by either:
(1) Listing the refspec(s) explicitly on the command line.
E.g. "git push subsys:/path/name master".
(2) Using --all or --tags on the command line.
E.g. "git push --tags subsys:/path/name".
(3) Using a $GIT_DIR/remotes shorthand with 'Push: refspec'
line in it.
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 even only to save typing the URL,
so keeping the default 'Push: refspec' line in such is a
sensible thing to do.
It was suggested to further fall back on pushing the current
branch, but this commit does not implement it. If developers
adopt topic branch workflow, pushing to public while on a topic
branch by mistake would expose the topic branch to the public
repository. Not falling back to the current branch prevents
that mistake from happening.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-push.sh | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
85393139981c28a2df93950b00e4712dc4bca56c
diff --git a/git-push.sh b/git-push.sh
index 1c5cf80..2b97e09 100755
--- a/git-push.sh
+++ b/git-push.sh
@@ -9,12 +9,15 @@ has_all=
has_force=
has_exec=
remote=
+do_tags=
while case "$#" in 0) break ;; esac
do
case "$1" in
--all)
has_all=--all ;;
+ --tags)
+ do_tags=yes ;;
--force)
has_force=--force ;;
--exec=*)
@@ -33,6 +36,10 @@ case "$#" in
echo "Where would you want to push today?"
usage ;;
esac
+if test ",$has_all,$do_tags," = ",--all,yes,"
+then
+ do_tags=
+fi
. git-parse-remote
remote=$(get_remote_url "$@")
@@ -42,6 +49,20 @@ case "$has_all" in
esac
shift
+case "$do_tags" in
+yes)
+ set "$@" $(cd "$GIT_DIR/refs" && find tags -type f -print) ;;
+esac
+
+# Now we have explicit refs from the command line or from remotes/
+# shorthand, or --tags. Falling back on the current branch if we still
+# do not have any may be an alternative, but prevent mistakes for now.
+
+case "$#,$has_all" in
+0,)
+ die "No refs given to be pushed." ;;
+esac
+
case "$remote" in
git://*)
die "Cannot use READ-ONLY transport to push to $remote" ;;
--
1.1.1-g6009
^ permalink raw reply related
* Re: git-bisect is magical
From: walt @ 2006-01-12 23:49 UTC (permalink / raw)
To: git
In-Reply-To: <20060112215946.GA5808@speedy.student.utwente.nl>
Sytse Wielinga wrote:
[...]
> No thank _you_, for explaining so well what exactly you didn't understand! :-)
I am totally blown away by the amount of useful information in your
post! I have scanned through what you sent, but I will need some time
to digest it all.
I promise you that I *will* understand every word of what you wrote,
even if I have to ignore my wife for a week! (Maybe longer ;o)
Thank you! I foresee a great future for you in private industry.
(I say that because the ability to write clearly is not very much
valued in government or academia...)
^ permalink raw reply
* [PATCH] git-cvsimport: Add -A <author-conv-file> option
From: Andreas Ericsson @ 2006-01-12 23:38 UTC (permalink / raw)
To: git
This patch adds the option to specify an author name/email conversion
file in the format
exon=Andreas Ericsson <ae@op5.se>
spawn=Simon Pawn <spawn@frog-pond.org>
which will translate the ugly cvs authornames to the more informative
git style.
The info is saved in $GIT_DIR/cvs-authors, so that subsequent
incremental imports will use the same author-info even if no -A
option is specified. If an -A option *is* specified, the info in
$GIT_DIR/cvs-authors is appended/updated appropriately.
Docs updated accordingly.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
Documentation/git-cvsimport.txt | 20 ++++++++++++++
git-cvsimport.perl | 56 +++++++++++++++++++++++++++++++++++----
2 files changed, 70 insertions(+), 6 deletions(-)
a1883e11a55c4684c0c5123c75425623a54f44cf
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 01ca7ef..dfe86ce 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -89,6 +89,26 @@ If you need to pass multiple options, se
-s <subst>::
Substitute the character "/" in branch names with <subst>
+-A <author-conv-file>::
+ CVS by default uses the unix username when writing its
+ commit logs. Using this option and an author-conv-file
+ in this format
+
+ exon=Andreas Ericsson <ae@op5.se>
+ spawn=Simon Pawn <spawn@frog-pond.org>
+
+ git-cvsimport will make it appear as those authors had
+ their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
+ all along.
+
+ For convenience, this data is saved to $GIT_DIR/cvs-authors
+ each time the -A option is provided and read from that same
+ file each time git-cvsimport is run.
+
+ It is not recommended to use this feature if you intend to
+ export changes back to CVS again later with
+ git-link[1]::git-cvsexportcommit.
+
OUTPUT
------
If '-v' is specified, the script reports what it is doing.
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 8619e7d..8d493c2 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -29,19 +29,52 @@ use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, $opt_s,$opt_m,$opt_M);
+our($opt_h,$opt_o,$opt_v,$opt_k,$opt_u,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_P, $opt_s,$opt_m,$opt_M,$opt_A);
+my (%conv_author_name, %conv_author_email);
sub usage() {
print STDERR <<END;
Usage: ${\basename $0} # fetch/update GIT from CVS
- [-o branch-for-HEAD] [-h] [-v] [-d CVSROOT]
- [-p opts-for-cvsps] [-C GIT_repository] [-z fuzz]
- [-i] [-k] [-u] [-s subst] [-m] [-M regex] [CVS_module]
+ [-o branch-for-HEAD] [-h] [-v] [-d CVSROOT] [-A author-conv-file]
+ [-p opts-for-cvsps] [-C GIT_repository] [-z fuzz] [-i] [-k] [-u]
+ [-s subst] [-m] [-M regex] [CVS_module]
END
exit(1);
}
-getopts("hivmkuo:d:p:C:z:s:M:P:") or usage();
+sub read_author_info($) {
+ my ($file) = @_;
+ my $user;
+ open my $f, '<', "$file" or die("Failed to open $file: $!\n");
+
+ while (<$f>) {
+ chomp;
+ # Expected format is this;
+ # exon=Andreas Ericsson <ae@op5.se>
+ if (m/^([^ \t=]*)[ \t=]*([^<]*)(<.*$)\s*/) {
+ $user = $1;
+ $conv_author_name{$1} = $2;
+ $conv_author_email{$1} = $3;
+ # strip trailing whitespace from author name
+ $conv_author_name{$1} =~ s/\s*$//;
+ }
+ }
+ close ($f);
+}
+
+sub write_author_info($) {
+ my ($file) = @_;
+ open my $f, '>', $file or
+ die("Failed to open $file for writing: $!");
+
+ foreach (keys %conv_author_name) {
+ print $f "$_=" . $conv_author_name{$_} .
+ " " . $conv_author_email{$_} . "\n";
+ }
+ close ($f);
+}
+
+getopts("hivmkuo:d:p:C:z:s:M:P:A:") or usage();
usage if $opt_h;
@ARGV <= 1 or usage();
@@ -453,7 +486,7 @@ CVS2GIT_HEAD exists.
Make sure your working directory corresponds to HEAD and remove CVS2GIT_HEAD.
You may need to run
- git-read-tree -m -u CVS2GIT_HEAD HEAD
+ git read-tree -m -u CVS2GIT_HEAD HEAD
EOM
}
system('cp', "$git_dir/HEAD", "$git_dir/CVS2GIT_HEAD");
@@ -489,6 +522,14 @@ EOM
-d $git_dir
or die "Could not create git subdir ($git_dir).\n";
+# now we read (and possibly save) author-info as well
+-f "$git_dir/cvs-authors" and
+ read_author_info("$git_dir/cvs-authors");
+if ($opt_A) {
+ read_author_info($opt_A);
+ write_author_info("$git_dir/cvs-authors");
+}
+
my $pid = open(CVS,"-|");
die "Cannot fork: $!\n" unless defined $pid;
unless($pid) {
@@ -702,6 +743,9 @@ while(<CVS>) {
s/\s+$//;
if (/^(.*?)\s+<(.*)>/) {
($author_name, $author_email) = ($1, $2);
+ } elsif ($conv_author_name{$_}) {
+ $author_name = $conv_author_name{$_};
+ $author_email = $conv_author_email{$_};
} else {
$author_name = $author_email = $_;
}
--
1.1.1-g4c34-dirty
^ permalink raw reply related
* 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
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