* Re: Some tips for doing a CVS importer
From: Marko Macek @ 2006-11-26 10:18 UTC (permalink / raw)
To: jonsmirl; +Cc: git
In-Reply-To: <9e4733910611201753m392b5defpb3eb295a075be789@mail.gmail.com>
Jon Smirl wrote:
>
> SVN hides the mini branch by creating a symbol like this:
>
> Symbol XXX, change set 70
> copy All from change set 50
> copy file A from change set 55
> copy file B,C from change set 60
> copy file D from change set 61
> copy file E,F,G from change set 63
> copy file H from change set 67
>
> It has to do all of those copies because the change sets weren't
> constructed while taking symbol dependency information into account.
>
> Symbol XXX can't copy from change set 69 because commits from after
> the symbol was created are included in change sets 51-69.
Sometimes it is not actually possible to have a 'simple' symbol, even
by following proper symbol dependencies.
Some situations:
- tags on some files are readjusted later, or tagged separately with an older
version
- tag is created with a -D "date" and the file times are not in sync
- tag is created from a mixed-revision working copy
While in the cases of 'time warp' the revision sequence should be
considered more important than timestamps, this is not necessarily
true for tags, since it's easily possible to create them on mixed
revisions.
cvs2svn also has a problem with vendor branches because it creates
tags/branches that contain files from vendor branch by copying some
files from the trunk and other files from the vendor branch.
If the vendor branch/tag was only used for the initial import,
it's IMO best to skip them in the conversion (this needs a patch).
There are however problems because keyword expansion causes file
differences.
It seems that mozilla CVS repository has vendor branches/imports in
some parts of the tree.
Mark
^ permalink raw reply
* [PATCH] Use new .git/config for storing "origin" shortcut repository
From: Andy Parkins @ 2006-11-26 12:10 UTC (permalink / raw)
To: git
In-Reply-To: <ekbnr6$naq$2@sea.gmane.org>
Rather than use a separate config .git/remotes/ for remote shortcuts, this
patch adds the analagous definitions to .git/config using git-repo-config
calls.
For example what was previously .git/remotes/origin
URL: proto://host/path
Pull: refs/heads/master:refs/heads/origin
Is now added to .git/config as
[remote "origin"]
url = proto://host/path
fetch = refs/heads/master:refs/heads/origin
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
You're absolutely correct; fixed. This patch replaces the previous (again).
git-clone.sh | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 9ed4135..7e5dc0f 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -373,9 +373,8 @@ then
*) origin_track="$remote_top/$origin"
git-update-ref "refs/heads/$origin" "$head_sha1" ;;
esac &&
- echo >"$GIT_DIR/remotes/$origin" \
- "URL: $repo
-Pull: refs/heads/$head_points_at:$origin_track" &&
+ git-repo-config remote."$origin".url "$repo" &&
+ git-repo-config remote."$origin".fetch "refs/heads/$head_points_at:$origin_track" ^$ &&
(cd "$GIT_DIR/$remote_top" && find . -type f -print) |
while read dotslref
do
@@ -389,8 +388,8 @@ Pull: refs/heads/$head_points_at:$origin_track" &&
then
continue
fi
- echo "Pull: refs/heads/${name}:$remote_top/${name}"
- done >>"$GIT_DIR/remotes/$origin" &&
+ git-repo-config remote."$origin".fetch "refs/heads/${name}:$remote_top/${name}" ^$
+ done &&
case "$use_separate_remote" in
t)
rm -f "refs/remotes/$origin/HEAD"
--
1.4.4.1.g9fd7
^ permalink raw reply related
* cache for copy/rename detection
From: Nguyen Thai Ngoc Duy @ 2006-11-26 12:59 UTC (permalink / raw)
To: git
I thought about this lately. git's expensive copy/rename detection can
be run once and the results are kept somewhere in .git. Copy/rename
detection depends on tree objects and git detection algorithm. Tree
objects are immutable and git algorithm change rate is low IMO. So
cache invalidation is unlikely to happen.
Another thing I want to do with this cache is ability to manually
inject some hints to git. For example, I remove a file. Several
commits later, I revive that file in another place. I know that two
files are the same but can't tell git (and I don't think Git will
detect this pattern). With this cache, I can tell git this file is a
copy of that file.
What do you think?
--
^ permalink raw reply
* Re: [PATCH] Use new .git/config for storing "origin" shortcut repository
From: Johannes Schindelin @ 2006-11-26 13:30 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611261210.52154.andyparkins@gmail.com>
Hi,
On Sun, 26 Nov 2006, Andy Parkins wrote:
> - echo >"$GIT_DIR/remotes/$origin" \
> - "URL: $repo
> -Pull: refs/heads/$head_points_at:$origin_track" &&
> + git-repo-config remote."$origin".url "$repo" &&
> + git-repo-config remote."$origin".fetch "refs/heads/$head_points_at:$origin_track" ^$ &&
You do not need the "^$" here: this _is_ the first entry. I would even
argue that this _has_ to replace whatever might be there (could be
introduced by some bogus templates, for example), since the first fetch
entry has a special meaning for pull.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Use new .git/config for storing "origin" shortcut repository
From: Johannes Schindelin @ 2006-11-26 13:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmaeyie6.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 25 Nov 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This hunk is wrong: "git-repo-config remote.bla.fetch b" will _overwrite_
> > remoter.bla.fetch. To avoid that, you have to use "git repo-config
> > remote.bla.fetch b ^$". (The last argument is a regular expression which
> > has to be matched by the value-to-be-oreplaced.)
>
> Yup, one of the joys of working the config file everybody seems to like
> ;-).
The problem is: config files are ubiquitous, so you need not teach
users about it. On the other hand, they are just key / value stores, i.e.
reflecting a mapping. What we want here, is a multimapping, so we use the
wrong tool.
But sometimes it is so much more pragmatic to just take off one shoe and
put the darned nail back into the wall than to go to the shop, buy the
hammer, go back, put the nail in, and try to sell the hammer via eBay.
BTW regarding your criticism of the config file: I agree that the write
support of git-repo-config was quite brittle at the start. Which is my
fault.
However, we had quite some flashing out bugs in the mean time, so I am
quite confident in the tool. Of course, what with the recent addition of a
user specific config file (which makes the name "repo-config" seem utterly
wrong), there might be some dragons in the code.
So, it seems that the whole config writing code is a perfect opportunity
for people wanting to audit source code!
Ciao,
Dscho
^ permalink raw reply
* Re: git-PS1 bash prompt setting
From: Johannes Schindelin @ 2006-11-26 14:27 UTC (permalink / raw)
To: Sean; +Cc: git, Theodore Tso
In-Reply-To: <BAYC1-PASMTP037FDA6C6465F0541AC613AEE90@CEZ.ICE>
Hi,
On Thu, 16 Nov 2006, Sean wrote:
> For what it's worth i'll post a little script i've been using for quite
> some time that helps a little. It's called git-PS1 and is used by
> including it in your bash PS1 variable like so:
>
> export PS1='$(git-PS1 "[\u@\h \W]\$ ")'
I actually like that very much! So much that I tried to implement this as
an option to an existing builtin (I did not want to clutter the list of
commands any more...).
But there really is no good place to put it: most commands need a git
repository, and those which do not, are inappropriate to put an option
"--show-ps1" into. Except maybe repo-config. Thoughts?
Ciao,
Dscho
^ permalink raw reply
* Re: git-PS1 bash prompt setting
From: Sean @ 2006-11-26 14:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Theodore Tso
In-Reply-To: <Pine.LNX.4.63.0611261524130.30004@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 26 Nov 2006 15:27:07 +0100 (CET)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> But there really is no good place to put it: most commands need a git
> repository, and those which do not, are inappropriate to put an option
> "--show-ps1" into. Except maybe repo-config. Thoughts?
What about just making it an option to the git wrapper?
^ permalink raw reply
* [patch] cg help broken when $PAGER contains space
From: Eric Blake @ 2006-11-26 14:51 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
With cogito 0.18.1, cg-help line 152 invokes "IFS=$'\n' colorize", which
in turn invokes the "pager" shell function from cg-Xlib with IFS set to
just a newline. This means that if PAGER contains any spaces, the
expansion of ${PAGER:-less} within pager() will not be split, leading to
the following less-than-useful help message:
$ echo $PAGER
less -s
$ cg help
/usr/lib/cogito/cg-Xlib: line 193: less -s: command not found
$ echo $?
127
This patch fixes the problem:
2006-11-26 Eric Blake <ebb9@byu.net>
* cg-help: Don't change IFS when invoking pager.
diff --git a/cg-help b/cg-help
index c2d558f..f428767 100755
- --- a/cg-help
+++ b/cg-help
@@ -149,7 +149,7 @@ BRANCH_COMMANDS="$(ls "$bin_path"/cg-bra
TAG_COMMANDS="$(ls "$bin_path"/cg-tag* | sed 's#.*/##' | tr '\n' ' ')"
ADVANCED_COMMANDS="$(ls "$bin_path"/cg-admin-* | sed 's#.*/##' | tr '\n'
' ')"
- -IFS=$'\n' colorize <<__END__
+colorize <<__END__
The Cogito version control system $(cg-version)
Available regular commands:
- --
Life is short - so eat dessert first!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFaanr84KuGfSFAYARAmfSAKCZ15/oq3rwsPyB/XLNXpUWYzQRiACfeYcC
DFw8ldbHVYs0vZtjynI3/hU=
=rR/p
^ permalink raw reply
* git-grep misses an instance of a string (after conflict)
From: Johannes Sixt @ 2006-11-26 14:53 UTC (permalink / raw)
To: git
I've roughly had the following sequence of operations on a particular file
in my project:
1. git-cherry-pick a commit, which resulted in a conflict in in that file
2. edit the file to insert a particular string (which wasn't there before)
3. then:
$ git-grep getSibling -- kdbg/exprwnd.h # this file had a conflict
$ grep getSibling -- kdbg/exprwnd.h
{ return static_cast<VarTree*>(getSibling()); }
$ git-update-index kdbg/exprwnd.h
$ git-grep getSibling -- kdbg/exprwnd.h
kdbg/exprwnd.h: { return static_cast<VarTree*>(getSibling()); }
As you can see, the first git-grep doesn't find the string, but after the
update-index, it does find it.
This is unexpected behavior, in particular since the manual page talks about
git-grep to search the working tree. I understand that the conflict may
have influenced the behavior, but the manual page is not in line with the
behavior. Am I missing something?
-- Hannes
^ permalink raw reply
* Re: git-PS1 bash prompt setting
From: Nicolas Vilz @ 2006-11-26 15:05 UTC (permalink / raw)
To: Sean; +Cc: Johannes Schindelin, git, Theodore Tso
In-Reply-To: <20061126094212.fde8cce7.seanlkml@sympatico.ca>
On Sun, Nov 26, 2006 at 09:42:12AM -0500, Sean wrote:
> On Sun, 26 Nov 2006 15:27:07 +0100 (CET)
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > But there really is no good place to put it: most commands need a git
> > repository, and those which do not, are inappropriate to put an option
> > "--show-ps1" into. Except maybe repo-config. Thoughts?
>
> What about just making it an option to the git wrapper?
I glued that in my system bashrc with the extension, that it shows to me
user.email out of repo-config, which is also very handy. So I am always
reminded to set my user.credentials in .git/config and i always know which
role i play in the repository i am working at.
^ permalink raw reply
* Re: git-PS1 bash prompt setting
From: Johannes Schindelin @ 2006-11-26 15:18 UTC (permalink / raw)
To: Sean; +Cc: git, Theodore Tso
In-Reply-To: <BAYC1-PASMTP0478559E108A91E0F2A038AEE70@CEZ.ICE>
Hi,
On Sun, 26 Nov 2006, Sean wrote:
> On Sun, 26 Nov 2006 15:27:07 +0100 (CET)
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > But there really is no good place to put it: most commands need a git
> > repository, and those which do not, are inappropriate to put an option
> > "--show-ps1" into. Except maybe repo-config. Thoughts?
>
> What about just making it an option to the git wrapper?
D'oh. Too easy!
Thanks,
Dscho
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Jon Smirl @ 2006-11-26 15:35 UTC (permalink / raw)
To: Marko Macek; +Cc: git
In-Reply-To: <456969DA.6090702@gmx.net>
On 11/26/06, Marko Macek <marko.macek@gmx.net> wrote:
> Jon Smirl wrote:
>
> >
> > SVN hides the mini branch by creating a symbol like this:
> >
> > Symbol XXX, change set 70
> > copy All from change set 50
> > copy file A from change set 55
> > copy file B,C from change set 60
> > copy file D from change set 61
> > copy file E,F,G from change set 63
> > copy file H from change set 67
> >
> > It has to do all of those copies because the change sets weren't
> > constructed while taking symbol dependency information into account.
> >
> > Symbol XXX can't copy from change set 69 because commits from after
> > the symbol was created are included in change sets 51-69.
>
> Sometimes it is not actually possible to have a 'simple' symbol, even
> by following proper symbol dependencies.
>
> Some situations:
> - tags on some files are readjusted later, or tagged separately with an older
> version
> - tag is created with a -D "date" and the file times are not in sync
> - tag is created from a mixed-revision working copy
I agree that there are a few exceptions to making simple symbols. But
the current cvs2svn makes no attempt at all to preserve simple
symbols. In my attempts at converting Mozilla 60% of the symbols ended
up as tiny branches. I investigated a couple by hand and was able to
rearrange things to create simple symbols in every case I looked at.
This can be dealt with during the topological sort. If there are
complex symbol creations you will end up with loops during the sort
process. At that point you need to start breaking up change sets to
remove the loops. You would use a heuristic at this point, something
like try breaking up to ten commit change sets to preserve a symbol,
if you can't preserve it with 10 breaks then break the symbol once and
try again, repeat until the loop is gone.
The current cvs2svn code effectively implements a heuristic when the
commits are always preserved at the expense of breaking the symbols.
Since some commit comments are very common comments (blank ones) those
commits get combined into bigger change sets and trash the simple
symbols.
Another note for doing a converter. When combining things into change
sets, for git import the comments in the branches should not be mixed
between branches and the trunk when detecting change set. Git doesn't
allow simultaneous commits to the trunk and branches.
> While in the cases of 'time warp' the revision sequence should be
> considered more important than timestamps, this is not necessarily
> true for tags, since it's easily possible to create them on mixed
> revisions.
>
> cvs2svn also has a problem with vendor branches because it creates
> tags/branches that contain files from vendor branch by copying some
> files from the trunk and other files from the vendor branch.
> If the vendor branch/tag was only used for the initial import,
> it's IMO best to skip them in the conversion (this needs a patch).
> There are however problems because keyword expansion causes file
> differences.
>
> It seems that mozilla CVS repository has vendor branches/imports in
> some parts of the tree.
I never got around to checking out problems with vendor branches in Mozilla.
>
> Mark
>
>
--
Jon Smirl
^ permalink raw reply
* [PATCH] Make logAllRefUpdates true by default
From: Anand Kumria @ 2006-11-26 15:36 UTC (permalink / raw)
To: git; +Cc: Anand Kumria
reflog support, which allows you to determine what the state of a branch
was at a particular date/time, is often cited as something that would be
useful to have on by default. Modify git init-db, so that newly created
repositories have this on.
Signed-off-by: Anand Kumria <wildfire@progsoc.org>
---
Documentation/config.txt | 2 +-
builtin-init-db.c | 3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9d3c71c..e8d0bc1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -80,7 +80,7 @@ core.logAllRefUpdates::
This information can be used to determine what commit
was the tip of a branch "2 days ago". This value is
- false by default (no automated creation of log files).
+ true by default.
core.repositoryFormatVersion::
Internal variable identifying the repository format and layout
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 235a0ee..4ea865d 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -239,6 +239,9 @@ static void create_default_files(const c
git_config_set("core.filemode",
filemode ? "true" : "false");
}
+
+ git_config_set("core.logAllRefUpdates", "true");
+
}
static const char init_db_usage[] =
--
1.4.3.3
^ permalink raw reply related
* Re: Some tips for doing a CVS importer
From: Marko Macek @ 2006-11-26 16:11 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910611260735g2b18e9d1p51a0dca153282cc7@mail.gmail.com>
Jon Smirl wrote:
> Another note for doing a converter. When combining things into change
> sets, for git import the comments in the branches should not be mixed
> between branches and the trunk when detecting change set. Git doesn't
> allow simultaneous commits to the trunk and branches.
Yup, this is the current problem I'm facing now. Even for CVS->SVN conversion,
I don't want to see multi-branch commits.
^ permalink raw reply
* Possible BUG with git-rev-list --all in a StGit repository
From: Marco Costalba @ 2006-11-26 16:27 UTC (permalink / raw)
To: catalin.marinas; +Cc: Git Mailing List, Junio C Hamano
In a StGit repository the --all option causes a lot of spurious
revisions, possibly stgit related.
$ git branch
* master
origin
test
$ git rev-list master origin test -- src/settingsimpl.cpp | wc
13 13 533
$ git rev-list --all -- src/settingsimpl.cpp | wc
26 26 1066
The extra revisions have shortlogs of the kind of:
push a3bc76fd0bdd154149c26a3c208f0344e9cd873b
new e7baf56544cd8b4f8601a35fad274b8de97fd558
refresh 8fa01a56a40b04ed9c6d006c669ca9d370176728
From qgit these are easily seen from file history tab of a file
modified by stgit patches or when filtering in main view on the same
file.
Shouldn't 'git-rev-list --all' print *the same output* of when the
list with all branches is given in command line?
Thanks
Marco
P.S:
$ git version
git version 1.4.4.1.g7002
$ stg --version
Stacked GIT 0.11
git version 1.4.4.1.g7002
Python version 2.4.3 (#2, Oct 6 2006, 15:32:41)
^ permalink raw reply
* Re: git tag: don't complain of empty messages
From: Han-Wen Nienhuys @ 2006-11-26 16:42 UTC (permalink / raw)
To: git
In-Reply-To: <7v64dgo9gj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano escreveu:
> Please follow Documentation/SubmittingPatches.
See below, hope I didn't mess up.
From be40730d19592f9db8f07f619f5723060c2f4f0c Mon Sep 17 00:00:00 2001
From: Han-Wen Nienhuys <hanwen@lilypond.org>
Date: Sun, 26 Nov 2006 17:41:30 +0100
Subject: [PATCH] allow empty tag message if -m is given explicitly.
---
git-tag.sh | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/git-tag.sh b/git-tag.sh
index ac269e3..d53f94c 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -5,6 +5,7 @@ USAGE='-l [<pattern>] | [-a | -s | -u <k
SUBDIRECTORY_OK='Yes'
. git-sh-setup
+message_given=
annotate=
signed=
force=
@@ -37,6 +38,12 @@ do
annotate=1
shift
message="$1"
+ if test "$#" = "0"; then
+ die "error: option -m needs an argument"
+ exit 2
+ else
+ message_given=1
+ fi
;;
-u)
annotate=1
@@ -83,7 +90,7 @@ tagger=$(git-var GIT_COMMITTER_IDENT) ||
trap 'rm -f "$GIT_DIR"/TAG_TMP* "$GIT_DIR"/TAG_FINALMSG "$GIT_DIR"/TAG_EDITMSG' 0
if [ "$annotate" ]; then
- if [ -z "$message" ]; then
+ if [ -z "$message_given" ]; then
( echo "#"
echo "# Write a tag message"
echo "#" ) > "$GIT_DIR"/TAG_EDITMSG
@@ -95,7 +102,7 @@ if [ "$annotate" ]; then
grep -v '^#' <"$GIT_DIR"/TAG_EDITMSG |
git-stripspace >"$GIT_DIR"/TAG_FINALMSG
- [ -s "$GIT_DIR"/TAG_FINALMSG ] || {
+ [ -s "$GIT_DIR"/TAG_FINALMSG -o -n "$message_given" ] || {
echo >&2 "No tag message?"
exit 1
}
--
1.4.2.4
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply related
* Re: git tag: don't complain of empty messages
From: Han-Wen Nienhuys @ 2006-11-26 16:46 UTC (permalink / raw)
To: git
In-Reply-To: <4569C409.5080509@xs4all.nl>
Han-Wen Nienhuys escreveu:
> Junio C Hamano escreveu:
>> Please follow Documentation/SubmittingPatches.
>
> See below, hope I didn't mess up.
please add
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* handling symlinks proposal
From: Christian Thaeter @ 2006-11-26 16:59 UTC (permalink / raw)
To: git
Git currently keep symlinks always as symlink, I would like to see some
optional functionality when handling symlinks.
Sometimes it is not intended to store information external to a source
tree in git. Problems are that it might break a checkout, just loosing
information or even have security implications.
What are are the diffrent kinds of symlinks:
- they can point to a file local to the tree
- or point to a file outside of the tree
- they can be absolute
- or relative
how can we handle symlinks:
- 'keep' what git currently does, store the symlink as it is
- 'file' store it as file (dereference it), information that it was a
symlink gets lost, checkouts will produce a file.
- 'relative' store it as a relative symlink
- 'absolute' store it as a absolute symlink
- 'error' refuse to checkin and abort commit
- 'warn' display a warning
How to add this to git?
make config options (defaults in [core] ?)
symlink[.{local|extern}?_?{absolute|relative}?] = action
per branch overrides in [branch]
Example:
[core]
# in-tree symlinks shall not break a checkout to another place
symlink.local = relative
# we don't want out-of-tree symlinks, store them as file
symlink.extern_absolute = file
# a relative symlink out-of-tree is likely a typo/error?
symlink.extern_relative = error
[branch]
# some local feature branch keeps all symlinks
myfeature.symlink = keep
Default will be 'keep' so without this options it is what git currently
does.
Additional thoughts:
An existing symlink in the tree is not altered by check in, only the
repository is affected.
New checkouts or switching branches may alter it.
Merging between branches where one stores something as file and the
other symlink should be straightforward, does this need to be resolved?
So far thats just an idea how I would like it. If People like it this
way or we can refine it even better, I am going to implement it sometime
next.
^ permalink raw reply
* Svnimport problem for openwrt repo
From: P. Christeas @ 2006-11-26 17:30 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git-list
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
Just tried today to sync my openwrt copy, but it seems that their extensive
use of svn makes git-svnimport fail.
In particular, around commit #5089, I get the attached error (having printed
the 'system' line). That commit should be the one when they merged
their 'buildroot-ng' branch into the trunk (major changes, that is).
I have little to no time to debug the issue. Would you please give me a clue
how to solve the issue and keep on using git-svnimport? Of course, I could
even let you clone my repo or even work on it..
Hint: is there something wrong in the git-update-index arguments I have
there?
[-- Attachment #2: svnimport.log --]
[-- Type: text/x-log, Size: 1094 bytes --]
~/bin/git-svnimport -v https://svn.openwrt.org/openwrt/
Fetching from 5059 to 5646 ...
Switching from 52e84fb9bdd801d5ec730c871918b9a72103d93b to fd0a4bec684c716f58f674c7f6b609a78450de49 (/)
5059:/:/: copying from buildroot-ng:openwrt @ 5058
git-update-index --add --cacheinfo 100644f6f0cadf4603265e36202cfb1bac1092e240d956//BSDmakefile --cacheinfo 10064474b3696242caf331aebf1df2d02f70cd53d2792e//Config.in --cacheinfo 100644d60c31a97a544b53039088d14fe9114583c0efc3//LICENSE --cacheinfo 10064439ffb17fb5e770c8c6983feee5ef3568388665a2//Makefile --cacheinfo 1006442bba6fa6f6c8190e659145770d3d5cfeb01b45b9//README --cacheinfo 10064459881580b475e05803a3a55dde4d356c27a9a589//docs/config.txt --cacheinfo 100644024161bdebf1cfcec79c4a1063c2ddabaf5237f0//docs/network-scripts.txt --cacheinfo 10064469dbaa60ba8f492c0875060b09b583173921fa48//docs/network.txt --cacheinfo 100644a1287da475bc8a63a5d13c021e6d27efc0fe39e9//include/host-build.mk --cacheinfo 1006443a5fd9683e3592f4750a80964a321075e388cde7//include/host.mkfatal: git-update-index: --cacheinfo cannot add //BSDmakefile
Cannot add files: 32768
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Jon Smirl @ 2006-11-26 17:51 UTC (permalink / raw)
To: Marko Macek; +Cc: git
In-Reply-To: <4569BCB8.9030809@gmx.net>
On 11/26/06, Marko Macek <marko.macek@gmx.net> wrote:
> Jon Smirl wrote:
>
> > Another note for doing a converter. When combining things into change
> > sets, for git import the comments in the branches should not be mixed
> > between branches and the trunk when detecting change set. Git doesn't
> > allow simultaneous commits to the trunk and branches.
>
> Yup, this is the current problem I'm facing now. Even for CVS->SVN conversion,
> I don't want to see multi-branch commits.
There is a command line option on cvs2svn to isolate the branches. I
got him to add it as part of the attempt at doing git support.
>
> Mark
>
--
Jon Smirl
^ permalink raw reply
* Re: [PATCH] Documentation: clarify tutorial pull/merge discussion
From: Paolo Ciarrocchi @ 2006-11-26 18:05 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20061126034502.GA3782@fieldses.org>
On 11/26/06, J. Bruce Fields <bfields@fieldses.org> wrote:
> Attempt to clarify somewhat the difference between pull and merge,
> and give a little more details on the pull syntax.
>
> I'm still not happy with this section: the explanation of the origin
> branch isn't great, but maybe that should be left alone pending the
> use-separate-remotes change; and we need to explain how to set up a
> public repository and push to it.
>
> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
A lot more clear in my opinion.
Acked-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Ciao,
--
Paolo
http://docs.google.com/View?docid=dhbdhs7d_4hsxqc8
http://www.linkedin.com/pub/0/132/9a3
^ permalink raw reply
* Re: handling symlinks proposal
From: René Scharfe @ 2006-11-26 18:25 UTC (permalink / raw)
To: Christian Thaeter; +Cc: git
In-Reply-To: <4569C7F8.4030303@pipapo.org>
Christian Thaeter schrieb:
> Git currently keep symlinks always as symlink, I would like to see some
> optional functionality when handling symlinks.
>
> Sometimes it is not intended to store information external to a source
> tree in git. Problems are that it might break a checkout, just loosing
> information or even have security implications.
[...]
> how can we handle symlinks:
> - 'keep' what git currently does, store the symlink as it is
> - 'file' store it as file (dereference it), information that it was a
> symlink gets lost, checkouts will produce a file.
> - 'relative' store it as a relative symlink
> - 'absolute' store it as a absolute symlink
> - 'error' refuse to checkin and abort commit
> - 'warn' display a warning
>
> How to add this to git?
Why would we want to? Could you perhaps give examples on how a symlink
in a git repo could break checkouts, cause loss of information or have
security implications?
You're symlink handling methods 'file', 'relative', 'absolute', 'error',
'warn' aren't very useful if you check in files (and symlinks) manually,
because if you add the links by hand then you can make sure they point
to the right place (or are no symlinks, but plain files), after all.
So they're mainly intended for initial checkins and merges with external
repos, right? But in these cases you have to trust foreign code anyway
(simple example: you need to be sure 'make all' doesn't run a command
like 'rm -rf $HOME'), so you have to take a closer look at that stuff
anyway -- symlinks are just one part of what needs checking.
Thanks,
^ permalink raw reply
* Re: handling symlinks proposal
From: Linus Torvalds @ 2006-11-26 18:46 UTC (permalink / raw)
To: Christian Thaeter; +Cc: git
In-Reply-To: <4569C7F8.4030303@pipapo.org>
On Sun, 26 Nov 2006, Christian Thaeter wrote:
>
> Git currently keep symlinks always as symlink, I would like to see some
> optional functionality when handling symlinks.
I can pretty much guarantee that you really don't want to do this, and
that you'd be _much_ happier using some explicit wrappers around git to
handle your special needs, than try to teach the SCM to handle symlinks
specially.
The issues become all the same as with some of the idiotic things that
other SCM's do - like $Id keyword substitution - but _much_ worse.
A simple example: what is "git diff HEAD" supposed to say, once you've
committed the symlink as something else than a symlink? It's obviously
still a symlink in your source tree.. Or what about "git reset --hard", or
"git checkout other-branch-that-also-had-a-symlink"?
In other words, trivial and simple operations that have clear and
well-defined semantics suddenly become totally insane, with no semantics
that make sense what-so-ever.
By not "keeping" symlinks as symlinks, what you actually did was to
totally destroy the ability to handle symlinks AT ALL. The simplest core
operations suddenly cannot work, because you've broken the 1:1 link
between "original source tree" and "tree that actually got committed".
> how can we handle symlinks:
> - 'keep' what git currently does, store the symlink as it is
Right. This is the only sane thing, if you want to support symlinks at
all.
> - 'file' store it as file (dereference it), information that it was a
> symlink gets lost, checkouts will produce a file.
This is what some other systems do, by just not knowing anything about
symlinks at all. It's certainly self-consistent - you can just drop all
"lstat()" calls, and replace them with regular "stat()" calls.
It causes:
- (obviously) inability to handle symlinks correctly
- security problems and serious confusion when you _do_ have a symlink
(what happens when you check out another branch, and the symlink points
to outside the tree? A system that is truly unaware of symlinks will
generally just overwrite the file OUTSIDE the tree, which is clearly
bogus, but equally bogus is to just do an "unlink + create" which will
break the symlink.
so it's generally MUCH worse than any alternative.
> - 'relative' store it as a relative symlink
> - 'absolute' store it as a absolute symlink
Neither of these make any real sense. You can really only store it in the
form it is now, because you simply _cannot_ make it a "relative" or
"absolute" symlink (the transformation depends on how things are mounted).
Not to mention that you get all the problems with "what does 'git diff'
mean?" that I already alluded to above..
> - 'error' refuse to checkin and abort commit
Sure, we can just say "don't allow symlinks". This is probably what we'd
have to do for a native Windows client, for example, or for anything else
that simply doesn't support the concept (VMS port of git, anyone?).
> - 'warn' display a warning
Again, there's nothing wrong with this, but what's the point, really?
Especially a big enough point to merit a per-branch config option?
^ permalink raw reply
* Re: handling symlinks proposal
From: Christian Thaeter @ 2006-11-26 19:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611261034100.3483@woody.osdl.org>
Linus Torvalds wrote:
>
> On Sun, 26 Nov 2006, Christian Thaeter wrote:
>> Git currently keep symlinks always as symlink, I would like to see some
>> optional functionality when handling symlinks.
>
> I can pretty much guarantee that you really don't want to do this, and
> that you'd be _much_ happier using some explicit wrappers around git to
> handle your special needs, than try to teach the SCM to handle symlinks
> specially.
ok agreed, i'll write some script which one can use on a tree to
sanitize symlinks on given rules and/or be used as a pre-commit check.
That has the pretty same effect for my needs and is more sane like you
outlined.
^ permalink raw reply
* Re: [PATCH] Make logAllRefUpdates true by default
From: Junio C Hamano @ 2006-11-26 20:12 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <11645554033331-git-send-email-wildfire@progsoc.org>
I do not think I can take this patch in its current form.
Although I think majority of users would find it convenient to
have ref-log enabled by default on repositories to be developed
in, it does not make sense to enable ref-log by default for bare
repositories that is used as a distribution point. So at least
this needs an option to disable it (if you make it the default),
or enable it.
Side note. A ref-log at a distribution point _could_ be
used for somebody to say "Hey, I pushed that fix three
days ago -- why are you complaining about the breakage
I've already fixed before checking the public tip?", but
that is a manifestation of lack of communication among
people and a SCM is not about solving that problem.
But having to add an option tends to drive people nuts. We
already have --shared and --template, so adding --with-reflog
would be "just one more option" that we may not have to worry
too much about, but we would have to revisit this as we gain
more experience using git and more best-current-practices are
learned. I wonder if we can infer if a particular invocation of
init-db is to prepare a repository to be developed in without
being told with a command line option. If we can do so, then we
can do the configuratio setting with --with-reflog=[yes|no|guess]
option (and lack of --with-reflog means "guess").
There are three use cases that init-db is run directly from the
command line, and I think you want different behaviours.
(1) you have a directory, perhaps already with many files
there, because you are doing an initial import to prepare a
repository to work in. You obviously want a ref-log there,
and you want --shared=no. You do not care about
denyNonFastForwards because you are not likely to be
pushing into it.
(2) you are preparing a public distribution point for _your_
own tree. You do not want a ref-log, you want --shared=no,
and you _might_ want denyNonFastForwards.
(3) you are preparing a public shared repository for project
members to use to synchronize, CVS-style. You do not want
a ref-log, you do want --shared=group, and and you want
denyNonFastForwards.
Another case that init-db is run indirectly is via git-clone and
via foreign SCM importers. I think enabling ref-log during
non-bare clone, for example, should behave similarly to (1)
because the resulting repository is clearly meant to be used
with a working tree in which to develop. A bare clone is either
(2) or (3) but you do not have to decide what to do with ref-log
(i.e. "don't"). But in these "indirect" cases, the command that
drives init-db can explicitly tell init-db what it is doing, and
we would need to have both --with-reflog and --without-reflog
options so that the command can tell what it wants from init-db
explicitly without having init-db guess.
If you can come up with a reliable way to tell (1)..(3) then we
can make init-db to do the right thing without an end user to
tell what should happen --with-reflog or --without-reflog; and
they do not even have to say --shared anymore as an added bonus.
Having thought about all the above, I think the event to create
distribution/synchronization point repositories are rare enough
and the simplest and cleanest way might be to make it default
and add a --without-reflog option to the command, and forget
about the guessing.
^ 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