* [ANNOUNCE] Cogito-0.16.1
From: Petr Baudis @ 2005-12-12 1:12 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hello,
this is Cogito version 0.16.1, the next stable release of the
human-friendly version control UI for the Linus' GIT tool. Share
and enjoy at:
http://www.kernel.org/pub/software/scm/cogito/
This crispy new release gives you a few minor to medium bugfixes and
a significant cg-patch speedup. You can reach it as the "v0.16" branch
of the Cogito repository. Note that this is just the stable branch, more
interesting stuff is happenning (and especially going to happen) on the
master development branch; if everything goes well, I might release
cogito-0.17rc1 at the end of this week).
So the new stuff since 0.16 is:
Jonas Fonseca:
cg-merge: Improve the hook description
cg-status: handle subdirs when listing heads
Petr Baudis:
Fix cg-admin-setuprepo warning on missing post-update hook
Initial cg-push to a remote branch wouldn't work properly
Fix cg-object-id <singleletter>
Fix unsafe sed usage in scripts
cg-clean -n will just pretend to remove stuff
Make cg-clean whitespace-safe
If you use filenames with spaces _and_ cg-clean (or cg-clean
at all, after all), you should certainly upgrade!
bash-3.1-related fixes
Fix broken cg-log FILE in subdirectory
Drastically speed up cg-patch
cogito-0.16.1
Happy hacking,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.16.1
From: Petr Baudis @ 2005-12-12 1:14 UTC (permalink / raw)
To: git
In-Reply-To: <20051212011210.GC12373@pasky.or.cz>
Dear diary, on Mon, Dec 12, 2005 at 02:12:10AM CET, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> this is Cogito version 0.16.1, the next stable release of the
> human-friendly version control UI for the Linus' GIT tool.
By the way, did anyone receive the 0.16 announcement? I have it in my
=sent mailbox, but not in either the git@ or linux-kernel@ mailboxes...
*perplexed*
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [ANNOUNCE] GIT 0.99.9m aka 1.0rc5
From: Junio C Hamano @ 2005-12-12 2:34 UTC (permalink / raw)
To: git, linux-kernel
GIT 0.99.9m aka 1.0rc5 is found at usual places:
RPM
http://kernel.org:/pub/software/scm/git/RPMS/
Debian
http://kernel.org:/pub/software/scm/git/debian/
Notable changes since 1.0rc4 are:
- archimport updates.
- gitk updates to work around Tcl/Tk i18n issues.
- better portability to Solaris and AIX.
- slimmed down update-server-info.
- conflicting merge leaves higher stages in index around.
- http-fetch does not fail to write refs in subdirectories.
- git-prune cannot be made to lose referened objects by mistake anymore.
- a lot of documentation fixes.
We are now feature complete and I am hoping that I can push the
same out sometime in the coming week tagged as v1.0, after
giving it some time to shake out any possible last-minute bugs.
Right now, proposed updates branch has sample patches for the
usage string clean-up from Fredrik Kuivinen for people to
comment on; it is not a complete series yet and makes some tests
fail. I personally feel this series can and probably should
wait post 1.0.
-- >8 --
Alex Riesen:
use "git init-db" in tests
Daniel Barkalow:
Warn when send-pack does nothing
Clean up file descriptors when calling hooks.
Allow saving an object from a pipe
Eric Wong:
archimport: first, make sure it still compiles
archimport: remove String::ShellQuote dependency.
archimport: fix -t tmpdir switch
archimport: remove git wrapper dependency
archimport: add -D <depth> and -a switch
archimport: safer log file parsing
archimport: Add the accurate changeset applyer
archimport: Fix a bug I introduced in the new log parser
archimport: fix a in new changeset applyer addition
Jason Riedy:
Document config.mak in INSTALL.
Initial AIX portability fixes.
Use printf rather than echo -n.
Jon Loeliger:
Added documentation for few missing options.
Junio C Hamano:
compat/setenv: do not free what we fed putenv(3).
git.c: two fixes, gitsetenv type and off-by-one error.
show-branch: allow glob pattern to name branches to show.
Documentation: rebase does not use cherry-pick anymore.
struct tree: remove unused field "parent"
git.c: remove excess output for debugging when command is too long.
sha1_file.c: make sure packs in an alternate odb is named properly.
server-info.c: drop unused D lines.
server-info: stop sorting packs by latest date.
server-info: throw away T computation as well.
Documentation: talk about pathspec in bisect.
Documentation: git-mv manpage workaround.
Documentation: git-diff asciidoc table workaround.
Documentation: push/receive hook references.
Documentation: shared repository management in tutorial.
server-info.c: use pack_local like everybody else.
server-info.c: and two functions are not used anymore.
config.c: remove unnecessary header in minimum configuration file.
Clean up compatibility definitions.
Fix 5501 test
git-mv to work with Perl 5.6
hash-object: -- and --help
init-db: check extra arguments and complain.
write-tree: check extra arguments and die but be a bit more helpful.
Documentation: hash-object.
Documentaiton (read-tree): update description of 3-way
git-merge-one-file: resurrect leading path creation.
qsort() ptrdiff_t may be larger than int
checkout-index: allow checking out from higher stages.
git-merge-one: new merge world order.
update-index: allow --index-info to add higher stages.
Documentation: git.html/git.7
Documentation(glossary): minor formatting clean-ups.
Documentation(cvs-migration): minor cleanups.
Documentation(tutorial): adjust merge example to the new merge world order.
refs.c: make sure leading directories exist before writing a ref.
Make sure we use compat/subprocess.py with Python 2.3 while running tests.
Documentation: recursive is the default strategy these days.
show-branch: comment typo
Documentation: git-prune
qsort(): ptrdiff_t may be larger than int
git-prune: never lose objects reachable from our refs.
Use GIT_EXEC_PATH explicitly for initial git-init-db in tests.
Everyday GIT with 20 commands
Link Everyday GIT to main documentation tree.
t3300: funny name test
t0000: catch trivial pilot errors.
format-patch: use same number of digits in numbers
merge-recursive: leave unmerged entries in the index.
merge-recursive: cleanup setIndexStages
t/t6022: a new test for renaming merge.
Nikolai Weibull:
Document the --non-empty command-line option to git-pack-objects.
Fix the description of --utf8 and --keep to git-am.
Use uniform description for the '--' option.
Documentation/git-commit.txt: Add long options and -- to documentation.
Documentation/git-verify-pack.txt: added documentation for --.
Documentation/git-cvsimport.txt: Fix a slight glitch in description heading.
Documentation/git-cherry-pick: Add --replay and --no-commit.
Add documentation for git-revert and git-cherry-pick.
Add documentation for the --topo-order option to git-show-branch.
Documentation/git-format-patch.txt: Add --signoff, --check, and long option-names.
Documentation/git-ls-remote.txt: Add -h and -t.
Documentation/git-repack.txt: Add -l and -n.
Documentation/git-http-fetch.txt: Document the commit-id argument.
Documentation/git-update-server-info.txt: Add -f alias for --force to documentation.
Documentation/git-tag.txt: Fix the order of sections (DESCRIPTION should come before OPTIONS).
Documentation/git-read-tree.txt: Add --reset to SYNOPSIS.
Paul Mackerras:
gitk: Factored out some common code into a new start_rev_list procedure
gitk: Some improvements for the code for updating the display
gitk: Work around Tcl's non-standard names for encodings
Petr Baudis:
Update the git-ls-tree documentation
Document the --(no-)edit switch of git-revert and git-cherry-pick
Sven Verdoolaege:
gitk: add Update menu item.
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.16.1
From: Don Koch @ 2005-12-12 3:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051212011411.GY22159@pasky.or.cz>
On Mon, 12 Dec 2005 02:14:11 +0100
Petr Baudis wrote:
> By the way, did anyone receive the 0.16 announcement? I have it in my
> =sent mailbox, but not in either the git@ or linux-kernel@ mailboxes...
> *perplexed*
I see the 0.16 RC1 and RC2 mails, but not the 0.16 announcement. When didn't
you send it?
> Thanks,
>
> --
> Petr "Pasky" Baudis
---
Don Koch
http://www.krl.com/
^ permalink raw reply
* Re: Latest cogito broken with bash-3.1
From: Marcel Holtmann @ 2005-12-12 9:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051212002631.GW22159@pasky.or.cz>
Hi Petr,
> > There exists also another problem with the new bash. It is the broken
> > pipe error from cg-log.
> >
> > cg-log: line 141: echo: write error: Broken pipe
> >
> > The line number varies depending how much you scrolled and when you
> > scrolled to the end no broken pipe error comes up. Do you have any idea
> > on how to deal with this. I saw your comment about that bash is broken
> > and the extra trap command, but it doesn't help. I never saw that
> > problem with older versions of bash.
>
> Then that's quite funny, one-line broken pipe message has been always
> there (in the past it looked much worse, we thankfully managed to bring
> it down to this at least).
I have some machines where I stopped installing the latest bash version
and they don't have this problem. With bash-2.05b.0 and bash-3.00.16 I
never (and really mean never) saw this problem.
It is not related to this, but the make-3.81beta3 breaks all my Debian
package rules and I don't have the slightest idea why. It seems that
they try to fix some Posix issues and make it worse then any better :(
Regards
Marcel
^ permalink raw reply
* Re: Latest cogito broken with bash-3.1
From: Petr Baudis @ 2005-12-12 10:40 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: git
In-Reply-To: <1134379801.1468.5.camel@blade>
Hi,
Dear diary, on Mon, Dec 12, 2005 at 10:30:01AM CET, I got a letter
where Marcel Holtmann <marcel@holtmann.org> said that...
> > > There exists also another problem with the new bash. It is the broken
> > > pipe error from cg-log.
> > >
> > > cg-log: line 141: echo: write error: Broken pipe
> > >
> > > The line number varies depending how much you scrolled and when you
> > > scrolled to the end no broken pipe error comes up. Do you have any idea
> > > on how to deal with this. I saw your comment about that bash is broken
> > > and the extra trap command, but it doesn't help. I never saw that
> > > problem with older versions of bash.
> >
> > Then that's quite funny, one-line broken pipe message has been always
> > there (in the past it looked much worse, we thankfully managed to bring
> > it down to this at least).
>
> I have some machines where I stopped installing the latest bash version
> and they don't have this problem. With bash-2.05b.0 and bash-3.00.16 I
> never (and really mean never) saw this problem.
this might be some Debian patches then. Indeed, with bash-3.00.16 on
both systems, the line is shown on my home Gentoo system but not on my
Debian machine at work. On RHEL at kernel.org the line is not printed
either. Hmm. So either it's not really bash what emits this (but what
then?) or most of the distributions override that stupid bash behaviour
with a patch already. And Debian didn't foreport the patch to bash-3.1.
Well, this would make the weekend research more interesting, at least.
;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Latest cogito broken with bash-3.1
From: Marcel Holtmann @ 2005-12-12 11:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051212104039.GJ10680@pasky.or.cz>
Hi Petr,
> > > > There exists also another problem with the new bash. It is the broken
> > > > pipe error from cg-log.
> > > >
> > > > cg-log: line 141: echo: write error: Broken pipe
> > > >
> > > > The line number varies depending how much you scrolled and when you
> > > > scrolled to the end no broken pipe error comes up. Do you have any idea
> > > > on how to deal with this. I saw your comment about that bash is broken
> > > > and the extra trap command, but it doesn't help. I never saw that
> > > > problem with older versions of bash.
> > >
> > > Then that's quite funny, one-line broken pipe message has been always
> > > there (in the past it looked much worse, we thankfully managed to bring
> > > it down to this at least).
> >
> > I have some machines where I stopped installing the latest bash version
> > and they don't have this problem. With bash-2.05b.0 and bash-3.00.16 I
> > never (and really mean never) saw this problem.
>
> this might be some Debian patches then. Indeed, with bash-3.00.16 on
> both systems, the line is shown on my home Gentoo system but not on my
> Debian machine at work. On RHEL at kernel.org the line is not printed
> either. Hmm. So either it's not really bash what emits this (but what
> then?) or most of the distributions override that stupid bash behaviour
> with a patch already. And Debian didn't foreport the patch to bash-3.1.
I just verified that on my Ubuntu Dapper system where I had a copy of
the old bash package lying around. The bash-3.0 works fine, but the
bash-3.1 produces this error. So it is definitely bash related.
Regards
Marcel
^ permalink raw reply
* patches between commits
From: Bahadir Balban @ 2005-12-12 15:31 UTC (permalink / raw)
To: git
Hi,
A very basic question - how could I generate patches across different commits?
Suppose I have a HEAD branch, which is the latest. And I want to
generate `individual' patches for each commit I did since the
beginning of development for this branch.
Secondly, is the sha1 of a tree what appears next to each commit when
I type git-log? Is this the only command that lets us know the sha1's
of commits?
Thanks,
Bahadir
^ permalink raw reply
* Re: Latest cogito broken with bash-3.1
From: Linus Torvalds @ 2005-12-12 15:32 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Petr Baudis, git
In-Reply-To: <1134385342.1468.27.camel@blade>
On Mon, 12 Dec 2005, Marcel Holtmann wrote:
>
> I just verified that on my Ubuntu Dapper system where I had a copy of
> the old bash package lying around. The bash-3.0 works fine, but the
> bash-3.1 produces this error. So it is definitely bash related.
It's been around forever, and it's a bash default installation issue. It's
just that all sane distributions will change the default.
Sounds like debian forgot to do that when upgrading to bash-3.1.
The magic incantation is hidden in the bash FAQ (E2):
You can build a version of bash that will not report SIGPIPE errors
by uncommenting the definition of DONT_REPORT_SIGPIPE in the file
config-top.h.
and I still don't understand why it's not the default. Oh, well.
Linus
^ permalink raw reply
* make install bug?
From: eschvoca @ 2005-12-12 15:35 UTC (permalink / raw)
To: git
Using the latest git on "make prefix=/home/eschvoca/apps/git-0.99.9m
install" I get the following error:
make[1]: Entering directory `/home/eschvoca/downloads/git-0.99.9m/templates'
: no custom templates yet
install -d -m755 '/home/eschvoca/share/git-core/templates/'
(cd blt && tar cf - .) | \
(cd '/home/eschvoca/share/git-core/templates/' && tar xf -)
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Error exit delayed from previous errors
make[1]: *** [install] Error 2
I can fix the problem by changing templates/Makefile to the following:
install: all
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(template_dir))
(cd blt && $(TAR) cf - . > /tmp/a.tar) | \
(cd $(call shellquote,$(DESTDIR)$(template_dir)) && $(TAR) xf /tmp/a.tar)
^ permalink raw reply
* Missing links in documentation
From: Johannes Schindelin @ 2005-12-12 15:53 UTC (permalink / raw)
To: git, junkio
Hi,
just to let you know: the following files are not linked:
git-cvsexportcommit.txt
git-http-push.txt
git-pack-redundant.txt
pack-protocol.txt
Unfortunately, I don't have time to work on that, since I hunted a bug
with t6022 for two hours, only to discover that somehow make did not pick
up the new git-merge-recursive.py, but used the old one. And no, I cannot
reproduce this behaviour .-(
Ciao,
Dscho
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Linus Torvalds @ 2005-12-12 16:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: linux, git
In-Reply-To: <7vmzj9zwfu.fsf@assigned-by-dhcp.cox.net>
On Fri, 9 Dec 2005, Junio C Hamano wrote:
>
> Exactly. That's why task oriented list would be most useful.
> Here is a starter.
>
>
> Everyday GIT Cheat Sheet Or Git With 20 Commands
> ================================================
Would this file perhaps also have examples?
I really think a lot of people learn better from examples than from having
pointers to git programs that can be useful.
For example, earlier today I got the bash tar-ball because I had forgotten
what the magic config option was to make bash do the right thing wrt pipe
write errors. And because I'm totally dependent on "git grep" these days,
I turned that tar-ball into a git archive. It's really a sinfully simple
thing to do, but I don't think we mention that anywhere in the docs.
Here's what I did:
# Extract the thing as normal
zcat < bash-3.0.tar.gz | tar xvf -
cd bash-3.0/
# make a git archive out of it
git init-db
git add .
git commit
and that's it. That creates a git archive from a tar-ball. Very simple,
and short sequences like these would make tons of sense for a "cheat
sheet" like yours, and I really think most people can look at those three
git commands and suddenly they understand what they do a lot better than
by reading the man-pages.
Or maybe it's just me. But I know _I_ understand things better by seeing
the "context" that they are used in. Then I go to man-pages later on, if I
want to know the details.
No?
Linus
^ permalink raw reply
* diff-core segfault
From: Darrin Thompson @ 2005-12-12 16:29 UTC (permalink / raw)
To: git
$ mkdir a
$ cd a/
$ git-init-db
defaulting to local storage area
$ touch a
$ git-update-index --add a
$ git-commit -m 'message'
Committing initial tree 496d6428b9cf92981dc9495211e6e1120fb6f2ba
$ echo hello >a
$ git-diff-files
:100644 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
0000000000000000000000000000000000000000 M a
$ git-diff-files -B
Segmentation fault
Disclaimer: I'm running 1.0rc2. I did some searching of recent mailing
list posts and commits. I see no evidence that this has been addressed.
Could someone confirm that this exists on more recent git heads and fix
if needed?
Thanks.
--
Darrin
^ permalink raw reply
* Re: diff-core segfault
From: Johannes Schindelin @ 2005-12-12 16:56 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git
In-Reply-To: <1134404990.5928.4.camel@localhost.localdomain>
Hi,
On Mon, 12 Dec 2005, Darrin Thompson wrote:
> $ git-diff-files -B
> Segmentation fault
This looks exactly like the problem on cygwin which is fixed by using
NO_MMAP=YesPlease.
How about enabling NO_MMAP=YesPlease on cygwin per default? I think there
are enough cases where it helps. If it is too slow *and* the user knows
what she's doing, she can recompile NO_MMAP=NoNoNo.
Opinions, please?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow saving an object from a pipe
From: Daniel Barkalow @ 2005-12-12 17:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64pwuyny.fsf@assigned-by-dhcp.cox.net>
On Sat, 10 Dec 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > In order to support getting data into git with scripts, this adds a
> > --stdin option to git-hash-object, which will make it read from stdin.
>
> Thanks, will apply.
>
> To be honest, though, I am still debating myself about the merit
> of not having to have a temporary file. Because we need the
> size of the blob available before starting to hash (i.e. we
> cannot say "atend"), index_pipe ends up keeping the whole blob
> data in memory, which is not much better than the caller storing
> it in a temporary file and driving the normal hash-object from
> the command line anyway.
It's not much better for efficiency, but it's a whole lot easier to write
the script without having to worry about a temporary file, what could
happen to it while you're trying to use it, and making sure it gets
cleaned up afterwards. It can also save on disk writes, depending on where
you put it and how the system is configured.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: patches between commits
From: Alex Riesen @ 2005-12-12 17:33 UTC (permalink / raw)
To: Bahadir Balban; +Cc: git
In-Reply-To: <7ac1e90c0512120731g3eacdcf0s7e9d1226c88dce73@mail.gmail.com>
Bahadir Balban, Mon, Dec 12, 2005 16:31:12 +0100:
> Suppose I have a HEAD branch, which is the latest. And I want to
> generate `individual' patches for each commit I did since the
> beginning of development for this branch.
That is what I think "git format-patch <commit>" is for. It will
generate patches to bring "<commit>" to HEAD.
> Secondly, is the sha1 of a tree what appears next to each commit when
> I type git-log? Is this the only command that lets us know the sha1's
> of commits?
"git rev-list", I think
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Timo Hirvonen @ 2005-12-12 17:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, linux, git
In-Reply-To: <Pine.LNX.4.64.0512120827440.15597@g5.osdl.org>
On Mon, 12 Dec 2005 08:34:12 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:
> Or maybe it's just me. But I know _I_ understand things better by seeing
> the "context" that they are used in. Then I go to man-pages later on, if I
> want to know the details.
Me too. BTW, new users very likely read tutorial.txt first. But it is
way too low level (git-cat-file, git-write-tree...). Maybe those low
level commands should be described in technical/ instead? The tutorial
would be logical place for examples.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Junio C Hamano @ 2005-12-12 17:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux, git
In-Reply-To: <Pine.LNX.4.64.0512120827440.15597@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> ... But I know _I_ understand things better by seeing
> the "context" that they are used in. Then I go to man-pages later on, if I
> want to know the details.
>
> No?
Absolutely. It's the way how I pick up new things for me too.
^ permalink raw reply
* Re: make install bug?
From: Junio C Hamano @ 2005-12-12 17:54 UTC (permalink / raw)
To: eschvoca; +Cc: git
In-Reply-To: <2b05065b0512120735v26c8343aged48165f3ccc5892@mail.gmail.com>
eschvoca <eschvoca@gmail.com> writes:
> I can fix the problem by changing templates/Makefile to the following:
>
> install: all
> $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(template_dir))
> (cd blt && $(TAR) cf - . > /tmp/a.tar) | \
> (cd $(call shellquote,$(DESTDIR)$(template_dir)) && $(TAR) xf /tmp/a.tar)
Here is my guess. Could you try, from your interactive shell:
$ (unset CDPATH; make install)
first without the above "fix" (your "fixed" pipe does not make
any sense --- what are the data passed between pipe upstream and
downstream?)?
If that makes the problem go away, then your environment is
broken --- my guess is that you are exporting CDPATH to
non-interactive scripts. Don't do that.
I once googled for "CDPATH" and saw many "guide to unix" type
webpages talk about "CDPATH environment variable"; they are the
real culprit to cause this confusion in peoples' .bash_profile.
CDPATH might be a nice variable for interactive shells, but is a
horrible one if made environment.
^ permalink raw reply
* Re: patches between commits
From: Junio C Hamano @ 2005-12-12 17:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051212173352.GA3007@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Bahadir Balban, Mon, Dec 12, 2005 16:31:12 +0100:
>> Suppose I have a HEAD branch, which is the latest. And I want to
>> generate `individual' patches for each commit I did since the
>> beginning of development for this branch.
>
> That is what I think "git format-patch <commit>" is for. It will
> generate patches to bring "<commit>" to HEAD.
Yes, but I think the real question Bahadir wants to know is what
the <commit> parameter should be, if you want to export the
whole history (I do not think there is any suitable argument to
"format-patch" that does this).
>> Secondly, is the sha1 of a tree what appears next to each commit when
>> I type git-log? Is this the only command that lets us know the sha1's
>> of commits?
Depends on what you have, to ask the question "what are their
object names?".
- I have this commit, how do I find out its object name?
E.g. I want to know the HEAD commit's object name, second to
the last commit on "test" branch.
$ git rev-parse --verify HEAD
$ git rev-parse --verify test^
- I have bunch of commits leading to the head of my "test"
branch. What are they?
$ git rev-list test ;# unadorned list of object names and nothing else
$ git rev-list --pretty test ;# this is git-log
$ git whatchanged -m -M -p test ;# with patch in full glory
^ permalink raw reply
* Re: as promised, docs: git for the confused
From: Linus Torvalds @ 2005-12-12 18:18 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: junkio, linux, git
In-Reply-To: <20051212195319.11d41269.tihirvon@gmail.com>
On Mon, 12 Dec 2005, Timo Hirvonen wrote:
>
> Me too. BTW, new users very likely read tutorial.txt first. But it is
> way too low level (git-cat-file, git-write-tree...). Maybe those low
> level commands should be described in technical/ instead? The tutorial
> would be logical place for examples.
I'd almost suggest skipping the technical notes in the current tutorial,
and just gearing it directly more towards a regular user.
When I started writing it, I cared more about people understanding how git
works internally. I think that was useful too, but I suspect that it's
less useful than just knowing how to use git, and there _are_ enough
people out there that understand how git works under the hood that it
probably would be much better to concentrate on getting people _first_
used to using git, and then having a separate tutorial for "what goes
under the hood".
So instead of teaching people about "git-read-tree --reset HEAD" etc that
you'd never know on your own, just teach about "git reset". And not
bothering with the "git-write-tree + git-commit-tree + git-update-ref"
approach, just make people use "git commit" from the very beginning.
Anybody willing to just strip out the raw internals talk?
Then we could add a small section about importing from a tar-file.
Linus
^ permalink raw reply
* Re: diff-core segfault
From: Junio C Hamano @ 2005-12-12 18:50 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git
In-Reply-To: <1134404990.5928.4.camel@localhost.localdomain>
Darrin Thompson <darrint@progeny.com> writes:
> Could someone confirm that this exists on more recent git heads and fix
> if needed?
(1) Yup. I can reproduce it.
(2) Will look into it when able.
^ permalink raw reply
* Delitifier broken (Re: diff-core segfault)
From: Junio C Hamano @ 2005-12-12 18:59 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git, Linus Torvalds
In-Reply-To: <7vmzj6i206.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Darrin Thompson <darrint@progeny.com> writes:
>
>> Could someone confirm that this exists on more recent git heads and fix
>> if needed?
>
> (1) Yup. I can reproduce it.
> (2) Will look into it when able.
This is not just "diff". Our deltify code is half-broken, and
in the worst case this can corrupt our packs if an empty blob is
involved.
The problem is if from_size or to_size is empty, it does not
produce any.
if (!from_size || !to_size || delta_prepare(from_buf, from_size, &bdf))
return NULL;
I think either we need to make the users more careful or fix
deltifier to produce trivial delta. I'd vote for the latter;
let me rig up something.
^ permalink raw reply
* [PATCH] add git-nntp-post: post git commit diffs as news messages
From: Artem Khodush @ 2005-12-12 19:39 UTC (permalink / raw)
To: git
This is a script that exports git repository to a nntp server,
as prompted in http://marc.theaimsgroup.com/?l=git&m=113385203614980&w=2
Tested with INN on localhost with a copy of git repository
(newsgroups must be created beforehand, and inn.conf artcutoff:
and expire.ctl /remember/: parameters better set to never).
I'm not sure if I got this one right, though:
> A merge commit would probably become a multipart with usually 2
> attachments (but N attachments for a N-way octopus), showing
> diff from each branch.
Currently for merges, it posts diff with parent[0] as first attachment,
and diff between parent[i] and git-merge-base parent[i] parent[0]
as each next attachment.
Signed-off-by: Artem Khodush <greenkaa@gmail.com>
---
Makefile | 2
git-nntp-post.perl | 450 ++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 451 insertions(+), 1 deletions(-)
create mode 100755 git-nntp-post.perl
bde2562197562d21fb0f66e83e51864c9f648c6a
diff --git a/Makefile b/Makefile
index a851f56..b9ed12c 100644
--- a/Makefile
+++ b/Makefile
@@ -80,7 +80,7 @@ SCRIPT_SH = \
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
- git-rename.perl git-shortlog.perl
+ git-rename.perl git-shortlog.perl git-nntp-post.perl
SCRIPT_PYTHON = \
git-merge-recursive.py
diff --git a/git-nntp-post.perl b/git-nntp-post.perl
new file mode 100755
index 0000000..13d0293
--- /dev/null
+++ b/git-nntp-post.perl
@@ -0,0 +1,450 @@
+#!/usr/bin/perl -w
+#
+# Copyright (C) 2005 Artem Khodush <greenkaa@gmail.com>
+#
+# This program contains parts from gitweb.cgi,
+# (C) 2005, Kay Sievers <kay.sievers@vrfy.org>
+# (C) 2005, Christian Gierke <ch@gierke.de>
+
+# This program is licensed under the GPL v2, or a later version
+
+use warnings;
+use strict;
+use Net::NNTP;
+use HTTP::Date;
+use MIME::Lite;
+#use MIME::Entity; # interchangeable with the above, but slower
+
+BEGIN {
+ if( $^V ge v5.8.0 ) {
+ require Encode; import Encode;
+ }else {
+ no strict "refs";
+ *{"Encode::encode"}=sub { my ($a,$s,$b)=@_; return $s; };
+ }
+}
+
+# Read commits, starting from heads given on the command line,
+# (or all repository heads), and post each commit diff
+# to a newsgroup, starting with earliest commit.
+# Commits from different branches go to different newsgroups,
+# named after the head names.
+# The order of heads on the command line is important:
+# when branching point is encountered, the branch specified
+# earlier is considered to be the trunk, continuing into the past.
+
+# For commits with more than one parent, multipart message
+# is posted with first part containing diff with parent[0], and each
+# other part containing diff between parent[i] and
+# git-merge-base parent[i] parent[0] (thus showing summary change
+# followed by what was merged from each branch)
+
+# Subset of the git-rev-list options (--max-age, --min-age and
+# commits starting with ^) is accepted to limit the number of
+# commits posted.
+# Exactly one (the latest) commit may be posted with --one option.
+
+# By default, it posts to localhost nntp port (119), this may
+# be changed by --nntp-host and --nntp-port.
+
+# The newsgroup names are formed by taking the GIT_DIR
+# without the trailing .git, replacing / with ., and appending
+# the head name. This can be overriden with --newsgroup-prefix.
+
+# Each posted message gets an id of the form
+# <commit.SHA1@kernel.org>, and the nntp server is relied upon
+# to reject duplicate posts, and to keep the posting order intact.
+# Hence, with ordinary news servers, each commit
+# can appear only in the newsgroups it was originally posted
+# (currently only one), unless someone care to implement
+# logic for rewriting posts, or a special nntp server.
+
+sub usage() {
+ print STDERR <<EOT;
+$0 [OPTIONS] [<head> ...] [^<commit> ...]
+--nntp-host <host>
+--nntp-port <port>
+--newsgroup-prefix <prefix>
+--max-age <epoch>
+--min-age <epoch>
+--one
+--print-newsgroup-names
+--print-messages
+EOT
+ exit(1);
+}
+
+my $GIT_DIR = `git rev-parse --git-dir`;
+chop $GIT_DIR;
+exit 1 if $?; # rev-parse would have given "not a git dir" message.
+chomp($GIT_DIR);
+
+my $DOMAIN_ID="kernel.org"; # sufficiently unique string for Path and
Message-Id headers
+
+my $NNTP_HOST="localhost";
+my $NNTP_PORT="119";
+my $NEWSGROUP_PREFIX;
+my $MAX_AGE;
+my $MIN_AGE;
+my $ONLY_ONE;
+my %HEADS;
+my @STOP_COMMITS;
+my $PRINT_NEWSGROUP_NAMES;
+my $PRINT_MESSAGES;
+
+my $HEAD_COUNT=0;
+
+while( my $arg=shift ) {
+ if( $arg eq "-h" || $arg eq "--nntp-host" ) {
+ $NNTP_HOST=shift or usage();
+ }elsif( $arg=~/^--nntp-host=(.+)$/ ) {
+ $NNTP_HOST=$1;
+ }elsif( $arg eq "-p" || $arg eq "--nntp-port" ) {
+ $NNTP_PORT=shift or usage();
+ }elsif( $arg=~/^--nntp-port=(.+)$/ ) {
+ $NNTP_PORT=$1;
+ }elsif( $arg eq "-n" || $arg eq "--newsgroup-prefix" ) {
+ $NEWSGROUP_PREFIX=shift or usage();
+ }elsif( $arg=~/^--newsgroup-prefix=(.+)$/ ) {
+ $NEWSGROUP_PREFIX=$1;
+ }elsif( $arg eq "-a" || $arg eq "--max-age" ) {
+ $MAX_AGE=shift or usage();
+ }elsif( $arg=~/^--max-age=(.+)$/ ) {
+ $MAX_AGE=$1;
+ }elsif( $arg eq "-i" || $arg eq "--min-age" ) {
+ $MIN_AGE=shift or usage();
+ }elsif( $arg=~/^--min-age=(.+)$/ ) {
+ $MIN_AGE=$1;
+ }elsif( $arg eq "-1" || $arg eq "--one" ) {
+ $ONLY_ONE=1;
+ }elsif( $arg eq "--print-newsgroup-names" ) {
+ $PRINT_NEWSGROUP_NAMES=1;
+ }elsif( $arg eq "--print-messages" ) {
+ $PRINT_MESSAGES=1;
+ }elsif( $arg=~/^\^/ ) {
+ push @STOP_COMMITS, $arg;
+ }else {
+ if( "HEAD" eq $arg ) {
+ (undef,$arg)=split( " ", `git-name-rev HEAD` );
+ }
+ $HEADS{$arg}->{order}=++$HEAD_COUNT;
+ }
+}
+
+&verify_heads;
+&read_commits;
+&propagate_branches;
+&post_commits;
+exit( 0 );
+
+sub verify_heads()
+{
+ my $repo=$GIT_DIR;
+ my $read_all_heads= 0==$HEAD_COUNT;
+ open my $fd, "-|", "git-peek-remote $repo" or die "$0: error running
git-peek-remote: $!";
+ while( my $line=<$fd> ) {
+ my ($id,$name)=split ' ', $line;
+ my $is_head=0;
+ if( "HEAD" eq $name ) {
+ $is_head=1;
+ (undef,$name)=split( " ", `git-name-rev HEAD` );
+ }
+ if( $name=~s/^refs\/heads\/// || $is_head ) {
+ # if there were heads given on the command line, take only those.
+ # otherwise, with --one, take only HEAD, without --one, take all heads.
+ if( exists( $HEADS{$name} ) || ($read_all_heads && ($is_head ||
!$ONLY_ONE)) ) {
+ $HEADS{$name}->{id}=$id;
+ }
+ }
+ }
+ close $fd or die "$0: git_get_type: unable to close fd: $!";
+ if( $read_all_heads ) {
+ #sort them
+ my $n=0;
+ for my $name (sort keys %HEADS) {
+ $HEADS{$name}->{order}=++$n;
+ }
+ # make master the first
+ $HEADS{"master"}->{order}=0 if exists $HEADS{"master"};
+ }
+ if( $ONLY_ONE && scalar( keys %HEADS )!=1 ) {
+ die "$0: --one requires exactly one head, but " . scalar( keys
%HEADS ) . " were given\n";
+ }
+ if( $PRINT_NEWSGROUP_NAMES ) { # just print them
+ for my $head (keys %HEADS) {
+ print &make_newsgroup_name( $head ) . "\n";
+ }
+ exit( 0 );
+ }
+}
+
+my %COMMITS;
+
+sub read_commits
+{
+ my $args="";
+ $args.=" --max-age $MAX_AGE" if $MAX_AGE;
+ $args.=" " . join( " ", keys %HEADS );
+ $args.=" " . join( " ", @STOP_COMMITS );
+ $args.=" --max-count=1" if $ONLY_ONE;
+ $/ = "\0";
+ open my $fd, "-|", "git-rev-list --header --parents $args" or die
"$0: error running git-rev-list: $!";
+ while( my $commit_line=<$fd> ) {
+ $commit_line =~ s/\r$//;
+ my @commit_lines = split '\n', $commit_line;
+ pop @commit_lines;
+ my %co;
+
+ my $header = shift @commit_lines;
+ if (!($header =~ m/^[0-9a-fA-F]{40}/)) {
+ next;
+ }
+ ($co{'id'}, my @parents) = split ' ', $header;
+ $co{'parents'} = \@parents;
+ while (my $line = shift @commit_lines) {
+ last if $line eq "\n";
+ if ($line =~ m/^author (.*) ([0-9]+) (.*)$/) {
+ $co{'author'} = $1;
+ $co{'author_epoch'} = $2;
+ $co{'author_tz'} = $3;
+ }elsif ($line =~ m/^committer (.*) ([0-9]+) (.*)$/) {
+ $co{'committer'} = $1;
+ $co{'committer_epoch'} = $2;
+ $co{'committer_tz'} = $3;
+ }
+ }
+ $co{'title'}="";
+ $co{'title_short'}="";
+ foreach my $title (@commit_lines) {
+ if ($title ne "") {
+ $title=~s/^\s+//;
+ $co{'title'} = chop_str($title, 80, 5);
+ # remove leading stuff of merges to make the interesting part visible
+ if (length($title) > 50) {
+ $title =~ s/^Automatic //;
+ $title =~ s/^merge (of|with) /Merge ... /i;
+ if (length($title) > 50) {
+ $title =~ s/(http|rsync):\/\///;
+ }
+ if (length($title) > 50) {
+ $title =~ s/(master|www|rsync)\.//;
+ }
+ if (length($title) > 50) {
+ $title =~ s/kernel.org:?//;
+ }
+ if (length($title) > 50) {
+ $title =~ s/\/pub\/scm//;
+ }
+ }
+ $co{'title_short'} = chop_str($title, 50, 5);
+ last;
+ }
+ }
+ # remove added spaces
+ foreach my $line (@commit_lines) {
+ $line =~ s/^ //;
+ }
+ $co{'comment'} = \@commit_lines;
+ $COMMITS{$co{'id'}}=\%co;
+ }
+ close $fd or die "$0: git_read_commit: unable to close fd: $!";
+ $/ = "\n";
+}
+
+sub propagate_branches
+{
+ for my $head (sort { $HEADS{$a}->{order} - $HEADS{$b}->{order} }
keys %HEADS) {
+ my $child_id=undef;
+ my $id=$HEADS{$head}->{id};
+ while( $id && exists $COMMITS{$id} && !exists $COMMITS{$id}->{branch} ) {
+ my $co=$COMMITS{$id};
+ $co->{branch}=$head;
+ $co->{child}=$child_id;
+ $HEADS{$head}->{start_id}=$id;
+ $child_id=$id;
+ $id=$co->{parents}->[0];
+ }
+ }
+}
+
+sub make_message_id
+{
+ my $id=shift;
+ return "<commit.$id\@$DOMAIN_ID>",
+}
+
+sub make_commit_body
+{
+ my ($id,$other_id,$from_branch)=@_;
+ my $body="";
+ my ($author, $author_epoch, $committer, $committer_epoch);
+ my $comment="";
+ if( exists $COMMITS{$id} ) { # if we have it already, spare git-cat-file
+ my $co=$COMMITS{$id};
+ ($author, $author_epoch, $committer,
$committer_epoch)=($co->{author}, $co->{author_epoch},
$co->{committer}, $co->{committer_epoch});
+ $comment=join( "\n", @{$co->{comment}} );
+ }else {
+ open my $fd0, "-|", "git-cat-file commit $id" or die "$0: error
running git-cat-file: $!";
+ my $header=1;
+ while( <$fd0> ) {
+ if( !$header ) {
+ $comment.=$_;
+ }elsif( m/^\s+$/ ) {
+ $header=0;
+ }elsif( m/^author (.*) ([0-9]+) (.*)$/ ) {
+ $author=$1;
+ $author_epoch=$2;
+ }elsif( m/^committer (.*) ([0-9]+) (.*)$/ ) {
+ $committer=$1;
+ $committer_epoch=$2;
+ }
+ }
+ close $fd0;
+ }
+ if( $from_branch ) {
+ my $merge_base=`git-merge-base $id $other_id`;
+ chop $merge_base;
+ $body.="merged from $id\n\n---\n";
+ $other_id=$merge_base if $merge_base;
+ }else {
+ my ($author_name,$author_email)=split( " ", $author );
+ my ($committer_name,$committer_email)=split( " ", $committer );
+ $body.="committer $committer " . time2str( $committer_epoch ) .
"\n" unless $author_name eq $committer_name;
+ $body.=$comment;
+ $body.="\n---\n\n";
+ }
+ if( $other_id ) {
+ open my $fd1, "-|", "git-diff-tree -p $other_id $id | git-apply
--stat --summary" or die "$0: error running git-diff-tree: $!";
+ while( <$fd1> ) {
+ $body.=$_;
+ }
+ close $fd1;
+ $body.="\n";
+ open my $fd2, "-|", "git-diff-tree -p $other_id $id" or die "$0:
error running git-diff-tree again: $!";
+ while( <$fd2> ) {
+ $body.=$_;
+ }
+ close $fd2;
+ }
+ return $body;
+}
+
+sub make_commit_message
+{
+ my ($newsgroup,$co)=@_;
+ my $n_parents=scalar( @{$co->{parents}} );
+ my $parents=join( " ", map( make_message_id( $_ ), @{$co->{parents}} ) );
+ my $from=$co->{author};
+ $from=$co->{committer} unless $from;
+ $from="unknown author" unless $from;
+ my $subject=$co->{title_short};
+ $subject="undescribed patch" unless $subject;
+ my $msg=MIME::Lite->new(
+ From=>join( " ", map( Encode::encode( "MIME-Q", $_ ), split( " ",
$from ) ) ),
+ Subject=>join( " ", map( Encode::encode( "MIME-Q", $_ ), split( "
", $subject ) ) ),
+ Date=>time2str( $co->{author_epoch} ),
+ "Message-Id"=>make_message_id( $co->{id} ),
+ ($n_parents>0 ? (References=>$parents) : ()),
+
+ ($n_parents>1 ? (Type=>"multipart/mixed")
+ :(
+ Type=>"text/plain; charset=utf8",
+ Encoding=>"quoted-printable",
+ Data=>make_commit_body( $co->{id}, $co->{parents}->[0], 0 )
+ )
+ )
+ );
+ $msg->add( Path=>$DOMAIN_ID );
+ $msg->add( Newsgroups=>$newsgroup );
+ if( $n_parents>1 ) {
+ $msg->attach(
+ Type=>"text/plain; charset=utf8",
+ Encoding=>"quoted-printable",
+ Data=>make_commit_body( $co->{id}, $co->{parents}->[0], 0 )
+ );
+ for my $n (1..$n_parents-1) {
+ $msg->attach(
+ Type=>"text/plain; charset=utf8",
+ Encoding=>"quoted-printable",
+ Data=>make_commit_body( $co->{parents}->[$n], $co->{parents}->[0], 1 )
+ );
+ }
+ }
+ return $msg;
+}
+
+sub post_commit
+{
+ my ($nntp,$newsgroup,$co)=@_;
+ if( $PRINT_MESSAGES ) { # just print them
+ print make_commit_message( $newsgroup, $co )->as_string();
+ print "\0";
+ }else {
+ if( !$nntp->ihave( make_message_id( $co->{id} ) ) ) {
+ my $reason=$nntp->message();
+ unless( $reason=~m/got it/i || $reason=~m/duplicate/i ) {
+ print STDERR "unexpected responce in attempt to post $co->{id}: $reason"
+ }
+ }else {
+ $nntp->datasend( make_commit_message( $newsgroup, $co )->as_string() );
+ if( !$nntp->dataend() ) {
+ print STDERR "error posting $co->{id}: " . $nntp->message() . "\n";
+ }
+ }
+ }
+}
+
+sub make_newsgroup_name
+{
+ my $nhead=shift;
+ $nhead=~s/\/+$//;
+ $nhead=~s/^\/+//;
+ $nhead=~s/\./-/g;
+ $nhead=~s/\//\./g;
+ my $nprefix=$NEWSGROUP_PREFIX;
+ if( !defined( $nprefix ) ) {
+ $nprefix=$GIT_DIR;
+ $nprefix=~s/\/\.git\/?\s*$//;
+ $nprefix=~s/\/+$//;
+ $nprefix=~s/^\/+//;
+ $nprefix=~s/\./-/g;
+ $nprefix=~s/\//\./g;
+ }
+ return "$nprefix.$nhead";
+}
+
+sub post_commits
+{
+ my $nntp;
+ unless( $PRINT_MESSAGES ) {
+ $nntp=Net::NNTP->new( $NNTP_HOST, Port=>$NNTP_PORT, Reader=>0 );
+ die "unable to connect to nntp host ${NNTP_HOST}:${NNTP_PORT}" unless $nntp;
+ }
+ while( my ($head,$h)=each %HEADS ) {
+ my $id=$h->{start_id};
+ my $newsgroup_name=make_newsgroup_name( $head );
+ while( $id ) {
+ my $co=$COMMITS{$id};
+ $id=$co->{child};
+ next if defined( $MIN_AGE ) && $co->{committer_epoch} > $MIN_AGE;
+ post_commit( $nntp, $newsgroup_name, $co );
+ }
+ }
+}
+
+sub chop_str {
+ my $str = shift;
+ my $len = shift;
+ my $add_len = shift || 10;
+
+ # allow only $len chars, but don't cut a word if it would fit in $add_len
+ # if it doesn't fit, cut it if it's still longer than the dots we would add
+ $str =~ m/^(.{0,$len}[^ \/\-_:\.@]{0,$add_len})(.*)/;
+ my $body = $1;
+ my $tail = $2;
+ if (length($tail) > 4) {
+ $tail = " ...";
+ }
+ return "$body$tail";
+}
+
--
0.99.9.GIT
^ permalink raw reply related
* Re: as promised, docs: git for the confused
From: Randal L. Schwartz @ 2005-12-12 20:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Timo Hirvonen, junkio, linux, git
In-Reply-To: <Pine.LNX.4.64.0512121010550.15597@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> So instead of teaching people about "git-read-tree --reset HEAD" etc that
Linus> you'd never know on your own, just teach about "git reset". And not
Linus> bothering with the "git-write-tree + git-commit-tree + git-update-ref"
Linus> approach, just make people use "git commit" from the very beginning.
I learned more by reading the cg-tutorial, at least from the user
perspective. I then went back to the git-tutorial, and was able to
finally understand that these commands are worth ignoring. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ 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