* [StGit PATCH] New test: "stg diff"
From: Karl Hasselström @ 2007-10-09 4:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20071008153450.GA12247@diana.vm.bytemark.co.uk>
A simple test to make sure that we can run "stg diff" without
arguments, just to list local changes.
Note that two subtests currently fail; these are due to plain "stg
diff" failing on a branch where "stg init" hasn't been run, which is
plainly a bug.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
On 2007-10-08 17:34:50 +0200, Karl Hasselström wrote:
> So, we don't have a single test that tries to run "stg diff". Duh.
t/t2400-diff.sh | 37 +++++++++++++++++++++++++++++++++++++
1 files changed, 37 insertions(+), 0 deletions(-)
create mode 100755 t/t2400-diff.sh
diff --git a/t/t2400-diff.sh b/t/t2400-diff.sh
new file mode 100755
index 0000000..6d9ed98
--- /dev/null
+++ b/t/t2400-diff.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+
+test_description='Run "stg diff"'
+
+. ./test-lib.sh
+
+test_expect_failure 'Diff with no StGit data' '
+ stg diff
+'
+
+test_expect_success 'Make some local changes' '
+ echo foo >> foo.txt &&
+ git add foo.txt
+'
+
+test_expect_failure 'Diff with some local changes' '
+ stg diff
+'
+
+test_expect_success 'Initialize StGit stuff' '
+ stg init &&
+ stg new foo -m foo
+'
+
+test_expect_success 'Diff with some local changes' '
+ stg diff
+'
+
+test_expect_success 'Refresh patch' '
+ stg refresh
+'
+
+test_expect_success 'Diff with no local changes' '
+ stg diff
+'
+
+test_done
^ permalink raw reply related
* Re: git push (mis ?)behavior
From: Jan Hudec @ 2007-10-09 5:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, Pierre Habouzit, git
In-Reply-To: <7vodfnqndc.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]
On Fri, Sep 28, 2007 at 00:07:27 -0700, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
> > When "remote.<name>.push" is set I'd expect "git push" to
> > choose only the 'right' remote.<name>.push lines, that is
> > the lines that have the current branch as the local ref.
I would like this for another reason and maybe in slightly different way.
Basically I would have configured something along the lines:
[remote "origin"]
push = refs/heads/*:refs/heads/jahu/*
and would want to choose, via option, whether I want to push all the branches
or just the current one, but in any case with the renaming specified.
The idea behind this is to have a shared repository, but not shared branches.
Everybody would have a subdirectory in refs/heads where he could push
anything that the others should see and than somebody else (either designated
integrator, or just anybody different) would do a quick review and merge it
into master.
Now I could of course push out everything, but usually I'd want to push
exactly the current branch, renaming it by the rule given, whether it already
existed in origin or not. Than there can be eg. a post-receive hook notifying
the integrator that there is something for review.
> That would break the existing setup so it would not fly as a
> default, although it could be added as an option.
We can have an option and/or we can have some new parameter in .git/config.
Maybe:
push = refs/heads/*:refs/heads/jahu/*
would mean to push always (ie. everything under refs/heads) and eg.:
push = !refs/heads/*:refs/heads/jahu/*
would mean to push just current branch if it matches. Mixed setups would be
possible:
push = refs/heads/*:refs/heads/jahu/* !master:master !next:next
would mean push everything to jahu/ and if current is master, push it to
master, or if current is next, push it to next.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [StGit PATCH 6/6] Let some commands work with detached HEAD
From: Karl Hasselström @ 2007-10-09 5:12 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20071008153450.GA12247@diana.vm.bytemark.co.uk>
On 2007-10-08 17:34:50 +0200, Karl Hasselström wrote:
> This hunk shouldn't be here, since diff does use crt_series. (The
> commit message also has to be modified accordingly.)
I've fixed the patch and pushed it out, along with the two new ones.
For good measure, I also demoted it from safe to experimental.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Johannes Sixt @ 2007-10-09 6:10 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Peter Karlsson, git
In-Reply-To: <8c5c35580710081259j6d7e8587r546d4c35d42a67a6@mail.gmail.com>
Lars Hjemli schrieb:
> On 10/8/07, Peter Karlsson <peter@softwolves.pp.se> wrote:
>> $ git var GIT_COMMITTER_IDENT
>> usage: git-var [-l | <variable>]
>
> Does 'git var -l' work as expected? Also, could you try the latest
> git-package provided by the cygwin installer? If CRLF-handling was
> your problem, take a look at the description of core.autocrlf with
> 'git help config'.
>
> [This does look like an issue with running mingw.git under Cygwin.
> Johannes, is this even supposed to work?]
Sure, why not? Cygwin's settings as well as core.autocrlf should be
completely irrelevant. I've no clue what could be wrong here.
-- Hannes
^ permalink raw reply
* Re: [PATCH] mergetool: add support for ECMerge
From: Steffen Prohaska @ 2007-10-09 6:14 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20071008214451.GB31713@thunk.org>
On Oct 8, 2007, at 11:44 PM, Theodore Tso wrote:
> On Mon, Oct 08, 2007 at 11:22:41PM +0200, Steffen Prohaska wrote:
>> Add support for ECMerge available from
>> http://www.elliecomputing.com/Products/merge_overview.asp
>
> Hmm. A propietary merge tool. It's not that much code, so I
> guess....
>
> I note though that it claims on the web page that they are integrated
> with "most famous SCM's", but they don't include git. If we add this
> support, are they going to change their web page? :-)
You may even apply for a free (as beer) license if you contribute
to open source projects:
http://www.elliecomputing.com/Community/opensource.asp
I didn't try this, so I can't say how this works in practice.
> Also, ECmerge is supported on Linux, Solaris, MacOS X, and Windows.
> Which platforms have you tested on?
Windows. Haven't tested Unix systems yet.
> My guess is that if it works on
> Linux, it'll probably work on Solaris and MacOS, but is it a fair
> guess you haven't tested under Windows? Not that most Windows systems
> are going to be able to use git-mergetool since it's a bash script,
> unless they are using Cygwin or some such.
I work on the msysgit project and I'd like to have mergetool
available before I advertise git on Windows. It makes merging
so much easier ;)
Steffen
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Steffen Prohaska @ 2007-10-09 6:30 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20071008215729.GC31713@thunk.org>
On Oct 8, 2007, at 11:57 PM, Theodore Tso wrote:
> On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:
>> This commit adds a mechanism to provide absolute paths to the
>> commands called by 'git mergetool'. A path can be specified
>> in the configuation variable merge.<toolname>path.
>
> This patch doesn't work if the config file doesn't specify an explicit
> mergetool via merge.tool. The reason for that is this loop:
>
> for i in $merge_tool_candidates; do
> if test $i = emerge ; then
> cmd=emacs
> else
> cmd=$i
> fi
> if type $cmd > /dev/null 2>&1; then
> merge_tool=$i
> break
> fi
> done
>
> is only checking to see if $cmd is in the path; it's not looking up
> the merge.<toolname>path variable in this loop.
I didn't change the automatic detection. It should work as before.
That is it continues to assume that merge tools are in PATH.
Is you expectation that git-mergetool should also consider the
absolute paths provided in merge.<toolname>path?
When I wrote the patch I had in mind that people will set the
merge.tool explicitly if they provide an absolute path. Automatic
detection would only be used if nothing is configured. In this
case a tool must be in PATH or would not be found.
> I guess the other question is whether we would be better off simply
> telling the user to specify an absolute pathname in merge.tool, and
> then having git-mergetool strip off the directory path via basename,
> and then on window systems, stripping off the .EXE or .COM suffix, and
> then downcasing the name so that something like "C:\Program
> Files\ECMerge\ECMerge.exe" gets translated to "ecmerge". Would I be
> right in guessing that the reason why you used merge.<toolname>path
> approach was to avoid this messy headache?
Yes. The program to start ECMerge on Windows is called 'guimerge.exe'.
Hard to derive a sensible short name from this.
So I don't think that an automatic translation is an option. I prefer
to provide the absolute paths.
Absolute paths have another advantage. You can set several of them
and choose a tool on the command line. Maybe you have several tools
you want to try. Or you hacking with someone else who preferes a
different tool. Or you just want to give a demo. I see
merge.<toolname>path more as a database associating absolute paths
with the shortnames.
My mental model is as follows:
1) merge.tool selects the mechanism needed to call the tool, that is
command line arguments, how merge result is passed, ...
2) merge.<toolname>path provides additional information how to locate
the selected tool in the filesystem.
The two points are somewhat orthogonal. I'd not fuse them into one.
Steffen
^ permalink raw reply
* Hi dear
From: Angela @ 2007-10-08 20:05 UTC (permalink / raw)
To: git
Hey, my name isAngela. Im looking for a fiend and dying to meet you. Catch my photo and call me. My photo http://10ur.net/logo.JPG
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Steffen Prohaska @ 2007-10-09 6:42 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Theodore Ts'o, git
In-Reply-To: <20071008220025.GZ31659@planck.djpig.de>
On Oct 9, 2007, at 12:00 AM, Frank Lichtenheld wrote:
> On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:
>> This commit adds a mechanism to provide absolute paths to the
>> commands called by 'git mergetool'. A path can be specified
>> in the configuation variable merge.<toolname>path.
>
> Why not merge.<toolname>.path?
>
> This would it make easy to introduce new variables of the form
> merge.<toolname>.<var> later if needed. I also think it is more
> consistent with names of existing configuration variables.
> (think branch.<name>.<var> or remote.<name>.<var>)
Looks more beautiful on the command line but a bit more complex
in the config file. But I like the idea.
Maybe mergetool.<tool>.path is even a better choice? It clearly
indicate the relationship with mergetool. We could explain:
'The variable merge.tool = <tool> refers to a tool that can
be further specified in mergetool.<tool>.path.'
Steffen
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Peter Karlsson @ 2007-10-09 7:06 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <8c5c35580710081259j6d7e8587r546d4c35d42a67a6@mail.gmail.com>
HI!
> Does 'git var -l' work as expected?
Hmm, it also gives an error message:
$ git var -l
usage: git-var [-l | <variable>]
> Also, could you try the latest git-package provided by the cygwin
> installer? If CRLF-handling was your problem, take a look at the
> description of core.autocrlf with 'git help config'.
I tried it with Git 1.5.3.2 from Cygwin, and the problem I'm having is
not with the CRLF handling in the checked out files, but rather in the
repository database itself. Cloning a repository with Cygwin-Git
produced various errors about the object database being corrupt.
Mingw-Git does not produce those errors.
> [This does look like an issue with running mingw.git under Cygwin.
> Johannes, is this even supposed to work?]
I get the same error running mingw-git from a regular cmd.exe prompt,
so it doesn't seem to be related to Cygwin at all.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Recording merges after repo conversion
From: Peter Karlsson @ 2007-10-09 7:09 UTC (permalink / raw)
To: git
Hi!
I have a couple of repositories converted from CVS to Git using
parsecvs. Some are just converted, some I've continued to develop after
the conversion (and cloned a couple of times).
Since parsecvs gave me all the CVS branches, I would like to record the
merge points in the Git history, if possible. I have commited merges
with comments like "merged <branchname>", so I can probably find them
quite easily, and I do have the imported CVS branches available. Can I
record the merge information so git knows about them?
Is it safe to do so on a repository that has already been cloned (i.e,
will a later push/pull work)?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Benoit SIGOURE @ 2007-10-09 7:19 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710090807060.26773@ds9.cixit.se>
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
On Oct 9, 2007, at 9:09 AM, Peter Karlsson wrote:
> Hi!
>
> I have a couple of repositories converted from CVS to Git using
> parsecvs. Some are just converted, some I've continued to develop
> after
> the conversion (and cloned a couple of times).
>
> Since parsecvs gave me all the CVS branches, I would like to record
> the
> merge points in the Git history, if possible. I have commited merges
> with comments like "merged <branchname>", so I can probably find them
> quite easily, and I do have the imported CVS branches available. Can I
> record the merge information so git knows about them?
>
> Is it safe to do so on a repository that has already been cloned (i.e,
> will a later push/pull work)?
I think you can use grafts do achieve this.
From Documentation/repository-layout.txt:
info/grafts::
This file records fake commit ancestry information, to
pretend the set of parents a commit has is different
from how the commit was actually created. One record
per line describes a commit and its fake parents by
listing their 40-byte hexadecimal object names separated
by a space and terminated by a newline.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Steffen Prohaska @ 2007-10-09 7:23 UTC (permalink / raw)
To: Jan Hudec; +Cc: Junio C Hamano, Pierre Habouzit, git
In-Reply-To: <20071009050533.GA2968@efreet.light.src>
On Oct 9, 2007, at 7:05 AM, Jan Hudec wrote:
> On Fri, Sep 28, 2007 at 00:07:27 -0700, Junio C Hamano wrote:
>> Steffen Prohaska <prohaska@zib.de> writes:
>>
>>> When "remote.<name>.push" is set I'd expect "git push" to
>>> choose only the 'right' remote.<name>.push lines, that is
>>> the lines that have the current branch as the local ref.
>
> I would like this for another reason and maybe in slightly
> different way.
> Basically I would have configured something along the lines:
> [remote "origin"]
> push = refs/heads/*:refs/heads/jahu/*
> and would want to choose, via option, whether I want to push all
> the branches
> or just the current one, but in any case with the renaming specified.
>
> The idea behind this is to have a shared repository, but not shared
> branches.
> Everybody would have a subdirectory in refs/heads where he could push
> anything that the others should see and than somebody else (either
> designated
> integrator, or just anybody different) would do a quick review and
> merge it
> into master.
>
> Now I could of course push out everything, but usually I'd want to
> push
> exactly the current branch, renaming it by the rule given, whether
> it already
> existed in origin or not. Than there can be eg. a post-receive hook
> notifying
> the integrator that there is something for review.
I had a similar scenario in mind. So a more general question is the
following:
Git well supports the clone from read-only and push to private repo
scheme.
In this case all repositories you're pushing to are by definition _your_
repositories. The only question left is, which subset of your
branches are
pushed. But there's no need for renaming during push.
Now the question is, what is a sensible workflow on a shared repository?
One option is to use some kind of private 'namespace' scheme. For
example
developers should push their topics to a branch prefixed with their
name,
or to a 'subdirectory' ref/heads/needsreview/*.
This workflow may require to 'rename' branches during push. So how
can this
be supported by git? Supporting only renames that add a prefix, as
suggested
by Jan, may be reasonable restriction.
Steffen
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Johannes Sixt @ 2007-10-09 7:36 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710090800220.26773@ds9.cixit.se>
Peter Karlsson schrieb:
> I get the same error running mingw-git from a regular cmd.exe prompt,
> so it doesn't seem to be related to Cygwin at all.
What if you run 'git var -l' outside a repository? From CMD?
Have you tried 'git-var -l' (note the dash)? From CMD?
Are you sure you have only one version of git in the PATH?
What's in your .git/config?
-- Hannes
^ permalink raw reply
* 'git diff' in rebase--interactive
From: Johannes Sixt @ 2007-10-09 8:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
I wonder for what reason rebase--interactive generates a patch using
'git diff' in the make_patch function. Is this an artefact?
I'd like to get rid of this use of 'git diff' because it invokes external
diff drivers, which is totally unwanted if the driver is interactive - like
the 'windiff' thing that I posted a week ago.
-- Hannes
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Peter Karlsson @ 2007-10-09 8:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <470B2F7E.4080308@viscovery.net>
Hi!
> What if you run 'git var -l' outside a repository? From CMD?
> Have you tried 'git-var -l' (note the dash)? From CMD?
C:\Program Files\Git\bin>git var -l
usage: git-var [-l | <variable>]
C:\Program Files\Git\bin>git-var -l
fatal: Not a git repository
C:\Program Files\Git\bin>git --version
git version 1.5.3.mingw.1
> Are you sure you have only one version of git in the PATH?
Yes.
> What's in your .git/config?
This is the .git/config file for one of the repositories where it
fails:
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = false
pager = less -x3 -r
[instaweb]
local = true
httpd = c:/cygwin/usr/sbin/lighttpd.exe -f
port = 4321
browser = c:/progra~1/opera/opera.exe
modulepath = c:/cygwin/usr/lib/apache
[diff]
renames = copies
external = C:/Program Files/tkdiff/tkdiff.exe
[user]
name = Peter Karlsson
email = peter.karlsson@tandbergdata.com
This is my global $HOME/.gitconfig:
[user]
name = Peter Karlsson
email = peter@softwolves.pp.se
[core]
editor = c:/cygwin/bin/joe.exe
pager = less -x3 -r
[color]
[color]
pager = true
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Johannes Sixt @ 2007-10-09 9:03 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710090953240.26773@ds9.cixit.se>
Peter Karlsson schrieb:
> C:\Program Files\Git\bin>git var -l
> usage: git-var [-l | <variable>]
>
> C:\Program Files\Git\bin>git-var -l
> fatal: Not a git repository
>
> C:\Program Files\Git\bin>git --version
> git version 1.5.3.mingw.1
For the time being, install this beast in a path without blanks.
This needs fixing, appearently. :(
-- Hannes
^ permalink raw reply
* Two minor glitches in git-gui
From: Michele Ballabio @ 2007-10-09 9:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
On Linux:
1. run git-gui
2. open edit->options dialog box
3. click on "select font". It will open the "choose font" box.
4. click on "options" box to give it focus.
5. return to the "choose font" box and try to choose a font.
At this point, the "choose font" box won't react to my actions.
The workaround is to iconify the "select font" dialog box and
then restore it. Can someone reproduce this?
I think I've seen a similar behaviour before, on git-gui's
about window, but I'm not sure (it doesn't trigger anymore).
The other problem is that it is possible to open the same
"choose font" box many times (one is enough :).
^ permalink raw reply
* Problem with git-cvsimport
From: Thomas Pasch @ 2007-10-09 9:25 UTC (permalink / raw)
To: git
Hello,
using git-cvsimport (1.5.3.4), it dies with
Update
guidance-common/src/java/com/jentro/manager/guidance/common/servlet/IconServlet.java:
2104 bytes
Tree ID 01cb84cbee2e70a712459be6601b993603eed5bd
Parent ID dcd8dc76f4638d1994165070c9813202992d546a
Committed patch 3775 (bmw +0000 2004-10-14 11:10:43)
Commit ID 53c68066f71651b057884e1101cda3967070724d
Fetching
guidance-common/src/java/com/jentro/manager/guidance/common/serverapi/GuidanceException.java
v 1.14.4.2
Update
guidance-common/src/java/com/jentro/manager/guidance/common/serverapi/GuidanceException.java:
3718 bytes
Tree ID 886268190ac2cb28b5f1e6cdb309054bcb8fa38e
Parent ID 53c68066f71651b057884e1101cda3967070724d
Merge parent branch: master
fatal: Not a valid object name master
Use of uninitialized value in chomp at /usr/bin/git-cvsimport line 766.
Use of uninitialized value in pattern match (m//) at
/usr/bin/git-cvsimport line 527.
Use of uninitialized value in concatenation (.) or string at
/usr/bin/git-cvsimport line 767.
Cannot get commit id ():
What can I do to avoid this problem?
Cheers,
Thomas
^ permalink raw reply
* [PATCH] Fixed crash in fetching remote tags when there is not tags.
From: Väinö Järvelä @ 2007-10-09 8:51 UTC (permalink / raw)
To: git; +Cc: gitster, Väinö Järvelä
In-Reply-To: <1191919868-4963-1-git-send-email-v@pp.inet.fi>
Signed-off-by: Väinö Järvelä <v@pp.inet.fi>
---
remote.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index e7d735b..5e92378 100644
--- a/remote.c
+++ b/remote.c
@@ -537,6 +537,8 @@ static int count_refspec_match(const char *pattern,
static void tail_link_ref(struct ref *ref, struct ref ***tail)
{
+ if (!ref) return;
+
**tail = ref;
while (ref->next)
ref = ref->next;
--
1.5.3.4.1156.g5407-dirty
^ permalink raw reply related
* [PATCH] Added a test for fetching remote tags when there is not tags.
From: Väinö Järvelä @ 2007-10-09 8:51 UTC (permalink / raw)
To: git; +Cc: gitster, Väinö Järvelä
When a user runs "git fetch -t", git crashes when it doesn't find any
tags on the remote repository.
Signed-off-by: Väinö Järvelä <v@pp.inet.fi>
---
t/t5510-fetch.sh | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 73a4e3c..40ebf2e 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -67,6 +67,18 @@ test_expect_success "fetch test for-merge" '
cut -f -2 .git/FETCH_HEAD >actual &&
diff expected actual'
+test_expect_success 'fetch tags when there is no tags' '
+
+ cd "$D" &&
+
+ mkdir notags &&
+ cd notags &&
+ git init &&
+
+ git fetch -t ..
+
+'
+
test_expect_success 'fetch following tags' '
cd "$D" &&
--
1.5.3.4.1156.g5407-dirty
^ permalink raw reply related
* Re: git-http-push / webDAV
From: Thomas Pasch @ 2007-10-09 9:37 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <47022857.806@jentro.com>
Dear Eygene,
I tried all this on a Gentoo x86_64 machine. No problems!
Git on http/webDAV is just working fine.
I also retried all this on a SuSE 10.3 system. Same
problems as before. Thus it could have to do with
the (general) configuration of the SuSE system.
I still feel that the behaviour of git-push /
git-http-push is *not* approbiate. It should
indicate a problem if it was not able to upload
a new object to the remote server. Just saying
>>> sending 3 objects
>>> done
instead of indicating a problem is not what a
user expects. This particulary true if the
objects are not created on the server as it
seems to be in my case.
Cheers,
Thomas
Thomas Pasch wrote:
> Dear Eygene,
>
> I used a rather small test repo with only 2 or 3
> commits.
>
> The last tests I did with the a (current) git repo clone:
>
>> git clone --bare git://git.kernel.org/pub/scm/git/git.git
>
> e147e54b14828fa2e88e88907e0ca4dc3d694448 has indeed *not*
> found its way into the http push repo. For me it looks
> like that the push *first* updates refs/heads/master
> (successfully) but fails to transfer the object itself.
>
> Perhaps it would be more graceful that the object is
> transfered *first* and then the remote tip is updated...
>
> What version of git do you use?
>
> Cheers,
>
> Thomas
>
> Eygene Ryabinkin wrote:
>> Thomas,
>>
>> Tue, Oct 02, 2007 at 11:57:10AM +0200, Thomas Pasch wrote:
>>> well, *somewhat* better with the trailing slash:
>>>
>>>> echo "modified" >>grep.c
>>>> git commit -a
>>> Created commit e147e54: mod
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>> git push -v
>>> Pushing to http://test@x.x.x.x/git/git.git/
>>> Fetching remote heads...
>>> refs/
>>> refs/heads/
>>> refs/tags/
>>> updating 'refs/heads/master'
>>> from 34c6dbdef439f7cd93d3fe22493a3c1496ce96f7
>>> to e147e54b14828fa2e88e88907e0ca4dc3d694448
>>> sending 3 objects
>>> done
>>> Updating remote server info
>>>
>>> There's no more error message.
>> OK, that's fine: the previous error was tied to the fact that
>> when you're getting /git/git.git from the Web-server, it notices
>> that it is a directory and redirects you to the /git/git.git/.
>> But (IIRC) curl does not follow such redirections.
>>
>>> However, push has still
>>> not worked. If I try to check out the new HEAD:
>>>
>>>> git clone http://test@x.x.x.x/git/git.git/
>>> Initialized empty Git repository in /home/tpasch/tmp/git/.git/
>>> Getting alternates list for http://test@x.x.x.x/git/git.git
>>> Getting pack list for http://test@x.x.x.x/git/git.git
>>> Getting index for pack 563e2090185692c7d765775569a0ce986840fd17
>>> Getting pack 563e2090185692c7d765775569a0ce986840fd17
>>> which contains 3af9d3e08da868c3a7687ab38d72f4296a99005d
>>> [...]
>>> walk 24778e335a6450e34257a311d0bf4a12bdb3006c
>>> walk 19b2860cba5742ab31fd682b80fefefac19be141
>>> walk bf0c6e839c692142784caf07b523cd69442e57a5
>>> walk e497ea2a9b6c378f01d092c210af20cbee762475
>>> walk 8bc9a0c769ac1df7820f2dbf8f7b7d64835e3c68
>>> walk e83c5163316f89bfbde7d9ab23ca2e25604af290
>>> Getting alternates list for http://test@x.x.x.x/git/git.git
>>> Getting pack list for http://test@x.x.x.x/git/git.git
>>> error: Unable to find e147e54b14828fa2e88e88907e0ca4dc3d694448 under
>>> http://test@x.x.x.x/git/git.git
>>> Cannot obtain needed object e147e54b14828fa2e88e88907e0ca4dc3d694448
>> OK, I will try to do this on my server with 2.2.6. How big
>> is your repository? Both size and commit number.
>>
>> Thanks.
> -
> 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
--
Mit freundlichen Grüßen / Kind regards
Thomas Pasch
--------------------------------------------------------------------
Jentro Technologies GmbH
Thomas Pasch
Entwicklung
--------------------------------------------------------------------
Rosenheimer Strasse 145e, D-81671 Munich, Germany
N 48°07'19", E 11°36'18"
http://www.jentro.com
Managing Directors: Dr. Hans-Hendrik Puvogel, Erno Hempel
Trade register Munich HRB 148653
--------------------------------------------------------------------
Tel. +49 89 189 169 80
Fax +49 89 189 169 99
thomas.pasch@jentro.com
--------------------------------------------------------------------
NOTICE: The information contained in this e-mail is confidential or
may otherwise be legally privileged. It is intended for the named
recipient only. If you have received it in error, please notify us
immediately by reply or by calling the telephone number above and
delete this message and all its attachments without any use or
further distribution of its contents. Please note that any
unauthorised review, copying, disclosing or otherwise making use of
the information is strictly prohibited. Thank you.
--------------------------------------------------------------------
^ permalink raw reply
* Re: confused about a conflict during octopus merging
From: martin f krafft @ 2007-10-09 9:47 UTC (permalink / raw)
To: git discussion list; +Cc: Linus Torvalds
In-Reply-To: <alpine.LFD.0.999.0710081812200.4964@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]
Thanks, Linus, for taking your time to answer me. I truly appreciate
it.
also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.10.09.0221 +0100]:
> So when the octopus merge starts merging in "master" into the
> "merger" branch, it will *not* just fast-forward the branch to
> "master". Instead, if will generate a new tree that is basically
> the merged state: but that new tree is *not* the same as the
> master commit, it's literally a merge of the two branches - which
> in practice means that it has the same *content* as master, but
> it's not at that commit.
Okay, this makes perfect sense.
> And so now we have a half-way done octopus merge, with the first
> branch added. Now it merges in the second branch ("second"), and
> it *still* has the merge base being the original merge base,
> namely "merger".
>
> And from that standpoint, it really *is* a conflict.
I would have to agree with you: this is pretty exactly what's going
on.
Now, I think Git could do better though. Fast-forwarding
octopus merges, as you suggest, is one possible enhancement, but is
that the solution to my problem? Yes, but could we do better?
Couldn't Git just ignore any commit it has already seen in this
octopus merge? I think this is perfectly okay in terms of the
resulting ancestry, it's really all about applying a commit to the
worktree or not.
Recall the original tree:
x -- master: d2
| x -- second: b
|/
x d1
|
x -- merger: a
Now after merging master, the tree is at the same state as it is at
the tip of master. The asterisk denotes that the commit is half-way
done:
x c* (a+d1+d2)
|\
| x -- master: d2
| | x -- second: b
| |/
| x d1
|/
x a
Next, we merge second to create c2
x_ c2* ((a+d1+d2)+(d1+b))
|\ \
| | |
| x-|- master: d2
| | |
| | x -- second: b
| |/
| x d1
|/
x a
(yay ASCII art!)
At this point, the conflict happens, when Git tries to re-apply d1
to the work tree. But since d1 is already in the ancestry of the
node into which we are merging, couldn't it just skip applying the
commit to the worktree?
x_ c (a+d1+d2+b)
|\ \
| | |
| x-|- master: d2
| | |
| | x -- second: b
| |/
| x d1
|/
x a
If it does, then I think ordering of merges for an octopus becomes
relevant, but I'd say that's already the case.
And I guess this is identical to fast-forwarding the branches...
just seems like approaching it from another angle to me.
> If you think of octopus merges as a really stupid thing where git
> will mindlessly do a three-way merge based on the *current* state
> with all the branches you name, then you get the current octopus
> merge. You just expected it to be smarter than it is, probably
> because you compare it to the *real* merge.
No, Git just raised the bar for expectations half-way up to the
moon In other words: you spoiled me so far; now I won't settle for
less than perfection. :)
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"however jewel-like the good will may be in its own right, there is
a morally significant difference between rescuing someone from
a burning building and dropping him from a twelfth-storey window
while trying to rescue him."
-- thomas nagel
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] rev-list: implement --bisect-all
From: Frank Lichtenheld @ 2007-10-09 10:04 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, Johannes Schindelin, git
In-Reply-To: <20071009062511.fb6f6222.chriscool@tuxfamily.org>
On Tue, Oct 09, 2007 at 06:25:11AM +0200, Christian Couder wrote:
> This is Junio's patch with some stuff to make --bisect-all
> compatible with --bisect-vars.
>
> This option makes it possible to see all the potential
> bisection points. The best ones are displayed first.
The whole series is missing patches for the manual pages.
Just saying.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* possible bug in using local branches
From: Natanael Copa @ 2007-10-09 10:11 UTC (permalink / raw)
To: git
Hi,
I think I might have found a bug in git, but I'm not sure if I am
misunderstanding the way local branches is supposed to work. I will
describe all teh steps I am doing. Please let me know if I'm doing
something wrong.
It seems that when committing changes to one branch, one file is
modified across the branches. (all branches ge the modified file)
The source files used are those:
http://distfiles.gentoo.org/distfiles/linux-2.6.22.tar.bz2
http://distfiles.gentoo.org/distfiles/genpatches-2.6.22-9.base.tar.bz2
http://people.linux-vserver.org/~harry/patch-2.6.22.6-vs2.2.0.3-grsec2.1.11-20070905.diff
First unpack the linux-2.6.22.tar.bz2 archive, genpatches archive and
add linux kernel to a local repository.
$ tar -jxf linux-2.6.22.tar.bz2
$ tar -jxf genpatches-2.6.22-9.base.tar.bz2
$ cd linux-2.6.22
$ git-init
Initialized empty Git repository in .git/
$ git-add .
$ git commit -m 'vanilla 2.6.22'
...
create mode 100644 usr/Makefile
create mode 100644 usr/gen_init_cpio.c
create mode 100644 usr/initramfs_data.S
Apply the genpatches to get kernel up to 2.6.22.9
$ ls ../2.6.22/100*
../2.6.22/1000_linux-2.6.22.1.patch ../2.6.22/1005_linux-2.6.22.6.patch
../2.6.22/1001_linux-2.6.22.2.patch ../2.6.22/1006_linux-2.6.22.7.patch
../2.6.22/1002_linux-2.6.22.3.patch ../2.6.22/1007_linux-2.6.22.8.patch
../2.6.22/1003_linux-2.6.22.4.patch ../2.6.22/1008_linux-2.6.22.9.patch
../2.6.22/1004_linux-2.6.22.5.patch
$ for i in ../2.6.22/100*; do patch -p1 < $i ; done
...
patching file net/ipv6/raw.c
patching file net/sunrpc/svcsock.c
patching file scripts/kconfig/conf.c
Commit those changes to git repo.
$ git-commit -a -m'vanilla 2.6.22.9'
Created commit a374b11: vanilla 2.6.22.9
217 files changed, 1748 insertions(+), 863 deletions(-)
delete mode 100644 arch/i386/kernel/legacy_serial.c
We want merge the gentoo patches with the vserver/grsecurity patch so we
create 2 branches: vsgrsec-orig and genpatches.
$ git-branch vsgrsec-orig
$ git-branch genpatches
We switch to the vsgrsec-orig branch:
$ git-checkout vsgrsec-orig
Switched to branch "vsgrsec-orig"
$ git-branch
genpatches
master
* vsgrsec-orig
Before we commit any patch, we verify that we dont have any gresecurity
related stuff in there, just to be sure. We check the file that I have
had problems with.
$ grep PAX arch/i386/kernel/vmlinux.lds.S
Its verified clean. Just to be sure, verify the other branches as well.
$ git-checkout genpatches
Switched to branch "genpatches"
$ grep PAX arch/i386/kernel/vmlinux.lds.S
$ git-checkout master
Switched to branch "master"
$ grep PAX arch/i386/kernel/vmlinux.lds.S
Ok, its clean (why wouldnt it?), lets switch back to vsgrsec-orig and
apply the vserver/grsec patch.
$ git-checkout vsgrsec-orig
Switched to branch "vsgrsec-orig"
$ patch -p1 < ../patch-2.6.22.6-vs2.2.0.3-grsec2.1.11-20070905.diff
...
patching file sound/pci/ens1370.c
patching file sound/pci/intel8x0.c
patching file sound/pci/intel8x0m.c
There are one reject (due to the patch was made for 2.6.22.6), lets
merge it manually.
$ find -name '*.rej'
./fs/locks.c.rej
$ cat ./fs/locks.c.rej
***************
*** 787,792 ****
goto out;
locks_copy_lock(new_fl, request);
locks_insert_lock(&inode->i_flock, new_fl);
new_fl = NULL;
error = 0;
--- 806,812 ----
goto out;
locks_copy_lock(new_fl, request);
locks_insert_lock(&inode->i_flock, new_fl);
+ vx_locks_inc(new_fl);
new_fl = NULL;
error = 0;
$ vim +809 ./fs/locks.c
Insert the missing "vx_locks_inc(new_fl);", save and exit. Remove the
reject file.
$ rm ./fs/locks.c.rej
Verify that the propblematic file is modified.
$ grep PAX arch/i386/kernel/vmlinux.lds.S
#ifdef CONFIG_PAX_KERNEXEC
Commit all the changes to the vsgrsec-orig branch.
$ git-branch
genpatches
master
* vsgrsec-orig
$ git-add .
$ git-commit -a -m'patch-2.6.22.6-vs2.2.0.3-grsec2.1.11-20070905.diff'
...
create mode 100644 mm/slab_vs.h
create mode 100644 net/ipv4/devinet.c.orig
create mode 100644 net/ipv4/netfilter/ipt_stealth.c
Lets diff the commits and check if git has recordend the
arch/i386/kernel/vmlinux.lds.S modification.
$ git-log | cat
commit 9f2718984a6bc32d6ac1eee69ee27811496269d5
Author: Natanael Copa <natanael.copa@gmail.com>
Date: Tue Oct 9 11:54:33 2007 +0200
patch-2.6.22.6-vs2.2.0.3-grsec2.1.11-20070905.diff
commit a374b11b6fb93de40c9d3cf0cad4ff1cd7261283
Author: Natanael Copa <natanael.copa@gmail.com>
Date: Tue Oct 9 11:31:57 2007 +0200
vanilla 2.6.22.9
commit 2a31a9171d62b1ae8ed41124b61e43f49e4efb0b
Author: Natanael Copa <natanael.copa@gmail.com>
Date: Tue Oct 9 11:27:55 2007 +0200
vanilla 2.6.22
$ git-diff -p a374b11b6fb93de40c9d3cf0cad4ff1cd7261283 \
| grep arch/i386/kernel/vmlinux.lds.S
(empty)
What? shouldn't git detect that? Well something has changed:
$ git-diff -p a374b11b6fb93de40c9d3cf0cad4ff1cd7261283 \
| wc -l
77138
Lets check the file again:
$ grep PAX arch/i386/kernel/vmlinux.lds.S
#ifdef CONFIG_PAX_KERNEXEC
Well file is modified. Lets checkout the other branches.
$ git-checkout master
Switched to branch "master"
$ grep PAX arch/i386/kernel/vmlinux.lds.S
#ifdef CONFIG_PAX_KERNEXEC
What? That is not supposed to be there? the
arch/i386/kernel/vmlinux.lds.S file is modified on all branches.
Lets see what the log says about this branch:
$ git log | cat
commit a374b11b6fb93de40c9d3cf0cad4ff1cd7261283
Author: Natanael Copa <natanael.copa@gmail.com>
Date: Tue Oct 9 11:31:57 2007 +0200
vanilla 2.6.22.9
commit 2a31a9171d62b1ae8ed41124b61e43f49e4efb0b
Author: Natanael Copa <natanael.copa@gmail.com>
Date: Tue Oct 9 11:27:55 2007 +0200
vanilla 2.6.22
Well, nothing about the vserver/grsec patch there.
$ git-status
# On branch master
nothing to commit (working directory clean)
Lets make a diff between branches.
$ git-diff master vsgrsec-orig | wc -l
77138
Sure, something has changed. But is the vmlinux.lds.S changed?
$ git-diff master vsgrsec-orig | grep arch/i386/kernel/vmlinux.lds.S
(empty)
nope! Same thing happens in genpatches branch that I created earlier.
$ git checkout genpatches
Switched to branch "genpatches"
$ git-diff master | grep arch/i386/kernel/vmlinux.lds.S
$ grep PAX arch/i386/kernel/vmlinux.lds.S
#ifdef CONFIG_PAX_KERNEXEC
What is going on? Did I do something wrong or is this a bug?
I managed to duplicate this on my 64 bit gentoo ox and my 64 bit ubuntu
box.
$ git --version
git version 1.5.3.3
$ git --version
git version 1.5.2.5
-nc
^ permalink raw reply
* Re: bug? - git-checkout treeish paths ignores deleted files
From: Wincent Colaiuta @ 2007-10-09 10:20 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Git Mailing List
In-Reply-To: <470AF7F1.2010903@gmail.com>
El 9/10/2007, a las 5:39, Mark Levedahl escribió:
> I'm not convinced...
>
> "git checkout branch dir" should make dir have the same value it
> would get if I just did "git checkout branch". The latter command
> will ignore files only if they are untracked in *both* HEAD and
> branch. I fail to see why the path-limited version of git-checkout
> should give a different result on the part it is asked to affect
> than the non-path limited version. This is very inconsistent and
> I'm having a hard time understanding what workflow it will help.
I don't know the historical reasons for the difference but it's
explained in the second para of the man page:
When <paths> are given, this command does not switch branches. It
updates the named paths in the working tree from the index file
(i.e.
it runs git-checkout-index -f -u), or from a named commit.
So when you supply "." as a path it's not actually switching
branches. So that's why you see the different behaviour; it's
intentionally different. Like I said, I don't know the reasons why
but I imagine it's to make it easy to grab specific files from other
branches without actually switching.
Cheers,
Wincent
^ 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