* Re: pre-rebase safety hook
From: Junio C Hamano @ 2008-12-04 22:29 UTC (permalink / raw)
To: Tim Harper; +Cc: Git Mailing List
In-Reply-To: <7vbpvrens3.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> If you want to prevent a branch whose tip commit is on more than one
> branches from being rebased, I think something like this would suffice.
>
> #!/bin/sh
> LF='
> '
> in_branches=$(git branch -a --with "${2-HEAD}")
> case "$in_branches" in
> *"$LF"*)
> : this commit is on more than two branches
> exit 1
> ;;
> esac
> exit 0
>
> But I didn't test it.
Actually, the above cannot possibly be right. To decide whether to allow
rebasing of a branch or not, you need to also give it from which commit
the rebase will rewrite.
For example, suppose you have a branch "topic", that was forked from
"master" and built two commits, then another branch "side" was forked from
that, and you have three more commits on "topic" since then:
o "side"
/
A---B---C---D---E "topic"
/
---o---o---o---o "master"
Now, can I allow you to rebase "topic"? It depends. These should be
allowed:
git rebase B "topic"
git rebase C "topic"
git rebase D "topic"
but rebasing "topic" on top of "master", or anything that changes the fact
that "topic" contains commits A and B, should be prohibited, because it
will interfere with "side". For example,
git rebase A "topic"
would make this history:
B---o "side"
/
A---B'--C'--D'--E' "topic"
/
---o---o---o---o "master"
where B' and B are different commits.
So you need to check all the commits that will be affected by the rebase
to see if any of them is on a branch other than the one that is being
rebased. The set of commits that needs to be checked are:
git rev-list "$1..${2-HEAD}"
so a naive implementation that is based on brnach --with would probably
look like:
#!/bin/sh
: allow rebasing a detached HEAD
git symbolic-ref -q HEAD || exit 0
LF='
'
git rev-list "$1..${2-HEAD}" |
while read commit
do
case "$(git branch -a --with $commit)" in
*"$LF"*)
: this is on two or more branches
exit 1
;;
esac
done
^ permalink raw reply
* Re: [PATCH] Allow passing of --directory to git-am.
From: Simon 'corecode' Schubert @ 2008-12-04 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhc5jeo60.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Simon 'corecode' Schubert <corecode@fs.ei.tum.de> writes:
>
>> We need to play some shell tricks to be able to pass directory names
>> which contain spaces and/or quotes.
>
> There already was an earlier attempt for this feature by Kevin Ballard,
> which had issues I pointed out:
>
> http://thread.gmane.org/gmane.comp.version-control.git/94335/focus=94456
>
> The patch was carried for a few weeks in 'pu' but was dropped due to lack
> of follow-up updates.
>
> Does your version address the issues Kevin's one had?
You mean not storing/restoring the flags across an invocation? No, that's
a different thing. My patch only adds the --directory option, it does not
fix the previously existing bug.
cheers
simon
--
<3 the future +++ RENT this banner advert +++ ASCII Ribbon /"\
rock the past +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
^ permalink raw reply
* Re: [PATCH] Allow passing of --directory to git-am.
From: Simon 'corecode' Schubert @ 2008-12-04 22:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3hc5jivjo.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Shouldn't it be
>
> + directory= pass it through git-apply
>
> to have it aligned like the rest of it?
>
> By the way, your patch looks whitespace damaged, although only context
> for the above chunk was wrapped...
Thunderbird must have pummeled it. No clue why it does that though.
Black magic software.
>> @@ -155,8 +156,9 @@ do
>> ;;
>> --resolvemsg)
>> shift; resolvemsg=$1 ;;
>> - --whitespace)
>> - git_apply_opt="$git_apply_opt $1=$2"; shift ;;
>> + --whitespace|--directory)
>> + quot=$(echo "$2" | sed -e "s/'/'\\\''/g")
>
> Why not simply use "git rev-parse --sq"?
What I need is to convert $2 into a form suitable for quoting, does git
rev-parse --sq do that?
>> + git_apply_opt="$git_apply_opt $1='$quot'"; shift ;;
>> -C|-p)
>> git_apply_opt="$git_apply_opt $1$2"; shift ;;
>> --)
>> @@ -454,7 +456,7 @@ do
>>
>> case "$resolved" in
>> '')
>> - git apply $git_apply_opt --index "$dotest/patch"
>> + eval git apply $git_apply_opt --index '"$dotest/patch"'
>
> Why eval?
I quoted the above variable, so I now need to unquote it, that's done by eval.
--
<3 the future +++ RENT this banner advert +++ ASCII Ribbon /"\
rock the past +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
^ permalink raw reply
* Re: git-gui: Warn when username and e-mail address is unconfigured?
From: Junio C Hamano @ 2008-12-04 21:34 UTC (permalink / raw)
To: Jeremy Ramer; +Cc: spearce, sverre, Peter Krefting, Git Mailing List
In-Reply-To: <b9fd99020812041254l5d1fa383m4fcc3b40f6fabacb@mail.gmail.com>
"Jeremy Ramer" <jdramer@gmail.com> writes:
> On Thu, Dec 4, 2008 at 12:04 PM, Sverre Rabbelier <alturin@gmail.com> wrote:
>> On Thu, Dec 4, 2008 at 17:05, Jeremy Ramer <jdramer@gmail.com> wrote:
>>> That's strange. I am using git 1.6.0.4 on cygwin and I get a warning
>>> message every time I start git gui. I actually find this really
>>> annoying and would like a way to turn this warning message off.
>>
>> git config --global user.name "Your Name"
>> git config --global user.email "you@example.com"
>>
>
> I have done that. I still get the warning message every time I start git gui.
I do not use Windows, and I do not run git-gui, so I am guessing only from
the source. Are you talking about the message composed by this part?
# -- Warn the user about environmental problems. Cygwin's Tcl
# does *not* pass its env array onto any processes it spawns.
# This means that git processes get none of our environment.
#
if {[is_Cygwin]} {
set ignored_env 0
set suggest_user {}
set msg [mc "Possible environment issues exist.
The following environment variables are probably
going to be ignored by any Git subprocess run
by %s:
" [appname]]
The logic to produce the error message does look somewhat screwy.
It checks a selected set of variables whose name begin with GIT_ in the
environment, and if it finds any, it gives the above message. In
addition, if GIT_{AUTHOR,COMMITTER}_{EMAIL,NAME} are among them, it also
adds this to the message:
if {$suggest_user ne {}} {
append msg [mc "
A good replacement for %s
is placing values for the user.name and
user.email settings into your personal
~/.gitconfig file.
" $suggest_user]
There are two and half issues about this code.
(1) When it prepares additional message about user.{email,name},
it does not check if the user already has them defined. IOW, there
is no way other than unsetenv before running git-gui to squelch this
part of the message.
(2) For other environment variables, such as GIT_PAGER, it does not offer
alternatives, such as core.pager. Again, there is no way other than
unsetenv to squelch the warning.
An excuse to both of the above could be that the warning is not about the
user having environment variables that can be discarded, but about
brokenness of Cygwin Tcl envirnonment that discards them. But if that is
the case, there is this other half issue:
(3) The warning does not trigger if the environment is not set when this
check is made. Now I do not know if git-gui tries to spawn
subprocesses with its own (customized) environment settings (e.g. you
would need to be able to run git-commit-tree with modified
GIT_AUTHOR_NAME if you want to use the lowlevel plumbing to create a
new commit and lie about the author identity), but if it does, the
warning does not trigger.
^ permalink raw reply
* Re: git-gui: Warn when username and e-mail address is unconfigured?
From: Alexander Gavrilov @ 2008-12-04 21:30 UTC (permalink / raw)
To: Jeremy Ramer; +Cc: sverre, Peter Krefting, Git Mailing List
In-Reply-To: <b9fd99020812041254l5d1fa383m4fcc3b40f6fabacb@mail.gmail.com>
On Thursday 04 December 2008 23:54:00 Jeremy Ramer wrote:
> On Thu, Dec 4, 2008 at 12:04 PM, Sverre Rabbelier <alturin@gmail.com> wrote:
> > On Thu, Dec 4, 2008 at 17:05, Jeremy Ramer <jdramer@gmail.com> wrote:
> >> That's strange. I am using git 1.6.0.4 on cygwin and I get a warning
> >> message every time I start git gui. I actually find this really
> >> annoying and would like a way to turn this warning message off.
> >
> > git config --global user.name "Your Name"
> > git config --global user.email "you@example.com"
> >
>
> I have done that. I still get the warning message every time I start git gui.
> --
What does it say precisely? I.e. is it perhaps the warning about subprocesses
possibly ignoring the value of environment variables?
Alexander
^ permalink raw reply
* Re: gittorrent on /.
From: J.H. @ 2008-12-04 21:19 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0812041313270.7145@asgard.lang.hm>
*sighs* the slashdot commentators make me sad! Bonus points to whoever
got the comments up about "MirrorSync" up on the GitTorrent page.
- John 'Warthog9' Hawley
On Thu, 2008-12-04 at 13:15 -0800, david@lang.hm wrote:
> lots of misinformation in here (including the implication that gittorrent
> is ready, or nearly ready to use).
>
> David Lang
>
> http://tech.slashdot.org/tech/08/12/04/1625226.shtml
>
> Political and Technical Implications of GitTorrent
> Posted by CmdrTaco on Thursday December 04, @01:03PM
> from the distribute-this-sucka dept.
> Programming Media
> lkcl writes "The GitTorrent Protocol (GTP) is a protocol for collaborative
> git repository distribution across the Internet. Git promises to be a
> distributed software management tool, where a repository can be
> distributed. Yet, the mechanisms used to date to actually 'distribute,'
> such as ssh, are very much still centralized. GitTorrent makes Git truly
> distributed. The initial plans are for reducing mirror loading, however
> the full plans include totally distributed development: no central mirrors
> whatsoever. PGP signing (an existing feature of git) and other
> web-of-trust-based mechanisms will take over from protocols on ports (e.g.
> ssh) as the access control 'clearing house.' The implications of a truly
> distributed revision control system are truly staggering: unrestricted
> software freedom. The playing field is leveled in so many ways, as 'The
> Web Site' no longer becomes the central choke-point of control. Coming
> just in time for that all-encompassing Free Software revolution hinted at
> by The Rebellion Against Vista, this article will explain more fully some
> of the implications that make this quiet and technically brilliant
> project, GitTorrent, so important to Software Freedom, from both technical
> and political perspectives."
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git-gui: Warn when username and e-mail address is unconfigured?
From: Jeremy Ramer @ 2008-12-04 20:54 UTC (permalink / raw)
To: sverre; +Cc: Peter Krefting, Git Mailing List
In-Reply-To: <bd6139dc0812041104s26ae149foeafa489e65aeb584@mail.gmail.com>
On Thu, Dec 4, 2008 at 12:04 PM, Sverre Rabbelier <alturin@gmail.com> wrote:
> On Thu, Dec 4, 2008 at 17:05, Jeremy Ramer <jdramer@gmail.com> wrote:
>> That's strange. I am using git 1.6.0.4 on cygwin and I get a warning
>> message every time I start git gui. I actually find this really
>> annoying and would like a way to turn this warning message off.
>
> git config --global user.name "Your Name"
> git config --global user.email "you@example.com"
>
I have done that. I still get the warning message every time I start git gui.
^ permalink raw reply
* Re: [PATCH 1/4] add strbuf_expand_dict_cb(), a helper for simple cases
From: Jon Loeliger @ 2008-12-04 20:30 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, Junio C Hamano
In-Reply-To: <4928912A.5050307@lsrfire.ath.cx>
On Sun, 2008-11-23 at 00:09 +0100, René Scharfe wrote:
> The new callback function strbuf_expand_dict_cb() can be used together
> with strbuf_expand() if there is only a small number of placeholders
> for static replacement texts. It expects its dictionary as an array of
> placeholder+value pairs as context parameter, terminated by an entry
> with the placeholder member set to NULL.
>
> The new helper is intended to aid converting the remaining calls of
> interpolate(). strbuf_expand() is smaller, more flexible and can be
> used to go faster than interpolate(), so it should replace the latter.
>
> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
> ---
Acked-by: Jon Loeliger <jdl@freescale.com>
jdl
^ permalink raw reply
* gittorrent on /.
From: david @ 2008-12-04 21:15 UTC (permalink / raw)
To: git
lots of misinformation in here (including the implication that gittorrent
is ready, or nearly ready to use).
David Lang
http://tech.slashdot.org/tech/08/12/04/1625226.shtml
Political and Technical Implications of GitTorrent
Posted by CmdrTaco on Thursday December 04, @01:03PM
from the distribute-this-sucka dept.
Programming Media
lkcl writes "The GitTorrent Protocol (GTP) is a protocol for collaborative
git repository distribution across the Internet. Git promises to be a
distributed software management tool, where a repository can be
distributed. Yet, the mechanisms used to date to actually 'distribute,'
such as ssh, are very much still centralized. GitTorrent makes Git truly
distributed. The initial plans are for reducing mirror loading, however
the full plans include totally distributed development: no central mirrors
whatsoever. PGP signing (an existing feature of git) and other
web-of-trust-based mechanisms will take over from protocols on ports (e.g.
ssh) as the access control 'clearing house.' The implications of a truly
distributed revision control system are truly staggering: unrestricted
software freedom. The playing field is leveled in so many ways, as 'The
Web Site' no longer becomes the central choke-point of control. Coming
just in time for that all-encompassing Free Software revolution hinted at
by The Rebellion Against Vista, this article will explain more fully some
of the implications that make this quiet and technically brilliant
project, GitTorrent, so important to Software Freedom, from both technical
and political perspectives."
^ permalink raw reply
* Re: "git help stage" doesn't display git-stage man page
From: Junio C Hamano @ 2008-12-04 19:37 UTC (permalink / raw)
To: Jeff King; +Cc: Teemu Likonen, git, Scott Chacon
In-Reply-To: <20081204034203.GA12835@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Dec 03, 2008 at 12:34:22AM -0800, Junio C Hamano wrote:
>
>> diff --git a/Makefile b/Makefile
>> index 9577d6f..5158197 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -320,6 +320,7 @@ BUILT_INS += git-merge-subtree$X
>> BUILT_INS += git-peek-remote$X
>> BUILT_INS += git-repo-config$X
>> BUILT_INS += git-show$X
>> +BUILT_INS += git-stage$X
>> BUILT_INS += git-status$X
>> BUILT_INS += git-whatchanged$X
>
> We need this, too, then.
Good catch, thanks.
^ permalink raw reply
* Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category
From: Junio C Hamano @ 2008-12-04 19:37 UTC (permalink / raw)
To: Sébastien Cevey
Cc: git, Jakub Narebski, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <87hc5k22dr.wl%seb@cine7.net>
Thanks, will queue so that they won't get lost in the noise.
^ permalink raw reply
* Re: pre-rebase safety hook
From: Junio C Hamano @ 2008-12-04 19:35 UTC (permalink / raw)
To: Tim Harper; +Cc: Git Mailing List
In-Reply-To: <e1a5e9a00812040958u3af4c69ofba66567baacb79c@mail.gmail.com>
"Tim Harper" <timcharper@gmail.com> writes:
> Is anyone aware of a pre-rebase hook script that will prevent (or at
> least warn) you from letting a rebase rewrite a commit that has been
> pushed or merged into any branch except it's own?
>
> I've activated the pre-rebase.sample, and it does seem to give me any
> warnings at all:
>
> Here's the terminal output demonstrating what I mean:
>
> http://pastie.org/331082
The example script starts like this:
#!/bin/sh
# ...
# This sample shows how to prevent topic branches that are already
# merged to 'next' branch from getting rebased, because allowing it
# would result in rebasing already published history.
As it says, it explicitly checks against 'next'.
The sample was written way before "branch --with" feature was added, and I
suspect what it does can be expressed more concisely in modern git.
If you want to prevent a branch whose tip commit is on more than one
branches from being rebased, I think something like this would suffice.
#!/bin/sh
LF='
'
in_branches=$(git branch -a --with "${2-HEAD}")
case "$in_branches" in
*"$LF"*)
: this commit is on more than two branches
exit 1
;;
esac
exit 0
But I didn't test it.
^ permalink raw reply
* Re: [PATCH] Allow passing of --directory to git-am.
From: Jakub Narebski @ 2008-12-04 19:35 UTC (permalink / raw)
To: Simon 'corecode' Schubert; +Cc: git
In-Reply-To: <49382612.3010207@fs.ei.tum.de>
Simon 'corecode' Schubert <corecode@fs.ei.tum.de> writes:
> We need to play some shell tricks to be able to pass directory names
> which contain spaces and/or quotes.
>
> Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
> ---
>
> Boyd Stephen Smith Jr. wrote:
> > I'm thinking your sed line doesn't do what you think it does.
> > You probably want something like:
> > bss@monster:~$ echo "don't" | sed -e "s/'/'\\\\''/g"
> > don'\''t
>
> Thanks, I clearly did not test this well enough.
>
> git-am.sh | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/git-am.sh b/git-am.sh
> index aa60261..3baff4e 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit message
> u,utf8 recode into utf8 (default)
> k,keep pass -k flag to git-mailinfo
> whitespace= pass it through git-apply
> +directory= pass it through git-apply
Shouldn't it be
+ directory= pass it through git-apply
to have it aligned like the rest of it?
By the way, your patch looks whitespace damaged, although only context
for the above chunk was wrapped...
> C= pass it through git-apply
> p= pass it through git-apply
> resolvemsg= override error message when patch failure occurs
> @@ -155,8 +156,9 @@ do
> ;;
> --resolvemsg)
> shift; resolvemsg=$1 ;;
> - --whitespace)
> - git_apply_opt="$git_apply_opt $1=$2"; shift ;;
> + --whitespace|--directory)
> + quot=$(echo "$2" | sed -e "s/'/'\\\''/g")
Why not simply use "git rev-parse --sq"?
> + git_apply_opt="$git_apply_opt $1='$quot'"; shift ;;
> -C|-p)
> git_apply_opt="$git_apply_opt $1$2"; shift ;;
> --)
> @@ -454,7 +456,7 @@ do
>
> case "$resolved" in
> '')
> - git apply $git_apply_opt --index "$dotest/patch"
> + eval git apply $git_apply_opt --index '"$dotest/patch"'
Why eval?
> apply_status=$?
> ;;
> t)
> --
> 1.6.1.rc1.45.g123ed.dirty
Hmmm...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Allow passing of --directory to git-am.
From: Junio C Hamano @ 2008-12-04 19:27 UTC (permalink / raw)
To: Simon 'corecode' Schubert; +Cc: git
In-Reply-To: <49382612.3010207@fs.ei.tum.de>
Simon 'corecode' Schubert <corecode@fs.ei.tum.de> writes:
> We need to play some shell tricks to be able to pass directory names
> which contain spaces and/or quotes.
There already was an earlier attempt for this feature by Kevin Ballard,
which had issues I pointed out:
http://thread.gmane.org/gmane.comp.version-control.git/94335/focus=94456
The patch was carried for a few weeks in 'pu' but was dropped due to lack
of follow-up updates.
Does your version address the issues Kevin's one had?
^ permalink raw reply
* Re: [PATCH] git-svn: Make branch use correct svn-remote
From: Eric Wong @ 2008-12-04 19:26 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List, Junio C Hamano, Deskin Miller
In-Reply-To: <49365259.5090803@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Junio C Hamano venit, vidit, dixit 03.12.2008 04:55:
> > Eric Wong <normalperson@yhbt.net> writes:
> >> Deskin Miller <deskinm@umich.edu> wrote:
>
> If I split the above copy into three lines then the test passes (svn
> 1.4.6, Deskin's patch applied onto 1.6.1-rc1 with the fix.
Thank you all for the testing and fixes.
--
Eric Wong
^ permalink raw reply
* Re: git-gui: Warn when username and e-mail address is unconfigured?
From: Sverre Rabbelier @ 2008-12-04 19:04 UTC (permalink / raw)
To: Jeremy Ramer; +Cc: Peter Krefting, Git Mailing List
In-Reply-To: <b9fd99020812040805j1143c029yf0cc4c1c4a835759@mail.gmail.com>
On Thu, Dec 4, 2008 at 17:05, Jeremy Ramer <jdramer@gmail.com> wrote:
> That's strange. I am using git 1.6.0.4 on cygwin and I get a warning
> message every time I start git gui. I actually find this really
> annoying and would like a way to turn this warning message off.
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Allow passing of --directory to git-am.
From: Jeff King @ 2008-12-04 18:51 UTC (permalink / raw)
To: Simon 'corecode' Schubert; +Cc: git
In-Reply-To: <49382612.3010207@fs.ei.tum.de>
On Thu, Dec 04, 2008 at 07:48:50PM +0100, Simon 'corecode' Schubert wrote:
> Boyd Stephen Smith Jr. wrote:
> > I'm thinking your sed line doesn't do what you think it does. You
> probably
> > want something like:
> > bss@monster:~$ echo "don't" | sed -e "s/'/'\\\\''/g"
> > don'\''t
>
> Thanks, I clearly did not test this well enough.
Maybe it would be a good idea to add a test to the test script, then?
-Peff
^ permalink raw reply
* [PATCH] Allow passing of --directory to git-am.
From: Simon 'corecode' Schubert @ 2008-12-04 18:48 UTC (permalink / raw)
To: git
We need to play some shell tricks to be able to pass directory names
which contain spaces and/or quotes.
Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
---
Boyd Stephen Smith Jr. wrote:
> I'm thinking your sed line doesn't do what you think it does. You
probably
> want something like:
> bss@monster:~$ echo "don't" | sed -e "s/'/'\\\\''/g"
> don'\''t
Thanks, I clearly did not test this well enough.
git-am.sh | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index aa60261..3baff4e 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit
message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
whitespace= pass it through git-apply
+directory= pass it through git-apply
C= pass it through git-apply
p= pass it through git-apply
resolvemsg= override error message when patch failure occurs
@@ -155,8 +156,9 @@ do
;;
--resolvemsg)
shift; resolvemsg=$1 ;;
- --whitespace)
- git_apply_opt="$git_apply_opt $1=$2"; shift ;;
+ --whitespace|--directory)
+ quot=$(echo "$2" | sed -e "s/'/'\\\''/g")
+ git_apply_opt="$git_apply_opt $1='$quot'"; shift ;;
-C|-p)
git_apply_opt="$git_apply_opt $1$2"; shift ;;
--)
@@ -454,7 +456,7 @@ do
case "$resolved" in
'')
- git apply $git_apply_opt --index "$dotest/patch"
+ eval git apply $git_apply_opt --index '"$dotest/patch"'
apply_status=$?
;;
t)
--
1.6.1.rc1.45.g123ed.dirty
^ permalink raw reply related
* Re: [PATCH] Allow passing of --directory to git-am.
From: Boyd Stephen Smith Jr. @ 2008-12-04 18:28 UTC (permalink / raw)
To: git; +Cc: Simon 'corecode' Schubert
In-Reply-To: <49380D84.5050403@fs.ei.tum.de>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
On Thursday 04 December 2008, Simon 'corecode' Schubert
<corecode@fs.ei.tum.de> wrote about '[PATCH] Allow passing of --directory
to git-am.':
>- --whitespace)
>- git_apply_opt="$git_apply_opt $1=$2"; shift ;;
>+ --whitespace|--directory)
>+ quot=$(echo "$2" | sed -e "s/'/\\'/g")
>+ git_apply_opt="$git_apply_opt $1='$quot'"; shift ;;
Test:
bss@monster:~$ echo "don't" | sed -e "s/'/\\'/g"
don't
bss@monster:~$
I'm thinking your sed line doesn't do what you think it does. You probably
want something like:
bss@monster:~$ echo "don't" | sed -e "s/'/'\\\\''/g"
don'\''t
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* pre-rebase safety hook
From: Tim Harper @ 2008-12-04 17:58 UTC (permalink / raw)
To: Git Mailing List
Is anyone aware of a pre-rebase hook script that will prevent (or at
least warn) you from letting a rebase rewrite a commit that has been
pushed or merged into any branch except it's own?
I've activated the pre-rebase.sample, and it does seem to give me any
warnings at all:
Here's the terminal output demonstrating what I mean:
http://pastie.org/331082
Thanks!
Tim
^ permalink raw reply
* Re: git rebase --continue with goofy error
From: Johannes Schindelin @ 2008-12-04 17:43 UTC (permalink / raw)
To: Adrian Klingel; +Cc: Michael J Gruber, git
In-Reply-To: <70AE8AF8-9353-442A-A315-047DA176B351@illumaware.com>
Hi,
On Thu, 4 Dec 2008, Adrian Klingel wrote:
> I found out why my "git rebase --continue" was failing. Do I need to
> explicitly add the .dotest directory and contents after each rebase
> failure?
You did _what_?
The directory .dotest/ contains metadata of the rebase. That you have to
add it probably means that your commits contain files in that directory.
Which is bogus.
Just another proof that we were right to move .dotest/ into .git/ (which
you will benefit from after an upgrade).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Allow passing of --directory to git-am.
From: Simon 'corecode' Schubert @ 2008-12-04 17:04 UTC (permalink / raw)
To: git
We need to play some shell tricks to be able to pass directory names
which contain spaces and/or quotes.
Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
---
git-am.sh | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index aa60261..4052d7d 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit
message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
whitespace= pass it through git-apply
+directory= pass it through git-apply
C= pass it through git-apply
p= pass it through git-apply
resolvemsg= override error message when patch failure occurs
@@ -155,8 +156,9 @@ do
;;
--resolvemsg)
shift; resolvemsg=$1 ;;
- --whitespace)
- git_apply_opt="$git_apply_opt $1=$2"; shift ;;
+ --whitespace|--directory)
+ quot=$(echo "$2" | sed -e "s/'/\\'/g")
+ git_apply_opt="$git_apply_opt $1='$quot'"; shift ;;
-C|-p)
git_apply_opt="$git_apply_opt $1$2"; shift ;;
--)
@@ -454,7 +456,7 @@ do
case "$resolved" in
'')
- git apply $git_apply_opt --index "$dotest/patch"
+ eval git apply $git_apply_opt --index '"$dotest/patch"'
apply_status=$?
;;
t)
--
1.6.1.rc1.45.g123ed.dirty
^ permalink raw reply related
* Re: git rebase --continue with goofy error
From: Adrian Klingel @ 2008-12-04 16:40 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <49380639.3010508@drmicha.warpmail.net>
Thanks alot Michael, Scott, and Bjorn. I will upgrade git.
I found out why my "git rebase --continue" was failing. Do I need to
explicitly add the .dotest directory and contents after each rebase
failure?
Adrian
On Dec 4, 2008, at 11:32 AM, Michael J Gruber wrote:
> Adrian Klingel venit, vidit, dixit 04.12.2008 15:55:
>> I am trying so, so hard to rebase a branch with updates made in
>> master:
>>
>> *********
>> git rebase master
>> *********
>>
>> I get about 20 conflicts back, which I fix and do:
>>
>> *********
>> git add *
>> *********
>>
>> There were also many, many error messages after the rebase
>> command, eg:
>>
>> *********
>> error: test/unit/missing_year_test.rb: already exists in index
>> error: test/unit/axle_test.rb: already exists in index
>> error: test/unit/body_style_test.rb: already exists in index
>> error: test/unit/brake_test.rb: already exists in index
>> error: test/unit/category_test.rb: already exists in index
>> error: test/unit/comment_test.rb: already exists in index
>> error: test/unit/company_comment_test.rb: does not exist in index
>> error: test/unit/country_test.rb: already exists in index
>> *********
>>
>>
>> but I ignore that error, because I have no idea what it means. If I
>
> Not a good general approach. If there are errors to begin with
> there is
> no reason to expect success later on.
>
> Here, I assume you are starting from a dirty working tree. What did
> git
> status say before the rebase?
>
>> were to guess, I'd say it's trying to copy files from master to my
>> current branch. Of course.
>>
>> So now I have added my conflict fixes, per the message:
>>
>> *********
>> Failed to merge in the changes.
>> Patch failed at 0002.
>>
>> When you have resolved this problem run "git rebase --continue".
>> If you would prefer to skip this patch, instead run "git rebase --
>> skip".
>> To restore the original branch and stop rebasing run "git rebase --
>> abort".
>> *********
>
> What command triggered that message? It's certainly not saying that
> you
> have added your conflict fixes, as you seem to think.
>
>>
>> So I decide to continue:
>>
>> *********
>> git rebase --continue
>> *********
>>
>>
>> And I get the following:
>>
>> *********
>> mymac:/Library/mydir/code/myapp me$ git rebase --continue
>> Unknown option: 1
>> Usage: head [-options] <url>...
>> -m <method> use method for the request (default is 'HEAD')
>> -f make request even if head believes method is
>> illegal
>> -b <base> Use the specified URL as base
>> -t <timeout> Set timeout value
>> -i <time> Set the If-Modified-Since header on the request
>> -c <conttype> use this content-type for POST, PUT, CHECKIN
>> -a Use text mode for content I/O
>> -p <proxyurl> use this as a proxy
>> -P don't load proxy settings from environment
>> -H <header> send this HTTP header (you can specify several)
>>
>> -u Display method and URL before any response
>> -U Display request headers (implies -u)
>> -s Display response status code
>> -S Display response status chain
>> -e Display response headers
>> -d Do not display content
>> -o <format> Process HTML content in various ways
>>
>> -v Show program version
>> -h Print this message
>>
>> -x Extra debugging output
>> Applying
>> You still have unmerged paths in your index
>> did you forget to use 'git add'?
>>
>> When you have resolved this problem run "git rebase --continue".
>> If you would prefer to skip this patch, instead run "git rebase --
>> skip".
>> To restore the original branch and stop rebasing run "git rebase --
>> abort".
>>
>> *********
>>
>>
>> A google search of "git" and "Unknown option: 1" yields zero
>> results.
>
> As the "Usage: head..." tells us, the message comes from the command
> "head", not from git. (head is used by git-rebase -i)
>
>> Notice I did not commit the adds. I didn't think it made
>> sense to do that, since I imagine that is what the rebase is doing
>> anyway?
>>
>> This is on git version 1.5.5.3.
>>
>> Should I upgrade git? Will that break any repos that I have?
>
> Yes! No!
>
> Cheers,
> Michael
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* git-svn feature request: exclude certain subpaths on clone
From: Wade Berrier @ 2008-12-04 16:43 UTC (permalink / raw)
To: git
Hi,
Consider the following example layout:
trunk/src
trunk/big_fat_binary_blobs
trunk/doc
I think it would be really nice to be able to tell git-svn to ignore
'big_fat_binary_blobs' while keeping 'src' and 'doc'.
I know someone is thinking, "Why did you check in
'big_fat_binary_blobs' in the first place?" In this case, the
repository is out of my control. For the svn users, it's not that big
of a deal since they only get one HEAD version of the binary_blobs.
But when trying to clone with git-svn, I repeatedly get out of memory
and packing errors (every 1000 commits) when packing several revisions
of these binary_blobs. (Now, that may be a bug in of itself... which
can reproduced by creating an svn repo with several revisions of
KNOPPIX at the same path, followed by a git svn clone )
Anyway, I still think it may be useful to be able to ignore certain
paths on a clone. In thinking about the implementation details, I
figure probably the best approach would be to manually purge the
unwanted path after it has been fetched, but before it is committed.
That way, if a commit contains changes in paths that are both wanted
and unwanted, the commit could be 'pruned'.
I've looked at the git-svn script a little, but wanted to solicit
feedback and ideas before continuing further.
Thoughts?
Wade
^ permalink raw reply
* Re: git rebase --continue with goofy error
From: Michael J Gruber @ 2008-12-04 16:32 UTC (permalink / raw)
To: Adrian Klingel; +Cc: git
In-Reply-To: <5AC243B6-F048-4286-80E1-1D0E695792B9@illumaware.com>
Adrian Klingel venit, vidit, dixit 04.12.2008 15:55:
> I am trying so, so hard to rebase a branch with updates made in master:
>
> *********
> git rebase master
> *********
>
> I get about 20 conflicts back, which I fix and do:
>
> *********
> git add *
> *********
>
> There were also many, many error messages after the rebase command, eg:
>
> *********
> error: test/unit/missing_year_test.rb: already exists in index
> error: test/unit/axle_test.rb: already exists in index
> error: test/unit/body_style_test.rb: already exists in index
> error: test/unit/brake_test.rb: already exists in index
> error: test/unit/category_test.rb: already exists in index
> error: test/unit/comment_test.rb: already exists in index
> error: test/unit/company_comment_test.rb: does not exist in index
> error: test/unit/country_test.rb: already exists in index
> *********
>
>
> but I ignore that error, because I have no idea what it means. If I
Not a good general approach. If there are errors to begin with there is
no reason to expect success later on.
Here, I assume you are starting from a dirty working tree. What did git
status say before the rebase?
> were to guess, I'd say it's trying to copy files from master to my
> current branch. Of course.
>
> So now I have added my conflict fixes, per the message:
>
> *********
> Failed to merge in the changes.
> Patch failed at 0002.
>
> When you have resolved this problem run "git rebase --continue".
> If you would prefer to skip this patch, instead run "git rebase --skip".
> To restore the original branch and stop rebasing run "git rebase --
> abort".
> *********
What command triggered that message? It's certainly not saying that you
have added your conflict fixes, as you seem to think.
>
> So I decide to continue:
>
> *********
> git rebase --continue
> *********
>
>
> And I get the following:
>
> *********
> mymac:/Library/mydir/code/myapp me$ git rebase --continue
> Unknown option: 1
> Usage: head [-options] <url>...
> -m <method> use method for the request (default is 'HEAD')
> -f make request even if head believes method is illegal
> -b <base> Use the specified URL as base
> -t <timeout> Set timeout value
> -i <time> Set the If-Modified-Since header on the request
> -c <conttype> use this content-type for POST, PUT, CHECKIN
> -a Use text mode for content I/O
> -p <proxyurl> use this as a proxy
> -P don't load proxy settings from environment
> -H <header> send this HTTP header (you can specify several)
>
> -u Display method and URL before any response
> -U Display request headers (implies -u)
> -s Display response status code
> -S Display response status chain
> -e Display response headers
> -d Do not display content
> -o <format> Process HTML content in various ways
>
> -v Show program version
> -h Print this message
>
> -x Extra debugging output
> Applying
> You still have unmerged paths in your index
> did you forget to use 'git add'?
>
> When you have resolved this problem run "git rebase --continue".
> If you would prefer to skip this patch, instead run "git rebase --skip".
> To restore the original branch and stop rebasing run "git rebase --
> abort".
>
> *********
>
>
> A google search of "git" and "Unknown option: 1" yields zero
> results.
As the "Usage: head..." tells us, the message comes from the command
"head", not from git. (head is used by git-rebase -i)
> Notice I did not commit the adds. I didn't think it made
> sense to do that, since I imagine that is what the rebase is doing
> anyway?
>
> This is on git version 1.5.5.3.
>
> Should I upgrade git? Will that break any repos that I have?
Yes! No!
Cheers,
Michael
^ 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