* Re: uncommon shell code
From: Junio C Hamano @ 2005-09-22 22:03 UTC (permalink / raw)
To: Robert Watson; +Cc: git
In-Reply-To: <72499e3b05092207326abadd91@mail.gmail.com>
Robert Watson <robert.oo.watson@gmail.com> writes:
> I found the following shell code in git-tag.sh (and others):
My fault; see point 2. in this article:
http://marc.theaimsgroup.com/?l=git&m=112386506308820&w=2
Please either get used to it or wait until I decide to modernize
the scripts wholesale, whichever comes first.
^ permalink raw reply
* Re: Please undo "Use git-merge instead of git-resolve in
From: Linus Torvalds @ 2005-09-22 22:05 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Jon Loeliger, git
In-Reply-To: <Pine.LNX.4.63.0509221747340.23242@iabervon.org>
On Thu, 22 Sep 2005, Daniel Barkalow wrote:
>
> Would it be worthwhile to have a flag to make git-read-tree abort rather
> than making a mess if you have any dirty state and the merge isn't
> completely automatic? It's certainly easy enough to write.
I don't think it would be wrong, necessarily.
On the other hand, it might be easier to just instead do a
git diff HEAD > .git/pre-merge-diff
and let it go at that. If the merge ends up being nasty, you can then just
do
git reset --hard
git-apply .git/pre-merge-diff
or something.
I dunno. This is not something that has caused me a lot of headache. I
certainly _hope_ that people generally don't keep a lot of dirty state
around: I do it for truly small stuff that I don't care about.
Let's face it - if I cared about it, I'd have committed it (possibly to
another branch). It's not like that's hard. So the dirty stuff really does
tend to be only trivial things.
Linus
^ permalink raw reply
* Re: Please undo "Use git-merge instead of git-resolve in
From: Junio C Hamano @ 2005-09-22 22:22 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP0510EEC44C7F787F27215AAE970@CEZ.ICE>
"Sean" <seanlkml@sympatico.ca> writes:
> Why doesn't cogito just use the git fetch/pull commands? Why does it
> need anything special? It seems like cogito is doing more than just
> being an ease-of-use layer above git.
The way this question is posed is quite unfair to Pasky -- it
makes him look needlessly bad.
The simple reason is because Cogito had its own richer
fetch/pull first. The development of git aware pack transfer
protocols by Linus and the list discussion for multi-head pushes
and pulls came much later, which resulted in the current 'git
fetch/pull' interface.
^ permalink raw reply
* Re: Please undo "Use git-merge instead of git-resolve in
From: Sean @ 2005-09-22 22:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6h8lp3k.fsf@assigned-by-dhcp.cox.net>
On Thu, September 22, 2005 6:22 pm, Junio C Hamano said:
> "Sean" <seanlkml@sympatico.ca> writes:
>
>> Why doesn't cogito just use the git fetch/pull commands? Why does it
>> need anything special? It seems like cogito is doing more than just
>> being an ease-of-use layer above git.
>
> The way this question is posed is quite unfair to Pasky -- it
> makes him look needlessly bad.
Will try to pose it differently then, because it was not meant to make him
"look bad". In a different email Pasky seemed to be musing that cogito
might do away with fast forward merges. This too seemed like a decision
best left to the plumbing, so i have been wondering how Pasky views
cogito's relationship to git.
But the immediate question really was, wouldn't it be better if cogito
used the same code paths that git uses for push/pull/fetch? Is there a
reason that this isn't possible?
> The simple reason is because Cogito had its own richer
> fetch/pull first. The development of git aware pack transfer
> protocols by Linus and the list discussion for multi-head pushes
> and pulls came much later, which resulted in the current 'git
> fetch/pull' interface.
Yes, cogito had it first but once this functionality gets pushed down into
git (where it's been for a while now) it makes a lot of sense for the
procelain layers to use it. That way the functionality only has to be
maintained in one place and nobody has to guess what transports work with
cogito or git etc. But perhaps there are reasons that this just isn't
possible with the cogito code, i dunno.
Sean
^ permalink raw reply
* Re: 'bad file' error updating from Linus
From: Linus Torvalds @ 2005-09-22 23:32 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dgv8jv$amv$1@sea.gmane.org>
On Thu, 22 Sep 2005, walt wrote:
>
> I think it was a disk failure, but no matter -- it's fixed now.
Nope, it's not.
It just depends on which IP address you happen to get when you look at
www.kernel.org.
www.kernel.org resolves to two addresses:
Name: zeus-pub.kernel.org
Address: 204.152.191.5
Name: zeus-pub.kernel.org
Address: 204.152.191.37
and the .5 address is working, but the .37 address has the broken mirror.
I thought hpa took it out of service while it was re-syncing, but
apparently not.
Linus
^ permalink raw reply
* Re: [PATCH] Verbose git-daemon logging
From: Junio C Hamano @ 2005-09-22 23:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050922092528.GB21019@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> What would be knowing parent PID be useful for? (It's not really the PID
> number that's useful anyway (at least mostly), it's just a good unique
> identifier to distinguish between several simultaneous sessions.)
Maybe running two daemons serving two sets of repos? But anyway
what you have look more consistent so let's keep that.
> Fixed up patch follows.
Thanks.
> +static void logreport(const char *err, va_list params)
> +{
> + /* We should do a single write so that it is atomic and output
> + * of several processes does not get intermangled. */
> + char buf[1024];
> + int buflen;
> + int maxlen, msglen;
> +
> + buflen = snprintf(buf, sizeof(buf), "[%d] ", getpid());
> +
> + maxlen = sizeof(buf) - buflen - 1;
> + msglen = vsnprintf(buf + buflen, maxlen, err, params);
> + if (msglen > maxlen)
> + msglen = maxlen;
> + else if (msglen < 0)
> + msglen = -1; /* Protect against weird return values. */
> + buflen += msglen;
> +
> + buf[buflen++] = '\n';
> + buf[buflen] = '\0';
> +
> + fputs(buf, stderr);
> +}
The tail part still looks odd here. Maybe something like this?
+static void logreport(const char *err, va_list params)
+{
+ /* We should do a single write so that it is atomic and output
+ * of several processes does not get intermangled. */
+ char buf[1024];
+ int buflen;
+ int maxlen, msglen;
+
+ /* sizeof(buf) should be big enough for "[pid] \n" */
+ buflen = snprintf(buf, sizeof(buf), "[%d] ", getpid());
+
+ maxlen = sizeof(buf) - buflen - 1; /* -1 for our own LF */
+ msglen = vsnprintf(buf + buflen, maxlen, err, params);
+
+ /* maxlen counted our own LF but also counts space given to
+ * vsnprintf for the terminating NUL. We want to make sure that
+ * we have space for our own LF and NUL after the "meat" of the
+ * message, so truncate it at maxlen - 1.
+ */
+ if (msglen > maxlen - 1)
+ msglen = maxlen - 1;
+ else if (msglen < 0)
+ msglen = 0; /* Protect against weird return values. */
+ buflen += msglen;
+
+ buf[buflen++] = '\n';
+ buf[buflen] = '\0';
+
+ fputs(buf, stderr);
+}
^ permalink raw reply
* Re: [PATCH] Verbose git-daemon logging
From: Linus Torvalds @ 2005-09-22 23:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vd5n0lle8.fsf@assigned-by-dhcp.cox.net>
On Thu, 22 Sep 2005, Junio C Hamano wrote:
>
> The tail part still looks odd here. Maybe something like this?
And if you actually want it to be more reliable, don't use fputs. That
can still split lines, and even if it doesn't, it doesn't help.
> + buf[buflen++] = '\n';
> + buf[buflen] = '\0';
> +
> + fputs(buf, stderr);
Why use "fputs()", when you migth as well do write()?
Also, it would probably be nice if you allow the use of syslog()..
Linus
^ permalink raw reply
* Re: Please undo "Use git-merge instead of git-resolve in git-pull"
From: Petr Baudis @ 2005-09-23 0:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, David S. Miller, junkio, git
In-Reply-To: <Pine.LNX.4.58.0509211902010.2553@g5.osdl.org>
Dear diary, on Thu, Sep 22, 2005 at 04:10:08AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> But cogito at least _used_ to have some special logic for moving patches
> forward.
Yes, but it is used only in case of fast-forward commits.
> git-resolve-script never had that - it only ever did the per-file
> three-way merge, and refused to touch dirty state except for the
> "everything stays the same" case.
>
> Oh. I'm looking at the current cg-merge thing, and I think I see the
> problem: it's doing
>
> git-checkout-index -f -u -a
>
> at the end. That's not only unnecessary, since it uses the "-u" flag to
> "git-read-tree", but it will force an overwrite of the working tree, and
> is thus actively incorrect.
>
> Pasky?
Oops. How brown-paper-bag-ish. Thanks for pointing this out, that was
obviously horribly wrong, and it was indeed apparently happily trashing
all the local changes. I've removed it, and added proper handling for
cases when conflicts arise from merge over a tree with local changes -
that was troublesome since cg-commit after resolving the conflicts would
commit the local changes too. It won't anymore, and cg-status will mark
those files appropriately. Woohoo.
I've also added a rather elaborate regression testing for cg-merge, so I
hope that will help catch any future breakages. Hmm, I have to say that
while I find writing those tests incredibly boring and annoying, it is
pretty nice when I already have them. ;-)
This fix alone is worthy a release, so I'll do one tomorrow.
--
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
* [PATCH] Cogito: Minor documentation fixes
From: Jonas Fonseca @ 2005-09-23 0:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
- Link to the new cg-object-id man page from cogito(7).
- Fix cg-help usage string listing in cogito(7).
- Make the cg-commit -m option more conforming to other options taking
arguments (the old usage remains).
- Use COMMIT_ID consistently.
Signed-of-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/make-cogito-asciidoc | 4 ++--
cg-commit | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/make-cogito-asciidoc b/Documentation/make-cogito-asciidoc
--- a/Documentation/make-cogito-asciidoc
+++ b/Documentation/make-cogito-asciidoc
@@ -24,11 +24,11 @@ print_command_info()
echo
case "$cmdname" in
- cg-X*|*-id)
+ cg-X*)
echo "$cmdname::"
;;
cg-*)
- usage=$(sed -n '/^USAGE=/,0s/.*cg-[^ ]*\(.*\)"/\1/p' < $command)
+ usage=$(sed -n '/^USAGE=/,0s/.*"cg-[^ ]*\(.*\)"/\1/p' < $command)
echo "gitlink:$cmdname[] $usage::"
;;
esac
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -25,7 +25,7 @@
# Note, this is used internally by 'Cogito' when merging. This option
# does not make sense when files are given on the command line.
#
-# -mMESSAGE::
+# -m MESSAGE::
# Specify the commit message, which is used instead of starting
# up an editor (if the input is not `stdin`, the input is appended
# after all the '-m' messages). Multiple '-m' parameters are appended
@@ -111,7 +111,7 @@
# EDITOR::
# The editor used for entering revision log information.
-USAGE="cg-commit [-mMESSAGE]... [-C] [-e | -E] [-c COMMITID] [FILE]... [< MESSAGE]"
+USAGE="cg-commit [-m MESSAGE]... [-C] [-e | -E] [-c COMMIT_ID] [FILE]... [< MESSAGE]"
. ${COGITO_LIB}cg-Xlib || exit 1
--
Jonas Fonseca
^ permalink raw reply
* Re: 'bad file' error updating from Linus
From: walt @ 2005-09-23 0:56 UTC (permalink / raw)
To: git
In-Reply-To: <dgv8jv$amv$1@sea.gmane.org>
walt wrote:
[...]
> After I repeated the cg-update (successfully) I was still left with
> the 'bad file' error. I tried 'cg-restore' and the error went away.
Oops -- correction!
After encountering the same problem on a different machine, I find
that 'cg-reset' is the one which fixed the error, not 'cg-restore'.
I believe that I tried both commands on the first machine, so I was
uncertain which one actually did the fix.
^ permalink raw reply
* Re: GIT - breaking backward compatibility
From: Junio C Hamano @ 2005-09-23 6:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050922144124.GJ21019@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Actually, could we please keep the old git-ssh-* stuff for a bit
> (perhaps a lot) longer?
Yeah, I think that's very sensible. Thanks!
Updated the renames plan in the TODO document.
^ permalink raw reply
* [ANNOUNCE] GIT 0.99.7b
From: Junio C Hamano @ 2005-09-23 6:18 UTC (permalink / raw)
To: git
GIT 0.99.7b
Contains the following post-0.99.7a fixes:
- Commit walker performance fix, mostly during walking commits
in a downloaded packfile, thanks to Sergey Vlasov.
- Squelch unnecessarily alarming error message from fetch and
clone over rsync transport, when remote repository does not
borrow anything from other repositories.
I've seen enough people got annoyed/worried/alarmed after
seeing this one on both git and linux-kernel list.
- Documentation was not rebuilt before installation, noticed by
Randal L Schwartz.
- Fetching of objects over http transport got a bit safer.
Tarballs, RPMs and Debs are available at
http://kernel.org/pub/software/scm/git/
Or, if you use git already:
{http,rsync}://kernel.org/pub/scm/git/git.git/
^ permalink raw reply
* /bin/sh portability question
From: Peter Eriksen @ 2005-09-23 7:50 UTC (permalink / raw)
To: git
Hello,
It seems things are progressing nicely with regard to
Solaris portability. However, I still have a few problems:
1) Maybe I didn't notice some new configuration option,
but strcasestr is still not found with a simple "gmake".
2) In many of the shell scripts there is the idiom:
#!/bin/sh
cmd=
path=$(dirname $0)
case "$#" in
0) ;;
*) cmd="$1"
shift
When run, this gives the error:
./git.sh: syntax error at line 4: `path=$' unexpected
I think it's because (on my Solaris at least), sh is really
sh and is not symlinked to bash, and sh doesn't like that
syntax. Are there any good solutions to this other than
making the administrators actually change sh to a symlink,
(which I tried)?
/Peter
^ permalink raw reply
* Re: /bin/sh portability question
From: Junio C Hamano @ 2005-09-23 8:24 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20050923075058.GA25473@bohr.gbar.dtu.dk>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> 1) Maybe I didn't notice some new configuration option,
> but strcasestr is still not found with a simple "gmake".
Perhaps "gmake NO_STRCASESTR=YesPlease"?
Do people use glibc or other alternative C libraries on Solaris
these days? If nobody does, and everybody on SunOS lack
strcasestr, we could make SunOS imply NO_STRCASESTR in the
Makefile.
> 2) In many of the shell scripts there is the idiom:
> I think it's because (on my Solaris at least), sh is really
> sh and is not symlinked to bash, and sh doesn't like that
> syntax.
Writing $(command) instead of `command` is not a bashism; Korn
supports it and even ash seems to. But saying that would not
reduce the pain from non-sysadmins.
In many places we could just rewrite them to old-timer back-tick
form, unless we nest, in which case you would end up doing
something like this for readability:
foo=$(command $(command to compute arg to it))
arg=`command to compute arg to it`
foo=`command "$arg"`
I haven't assessed the extent of damage if we tried to use ``
for portability lately (I did once, and it did not look too bad
back then). If somebody comes up with a readable patch, I might
be persuaded to take it [*1*].
Another thing that will bite you is the use of shell arrays -- I
was trying to stay away from it but at least git-grep uses it
now (and hopefully nobody else). It may not be a bad idea to
rewrite that one script in Perl or Python.
[Footnotes]
*1* Personally I feel that the only bug in Bourne was that it
did not spell command substitution as $().
^ permalink raw reply
* Re: uncommon shell code
From: Robert Watson @ 2005-09-23 8:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0gclpyo.fsf@assigned-by-dhcp.cox.net>
On 9/22/05, Junio C Hamano <junkio@cox.net> wrote:
> Robert Watson <robert.oo.watson@gmail.com> writes:
>
> > I found the following shell code in git-tag.sh (and others):
>
> My fault; see point 2. in this article:
>
> http://marc.theaimsgroup.com/?l=git&m=112386506308820&w=2
>
> Please either get used to it or wait until I decide to modernize
> the scripts wholesale, whichever comes first.
>
I see. I thought I was old fashioned by sticking to test instead of
[] (that is your point 1), but obviously I am not old enough ;)
Well, it's fine now that I know what it is. But it hurts readability,
and probably it's a good idea to simplify it. Any reasonable shell
should built-in test(1)?
Robertoo
^ permalink raw reply
* [PATCH] Fix overzealous cleanliness check in git-merge
From: Junio C Hamano @ 2005-09-23 8:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0509221500150.2553@g5.osdl.org>
Being able to try multiple strategies and automatically picking one
that seems to give less conflicting result may or may not much sense
in practice. At least that should not force normal use case to
additionally require the working tree to be fully clean. As Linus
shouted, local changes do not matter unless they interfere with the
merge.
This commit changes git-merge not to require a clean working tree.
Only when we will iterate through more than one merge strategies,
local changes are stashed away before trying the first merge, and
restored before second and later merges are attempted.
The index file must be in sync with HEAD in any case -- otherwise the
merge result would contain changes since HEAD that was done locally
and registered in the index. This check is already enforced by
three-way read-tree existing merge strategies use, but is done here as
a safeguard as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Taking hint from your message, here is an attempt to fix the
'incredibly broken' git-merge. This does not make git-pull
use it yet.
git-merge.sh | 65 ++++++++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 49 insertions(+), 16 deletions(-)
abfefa19cf56a312d571ea36a491152ac7aef657
diff --git a/git-merge.sh b/git-merge.sh
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -18,8 +18,19 @@ all_strategies='recursive octopus resolv
default_strategies='resolve octopus'
use_strategies=
-dropheads() {
- rm -f -- "$GIT_DIR/MERGE_HEAD" || exit 1
+dropsave() {
+ rm -f -- "$GIT_DIR/MERGE_HEAD" \
+ "$GIT_DIR/MERGE_SAVE" || exit 1
+}
+
+savestate() {
+ git diff -r -z --name-only $head | cpio -0 -o >"$GIR_DIR/MERGE_SAVE"
+}
+
+restorestate() {
+ git reset --hard $head
+ cpio -iuv <"$GIT_DIR/MERGE_SAVE"
+ git-update-index --refresh >/dev/null
}
summary() {
@@ -92,7 +103,7 @@ case "$#,$common" in
# 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. Yeeah!"
- dropheads
+ dropsave
exit 0
;;
1,"$head")
@@ -102,7 +113,7 @@ case "$#,$common" in
git-read-tree -u -m $head "$1" || exit 1
git-rev-parse --verify "$1^0" > "$GIT_DIR/HEAD"
summary "$1"
- dropheads
+ dropsave
exit 0
;;
1,*)
@@ -124,29 +135,51 @@ case "$#,$common" in
if test "$up_to_date" = t
then
echo "Already up-to-date. Yeeah!"
- dropheads
+ dropsave
exit 0
fi
;;
esac
-# At this point we need a real merge. Require that the tree matches
-# exactly our head.
-git-update-index --refresh &&
-test '' = "`git-diff-index --cached --name-only $head`" || {
- die "Need real merge but the working tree has local changes."
-}
+# At this point, we need a real merge. No matter what strategy
+# we use, it would operate on the index, possibly affecting the
+# working tree, and when resolved cleanly, have the desired tree
+# in the index -- this means that the index must be in sync with
+# the $head commit.
+files=$(git-diff-index --cached --name-only $head) || exit
+if [ "$files" ]; then
+ echo >&2 "Dirty index: cannot merge (dirty: $files)"
+ exit 1
+fi
+
+case "$use_strategies" in
+?*' '?*)
+ # Stash away the local changes so that we can try more than one.
+ savestate
+ single_strategy=no
+ ;;
+*)
+ single_strategy=yes
+ ;;
+esac
result_tree= best_cnt=-1 best_strategy= wt_strategy=
for strategy in $use_strategies
do
test "$wt_strategy" = '' || {
echo "Rewinding the tree to pristine..."
- git reset --hard $head
+ restorestate
}
- echo "Trying merge strategy $strategy..."
+ case "$single_strategy" in
+ no)
+ echo "Trying merge strategy $strategy..."
+ ;;
+ esac
+
+ # Remember which strategy left the state in the working tree
wt_strategy=$strategy
+
git-merge-$strategy $common -- $head "$@" || {
# The backend exits with 1 when conflicts are left to be resolved,
@@ -185,14 +218,14 @@ then
echo "Committed merge $result_commit, made by $wt_strategy."
echo $result_commit >"$GIT_DIR/HEAD"
summary $result_commit
- dropheads
+ dropsave
exit 0
fi
# Pick the result from the best strategy and have the user fix it up.
case "$best_strategy" in
'')
- git reset --hard $head
+ restorestate
die "No merge strategy handled the merge."
;;
"$wt_strategy")
@@ -200,7 +233,7 @@ case "$best_strategy" in
;;
*)
echo "Rewinding the tree to pristine..."
- git reset --hard $head
+ restorestate
echo "Using the $best_strategy to prepare resolving by hand."
git-merge-$best_strategy $common -- $head "$@"
;;
^ permalink raw reply
* Re: uncommon shell code
From: Junio C Hamano @ 2005-09-23 9:00 UTC (permalink / raw)
To: Robert Watson; +Cc: git
In-Reply-To: <72499e3b05092301322a145e52@mail.gmail.com>
Robert Watson <robert.oo.watson@gmail.com> writes:
> Well, it's fine now that I know what it is. But it hurts
> readability, and probably it's a good idea to simplify it.
I try to stay away from style discussion, but readability is
always relative and personal. Things like 'while case $# in
..." is an idiom for some but not for others -- and I am
included in the former group of people (unfortunately). In any
case, 'while test $# != 0' is not too much of a simplification
anyway.
> Any reasonable shell should built-in test(1)?
Correct. The idiom comes from performance issues -- lack of
built in test long ago -- and that issue is not relevant
anymore. But the pattern being an idiom for some still is.
Having said that, I do not feel too strong about enforcing _my_
style. I _do_ feel somewhat strong about consistency, so if
somebody wants to update them, without dropping the ball in the
middle, it is very likely that I can be persuaded to take a
series of patches to modernize them.
^ permalink raw reply
* [PATCH] Use git-merge in git-pull (second try).
From: Junio C Hamano @ 2005-09-23 9:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0509221500150.2553@g5.osdl.org>
This again makes git-pull to use git-merge, so that different merge
strategy can be specified from the command line. Without explicit
strategy parameter, it defaults to git-merge-resolve if only one
remote is pulled, and git-merge-octopus otherwise, to keep the
default behaviour of the command the same as the original.
Also this brings another usability measure: -n flag from the command
line, if given, is passed to git-merge to prevent it from running the
diffstat at the end of the merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
I tested this at least once with a dirty working tree ;-). The
main difference from the one that was backed out is that only
one strategy is used by default -- this is to avoid any
'stashing away old states' done on the git-merge side.
git-pull.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 44 insertions(+), 4 deletions(-)
9c078a16523a2aae224a99e70f41eeb3d05a470c
diff --git a/git-pull.sh b/git-pull.sh
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -6,6 +6,38 @@
. git-sh-setup || die "Not a git archive"
+usage () {
+ die "git pull [-n] [-s strategy]... <repo> <head>..."
+}
+
+strategy_args= no_summary=
+while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
+do
+ case "$1" in
+ -n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
+ --no-summa|--no-summar|--no-summary)
+ no_summary=-n ;;
+ -s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
+ --strateg=*|--strategy=*|\
+ -s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
+ case "$#,$1" in
+ *,*=*)
+ strategy=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ strategy="$2"
+ shift ;;
+ esac
+ strategy_args="${strategy_args}-s $strategy "
+ ;;
+ -*)
+ usage
+ ;;
+ esac
+ shift
+done
+
orig_head=$(cat "$GIT_DIR/HEAD") || die "Pulling into a black hole?"
git-fetch --update-head-ok "$@" || exit 1
@@ -31,11 +63,19 @@ case "$merge_head" in
echo >&2 "No changes."
exit 0
;;
-*' '?*)
- echo >&2 "Pulling more than one heads; making an Octopus."
- exec git-octopus
+?*' '?*)
+ strategy_default_args='-s octopus'
+ ;;
+*)
+ strategy_default_args='-s resolve'
+ ;;
+esac
+
+case "$strategy_args" in
+'')
+ strategy_args=$strategy_default_args
;;
esac
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
-git-resolve "$(cat "$GIT_DIR"/HEAD)" $merge_head "$merge_name"
+git-merge $no_summary $strategy_args "$merge_name" HEAD $merge_head
^ permalink raw reply
* Re: /bin/sh portability question
From: Sean @ 2005-09-23 9:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Eriksen, git
In-Reply-To: <7vzmq4faz6.fsf@assigned-by-dhcp.cox.net>
On Fri, September 23, 2005 4:24 am, Junio C Hamano said:
> I haven't assessed the extent of damage if we tried to use ``
> for portability lately (I did once, and it did not look too bad
> back then). If somebody comes up with a readable patch, I might
> be persuaded to take it [*1*].
Junio,
It sounds like changing the sha-bang line to "#!/bin/bash" would fix the
problem on Solaris. As an aside, it would improve vi syntax highlighting
as well. Does any target system lack bash?
If not, would you accept a patch that first converted the shell scripts to
#!/bin/bash and then added a "make install" option that allowed them to be
replaced? Something like "make install S=/bin/ash" for instance?
Sean
^ permalink raw reply
* Re: /bin/sh portability question
From: Junio C Hamano @ 2005-09-23 9:07 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git, Patrick Mauritz
In-Reply-To: <20050923075058.GA25473@bohr.gbar.dtu.dk>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> It seems things are progressing nicely with regard to
> Solaris portability.
Good to have a Solaris user. I have one patch that I've been
keeping in the proposed updates branch, waiting for a
comfirmation or 'not-good-enough-for-me' answer from people that
have cURL installed in nonstandard places.
------------
Subject: [PATCH] CURLDIR in Makefile
From: Patrick Mauritz <oxygene@studentenbude.ath.cx>
Date: 1127139079 +0200
Support systems that do not install curl headers and libraries
in /usr/{include,lib}.
Signed-off-by: Patrick Mauritz <oxygene@studentenbude.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
a5ebfc164f8380eb4c1c2ff92082687c3cb0b39d
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -9,6 +9,9 @@
# Define NO_CURL if you do not have curl installed. git-http-pull is not
# built, and you cannot use http:// and https:// transports.
#
+# Define CURLDIR=/foo/bar if your curl header and library files are in
+# /foo/bar/include and /foo/bar/lib directories.
+#
# Define NO_STRCASESTR if you don't have strcasestr.
#
# Define PPC_SHA1 environment variable when running make to make use of
@@ -131,6 +134,13 @@ ifdef WITH_SEND_EMAIL
endif
ifndef NO_CURL
+ ifdef CURLDIR
+ # This is still problematic -- gcc does not want -R.
+ CFLAGS += -I$(CURLDIR)/include
+ CURL_LIBCURL = -L$(CURLDIR)/lib -R$(CURLDIR)/lib -lcurl
+ else
+ CURL_LIBCURL = -lcurl
+ endif
PROGRAMS += git-http-fetch
endif
@@ -285,7 +295,7 @@ git-ssh-upload: rsh.o
git-ssh-pull: rsh.o fetch.o
git-ssh-push: rsh.o
-git-http-fetch: LIBS += -lcurl
+git-http-fetch: LIBS += $(CURL_LIBCURL)
git-rev-list: LIBS += $(OPENSSL_LIBSSL)
init-db.o: init-db.c
^ permalink raw reply
* Re: Please undo "Use git-merge instead of git-resolve in
From: Petr Baudis @ 2005-09-23 9:10 UTC (permalink / raw)
To: Sean; +Cc: Jon Loeliger, git
In-Reply-To: <34462.10.10.10.28.1127417134.squirrel@linux1>
Dear diary, on Thu, Sep 22, 2005 at 09:25:34PM CEST, I got a letter
where Sean <seanlkml@sympatico.ca> told me that...
> On Thu, September 22, 2005 3:10 pm, Petr Baudis said:
>
> > FWIW, with Cogito, interrupted or failed fetch can be safely rerun, no
> > extra recovery procedure is required. It *seems* that this holds for
> > git-fetch as well.
>
> Petr,
>
> Why doesn't cogito just use the git fetch/pull commands? Why does it
> need anything special? It seems like cogito is doing more than just
> being an ease-of-use layer above git.
As Junio already explained, Cogito had those commands earlier - so the
main reason was simply that I didn't manage to do it yet. It is not so
easy to keep up with the latest GIT stuff _and_ enhance Cogito at the
same time, so I simply didn't get to really consider that yet. :-)
That said, this is a non-comprehensive list of the factors in my
consideration:
Pros (not so much of them, but they are big):
* Already supports alternates and remotes
* Do it once, stop caring :-) - only single instance of the code
does the stuff (this is obviously the motivation)
Cons:
* cg-fetch can do with symlinked object database
* cg-fetch will hardlink if possible when fetching locally
* cg-fetch will fetch the tags if possible
(this is actually a bit controversial - we should have
the private/public tags distinction, that's another
thing I simply didn't get to yet)
* cg-fetch has cute progress info
(perhaps git-fetch output could be just fed to that)
* cg-fetch won't do useless fetches when we are already
up-to-date
* I'm not sure if I could call git-fetch to do the initial
fetch during clone
* The amount of work to initially convert it might be comparable
with implementing the current new stuff
* I really dislike the git-fetch coding style
This is not that I'd like to force my coding style
customs on anyone and Junio might well feel the same
about Cogito's code, but I would have to support and
fix bugs in git-fetch if I used it.
* I'm obviously not too happy to throw away the rather big
amount of code I spent a lot of time on and which is already
pretty well debugged and tuned, I think (that's not to say
that git-fetch is buggy... ;-)
The cons may seem mostly minor stuff which is quite fixable, and that's
right, it's just show that there is plenty of stuff to do before
git-fetch will be superset of cg-fetch. Now because of the coding style,
I might as well just implement the alternates and remotes stuff to
cg-fetch, which would be less work and less painful for me in the short
term.
I'll convert cg-object-id to use git-rev-parse after the release so that
you can't say I'm an old-fashioned freak refusing to use any of the new
GIT stuff. :^)
--
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
* StGIT site down
From: Catalin Marinas @ 2005-09-23 9:16 UTC (permalink / raw)
To: git
The www.procode.org/stgit page is (freely) hosted somewhere in Florida
and, because of the latest hurricanes, it's been down probably for
more than a couple of weeks. I don't know when it will be up again.
The archives and the GIT repository are hosted in the UK and still
available. For releases and snapshots:
http://homepage.ntlworld.com/cmarinas/stgit/
For cloning it:
git clone http://homepage.ntlworld.com/cmarinas/stgit.git
In the meantime, I will think about moving it to public source hosting
site (like sf.net or similar).
--
Catalin
^ permalink raw reply
* Re: /bin/sh portability question
From: Junio C Hamano @ 2005-09-23 9:19 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP05141C92C0F083A17B2EEFAE960@CEZ.ICE>
"Sean" <seanlkml@sympatico.ca> writes:
> If not, would you accept a patch that first converted the shell scripts to
> #!/bin/bash and then added a "make install" option that allowed them to be
> replaced? Something like "make install S=/bin/ash" for instance?
$ make SHELL_PATH=/bin/bash
Perhaps?
^ permalink raw reply
* Re: StGIT site down
From: Petr Baudis @ 2005-09-23 9:31 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnxy85oywhx.fsf@arm.com>
Dear diary, on Fri, Sep 23, 2005 at 11:16:42AM CEST, I got a letter
where Catalin Marinas <catalin.marinas@arm.com> told me that...
> The www.procode.org/stgit page is (freely) hosted somewhere in Florida
> and, because of the latest hurricanes, it's been down probably for
> more than a couple of weeks. I don't know when it will be up again.
>
> The archives and the GIT repository are hosted in the UK and still
> available. For releases and snapshots:
>
> http://homepage.ntlworld.com/cmarinas/stgit/
>
> For cloning it:
>
> git clone http://homepage.ntlworld.com/cmarinas/stgit.git
>
> In the meantime, I will think about moving it to public source hosting
> site (like sf.net or similar).
This is very unfortunate because the tutorial is now unavailable, and
for some reason it is not available in the StGIT distribution either.
Could you please bundle it?
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
* Re: Please undo "Use git-merge instead of git-resolve in
From: Junio C Hamano @ 2005-09-23 9:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050923091012.GA10255@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> * cg-fetch can do with symlinked object database
Do you mean ".git/object" in the repository you are fetching
into is a symlink to somewhere, or something else?
> * cg-fetch will hardlink if possible when fetching locally
True, git-fetch and git-clone try to use pack protocols by
default, which is debatable. Adding -l (similar to what
git-clone does) would not be too hard, if enough people want
it.
> * cg-fetch won't do useless fetches when we are already
> up-to-date
Care to explain? Perhaps you are talking about rsync transport
(in which case I would not be surprised)?
> * I'm not sure if I could call git-fetch to do the initial
> fetch during clone
$ git-init-db && git fetch http://kernel.org/pub/scm/git/git.git
should work.
There is another minor "con", if you include git-clone in the
discussion. Over http transport, it refuses to run against a
remote repository that does not have info/refs and info/packs,
even if it is not packed. I think cg-clone uses recursive wget
for directory traversal and does not have to use them.
^ 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