* [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Johannes Schindelin @ 2007-11-28 13:57 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Junio C Hamano, Johannes Sixt, Benoit Sigoure, Git Mailing List
In-Reply-To: <1570EAD5-9F47-4105-B3DA-49CA6FA57369@wincent.com>
It might be POSIX, but there are shells that do not like the
expression 'export VAR=VAL'. To be on the safe side, rewrite them
into 'VAR=VAL' and 'export VAR'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 28 Nov 2007, Wincent Colaiuta wrote:
> I'm still a little concerned that nobody commented when I
> pointed out that export VAR=VAL is used elsewhere in Git,
> especially in git-clone.sh, which is very commonly-used
> porcelain. Is it a problem?
How's that for a comment?
git-clone.sh | 2 +-
git-filter-branch.sh | 20 ++++++++++++--------
git-quiltimport.sh | 10 ++++++----
3 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 24ad179..ecf9d89 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -229,7 +229,7 @@ cleanup() {
trap cleanup 0
mkdir -p "$dir" && D=$(cd "$dir" && pwd) || usage
test -n "$GIT_WORK_TREE" && mkdir -p "$GIT_WORK_TREE" &&
-W=$(cd "$GIT_WORK_TREE" && pwd) && export GIT_WORK_TREE="$W"
+W=$(cd "$GIT_WORK_TREE" && pwd) && GIT_WORK_TREE="$W" && export GIT_WORK_TREE
if test yes = "$bare" || test -n "$GIT_WORK_TREE"; then
GIT_DIR="$D"
else
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 19cab5a..3afc945 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -66,17 +66,17 @@ set_ident () {
h
s/^'$lid' \([^<]*\) <[^>]*> .*$/\1/
s/'\''/'\''\'\'\''/g
- s/.*/export GIT_'$uid'_NAME='\''&'\''/p
+ s/.*/GIT_'$uid'_NAME='\''&'\''\nexport GIT_'$uid'_NAME/p
g
s/^'$lid' [^<]* <\([^>]*\)> .*$/\1/
s/'\''/'\''\'\'\''/g
- s/.*/export GIT_'$uid'_EMAIL='\''&'\''/p
+ s/.*/GIT_'$uid'_EMAIL='\''&'\''\nexport GIT_'$uid'_EMAIL/p
g
s/^'$lid' [^<]* <[^>]*> \(.*\)$/\1/
s/'\''/'\''\'\'\''/g
- s/.*/export GIT_'$uid'_DATE='\''&'\''/p
+ s/.*/GIT_'$uid'_DATE='\''&'\''\nexport GIT_'$uid'_DATE/p
q
}
@@ -84,7 +84,7 @@ set_ident () {
LANG=C LC_ALL=C sed -ne "$pick_id_script"
# Ensure non-empty id name.
- echo "[ -n \"\$GIT_${uid}_NAME\" ] || export GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\""
+ echo "case \"\$GIT_${uid}_NAME\" in \"\") GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\" && export GIT_${uid}_NAME;; esac"
}
USAGE="[--env-filter <command>] [--tree-filter <command>] \
@@ -206,7 +206,8 @@ done < "$tempdir"/backup-refs
ORIG_GIT_DIR="$GIT_DIR"
ORIG_GIT_WORK_TREE="$GIT_WORK_TREE"
ORIG_GIT_INDEX_FILE="$GIT_INDEX_FILE"
-export GIT_DIR GIT_WORK_TREE=.
+GIT_WORK_TREE=.
+export GIT_DIR GIT_WORK_TREE
# These refs should be updated if their heads were rewritten
@@ -231,7 +232,8 @@ done > "$tempdir"/heads
test -s "$tempdir"/heads ||
die "Which ref do you want to rewrite?"
-export GIT_INDEX_FILE="$(pwd)/../index"
+GIT_INDEX_FILE="$(pwd)/../index"
+export GIT_INDEX_FILE
git read-tree || die "Could not seed the index"
ret=0
@@ -267,7 +269,8 @@ while read commit parents; do
git read-tree -i -m $commit:"$filter_subdir"
esac || die "Could not initialize the index"
- export GIT_COMMIT=$commit
+ GIT_COMMIT=$commit
+ export GIT_COMMIT
git cat-file commit "$commit" >../commit ||
die "Cannot read commit $commit"
@@ -401,7 +404,8 @@ if [ "$filter_tag_name" ]; then
[ -f "../map/$sha1" ] || continue
new_sha1="$(cat "../map/$sha1")"
- export GIT_COMMIT="$sha1"
+ GIT_COMMIT="$sha1"
+ export GIT_COMMIT
new_ref="$(echo "$ref" | eval "$filter_tag_name")" ||
die "tag name filter failed: $filter_tag_name"
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 6b0c4d2..233e5ea 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -77,8 +77,9 @@ for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
}
# Parse the author information
- export GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
- export GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
+ GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
+ GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
+ export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
while test -z "$GIT_AUTHOR_EMAIL" && test -z "$GIT_AUTHOR_NAME" ; do
if [ -n "$quilt_author" ] ; then
GIT_AUTHOR_NAME="$quilt_author_name";
@@ -104,8 +105,9 @@ for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
GIT_AUTHOR_EMAIL="$patch_author_email"
fi
done
- export GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' "$tmp_info")
- export SUBJECT=$(sed -ne 's/Subject: //p' "$tmp_info")
+ GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' "$tmp_info")
+ SUBJECT=$(sed -ne 's/Subject: //p' "$tmp_info")
+ export GIT_AUTHOR_DATE SUBJECT
if [ -z "$SUBJECT" ] ; then
SUBJECT=$(echo $patch_name | sed -e 's/.patch$//')
fi
--
1.5.3.6.2064.g4e322
^ permalink raw reply related
* Re: [PATCH v2] Teach 'git pull' about --rebase
From: Johannes Schindelin @ 2007-11-28 14:02 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <D7B369D7-B690-4F5B-852F-4EC4B03CEB45@steelskies.com>
Hi,
On Wed, 28 Nov 2007, Jonathan del Strother wrote:
> On 28 Nov 2007, at 13:11, Johannes Schindelin wrote:
>
> > When calling 'git pull' with the '--rebase' option, it performs a
> > fetch + rebase instead of a fetch + pull.
> >
> > This behavior is more desirable than fetch + pull when a topic branch
> > is ready to be submitted and needs to be update.
>
> Don't you mean fetch + merge ?
Obviously.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: David Kastrup @ 2007-11-28 14:09 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, Junio C Hamano, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711281355460.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It might be POSIX, but there are shells that do not like the
> expression 'export VAR=VAL'. To be on the safe side, rewrite them
> into 'VAR=VAL' and 'export VAR'.
This seems like activism to me: if no supported shell has a problem with
that construct, why bother?
There probably should be a list of shells we try supporting, and in
particular a list of those where we don't bother.
And if a POSIX construct is supported by all shells we try supporting, I
don't see a point in patching it away.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: StGit hooks
From: Andreas Ericsson @ 2007-11-28 14:11 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20071128132605.GB15953@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2007-11-28 14:14:15 +0100, Andreas Ericsson wrote:
>
>> Karl Hasselström wrote:
>>
>>> On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:
>>>
>>>> Karl Hasselström wrote:
>>>>
>>>>> Also, if StGit is to set up hooks automatically (commit hooks,
>>>>> pre-rebase hooks, whatever), it'd be nice to not have to worry
>>>>> about overwriting any existing hooks the user might have. But
>>>>> git currently allows only one hook script per hook, right?
>>>> Yes, but you can obviously call any number of scripts and
>>>> programs from within the hook that git executes.
>>> That doesn't help here, however, since the user and not StGit
>>> "owns" the "top-level" hook. StGit would have to rely on the user
>>> having installed a specific kind of multiplexer as a hook script
>>> (e.g. one that executes everything under .git/hooks/$hook.d/). Or
>>> it would have to install it itself, and hope that moving any
>>> existing hook to the subdirectory where the multiplexer looks for
>>> hooks doesn't break anything. Both solutions are problematic.
>> The user-defined hook can be kept in the hooks directory too. It
>> just needs to be named in such a way that git will never have a hook
>> named like that. For that reason, I think it would be easiest to
>> just agree for the git core to never call any hooks prefixed with
>> "stgit" or some such. I think the odds for it happening by chance
>> are remote, to say the least.
>
> You've lost me. :-/
>
> Take the pre-commit hook as an example. git will call
> ".git/hooks/pre-commit" when interesting stuff happens. Now StGit
> wants to install its pre-commit hook in an existing repository, and
> finds that there already is a file called ".git/hooks/pre-commit".
> What should it do?
>
Move the existing hook to ".git/hooks/stgit-moved.pre-commit". So
long as the hook doesn't care what its named (which would only matter
in the insane case where the repository has a single hook with a lot
of links going to it), this will work with relative paths that worked
earlier.
> It could move ".git/hooks/pre-commit" to
> ".git/hooks/pre-commit.d/user_hook", install its own hook in
> ".git/hooks/pre-commit.d/stgit_hook", and install a multiplexer at
> ".git/hooks/pre-commit". But that makes some assumptions, e.g. that
> the user's hook can handle being moved, and that the user is fine with
> this.
>
> I don't see a good way around this other than having git mandate the
> multiplexing scheme.
>
Multiplexing the execution of those hooks would be a very bad idea
indeed, but that's a different issue.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Nguyen Thai Ngoc Duy @ 2007-11-28 14:19 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, Junio C Hamano, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711281355460.27959@racer.site>
On Nov 28, 2007 8:57 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> It might be POSIX, but there are shells that do not like the
> expression 'export VAR=VAL'. To be on the safe side, rewrite them
> into 'VAR=VAL' and 'export VAR'.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> On Wed, 28 Nov 2007, Wincent Colaiuta wrote:
>
> > I'm still a little concerned that nobody commented when I
> > pointed out that export VAR=VAL is used elsewhere in Git,
> > especially in git-clone.sh, which is very commonly-used
> > porcelain. Is it a problem?
>
> How's that for a comment?
>
> git-clone.sh | 2 +-
> git-filter-branch.sh | 20 ++++++++++++--------
> git-quiltimport.sh | 10 ++++++----
> 3 files changed, 19 insertions(+), 13 deletions(-)
Why leave test scripts behind?
--
Duy
^ permalink raw reply
* Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Johannes Sixt @ 2007-11-28 14:21 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, Junio C Hamano, Benoit Sigoure,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711281355460.27959@racer.site>
Johannes Schindelin schrieb:
> - s/.*/export GIT_'$uid'_NAME='\''&'\''/p
> + s/.*/GIT_'$uid'_NAME='\''&'\''\nexport GIT_'$uid'_NAME/p
Recently there was a report that \n in the substitution side of s/// is not
supported by all seds :-(
> - export GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
> - export GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
> + GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
> + GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
> + export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
This even fixes a bug: ash supports export VAR=VAL, but *does* word-split
VAL if it is not quoted.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: David Kastrup @ 2007-11-28 14:24 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Johannes Schindelin, Wincent Colaiuta, Junio C Hamano,
Johannes Sixt, Benoit Sigoure, Git Mailing List
In-Reply-To: <fcaeb9bf0711280619j3479ea6csa74f4b0d907f2a65@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On Nov 28, 2007 8:57 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>> It might be POSIX, but there are shells that do not like the
>> expression 'export VAR=VAL'. To be on the safe side, rewrite them
>> into 'VAR=VAL' and 'export VAR'.
>
> Why leave test scripts behind?
Good keyword: how about starting the basic tests by testing for shell
features that are known and accepted to be used in git?
That way, we get direct feedback when feature assumptions are
problematic with some shells.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Nguyen Thai Ngoc Duy @ 2007-11-28 14:27 UTC (permalink / raw)
To: David Kastrup
Cc: Johannes Schindelin, Wincent Colaiuta, Junio C Hamano,
Johannes Sixt, Benoit Sigoure, Git Mailing List
In-Reply-To: <85lk8ia1nw.fsf@lola.goethe.zz>
On Nov 28, 2007 9:24 PM, David Kastrup <dak@gnu.org> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > On Nov 28, 2007 8:57 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >>
> >> It might be POSIX, but there are shells that do not like the
> >> expression 'export VAR=VAL'. To be on the safe side, rewrite them
> >> into 'VAR=VAL' and 'export VAR'.
> >
> > Why leave test scripts behind?
>
> Good keyword: how about starting the basic tests by testing for shell
> features that are known and accepted to be used in git?
>
> That way, we get direct feedback when feature assumptions are
> problematic with some shells.
Uh.. I meant there are "export VAL=VAL" usage in test scripts and they
should be fixed as well. Anyway your idea is nice.
--
Duy
^ permalink raw reply
* Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Johannes Schindelin @ 2007-11-28 14:27 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Wincent Colaiuta, Junio C Hamano, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <fcaeb9bf0711280619j3479ea6csa74f4b0d907f2a65@mail.gmail.com>
Hi,
On Wed, 28 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> On Nov 28, 2007 8:57 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > It might be POSIX, but there are shells that do not like the
> > expression 'export VAR=VAL'. To be on the safe side, rewrite them
> > into 'VAR=VAL' and 'export VAR'.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > On Wed, 28 Nov 2007, Wincent Colaiuta wrote:
> >
> > > I'm still a little concerned that nobody commented when I
> > > pointed out that export VAR=VAL is used elsewhere in Git,
> > > especially in git-clone.sh, which is very commonly-used
> > > porcelain. Is it a problem?
> >
> > How's that for a comment?
> >
> > git-clone.sh | 2 +-
> > git-filter-branch.sh | 20 ++++++++++++--------
> > git-quiltimport.sh | 10 ++++++----
> > 3 files changed, 19 insertions(+), 13 deletions(-)
>
> Why leave test scripts behind?
Because I did a
git grep 'export.*=' *.sh
instead of a
git grep 'export.*=' -- \*.sh
But this patch is
- good of its own, and
- a comment ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Johannes Schindelin @ 2007-11-28 14:29 UTC (permalink / raw)
To: Johannes Sixt
Cc: Wincent Colaiuta, Junio C Hamano, Benoit Sigoure,
Git Mailing List
In-Reply-To: <474D7956.8050401@viscovery.net>
Hi,
On Wed, 28 Nov 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > - s/.*/export GIT_'$uid'_NAME='\''&'\''/p
> > + s/.*/GIT_'$uid'_NAME='\''&'\''\nexport
> > GIT_'$uid'_NAME/p
>
> Recently there was a report that \n in the substitution side of s/// is not
> supported by all seds :-(
Okay, how about replacing the line with
+ s/.*/GIT_'$uid'_NAME='\''&'\''\
+export GIT_'$uid'_NAME/p
Hmm? (It works here.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Johannes Schindelin @ 2007-11-28 14:36 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Wincent Colaiuta, Junio C Hamano, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <fcaeb9bf0711280627h1ac216bbr98dc986b82a54423@mail.gmail.com>
On Wed, 28 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> > how about starting the basic tests by testing for shell features that
> > are known and accepted to be used in git?
> >
> > That way, we get direct feedback when feature assumptions are
> > problematic with some shells.
>
> Uh.. I meant there are "export VAL=VAL" usage in test scripts and they
> should be fixed as well. Anyway your idea is nice.
I have an even better idea: how about getting rid of all shell scripts,
making them builtins? ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Johannes Sixt @ 2007-11-28 14:39 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, Junio C Hamano, Benoit Sigoure,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711281428180.27959@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Wed, 28 Nov 2007, Johannes Sixt wrote:
>
>> Johannes Schindelin schrieb:
>>> - s/.*/export GIT_'$uid'_NAME='\''&'\''/p
>>> + s/.*/GIT_'$uid'_NAME='\''&'\''\nexport
>>> GIT_'$uid'_NAME/p
>> Recently there was a report that \n in the substitution side of s/// is not
>> supported by all seds :-(
>
> Okay, how about replacing the line with
>
> + s/.*/GIT_'$uid'_NAME='\''&'\''\
> +export GIT_'$uid'_NAME/p
>
> Hmm? (It works here.)
This looks good. The other case I'm refering to was also solved in this way.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: David Kastrup @ 2007-11-28 14:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Wincent Colaiuta, Junio C Hamano, Benoit Sigoure,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711281428180.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 28 Nov 2007, Johannes Sixt wrote:
>
>> Johannes Schindelin schrieb:
>> > - s/.*/export GIT_'$uid'_NAME='\''&'\''/p
>> > + s/.*/GIT_'$uid'_NAME='\''&'\''\nexport
>> > GIT_'$uid'_NAME/p
>>
>> Recently there was a report that \n in the substitution side of s/// is not
>> supported by all seds :-(
>
> Okay, how about replacing the line with
>
> + s/.*/GIT_'$uid'_NAME='\''&'\''\
> +export GIT_'$uid'_NAME/p
>
> Hmm? (It works here.)
Do we really want to replace code which is not as far as I know known to
fail under any of the supported shells with something which quite
possibly relies on particular sed implementations (and we have fewer
portability guarantees or even experience about sed than about the
shell, right?)?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Rollback of git commands
From: Nicolas Pitre @ 2007-11-28 14:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: Sean, Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711272037r2ce3ed01y31ec8531f5803efe@mail.gmail.com>
On Tue, 27 Nov 2007, Jon Smirl wrote:
> Of course you've never screwed up a repository using git commands,
> right? I've messed up plenty. A good way to mess up a repo is to get
> the data in .git/* out of sync with what is in the repo. I'm getting
> good enough with git that I can fix most mess up with a few edits, but
> it took me two years to get to that point. Rolling back to a check
> point is way easier. User error and a command failing are both equally
> valid ways to mess up a repo.
The reflog contains all your check points, for every modifications you
make, even the stupid ones. You should look at it.
Nicolas
^ permalink raw reply
* Re: StGit hooks
From: Jon Smirl @ 2007-11-28 14:53 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Karl Hasselström, Git Mailing List
In-Reply-To: <474D7710.4090303@op5.se>
I would expect 'stg init' to switch the branch to using the stgit
hooks and only those hooks. Branches that were not inited would
continue to use the user hooks. I don't have any user hooks, but this
is what I would expect to happen.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: StGit hooks
From: Andreas Ericsson @ 2007-11-28 14:58 UTC (permalink / raw)
To: Jon Smirl; +Cc: Karl Hasselström, Git Mailing List
In-Reply-To: <9e4733910711280653q119f2c2n173eaebdda6cd774@mail.gmail.com>
Jon Smirl wrote:
> I would expect 'stg init' to switch the branch to using the stgit
> hooks and only those hooks. Branches that were not inited would
> continue to use the user hooks. I don't have any user hooks, but this
> is what I would expect to happen.
>
Obviously the stgit-installed hook will have to check if the branch
the user is operating on is managed by stgit before it prevents git
rebase (or whatever it's supposed to do).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: ok for git to delete temporary packs on write error?
From: Nicolas Pitre @ 2007-11-28 15:01 UTC (permalink / raw)
To: David Tweed; +Cc: Git Mailing List
In-Reply-To: <e1dab3980711272342x7afad721m113fe21f6879a886@mail.gmail.com>
On Wed, 28 Nov 2007, David Tweed wrote:
> Hi, I'd like to check if there's any reason in the overall design of
> git which would make deleting tmp_pack's that have suffered
> write errors a bad idea? (Before I look further into this I may be missing
> a good reason why they shouldn't be auto-deleted.)
>
> My encounter with this comes from using an almost full
> usbstick which I discovered when I was poking around
> for other reasons several partial packs from occasions
> (separated by weeks) where gc failed. On each failure
> I'd removed stuff from the drive to clear space and done
> a successful gc but hadn't thought to
> check below .git for removable stuff so they'd just accumulated.
I'd suggest they get removed a part of the prune command.
Nicolas
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Jon Smirl @ 2007-11-28 15:06 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20071128093403.GB12977@diana.vm.bytemark.co.uk>
On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-11-27 18:12:49 -0500, Jon Smirl wrote:
>
> > As Jakub pointed out to me "git reset --hard $(cat
> > .git/patches/<branch>/orig-base)" would have recovered from the
> > rebase command. But I had already typed 'stg repair' which
> > compounded the mess.
>
> Unless it has a bug, the only thing "stg repair" will do is
>
> * create some new applied patches out of commits reachable from HEAD
>
> * mark some applied patches as unapplied
>
> * mark some unapplied patches as applied
I did 'stg repair' after doing 'git rebase'. After the repair half of
my patches were marked as being applied and half not. The ones that
were applied were all empty. They were probably empty because my
original patches were still commited by stg in front of the rebase. I
couldn't figure out how to recover so I extracted the pre-rebase
commits manual, built a series file and started again on a new branch.
When I applied the patches to a clean branch none of them had conflicts.
> in order to make sure that the applied patches are precisely those
> that are reachable from HEAD, and that the sequence of applied patches
> doesn't have "holes" in it (that is, commits that aren't patches).
>
> In particular, it should not ever modify your existing patches, and it
> will never move the branch head. Just resetting the branch head to
> wherever you want it to be (and then running repair again) should fix
> literally all problems.
I did this:
all pataches were applied
git rebase
stg repair -- partial repair, some patches empty, half are pushed
moved HEAD back in front of rebase
stg repair - it show all my patches as popped, but when I started
doing command it complain that some commits that stg needed were not
there.
The complaint was caused by the first repair. The first repair altered
some of the stg state to point at commits past the rebase. That why I
wanted check point. At this point I could move the HEAD back without
also reverting the stgit state in .git/*
>
> > This is way too easy to do. One simple mistype of 'git' for 'stg'
> > and you're in a mess.
>
> You're right, this is not user friendly. A pre-rebase hook sounds like
> a reasonable idea.
>
> It would also be convenient with a post-commit hook that turns new
> commits into patches automatically. And gives "git commit --amend" the
> semantics of "stg refresh".
>
> --
> Karl Hasselström, kha@treskal.com
> www.treskal.com/kalle
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Rollback of git commands
From: Jon Smirl @ 2007-11-28 15:13 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20071128092234.GA12977@diana.vm.bytemark.co.uk>
On 11/28/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-11-27 20:33:27 -0500, Jon Smirl wrote:
>
> > Let's take my recent problem as an example. I typed 'git rebase
> > linus/master' instead of 'stg rebase linus/master'. Then I typed
> > 'stg repair'. The repair failed and left me in a mess. Both of these
> > are easy to rollback except for the fact that stg has stored a bunch
> > of state in .git/*.
> >
> > After doing the commands I located my last commit before the rebase
> > and edited master back to it. But my system was still messed up
> > since moving master got me out of sync with the state stg stored in
> > .git/*. The 'stg repair' command had changed the stored state.
>
> How exactly did repair mess up? Did it crash, produce a broken result,
> an unreasonable but technically valid result, or just not the result
> you wanted?
all my patches applied
git rebase
cursing.... I immediately knew what I had done
update stg and install it
stg repair
four of my 15 patches tried to apply, I received messages that there
were all empty
most stg commands won't work, they complain that the commit references
in the stg .git/* state are not correct.
I then proceed to manually attempt repair.
>
> --
> Karl Hasselström, kha@treskal.com
> www.treskal.com/kalle
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: StGit hooks
From: Karl Hasselström @ 2007-11-28 15:40 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <474D8205.8030401@op5.se>
On 2007-11-28 15:58:13 +0100, Andreas Ericsson wrote:
> Jon Smirl wrote:
>
> > I would expect 'stg init' to switch the branch to using the stgit
> > hooks and only those hooks. Branches that were not inited would
> > continue to use the user hooks. I don't have any user hooks, but
> > this is what I would expect to happen.
>
> Obviously the stgit-installed hook will have to check if the branch
> the user is operating on is managed by stgit before it prevents git
> rebase (or whatever it's supposed to do).
Yes. The point is, hooks are per repository, not per branch. So
there's no concept of "replacing the hooks for just this one branch".
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git guidance
From: Johannes Schindelin @ 2007-11-28 15:46 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Al Boldi, git
In-Reply-To: <474D70DD.4020601@dawes.za.net>
Hi,
On Wed, 28 Nov 2007, Rogan Dawes wrote:
> Al Boldi wrote:
>
> > Willy Tarreau wrote:
> >
> > > It should not turn into an endless thread led by people who want to
> > > redefine GIT's roadmap, but experience sharing helps a lot with GIT.
> >
> > Well, now that you mentioned it, if there is one thing I dislike, it's
> > for version control to start mutilating your sources. Version Control
> > should be completely transparent. GIT isn't.
>
> Care to explain? Git is quite happy handling arbitrary binary content,
> so I find it difficult to believe that it is changing your source code
> in strange ways.
It is nice of you to ask him to explain: Unless this handwaving claim is
substantiated, it is quite hard to argue with.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Jason Sewall @ 2007-11-28 15:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0711281225150.27959@racer.site>
On Nov 28, 2007 7:32 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 28 Nov 2007, Jakub Narebski wrote:
>
> > Johannes Schindelin wrote:
> >
> > 1. What language and what toolkit should git-gui be written in?
> > (single choice)
> >
> > a. Tcl/Tk (current implementation)
> > b. C++/Qt
> > c. C/GTK+
> > d. Python (native)
> > e. Python/PyQt
> > f. Python/PyGTK
> > g. Ruby
> > h. Java/Swing
> > i. Java/SWT
> > j. XUL+JavaScript+CSS/XULRunner
> > k. other
> > l. no opinion
Since we're listing off a bunch of toolkits, I should pitch FLTK,
which is well-supported across platforms, reasonably featured, and
pretty lightweight (probably much smaller than any of the other ones
listed, in terms of dependency installs)
That said...
> Personally, I am quite comfortable with the existing implementation, and
> IMHO people dismiss contributing to git-gui too easily; Tcl is not all
> that complicated, and it is not hard at all to change/imitate existing
> code.
Agreed. I don't know much about Tcl/Tk, but I think that git-gui is
fine as-is. It's not very "pretty" compared to all of the fancy Gtk
apps the make up my system, but that's not an obstacle for me. (The
fonts are pretty bad, though)
Jason
^ permalink raw reply
* can't commit files that have been git add'ed because "fatal: you need to resolve your current index first"
From: Bill Priest @ 2007-11-28 15:48 UTC (permalink / raw)
To: git
All,
I merged from one branch to another and had lots of
conflicts. I've resolved a set of files from the
conflicts (in a directory) and did a git-add on this
set of files. I wasn't able to commit these files.
On IRC I was told that all files must be resolved
before I can commit any of them. This seems pretty
limiting. Why is a commit after a merge all or
nothing; I thought that git figured out merges and
such by the differences between files??
Bill
____________________________________________________________________________________
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ
^ permalink raw reply
* Re: ok for git to delete temporary packs on write error?
From: David Tweed @ 2007-11-28 15:48 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0711281000590.9605@xanadu.home>
On Nov 28, 2007 3:01 PM, Nicolas Pitre <nico@cam.org> wrote:
> On Wed, 28 Nov 2007, David Tweed wrote:
>
> > Hi, I'd like to check if there's any reason in the overall design of
> > git which would make deleting tmp_pack's that have suffered
> > write errors a bad idea? (Before I look further into this I may be missing
> > a good reason why they shouldn't be auto-deleted.)
[snip]
> I'd suggest they get removed a part of the prune command.
Mmm, I hadn't looked at the source and spotted the prune
is actually a separate process to the repack. From a policy
POV is it ok to assume any tmp_pack*'s existing when
prune is run can be deleted? (I know you're not supposed
to be having any other git ops going on whilst git gc works.)
Now I know they aren't being kept around for, say, "emergency
error recovery" I may look to see if I can come up with
an acceptable patch. (Don't hold your breath waiting.)
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* [PATCH] filter-branch: fix dirty way to provide the helpers to commit filters
From: Johannes Schindelin @ 2007-11-28 15:50 UTC (permalink / raw)
To: git, gitster
The helper functions 'map' and 'skip_commit' were provided to commit
filters by sourcing filter-branch itself. This was done with a certain
environment variable set to indicate that only the functions should be
defined, and the script should return then.
This was really hacky, and it did not work all that well, since the
full path to git-filter-branch was not known at all times.
Avoid that by putting the functions into a variable, and eval'ing
that variable. The commit filter gets these functions by prepending
the variable to the specified commands.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Frankly, I have no idea why this worked, but it did. However,
we had to replace the spawnvpe() function in msysGit with a
custom version (thanks Hannes!) to avoid cmd windows popping up
all over the place, and the method to source the first part of
the script back in commit filters failed.
Independently, I think that this version is nicer.
git-filter-branch.sh | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index c9f515d..19cab5a 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -8,6 +8,9 @@
# a new branch. You can specify a number of filters to modify the commits,
# files and trees.
+# The following functions will also be available in the commit filter:
+
+functions=$(cat << \EOF
warn () {
echo "$*" >&2
}
@@ -46,6 +49,10 @@ die()
echo "$*" >&2
exit 1
}
+EOF
+)
+
+eval "$functions"
# When piped a commit, output a script to set the ident of either
# "author" or "committer
@@ -80,11 +87,6 @@ set_ident () {
echo "[ -n \"\$GIT_${uid}_NAME\" ] || export GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\""
}
-# This script can be sourced by the commit filter to get the functions
-test "a$SOURCE_FUNCTIONS" = a1 && return
-this_script="$(cd "$(dirname "$0")"; pwd)"/$(basename "$0")
-export this_script
-
USAGE="[--env-filter <command>] [--tree-filter <command>] \
[--index-filter <command>] [--parent-filter <command>] \
[--msg-filter <command>] [--commit-filter <command>] \
@@ -156,7 +158,7 @@ do
filter_msg="$OPTARG"
;;
--commit-filter)
- filter_commit='SOURCE_FUNCTIONS=1 . "$this_script";'" $OPTARG"
+ filter_commit="$functions; $OPTARG"
;;
--tag-name-filter)
filter_tag_name="$OPTARG"
--
1.5.3.6.2065.gd47ac
^ permalink raw reply related
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