* Re: [PATCH] Handle branch names with slashes
From: Sam Vilain @ 2006-02-17 3:01 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20060217014117.12525.21330.stgit@backpacker.hemma.treskal.com>
Karl Hasselström wrote:
> Let StGIT grok branch names with slashes in them. It used to fall flat
> on its face when confronted with them.
>
> I think I've covered all, or at least most cases, but there are
> probably some bugs left if you look hard enough.
Does `stgit -r patchname/bottom` still work?
Sam.
^ permalink raw reply
* "stg mail" doesn't set Content-Type and such
From: Karl Hasselström @ 2006-02-17 2:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
As can be seen in the headers of the stgit patches I've send to this
list recently, "stgit mail" doesn't seem to handle charsets and stuff
when sending mail; from what I can tell, it just sends the raw bytes
without setting Content-Transfer-Encoding, Content-Type, or anything
similar.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] Change the signature start string to "-- \n"
From: Karl Hasselström @ 2006-02-17 2:25 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Change the signature start string from "--\n" to "-- \n" in the cover
mail template, as recommended in Mutt's manual:
It is *strongly* recommended that you not unset this variable
[from its default value of "-- \n"] unless your "signature"
contains just your name. The reason for this is because many
software packages use "-- \n" to detect your signature. For
example, Mutt has the ability to highlight the signature in a
different color in the builtin pager.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
templates/covermail.tmpl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/templates/covermail.tmpl b/templates/covermail.tmpl
index 9789c9c..44cd19e 100644
--- a/templates/covermail.tmpl
+++ b/templates/covermail.tmpl
@@ -4,5 +4,5 @@ Date: %(date)s
%(endofheaders)s
The following series implements...
---
+--
Signature
^ permalink raw reply related
* [PATCH] git-svn: ensure fetch always works chronologically.
From: Eric Wong @ 2006-02-17 2:13 UTC (permalink / raw)
To: git list, Junio C Hamano
In-Reply-To: <20060216194751.GB4446@Muzzle>
We run svn log against a URL without a working copy for the first fetch,
so we end up a log that's sorted from highest to lowest. That's bad, we
always want lowest to highest. Just default to --revision 0:HEAD now if
-r isn't specified for the first fetch.
Also sort the revisions after we get them just in case somebody
accidentally reverses the argument to --revision for whatever reason.
Thanks again to Emmanuel Guerin for helping me find this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
2ec4f205eaa3914a64205ea224292b9e27e06cdf
diff --git a/contrib/git-svn/git-svn b/contrib/git-svn/git-svn
index ddd9579..2caf057 100755
--- a/contrib/git-svn/git-svn
+++ b/contrib/git-svn/git-svn
@@ -168,14 +168,15 @@ sub fetch {
my (@parents) = @_;
$SVN_URL ||= file_to_s("$GIT_DIR/$GIT_SVN/info/url");
my @log_args = -d $SVN_WC ? ($SVN_WC) : ($SVN_URL);
- if (-d $SVN_WC && !$_revision) {
- $_revision = 'BASE:HEAD';
+ unless ($_revision) {
+ $_revision = -d $SVN_WC ? 'BASE:HEAD' : '0:HEAD';
}
- push @log_args, "-r$_revision" if $_revision;
+ push @log_args, "-r$_revision";
push @log_args, '--stop-on-copy' unless $_no_stop_copy;
eval { require XML::Simple or croak $! };
my $svn_log = $@ ? svn_log_raw(@log_args) : svn_log_xml(@log_args);
+ @$svn_log = sort { $a->{revision} <=> $b->{revision} } @$svn_log;
my $base = shift @$svn_log or croak "No base revision!\n";
my $last_commit = undef;
--
1.2.0.gdee6
^ permalink raw reply related
* [PATCH] Use --refid option even when sending a cover mail
From: Karl Hasselström @ 2006-02-17 2:07 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
StGIT used to just ignore the --refid option when sending a cover
mail. With this patch, it will send the cover mail as a reply to the
mail identified by the refid, and the patch emails as replies to the
cover mail as usual.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/mail.py | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index b3b7b49..975f8c9 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -199,6 +199,9 @@ def __build_cover(tmpl, total_nr, msg_id
headers_end = __build_address_headers(options)
headers_end += 'Message-Id: %s\n' % msg_id
+ if options.refid:
+ headers_end += "In-Reply-To: %s\n" % options.refid
+ headers_end += "References: %s\n" % options.refid
if options.version:
version_str = ' %s' % options.version
^ permalink raw reply related
* [PATCH] Handle branch names with slashes
From: Karl Hasselström @ 2006-02-17 1:41 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20060214173509.GA8666@diana.vm.bytemark.co.uk>
Let StGIT grok branch names with slashes in them. It used to fall flat
on its face when confronted with them.
I think I've covered all, or at least most cases, but there are
probably some bugs left if you look hard enough.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/branch.py | 6 +++-
stgit/git.py | 12 +++++--
stgit/stack.py | 42 ++++++++++---------------
stgit/utils.py | 77 ++++++++++++++++++++++++++++++++++++++++------
4 files changed, 97 insertions(+), 40 deletions(-)
diff --git a/stgit/commands/branch.py b/stgit/commands/branch.py
index ef44349..d3e8a3c 100644
--- a/stgit/commands/branch.py
+++ b/stgit/commands/branch.py
@@ -173,7 +173,11 @@ def func(parser, options, args):
if len(args) != 0:
parser.error('incorrect number of arguments')
- branches = os.listdir(os.path.join(git.get_base_dir(), 'refs', 'heads'))
+ branches = []
+ basepath = os.path.join(git.get_base_dir(), 'refs', 'heads')
+ for path, dirs, files in os.walk(basepath):
+ branches += [remove_leading_dir(basepath, os.path.join(path, f))
+ for f in files]
branches.sort()
max_len = max([len(i) for i in branches])
diff --git a/stgit/git.py b/stgit/git.py
index 582e803..724b6fd 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -232,7 +232,8 @@ def get_head():
def get_head_file():
"""Returns the name of the file pointed to by the HEAD link
"""
- return os.path.basename(_output_one_line('git-symbolic-ref HEAD'))
+ return remove_leading_dir(os.path.join('refs', 'heads'),
+ _output_one_line('git-symbolic-ref HEAD'))
def set_head_file(ref):
"""Resets HEAD to point to a new ref
@@ -325,7 +326,9 @@ def delete_branch(name):
branch_head = os.path.join('refs', 'heads', name)
if not branch_exists(branch_head):
raise GitException, 'Branch "%s" does not exist' % name
- os.remove(os.path.join(get_base_dir(), branch_head))
+ base = get_base_dir()
+ rm_file_and_dirs(os.path.join(base, branch_head),
+ os.path.join(base, 'refs', 'heads'))
def rename_branch(from_name, to_name):
"""Rename a git branch
@@ -339,8 +342,9 @@ def rename_branch(from_name, to_name):
if get_head_file() == from_name:
set_head_file(to_head)
- os.rename(os.path.join(get_base_dir(), from_head), \
- os.path.join(get_base_dir(), to_head))
+ base = os.path.join(get_base_dir())
+ rename_dirs(os.path.join(base, from_head), os.path.join(base, to_head),
+ os.path.join(base, 'refs', 'heads'))
def add(names):
"""Add the files or recursively add the directory contents
diff --git a/stgit/stack.py b/stgit/stack.py
index 556c40e..68a2936 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -406,7 +406,7 @@ class Series:
"""
if len(self.get_applied()) == 0:
head = git.get_head()
- write_string(self.__base_file, head)
+ write_string(self.__base_file, head, mkdir = True)
def __end_stack_check(self):
"""Remove .git/refs/heads/base if the stack is empty.
@@ -499,9 +499,11 @@ class Series:
git.rename_branch(self.__name, to_name)
if os.path.isdir(self.__series_dir):
- os.rename(self.__series_dir, to_stack.__series_dir)
+ rename_dirs(self.__series_dir, to_stack.__series_dir,
+ os.path.join(self.__base_dir, 'patches'))
if os.path.exists(self.__base_file):
- os.rename(self.__base_file, to_stack.__base_file)
+ rename_dirs(self.__base_file, to_stack.__base_file,
+ os.path.join(self.__base_dir, 'refs', 'bases'))
self.__init__(to_name)
@@ -543,29 +545,19 @@ class Series:
for p in patches:
Patch(p, self.__patch_dir, self.__refs_dir).delete()
- if os.path.exists(self.__applied_file):
- os.remove(self.__applied_file)
- if os.path.exists(self.__unapplied_file):
- os.remove(self.__unapplied_file)
- if os.path.exists(self.__current_file):
- os.remove(self.__current_file)
- if os.path.exists(self.__descr_file):
- os.remove(self.__descr_file)
- if not os.listdir(self.__patch_dir):
- os.rmdir(self.__patch_dir)
- else:
- print 'Patch directory %s is not empty.' % self.__name
- if not os.listdir(self.__series_dir):
- os.rmdir(self.__series_dir)
- else:
- print 'Series directory %s is not empty.' % self.__name
- if not os.listdir(self.__refs_dir):
- os.rmdir(self.__refs_dir)
- else:
- print 'Refs directory %s is not empty.' % self.__refs_dir
+ for f in [self.__applied_file, self.__unapplied_file,
+ self.__current_file, self.__descr_file]:
+ rm_if_exists(f)
+
+ for (d, n) in [(self.__patch_dir, 'Patch'),
+ (self.__series_dir, 'Series'),
+ (self.__refs_dir, 'Refs')]:
+ if os.path.isdir(d) and os.listdir(d):
+ print '%s directory %s is not empty.' % (n, self.__name)
+ rmdir_while_empty(d, self.__base_dir)
- if os.path.exists(self.__base_file):
- os.remove(self.__base_file)
+ rm_if_exists(self.__base_file)
+ rmdir_while_empty(os.path.dirname(self.__base_file), self.__base_dir)
def refresh_patch(self, files = None, message = None, edit = False,
show_patch = False,
diff --git a/stgit/utils.py b/stgit/utils.py
index 5749b3b..33c62be 100644
--- a/stgit/utils.py
+++ b/stgit/utils.py
@@ -18,6 +18,18 @@ along with this program; if not, write t
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
"""
+import os.path
+
+def mkdir_file(filename, mode, mkdir):
+ """Opens filename with the given mode, creating the directory it's
+ in if it doesn't already exist and mkdir is true
+ """
+ if mkdir:
+ d = os.path.dirname(filename)
+ if not os.path.isdir(d):
+ os.makedirs(d)
+ return file(filename, mode)
+
def read_string(filename, multiline = False):
"""Reads the first line from a file
"""
@@ -29,42 +41,87 @@ def read_string(filename, multiline = Fa
f.close()
return result
-def write_string(filename, line, multiline = False):
+def write_string(filename, line, multiline = False, mkdir = False):
"""Writes 'line' to file and truncates it
"""
- f = file(filename, 'w+')
+ f = mkdir_file(filename, 'w+', mkdir)
if multiline:
f.write(line)
else:
print >> f, line
f.close()
-def append_strings(filename, lines):
+def append_strings(filename, lines, mkdir = False):
"""Appends 'lines' sequence to file
"""
- f = file(filename, 'a+')
+ f = mkdir_file(filename, 'a+', mkdir)
for line in lines:
print >> f, line
f.close()
-def append_string(filename, line):
+def append_string(filename, line, mkdir = False):
"""Appends 'line' to file
"""
- f = file(filename, 'a+')
+ f = mkdir_file(filename, 'a+', mkdir)
print >> f, line
f.close()
-def insert_string(filename, line):
+def insert_string(filename, line, mkdir = False):
"""Inserts 'line' at the beginning of the file
"""
- f = file(filename, 'r+')
+ f = mkdir_file(filename, 'r+', mkdir)
lines = f.readlines()
f.seek(0); f.truncate()
print >> f, line
f.writelines(lines)
f.close()
-def create_empty_file(name):
+def create_empty_file(name, mkdir = False):
"""Creates an empty file
"""
- file(name, 'w+').close()
+ mkdir_file(name, 'w+', mkdir).close()
+
+def remove_leading_dir(leading, path):
+ """Remove leading directories from a pathname
+ """
+ if not path.startswith(leading):
+ raise Exception('"%s" does not begin with "%s"' % (path, leading))
+ path = path[len(leading):]
+ if len(path) > 0 and path[0] in [os.path.sep, os.path.altsep]:
+ path = path[1:]
+ return path
+
+def rmdir_while_empty(path, stop):
+ """Delete dirs until we reach a directory that isn't empty, or
+ until we reach the path stop
+ """
+ while path.startswith(stop) and len(path) > len(stop):
+ parent = os.path.dirname(path)
+ try:
+ os.rmdir(path)
+ except OSError:
+ return # directory not empty
+ path = parent
+
+def rm_file_and_dirs(path, stop):
+ """Delete the file, and keep deleting dirs until we reach a
+ directory that isn't empty, or until we reach the path stop
+ """
+ os.remove(path)
+ rmdir_while_empty(os.path.dirname(path), stop)
+
+def rm_if_exists(f):
+ """Delete file if it exists
+ """
+ if os.path.exists(f):
+ os.remove(f)
+
+def rename_dirs(from_path, to_path, stop):
+ """Rename file or directory, creating new directories at to_path
+ as necessary, and removing leftover empty directories at from_path
+ until we reach stop
+ """
+ if not os.path.isdir(os.path.dirname(to_path)):
+ os.makedirs(os.path.dirname(to_path))
+ os.rename(from_path, to_path)
+ rmdir_while_empty(os.path.dirname(from_path), stop)
^ permalink raw reply related
* Re: Fake linear history in a deterministic manner.
From: Junio C Hamano @ 2006-02-16 23:54 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90602121746v5adb448ej73cc2be6dd3745ce@mail.gmail.com>
Martin, (and Martyn),
I just cloned the gitcvs via git locally, exported it via
gitcvs, and ran "cvs log" and "cvs annotate README" there.
Good job. I really had a good laugh looking at the generated
output. It just looks like .... CVS! ;-)
I haven't read the code in detail (I tend to start nitpicking
the details without looking at a bigger picture, once I start
reading the code, so I try to only give superficial look until I
know I'll have tons of time to spend on it).
But it looks like a fun project.
^ permalink raw reply
* Re: git faq : draft and rfc
From: Thomas Riboulet @ 2006-02-16 23:52 UTC (permalink / raw)
To: git
In-Reply-To: <20060216151826.GS31278@pasky.or.cz>
On 2/16/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Thu, Feb 16, 2006 at 01:36:20AM CET, I got a letter
> where Thomas Riboulet <riboulet@gmail.com> said that...
> > . Git commit is dying telling me "fatal : empty ident <user@myhost>
> > not allowed", what's wrong ?
> > Make sure your Full Name is not empty in chsh or the 5th field of your
> > user line in /etc/passwd isn't empty. If you @myhost is empty make sure
> > your hostname is correctly set.
>
> Please also mention GIT_AUTHOR_NAME; chsh may be frequently unavailable.
ok
>
> > . What's the difference between fetch and pull ?
> > Fetch : download objects and a head from another repository.
> > Pull : pull and merge from another repository.
> > See man git-fetch and git-pull for more.
>
> This could do with a little more elaboration as well. Nice inspiration
> might be <Pine.LNX.4.64.0602140845080.3691@g5.osdl.org>.
ok, I'll as soon as I manage to get it :/
>
> > . Can I tell git to ignore files ?
> > Yes. Put the files path in the repository in the .git/info/exclude file.
>
> Or .gitignore in the tree itself. .git/info/exclude is only for your
> particular checkout while .gitignore is what matters for all and
> everyone's checkouts of the project.
>
ok, added
> > . What can I use to setup a public repository ?
> > A ssh server, an http server, or the git-daemon.
> > See the tutorial for more details.
>
> Well this is about how to make it available, not how to use it.
>
> The repository should be set up by cg-admin-setuprepo or git-init-db
> --shared and normally does not have a working tree attached. You can
> fetch from such a repository either over:
>
> * the GIT protocol (you need to run git-daemon)
> * SSH (you can set up a git-use-only account using git-shell)
> * rsync (has important disadvantages but it is currently the
> fastest way to do the initial checkout)
> * or the HTTP protocol (any reasonable webhosting will do, but
> you need to run git-update-server-info after each repository
> update; if you used cg-admin-setuprepo to set it up, this
> will be done automatically, otherwise you may enable it in
> the post-update hook - see .git/hooks/post-update).
>
> You can push to such a repository over:
>
> * SSH
> * HTTP DAV (you will need to specially configure your HTTP
> server for this)
>
> Obviously, you can also fetch/push from/to a repository locally if it
> is available in the local filesystem structure.
>
the initial aim of that question was simply to tell svn people (and
others) what can be used to setup a public repos.
isn't it a bit too much for a faq ? maybe add some things to the
present answer and put this question in the "general questions"
section (see below), and add more details in the "usage" section ?
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> Of the 3 great composers Mozart tells us what it's like to be human,
> Beethoven tells us what it's like to be Beethoven and Bach tells us
> what it's like to be the universe. -- Douglas Adams
>
ok added (and pushed) the :
- taylor qa
- the git import bk qa
- GIT_AUTHOR_NAME
I'll separate the questions between the following sections :
- general questions (who, when, where, ...)
- usage : commands, errors ...
I'm planning on removing the text format faq and handle it as I handle
the html one : through the docbook. ok ?
--
Thom/ange
^ permalink raw reply
* Re: Fake linear history in a deterministic manner.
From: Martin Langhoff @ 2006-02-16 23:29 UTC (permalink / raw)
To: Eric Wong; +Cc: Git Mailing List, Paul Mackerras
In-Reply-To: <20060216222956.GA5818@Muzzle>
On 2/17/06, Eric Wong <normalperson@yhbt.net> wrote:
> Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > To emulate `cvs log somepath` I need to munge history to look linear.
> > I am working on the theory that I will tell the cvs client about *one*
> > linear history, and show merges from parallel histories as a merge
> > commit, "flattened" so to speak, and with a commit message where I'll
> > list the hash and first line of each commit that it involves.
>
> I'd be interested in exporting from git to SVN with something like this.
We're hoping to release the code soon, but the truth is that it's
really trivial. It was more agonizing over the fact that there's no
"good" (aka "stable") algorithm for this.
> > I thought briefly about delaying the decision until I see the merge,
> > and pick the leftmost, or rightmost, if there is some bias in
> > git-merge or cg-merge on putting whatever origin has on a particular
> > side. It'd mean running backwards through history and that the very
> > last merge can flip the decision entirely. Hmmm... any strategy I can
> > come up with means that each new merge throws the dice again entirely.
> >
> > Ideas?
>
> I'd actually like to do this interactively in gitk. Just browse history
> visually and pick the path you want to choose each time there's a merge,
> and then having it output the revisions to stdout or saved to a file
> after you're done picking. Ideally you'd be able to use saved output
> interactively, as well.
It's cool to be able to pick, but if it's for a git-svnserver
implementation, you can't change your (fake) history you tell after
clients have seen. So a merge that gets pushed to the repo later may
contain more interesting paths, but you're bound to the lies you've
told.
cheers,
martin
^ permalink raw reply
* Re: Fake linear history in a deterministic manner.
From: Eric Wong @ 2006-02-16 22:29 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List, Paul Mackerras
In-Reply-To: <46a038f90602121746v5adb448ej73cc2be6dd3745ce@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> To emulate `cvs log somepath` I need to munge history to look linear.
> I am working on the theory that I will tell the cvs client about *one*
> linear history, and show merges from parallel histories as a merge
> commit, "flattened" so to speak, and with a commit message where I'll
> list the hash and first line of each commit that it involves.
I'd be interested in exporting from git to SVN with something like this.
> I thought briefly about delaying the decision until I see the merge,
> and pick the leftmost, or rightmost, if there is some bias in
> git-merge or cg-merge on putting whatever origin has on a particular
> side. It'd mean running backwards through history and that the very
> last merge can flip the decision entirely. Hmmm... any strategy I can
> come up with means that each new merge throws the dice again entirely.
>
> Ideas?
I'd actually like to do this interactively in gitk. Just browse history
visually and pick the path you want to choose each time there's a merge,
and then having it output the revisions to stdout or saved to a file
after you're done picking. Ideally you'd be able to use saved output
interactively, as well.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: fix revision order when XML::Simple is not loaded
From: Eric Wong @ 2006-02-16 21:44 UTC (permalink / raw)
To: git list
In-Reply-To: <20060216194751.GB4446@Muzzle>
Just to add, XML::Simple is a recommended dependency. git-svn will work
fine without it (after this patch) as long as the repository doesn't
have any log messages that regurgitate or otherwise look like svn log
output (most svn repositories are sane in this regard :)
I may add support for the SVN:: perl libraries in the future, but I'll
always git-svn compatible with the command-line svn client and lazy load
any non-standard libraries.
--
Eric Wong
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.2.1
From: Greg KH @ 2006-02-16 21:41 UTC (permalink / raw)
To: Brown, Len; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B300614210F@hdsmsx401.amr.corp.intel.com>
On Thu, Feb 16, 2006 at 01:47:28AM -0500, Brown, Len wrote:
> Happy to notice Documentation/git-send-email
> to standardize greg's scripts, but don't see it in the release.
>
> anybody using it?
I used it to send out my last 2 round of git patches (usb and i2c). I
like it a lot better than my original script, Ryan's done a great job of
cleaning up my horrible perl code.
thanks,
greg k-h
^ permalink raw reply
* Re: Handling large files with GIT
From: Fredrik Kuivinen @ 2006-02-16 20:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Fredrik Kuivinen, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602141953081.3691@g5.osdl.org>
On Tue, Feb 14, 2006 at 07:58:03PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 14 Feb 2006, Linus Torvalds wrote:
> >
> > So in case people want to try, here's a third patch. Oh, and it's against
> > my _original_ path, not incremental to the middle one (ie both patches two
> > and three are against patch #1, it's not a nice series).
> >
> > Now I'm really done, and won't be sending out any more patches today.
>
> Still true. I've just been thinking about the last state.
>
> As far as I can tell, the output from git-merge-tree with that fix to only
> simplify subdirectories that match exactly in all of base/branch1/branch2
> is precisely the output that git-merge-recursive actually wants.
>
> Rather than doing a three-way merge with "git-read-tree", and then doing
> "git-ls-files --unmerged", I think this gives the same result much more
> efficiently.
>
> That said, I can't follow the python code, so maybe I'm missing something.
> Fredrik cc'd, in case he can put me right.
>
I don't think you miss anything. I _think_ (I haven't looked at this
too close yet) that it shouldn't be too much work to make
git-merge-recursive make use of the git-merge-tree thing.
- Fredrik
^ permalink raw reply
* [PATCH] git-svn: fix revision order when XML::Simple is not loaded
From: Eric Wong @ 2006-02-16 19:47 UTC (permalink / raw)
To: Emmanuel Guerin; +Cc: git list, Junio C Hamano
In-Reply-To: <20060216073826.GA12055@hand.yhbt.net>
Thanks to Emmanuel Guerin for finding the bug.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
98de7584b4991ab9c4025e36bfbfc10eacd17b8d
diff --git a/contrib/git-svn/git-svn b/contrib/git-svn/git-svn
index 62fc14f..ddd9579 100755
--- a/contrib/git-svn/git-svn
+++ b/contrib/git-svn/git-svn
@@ -523,7 +523,7 @@ sub svn_log_raw {
# if we have an empty log message, put something there:
if (@svn_log) {
- $svn_log[0]->{msg} ||= "\n";
+ $svn_log[$#svn_log]->{msg} ||= "\n";
}
next;
}
@@ -538,7 +538,7 @@ sub svn_log_raw {
date => "$tz $Y-$m-$d $H:$M:$S",
author => $author,
msg => '' );
- unshift @svn_log, \%log_msg;
+ push @svn_log, \%log_msg;
$state = 'msg_start';
next;
}
@@ -546,7 +546,7 @@ sub svn_log_raw {
if ($state eq 'msg_start' && /^$/) {
$state = 'msg';
} elsif ($state eq 'msg') {
- $svn_log[0]->{msg} .= $_."\n";
+ $svn_log[$#svn_log]->{msg} .= $_."\n";
}
}
close $log_fh or croak $?;
--
1.2.0.gdee6
^ permalink raw reply related
* Re: [ANNOUNCE] git-svn - bidirection operations between svn and git
From: Eric Wong @ 2006-02-16 19:25 UTC (permalink / raw)
To: Eduardo Pereira Habkost; +Cc: git list
In-Reply-To: <20060216134248.GC4271@duckman.conectiva>
Eduardo Pereira Habkost <ehabkost@mandriva.com> wrote:
> On Wed, Feb 15, 2006 at 11:38:26PM -0800, Eric Wong wrote:
> > Hello, I've written a simple tool for interoperating between git and
> > svn. I wrote this so I could use git to work on projects where other
> > developers use Subversion. I really hate using svn, but some projects I
> > work on require it, and svk isn't nearly as fast nor simple as git.
>
> Great, I was doing some testing with git-svnimport for this, but I missed
> a tool to automatically commit to svn what I have in my GIT tree.
>
> >
> > git-svn does not replace git-svnimport, git-svnimport handles branches
> > and tags automatically, but is too inflexible about repository layouts
> > to be useful for a good number of projects I follow, and of course
> > git-svnimport can't commit to Subversion repositories :)
>
> I am already using git-svnimport to keep a "mirror" of some subversion
> repositories, here (automatically udpated on crontab). Do you plan to
> allow "integration" with repositories that are just clones of
> git-svnimport'ed repositories?
It's possible, just not very obvious at the moment. git-svn was written
as quickly as possible without regard to svnimport compatibility since I
had some repos that didn't work with svnimport to begin with.
The 'ADDITIONAL FETCH ARGUMENTS' part of the manpage is worth reading
for you. Basically, you can define equalities
"(svn revision number)=(git commit)" as arguments to git-svn fetch to
add parents for all the revisions it imports.
If I were you, I'd only want git-svn to care about partial history,
since you already have the rest of it from git-svnimport. You can do
this:
svn_revno=<last svn revision number you imported from git-svnimport>
git_commit=<equivalent commit sha1 name of svn_revno above>
git-svn fetch --revision $svn_revno:HEAD $svn_revno=$git_commit
> I plan to keep using git-svnimport and the standard git tools to work
> using the "svn mirror on git" as the main repository, but I plan to use
> "git-svn commit" to commit to the SVN repositories. I want this "commit
> tool" to not affect the current repository in any way, just like git-push:
> only send the commits to the remote repository and don't change anything
> in the local repository.
> However, it seems that "git-svn commit" does some tasks assuming we
> are on a "git-svn aware" repository (e.g. the "resyncing" just after
> the commit). Would you accept patches to allow using "git-svn commit"
> to commit changes from any GIT repository (i.e. not "svn-git aware"
> repositories) to any SVN repository, just like "git-push" would work
> for a GIT repository?
>
> However, I am not sure if the easier way would be changing git-svn to
> do this for me or writing a different script just for this task.
You should be 95% there just by exporting the svn_checkout_tree()
function to the command-line. Perhaps automating reading of the
$svn_rev variable can be in order.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Fix for rpm creation
From: Petr Baudis @ 2006-02-16 16:09 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200602161659.39173.Josef.Weidendorfer@gmx.de>
Dear diary, on Thu, Feb 16, 2006 at 04:59:39PM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> So perhaps it would be good to hint the user to cg-seek in this
> error message?
That's a good idea. I added a hint there and a paragraph to cg-switch
documentation.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [PATCH] Fix for rpm creation
From: Josef Weidendorfer @ 2006-02-16 15:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060216154320.GT31278@pasky.or.cz>
On Thursday 16 February 2006 16:43, Petr Baudis wrote:
> > Another thing:
> > "cg-switch origin" currently refuses to switch to the branch.
> > Wouldn't it be better to handle this like "cg-seek origin"?
>
> Well, it depends on what you expect this to actually do. If you really
> want to just seek to whichever is the current origin commit, that's very
> different from what cg-switch does - you want cg-seek and cg-switch
> doing the same thing when it does something totally different from the
> user POV otherwise would be very confusing.
I just used it to check if you already fixed this issue yourself.
I known I should have used cg-seek, but I thought cg-switch should
allow me to do the same - I did not need to remember where I come
from.
So perhaps it would be good to hint the user to cg-seek in this
error message?
Josef
^ permalink raw reply
* Re: [PATCH] Fix for rpm creation
From: Petr Baudis @ 2006-02-16 15:43 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200602161633.44399.Josef.Weidendorfer@gmx.de>
Dear diary, on Thu, Feb 16, 2006 at 04:33:44PM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
>
> Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
>
> ---
> This fixes "make rpm", which currently gives at the very end:
> ...
> Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/cogito-0.17rc2.GIT-1-root-weidendo
> error: Installed (but unpackaged) file(s) found:
> /usr/share/cogito/default-exclude
Thanks, applied.
> Another thing:
> "cg-switch origin" currently refuses to switch to the branch.
> Wouldn't it be better to handle this like "cg-seek origin"?
Well, it depends on what you expect this to actually do. If you really
want to just seek to whichever is the current origin commit, that's very
different from what cg-switch does - you want cg-seek and cg-switch
doing the same thing when it does something totally different from the
user POV otherwise would be very confusing.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* [PATCH] Fix for rpm creation
From: Josef Weidendorfer @ 2006-02-16 15:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060216135100.GR31278@pasky.or.cz>
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
This fixes "make rpm", which currently gives at the very end:
...
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/cogito-0.17rc2.GIT-1-root-weidendo
error: Installed (but unpackaged) file(s) found:
/usr/share/cogito/default-exclude
Another thing:
"cg-switch origin" currently refuses to switch to the branch.
Wouldn't it be better to handle this like "cg-seek origin"?
Josef
cogito.spec.in | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
e483d914813413b43fd1d067ebc50d4a86c93df1
diff --git a/cogito.spec.in b/cogito.spec.in
index 1fb3b7b..50c4172 100644
--- a/cogito.spec.in
+++ b/cogito.spec.in
@@ -38,6 +38,8 @@ rm -rf $RPM_BUILD_ROOT
%{_bindir}/*
%dir %{_libdir}/cogito
%{_libdir}/cogito/*
+%dir %{_datadir}/cogito
+%{_datadir}/cogito/*
%{_mandir}/man*/*
%doc README COPYING Documentation/tutorial-script
--
1.2.0.g719b
^ permalink raw reply related
* Re: git faq : draft and rfc
From: Petr Baudis @ 2006-02-16 15:18 UTC (permalink / raw)
To: Thomas Riboulet; +Cc: git
In-Reply-To: <22e91bb0602151636r2e70e60cpa5038f4b6caccc9c@mail.gmail.com>
Dear diary, on Thu, Feb 16, 2006 at 01:36:20AM CET, I got a letter
where Thomas Riboulet <riboulet@gmail.com> said that...
> . Git commit is dying telling me "fatal : empty ident <user@myhost>
> not allowed", what's wrong ?
> Make sure your Full Name is not empty in chsh or the 5th field of your
> user line in /etc/passwd isn't empty. If you @myhost is empty make sure
> your hostname is correctly set.
Please also mention GIT_AUTHOR_NAME; chsh may be frequently unavailable.
> . What's the difference between fetch and pull ?
> Fetch : download objects and a head from another repository.
> Pull : pull and merge from another repository.
> See man git-fetch and git-pull for more.
This could do with a little more elaboration as well. Nice inspiration
might be <Pine.LNX.4.64.0602140845080.3691@g5.osdl.org>.
> . Can I tell git to ignore files ?
> Yes. Put the files path in the repository in the .git/info/exclude file.
Or .gitignore in the tree itself. .git/info/exclude is only for your
particular checkout while .gitignore is what matters for all and
everyone's checkouts of the project.
> . What can I use to setup a public repository ?
> A ssh server, an http server, or the git-daemon.
> See the tutorial for more details.
Well this is about how to make it available, not how to use it.
The repository should be set up by cg-admin-setuprepo or git-init-db
--shared and normally does not have a working tree attached. You can
fetch from such a repository either over:
* the GIT protocol (you need to run git-daemon)
* SSH (you can set up a git-use-only account using git-shell)
* rsync (has important disadvantages but it is currently the
fastest way to do the initial checkout)
* or the HTTP protocol (any reasonable webhosting will do, but
you need to run git-update-server-info after each repository
update; if you used cg-admin-setuprepo to set it up, this
will be done automatically, otherwise you may enable it in
the post-update hook - see .git/hooks/post-update).
You can push to such a repository over:
* SSH
* HTTP DAV (you will need to specially configure your HTTP
server for this)
Obviously, you can also fetch/push from/to a repository locally if it
is available in the local filesystem structure.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: git faq : draft and rfc
From: Johannes Schindelin @ 2006-02-16 15:00 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: Martin Langhoff, Thomas Riboulet, git
In-Reply-To: <4fb292fa0602160538s3f6d3c2av45dd907837b01f90@mail.gmail.com>
Hi,
On Thu, 16 Feb 2006, Bertrand Jacquin wrote:
> How old linus bk repos have been import to git ?
Using the CVS gateway, via git-cvsimport.
Hth,
Dscho
^ permalink raw reply
* Re: git faq : draft and rfc
From: Jon Loeliger @ 2006-02-16 14:32 UTC (permalink / raw)
To: git
> I'll try to add questions from the archives of this ml, I'm also open
> to any suggestions.
This is sort of the "missing" paragraph from the "git-checkout"
man page. It's there now, but in the "-m" option.
jdl
Q. Why won't git let me change to a different branch
using "git checkout <branch>" or "git checkout -b <branch>"?
Instead it just says:
fatal: Entry 'foo.c' not uptodate. Cannot merge.
A. You have changes to files in your working directory that
will be overwritten, removed or otherwise lost if the checkout
and change to the new branch were to proceed. To fix this
you may either check your changes in, create a patch of your
changes and revert your files, or use the "-m" flag like this:
git checkout -m -b my-branch
^ permalink raw reply
* [ANNOUNCE] Cogito-0.17rc2
From: Petr Baudis @ 2006-02-16 13:51 UTC (permalink / raw)
To: git
Hello,
here comes Cogito version 0.17rc1, the human-friendly version control
UI for Linus' GIT tool. Share and enjoy at:
http://www.kernel.org/pub/software/scm/cogito/
Few bugfixes and actually few minor features compared to 0.17rc1.
You're encouraged to upgrade if you are using 0.17rc2. I am receiving
less bugreports than what I have expected, which either means there are
no bugs (hah!) or that noone cares about the rcs (more likely). So if
there will be no bugreports in two or three days, I'll make this the
final 0.17.
The notable new stuff includes:
* cg-clean -d fix (do not clean the contents of untracked directories)
* cg-log -d renamed to cg-log -D, please fix your scripts and retrain
your fingers if you actually use it regularily
* cg-commit -M to load the commit message from a file
* cg-commit -f will commit even if you are seeked
* Fix repeated cg-seek <commit> invocations
* Fix pushing to symlinked repositories (it was racy before and would
not deal appropriately with permissions)
* Random documentation improvements
$ cg-log --summary -r cogito-0.17rc1..
Jonas Fonseca:
cg-commit: use -- to delimit paths args to git-diff-index for --review
cg-status: pretty-print heads using printf
Add warn function which can beep; use it to generalise warnings
Pavel Roskin:
[PATCH 1/2] cg-clean shouldn't clean untracked directories without -d
[PATCH 2/2] Workaround git < 1.2.0 ignoring .gitignore in parent directories
Petr Baudis:
0.17rc1.GIT
Doc clarification.
Do not list cg-object-id in helper commands
Fix shortdesc.
Rename cg-log -d to cg-log -D
Network together the cg-switch,cg-seek,cg-admin-uncommit docs
Refuse to uncommit merges, redirect the user to cg-switch
Simplify the editor testing code
Warn about seeking to a branch head
cg-commit -M to take the commit message from a file
cg-commit -f will override cg-seek's blocking
Hint cg-switch -n to save the volatile commit
Automatically determine cg-status headname column width
Fix cg-seek re-seeking
Remove the obsolete umask mention
Fix pushing to symlinked repositories
cogito-0.17rc2
P.S.: See us at #git @ FreeNode!
Happy hacking,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: git faq : draft and rfc
From: Bertrand Jacquin @ 2006-02-16 13:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, Thomas Riboulet, git
In-Reply-To: <Pine.LNX.4.63.0602161421320.18016@wbgn013.biozentrum.uni-wuerzburg.de>
How old linus bk repos have been import to git ?
On 2/16/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 16 Feb 2006, Martin Langhoff wrote:
>
> > + Can I import from others? Maybe -- check if tailor.py can do it.
>
> + What is tailor.py? http://www.darcs.net/DarcsWiki/Tailor.
>
> Hth,
> Dscho
>
> -
> 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
>
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: [ANNOUNCE] git-svn - bidirection operations between svn and git
From: Eduardo Pereira Habkost @ 2006-02-16 13:42 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20060216073826.GA12055@hand.yhbt.net>
[-- Attachment #1: Type: text/plain, Size: 2676 bytes --]
On Wed, Feb 15, 2006 at 11:38:26PM -0800, Eric Wong wrote:
> Hello, I've written a simple tool for interoperating between git and
> svn. I wrote this so I could use git to work on projects where other
> developers use Subversion. I really hate using svn, but some projects I
> work on require it, and svk isn't nearly as fast nor simple as git.
Great, I was doing some testing with git-svnimport for this, but I missed
a tool to automatically commit to svn what I have in my GIT tree.
>
> git-svn does not replace git-svnimport, git-svnimport handles branches
> and tags automatically, but is too inflexible about repository layouts
> to be useful for a good number of projects I follow, and of course
> git-svnimport can't commit to Subversion repositories :)
I am already using git-svnimport to keep a "mirror" of some subversion
repositories, here (automatically udpated on crontab). Do you plan to
allow "integration" with repositories that are just clones of
git-svnimport'ed repositories?
I plan to keep using git-svnimport and the standard git tools to work
using the "svn mirror on git" as the main repository, but I plan to use
"git-svn commit" to commit to the SVN repositories. I want this "commit
tool" to not affect the current repository in any way, just like git-push:
only send the commits to the remote repository and don't change anything
in the local repository.
However, it seems that "git-svn commit" does some tasks assuming we
are on a "git-svn aware" repository (e.g. the "resyncing" just after
the commit). Would you accept patches to allow using "git-svn commit"
to commit changes from any GIT repository (i.e. not "svn-git aware"
repositories) to any SVN repository, just like "git-push" would work
for a GIT repository?
However, I am not sure if the easier way would be changing git-svn to
do this for me or writing a different script just for this task.
>
> git-svn only cares about a single branch/trunk in SVN[1], but you can
> use as many branches in git as you want. This makes it much easier to
> use and allows it to handle just about any repository layout, not just
> those recommended in the SVN book/developers.
>
> Although importing changesets from SVN is mostly a linear affair,
> committing to SVN is the opposite. You may commit git tree objects in
> any order you want. It simply clobbers the existing svn tree as
> 'git-checkout -f' would, but tags file renames/copies carefully so users
> on the SVN side can see them. You can even do some wacky things with
> patch reordering.
Good, this is what I expect to be able to do when commiting to svn.
--
Eduardo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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