* Re: My first git success [not quite]
From: walt @ 2006-01-14 15:39 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0601130909290.3535@g5.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 13 Jan 2006, walt wrote:
>> And it was all so easy I never broke a sweat. Amazing!
> ...Most people don't bother to
> explain their problems well...
I see I still have a problem: my mental model of how git
works is still wrong.
I used 'git-checkout -b test' to create a disposable place
to test the patch I was given.
Okay, making sure I'm now sitting in 'test', I apply the
patch to foo.c and do my testing.
Now, intending to delete my 'test' branch, I do git-checkout
master. My mental model predicts that 'master' should still
be identical to 'origin' because I did the patching in 'test'.
Am I right so far?
The problem I see is that, after switching back to 'master',
foo.c is the patched version, not your original version. I
figured that the git-checkout would overwrite any changes I
made to foo.c, but that doesn't seem to be the case. To get
your original version back I had to delete foo.c and do a
git-checkout foo.c (or git-checkout -f master).
So, I clearly don't understand what git-checkout does. It
doesn't seem to touch the already-checked-out sources at
all, which is what I would expect it to do.
Can someone hit me with the clue-stick here? Thanks!
^ permalink raw reply
* Re: [PATCH] rpmbuild doesn't like '-' in version strings
From: John Ellson @ 2006-01-14 15:39 UTC (permalink / raw)
To: git; +Cc: git, Linus Torvalds
In-Reply-To: <7voe2prniw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> John Ellson <ellson@research.att.com> writes:
>
>> Suggested fix: Use '_' instead of '-'
>
> I wonder if the right fix is to change the git-describe output
> before the current output becomes too widespread. After all,
> somebody might be tempted to use 1.0.6-g58e3 as a tagname ;-).
> For example, if we say "1.0.6:58e3" there is no ambiguity, but
> probably binary packagers would not like colon either X-<.
>
> More seriously, I do not think git-describe based versioning
> scheme meshes well with binary packagers. There is no guaranee
> 1.0.6-g58e3 comes before 1.0.6-g4e7a2 (it does not). To really
> fix this problem, I think the rpm target of the main Makefile
> needs to be modified to include something monotonicly increasing
> (e.g. number of seconds since the base commit encoded in base26,
> or something silly like that) between the base version and the
> abbreviated object name, but the development being distributed,
> my today's version on top of 1.0.6 may be way behind your
> yesterday's version, so some centralized coordination (read:
> manual version assignment by the maintainer, or automated
> assignment but only reserved for the maintainer and unavailable
> to mere mortals) might be needed to truly solve this. In that
> sense, maybe leaving the interim version unbuildable for binary
> packaging might be considered a feature.
What happened to this? I don't particularly like my fix either, but
some kind of fix is needed for the "make rpm" target to work. Its still broken
because of the '-' in the version string.
The need in rpm versioning is to be able to distinguish and monotonically
order, locally built rpms. There is no particular need to disambiguate against
somebody else's rpms since if you are merging someone else's changes you
would be doing it in git and not by intermixing rpms.
I think that distinguishing between local branches is not likely to be a prolem.
Most developers are likely to use only one for rpm construction, or if there
is a second experimental branch, then it is likely to contain more-recent
changes anyway.
So a count of minutes since last tag is probably sufficient.
This could have a hash appended if it is essential to make the rpm version
unique without losing the ordering of the timestamp.
Something like:
1.1.2_123456_g9e9b
John
^ permalink raw reply
* Re: [wish] Auto-generate gitk's pretty pictures
From: Andreas Ericsson @ 2006-01-14 13:36 UTC (permalink / raw)
To: Artem Khodush; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <40b2b7d90601131905s6bb9954fk8e359e3f066ce0c2@mail.gmail.com>
Artem Khodush wrote:
> On 1/14/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
>
>>That looks *great* -- How hard would it be to run it alongside gitweb,
>>with links back to gitweb for showing commits? And... what is it
>>written in?
>
>
> It's written mainly in HTML+javascript, so linking to and from it should
> be simple - just add an <a> tag. But, the next feature I plan to add
> is to show commits in the same window in a way like gitk does.
>
Why not just have a separate frame for the commits and load gitweb.cgi
there?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: RFC: Subprojects
From: Junio C Hamano @ 2006-01-14 8:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git, Simon Richter
In-Reply-To: <Pine.LNX.4.64.0601110928350.5073@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I'd suggest adding a new kind of object ("gitlink") which has some
> well-specified format (20-byte SHA1 + ASCII C string "name" - the name
> translation to external repository would be done in the .git/config file
> of the "outer" project). Then a special file mode to indicate that in the
> "struct tree", and support for "git-update-cache" to understand how such
> an object is really tied into the "<pathname>/.git/HEAD" file rather than
> the rest of the directory contents.
>
> Then a "git fetch" would have to be taught to recursively fetch the other
> subproject when the "gitlink" changes.
There are two positive properties about this setup, and one
negative:
+ The contained project is kept totally independent and does
not have to know it is contained.
+ The tree for the contained project can be rooted anywhere in
the containing project's tree.
- The contained project cannot be rooted at the same level or
higher than the containing project; the containing project
can only delegate a whole subdirectory to the contained
project.
The "embedded software" example Simon originally suggested can
be represented with the above. I'll think aloud for a while
here, because I am of a slow kind who needs a more-or-less
concrete illustration to understand what is being discussed
(that is primarily why I have not said anything on this topic so
far).
The "containing" project would have a handful "gitlink" objects
among other things. The toplevel tree object from a commit in
such a project might look like this (mode bits 0160000 is
S_IFDIR|S_IFLNK, which is what this thing is):
$ git ls-tree HEAD
0100644 blob 012345... Makefile
0100644 blob 123456... README
0160000 link 234567... gcc-4.0
0160000 link 345678... linux-2.6
0040000 tree 456789... src
$ git cat-file -t 345678
link
$ git cat-file link 345678
commit 87530db5ec7d519c7ba334e414307c5130ae2da8
url git://...torvalds/linux-2.6.git/
The upstream Linux 2.6 repository.
$ cd linux-2.6 && git-rev-parse --verify HEAD
87530db5ec7d519c7ba334e414307c5130ae2da8
URL will be used as a suggestion for people who cloned this tree
to set up their repository. The place and method you clone from
Linus tree might be different, so this has to stay suggestion
and should be overridable by the repository owner. And to help
people at an unusual location you could have textual comment at
the end, just like tags.
How would this get set up initially? Here is one way.
$ git init-db
$ edit Makefile README src/*
$ git clone git://...torvalds/linux-2.6.git/ linux-2.6
$ git clone git://.../gcc-4.0.git/ gcc-4.0
$ link=$(echo 'The upstream Linux 2.6 repository.' |
git-mklink linux-2.6)
$ git update-index --add --cacheinfo 0160000 $link linux-2.6
$ : ;# same for gcc-4.0
$ git add . ;# add the rest as usual
$ git commit
I presume that the index file have the "gitlink" object just
like in a tree object. The usual merge rules would apply to
those index entries; we should be able to treat gitlinks just
like we handle symlinks.
Interesting would be "git checkout-index linux-2.6" (or what
"git read-tree -u" does in this "containing" project for
linux-2.6 subdirectory). After descending into linux-2.6, it
should not just do "git reset --hard $commit" for the commit
recorded in the gitlink (the user may have local modifications
in the subtree). Doing "git update-ref HEAD $commit" there is
not quite right either because the index there would then need
to be adjusted as well. Perhaps the real core level commands
such as "checkout-index" and "read-tree -u" should fail when the
subproject tree is dirty, just like "read-tree -m old new" does
not always have to succeed.
What does "git-diff-index/git-diff-tree/git-diff-files" would do
with them?
$ git-diff-files linux-2.6
would compare the commit recorded in the link and what is
checked out in the linux-2.6/.git/HEAD and report that
difference. So do other git-diff-* siblings. At the core level
we do not have to recurse and look at linux-2.6/.git/index (we
may end up doing so at the end, I dunno; initially we said at
the core level we do not have to generate patches but we ended
up having -p option go all of git-diff-* siblings).
Fetching/cloning at the core level is easy. "git-fetch-pack"
would just need to do one level, but Porcelains need to address
how to actually arrange the subprojects cloning to happen, which
is harder.
"git clone" would say: "Ah, now I see these gitlinks; we need to
clone them. linux-2.6 directory needs to be populated with
commit 87530d from git://...torvalds/linux-2.6.git/ repository.
Would this work for you, or would you use different mirror?"
and then it clones the repository and sets linux-2.6/.git/HEAD
to the named commit and does a checkout. The URL used for this
actual subcloning would need to be stored somewhere in $GIT_DIR/,
perhaps in config as you suggested. I do not think we need a
separate name for it -- we can probably say "linux-2.6" for this
(i.e. use the pathname itself as the key).
What happens if the containing project wants to move these
gitlinks (or remove them)? When checking out such a commit with
"git-read-tree -u", would the subproject directory be wiped out
(again, such a "read-tree" would be prevented if it would result
in information loss)?
All of this sounds quite a lot of change with brittleness.
Now I'll think aloud about a completely different design.
We could simply overlay the projects. I think this is what
Johannes suggested earlier.
You keep one branch for each "subproject", and make commits into
each branch (i.e. if you modified files for the upstream kernel,
the change is committed to the branch for linux-2.6 subproject),
but when checking things out, you do an equivalent of octopus
merge across subprojects.
One downside of this approach is we cannot re-root the
subprojects until we update read-tree and write-tree, but I
suspect that would be a lot smaller change. Once that is done,
we could:
$ git init-db
$ mkdir linux-2.6
$ H=$(git-fetch-pack -k git://...torvalds/linux-2.6.git/ master)
$ echo $H >.git/refs/heads/kernel
$ : ;# same for gcc-4.0
$ cat .git/config <<EOF
[core]
branchroot = linux-2.6 for kernel
branchroot = gcc-4.0 for gcc
EOF
$ git add . ;# add src and stuff
$ git commit ;# commits only the scaffolding into "master"
So far, we fetched the kernel and gcc HEAD with needed objects
and stored them into separate branches. Then:
$ git setup-overlay embed master kernel gcc ;# works like an octopus
The setup-overlay command would create a new branch "embed" to
hold an octopus merge across named branches "master", "kernel",
and "gcc", and mark that the repository is in a funny "overlay"
mode, in which various commands work differently from usual:
$ edit linux-2.6/CREDITS gcc-4.0/COPYING Makefile
$ git commit -a
The "commit" needs to be taught to look at what setup-overlay
left for us, pick out paths that belong to each constituent
branch and do a re-rooting write-tree, for each branch.
This would keep changes to subprojects independent painlessly,
but we would also need a way to tie the versions of subprojects
together (i.e. "this version of src was done with this
particular version of linux-2.6"). This can be done by
committing the octopus to "embed" branch. Probably easiest
would be to make one commit each to modified constituent branch,
and after that make another commit to "embed" to commit the
octopus to keep track of the aggregation --- the commit would
have the parents set to the previous embed and top commit of
each constituent branch.
If we do not need re-rooting (e.g. redo your slurping gitk into
git.git), I think all of the above can be done without any core
changes. It would be a lot of Porcelainish work, but I suspect
the core impact would be smaller.
^ permalink raw reply
* Software
From: Tweets D. Guesswork @ 2006-01-14 6:41 UTC (permalink / raw)
To: Git
Why pay big bucks? Create your OWN website now!
some software u need!
New software on our site:
Encarta Encyclopedia Delux 2004 (3CD) - $89.95
Acrobat 6 Professional - $79.95
Studio MX 2004 with Director MX 2004 - $139.95
SQL Server 2000 Enterprise Edition - $69.95
Office 2000 Premium Edition PE (2CD) - $59.95
Windows 98 - $49.95
Painter 8 - $59.95
InDesign CS - $69.95
Premiere 7 - $69.95
WordPerfect Office 10 - $69.95
Flash MX 2004 - $69.95
Visual Studio .NET Architect Edition (8CD) - $139.95
Office 97 SR2 - $49.95
InDesign CS PageMaker Edition (2CD) - $69.95
Our site:
http://riddamna.com
^ permalink raw reply
* [ANNOUNCE] GIT 1.1.2
From: Junio C Hamano @ 2006-01-14 4:53 UTC (permalink / raw)
To: git, linux-kernel
The latest maintenance release GIT 1.1.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.1.2.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.1.2-1.$arch.rpm (RPM)
----------------------------------------------------------------
Changes since v1.1.1 are as follows:
J. Bruce Fields:
Documentation: clarify fetch parameter descriptions.
Junio C Hamano:
update-index: work with c-quoted name
describe: do not silently ignore indescribable commits
name-rev: do not omit leading components of ref name.
show-branch: handle [] globs as well.
Documentation: git-commit -a
Documentation: git-reset - interrupted workflow.
Tom Prince:
Add git-describe to .gitignore.
----------------------------------------------------------------
These have been added to the "master" branch lately, in addition
to all of the above fixes:
Makefile: add 'strip' target.
octopus: allow criss-cross and clarify the message when it rejects.
checkout: automerge local changes while switching branches.
checkout: merge local modifications while switching branches.
git-push: avoid falling back on pushing "matching" refs.
Exec git programs without using PATH (Michal Ostrowski)
Fix the installation location.
These are still waiting their turn in the proposed updates
("pu") branch:
git-cvsimport: Add -A <author-conv-file> option (Andreas Ericsson)
convert-packs: futureproofing.
Require packfiles to follow the naming convention (preparation).
format-patch: always --mbox and show sane Date:
octopus: allow manual resolve on the last round.
Documentation: show-branch.
show-branch: make the current branch and merge commits stand out.
Disable USE_SYMLINK_HEAD by default (Pavel Roskin)
^ permalink raw reply
* What's cooking in git.git
From: Junio C Hamano @ 2006-01-14 3:45 UTC (permalink / raw)
To: git
In-Reply-To: <7vhd8al3ae.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> - Exec git programs without using PATH (Michal Ostrowski).
>
> This has been discussed for the last couple of days on the
> list. I think C side is ready to go in, but I'd like to
> decide what to do on the scripting side before merging it
> into the master branch.
I've done a minor fix in the Makefile (things were installed in
the wrong way around --- $bindir should hold git and gitk and
$gitexecdir should hold the rest), and ran a brief test after
installing things with gitexecdir set to /usr/lib/git-core/x.
gitk needs to be taught to use git --exec-path upfront to set
its own PATH, but other than that, everything looks peachy.
About prepending to/appending to/not touching PATH, my current
thinking is that prepending is the way to go. The best
rationale so far I have heard against mucking with PATH was
"/home/mo/bin/diff vs /usr/bin/diff" issue, but I do not find
this to be so convincing in practice. This "use my diff not
system diff" is done most often when system diff is not GNU
enough, but on such a machine git will not be installed under
/usr/bin anyway (after all git prefers GNU diff).
And this becomes truly a non-issue when you point $gitexecdir at
a separate location that holds *only* git stuff. Everybody will
find the matching version of git that way, and when looking for
"diff", it will be found from one of the directories in the rest
of the PATH, not from $gitexecdir.
So unless there is an objection, this will graduate into the
"master" branch over the weekend.
What happens if gitexecdir != bindir?
As long as the user invokes "git foo" from the command line, not
"git-foo", everything should work fine, and once gitk is
updated, binary distributions could ship git with only git and
gitk in /usr/bin and others in /usr/lib/git-core/tools, or
something like that.
I will _not_ change the default gitexecdir in my Makefile nor
change the spec file, so RPM binary from kernel.org will still
have everything in /usr/bin for now.
Somebody needs to audit how ready popular Porcelains are, for at
least Cogito, stgit, gitweb and qgit and feed patches to
respective authors as necessary. I haven't looked into any of
them about this issue. The rules are:
(1) you can assume "git" is available on PATH;
(2) you should be safe if you do not use "git-foo" form;
(3) you can run
PATH="$(git --exec-path):$PATH"; export PATH
once at the beginning of your program and use "git-foo"
form.
Volunteers?
^ permalink raw reply
* Re: [wish] Auto-generate gitk's pretty pictures
From: Artem Khodush @ 2006-01-14 3:05 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90601131444m32a1a8b8w7ab16617f15ab93b@mail.gmail.com>
On 1/14/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
>
> That looks *great* -- How hard would it be to run it alongside gitweb,
> with links back to gitweb for showing commits? And... what is it
> written in?
It's written mainly in HTML+javascript, so linking to and from it should
be simple - just add an <a> tag. But, the next feature I plan to add
is to show commits in the same window in a way like gitk does.
Artem
^ permalink raw reply
* Question on empty commit
From: Luben Tuikov @ 2006-01-14 2:18 UTC (permalink / raw)
To: git
Hi,
Scenario:
trunk remote
|
\/
trunk local
\
`--> tree A
\
`--> tree B
Figure 1.
This is the dependecny since project B depends on project A
introduced in tree A. And merging is done as follows
(branch per directory; everything but HEAD and index is shared):
cd trunk && git pull trunk
cd ../treeA && git merge "merge trunk" HEAD trunk
cd ../treeB && git merge "merge tree A" HEAD treeA
But this isn't the only way to do it since tree B depends
only on the introduced into tree A project A, and both
project A and project B depend on the trunk, as follows:
trunk remote
|
\/
trunk local
\ \
\ `--> tree A
\ \
`--------> `--> tree B
Figure 2.
So at point in time t where tree B had been synced with tree A,
and tree A had been synced with trunk, but trunk had _not_ been
synced with remote trunk, a merge was done following Figure 2:
cd trunk && git pull trunk
cd ../treeA && git merge "merge trunk" HEAD trunk
cd ../treeB && git merge "merge trunk" HEAD trunk
git merge "merge tree A" HEAD treeA
Now the last merge introduced an empty commit, since
tree A and tree B had been in sync (only local and
remote trunk had been out of sync). While it was expected
that no commit would be introduced since they were in sync.
Was the empty commit correct behavior?
Thanks,
Luben
^ permalink raw reply
* [PATCH] format-patch: always --mbox and show sane Date:
From: Junio C Hamano @ 2006-01-13 23:56 UTC (permalink / raw)
To: git; +Cc: Andreas Ericsson, Linus Torvalds
In-Reply-To: <20060108140109.909925BE8D@nox.op5.se>
Make --mbox, --author, and --date options a no-op, and always
use --mbox output, and rewrite the commit log formatting in
Perl. This makes it easier to output Date: header in RFC 2822
format, so do that as well.
Inspiration for this patch came from Andreas Ericsson's earlier
patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I admit that trying to avoid Perl and sticking to multiple
sed invocations in this script was a lost battle. This patch
is still minimalistic and it does not go all the way to
rewrite the main loop of the program, which probably should
happen someday.
I would not mind if someday somebody rewrote most of the
barebone Porcelainish in Python or Perl, but the rewrite
should not be for the sake of using that language. It should
have other justifications: "there is too much text processing
there it would not make sense to do that in shell". I think
this patch is borderline to qualify to be in that camp.
As the version string at the end shows, this was prepared
with the script source itself before building, as a test
case.
git-format-patch.sh | 143 +++++++++++++++++++++++++++------------------------
1 files changed, 75 insertions(+), 68 deletions(-)
8b4271ef24818e6d52926bc615e5ce78ba0ed01b
diff --git a/git-format-patch.sh b/git-format-patch.sh
index d3979d7..7e67c4e 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -34,14 +34,12 @@ outdir=./
while case "$#" in 0) break;; esac
do
case "$1" in
- -a|--a|--au|--aut|--auth|--autho|--author)
- author=t ;;
-c|--c|--ch|--che|--chec|--check)
check=t ;;
- -d|--d|--da|--dat|--date)
- date=t ;;
- -m|--m|--mb|--mbo|--mbox)
- date=t author=t mbox=t ;;
+ -a|--a|--au|--aut|--auth|--autho|--author|\
+ -d|--d|--da|--dat|--date|\
+ -m|--m|--mb|--mbo|--mbox) # now noop
+ ;;
-k|--k|--ke|--kee|--keep|--keep-|--keep-s|--keep-su|--keep-sub|\
--keep-subj|--keep-subje|--keep-subjec|--keep-subject)
keep_subject=t ;;
@@ -173,80 +171,89 @@ titleScript='
q
'
-whosepatchScript='
-/^author /{
- s/'\''/'\''\\'\'\''/g
- s/author \(.*>\) \(.*\)$/au='\''\1'\'' ad='\''\2'\''/p
- q
-}'
-
process_one () {
- mailScript='
- /./d
- /^$/n'
- case "$keep_subject" in
- t) ;;
- *)
- mailScript="$mailScript"'
- s|^\[PATCH[^]]*\] *||
- s|^|[PATCH'"$num"'] |'
- ;;
- esac
- mailScript="$mailScript"'
- s|^|Subject: |'
- case "$mbox" in
- t)
- echo 'From nobody Mon Sep 17 00:00:00 2001' ;# UNIX "From" line
- ;;
- esac
+ perl -w -e '
+my ($keep_subject, $num, $signoff, $commsg) = @ARGV;
+my ($signoff_pattern, $done_header, $done_subject, $signoff_seen,
+ $last_was_signoff);
+
+if ($signoff) {
+ $signoff = `git-var GIT_COMMITTER_IDENT`;
+ $signoff =~ s/>.*/>/;
+ $signoff_pattern = quotemeta($signoff);
+}
- eval "$(sed -ne "$whosepatchScript" $commsg)"
- test "$author,$au" = ",$me" || {
- mailScript="$mailScript"'
- a\
-From: '"$au"
- }
- test "$date,$au" = ",$me" || {
- mailScript="$mailScript"'
- a\
-Date: '"$ad"
- }
+my @weekday_names = qw(Sun Mon Tue Wed Thu Fri Sat);
+my @month_names = qw(Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec);
- mailScript="$mailScript"'
- a\
+sub show_date {
+ my ($time, $tz) = @_;
+ my $minutes = abs($tz);
+ $minutes = ($minutes / 100) * 60 + ($minutes % 100);
+ if ($tz < 0) {
+ $minutes = -$minutes;
+ }
+ my $t = $time + $minutes * 60;
+ my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday) = gmtime($t);
+ return sprintf("%s %s %d %02d:%02d:%02d %d %+05d",
+ $weekday_names[$wday],
+ $month_names[$mon],
+ $mday, $hour, $min, $sec,
+ $year+1900, $tz);
+}
- : body
- p
- n
- b body'
+print "From nobody Mon Sep 17 00:00:00 2001\n";
+open FH, "git stripspace <$commsg |" or die "open $commsg pipe";
+while (<FH>) {
+ unless ($done_header) {
+ if (/^$/) {
+ $done_header = 1;
+ }
+ elsif (/^author (.*>) (.*)$/) {
+ my ($author_ident, $author_date) = ($1, $2);
+ my ($utc, $off) = ($author_date =~ /^(\d+) ([-+]?\d+)$/);
+ $author_date = show_date($utc, $off);
- (cat $commsg ; echo; echo) |
- sed -ne "$mailScript" |
- git-stripspace
-
- test "$signoff" = "t" && {
- offsigner=`git-var GIT_COMMITTER_IDENT | sed -e 's/>.*/>/'`
- line="Signed-off-by: $offsigner"
- grep -q "^$line\$" $commsg || {
- echo
- echo "$line"
- echo
- }
+ print "From: $author_ident\n";
+ print "Date: $author_date\n";
}
- echo
- echo '---'
- echo
+ next;
+ }
+ unless ($done_subject) {
+ unless ($keep_subject) {
+ s/^\[PATCH[^]]*\]\s*//;
+ s/^/[PATCH$num] /;
+ }
+ print "Subject: $_";
+ $done_subject = 1;
+ next;
+ }
+
+ $last_was_signoff = 0;
+ if (/Signed-off-by:/i) {
+ if ($signoff ne "" && /Signed-off-by:\s*$signoff_pattern$/i) {
+ $signoff_seen = 1;
+ }
+ }
+ print $_;
+}
+if (!$signoff_seen && $signoff ne "") {
+ if (!$last_was_signoff) {
+ print "\n";
+ }
+ print "$signoff\n";
+}
+print "\n---\n\n";
+close FH or die "close $commsg pipe";
+' "$keep_subject" "$num" "$signoff" $commsg
+
git-diff-tree -p $diff_opts "$commit" | git-apply --stat --summary
echo
git-diff-tree -p $diff_opts "$commit"
echo "-- "
echo "@@GIT_VERSION@@"
- case "$mbox" in
- t)
- echo
- ;;
- esac
+ echo
}
total=`wc -l <$series | tr -dc "[0-9]"`
--
@@GIT_VERSION@@
^ permalink raw reply related
* Re: git pull on Linux/ACPI release tree
From: Matthias Urlichs @ 2006-01-13 23:35 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.64.0601101048440.4939@g5.osdl.org>
Hi, Linus Torvalds wrote:
> I'm pretty proud of it. It's simple, and it's obvious once you think about
> it, but it is pretty novel as far as I know. BK certainly had nothing
> similar, not have I heard of anythign else that does it.
Actually, I've written a hackish script that tries to do simple-minded
bisection (read: it searched for the 50% point on the shortest path
between any-of-GOOD and any-of-BAD, instead of considering the whole
graph) on BK trees. I haven't exactly published the thing anyplace though,
because, well, it was ugly. :-/
Besides, actually working with the current bisection point is no problem
at all for git. Doing the same thing in BK's world view is *painful*,
esp. given the size of the kernel tree.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Arthur felt at a bit of a loss. There was a whole Galaxy
of stuff out there for him, and he wondered if it was
churlish of him to complain to himself that it lacked just
two things: the world he was born on and the woman he loved.
^ permalink raw reply
* Re: [wish] Auto-generate gitk's pretty pictures
From: Martin Langhoff @ 2006-01-13 22:44 UTC (permalink / raw)
To: Artem Khodush; +Cc: Git Mailing List
In-Reply-To: <40b2b7d90601131414o20eae573r23256ff2dfbeffa5@mail.gmail.com>
On 1/14/06, Artem Khodush <greenkaa@gmail.com> wrote:
> I'm working on a web interface that will look similar to gitk.
> It's far from being usable, the only thing it does now is to "draw"
> gitk-like "picture". But if the picture is all you want, you may
> find it useful. Please look at
>
> http://straytree.com/git-browser/by-commit.html?r=git
That looks *great* -- How hard would it be to run it alongside gitweb,
with links back to gitweb for showing commits? And... what is it
written in?
martin
^ permalink raw reply
* Re: [wish] Auto-generate gitk's pretty pictures
From: Artem Khodush @ 2006-01-13 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff
In-Reply-To: <7v1wzb3h2h.fsf@assigned-by-dhcp.cox.net>
On 1/14/06, Junio C Hamano <junkio@cox.net> wrote:
> Artem Khodush <greenkaa@gmail.com> writes:
>
> > I'm working on a web interface that will look similar to gitk.
> > It's far from being usable, the only thing it does now is to "draw"
> > gitk-like "picture". But if the picture is all you want, you may
> > find it useful. Please look at
> >
> > http://straytree.com/git-browser/by-commit.html?r=git
>
> Looks nice, although octopi look very ugly ;-).
Thank you all, any suggestions are welcome :-)
cheers,
Artem
^ permalink raw reply
* Re: [wish] Auto-generate gitk's pretty pictures
From: Junio C Hamano @ 2006-01-13 22:21 UTC (permalink / raw)
To: Artem Khodush; +Cc: git, Martin Langhoff
In-Reply-To: <40b2b7d90601131414o20eae573r23256ff2dfbeffa5@mail.gmail.com>
Artem Khodush <greenkaa@gmail.com> writes:
> I'm working on a web interface that will look similar to gitk.
> It's far from being usable, the only thing it does now is to "draw"
> gitk-like "picture". But if the picture is all you want, you may
> find it useful. Please look at
>
> http://straytree.com/git-browser/by-commit.html?r=git
Looks nice, although octopi look very ugly ;-).
^ permalink raw reply
* Re: [wish] Auto-generate gitk's pretty pictures
From: Johannes Schindelin @ 2006-01-13 22:19 UTC (permalink / raw)
To: Artem Khodush; +Cc: Git Mailing List
In-Reply-To: <40b2b7d90601131414o20eae573r23256ff2dfbeffa5@mail.gmail.com>
Hi,
On Sat, 14 Jan 2006, Artem Khodush wrote:
> http://straytree.com/git-browser/by-commit.html?r=git
Wow! Great work...
Ciao,
Dscho
^ permalink raw reply
* Re: [wish] Auto-generate gitk's pretty pictures
From: Artem Khodush @ 2006-01-13 22:14 UTC (permalink / raw)
To: Git Mailing List; +Cc: Martin Langhoff
In-Reply-To: <46a038f90601121302x3d06898dk3f9a0ab7114ef70a@mail.gmail.com>
> 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.
I'm working on a web interface that will look similar to gitk.
It's far from being usable, the only thing it does now is to "draw"
gitk-like "picture". But if the picture is all you want, you may
find it useful. Please look at
http://straytree.com/git-browser/by-commit.html?r=git
hope this helps,
Artem.
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Johannes Schindelin @ 2006-01-13 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: sean, git
In-Reply-To: <7vy81j6h56.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 13 Jan 2006, Junio C Hamano wrote:
> sean <seanlkml@sympatico.ca> writes:
>
> > So do you still agree with that, would you accept a patch? Or do you have
> > some fundamental reason to think that environment variables are a better
> > way to pass information in this case?
>
> Fundamental reason of not doing anything is (1) not to make
> unnecessary changes and (1) to avoidi decisions ;-).
You forgot the 3rd (1).
> No objections to --from='John Doe <john.doe@example.com>' by
> itself, other than "You could say GIT_AUTHOR_* before the
> command instead of --from after the command; as long as it is
> not done regularly as an interactive command, the difference
> does not matter".
Well, they are not completely idempotent. If you call
git commit --form='Me <bla@bla.com>'
it will tell you that you misspelt an option. Try that with
GIT_AUTOR_NAME='Me without H <dumm@my.com>' git commit
> - Is --from the right word? Shouldn't it be --author?
> - Do we want author date? If not, why not?
> - What about committer information? If not, why not?
These are very valid objections, however. As is: why would you want to do
that instead of creating an mbox-style file in the first place.
IIRC there was this strange use case which tried to make a clean git tree
from several CVS repositories. IMHO it is much easier to cvsimport them,
and fix everything from within git, which should be relatively easy with
the nice recursive merge.
My 2 cents,
Dscho
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Johannes Schindelin @ 2006-01-13 21:47 UTC (permalink / raw)
To: Joel Becker; +Cc: Junio C Hamano, git
In-Reply-To: <20060113191231.GM14196@ca-server1.us.oracle.com>
Hi,
On Fri, 13 Jan 2006, Joel Becker wrote:
> On Thu, Jan 12, 2006 at 11:06:07PM -0800, Junio C Hamano wrote:
> > Joel Becker <Joel.Becker@oracle.com> writes:
> >
> > > Well, I'm wary of putting
> > > GIT_AUTHOR_EMAIL=joel.becker@oracle.com as a permanent part of my
> > > environment, for fear of overriding some other authors at some point.
> >
> > The weakest default comes from .git/config so you could have
> > this in your .git/config:
> >
> > [user]
> > name = Joel Becker
> > email = Joel.Becker@oracle.com
>
> This configuration is something I have the opportunity to forget
> every time I call git-clone. So I still need to leave it in the
> environment permanently.
Of course, you could put it in your templates and never forget.
Ciao,
Dscho
^ permalink raw reply
* Re: qgit shows wrong popup
From: Pavel Roskin @ 2006-01-13 21:06 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <43C7E645.2050702@yahoo.it>
Hi, Marco!
On Fri, 2006-01-13 at 18:41 +0100, Marco Costalba wrote:
> please test the following an let me know if it is ok for you.
It works, but not the first time. Suppose I have two unapplied patches
and one applied. qgit focuses on the top unapplied patch on startup.
Right-click on the applied patch shows disabled "Push Patch". Then I
select the top line again, right-click on the applied patch, and I see
enabled "Pop Patch".
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-13 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virsn50lv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Joel Becker <Joel.Becker@oracle.com> writes:
>
>> On Fri, Jan 13, 2006 at 11:39:17AM -0800, Junio C Hamano wrote:
>>> That's what I do. Although I use git-am not git-applymbox, both
>>> of them are designed to work that way.
>>
>> While I can see that git-am and git-applymbox have different
>> options for the same basic task, I can't quite see why one would be
>> preferred to the other. What does git-am do that git-applymbox does
>> not?
The behaviour upon seeing unapplicable patch is somewhat
different. In Linus workflow, he reviews (and modifies if
necessary) all patches inside mbox and runs "applymbox"; upon
failure, he blows what remains in .dotest away, trims mbox to
get rid of what has already been applied and re-runs it from
scratch. The failure recovery method "applymbox" had (this
happened before my time IIRC) is to edit .dotest/patch to make
it applicable and re-run it. OTOH, "am" tries to do better by
allowing you to hand tweak the working tree to match what would
have resulted if the patch applied cleanly and say "--resolved".
Another difference is that "am" can be told to handle binary
file changes and apply such as long as the patch is intra
repository (i.e. both pre and post image blob are available in
the repository). This is used as a backend to do "git rebase".
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-13 20:33 UTC (permalink / raw)
To: Joel Becker; +Cc: git
In-Reply-To: <20060113200124.GO14196@ca-server1.us.oracle.com>
Joel Becker <Joel.Becker@oracle.com> writes:
> On Fri, Jan 13, 2006 at 11:39:17AM -0800, Junio C Hamano wrote:
>> That's what I do. Although I use git-am not git-applymbox, both
>> of them are designed to work that way.
>
> While I can see that git-am and git-applymbox have different
> options for the same basic task, I can't quite see why one would be
> preferred to the other. What does git-am do that git-applymbox does
> not?
Sorry about the confusion. This is turning into a FAQ and it is
all _my_ fault [*1*].
Some historical background.
- "applymbox" was there first. It was renamed from a tool
'dotest' Linus had used since BK days, with somewhat
unextensible command line syntax.
- "am" was invented later, to majorly redo what applymbox does
with extensible command line syntax. It is supposed to do
everything applymbox does, but the only thing it does not
support is to be command-line compatible.
The primary reason why I kept applymbox maintained is because
many "How to hack kernel with git" documents floating around
talk about applymbox, and it still is used by Linus to apply
patches with his trained fingers. Worse yet, it could be that
applymbox is used as a building block in larger private scripts
used by kernel developers, and its removal would force them to
update their scripts to use "am" instead. I do not want to see
the kernel people spending their time on adjusting their private
tools for git changes unnecessarily; their time is better spent
on improving the kernel.
So in short, I tend to recommend "am" to new people, but
"applymbox" is still usable.
[Footnote]
*1* I do not mind keeping applymbox maintained, but at the same
time I know I would feel it stupid to carry two tools that do
almost the same thing if it were somebody else's project, and
every time this issue comes up I feel the urge to say "in 3
months, git-applymbox will be removed, please get used to
git-am", which so far I ended up resisting.
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: Joel Becker @ 2006-01-13 20:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd877w9m.fsf@assigned-by-dhcp.cox.net>
On Fri, Jan 13, 2006 at 11:39:17AM -0800, Junio C Hamano wrote:
> That's what I do. Although I use git-am not git-applymbox, both
> of them are designed to work that way.
While I can see that git-am and git-applymbox have different
options for the same basic task, I can't quite see why one would be
preferred to the other. What does git-am do that git-applymbox does
not?
Joel
--
"I'm so tired of being tired,
Sure as night will follow day.
Most things I worry about
Never happen anyway."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: merging initial part of a branch?
From: J. Bruce Fields @ 2006-01-13 20:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q477vqj.fsf@assigned-by-dhcp.cox.net>
On Fri, Jan 13, 2006 at 11:50:44AM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> but the general sentiment was that having another document is
> making things more confusing and we should try to clarify the
> main documentation instead.
Understood. We may need to add documentation here and there, but that
needs to be done alongside clarifying the existing text and
organization, and without creating unnecessary duplication.
> So I would really appreciate documentaiotn patches to clarify
> the current mess ;-).
OK. I'll see if I can up with something useful!
> > I also have Yet Another Git Tutorial, at
> > http://www.fieldses.org/~bfields/kernel/git.html. (Corrections and
> > suggestions welcomed.)
>
> The $prefix defaults to $HOME/bin/. Having $bindir on $PATH
> ought to be enough and exporting GIT_EXEC_PATH is not needd.
>
> Other than that I did not see anything obviously wrong, although
> I suspect you did not intend to say clone with stgit.
Whoops, right. Thanks for the corrections; I've applied all three.
--b.
^ permalink raw reply
* Re: Recursive remove
From: Junio C Hamano @ 2006-01-13 19:51 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP08F3875A7636E18401E7B3AE260@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> On Fri, 13 Jan 2006 09:37:54 -0800
> Junio C Hamano <junkio@cox.net> wrote:
>>
>> $ rm -fr Some/Dir; git commit -a -m 'Remove'
>>
>> perhaps?
>
> Sigh, its been a humbling morning all around; can't get easier than that.
Perhaps this is because I did not do a good job in
Documentation/git-commit.txt. Something like this?
-- >8 --
Documentation: git-commit -a
A bit more elaboration on what "update all paths" means.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index e0ff74f..e35984d 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -25,7 +25,9 @@ information.
OPTIONS
-------
-a|--all::
- Update all paths in the index file.
+ Update all paths in the index file. The command with this flag
+ notices files that have been modified and deleted, but new files
+ you have not told about git are not affected.
-c or -C <commit>::
Take existing commit object, and reuse the log message
^ permalink raw reply related
* Re: git-commit: allow From: line to be entered in commit message
From: Junio C Hamano @ 2006-01-13 19:51 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP0918AE856AD34E35597CA4AE260@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> So do you still agree with that, would you accept a patch? Or do you have
> some fundamental reason to think that environment variables are a better
> way to pass information in this case?
Fundamental reason of not doing anything is (1) not to make
unnecessary changes and (1) to avoidi decisions ;-).
No objections to --from='John Doe <john.doe@example.com>' by
itself, other than "You could say GIT_AUTHOR_* before the
command instead of --from after the command; as long as it is
not done regularly as an interactive command, the difference
does not matter". At that point, "making no unneeded changes"
kicks in. While I do understand that it might be necessary to
commit somebody else's patch occasionally, you have not
convinced me that is not such a rare thing, so until then the
change stays at lower priority.
After I am convinced that it is not so rare and having an easier
and more consistent way (something coming from environment and
other things from command line is inconsistent) would generally
be a good addition, I further need to think about these issues
before taking such a patch, in the context of the "git commit"
command as a whole:
- Is --from the right word? Shouldn't it be --author?
- Do we want author date? If not, why not?
- What about committer information? If not, why not?
^ 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