* Re: [PATCH] Introduce Git.pm (v3)
From: Junio C Hamano @ 2006-06-23 4:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060623011205.GJ21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> cc -shared -L/usr/local/lib Git.o -o blib/arch/auto/Git/Git.so ../libgit.a \
>> -lz -lcrypto \
>>
>> /usr/bin/ld: ../libgit.a(exec_cmd.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
>> ../libgit.a: could not read symbols: Bad value
>> collect2: ld returned 1 exit status
>> make[1]: *** [blib/arch/auto/Git/Git.so] Error 1
>>
>> This is a real killer. If we compile everything with -fPIC,
>> this goes away, but I do not think we want -fPIC for the core
>> level tools. At least not until we are ready to do libgit.so.
>
> Hmm, I didn't get that; I guess that's x86-64 specific. :/
So it seems. Both RH machines I have access at kernel.org and
Debian machines I have locally exhibit that x86-32 is OK and
x86-64 is bad. They all run libc-2.3.6 except RH x86-32 is at
libc-2.3.4.
^ permalink raw reply
* Re: [PATCH] Introduce Git.pm (v3)
From: Jakub Narebski @ 2006-06-23 6:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vk678fpqy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>>> cc -shared -L/usr/local/lib Git.o -o blib/arch/auto/Git/Git.so ../libgit.a \
>>> -lz -lcrypto \
>>>
>>> /usr/bin/ld: ../libgit.a(exec_cmd.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
>>> ../libgit.a: could not read symbols: Bad value
>>> collect2: ld returned 1 exit status
>>> make[1]: *** [blib/arch/auto/Git/Git.so] Error 1
>>>
>>> This is a real killer. If we compile everything with -fPIC,
>>> this goes away, but I do not think we want -fPIC for the core
>>> level tools. At least not until we are ready to do libgit.so.
>>
>> Hmm, I didn't get that; I guess that's x86-64 specific. :/
>
> So it seems. Both RH machines I have access at kernel.org and
> Debian machines I have locally exhibit that x86-32 is OK and
> x86-64 is bad. They all run libc-2.3.6 except RH x86-32 is at
> libc-2.3.4.
Perhaps Git.pm should provide also generic, pure Perl (and slower)
fallback implementation (when for some reason we cannot compile XS).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Introduce Git.pm (v3)
From: Nguyễn Thái Ngọc Duy @ 2006-06-23 6:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7g079$8qt$1@sea.gmane.org>
On 6/23/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Perhaps Git.pm should provide also generic, pure Perl (and slower)
> fallback implementation (when for some reason we cannot compile XS).
Haven't looked at Git.pm. But I have written receive-pack in perl. It
may have some useful functions for Git.pm
^ permalink raw reply
* [PATCH] git-merge --squash
From: Junio C Hamano @ 2006-06-23 8:50 UTC (permalink / raw)
To: git
Some people tend to do many little commits on a topic branch,
recording all the trials and errors, and when the topic is
reasonably cooked well, would want to record the net effect of
the series as one commit on top of the mainline, removing the
cruft from the history. The topic is then abandoned or forked
off again from that point at the mainline.
The barebone porcelainish that comes with core git tools does
not officially support such operation, but you can fake it by
using "git pull --no-merge" when such a topic branch is not a
strict superset of the mainline, like this:
git checkout mainline
git pull --no-commit . that-topic-branch
: fix conflicts if any
rm -f .git/MERGE_HEAD
git commit -a -m 'consolidated commit log message'
git branch -f that-topic-branch ;# now fully merged
This however does not work when the topic branch is a fast
forward of the mainline, because normal "git pull" will never
create a merge commit in such a case, and there is nothing
special --no-commit could do to begin with.
This patch introduces a new option, --squash, to support such a
workflow officially in both fast-forward case and true merge
case. The user-level operation would be the same in both cases:
git checkout mainline
git pull --squash . that-topic-branch
: fix conflicts if any -- naturally, there would be
: no conflict if fast forward.
git commit -a -m 'consolidated commit log message'
git branch -f that-topic-branch ;# now fully merged
When the current branch is already up-to-date with respect to
the other branch, there truly is nothing to do, so the new
option does not have any effect.
This was brought up in #git IRC channel recently.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is something I am unlikely to use myself, since
"squashing into one" is too coarse grained for the commits I
usually make myself.
If one's habit is to use a sequence of many commits to keep
too-finer-grained snapshots, and the result of a squash
commit out of such a sequence of commits is a coherent,
self-contained unit, then I do not see any reason to
discourage that workflow. I however suspect that people who
make such a sequence of "many too-finer-grained commits"
would inevitably include changes that do not belong together
in in one sequence on a topic branch and end up squashing
them together into one resulting commit. If that is the
case, this facility is actively encouraging a bad workflow
and we should instead teach them to use StGIT or something
saner.
But somebody asked on #git channel, so here is the rope.
Documentation/merge-options.txt | 8 ++++
git-commit.sh | 7 +++-
git-merge.sh | 72 +++++++++++++++++++++++++++++----------
git-pull.sh | 7 +++-
git-reset.sh | 2 +
5 files changed, 72 insertions(+), 24 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 53cc355..182cef5 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -6,6 +6,14 @@
not autocommit, to give the user a chance to inspect and
further tweak the merge result before committing.
+--squash::
+ Produce the working tree and index state as if a real
+ merge happened, but do not actually make a commit or
+ move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
+ cause the next `git commit` command to create a merge
+ commit. This allows you to create a single commit on
+ top of the current branch whose effect is the same as
+ merging another branch (or more in case of an octopus).
-s <strategy>, \--strategy=<strategy>::
Use the given merge strategy; can be supplied more than
diff --git a/git-commit.sh b/git-commit.sh
index 6dd04fd..cd7358e 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -564,6 +564,9 @@ then
elif test -f "$GIT_DIR/MERGE_HEAD" && test -f "$GIT_DIR/MERGE_MSG"
then
cat "$GIT_DIR/MERGE_MSG"
+elif test -f "$GIT_DIR/SQUASH_MSG"
+then
+ cat "$GIT_DIR/SQUASH_MSG"
fi | git-stripspace >"$GIT_DIR"/COMMIT_EDITMSG
case "$signoff" in
@@ -661,7 +664,7 @@ else
fi
if [ "$?" != "0" -a ! -f "$GIT_DIR/MERGE_HEAD" -a -z "$amend" ]
then
- rm -f "$GIT_DIR/COMMIT_EDITMSG"
+ rm -f "$GIT_DIR/COMMIT_EDITMSG" "$GIT_DIR/SQUASH_MSG"
run_status
exit 1
fi
@@ -727,7 +730,7 @@ else
false
fi
ret="$?"
-rm -f "$GIT_DIR/COMMIT_MSG" "$GIT_DIR/COMMIT_EDITMSG"
+rm -f "$GIT_DIR/COMMIT_MSG" "$GIT_DIR/COMMIT_EDITMSG" "$GIT_DIR/SQUASH_MSG"
if test -d "$GIT_DIR/rr-cache"
then
git-rerere
diff --git a/git-merge.sh b/git-merge.sh
index af1f25b..e6db610 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,8 +3,7 @@ #
# Copyright (c) 2005 Junio C Hamano
#
-
-USAGE='[-n] [--no-commit] [-s <strategy>]... <merge-message> <head> <remote>+'
+USAGE='[-n] [--no-commit] [--squash] [-s <strategy>]... <merge-message> <head> <remote>+'
. git-sh-setup
LF='
@@ -42,20 +41,49 @@ restorestate() {
fi
}
+finish_up_to_date () {
+ case "$squash" in
+ t)
+ echo "$1 (nothing to squash)" ;;
+ '')
+ echo "$1" ;;
+ esac
+ dropsave
+}
+
+squash_message () {
+ echo Squashed commit of the following:
+ echo
+ git-log --no-merges ^"$head" $remote
+}
+
finish () {
test '' = "$2" || echo "$2"
- case "$merge_msg" in
- '')
- echo "No merge message -- not updating HEAD"
+ case "$squash" in
+ t)
+ echo "Squash commit -- not updating HEAD"
+ squash_message >"$GIT_DIR/SQUASH_MSG"
;;
- *)
- git-update-ref HEAD "$1" "$head" || exit 1
+ '')
+ case "$merge_msg" in
+ '')
+ echo "No merge message -- not updating HEAD"
+ ;;
+ *)
+ git-update-ref HEAD "$1" "$head" || exit 1
+ ;;
+ esac
;;
esac
-
- case "$no_summary" in
+ case "$1" in
'')
- git-diff-tree -p --stat --summary -M "$head" "$1"
+ ;;
+ ?*)
+ case "$no_summary" in
+ '')
+ git-diff-tree -p --stat --summary -M "$head" "$1"
+ ;;
+ esac
;;
esac
}
@@ -66,6 +94,8 @@ do
-n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
--no-summa|--no-summar|--no-summary)
no_summary=t ;;
+ --sq|--squ|--squa|--squas|--squash)
+ squash=t no_commit=t ;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
no_commit=t ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
@@ -152,8 +182,7 @@ f,*)
?,1,"$1",*)
# If head can reach all the merge then we are up to date.
# but first the most common case of merging one remote.
- echo "Already up-to-date."
- dropsave
+ finish_up_to_date "Already up-to-date."
exit 0
;;
?,1,"$head",*)
@@ -205,8 +234,7 @@ f,*)
done
if test "$up_to_date" = t
then
- echo "Already up-to-date. Yeeah!"
- dropsave
+ finish_up_to_date "Already up-to-date. Yeeah!"
exit 0
fi
;;
@@ -310,11 +338,17 @@ case "$best_strategy" in
git-merge-$best_strategy $common -- "$head_arg" "$@"
;;
esac
-for remote
-do
- echo $remote
-done >"$GIT_DIR/MERGE_HEAD"
-echo "$merge_msg" >"$GIT_DIR/MERGE_MSG"
+
+if test "$squash" = t
+then
+ finish
+else
+ for remote
+ do
+ echo $remote
+ done >"$GIT_DIR/MERGE_HEAD"
+ echo "$merge_msg" >"$GIT_DIR/MERGE_MSG"
+fi
if test "$merge_was_ok" = t
then
diff --git a/git-pull.sh b/git-pull.sh
index 4611ae6..1670da1 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -8,7 +8,7 @@ USAGE='[-n | --no-summary] [--no-commit]
LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
. git-sh-setup
-strategy_args= no_summary= no_commit=
+strategy_args= no_summary= no_commit= squash=
while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
do
case "$1" in
@@ -17,6 +17,8 @@ do
no_summary=-n ;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
no_commit=--no-commit ;;
+ --sq|--squ|--squa|--squas|--squash)
+ squash=--squash ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -100,4 +102,5 @@ case "$strategy_args" in
esac
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
-git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
+git-merge $no_summary $no_commit $squash $strategy_args \
+ "$merge_name" HEAD $merge_head
diff --git a/git-reset.sh b/git-reset.sh
index 296f3b7..46451d0 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -61,4 +61,4 @@ case "$reset_type" in
;;
esac
-rm -f "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/rr-cache/MERGE_RR"
+rm -f "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/rr-cache/MERGE_RR" "$GIT_DIR/SQUASH_MSG"
--
1.4.1.rc1.g1f33
^ permalink raw reply related
* Re: [PATCH] Introduce Git.pm (v3)
From: Junio C Hamano @ 2006-06-23 8:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060623011205.GJ21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Also, is there any real problem with just using -fPIC?
Personally, not really, but I consider it a workaround having to
compile with -fPIC (being able to compile with -fPIC is a
feature).
Doesn't it have performance implications to use -fPIC when you
do not have to?
By the way, you also need to adjust the testsuite so that it
finds the Perl modules from freshly built tree before
installing. I think (but haven't checked yet) the stuff written
in Python does that already, so you might want to mimic it.
^ permalink raw reply
* Re: [PATCH] git-merge --squash
From: Junio C Hamano @ 2006-06-23 9:45 UTC (permalink / raw)
To: git
In-Reply-To: <7virmscl2u.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> If one's habit is to use a sequence of many commits to keep
> too-finer-grained snapshots, and the result of a squash
> commit out of such a sequence of commits is a coherent,
> self-contained unit, then I do not see any reason to
> discourage that workflow. I however suspect that people who
> make such a sequence of "many too-finer-grained commits"
> would inevitably include changes that do not belong together
> in in one sequence on a topic branch and end up squashing
> them together into one resulting commit. If that is the
> case, this facility is actively encouraging a bad workflow
> and we should instead teach them to use StGIT or something
> saner.
This part of the commentary needs a bit of clarification, as I
realize that I was a bit too negative about this --squash
option.
Suppose you have this bright idea for the new filesystem feature
that involves some VFS layer changes. Let's call that "frob"
feature, and create a topic branch to develop it in.
git checkout -b frob linus
Now, when you are done, you would want the result to be
a nice, neat, logical steps. Perhaps that would introduce
features in a sequence like this:
[PATCH 1/n] vfs: support f_op.frob_read
[PATCH 2/n] vfs: support f_op.frob_write
[PATCH 3/n] ext3: add f_op.frob_read and frob_write
[PATCH 4/n] ramfs: add f_op.frob_read and frob_write
[PATCH 5/n] vfat: add f_op.frob_read and frob_write
...
But would you be able to develop things in a neat sequence like
this? Probably not. In practice (I do not do kernel myself, so
I am just speculating), I would imagine you would pick one
filesystem (say ext3) as your initial target, and do the
codepath for frob_read operation from bottom to top (vfs to
ext3), and then do the same exercise for frob_write codepath, to
have something working first. After that, you would start
migrating another fs to your updated vfs layer, and during that
process you would find your earlier changes to the vfs are
insufficient and need further tweaks to support that other fs.
So your topic branch with many little snapshot commits might
end up looking this way (fictional show-branch output):
! [linus] linux-2.6.17
* [frob] vfs: finishing touches to frob_write
--
* [frob] vfs: finishing touches to frob_write
* [frob~1] vfat: final fix to frob_read to make it work
* [frob~2] vfs: Oops, vfat is special and frob_write needs this hack
* [frob~3] vfat: fix support frob_write for disk full condition
* [frob~4] vfat: support f_op.frob_write
* [frob~5] ext3, ramfs: give frob_read the extra parameter like vfat does.
* [frob~6] vfat: give frob_read the extra parameter
* [frob~7] vfs: frob_read needs an extra parameter for vfat.
* [frob~8] ramfs: add frob_write, that was easy.
* [frob~9] ramfs: add frob_read, that was easy.
* [frob~10] ext3: more frob_write, now ext3 works!
* [frob~11] ext3: starting to add frob_write
* [frob~12] vfs: support frob_write
* [frob~13] vfs: enhance frob_read for special case, now ext3 works!
* [frob~14] ext3: yet more frob_read
* [frob~15] ext3: more frob_read
* [frob~16] ext3: starting to add frob_read
* [frob~17] vfs: support frob_read
+* [linus] linux-2.6.17
The --squash merge alone would not help sorting out something
like this. However, you could do something like this to
separate them out and squash:
git checkout -b temp master
for c in 17 13 7 1; do git cherry-pick frob~$c; done
git checkout master
git pull --sq . temp
git commit -a -m 'vfs: support f_op.frob_read'
git checkout temp
git reset --hard master
for c in 12 2 0; do git cherry-pick frob~$c; done
git checkout master
git pull --sq . temp
git commit -a -m 'vfs: support f_op.frob_write'
git checkout temp
git reset --hard master
for c in 16 15 14 11 10 5; do git cherry-pick frob~$c; done
git checkout master
git pull --sq . temp
edit to remove changes to ramfs portion
git commit -a -m 'ext3: add f_op.frob_read and frob_write'
...
So in that sense I would imagine --squash is not really useless
in such a situation as I made it sound like, but at the same
time I suspect people might be better off to use tools like
StGIT which are specially designed to support such a workflow if
they were to do this.
^ permalink raw reply
* Re: What's in git.git and announcing v1.4.1-rc1
From: Johannes Schindelin @ 2006-06-23 11:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Git Mailing List, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.64.0606221301500.5498@g5.osdl.org>
Hi,
On Thu, 22 Jun 2006, Linus Torvalds wrote:
> On Thu, 22 Jun 2006, Junio C Hamano wrote:
> >
> > - diff --color (Johannes).
>
> - default to red/green for old/new lines. That's the norm, I'd think.
... and which happens to be useless for 10% of the male population (and
even more if you look specifically at Asian people). But then, I just
pasted that part from somewhere else.
Besides, I rarely have a fondue fork handy when I sit in front of the
computer. I actually do not own one. And when I am sitting in front of the
computer, shops typically are closed (yeah, I am living in Germany, but we
_do_ have cars...). So at least for 100% of the writers of this email,
your warning just does not apply.
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git and announcing v1.4.1-rc1
From: Johannes Schindelin @ 2006-06-23 11:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Petr Baudis, Junio C Hamano, Git Mailing List,
Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.64.0606221402140.6483@g5.osdl.org>
Hi,
On Thu, 22 Jun 2006, Linus Torvalds wrote:
> On Thu, 22 Jun 2006, Petr Baudis wrote:
> >
> > Isn't manually numbering the enum choices somewhat pointless, though?
> > (Actually makes it more difficult to do changes in it later.)
>
> Yeah, I just mindlessly followed Johannes' original scheme.
... which wasn't his, to begin with ...
^ permalink raw reply
* The newest Online Casinno. Go and Play It
From: Estela @ 2006-06-23 11:32 UTC (permalink / raw)
To: git
God helps those who help themselves
Online Casino with 85+ games. PPlay It Now! http://ewcnss.com/d1/check
So he that goeth in to his neighbour's wife; whosoever toucheth her shall not be innocent.
^ permalink raw reply
* A series file for git?
From: Eric W. Biederman @ 2006-06-23 11:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vpshtyffk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> (a) git-rev-list --pretty=oneline "$upstream"..ORIG_HEAD > rev-list
>>
>> (b) edit the rev-list, moving the single lines around, deleting them, etc
>>
>> (c) cat rev-list |
>> git-format-patch -k --stdout --stdin --full_index |
>> git-am
>>
> Tentatively my feeling is that we should make it known that the
> list format-patch takes from --stdin is supposed to be _not_
> reversed, and do nothing in format-patch. In other words, the
> list fed is a moral equivalent to quilt "series" file.
Agreed that seem to make a lot of sense.
> What this means is:
>
> git-format-patch $revargs
>
> is not equivalent to
>
> git-rev-list $revargs | git-format-patch --stdin
>
> but is equivalent to
>
> git-rev-list $revargs | tac | git-format-patch --stdin
At least for now the using tac is fine. Longer term I think
having some reverse arguments to rev-list or even better
git-log so we can review patches in order instead backwards
would be very interesting.
> Thoughts from the list?
So I have played with this some and a bit of feedback.
I was using:
git-rev-list $revargs | tac > list
for sha1 in $(cat list); do git-cherry-pick -r $sha1 ; done
Is there any real difference between using git-format-patch | git-am
and using git-am to apply patches. I was using git-cherry-pick simply
because it was easier to sha1 too.
- When you reorder patches minor merge conflicts are common
so a big pipe won't work very often in practice. So you
need a way to handle failures in the middle.
- Keeping patches in git and just remembering their sha1 is nice
but it has the downside that it can be really easy to loose
the sha1, and thus the patch. So some sort of history mechanism
so you can get back to where you were would be nice.
- This is a similar technique to topic branches. However in some
of the more interesting cases a topic branch can't be used because
you have a whole series of little changes, that allow depend on
each other. So topic branches need not apply.
- One of the places where we currently uses series files
(patch-scripts && quilt), and heavy cherry picking is for patch
aging. That is letting patches sit in a testing branch for
a while so people have a chance to test and look at them.
The important pieces there are the ability to reorder the changes
to put the patches with the highest confidence first.
The ability to comment on the patches so that it is possible
to record groups of patches and information about their relative
stability. As once a patch series gets large without at least
a few comments it is too much for a person to remember what
is happening with each patch without a few clues.
- The other place where we use series files is in pure development
where we are breaking up or otherwise creating the needed changes
in a set of simple obviously correct changes.
....
So I think it could be very interesting to have a series file
as something the base git porcelain helps to deal with.
If we create a meta data branch with just the series file
we can remove the risk of loosing things, as we always
have a path back to the old history if we want it.
We can keep track of the series file with a SERIES_HEAD
similar to FETCH_HEAD. This fairly easily allows editing
in different places in the patch stack that normally happens
with quilt or patch-scripts.
We can put comments in a series file to keep track of probationary
patches.
The two tricky pieces I see with this idea are:
- teaching git-fsck-objects that we have a sha1 in a blob objects.
- Where to put the active checkout series file when we are working,
so we don't stumble on it.
...
I'm trying to sort out a sane work flow for developing with a large
number of highly related patches on the development side. I care
because the way I think I usually fix the root cause of problems.
It took me nearly 25 patches to decouple the brain damage the msi
code imposed on x86 irq handling. In the development of that
I had to reorder and edit things extensively as I broke the
work up, and created a sane patch flow.
The trick with rev-list | tac to create a series file for reordering
changes was very useful but it wasn't enough to say it solve the
problem.
One trivial issue was that git-cherry-pick -r always does the full
git-commit so it is much more I/O bound than necessary, because
git-commit does git-status. Which is just silly if you are applying
a bunch of changes that apply without errors.
Eric
^ permalink raw reply
* Never-seen Onlinee Casino. Go and Playy It
From: Walker @ 2006-06-23 11:37 UTC (permalink / raw)
To: glenn
Age is a very high price to pay for maturity If cow-man pass wild meat whah mek me must pick up am.
Online Casino witth 85+ games. Play It Now! http://ewcnss.com/d1/check
Old habits die hard Haste makes waste.
^ permalink raw reply
* Re: [PATCH] Make -p --stat and --stat -p behave like --patch-with-stat
From: Timo Hirvonen @ 2006-06-23 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: junkio, git
In-Reply-To: <7vr71hkofg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> The diff output has four parts, each of which can independently
> be enabled. When no options are specified on the command line,
> each command has its own default but in general the low-level
> commands default to raw output only, and the higher-level ones
> default to patch output only.
>
> The four parts are controlled with a bit each, and are output in
> the fixed order (iow the order of the options given from the
> command line does not matter): raw, stat, summary and patch.
>
> When --name-only or --name-status is specified, that would be
> the only thing that is output (iow the above four parts would
> not be shown, just names optionally with the status are shown).
>
> The four switches are: --raw, --stat, --summary and --patch.
> Existing flags are supported as obvious shorthands to turn on
> the corresponding bits:
>
> -p, -u --patch
> --patch-with-raw --raw --patch
> --patch-with-stat --stat --patch
>
> Anybody interested in doing a patch?
I'll try. It shouldn't be too hard.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Introduce Git.pm (v3)
From: Eric W. Biederman @ 2006-06-23 12:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vejxgckq9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> Also, is there any real problem with just using -fPIC?
>
> Personally, not really, but I consider it a workaround having to
> compile with -fPIC (being able to compile with -fPIC is a
> feature).
>
> Doesn't it have performance implications to use -fPIC when you
> do not have to?
>
> By the way, you also need to adjust the testsuite so that it
> finds the Perl modules from freshly built tree before
> installing. I think (but haven't checked yet) the stuff written
> in Python does that already, so you might want to mimic it.
So what was being compiled was a shared Git.so.
32bit x86 is on of the few architectures that allows you to build
a .so without compiling with -fPIC.
The question is why are we building with a .so?
Eric
^ permalink raw reply
* Re: git-format-patch builtin isn't using git-cherry?
From: Johannes Schindelin @ 2006-06-23 12:05 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90606221732k6d93bcceic2761081d7a7c72b@mail.gmail.com>
Hi,
On Fri, 23 Jun 2006, Martin Langhoff wrote:
> Reading cmd_format_patch() in builtin-log.c, it seems to have lost that
> magic that made it so useful... :( Can a kind soul that speaks C
> fluently help me out here?
My fault. But note that it is much faster now, too! I think I can trick it
back into doing something like the old script, but I'll do that only with
an option (in order to not slow down the now-common case). And it will
take a while. So if anybody wants to give it a try...
Basically, it will involve the following recipe:
- add a DIFF_FORMAT_PATCH_ID
- calculate _all_ the patch ids in upstream since branch point
- in cmd_format_patch, in the get_revision() loop, skip those
commits which have the same patch id
Ciao,
Dscho
^ permalink raw reply
* Re: git-format-patch builtin isn't using git-cherry?
From: Timo Hirvonen @ 2006-06-23 12:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: martin.langhoff, git
In-Reply-To: <Pine.LNX.4.63.0606231357420.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Basically, it will involve the following recipe:
>
> - add a DIFF_FORMAT_PATCH_ID
Please don't add any DIFF_FORMAT_*. I'm cleaning the diff output code
and replacing diff_options.output_format with one-bit flags.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] git-merge --squash
From: Thomas Glanzmann @ 2006-06-23 12:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5d09pe2.fsf@assigned-by-dhcp.cox.net>
Hello Junio,
> So in that sense I would imagine --squash is not really useless
> in such a situation as I made it sound like, but at the same
> time I suspect people might be better off to use tools like
> StGIT which are specially designed to support such a workflow if
> they were to do this.
thanks for --squash. So --squash is basically a 'suck multiple deltas
from another branch into ., but don't commit it'. I very often use that
way of work flow. I do small and many commits, and when I am done I
merge them to one a bit bigger one and submit it upstream. I useally use
'one branch per feature'.
Thomas
^ permalink raw reply
* Re: git-format-patch builtin isn't using git-cherry?
From: Johannes Schindelin @ 2006-06-23 12:33 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: martin.langhoff, git
In-Reply-To: <20060623152321.2c20e9f8.tihirvon@gmail.com>
Hi,
On Fri, 23 Jun 2006, Timo Hirvonen wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > Basically, it will involve the following recipe:
> >
> > - add a DIFF_FORMAT_PATCH_ID
>
> Please don't add any DIFF_FORMAT_*. I'm cleaning the diff output code
> and replacing diff_options.output_format with one-bit flags.
Okay. For the purposes of git-format-patch, this is not needed anyway, but
rather a function which takes two tree objects and returns the patch id.
When you are finished it should be easy to add this as a display format.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge --squash
From: Johannes Schindelin @ 2006-06-23 12:36 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Junio C Hamano, git
In-Reply-To: <20060623122501.GD15631@cip.informatik.uni-erlangen.de>
Hi,
On Fri, 23 Jun 2006, Thomas Glanzmann wrote:
> Hello Junio,
>
> > So in that sense I would imagine --squash is not really useless
> > in such a situation as I made it sound like, but at the same
> > time I suspect people might be better off to use tools like
> > StGIT which are specially designed to support such a workflow if
> > they were to do this.
>
> thanks for --squash. So --squash is basically a 'suck multiple deltas
> from another branch into ., but don't commit it'. I very often use that
> way of work flow. I do small and many commits, and when I am done I
> merge them to one a bit bigger one and submit it upstream. I useally use
> 'one branch per feature'.
Isn't this the same as 'git-cherry-pick -n'? I often do a poor man's StGIT
by cherry picking my way through a messy branch, often combining patches
by '-n'.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce Git.pm (v3)
From: Petr Baudis @ 2006-06-23 12:39 UTC (permalink / raw)
To: Junio C Hamano, Eric W. Biederman; +Cc: git
In-Reply-To: <7vejxgckq9.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Jun 23, 2006 at 10:57:50AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Also, is there any real problem with just using -fPIC?
>
> Personally, not really, but I consider it a workaround having to
> compile with -fPIC (being able to compile with -fPIC is a
> feature).
Well, for the .xs you do need an .so and for that you apparently need
-fPIC on most architectures, so there's no way around it.
There's a patch to build libgit.so, would you take it as an excuse to
always compile with -fPIC? ;-)
> Doesn't it have performance implications to use -fPIC when you
> do not have to?
No idea here.
> By the way, you also need to adjust the testsuite so that it
> finds the Perl modules from freshly built tree before
> installing. I think (but haven't checked yet) the stuff written
> in Python does that already, so you might want to mimic it.
It should be enough to -I../perl/blib/lib -I../perl/blib/arch/auto/Git.
Dear diary, on Fri, Jun 23, 2006 at 02:04:17PM CEST, I got a letter
where "Eric W. Biederman" <ebiederm@xmission.com> said that...
> The question is why are we building with a .so?
To make use of it in Git.pm - it can call libgit routines directly from
inside of Perl, but for that it needs to dynamically link libgit to the
Perl process on the fly (using dlopen()).
We _can_ avoid the .so, but that involved producing a new perl
executable with libgit statically linked to it, which is quite
impractical, so to say.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH] git-merge --squash
From: Thomas Glanzmann @ 2006-06-23 12:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606231433370.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hello,
> Isn't this the same as 'git-cherry-pick -n'? I often do a poor man's StGIT
> by cherry picking my way through a messy branch, often combining patches
> by '-n'.
yes it is. I didn't know about the cherry-pick -n option. Thanks.
Thomas
^ permalink raw reply
* Re: [PATCH] Introduce Git.pm (v3)
From: Petr Baudis @ 2006-06-23 12:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7g079$8qt$1@sea.gmane.org>
Dear diary, on Fri, Jun 23, 2006 at 08:03:23AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Perhaps Git.pm should provide also generic, pure Perl (and slower)
> fallback implementation (when for some reason we cannot compile XS).
I fiercely want to avoid this if there is any other possible way to go
about it - this is a path to hell of massive code duplication and
additional work, as the number of routines will grow. If it is question
of spending many developer-hours uselessly duplicating code in a way
that'll be much slower than possible anyway OR building with -fPIC... ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* [PATCH] Customizable error handlers
From: Petr Baudis @ 2006-06-23 13:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch makes the usage(), die() and error() handlers customizable.
Nothing in the git code itself uses that but many other libgit users
(like Git.pm) will.
This is implemented using the mutator functions primarily because you
cannot directly modifying global variables of libgit from a program that
dlopen()ed it, apparently. But having functions for that is a better API
anyway.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
git-compat-util.h | 10 +++++++---
usage.c | 50 +++++++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 5d543d2..e954002 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -36,9 +36,13 @@ #endif
#endif
/* General helper functions */
-extern void usage(const char *err) NORETURN;
-extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
-extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
+void usage(const char *err) NORETURN;
+void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
+int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
+
+void set_usage_routine(void (*routine)(const char *err) NORETURN);
+void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN);
+void set_error_routine(int (*routine)(const char *err, va_list params));
#ifdef NO_MMAP
diff --git a/usage.c b/usage.c
index 1fa924c..445456d 100644
--- a/usage.c
+++ b/usage.c
@@ -12,28 +12,68 @@ static void report(const char *prefix, c
fputs("\n", stderr);
}
-void usage(const char *err)
+void usage_builtin(const char *err)
{
fprintf(stderr, "usage: %s\n", err);
exit(129);
}
+void die_builtin(const char *err, va_list params)
+{
+ report("fatal: ", err, params);
+ exit(128);
+}
+
+int error_builtin(const char *err, va_list params)
+{
+ report("error: ", err, params);
+ return -1;
+}
+
+
+/* If we are in a dlopen()ed .so write to a global variable would segfault
+ * (ugh), so keep things static. */
+static void (*usage_routine)(const char *err) NORETURN = usage_builtin;
+static void (*die_routine)(const char *err, va_list params) NORETURN = die_builtin;
+static int (*error_routine)(const char *err, va_list params) = error_builtin;
+
+void set_usage_routine(void (*routine)(const char *err) NORETURN)
+{
+ usage_routine = routine;
+}
+
+void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN)
+{
+ die_routine = routine;
+}
+
+void set_error_routine(int (*routine)(const char *err, va_list params))
+{
+ error_routine = routine;
+}
+
+
+void usage(const char *err)
+{
+ usage_routine(err);
+}
+
void die(const char *err, ...)
{
va_list params;
va_start(params, err);
- report("fatal: ", err, params);
+ die_routine(err, params);
va_end(params);
- exit(128);
}
int error(const char *err, ...)
{
va_list params;
+ int ret;
va_start(params, err);
- report("error: ", err, params);
+ ret = error_routine(err, params);
va_end(params);
- return -1;
+ return ret;
}
^ permalink raw reply related
* [PATCH] git-commit: allow -e option anywhere on command line
From: Jeff King @ 2006-06-23 13:43 UTC (permalink / raw)
To: junkio; +Cc: git
Previously, the command 'git-commit -e -m foo' would ignore the '-e' option
because the '-m' option overwrites the no_edit flag during sequential
option parsing. Now we cause -e to reset the no_edit flag after all
options are parsed.
Signed-off-by: Jeff King <peff@peff.net>
---
git-commit.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 6dd04fd..4bb16db 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -199,6 +199,7 @@ only=
logfile=
use_commit=
amend=
+edit_flag=
no_edit=
log_given=
log_message=
@@ -246,7 +247,7 @@ do
shift
;;
-e|--e|--ed|--edi|--edit)
- no_edit=
+ edit_flag=t
shift
;;
-i|--i|--in|--inc|--incl|--inclu|--includ|--include)
@@ -384,6 +385,7 @@ do
;;
esac
done
+case "$edit_flag" in t) no_edit= ;; esac
################################################################
# Sanity check options
--
1.4.1.rc1.gf603-dirty
^ permalink raw reply related
* Re: [PATCH] Customizable error handlers
From: Petr Baudis @ 2006-06-23 13:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060623133227.27854.65567.stgit@machine.or.cz>
Dear diary, on Fri, Jun 23, 2006 at 03:32:27PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 5d543d2..e954002 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -36,9 +36,13 @@ #endif
> #endif
>
> /* General helper functions */
> -extern void usage(const char *err) NORETURN;
> -extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
> -extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
> +void usage(const char *err) NORETURN;
> +void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
> +int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
Wah, this kind of slipped through. Below is a patch without the
externs removed. Sorry about the noise.
> int error(const char *err, ...)
> {
> va_list params;
> + int ret;
>
> va_start(params, err);
> - report("error: ", err, params);
> + ret = error_routine(err, params);
> va_end(params);
> - return -1;
> + return ret;
> }
BTW, I don't mind if you just force the return value to -1 here.
It might be saner.
---
[PATCH] Customizable error handlers
This patch makes the usage(), die() and error() handlers customizable.
Nothing in the git code itself uses that but many other libgit users
(like Git.pm) will.
This is implemented using the mutator functions primarily because you
cannot directly modifying global variables of libgit from a program that
dlopen()ed it, apparently. But having functions for that is a better API
anyway.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
diff --git a/git-compat-util.h b/git-compat-util.h
index 5d543d2..0c5ceb3 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -40,6 +40,10 @@ extern void usage(const char *err) NORET
extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
+extern void set_usage_routine(void (*routine)(const char *err) NORETURN);
+extern void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN);
+extern void set_error_routine(int (*routine)(const char *err, va_list params));
+
#ifdef NO_MMAP
#ifndef PROT_READ
diff --git a/usage.c b/usage.c
index 1fa924c..445456d 100644
--- a/usage.c
+++ b/usage.c
@@ -12,28 +12,68 @@ static void report(const char *prefix, c
fputs("\n", stderr);
}
-void usage(const char *err)
+void usage_builtin(const char *err)
{
fprintf(stderr, "usage: %s\n", err);
exit(129);
}
+void die_builtin(const char *err, va_list params)
+{
+ report("fatal: ", err, params);
+ exit(128);
+}
+
+int error_builtin(const char *err, va_list params)
+{
+ report("error: ", err, params);
+ return -1;
+}
+
+
+/* If we are in a dlopen()ed .so write to a global variable would segfault
+ * (ugh), so keep things static. */
+static void (*usage_routine)(const char *err) NORETURN = usage_builtin;
+static void (*die_routine)(const char *err, va_list params) NORETURN = die_builtin;
+static int (*error_routine)(const char *err, va_list params) = error_builtin;
+
+void set_usage_routine(void (*routine)(const char *err) NORETURN)
+{
+ usage_routine = routine;
+}
+
+void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN)
+{
+ die_routine = routine;
+}
+
+void set_error_routine(int (*routine)(const char *err, va_list params))
+{
+ error_routine = routine;
+}
+
+
+void usage(const char *err)
+{
+ usage_routine(err);
+}
+
void die(const char *err, ...)
{
va_list params;
va_start(params, err);
- report("fatal: ", err, params);
+ die_routine(err, params);
va_end(params);
- exit(128);
}
int error(const char *err, ...)
{
va_list params;
+ int ret;
va_start(params, err);
- report("error: ", err, params);
+ ret = error_routine(err, params);
va_end(params);
- return -1;
+ return ret;
}
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply related
* Re: What's in git.git and announcing v1.4.1-rc1
From: Pádraig Brady @ 2006-06-23 14:04 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Junio C Hamano, Git Mailing List,
Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.63.0606231305000.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 22 Jun 2006, Linus Torvalds wrote:
>
>
>>On Thu, 22 Jun 2006, Junio C Hamano wrote:
>>
>>> - diff --color (Johannes).
>>
>> - default to red/green for old/new lines. That's the norm, I'd think.
>
>
> ... and which happens to be useless for 10% of the male population (and
> even more if you look specifically at Asian people). But then, I just
> pasted that part from somewhere else.
:)
So 10% of the male population need to learn
traffic light positions rather than colours?
I'm red/green colour blind which means I can't
distinguish _subtley_ different shades of red and green.
vim is another fondue fork offender as it merges
syntax highlighting and diff colours in diff mode (vimdiff).
I put the following in ~/.vimrc to disable that madness:
if &diff
"I'm only interested in diff colours
syntax off
endif
Pádraig.
^ 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