* [EGIT] How to deal with important modifications
From: Yann Simon @ 2009-03-28 17:32 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
Hi,
I am working on the synchronization view. It is not 100% functional yet.
The view is not updated when a local file is modified for example.
As the modifications are getting important, I was wondering how to deal
with it. Should I continue my work an send all the patches when
finished?
To have an overview of the modifications:
http://github.com/yanns/egit/commit/18c4a928d53345802a8c9641dcb2d457ebbe2cbc
http://github.com/yanns/egit/commit/9fab398fa1b7b6efa9532b3c09e5bcfcc8bb9419
Or should I begin to send patches, but by not activating the function
yet?
(It could be a way to have other people to help contributing.)
Yann
^ permalink raw reply
* Re: git svn clone failure
From: Lachlan Deck @ 2009-03-28 17:29 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200903281620.29564.markus.heidelberg@web.de>
On 29/03/2009, at 2:20 AM, Markus Heidelberg wrote:
> Lachlan Deck, 28.03.2009:
>> On 28/03/2009, at 11:59 PM, Markus Heidelberg wrote:
>>
>>> Lachlan Deck, 27.03.2009:
>>>> Hi there,
>>>>
>>>> I'm trying to clone an existing svn repository with git (just
>>>> getting
>>>> started with git) and it keeps failing with:
>>>> ...
>>>> r604 = 6428e63734a21ee5fcb4593274747e2758578a91 (git-svn)
>>>> fatal: unable to run 'git-svn'
>>>
>>> Are you sure r604 isn't the latest svn revision?
>>
>> A few thousand out, yes.
>>
>>> I always get this error when doing "git svn fetch" with an http URL,
>>> it
>>> doesn't occur with an svn URL. But everything seems to work fine,
>>> though.
>>
>> Interesting. Yes, it's from an https url. I'll try svn+ssh://..
>> But are you saying there's no way to get more info about the error?
>
> At least I don't have more info about it except for this:
> I use Gentoo Linux and the git ebuild (I have the distribution package
> installed, but use the self-compiled git) says
>
> "Per Gentoo bugs #223747, #238586, when subversion is built"
> "with USE=dso, there may be weird crashes in git-svn. You"
> "have been warned."
>
> I have subversion compiled with dso (Enable runtime module search),
> it's
> enabled per default. And since it worked, I didn't change it. But it
> would be interesting to see, if this error has something to do with
> it.
> Maybe I'll try it out.
It may well have been a network issue for me when I tried the other
day. It seemed to work fine now.
with regards,
--
Lachlan Deck
^ permalink raw reply
* Re: Fork of abandoned SVN mirror - how to keep up to date with the SVN
From: jamespetts @ 2009-03-28 16:46 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a060903280922r6514de83mea4dea84c4116225@mail.gmail.com>
I just tried cloning this repo using the command below, and it appears
to be working just fine. (Hasn't finished, yet. Up to rev 465.) What
is the full command you're using when it will hang?
I was not using the command line - I was using the GUI on the Github website.
--
View this message in context: http://n2.nabble.com/Fork-of-abandoned-SVN-mirror---how-to-keep-up-to-date-with-the-SVN-tp2548952p2549665.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Segfault on merge with 1.6.2.1
From: Michael Johnson @ 2009-03-28 16:19 UTC (permalink / raw)
To: git
Greetings.
I'm trying to figure out what's going on with a merge I'm trying to do. As
far as I know, it's a fairly standard situation, just merging two
branches. But I get a segfault each time. This occurs with 1.5.6.5 and
1.6.2.1. The earlier version is on a Debian Etch box with
backports.debian.org. The latter is Debian Sid. I also tried on a Windows
box with MSysGit 1.6.2.1-preview20090322.exe.
The 1.6.2.1 version just segfaults, but 1.5.6.5 says:
/usr/bin/git-merge: line 438: 32335 Segmentation fault
git-merge-$strategy $common -- "$head_arg" "$@"
Merge with strategy recursive failed.
In all cases, .git/index.lock is left behind.
I'm using the default configuration, with only a few basic options in my
person .gitconfig.
Unfortunately, I cannot post the archive, but I can tar the archive and
share that with individuals, if need be.
The problems started with a weird merge by another developer a while ago
that somehow reapplied earlier commits. It looked like he had done some
commits that wiped some earlier commits but then a commit or two latter
the old commits were added back. When I tried to merge the resulting
master into my working branch it segfaulted. I didn't have time (or the
immediate need) to look into it then and it's been forgotten until now
(when, of course, it needs to be done in the next few days :( ).
I have run git gc and also pruned a couple of minor dangling objects.
Running git fsck --full reveals no problems. The largest file is about
6MiB.
I've asked on #git, and drizzd there suggested I try here. At this point
I'm completely at a loss.
Any help would be greatly appreciated.
Thanks,
Michael
--
Michael D Johnson <redbeard@mdjohnson.us>
redbeardcreator.deviantart.com
"Marketing research...[has] shown that energy weapons that make sounds sell
better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111)
^ permalink raw reply
* Re: Git Download/Bootstrap Suggestion
From: Jacob Helwig @ 2009-03-28 16:24 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Michael J Gruber, Mike Gaffney, git
In-Reply-To: <fabb9a1e0903280915l512374ebt8a1f804666dfe87b@mail.gmail.com>
So he can compile git from a git repo, and not have to download it
(again) after compiling from a work tree. Saving a step, and
re-compiling a bunch of files when he upgrades.
On Sat, Mar 28, 2009 at 09:15, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Sat, Mar 28, 2009 at 17:09, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> No, I think he meant repo, not work tree.
>
> Why would he need the repo to bootstrap?
>
> --
> Cheers,
>
> Sverre Rabbelier
> --
> 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: Fork of abandoned SVN mirror - how to keep up to date with the SVN
From: Jacob Helwig @ 2009-03-28 16:22 UTC (permalink / raw)
To: Git; +Cc: jamespetts
In-Reply-To: <22756729.post@talk.nabble.com>
I just tried cloning this repo using the command below, and it appears
to be working just fine. (Hasn't finished, yet. Up to rev 465.) What
is the full command you're using when it will hang?
git svn clone -s --username=anon --prefix=svn/ \
svn://tron.homeunix.org/simutrans/simutrans
On Sat, Mar 28, 2009 at 06:11, jamespetts <jamespetts@yahoo.com> wrote:
>
> For some months, I have been working on a
> http://github.com/jamespetts/simutrans-experimental/tree fork of the
> popular open source transport simulation game, http://www.simutrans.com
> Simutrans . Simutrans uses SVN as its official VCS, but I have been using
> Git, by forking an http://github.com/aburch/simutrans/tree/master
> unofficial mirror of the Simutrans SVN on Github. That has made it
> extremely easy for me to merge in updates to the trunk code whilst
> continuing to work on my branch.
>
> However, last week, the unofficial mirror on Github suddenly stopped
> tracking the updates on the SVN. I have sent a message to the person who
> administers it, but he has not been around for a long time, and I fear that
> he probably will not reply - he did not reply to a message that I sent him
> some time ago. I do not really know what to do now to keep my branch
> synchronised. I have tried creating my own mirror of the SVN on Github, but
> there are two problems: (1) I cannot for the life of me get the creation of
> the mirror to work - it gets stuck permanently at "fetching authors"; and
> (2) even if I did succeed in creating a mirror, it would no longer be the
> same as the branch from which I forked, so Git would not be able to keep a
> track of which parts of the code I intend to keep different from the trunk,
> and which are the new updates to the trunk that I want to incorporate in my
> branch.
>
> What is the best way of dealing with this mess to try to re-instate an easy
> and reliable system of taking updates from the SVN and merging them into my
> branched code?
> --
> View this message in context: http://www.nabble.com/Fork-of-abandoned-SVN-mirror---how-to-keep-up-to-date-with-the-SVN-tp22756729p22756729.html
> Sent from the git mailing list archive at Nabble.com.
>
> --
> 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 Download/Bootstrap Suggestion
From: Sverre Rabbelier @ 2009-03-28 16:15 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Mike Gaffney, git
In-Reply-To: <49CE4BD2.4060808@drmicha.warpmail.net>
Heya,
On Sat, Mar 28, 2009 at 17:09, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> No, I think he meant repo, not work tree.
Why would he need the repo to bootstrap?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Git Download/Bootstrap Suggestion
From: Michael J Gruber @ 2009-03-28 16:09 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Mike Gaffney, git
In-Reply-To: <fabb9a1e0903271621g392eefdeu85b46c655c1ad067@mail.gmail.com>
Sverre Rabbelier venit, vidit, dixit 28.03.2009 00:21:
> Heya,
>
> On Fri, Mar 27, 2009 at 18:09, Mike Gaffney <mr.gaffo@gmail.com> wrote:
>> I have to do is
>> - download the source tarball (or the rpm)
>> - make it
>> - install it
>
> Nah, you don't need to do all that ;).
>
>
>> It'd be a lot cooler if I could just wget a full get repo on the latest tag
>
> You mean like, this?
>
> http://repo.or.cz/w/git.git?a=snapshot;h=master;sf=tgz
>
No, I think he meant repo, not work tree.
Michael
^ permalink raw reply
* [PATCH] difftool: add support for a difftool.prompt config variable
From: David Aguilar @ 2009-03-28 15:44 UTC (permalink / raw)
To: gitster; +Cc: git, David Aguilar
difftool now supports difftool.prompt so that users do not have to
pass --no-prompt or hit enter each time a diff tool is launched.
The --prompt flag overrides the configuration variable.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Documentation/config.txt | 3 ++
Documentation/git-difftool.txt | 10 +++++-
git-difftool-helper.sh | 10 +++++-
git-difftool.perl | 15 +++++++--
t/t7800-difftool.sh | 64 ++++++++++++++++++++++++++++++++++++++++
5 files changed, 96 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 089569a..81f9e9a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -680,6 +680,9 @@ difftool.<tool>.cmd::
is set to the name of the temporary file containing the contents
of the diff post-image.
+difftool.prompt::
+ Prompt before each invocation of the diff tool.
+
diff.wordRegex::
A POSIX Extended Regular Expression used to determine what is a "word"
when performing word-by-word difference calculations. Character
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index a00e943..73d4782 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -7,7 +7,7 @@ git-difftool - Show changes using common diff tools
SYNOPSIS
--------
-'git difftool' [--tool=<tool>] [-y|--no-prompt] [<'git diff' options>]
+'git difftool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<'git diff' options>]
DESCRIPTION
-----------
@@ -21,6 +21,11 @@ OPTIONS
--no-prompt::
Do not prompt before launching a diff tool.
+--prompt::
+ Prompt before each invocation of the diff tool.
+ This is the default behaviour; the option is provided to
+ override any configuration settings.
+
-t <tool>::
--tool=<tool>::
Use the diff tool specified by <tool>.
@@ -72,6 +77,9 @@ difftool.<tool>.cmd::
+
See the `--tool=<tool>` option above for more details.
+difftool.prompt::
+ Prompt before each invocation of the diff tool.
+
SEE ALSO
--------
linkgit:git-diff[1]::
diff --git a/git-difftool-helper.sh b/git-difftool-helper.sh
index b91002b..02bb135 100755
--- a/git-difftool-helper.sh
+++ b/git-difftool-helper.sh
@@ -7,9 +7,15 @@
#
# Copyright (c) 2009 David Aguilar
-# Set GIT_DIFFTOOL_NO_PROMPT to bypass the per-file prompt.
+# difftool.prompt controls the default prompt/no-prompt behavior
+# and is overridden with $GIT_DIFFTOOL*_PROMPT.
should_prompt () {
- test -z "$GIT_DIFFTOOL_NO_PROMPT"
+ prompt=$(git config --bool difftool.prompt || echo true)
+ if test "$prompt" = true; then
+ test -z "$GIT_DIFFTOOL_NO_PROMPT"
+ else
+ test -n "$GIT_DIFFTOOL_PROMPT"
+ fi
}
# This function prepares temporary files and launches the appropriate
diff --git a/git-difftool.perl b/git-difftool.perl
index 8c160e5..985dfe0 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -2,9 +2,12 @@
# Copyright (c) 2009 David Aguilar
#
# This is a wrapper around the GIT_EXTERNAL_DIFF-compatible
-# git-difftool-helper script. This script exports
-# GIT_EXTERNAL_DIFF and GIT_PAGER for use by git, and
-# GIT_DIFFTOOL_NO_PROMPT and GIT_DIFF_TOOL for use by git-difftool-helper.
+# git-difftool-helper script.
+#
+# This script exports GIT_EXTERNAL_DIFF and GIT_PAGER for use by git.
+# GIT_DIFFTOOL_NO_PROMPT, GIT_DIFFTOOL_PROMPT, and GIT_DIFF_TOOL
+# are exported for use by git-difftool-helper.
+#
# Any arguments that are unknown to this script are forwarded to 'git diff'.
use strict;
@@ -62,6 +65,12 @@ sub generate_command
}
if ($arg eq '-y' || $arg eq '--no-prompt') {
$ENV{GIT_DIFFTOOL_NO_PROMPT} = 'true';
+ delete $ENV{GIT_DIFFTOOL_PROMPT};
+ next;
+ }
+ if ($arg eq '--prompt') {
+ $ENV{GIT_DIFFTOOL_PROMPT} = 'true';
+ delete $ENV{GIT_DIFFTOOL_NO_PROMPT};
next;
}
if ($arg eq '-h' || $arg eq '--help') {
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index ceef84b..9cb2790 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -15,6 +15,7 @@ remove_config_vars()
# Unset all config variables used by git-difftool
git config --unset diff.tool
git config --unset difftool.test-tool.cmd
+ git config --unset difftool.prompt
git config --unset merge.tool
git config --unset mergetool.test-tool.cmd
return 0
@@ -26,11 +27,18 @@ restore_test_defaults()
remove_config_vars
unset GIT_DIFF_TOOL
unset GIT_MERGE_TOOL
+ unset GIT_DIFFTOOL_PROMPT
unset GIT_DIFFTOOL_NO_PROMPT
git config diff.tool test-tool &&
git config difftool.test-tool.cmd 'cat $LOCAL'
}
+prompt_given()
+{
+ prompt="$1"
+ test "$prompt" = "Hit return to launch 'test-tool': branch"
+}
+
# Create a file on master and change it on branch
test_expect_success 'setup' '
echo master >file &&
@@ -116,6 +124,62 @@ test_expect_success 'GIT_DIFFTOOL_NO_PROMPT variable' '
restore_test_defaults
'
+# git-difftool supports the difftool.prompt variable.
+# Test that GIT_DIFFTOOL_PROMPT can override difftool.prompt = false
+test_expect_success 'GIT_DIFFTOOL_PROMPT variable' '
+ git config difftool.prompt false &&
+ GIT_DIFFTOOL_PROMPT=true &&
+ export GIT_DIFFTOOL_PROMPT &&
+
+ prompt=$(echo | git difftool --prompt branch | tail -1) &&
+ prompt_given "$prompt" &&
+
+ restore_test_defaults
+'
+
+# Test that we don't have to pass --no-prompt when difftool.prompt is false
+test_expect_success 'difftool.prompt config variable is false' '
+ git config difftool.prompt false &&
+
+ diff=$(git difftool branch) &&
+ test "$diff" = "branch" &&
+
+ restore_test_defaults
+'
+
+# Test that the -y flag can override difftool.prompt = true
+test_expect_success 'difftool.prompt can overridden with -y' '
+ git config difftool.prompt true &&
+
+ diff=$(git difftool -y branch) &&
+ test "$diff" = "branch" &&
+
+ restore_test_defaults
+'
+
+# Test that the --prompt flag can override difftool.prompt = false
+test_expect_success 'difftool.prompt can overridden with --prompt' '
+ git config difftool.prompt false &&
+
+ prompt=$(echo | git difftool --prompt branch | tail -1) &&
+ prompt_given "$prompt" &&
+
+ restore_test_defaults
+'
+
+# Test that the last flag passed on the command-line wins
+test_expect_success 'difftool last flag wins' '
+ diff=$(git difftool --prompt --no-prompt branch) &&
+ test "$diff" = "branch" &&
+
+ restore_test_defaults &&
+
+ prompt=$(echo | git difftool --no-prompt --prompt branch | tail -1) &&
+ prompt_given "$prompt"
+
+ restore_test_defaults
+'
+
# git-difftool falls back to git-mergetool config variables
# so test that behavior here
test_expect_success 'difftool + mergetool config variables' '
--
1.6.2.1.404.gb0085
^ permalink raw reply related
* Re: How do I force git to forget about merging a binary file that is to stay deleted on the target branch?
From: Brent Goodrick @ 2009-03-28 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Elijah Newren, git
In-Reply-To: <7viqltvg7n.fsf@gitster.siamese.dyndns.org>
On Sat, Mar 28, 2009 at 8:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> You can resolve this merge conflict by running
>> $ git rm TimeSheets/Timesheet\ Exempt.XLS
>>
>> which will make git delete the file from your working copy and the
>> index, at which point you can then make a commit that does not include
>> this file.
>
> But is this what you really want to do? After doing such a "remove it"
> merge resolution at Home, wouldn't merging it back to Work remove the
> file?
Yes, and I've not told the full story. Each time I do a merge in
between the two branches, I have a script that resets certain files
that I don't want cross-pollinated between the two branches. Then I do
the commit. Most of the time (on non-binary files, and/or on files I
only change on the work branch and not on the home branch), this works
just fine.
My desire to avoid doing the above drove my earlier post asking
whether there as a facility to exclude certain files from
participating in merges. But the answer was "no" to that, hence my ad
hoc workaround above.
bg
^ permalink raw reply
* Re: git svn clone failure
From: Markus Heidelberg @ 2009-03-28 15:20 UTC (permalink / raw)
To: Lachlan Deck; +Cc: git
In-Reply-To: <F76E6356-60EB-4FDE-B97E-CB34FF2D7017@gmail.com>
Lachlan Deck, 28.03.2009:
> On 28/03/2009, at 11:59 PM, Markus Heidelberg wrote:
>
> > Lachlan Deck, 27.03.2009:
> >> Hi there,
> >>
> >> I'm trying to clone an existing svn repository with git (just getting
> >> started with git) and it keeps failing with:
> >> ...
> >> r604 = 6428e63734a21ee5fcb4593274747e2758578a91 (git-svn)
> >> fatal: unable to run 'git-svn'
> >
> > Are you sure r604 isn't the latest svn revision?
>
> A few thousand out, yes.
>
> > I always get this error when doing "git svn fetch" with an http URL,
> > it
> > doesn't occur with an svn URL. But everything seems to work fine,
> > though.
>
> Interesting. Yes, it's from an https url. I'll try svn+ssh://..
> But are you saying there's no way to get more info about the error?
At least I don't have more info about it except for this:
I use Gentoo Linux and the git ebuild (I have the distribution package
installed, but use the self-compiled git) says
"Per Gentoo bugs #223747, #238586, when subversion is built"
"with USE=dso, there may be weird crashes in git-svn. You"
"have been warned."
I have subversion compiled with dso (Enable runtime module search), it's
enabled per default. And since it worked, I didn't change it. But it
would be interesting to see, if this error has something to do with it.
Maybe I'll try it out.
Markus
^ permalink raw reply
* Re: How do I force git to forget about merging a binary file that is to stay deleted on the target branch?
From: Junio C Hamano @ 2009-03-28 15:07 UTC (permalink / raw)
To: Elijah Newren; +Cc: Brent Goodrick, git
In-Reply-To: <51419b2c0903280547y1bb5664dj70e4e6aa939bd015@mail.gmail.com>
Elijah Newren <newren@gmail.com> writes:
> On Fri, Mar 27, 2009 at 11:26 PM, Brent Goodrick <bgoodr@gmail.com> wrote:
>> How do I commit a merge but force git to forget about merging one file
>> that I don't want on the target branch, when it is binary, and when it
>> was changed on the source branch, but was deleted on the target branch
>> (and should stay deleted on the target branch)?
>>
>> The details: I am merging a "work" branch into a "home" branch. There
>> is one file called "TimeSheets/Timesheet Exempt.XLS" that is binary.
>> I don't want that file on the "home" branch, but do want it on the
>> "work" branch. I had made an editing change to that file on the
>> "work" branch, along with a bunch of other changes I do want to merge
>> into the "home" branch. But no matter what I do, I can't force git to
>> forget about that "TimeSheets/Timesheet Exempt.XLS" file.
>>
>> I've tried various flavors of git-checkout and git-reset to no
>> avail. This is what I see at the very last before I gave up:
>
> You can resolve this merge conflict by running
> $ git rm TimeSheets/Timesheet\ Exempt.XLS
>
> which will make git delete the file from your working copy and the
> index, at which point you can then make a commit that does not include
> this file.
But is this what you really want to do? After doing such a "remove it"
merge resolution at Home, wouldn't merging it back to Work remove the
file?
^ permalink raw reply
* Re: How do I force git to forget about merging a binary file that is to stay deleted on the target branch?
From: Brent Goodrick @ 2009-03-28 14:46 UTC (permalink / raw)
To: Elijah Newren; +Cc: git
In-Reply-To: <51419b2c0903280547y1bb5664dj70e4e6aa939bd015@mail.gmail.com>
On Sat, Mar 28, 2009 at 5:47 AM, Elijah Newren <newren@gmail.com> wrote:
> You can resolve this merge conflict by running
> $ git rm TimeSheets/Timesheet\ Exempt.XLS
Much appreciated! That works.
Thanks for your and Nanako's help!
bg
^ permalink raw reply
* Re: How do I force git to forget about merging a binary file that is to stay deleted on the target branch?
From: Brent Goodrick @ 2009-03-28 14:29 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090328192300.6117@nanako3.lavabit.com>
On Sat, Mar 28, 2009 at 3:23 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> I think the standard answer is "you don't".
Thanks, but unfortunately, that won't work for me, since I have too
many commits with useful history that would get lost if I started over
and set up the work and home branches that are branched separately off
of master. Also the "work" fileset and the "home" fileset are 80% the
same; its the 20% that causes me puzzlement each time I want to merge
changes made on one branch onto the other.
bg
^ permalink raw reply
* Re: git svn clone failure
From: Lachlan Deck @ 2009-03-28 14:16 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200903281359.34412.markus.heidelberg@web.de>
On 28/03/2009, at 11:59 PM, Markus Heidelberg wrote:
> Lachlan Deck, 27.03.2009:
>> Hi there,
>>
>> I'm trying to clone an existing svn repository with git (just getting
>> started with git) and it keeps failing with:
>> ...
>> r604 = 6428e63734a21ee5fcb4593274747e2758578a91 (git-svn)
>> fatal: unable to run 'git-svn'
>
> Are you sure r604 isn't the latest svn revision?
A few thousand out, yes.
> I always get this error when doing "git svn fetch" with an http URL,
> it
> doesn't occur with an svn URL. But everything seems to work fine,
> though.
Interesting. Yes, it's from an https url. I'll try svn+ssh://..
But are you saying there's no way to get more info about the error?
Thanks
with regards,
--
Lachlan Deck
^ permalink raw reply
* Re: Newbie installation problem: non 7-zip archive
From: Michele Ballabio @ 2009-03-28 13:17 UTC (permalink / raw)
To: Angus Monro; +Cc: git
In-Reply-To: <7BF674E8656F4DA1A97DA952A4CD50EC@NEOAREOPAGUS>
On Saturday 28 March 2009, Angus Monro wrote:
> I’m working on Win XP 2002 SP3.
>
> When I download & run PortableGit-1.6.2.1-preview20090322.exe, it asks for
> the installation location, but after I’ve confirmed that location & pressed
> OK, it gives me an error message window:
> Title bar: “WinGit: MinGW Git + minimal MSys installation: error”
> Message: “Non 7-Zip archive.”
>
> When I download & run Git-1.6.2.1-preview20090322.exe, it immediately
> complains
> Title bar: “Error”
> Message: “The setup files are corrupted. Please obtain a new copy
> of the program.”
>
> In both cases, I’ve downloaded from
> http://code.google.com/p/msysgit/downloads/list, and have tried
> re-downloading & re-running, still without success.
>
> Any thoughts?
Maybe IE (or something else) is corrupting the downloads.
http://brucewagner.wordpress.com/2006/12/15/the-setup-files-are-corrupted-please-obtain-a-new-copy-of-the-program/
^ permalink raw reply
* Fork of abandoned SVN mirror - how to keep up to date with the SVN
From: jamespetts @ 2009-03-28 13:11 UTC (permalink / raw)
To: git
For some months, I have been working on a
http://github.com/jamespetts/simutrans-experimental/tree fork of the
popular open source transport simulation game, http://www.simutrans.com
Simutrans . Simutrans uses SVN as its official VCS, but I have been using
Git, by forking an http://github.com/aburch/simutrans/tree/master
unofficial mirror of the Simutrans SVN on Github. That has made it
extremely easy for me to merge in updates to the trunk code whilst
continuing to work on my branch.
However, last week, the unofficial mirror on Github suddenly stopped
tracking the updates on the SVN. I have sent a message to the person who
administers it, but he has not been around for a long time, and I fear that
he probably will not reply - he did not reply to a message that I sent him
some time ago. I do not really know what to do now to keep my branch
synchronised. I have tried creating my own mirror of the SVN on Github, but
there are two problems: (1) I cannot for the life of me get the creation of
the mirror to work - it gets stuck permanently at "fetching authors"; and
(2) even if I did succeed in creating a mirror, it would no longer be the
same as the branch from which I forked, so Git would not be able to keep a
track of which parts of the code I intend to keep different from the trunk,
and which are the new updates to the trunk that I want to incorporate in my
branch.
What is the best way of dealing with this mess to try to re-instate an easy
and reliable system of taking updates from the SVN and merging them into my
branched code?
--
View this message in context: http://www.nabble.com/Fork-of-abandoned-SVN-mirror---how-to-keep-up-to-date-with-the-SVN-tp22756729p22756729.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/2] init: support --import to add all files and commit right after init
From: Markus Heidelberg @ 2009-03-28 13:09 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Santi Béjar, Jeff King, Nguydn Thái Ngdc, git
In-Reply-To: <alpine.DEB.1.00.0903281334490.12669@intel-tinevez-2-302>
Johannes Schindelin, 28.03.2009:
> Hi,
>
> On Sat, 28 Mar 2009, Markus Heidelberg wrote:
>
> > Johannes Schindelin, 27.03.2009:
> > > Others who want to have a quick way to work safely with something they
> > > might need to change, and might then want to use the full power of Git
> > > to see what they changed. Without any need for a "nice" first commit.
> >
> > What's the difference between the first commit and the others? I don't
> > see the reason, not to have a short description for it.
>
> Maybe you can learn a new trick here:
>
> $ tar xf /some/random/project.tar
> $ git init
> $ git add .
> $ git commit -m initial
>
> and now one of two work flows:
>
> # get the thing to work properly, or add a new feature, or clean up...
> $ git diff > diff.patch
> # send the diff to the maintainer, without ever committing
>
> or
>
> # make a patch series, use rebase -i to clean up after it
> # send the patch series to the maintainer of the random project
>
> See? The initial commit does not matter at all.
Yep, I only thought about own projects and didn't take this workflow
into account. Although I have already used it myself and of course the
initial commit is not interesting then.
> I do this so often that it stops being funny having to type three
> commands.
>
> And having to edit a commit message I do not care about anyway everytime,
> just to please you, would not make it any funnier ;-)
Understood :)
But note, that my second mail was only about writing an initial commit
message or not. I don't have objections against the default commit
message with --import any more.
Markus
^ permalink raw reply
* Re: git svn clone failure
From: Markus Heidelberg @ 2009-03-28 12:59 UTC (permalink / raw)
To: Lachlan Deck; +Cc: git
In-Reply-To: <A5DCF978-5D10-4A6C-BE4B-1024FA475E2F@gmail.com>
Lachlan Deck, 27.03.2009:
> Hi there,
>
> I'm trying to clone an existing svn repository with git (just getting
> started with git) and it keeps failing with:
> ...
> r604 = 6428e63734a21ee5fcb4593274747e2758578a91 (git-svn)
> fatal: unable to run 'git-svn'
Are you sure r604 isn't the latest svn revision?
I always get this error when doing "git svn fetch" with an http URL, it
doesn't occur with an svn URL. But everything seems to work fine,
though.
Markus
^ permalink raw reply
* Re: How do I force git to forget about merging a binary file that is to stay deleted on the target branch?
From: Elijah Newren @ 2009-03-28 12:47 UTC (permalink / raw)
To: Brent Goodrick; +Cc: git
In-Reply-To: <e38bce640903272226l3facf47br9b1849bf708c3881@mail.gmail.com>
Hi,
On Fri, Mar 27, 2009 at 11:26 PM, Brent Goodrick <bgoodr@gmail.com> wrote:
> How do I commit a merge but force git to forget about merging one file
> that I don't want on the target branch, when it is binary, and when it
> was changed on the source branch, but was deleted on the target branch
> (and should stay deleted on the target branch)?
>
> The details: I am merging a "work" branch into a "home" branch. There
> is one file called "TimeSheets/Timesheet Exempt.XLS" that is binary.
> I don't want that file on the "home" branch, but do want it on the
> "work" branch. I had made an editing change to that file on the
> "work" branch, along with a bunch of other changes I do want to merge
> into the "home" branch. But no matter what I do, I can't force git to
> forget about that "TimeSheets/Timesheet Exempt.XLS" file.
>
> I've tried various flavors of git-checkout and git-reset to no
> avail. This is what I see at the very last before I gave up:
You can resolve this merge conflict by running
$ git rm TimeSheets/Timesheet\ Exempt.XLS
which will make git delete the file from your working copy and the
index, at which point you can then make a commit that does not include
this file.
> Here is what I'm left with:
>
> ,----
> | $ : gitw status
> | TimeSheets/Timesheet Exempt.XLS: needs merge
> | # On branch home
> | # Changes to be committed:
> | # (use "git reset HEAD <file>..." to unstage)
> | #
> | <snipped out other files I do want to commit>
> | #
> | # Changed but not updated:
> | # (use "git add <file>..." to update what will be committed)
> | # (use "git checkout -- <file>..." to discard changes in working directory)
> | #
> | # unmerged: TimeSheets/Timesheet Exempt.XLS
> | #
> | $ : gitw commit -m "merge from work"
> | TimeSheets/Timesheet Exempt.XLS: needs merge
> | TimeSheets/Timesheet Exempt.XLS: unmerged
> (49a49bd9de154daa8ca6cff3cfb550d0dd1b4519)
> | TimeSheets/Timesheet Exempt.XLS: unmerged
> (8de60b8b6827ef1f80921f6d35b574a56683bfdd)
> | error: Error building trees
> `----
>
> Any help anyone can provide is greatly appreciated.
^ permalink raw reply
* Re: [PATCH 1/2] init: support --import to add all files and commit right after init
From: Johannes Schindelin @ 2009-03-28 12:39 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: Santi Béjar, Jeff King, Nguydn Thái Ngdc, git
In-Reply-To: <200903281158.51012.markus.heidelberg@web.de>
Hi,
On Sat, 28 Mar 2009, Markus Heidelberg wrote:
> Johannes Schindelin, 27.03.2009:
> > Others who want to have a quick way to work safely with something they
> > might need to change, and might then want to use the full power of Git
> > to see what they changed. Without any need for a "nice" first commit.
>
> What's the difference between the first commit and the others? I don't
> see the reason, not to have a short description for it.
Maybe you can learn a new trick here:
$ tar xf /some/random/project.tar
$ git init
$ git add .
$ git commit -m initial
and now one of two work flows:
# get the thing to work properly, or add a new feature, or clean up...
$ git diff > diff.patch
# send the diff to the maintainer, without ever committing
or
# make a patch series, use rebase -i to clean up after it
# send the patch series to the maintainer of the random project
See? The initial commit does not matter at all.
I do this so often that it stops being funny having to type three
commands.
And having to edit a commit message I do not care about anyway everytime,
just to please you, would not make it any funnier ;-)
I'll just repeat one of my favorite mantras: optimize for the common case,
not for the uncommon case.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] Resolve double chmod() in move_temp_to_file()
From: Johan Herland @ 2009-03-28 11:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt
In-Reply-To: <7viqlu1837.fsf@gitster.siamese.dyndns.org>
On Saturday 28 March 2009, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > - if (chmod(filename, 0444) || adjust_shared_perm(filename))
> > + if (chmod(filename, get_shared_perm(0444)))
>
> Your get_shared_perm() will end up feeding 0444 to S_ISDIR(), which would
> most likely say "no" and cause real harm, but there is no guarantee that
> we won't start checking S_ISREG() or other things in get_shared_perm()
> later. I do not like this.
You are right.
> How about doing it this way instead?
>
> One thing to note is that we seem to have been passing what we read from
> st.st_mode, together with S_IFMT bits, to chmod(2); I do not think I've
> seen any breakage reports on exotic systems (glibc on Linux seems to
> ignore the higher bits), but from my reading of POSIX, I would not be
> surprised if somebody's chmod(2) returned EINVAL.
Agreed.
> -- >8 --
> set_shared_perm(): sometimes we know what the final mode bits should look
> like
>
> adjust_shared_perm() first obtains the mode bits from lstat(2), expecting
> to find what the result of applying user's umask is, and then tweaked it
s/tweaked/tweaks/
> as necessary. When the file to be adjusted is created with mkstemp(3),
> however, the mode thusly obtained does not have anything to do with
> usre's umask, and we would need to start from 0444 in such a case and
s/usre/user/
> there is no point running lstat(2) for such a path.
>
> This introduces a new API set_shared_perm() to bypass the lstat(2) and
> instead force setting the mode bits to the desired value directly.
> adjust_shared_perm() becomes a thin wrapper to the function.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
[...]
> diff --git a/sha1_file.c b/sha1_file.c
> index 8869488..5bfc36c 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -2263,7 +2263,7 @@ int move_temp_to_file(const char *tmpfile, const
> char *filename) *
> * The same holds for FAT formatted media.
> *
> - * When this succeeds, we just return 0. We have nothing
> + * When this succeeds, we just return; we have nothing
Small nit: This belongs in the previous patch, doesn't it?
All in all, this looks very good. Please drop my second patch, and use this
instead.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH 1/2] init: support --import to add all files and commit right after init
From: Markus Heidelberg @ 2009-03-28 10:58 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Santi Béjar, Jeff King, Nguydn Thái Ngdc, git
In-Reply-To: <alpine.DEB.1.00.0903270259470.10279@pacific.mpi-cbg.de>
Johannes Schindelin, 27.03.2009:
> Others who want to have a quick way to work safely with something they
> might need to change, and might then want to use the full power of Git to
> see what they changed. Without any need for a "nice" first commit.
What's the difference between the first commit and the others? I don't
see the reason, not to have a short description for it.
Markus
^ permalink raw reply
* Re: [PATCH 1/2] Move chmod(foo, 0444) into move_temp_to_file()
From: Johan Herland @ 2009-03-28 10:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt
In-Reply-To: <7vskky18ds.fsf@gitster.siamese.dyndns.org>
On Saturday 28 March 2009, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > When writing out a loose object or a pack (index), move_temp_to_file()
> > is called to finalize the resulting file. These files (loose files and
> > packs) should all have permission mode 0444 (modulo
> > adjust_shared_perm()). Therefore, instead of doing chmod(foo, 0444)
> > explicitly from each callsite (or even forgetting to chmod() at all),
> > do the chmod() call from within move_temp_to_file().
>
> I think you would need this on top.
Agreed.
Thanks,
..Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: demerphq @ 2009-03-28 10:33 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Michael J Gruber, git
In-Reply-To: <49CCE72E.20081.258EE61F@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
2009/3/27 Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>:
> On 27 Mar 2009 at 13:49, Michael J Gruber wrote:
>
>> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
>
> [...]
>
>> Keyword substitution and cvs/svn style version numbers are independent
>> issues. The sha1 describes a commit uniquely, one could use that as a
>> keyword.
>
> However version numbers and time stamps have the property of being at least
> partially ordered in respect of "newer/older". That property does not hold for
> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft
> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft
> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)
The problem here is that in some "version control" systems the concept
of "release version" has been conflated with "version control system
revision number".
They arent the same thing, never were, and conflating the two only
caused and causes trouble.
A "release version" is a *tag*, always has been or should have been
really, and in git is in fact.
Cheers,
yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ 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