* 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
* Re: git rebase --continue with goofy error
From: Björn Steinbrink @ 2008-12-04 16:27 UTC (permalink / raw)
To: Adrian Klingel; +Cc: git
In-Reply-To: <5AC243B6-F048-4286-80E1-1D0E695792B9@illumaware.com>
On 2008.12.04 09:55:55 -0500, Adrian Klingel wrote:
> 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
That comes via git-am which used to call "head -1", but using -<n> is
deprecated and apparently not supported anymore by modern versions of
coreutils. Was fixed in:
1d9b2656: git-am: head -1 is obsolete and doesn't work on some new systems
Which is in git 1.5.6.
Björn
^ permalink raw reply
* Re: git rebase --continue with goofy error
From: Adrian Klingel @ 2008-12-04 16:24 UTC (permalink / raw)
To: git
In-Reply-To: <9F631552-BA29-4A85-9A85-2992232CDDE6@railsnewbie.com>
That's the problem. I've resolved the conflicts, added everything.
Then I run git rebase --continue and that's what I get. After I do
the adds, am I supposed to commit them?
Adrian Klingel
President/CEO
Illumaware, LLC
Adrian.Klingel@illumaware.com
phone: 800.880.4964
outside US: 919.783.4037
fax: 919-882.9447
On Dec 4, 2008, at 10:52 AM, Scott Taylor wrote:
>
> On Dec 4, 2008, at 9:55 AM, Adrian Klingel wrote:
>
>> 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 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".
>> *********
>>
>>
>> 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. 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?
>>
>
> I'm not sure what the first part of this is saying (The "unknown
> option").
>
> The important part is later on:
>
> You still have unmerged paths in your index
> did you forget to use 'git add'?
>
> After you resolve any conflicts, make sure to git add any remaining
> files before you "rebase --continue"
>
> Regards,
>
> Scott
>
>
^ permalink raw reply
* Re: git-gui: Warn when username and e-mail address is unconfigured?
From: Jeremy Ramer @ 2008-12-04 16:05 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0812041141160.9969@ds9.cixit.se>
On Thu, Dec 4, 2008 at 3:43 AM, Peter Krefting <peter@softwolves.pp.se> wrote:
> Hi!
>
> When using Git on Windows, it doesn't pick up a user name from the
> environment, which leads to commits made by git gui (and probably by
> git itself) to show up as being made by "unknown <username@.(none)>"
> (where "username" is the Windows account name).
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.
>
> Is it possible to add a warning to git-gui the first time a commit is
> attempted if the e-mail address is not configured, and have the user
> open the configuration dialogue to set up the name properly?
>
> --
> \\// Peter - http://www.softwolves.pp.se/
> --
> 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: [PATCH] gitk: fix 'can't read "notflag"'
From: Johannes Sixt @ 2008-12-04 15:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Paul Mackerras, Alejandro Riveira, git
In-Reply-To: <alpine.DEB.1.00.0812041609150.7045@racer>
Johannes Schindelin schrieb:
> On Thu, 4 Dec 2008, Johannes Schindelin wrote:
>
>> diff --git a/gitk-git/gitk b/gitk-git/gitk
>
> D'oh. Please apply with -p2.
No; pull -s subtree before you write this patch ;) It's already fixed in
upstream gitk.
-- Hannes
^ permalink raw reply
* git rebase --continue with goofy error
From: Adrian Klingel @ 2008-12-04 14:55 UTC (permalink / raw)
To: git
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
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".
*********
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. 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?
Thanks very, very much.
^ permalink raw reply
* Re: [PATCH] gitk: fix 'can't read "notflag"'
From: Johannes Schindelin @ 2008-12-04 15:09 UTC (permalink / raw)
To: Paul Mackerras, Alejandro Riveira; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812041532160.7045@racer>
Hi,
On Thu, 4 Dec 2008, Johannes Schindelin wrote:
> diff --git a/gitk-git/gitk b/gitk-git/gitk
D'oh. Please apply with -p2.
Ciao,
Dscho
^ 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