* Re: [PATCH] config.txt: alphabetize configuration variable groups
From: Matt McCutchen @ 2008-11-24 20:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <492A579B.5000304@viscovery.net>
On Mon, 2008-11-24 at 08:28 +0100, Johannes Sixt wrote:
> Matt McCutchen schrieb:
> > @@ -963,6 +953,8 @@ man.<tool>.path::
> > Override the path for the given tool that may be used to
> > display help in the 'man' format. See linkgit:git-help[1].
> >
> > +include::merge-config.txt[]
> > +
> > merge.conflictstyle::
> > Specify the style in which conflicted hunks are written out to
> > working tree files upon merge. The default is "merge", which
>
> Here, the list is not in alphabetic order anymore.
After my change, the list is in alphabetical order by the first
component (before the first dot). I assume you're pointing out that I
haven't separated the merge.<driver> parameters from the non-<driver>
merge parameters.
The reason I left it that way was I thought there might be some reason
why merge.conflictstyle is in config.txt rather than merge-config.txt
(the difference being that it appears in "man git-config" but not
"man git-merge"), and to keep that arrangement while grouping together
the non-<driver> merge parameters, I would have to split
merge-config.txt into two separately included files.
I went back and looked at the commit (b5412484) that documented
merge.conflictstyle, and it appears that the placement in config.txt may
have been a mistake arising from the unsortedness of config.txt rather
than a conscious decision. Thus, I'll move that entry to
merge-config.txt for the better grouping. That does mean "man
git-merge" will contain two explanations of merge.conflictstyle (the
brief config-parameter one and the "HOW CONFLICTS ARE PRESENTED"
section), but I don't see that as a big problem.
> BTW, your commit message should emphasize the use-cases where an
> alphabetic order is a real benefit. Otherwise, this is just code churn.
I don't see alphabetization as a major benefit except that it might help
people add new parameters in the right place (case in point: the
addition of merge.conflictstyle). And I figured that the config
parameters might as well be in /some/ order. I'll state that in the
commit message.
Updated patch to follow.
Matt
^ permalink raw reply
* Re: Hello All and Seeking Information
From: Jakub Narebski @ 2008-11-24 18:22 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0811240828y61e7bfecka1cacdd37865a4e8@mail.gmail.com>
"Tim Visher" <tim.visher@gmail.com> writes:
> Hello Everyone,
>
> I'm new to the list so I figured I'd introduce myself instead of just
> wall-flowering... "Hello"... :)
>
> Anyway, I really like a lot of the concepts found in Git and the
> reported power and flexibility of it are very intriguing. However,
> there are some issues that I can't wrap my head around, such as how
> you can guarantee that all developers are working on the same
> code-base without a central repo. I would classify a lot of my issues
> as paradigm rather than technically related. I understand a lot of
> Git's underpinnings and the basic usage of it, I just can't wrap my
> head around the higher-order parts of it.
The idea behind Git repository format is content adressed filesystem,
which if I remember correctly was taken from Monotone (well, not
addressed by actual content, but SHA-1 cryptographic hash of
content+type). So if there is 134b8687c59e65ce06562ffb0e8be63ab7aa618b
object in some repository, it is the same object in all repositories,
even if it was created independently. That is one thing.
The other thing is that typical workflow calls for downloading changes
(fetching in git jargon) from some 'upstream' repository, the official
repository (one of official repositories) with code you are supposed
to base your changes upon.
Also easy to create branches, and very good support for merging (and
rebasing) makes it possible and easy to join (merge) lines of
development done independently from some older point of history. So
that even if you are not working on the same code-base I can
incorporate your changes, and you can incorporate mine.
>
> I've done some Googling and I can't find a good 'Introduction to
> Distributed SCM Concepts for Centralized SCM Developers' article yet.
> Ideally, this would be an article all about the high-level thought
> processes that go into utilizing Distributed SCM in a team environment
> where having a single canonical representation of your project that
> all developers are working off of is important.
See http://git.or.cz/gitwiki/GitDocumentation (and also main page of
this git wiki, Documentation mentioned on git homepage
(http://git.or.cz) including "Git User's Manual", and "The Git
Community Book" at http://book.git-scm.com
> P.S. Anyone want to tell me why the Git Mailing List was set-up
> monolithically rather than the typical git-dev, git-user, git-admin,
> git-x etc.? I don't plan on hacking on Git so having the Dev mail in
> the list is just noise for me. I'm sure other people think that too.
> Just wondering.
Because this Git is not so large project, and traffic on git mailing
list is not so large to support split? IIRC there was "Git for Human
Beings" aka git-users Google Group, but it doesn't seem to be there
any more. Also having common mailing list allow for better contact
between developers and git users (which hopefully would allow us to
avoid comon pitfalls with 'developers for developers' approach).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-svn and svnsync
From: Andriy Gapon @ 2008-11-24 17:33 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <492AE13D.5070102@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 2870 bytes --]
on 24/11/2008 19:15 Michael J Gruber said the following:
> Andriy Gapon venit, vidit, dixit 24.11.2008 13:56:
>> on 16/10/2008 11:07 Andriy Gapon said the following:
>>> I did the following:
>>> 1. mirror svn repository using svnsync
>>> 2. clone the mirror with git-svn --use-svnsync-props and some tweaking[*]
>>> 3. run git svn info in the clone
>>> 4. get error "Unable to determine upstream SVN information from working
>>> tree history"
>>>
>>> git svn log and git svn rebase do not work either.
>>> git log does work.
>>>
>>> I have git version 1.6.0.2 (from FreeBSD ports).
>>> [*] About the tweaking - I manually massaged config file to get the
>>> branches I was interested in, so .git/config is this:
>>> [core]
>>> repositoryformatversion = 0
>>> filemode = true
>>> bare = false
>>> logallrefupdates = true
>>> [svn-remote "svn"]
>>> useSvnsyncProps = 1
>>> url = file:///system/devel/svn/base
>>> fetch = head:refs/remotes/trunk
>>> fetch = stable/6:refs/remotes/stable_6
>>> fetch = stable/7:refs/remotes/stable_7
>>> fetch = releng/6.3:refs/remotes/releng_6_3
>>> fetch = releng/6.4:refs/remotes/releng_6_4
>>> fetch = releng/7.0:refs/remotes/releng_7_0
>>> fetch = release/6.3.0:refs/remotes/release_6_3_0
>>> fetch = release/7.0.0:refs/remotes/release_7_0_0
>>>
>>> This is .git/svn/.metadata:
>>> ; This file is used internally by git-svn
>>> ; You should not have to edit it
>>> [svn-remote "svn"]
>>> reposRoot = file:///system/devel/svn/base
>>> uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>>> svnsync-uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>>> svnsync-url = svn://svn.freebsd.org/base
>>>
>>> So you can see the original svn repository URL.
>>>
>>> git log reports svn info like the following:
>>> git-svn-id: svn://svn.freebsd.org/base/stable/7@183898
>>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>>>
>>> It seems that the problem is that the code in find_by_url() and/or
>>> read_all_remotes() subroutines (in git-svn.perl) are not aware of
>>> svnsync and do not realize an URL in logs and URL in svn-remote are
>>> different.
>>> BTW, I see that there is some special svm logic in read_all_remotes.
>>>
>>> Thank you very much for any help in advance.
>>>
>> Anyone?
>> I wonder if this is my local problem/misconfiguration or an issue with
>> git-svn.
>
> Same happens here, so it's a general issue ;)
>
> I think I encountered that before and ended up experimenting with
> git-svn cloning from a svnsync source until I found the final config,
> with which I git-svn cloned directly from upstream, so that I had to
> wait only twice.
I hacked together an ugly patch that replaces svm support with snvsync
support. This works for me, not sure if it will be useful in general.
--
Andriy Gapon
[-- Attachment #2: git-svn.patch --]
[-- Type: text/plain, Size: 1113 bytes --]
--- git-svn 2008-11-11 10:20:38.714620442 +0200
+++ git-svn 2008-11-07 17:10:49.245681213 +0200
@@ -1433,7 +1433,7 @@
sub read_all_remotes {
my $r = {};
my $use_svm_props = eval { command_oneline(qw/config --bool
- svn.useSvmProps/) };
+ svn.useSvnsyncProps/) };
$use_svm_props = $use_svm_props eq 'true' if $use_svm_props;
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
if (m!^(.+)\.fetch=\s*(.*)\s*:\s*(.+)\s*$!) {
@@ -1445,7 +1445,7 @@
$local_ref =~ s{^/}{};
$r->{$remote}->{fetch}->{$local_ref} = $remote_ref;
$r->{$remote}->{svm} = {} if $use_svm_props;
- } elsif (m!^(.+)\.usesvmprops=\s*(.*)\s*$!) {
+ } elsif (m!^(.+)\.usesvnsyncprops=\s*(.*)\s*$!) {
$r->{$1}->{svm} = {};
} elsif (m!^(.+)\.url=\s*(.*)\s*$!) {
$r->{$1}->{url} = $2;
@@ -1471,9 +1471,8 @@
my $section = "svn-remote.$_";
$svm = {
source => tmp_config('--get',
- "$section.svm-source"),
- replace => tmp_config('--get',
- "$section.svm-replace"),
+ "$section.svnsync-url"),
+ replace => '',
}
};
$r->{$_}->{svm} = $svm;
^ permalink raw reply
* Re: Not-quite-a-bug in pickaxe
From: Johannes Schindelin @ 2008-11-24 17:36 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: git, gitster
In-Reply-To: <237967ef0811240708t58d48c84ud0626ba3aaed47b6@mail.gmail.com>
Hi,
On Mon, 24 Nov 2008, Mikael Magnusson wrote:
> 2008/11/24 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > I do not know if I hit that behavior before,
>
> I'm pretty sure it has,
> http://thread.gmane.org/gmane.comp.version-control.git/100113/focus=100115
> (at least i think that's the same case?)
Ah, I finally got around to read Junio's reply. It did not stick back
then.
Thanks,
Dscho
^ permalink raw reply
* Re: git-svn and svnsync
From: Michael J Gruber @ 2008-11-24 17:15 UTC (permalink / raw)
To: Andriy Gapon; +Cc: git
In-Reply-To: <492AA464.5070404@icyb.net.ua>
Andriy Gapon venit, vidit, dixit 24.11.2008 13:56:
> on 16/10/2008 11:07 Andriy Gapon said the following:
>> I did the following:
>> 1. mirror svn repository using svnsync
>> 2. clone the mirror with git-svn --use-svnsync-props and some tweaking[*]
>> 3. run git svn info in the clone
>> 4. get error "Unable to determine upstream SVN information from working
>> tree history"
>>
>> git svn log and git svn rebase do not work either.
>> git log does work.
>>
>> I have git version 1.6.0.2 (from FreeBSD ports).
>> [*] About the tweaking - I manually massaged config file to get the
>> branches I was interested in, so .git/config is this:
>> [core]
>> repositoryformatversion = 0
>> filemode = true
>> bare = false
>> logallrefupdates = true
>> [svn-remote "svn"]
>> useSvnsyncProps = 1
>> url = file:///system/devel/svn/base
>> fetch = head:refs/remotes/trunk
>> fetch = stable/6:refs/remotes/stable_6
>> fetch = stable/7:refs/remotes/stable_7
>> fetch = releng/6.3:refs/remotes/releng_6_3
>> fetch = releng/6.4:refs/remotes/releng_6_4
>> fetch = releng/7.0:refs/remotes/releng_7_0
>> fetch = release/6.3.0:refs/remotes/release_6_3_0
>> fetch = release/7.0.0:refs/remotes/release_7_0_0
>>
>> This is .git/svn/.metadata:
>> ; This file is used internally by git-svn
>> ; You should not have to edit it
>> [svn-remote "svn"]
>> reposRoot = file:///system/devel/svn/base
>> uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> svnsync-uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> svnsync-url = svn://svn.freebsd.org/base
>>
>> So you can see the original svn repository URL.
>>
>> git log reports svn info like the following:
>> git-svn-id: svn://svn.freebsd.org/base/stable/7@183898
>> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>>
>> It seems that the problem is that the code in find_by_url() and/or
>> read_all_remotes() subroutines (in git-svn.perl) are not aware of
>> svnsync and do not realize an URL in logs and URL in svn-remote are
>> different.
>> BTW, I see that there is some special svm logic in read_all_remotes.
>>
>> Thank you very much for any help in advance.
>>
>
> Anyone?
> I wonder if this is my local problem/misconfiguration or an issue with
> git-svn.
Same happens here, so it's a general issue ;)
I think I encountered that before and ended up experimenting with
git-svn cloning from a svnsync source until I found the final config,
with which I git-svn cloned directly from upstream, so that I had to
wait only twice.
Michael
^ permalink raw reply
* Re: Hello All and Seeking Information
From: Christian MICHON @ 2008-11-24 16:39 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0811240828y61e7bfecka1cacdd37865a4e8@mail.gmail.com>
On Mon, Nov 24, 2008 at 5:28 PM, Tim Visher <tim.visher@gmail.com> wrote:
> Hello Everyone,
>
> I'm new to the list so I figured I'd introduce myself instead of just
> wall-flowering... "Hello"... :)
>
> Anyway, I really like a lot of the concepts found in Git and the
> reported power and flexibility of it are very intriguing. However,
> there are some issues that I can't wrap my head around, such as how
> you can guarantee that all developers are working on the same
> code-base without a central repo. I would classify a lot of my issues
> as paradigm rather than technically related. I understand a lot of
> Git's underpinnings and the basic usage of it, I just can't wrap my
> head around the higher-order parts of it.
>
> I've done some Googling and I can't find a good 'Introduction to
> Distributed SCM Concepts for Centralized SCM Developers' article yet.
> Ideally, this would be an article all about the high-level thought
> processes that go into utilizing Distributed SCM in a team environment
> where having a single canonical representation of your project that
> all developers are working off of is important.
>
http://git.or.cz/gitwiki/LinusTalk200705Transcript
but the video is obviously more fun
http://www.youtube.com/watch?v=4XpnKHJAok8
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: Hello All and Seeking Information
From: Bruce Stephens @ 2008-11-24 16:35 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0811240828y61e7bfecka1cacdd37865a4e8@mail.gmail.com>
"Tim Visher" <tim.visher@gmail.com> writes:
[...]
> However, there are some issues that I can't wrap my head around,
> such as how you can guarantee that all developers are working on the
> same code-base without a central repo.
You can't. That's the point.
If developers wish to use a central repository and always to work
based on that, then they can. But the tool doesn't enforce that.
<http://koweycode.blogspot.com/2008/11/iterative-commiting.html>
describes a common (IME) benefit.
[...]
^ permalink raw reply
* [RFC/PATCH v2] bisect: teach "skip" to accept special arguments like "A..B"
From: Christian Couder @ 2008-11-24 16:33 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Johannes Sixt; +Cc: git, H. Peter Anvin
The current "git bisect skip" syntax is "git bisect skip [<rev>...]"
so it's already possible to skip a range of revisions using
something like:
$ git bisect skip $(git rev-list A..B)
where A and B are the bounds of the range we want to skip.
This patch teaches "git bisect skip" to accept:
$ git bisect skip A..B
as an abbreviation for the former command.
This is done by checking each argument to see if it contains two
dots one after the other ('..'), and by expanding it using
"git rev-list" if that is the case.
Note that this patch will not make "git bisect skip" accept all
that "git rev-list" accepts, as things like "^A B" for exemple
will not work. But things like "A B..C D E F.. ..G H...I" should
work as expected.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
Change since last time: s/expend/expand/
I am still not sure if this patch is worth it because
this is a special case in many ways.
diff --git a/git-bisect.sh b/git-bisect.sh
index 0d0e278..6706bc1 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -191,6 +191,21 @@ check_expected_revs() {
done
}
+bisect_skip() {
+ all=''
+ for arg in "$@"
+ do
+ case "$arg" in
+ *..*)
+ revs=$(git rev-list "$arg") || die "Bad rev input: $arg" ;;
+ *)
+ revs="'$arg'" ;;
+ esac
+ all="$all $revs"
+ done
+ bisect_state 'skip' $all
+}
+
bisect_state() {
bisect_autostart
state=$1
@@ -630,8 +645,10 @@ case "$#" in
git bisect -h ;;
start)
bisect_start "$@" ;;
- bad|good|skip)
+ bad|good)
bisect_state "$cmd" "$@" ;;
+ skip)
+ bisect_skip "$@" ;;
next)
# Not sure we want "next" at the UI level anymore.
bisect_next "$@" ;;
--
1.6.0.4.617.g39d03
^ permalink raw reply related
* Hello All and Seeking Information
From: Tim Visher @ 2008-11-24 16:28 UTC (permalink / raw)
To: git
Hello Everyone,
I'm new to the list so I figured I'd introduce myself instead of just
wall-flowering... "Hello"... :)
Anyway, I really like a lot of the concepts found in Git and the
reported power and flexibility of it are very intriguing. However,
there are some issues that I can't wrap my head around, such as how
you can guarantee that all developers are working on the same
code-base without a central repo. I would classify a lot of my issues
as paradigm rather than technically related. I understand a lot of
Git's underpinnings and the basic usage of it, I just can't wrap my
head around the higher-order parts of it.
I've done some Googling and I can't find a good 'Introduction to
Distributed SCM Concepts for Centralized SCM Developers' article yet.
Ideally, this would be an article all about the high-level thought
processes that go into utilizing Distributed SCM in a team environment
where having a single canonical representation of your project that
all developers are working off of is important.
Anyway, looking forward to participating.
P.S. Anyone want to tell me why the Git Mailing List was set-up
monolithically rather than the typical git-dev, git-user, git-admin,
git-x etc.? I don't plan on hacking on Git so having the Dev mail in
the list is just noise for me. I'm sure other people think that too.
Just wondering.
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: gitsub{module,project}
From: Michael J Gruber @ 2008-11-24 16:01 UTC (permalink / raw)
Cc: Git Mailing List
In-Reply-To: <492ACE4E.1090506@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 24.11.2008 16:54:
> Dear all:
>
> Parts of git still use the term subproject rather then submodule. A
> simple grep/wc -l shows submodule as the winner by 10:1 or so. Are there
> any objections to consolidating that naming (in favour of submodule)?
...sorry, just to be clear: I only mean to change doc/error messages,
not the diff format. I guess that would mean running into a wall (and
bouncing back).
Michael
^ permalink raw reply
* gitsub{module,project}
From: Michael J Gruber @ 2008-11-24 15:54 UTC (permalink / raw)
To: Git Mailing List
Dear all:
Parts of git still use the term subproject rather then submodule. A
simple grep/wc -l shows submodule as the winner by 10:1 or so. Are there
any objections to consolidating that naming (in favour of submodule)?
Michael
^ permalink raw reply
* Re: How do I delete a git submodule?
From: Michael J Gruber @ 2008-11-24 15:51 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0811241537580.22925@ds9.cixit.se>
Peter Krefting venit, vidit, dixit 24.11.2008 15:44:
> Hi!
>
> I am trying to remove a submodule from a project, but can't figure out
> how to do it. With "modules/aldc" as a submodule:
>
> $ cat .gitmodules
> [submodule "modules/aldc"]
> path = modules/aldc
> url = [...cut...]
> [...more entries here...]
> $ git status
> [...cut...]
> nothing to commit (working directory clean)
>
> Starting from a clean set-up.
>
> $ git submodule rm modules/aldc
> -ff17d9e0e76d01e99d26aa16b28cf327c5abb48a modules/aldc
> $ git status
> [...cut...]
> nothing to commit (working directory clean)
>
> The obvious command didn't give any errors, but didn't do anything,
> either. (I notice that there is no mention of a "git submodule rm" on
> the git-submodule man page.)
>
> $ git rm modules/aldc
> rm 'modules/aldc'
> fatal: git rm: modules/aldc: Permission denied
> $ git status
> [...cut...]
> nothing to commit (working directory clean)
>
> Nope, that didn't work either.
>
> What am I missing?
The last line of git help/man on git submodule status:
"This command is the default command for git-submodule."
git submodule ignores the "rm" (because it doesn't know that command)
and does a "status" on modules/aldc.
OTOH, git rm refuses to do its thing, as you noticed. The brute force
method seems to work:
rm -Rf modules/aldc
#remove module from .gitmodules
#remove module from .git/config
git add -u
git commit -m "get thee hence, modules/aldc"
I edited the two config files manually, but this can be scripted.
git log -p shows a perfect diff including removal of the subproject
commit, so I think the result of the above is fine. I think I'll work on
a patch if nobody stops or beats me...
Cheers,
Michael
^ permalink raw reply
* Re: Best practices for maintaining a subversion mirror?
From: Peter Harris @ 2008-11-24 15:37 UTC (permalink / raw)
To: Oliver Charles; +Cc: git
In-Reply-To: <5641883d0811240255i21aef729ld202bd5a3211dad9@mail.gmail.com>
On Mon, Nov 24, 2008 at 5:55 AM, Oliver Charles wrote:
> This seems to be working nicely as a readonly interface, but when I
> clone this repository (git clone git://foo/repo.git) - served via
> git-daemon - I can't seem to get svn rebase to work on it, which means
> I can't dcommit my changes back to Subversion.
>
> Am I doing things generally the right way, or am I doing it completely
> wrong? :-) Any tips appreciated!
First, make sure you aren't using the --no-metadata flag. git svn
rebase needs that metadata to rebuild its index.
Second, a simple "git clone" will not set up the svn remotes; you have
to do that by hand. This is what I do when I clone my svn mirror:
mkdir project
cd project
git init
git remote add origin git://mirror/project
git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
git fetch
git svn init -Ttrunk svn://upstream/project
git config --add svn-remote.svn.fetch branches/foo:refs/remotes/foo
git config --add svn-remote.svn.fetch branches/bar:refs/remotes/bar
git reset --hard trunk
git svn rebase
Once you have it nailed down, you can put it into a script so all your
co-workers don't have to do that by hand too.
(Also, I quickly reset my cron job to run every five minutes; I found
an hour was way too long for my taste. YMMV, of course)
Peter Harris
^ permalink raw reply
* Re: [StGit PATCH] stgit.el: Show running commands
From: Karl Hasselström @ 2008-11-24 15:34 UTC (permalink / raw)
To: David Kågedal; +Cc: catalin.marinas, git
In-Reply-To: <20081124120136.9163.70947.stgit@krank>
Thanks, looks useful.
Sorry I haven't taken the time to apply & push out your patches. I'm
hoping it'll happen Real Soon Now(tm) ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Not-quite-a-bug in pickaxe
From: Mikael Magnusson @ 2008-11-24 15:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0811241238450.30769@pacific.mpi-cbg.de>
2008/11/24 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi people,
>
> I do not know if I hit that behavior before,
I'm pretty sure it has,
http://thread.gmane.org/gmane.comp.version-control.git/100113/focus=100115
(at least i think that's the same case?)
> but now it hit me big time:
> if a commit moves a certain string from one place to another, "git log
> -S<string>" does not pick up that commit. The code responsible for this
> is in diffcore-pickaxe.c:
>
> else if (!diff_unmodified_pair(p) &&
> contains(p->one, needle, len, regexp) !=
> contains(p->two, needle, len, regexp))
> has_changes++;
>
> Basically, the "contains()" method says how often the needle was found,
> and pickaxe just assumes that a move of a string is not interesting
> enough.
>
> Now, this behavior is probably intended, as searching files is much
> cheaper than generating the diffs between them, yet it is something you'll
> have to keep in mind when using "-S".
--
Mikael Magnusson
^ permalink raw reply
* How do I delete a git submodule?
From: Peter Krefting @ 2008-11-24 14:44 UTC (permalink / raw)
To: Git Mailing List
Hi!
I am trying to remove a submodule from a project, but can't figure out
how to do it. With "modules/aldc" as a submodule:
$ cat .gitmodules
[submodule "modules/aldc"]
path = modules/aldc
url = [...cut...]
[...more entries here...]
$ git status
[...cut...]
nothing to commit (working directory clean)
Starting from a clean set-up.
$ git submodule rm modules/aldc
-ff17d9e0e76d01e99d26aa16b28cf327c5abb48a modules/aldc
$ git status
[...cut...]
nothing to commit (working directory clean)
The obvious command didn't give any errors, but didn't do anything,
either. (I notice that there is no mention of a "git submodule rm" on
the git-submodule man page.)
$ git rm modules/aldc
rm 'modules/aldc'
fatal: git rm: modules/aldc: Permission denied
$ git status
[...cut...]
nothing to commit (working directory clean)
Nope, that didn't work either.
What am I missing?
$ git --version
git version 1.6.0.2.1172.ga5ed0
(This is Git-1.6.0.2-preview20080923 on Windows XP)
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Jon Smirl @ 2008-11-24 14:11 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <20081124111635.GA31986@diana.vm.bytemark.co.uk>
A useful future enhancement would be to adjust patches that insert
adjacent areas so that they can pass each other in a pop/pop
operation. The most common case of this being appends to end of file.
This would be a form of automatic conflict resolution. The pending
patch would be automatically corrected to resolve the adjacent insert
conflict. You might want a prompt asking if this was ok andt then
remember the answer so that question is not asked repeatedly.
It's a mechanism to say that multiple insertions at point X in the
original file don't matter in their order of insertion.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: git-svn and svnsync
From: Andriy Gapon @ 2008-11-24 12:56 UTC (permalink / raw)
To: git
In-Reply-To: <48F6F631.90709@icyb.net.ua>
on 16/10/2008 11:07 Andriy Gapon said the following:
>
> I did the following:
> 1. mirror svn repository using svnsync
> 2. clone the mirror with git-svn --use-svnsync-props and some tweaking[*]
> 3. run git svn info in the clone
> 4. get error "Unable to determine upstream SVN information from working
> tree history"
>
> git svn log and git svn rebase do not work either.
> git log does work.
>
> I have git version 1.6.0.2 (from FreeBSD ports).
> [*] About the tweaking - I manually massaged config file to get the
> branches I was interested in, so .git/config is this:
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [svn-remote "svn"]
> useSvnsyncProps = 1
> url = file:///system/devel/svn/base
> fetch = head:refs/remotes/trunk
> fetch = stable/6:refs/remotes/stable_6
> fetch = stable/7:refs/remotes/stable_7
> fetch = releng/6.3:refs/remotes/releng_6_3
> fetch = releng/6.4:refs/remotes/releng_6_4
> fetch = releng/7.0:refs/remotes/releng_7_0
> fetch = release/6.3.0:refs/remotes/release_6_3_0
> fetch = release/7.0.0:refs/remotes/release_7_0_0
>
> This is .git/svn/.metadata:
> ; This file is used internally by git-svn
> ; You should not have to edit it
> [svn-remote "svn"]
> reposRoot = file:///system/devel/svn/base
> uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> svnsync-uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> svnsync-url = svn://svn.freebsd.org/base
>
> So you can see the original svn repository URL.
>
> git log reports svn info like the following:
> git-svn-id: svn://svn.freebsd.org/base/stable/7@183898
> ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>
> It seems that the problem is that the code in find_by_url() and/or
> read_all_remotes() subroutines (in git-svn.perl) are not aware of
> svnsync and do not realize an URL in logs and URL in svn-remote are
> different.
> BTW, I see that there is some special svm logic in read_all_remotes.
>
> Thank you very much for any help in advance.
>
Anyone?
I wonder if this is my local problem/misconfiguration or an issue with
git-svn.
--
Andriy Gapon
^ permalink raw reply
* [StGit PATCH] stgit.el: Show running commands
From: David Kågedal @ 2008-11-24 12:01 UTC (permalink / raw)
To: kha, catalin.marinas; +Cc: git
---
contrib/stgit.el | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/contrib/stgit.el b/contrib/stgit.el
index 65af068..ec08a5b 100644
--- a/contrib/stgit.el
+++ b/contrib/stgit.el
@@ -68,9 +68,15 @@ Argument DIR is the repository path."
(display-buffer output-buf t)))))
(put 'stgit-capture-output 'lisp-indent-function 1)
-(defun stgit-run (&rest args)
+(defun stgit-run-silent (&rest args)
(apply 'call-process "stg" nil standard-output nil args))
+(defun stgit-run (&rest args)
+ (let ((msgcmd (mapconcat #'identity args " ")))
+ (message "Running stg %s..." msgcmd)
+ (apply 'call-process "stg" nil standard-output nil args)
+ (message "Running stg %s...done" msgcmd)))
+
(defun stgit-reload ()
"Update the contents of the stgit buffer"
(interactive)
@@ -79,8 +85,8 @@ Argument DIR is the repository path."
(curpatch (stgit-patch-at-point)))
(erase-buffer)
(insert "Branch: ")
- (stgit-run "branch")
- (stgit-run "series" "--description")
+ (stgit-run-silent "branch")
+ (stgit-run-silent "series" "--description")
(stgit-rescan)
(if curpatch
(stgit-goto-patch curpatch)
@@ -338,7 +344,7 @@ With numeric prefix argument, pop that many patches."
(set (make-local-variable 'stgit-edit-patch) patch)
(setq default-directory dir)
(let ((standard-output edit-buf))
- (stgit-run "edit" "--save-template=-" patch))))
+ (stgit-run-silent "edit" "--save-template=-" patch))))
(defun stgit-confirm-edit ()
(interactive)
@@ -402,7 +408,7 @@ With numeric prefix argument, pop that many patches."
(set (make-local-variable 'stgit-patches) patch-names)
(setq default-directory dir)
(let ((standard-output edit-buf))
- (apply 'stgit-run "coalesce" "--save-template=-" patch-names))))
+ (apply 'stgit-run-silent "coalesce" "--save-template=-" patch-names))))
(defun stgit-confirm-coalesce ()
(interactive)
^ permalink raw reply related
* Not-quite-a-bug in pickaxe
From: Johannes Schindelin @ 2008-11-24 11:43 UTC (permalink / raw)
To: git, gitster
Hi people,
I do not know if I hit that behavior before, but now it hit me big time:
if a commit moves a certain string from one place to another, "git log
-S<string>" does not pick up that commit. The code responsible for this
is in diffcore-pickaxe.c:
else if (!diff_unmodified_pair(p) &&
contains(p->one, needle, len, regexp) !=
contains(p->two, needle, len, regexp))
has_changes++;
Basically, the "contains()" method says how often the needle was found,
and pickaxe just assumes that a move of a string is not interesting
enough.
Now, this behavior is probably intended, as searching files is much
cheaper than generating the diffs between them, yet it is something you'll
have to keep in mind when using "-S".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Display (empty) when appropriate for the goto command
From: Karl Hasselström @ 2008-11-24 11:19 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081123212318.9835.53505.stgit@localhost.localdomain>
On 2008-11-23 21:23:18 +0000, Catalin Marinas wrote:
> This is a fix for bug #11810. The original implementation of goto
> used to display (empty patch) when a patch became empty during a
> push + merge operation. This patch adds this feature again.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
Acked-by: Karl Hasselström <kha@treskal.com>
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Karl Hasselström @ 2008-11-24 11:16 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <b0943d9e0811231320s804eff0k5aecbac84cb2ffe7@mail.gmail.com>
On 2008-11-23 21:20:59 +0000, Catalin Marinas wrote:
> 2008/11/12 Karl Hasselström <kha@treskal.com>:
>
> > On 2008-11-12 10:02:10 +0000, Catalin Marinas wrote:
> >
> > > I think it's just a matter of updating HEAD on the
> > > "merge_conflict" path but I'm still not fully confident in
> > > modifying the new lib infrastructure.
> >
> > You're probably right.
>
> The simple patch below seems to fix it the goto issue. Could you
> please confirm its correctness (the patch might be wrapped by the web
> interface)?
>
> diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
> index 6623645..0f414d8 100644
> --- a/stgit/lib/transaction.py
> +++ b/stgit/lib/transaction.py
> @@ -321,6 +321,7 @@ class StackTransaction(object):
> if any(getattr(cd, a) != getattr(orig_cd, a) for a in
> ['parent', 'tree', 'author', 'message']):
> comm = self.__stack.repository.commit(cd)
> + self.head = comm
> else:
> comm = None
> s = ' (unmodified)'
OK, so I just took a quick look, and my understanding of the problem
(without having had time to actually run any code to confirm) is that
the following happens:
1. In push_patch(), we delay the final stack update (the update()
function) since we want to record the state just before the
conflict in the stack log.
2. In run(), we update the branch head before running the delayed
stack update (self.__conflicting_push()).
Your patch works around this problem by explicitly specifying what the
branch head should be; this mechanism is used by undo etc. to be able
to set the branch head to something that isn't the stack top.
At first I thought it was something of a hack, and that the run()
function should probably be modified to do something clever when
self.__conflicting_push != None, such as writing the branch head
later. But there's a reason the checkout is done first in run(): it's
the one and only thing that can go wrong, in which case we have to
roll back. So I guess your solution is indeed at least as right and
proper as anything I would have come up with.
But I would recommend a big fat comment just before the line you
insert that explains why we have to set self.head hard in this case
(namely, that the update() function is run _after_ checkout in run()).
With that comment,
Acked-by: Karl Hasselström <kha@treskal.com>
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC PATCH 1/4] Refactor builtin-verify-tag.c
From: Johannes Schindelin @ 2008-11-24 11:04 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <1227497000-8684-2-git-send-email-deskinm@umich.edu>
Hi,
On Sun, 23 Nov 2008, Deskin Miller wrote:
> builtin-verify-tag.c didn't expose any of its functionality to be used
> internally. Refactor some of it into new verify-tag.c and expose
> verify_tag_sha1 able to be called from elsewhere in git.
>
> Signed-off-by: Deskin Miller <deskinm@umich.edu>
> ---
> Makefile | 2 +
> builtin-verify-tag.c | 61 ++-------------------------------------
> verify-tag.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++
> verify-tag.h | 10 ++++++
> 4 files changed, 93 insertions(+), 57 deletions(-)
> create mode 100644 verify-tag.c
> create mode 100644 verify-tag.h
I'll comment on the output of "format-patch -n -C -C" instead, as that
makes it much easier to see what you actually did:
> Makefile | 2 +
> builtin-verify-tag.c | 61 ++-------------------------------
> builtin-verify-tag.c => verify-tag.c | 48 ++++-----------------------
> verify-tag.h | 10 +++++
> 4 files changed, 23 insertions(+), 98 deletions(-)
> copy builtin-verify-tag.c => verify-tag.c (56%)
> create mode 100644 verify-tag.h
>
> [...]
> diff --git a/builtin-verify-tag.c b/verify-tag.c
> similarity index 56%
> copy from builtin-verify-tag.c
> copy to verify-tag.c
> index 729a159..c9be331 100644
> --- a/builtin-verify-tag.c
> +++ b/verify-tag.c
> @@ -1,18 +1,12 @@
> /*
> - * Builtin "git verify-tag"
> + * Internals for "git verify-tag"
Agree.
> *
> - * Copyright (c) 2007 Carlos Rica <jasampler@gmail.com>
> + * Copyright (c) 2008 Deskin Miller <deskinm@umich.edu>
Disagree.
Even if Carlos seemed to stop his work on Git entirely, which I find
disappointing, you are _not_ free to pretend his work is yours. And given
this diff:
> *
> - * Based on git-verify-tag.sh
> */
> #include "cache.h"
> -#include "builtin.h"
> -#include "tag.h"
> +#include "object.h"
> #include "run-command.h"
> -#include <signal.h>
> -
> -static const char builtin_verify_tag_usage[] =
> - "git verify-tag [-v|--verbose] <tag>...";
>
> #define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
>
> @@ -60,52 +54,24 @@ static int run_gpg_verify(const char *buf, unsigned long size, int verbose)
> return ret;
> }
>
> -static int verify_tag(const char *name, int verbose)
> +int verify_tag_sha1(const unsigned char *sha1, int verbose)
> {
> enum object_type type;
> - unsigned char sha1[20];
> char *buf;
> unsigned long size;
> int ret;
>
> - if (get_sha1(name, sha1))
> - return error("tag '%s' not found.", name);
> -
> type = sha1_object_info(sha1, NULL);
> if (type != OBJ_TAG)
> - return error("%s: cannot verify a non-tag object of type %s.",
> - name, typename(type));
> + return error("Cannot verify a non-tag object of type %s.",
> + typename(type));
>
> buf = read_sha1_file(sha1, &type, &size);
> if (!buf)
> - return error("%s: unable to read file.", name);
> + return error("Cnable to read file.");
>
> ret = run_gpg_verify(buf, size, verbose);
>
> free(buf);
> return ret;
> }
> -
> -int cmd_verify_tag(int argc, const char **argv, const char *prefix)
> -{
> - int i = 1, verbose = 0, had_error = 0;
> -
> - git_config(git_default_config, NULL);
> -
> - if (argc > 1 &&
> - (!strcmp(argv[i], "-v") || !strcmp(argv[i], "--verbose"))) {
> - verbose = 1;
> - i++;
> - }
> -
> - if (argc <= i)
> - usage(builtin_verify_tag_usage);
> -
> - /* sometimes the program was terminated because this signal
> - * was received in the process of writing the gpg input: */
> - signal(SIGPIPE, SIG_IGN);
> - while (i < argc)
> - if (verify_tag(argv[i++], verbose))
> - had_error = 1;
> - return had_error;
> -}
I think pretty much all you did was deleting (and thereby you do not gain
any copyright).
Except for one change: why on earth did you think it a good idea to
suppress telling the user the _name_ of the tag when an error occurs?
I, for one, would find it way less than helpful to read
Cannot verify a non-tag object of type blob.
than to read
refs/tags/dscho-key: cannot verify a non-tag object of type blob.
Besides, I do not see where you warn that "tag <name> not found." Changes
like this one need to be justified (by saying in the commit message where
the warning is already issued, and not letting the reviewer/reader leave
wondering).
Please, next time you submit a patch like this, do the -C -C yourself.
Letting all the reviewers do it looks lousy on the overall time balance
sheet, and it may also lead to a potential reviewer preferring to do
something else instead.
Now, Junio already said that he is not (yet) convinced that this change
should be in Git proper, rather than a hook, so it is up to you to decide
if you deem it important enough to try harder to convince people.
I, for one, would think that it may be a good change: AFAIK only hard-core
gits use hooks, everybody else avoids them. So if we deem verifying
signatures important enough, we might want to have better support for it
than some example hooks.
So color me half-convinced.
Ciao,
Dscho
^ permalink raw reply
* Best practices for maintaining a subversion mirror?
From: Oliver Charles @ 2008-11-24 10:55 UTC (permalink / raw)
To: git
Hi,
I just got myself a new server, and as I'm the major Git-using person
at my work, I'd like to set a mirror of our Subversion repository up
to hopefully convert a few more people. At the moment, I've done git
svn clone http://svn..., and then git clone --bare to make a --bare
version of this clone.
Now that I have this mirror, I have this entry in my crontab to update
it hourly:
0 * * * * cd /.git && /usr/bin/git --git-dir=. svn fetch &&
/usr/bin/git update-ref refs/heads/master refs/remotes/git-svn
This seems to be working nicely as a readonly interface, but when I
clone this repository (git clone git://foo/repo.git) - served via
git-daemon - I can't seem to get svn rebase to work on it, which means
I can't dcommit my changes back to Subversion.
Am I doing things generally the right way, or am I doing it completely
wrong? :-) Any tips appreciated!
- Oliver Charles
^ permalink raw reply
* Re: [RFC PATCH 4/4] Make git fetch verify signed tags
From: Johannes Schindelin @ 2008-11-24 10:44 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <1227497000-8684-5-git-send-email-deskinm@umich.edu>
Hi,
On Sun, 23 Nov 2008, Deskin Miller wrote:
> When git fetch downloads signed tag objects, make it verify them right
> then. This extends the output summary of fetch to include "(good
> signature)" for valid tags and "(BAD SIGNATURE)" for invalid tags. If
> the user does not have the correct key in the gpg keyring, gpg returns
> 2, verify_tag_sha1 returns -2 and nothing additional is output about the
> tag's validity.
This must be turned off by default, IMO. You cannot expect each and every
developer to have gpg _and_ all those public keys installed.
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