* The smartest way to save money, buy Viagra online.
From: Sandy Benton @ 2006-05-16 11:29 UTC (permalink / raw)
To: git
We guarantee the quality and safety of all medications ordered.
http://dtc.pxvxuguuv4uf7p7icppiu7p7.myrciaid.com/?nizjfaylh
^ permalink raw reply
* [PATCH] Simplify packing public repositories
From: Timo Hirvonen @ 2006-05-16 11:46 UTC (permalink / raw)
To: junkio; +Cc: git
Support "git repack project.git" syntax which is more intuitive than
using the GIT_DIR environment variable.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
git-repack.sh | 27 ++++++++++++++++++++++++---
1 files changed, 24 insertions(+), 3 deletions(-)
c09c41750023e5b502312ddaa21bf5a2371e66ac
diff --git a/git-repack.sh b/git-repack.sh
index 4fb3f26..b24cd1a 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -3,8 +3,8 @@ #
# Copyright (c) 2005 Linus Torvalds
#
-USAGE='[-a] [-d] [-f] [-l] [-n] [-q]'
-. git-sh-setup
+unset CDPATH
+USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [GIT_DIR]'
no_update_info= all_into_one= remove_redundant=
local= quiet= no_reuse_delta= extra=
@@ -19,11 +19,32 @@ do
-l) local=--local ;;
--window=*) extra="$extra $1" ;;
--depth=*) extra="$extra $1" ;;
- *) usage ;;
+ -h|--h|--he|--hel|--help)
+ echo "Usage: $0 $USAGE"
+ exit
+ ;;
+ *)
+ if test "$#" -gt 1
+ then
+ echo >&2 "Usage: $0 $USAGE"
+ exit 1
+ fi
+ export GIT_DIR="$1"
+ ;;
esac
shift
done
+: ${GIT_DIR=.git}
+: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
+
+# Make sure we are in a valid repository of a vintage we understand.
+GIT_DIR="$GIT_DIR" git repo-config --get core.nosuch >/dev/null
+if test $? = 128
+then
+ exit
+fi
+
rm -f .tmp-pack-*
PACKDIR="$GIT_OBJECT_DIRECTORY/pack"
--
1.3.3.g8701-dirty
^ permalink raw reply related
* Re: [PATCH] Simplify packing public repositories
From: Sean @ 2006-05-16 11:47 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: junkio, git
In-Reply-To: <20060516144635.010bb65f.tihirvon@gmail.com>
On Tue, 16 May 2006 14:46:35 +0300
Timo Hirvonen <tihirvon@gmail.com> wrote:
> Support "git repack project.git" syntax which is more intuitive than
> using the GIT_DIR environment variable.
>
There are a few commands that would benefit from being easier to run
in a bare repository. If this option was added to the "git" wrapper
rather than git-repack, it would work for all of them. But maybe
git could just automatically recognize when it's in a bare repository.
Sean
^ permalink raw reply
* Fwd: [OT] Re: Git via a proxy server?
From: Sam Song @ 2006-05-16 12:13 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: git
Hello,
Petr Vandrovec <petr@vmware.com> wrote:
> Date: Mon, 27 Feb 2006 00:35:00 +0100
> From: Petr Vandrovec <petr@vmware.com>
> To: Sergey Vlasov <vsu@altlinux.ru>
> CC: "Salyzyn, Mark" <mark_salyzyn@adaptec.com>,
> Kernel Mailing List
> <linux-kernel@vger.kernel.org>
> > [snip]
> > I have successfully used transconnect
> > (http://sourceforge.net/projects/transconnect) for
> > tunnelling git
> > protocol through a HTTP proxy (squid in my case)
> > supporting the CONNECT method.
> >
> > [snip]
> > Note: most HTTP proxy servers allow CONNECT method
> > to a very limited range of ports, and
> > administrators will need to enable the git port
> > (9418) explicitly.
> >
> I know I'm coming kinda late, but I'm using:
>
> export GIT_PROXY_COMMAND=/usr/local/bin/proxy-cmd.sh
>
> and proxy-cmd.sh is just single-line command glued
> from what I found available in /bin:
>
> #! /bin/bash
>
> (echo "CONNECT $1:$2 HTTP/1.0"; echo; cat ) | socket
>
> proxy.ourcompany.com 3128 | (read a; read a; cat )
>
> Replace socket's arguments 'proxy.ourcompany.com
> 3128' with your http proxy. Fortunately our proxy
> does not see anything wrong with git's port.
> Best regards,
> Petr Vandrovec
With above usage on GIT_PROXY_COMMAND, I still have
problem on connection with remote git repository.
I also tried setting http_proxy directly but the same
result. It's first usage of git in our network. Well,
need I enable the git port 9418 at proxy server? Or
did I miss sth or what?
I use git-2006-05-14.tar.gz package on FC3.
Method I : Use GIT_PROXY_COMMAND
[root@sam u-boot]# git clone \
git://www.denx.de/git/u-boot.git u-boot-denx.git
fatal: exec failed
fetch-pack from 'git://www.denx.de/git/u-boot.git'
failed.
[root@sam u-boot]# git clone \
http://parisc-linux.org/git/linux-2.6.git/ parisc-2.6
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
[root@sam u-boot]#
/usr/local/bin/proxy-cmd.sh
#! /bin/bash
(echo "CONNECT $1:$2 HTTP/1.0";echo;cat) | socket
<um> <pwd> 192.168.40.99 80 | (read a;read a;cat)
Method II : Use http_proxy directly
[root@sam u-boot]# export \
http_proxy="http://<username>:<pwd>@192.168.40.99:80"
[root@sam u-boot]# git clone \
http://parisc-linux.org/git/linux-2.6.git/ parisc-2.6
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
[root@sam u-boot]# git clone \
git://www.denx.de/git/u-boot.git u-boot-denx.git
fatal: unable to connect a socket (Connection timed
out)
fetch-pack from 'git://www.denx.de/git/u-boot.git'
failed.
[root@sam u-boot]#
Thanks in advance,
Sam
P.S. I forward this thread from LKML for better
discussion. Hope Petr wouldn't mind.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: gateway status?
From: Martin Langhoff @ 2006-05-16 13:09 UTC (permalink / raw)
To: David Lang; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0605151122500.29452@qynat.qvtvafvgr.pbz>
On 5/16/06, David Lang <dlang@digitalinsight.com> wrote:
> I seem to remember seeing discussion of gateways to cvs/svn that would let
> a project use a git repository and allow clients to use cvs/svn clients to
> retreive data.
David,
I suspect you might be thinking of git-cvsserver. The code has no
known bugs, but is has only seen limited use by in-house dev teams.
A good measure is to run an import of the current cvs project (I would
try both git-cvsimport and parsecvs) and then get a checkout via
git-cvsserver.
Works great with traditional cvs cli and well behaved clients (TortoiseCVS).
> am I remembering correctly, and are these tools ready for production use?
> the popfile project is getting ready to abandon sourceforge and move to
> self-hosting, but before I suggest that they use git I need to know the
> current status of these projects (I think the ability to export directly
> into the other interfaces is a significant advantage)
Moodle (a project I hack on) is in a similar situation, specially
after the SF.net debacle with CVS. It is very likely that it will move
to git with git-cvsserver providing "anon cvs" and cvs over ssh to a
very limited set of people with commit rights but no development
knowledge (translators, etc). So there is a path forward.
cheers,
martin
^ permalink raw reply
* Re: Fwd: [OT] Re: Git via a proxy server?
From: Petr Vandrovec @ 2006-05-16 13:11 UTC (permalink / raw)
To: Sam Song; +Cc: git
In-Reply-To: <20060516121356.11646.qmail@web32002.mail.mud.yahoo.com>
Sam Song wrote:
> Hello,
>
> Petr Vandrovec <petr@vmware.com> wrote:
>
>>Date: Mon, 27 Feb 2006 00:35:00 +0100
>>From: Petr Vandrovec <petr@vmware.com>
>>To: Sergey Vlasov <vsu@altlinux.ru>
>>CC: "Salyzyn, Mark" <mark_salyzyn@adaptec.com>,
>> Kernel Mailing List
>><linux-kernel@vger.kernel.org>
>>
>>>[snip]
>>>I have successfully used transconnect
>>>(http://sourceforge.net/projects/transconnect) for
>>>tunnelling git
>>>protocol through a HTTP proxy (squid in my case)
>>>supporting the CONNECT method.
>>>
>>>[snip]
>>>Note: most HTTP proxy servers allow CONNECT method
>>>to a very limited range of ports, and
>>>administrators will need to enable the git port
>>>(9418) explicitly.
>>>
>>
>>I know I'm coming kinda late, but I'm using:
>>
>>export GIT_PROXY_COMMAND=/usr/local/bin/proxy-cmd.sh
>>
>>and proxy-cmd.sh is just single-line command glued
>>from what I found available in /bin:
>>
>>#! /bin/bash
>>
>>(echo "CONNECT $1:$2 HTTP/1.0"; echo; cat ) | socket
>>
>>proxy.ourcompany.com 3128 | (read a; read a; cat )
>>
>>Replace socket's arguments 'proxy.ourcompany.com
>>3128' with your http proxy. Fortunately our proxy
>>does not see anything wrong with git's port.
>> Best regards,
>> Petr Vandrovec
>
>
> With above usage on GIT_PROXY_COMMAND, I still have
> problem on connection with remote git repository.
>
> I also tried setting http_proxy directly but the same
> result. It's first usage of git in our network. Well,
> need I enable the git port 9418 at proxy server? Or
> did I miss sth or what?
Yes. Try running 'socket 192.168.40.99 80', and type
CONNECT 204.152.191.37:9418 HTTP/1.0
Proxy-Authorization: Basic <yoursecret,f.e.wget -d should reveal this to you>
<empty line>
You should get back user readable diagnostics what went wrong. Yes, your admin
must allow CONNECT method for target port 9418.
> I use git-2006-05-14.tar.gz package on FC3.
>
> Method I : Use GIT_PROXY_COMMAND
>
> [root@sam u-boot]# git clone \
> git://www.denx.de/git/u-boot.git u-boot-denx.git
>
> fatal: exec failed
> fetch-pack from 'git://www.denx.de/git/u-boot.git'
> failed.
Is $GIT_PROXY_COMMAND executable? (just in case...) Try 'strace -f git clone
...', it should tell you what's going on.
> #! /bin/bash
>
> (echo "CONNECT $1:$2 HTTP/1.0";echo;cat) | socket
> <um> <pwd> 192.168.40.99 80 | (read a;read a;cat)
What is '<um>' and '<pwd>' ? socket just connects somewhere, so if you are
supposed to use <username>:<pwd> to connect to your proxy, you must add
Proxy-Authorization header yourself:
(echo "CONNECT $1:$2 HTTP/1.0";
echo "Proxy-Authorization: Basic <base64encoded um:pwd>";
echo;
cat ) | socket 192.168.40.99 80 | (read a; read a; cat)
Best to test this is to start 'socket 192.168.40.99 80' from command line and
then type these two lines above, plus one empty line. You should get back '200
OK', empty line, and then you can start communicating using git protocol - if
you can do that...
> Method II : Use http_proxy directly
>
> [root@sam u-boot]# export \
> http_proxy="http://<username>:<pwd>@192.168.40.99:80"
> [root@sam u-boot]# git clone \
> http://parisc-linux.org/git/linux-2.6.git/ parisc-2.6
As far as I can tell, http_proxy is ignored (Debian's git 1.3.2-1/cogito 0.17.2-1).
Petr
^ permalink raw reply
* Re: [PATCH] commit: allow --pretty= args to be abbreviated
From: Eric Wong @ 2006-05-16 13:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac9jhv66.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Unlike the original one, this one only does prefix matches, so
> > you can't do --pretty=er anymore :)
>
> Sounds good. But then you know how long the unique prefix
> are for each candidate, so wouldn't this rather be redundant, I
> wonder?
I just copied the idea for the 2nd for loop from gitopt, since it makes
maintenance easier when there are lots of possibilities. We only have 6
(soon 7) to worry about for --pretty= here, so hard coding lengths
probably makes more sense.
> > +
> > + /* look for abbreviations */
> > + len = strlen(arg);
> > + found = -1;
> > + for (i = 0; i < ARRAY_SIZE(cmt_fmts); i++) {
> > + if (!strncmp(cmt_fmts[i].n, arg, len)) {
> > + if (found >= 0)
> > + die("invalid --pretty format: %s", arg);
> > + found = i;
> > + }
> > + }
> > + if (found >= 0)
> > + return cmt_fmts[found].v;
> > + die("invalid --pretty format: %s", arg);
> > }
>
> It would probably be better to say "ambiguous" not "invalid" in
> the die() message.
Yes, but only one die() message left now :)
--
Eric Wong
>From nobody Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sun, 14 May 2006 17:20:46 -0700
Subject: [PATCH] commit: allow --pretty= args to be abbreviated
Unlike the original one, this one only does prefix matches, so
you can't do --pretty=er anymore :)
This one really works with and without the gitopt changes.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
commit.c | 38 ++++++++++++++++++++++++--------------
1 files changed, 24 insertions(+), 14 deletions(-)
044dff6523c25e173eb7fb1c5d5c8a8e6ada8fdc
diff --git a/commit.c b/commit.c
index 2717dd8..4a26070 100644
--- a/commit.c
+++ b/commit.c
@@ -22,23 +22,33 @@ struct sort_node
const char *commit_type = "commit";
+struct cmt_fmt_map {
+ const char *n;
+ size_t cmp_len;
+ enum cmit_fmt v;
+} cmt_fmts[] = {
+ { "raw", 1, CMIT_FMT_RAW },
+ { "medium", 1, CMIT_FMT_MEDIUM },
+ { "short", 1, CMIT_FMT_SHORT },
+ { "full", 5, CMIT_FMT_FULL },
+ { "fuller", 5, CMIT_FMT_FULLER },
+ { "oneline", 1, CMIT_FMT_ONELINE },
+};
+
enum cmit_fmt get_commit_format(const char *arg)
{
- if (!*arg)
+ int i;
+
+ if (!arg || !*arg)
return CMIT_FMT_DEFAULT;
- if (!strcmp(arg, "=raw"))
- return CMIT_FMT_RAW;
- if (!strcmp(arg, "=medium"))
- return CMIT_FMT_MEDIUM;
- if (!strcmp(arg, "=short"))
- return CMIT_FMT_SHORT;
- if (!strcmp(arg, "=full"))
- return CMIT_FMT_FULL;
- if (!strcmp(arg, "=fuller"))
- return CMIT_FMT_FULLER;
- if (!strcmp(arg, "=oneline"))
- return CMIT_FMT_ONELINE;
- die("invalid --pretty format");
+ if (*arg == '=')
+ arg++;
+ for (i = 0; i < ARRAY_SIZE(cmt_fmts); i++) {
+ if (!strncmp(arg, cmt_fmts[i].n, cmt_fmts[i].cmp_len))
+ return cmt_fmts[i].v;
+ }
+
+ die("invalid --pretty format: %s", arg);
}
static struct commit *check_commit(struct object *obj,
--
1.3.2.g7d11
^ permalink raw reply related
* Re: gateway status?
From: Jakub Narebski @ 2006-05-16 13:54 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.62.0605151122500.29452@qynat.qvtvafvgr.pbz>
David Lang wrote:
> I seem to remember seeing discussion of gateways to cvs/svn that would let
> a project use a git repository and allow clients to use cvs/svn clients to
> retreive data.
>
> am I remembering correctly, and are these tools ready for production use?
Eric Wong <normalperson@yhbt.net> wrote:
in "[0/2 PATCH] git-svn 1.0.0 release" thread
http://permalink.gmane.org/gmane.comp.version-control.git/19644
> It's been very solid for a long time now. I haven't run into
> any problems with it myself in a while, and no critical bugs
> that I know of exist. Labeling it 1.0.0 may make it look
> less scary to new users :)
So I guess yes, they are.
P.S. IIRC git-cvsserver is used as temporary "Git plugin" for Eclipse, and
there are some problems with that due to the cvs client/server
implementation in Eclipse.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] Update the documentation for git-merge-base
From: Linus Torvalds @ 2006-05-16 15:32 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Junio C Hamano, git
In-Reply-To: <20060516065452.GA5540@c165.ib.student.liu.se>
On Tue, 16 May 2006, Fredrik Kuivinen wrote:
>
> By "least" I mean the following:
>
> C is a least common ancestor of A and B if:
>
> * C is a common ancestor of A and B, and
> * for every other common ancestor D (different from C) of A and B, C
> is not reacheable from D.
Yes, git-merge-base should always return a least common ancestor, never
anything less. The only question is what happens when there are multiple
LCA commits.
In fact, even in that case git-merge-base will have a pretty strong
specification:
"git-merge-base with the '--all' flag will return the complete set of
least common ancestors, sorted by most recent (as defined purely by
the commit date order, not any graph ordering) first.
Without the '--all' flag, it will return just one LCA commit (the most
recent one, by the same date-based definition).
In the case two or more LCA commits have exactly the same committer
date, the ordering between them is arbitrary"
I don't think you can be more specific, or do a better job. The definition
of "most recent" is arbitrary, of course - and going by commit date is
just _one_ way to order them, but it happens to be an easy one, and one
that is as good as any other choice.
Of course, the defined ordering probably really matters only for the case
where we return just one LCA out of many, but it's nice to be able to tell
what the order will be even for the multi-commit case.
> There are two examples at the top of the source. In the first one a
> least common ancestor is returned. As I interpret the second one, it
> is an example of how the old algorithm without the postprocessing step
> produced a common ancestor which is not least.
Correct. We used to occasionally get it wrong, and return a common
ancestor that wasn't least.
> Am I wrong? Do we have any cases where the current merge-base
> algorithm gives us common ancestors which are not least?
Modulo bugs, no. And I don't think there are any bugs in that respect.
Linus
^ permalink raw reply
* Re: [PATCH] Update the documentation for git-merge-base
From: Linus Torvalds @ 2006-05-16 16:32 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605160821570.3866@g5.osdl.org>
On Tue, 16 May 2006, Linus Torvalds wrote:
>
> I don't think you can be more specific, or do a better job. The definition
> of "most recent" is arbitrary, of course - and going by commit date is
> just _one_ way to order them, but it happens to be an easy one, and one
> that is as good as any other choice.
Side note: since LCA's are (by definition) never going to have a direct
graph relationship, there is obviously no ordering enforced by the graph
itself. So they're all unordered in the graph sense, but you could use
other measures of "distance" in the graph.
Example other orderings that we _could_ do, and I considered (some purely
graph based, others based on content):
- order by number of commits between the LCA and the two commits that we
are trying to find the LCA for (the "tips").
- order by diff size between the LCA and the tips
- order by lack of conflicts between the LCA and the tips.
however, none of the alternate orderings really seem to make a lot of
sense.
The date-based one trumps them all by being straightforward and simple to
both implement and explain. And iirc, I actually verified that it happened
to pick the "better" one for at least one of my tests when using the old
stupid straigth three-way merge, so I think it was actually objectively a
good measure at least once.
Anybody who cares can obviously always just do "git-merge-base --all" and
do their own sorting for the (relatively unlikely) case that you get more
than one parent.
Anyway, just out of interest I just did some statistics using some shell
scripts:
- For the current kernel tree, of 1857 merges, only 17 had more than one
merge base (and none had more than two):
1840 o
17 oo
- In contrast, for git (current master branch), the numbers are 35 out of
540, and there are lots of merges with many LCA's:
505 o
15 oo
13 ooo
2 oooo
3 ooooo
2 ooooooo
I think the difference is that Junio does a lot of these branches where he
keeps on pulling from them, and never syncs back (which is a great
workflow). In contrast, the kernel tends to try to avoid that because the
history gets messy enough as it is ;)
Anyway, the two commits that apparently have seven (!) LCA's in the git
tree should probably be checked out. They are probably a good thing to see
if git-merge-base really _really_ does the right thing, and whether they
really are true LCA's.
They are commits ad0b46bf.. and e6a933bd.. respectively.
Linus
^ permalink raw reply
* [PATCH] Implement git-quiltimport
From: Eric W. Biederman @ 2006-05-16 16:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Importing a quilt patch series into git is not very difficult
but parsing the patch descriptions and all of the other
minutia take a bit of effort to get right, so this automates it.
Since git and quilt complement each other it makes sense
to make it easy to go back and forth between the two.
---
Eric
Documentation/git-quiltimport.txt | 50 +++++++++++++++++++++
Makefile | 2 -
git-quiltimport.sh | 88 +++++++++++++++++++++++++++++++++++++
3 files changed, 139 insertions(+), 1 deletions(-)
create mode 100644 Documentation/git-quiltimport.txt
create mode 100644 git-quiltimport.sh
2256c7e9b3913732a5c3a2e54cdea20fc951b76d
diff --git a/Documentation/git-quiltimport.txt b/Documentation/git-quiltimport.txt
new file mode 100644
index 0000000..8ea20eb
--- /dev/null
+++ b/Documentation/git-quiltimport.txt
@@ -0,0 +1,50 @@
+git-quiltimport(1)
+================
+
+NAME
+----
+git-quiltimport - Applies a quilt patchset onto the current branch
+
+
+SYNOPSIS
+--------
+[verse]
+'git-quiltimport' [--author <author>] [--patches <dir>]
+
+
+DESCRIPTION
+-----------
+Applies a quilt patchset onto the current git branch, preserving
+the patch boundaries, patch order, and patch descriptions present
+in the quilt patchset.
+
+For each patch the code attempts to extract the author from the
+patch description. If that fails it falls back to the author
+specified with --author. If the --author flag was not given
+the the author is recorded as unknown.
+
+The patch name is preserved as the 1 line subject in the git
+description.
+
+OPTIONS
+-------
+--author Author Name <Author Email>::
+ The author name and email address to use when no author
+ information can be found in the patch description.
+
+--patches <dir>::
+ The directory to find the quilt patches and the
+ quilt series file.
+
+Author
+------
+Written by Eric Biederman <ebiederm@lnxi.com>
+
+Documentation
+--------------
+Documentation by Eric Biederman <ebiederm@lnxi.com>
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index 37fbe78..1f4abe6 100644
--- a/Makefile
+++ b/Makefile
@@ -125,7 +125,7 @@ SCRIPT_SH = \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh git-grep.sh \
- git-lost-found.sh
+ git-lost-found.sh git-quiltimport.sh
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
new file mode 100644
index 0000000..534be82
--- /dev/null
+++ b/git-quiltimport.sh
@@ -0,0 +1,88 @@
+#!/bin/sh
+USAGE='--author <author> --patches </path/to/quilt/patch/directory>'
+SUBDIRECTORY_ON=Yes
+. git-sh-setup
+
+quilt_author="Unknown <unknown>"
+while case "$#" in 0) break;; esac
+do
+ case "$1" in
+ --au=*|--aut=*|--auth=*|--autho=*|--author=*)
+ quilt_author=$(expr "$1" : '-[^=]*\(.*\)')
+ shift
+ ;;
+
+ --au|--aut|--auth|--autho|--author)
+ case "$#" in 1) usage ;; esac
+ shift
+ quilt_author="$1"
+ shift
+ ;;
+
+ --pa=*|--pat=*|--patc=*|--patch=*|--patche=*|--patches=*)
+ QUILT_PATCHES=$(expr "$1" : '-[^=]*\(.*\)')
+ shift
+ ;;
+
+ --pa|--pat|--patc|--patch|--patche|--patches)
+ case "$#" in 1) usage ;; esac
+ shift
+ QUILT_PATCHES="$1"
+ shift
+ ;;
+
+ *)
+ break
+ ;;
+ esac
+done
+
+# Quilt Author
+quilt_author_name=$(expr "z$quilt_author" : 'z\(.*[^ ]\) *<.*') &&
+quilt_author_email=$(expr "z$quilt_author" : '.*\(<.*\)') &&
+test '' != "$quilt_author_name" &&
+test '' != "$quilt_author_email" ||
+die "malformatted --author parameter"
+
+# Quilt patch directory
+: ${QUILT_PATCHES:=patches}
+if ! [ -d "$QUILT_PATCHES" ] ; then
+ echo "The \"$QUILT_PATCHES\" directory does not exist."
+ exit 1
+fi
+
+# Temporay directories
+tmp_dir=.dotest
+tmp_msg="$tmp_dir/msg"
+tmp_patch="$tmp_dir/patch"
+tmp_info="$tmp_dir/info"
+
+
+# Find the intial commit
+commit=$(git-rev-parse HEAD)
+
+mkdir $tmp_dir || exit 2
+cat "$QUILT_PATCHES/series" | grep -v '^#' |
+while read line ; do
+ echo $line
+ (cat $QUILT_PATCHES/$line | git-mailinfo "$tmp_msg" "$tmp_patch" > "$tmp_info") || exit 3
+
+ # Parse the author information
+ export GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
+ export GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
+ if [ -z "$GIT_AUTHOR_EMAIL" ] ; then
+ GIT_AUTHOR_NAME=$quilt_author_name
+ GIT_AUTHOR_EMAIL=$quilt_author_email
+ fi
+ export GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' "$tmp_info")
+ export SUBJECT=$(sed -ne 's/Subject: //p' "$tmp_info")
+ if [ -z "$SUBJECT" ] ; then
+ SUBJECT=$(echo $line | sed -e 's/.patch$//')
+ fi
+
+ git-apply --index -C1 "$tmp_patch" &&
+ tree=$(git-write-tree) &&
+ commit=$((echo "$SUBJECT"; echo; cat "$tmp_msg") | git-commit-tree $tree -p $commit) &&
+ git-update-ref HEAD $commit || exit 4
+done
+rm -rf $tmp_dir || exit 5
--
1.3.2.g2256
^ permalink raw reply related
* Re: [PATCH] Implement git-quiltimport
From: Linus Torvalds @ 2006-05-16 17:03 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1k68l6hga.fsf@ebiederm.dsl.xmission.com>
On Tue, 16 May 2006, Eric W. Biederman wrote:
>
> If the --author flag was not given the the author is recorded as
> unknown.
Please don't do this. Just error out. It would be horrible to have a quilt
import "succeed", and then later notice that some of the patches had
incorrect authorship attribution just because the import script didn't
check it, but just made it "unknown".
An un-attributed patch is simply not acceptable in any serious project.
It's much better to consider it an error than to say "ok".
Linus
^ permalink raw reply
* git-svn vs. $Id$
From: Tommi Virtanen @ 2006-05-16 17:33 UTC (permalink / raw)
To: git
Hi. I just ran into trouble with git-svn, related to a file
containing $Id$. Yes, I know $Id$ sucks and should be avoided,
and I'll be removing them shortly, but that doesn't change the
fact that the history contains files with them.
Just wanted to let you know of a workaround:
manually edit the relevant file in .git/git-svn/tree/ to
undo the $Id$ change, and git-svn fetch works again.
$ git-svn fetch
Tree mismatch, Got: c242bb60d78c1dfce133e0bbaca7f13895de00b2, Expected:
07d35ac911cc56aabea86f4467cafc1d92b724c4
at /home/tv/bin/git-svn line 426
main::assert_tree('a5890d459de08dc8adbbe34cdfb4b1f44f377ad8')
called at /home/tv/bin/git-svn line 392
main::assert_svn_wc_clean(2039,
'a5890d459de08dc8adbbe34cdfb4b1f44f377ad8') called at
/home/tv/bin/git-svn line 262
main::fetch() called at /home/tv/bin/git-svn line 105
$ git diff-tree -p 07d35ac911cc56aabea86f4467cafc1d92b724c4 \
c242bb60d78c1dfce133e0bbaca7f13895de00b2
diff --git a/anonymized b/anonymized
index 16b3988..f43782a 100644
--- a/anonymized
+++ b/anonymized
@@ -1,4 +1,4 @@
-## $Id: anonymized 1775 2006-04-20 09:25:22Z tv $
+## $Id: anonymized 2025 2006-05-16 07:25:24Z tv $
blah
blah
So editing .git/git-svn/tree/anonymized and replacing
"1775 2006-04-20 09:25:22Z tv" with "2025 2006-05-16 07:25:24Z tv"
make git-svn happy again.
--
Inoi Oy, Tykistökatu 4 D (4. krs), FI-20520 Turku, Finland
http://www.inoi.fi/
Mobile +358 40 762 5656
^ permalink raw reply related
* Re: git-svn vs. $Id$
From: Linus Torvalds @ 2006-05-16 17:48 UTC (permalink / raw)
To: Tommi Virtanen; +Cc: git
In-Reply-To: <446A0CCF.2060903@inoi.fi>
On Tue, 16 May 2006, Tommi Virtanen wrote:
>
> Just wanted to let you know of a workaround:
> manually edit the relevant file in .git/git-svn/tree/ to
> undo the $Id$ change, and git-svn fetch works again.
Isn't there some flag to svn to avoid keyword expansion, like "-ko" to
CVS?
Any import script definitely should avoid keyword expansion (and that's
true whether you end up wanting to use keywords or not).
(And yes, CVS is probably a bad example. Those "substitution modes" are
confusing as hell, and I don't know which one is the right one. Is it
"-ko" or "-kk"? Don't ask me, I'm CVS-illiterate. I don't know why the
current cvsimport uses -kk, and only does it conditionally. Whatever.)
Linus
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport
From: Eric W. Biederman @ 2006-05-16 17:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605161001190.3866@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 16 May 2006, Eric W. Biederman wrote:
>>
>> If the --author flag was not given the the author is recorded as
>> unknown.
>
> Please don't do this. Just error out. It would be horrible to have a quilt
> import "succeed", and then later notice that some of the patches had
> incorrect authorship attribution just because the import script didn't
> check it, but just made it "unknown".
>
> An un-attributed patch is simply not acceptable in any serious project.
> It's much better to consider it an error than to say "ok".
There are two practical problems with this.
1) quilt does not force any authorship information to be preserved,
in the description, so this probably a common case. Although for
most users just needing to specify --author sounds reasonable.
2) There are currently 84 out of roughly 1322 patches in
2.6.17-rc4-mm1 that git-mailinfo cannot compute the author for.
Generally the information is there but in such an irregular form
that it cannot be automatically detected.
If we can resolve that problem I am willing to make it an error.
If we can't then sucking quilt patches into a git tree is much
less useful.
Given the ugliness in -mm making it an error to have an
non-attributed patch would result in people specifying --author
when they really don't know who the author is, giving us much
less reliable information.
Possibly what we need is an option to not make it an error so that
people doing this kind of thing in their own trees have useful
information.
The list of patches that git-mailinfo cannot find authorship
information for from 2.6.17-rc4-mm1 is included below. Mostly these
are either git trees splatted into a single file, or simply fixes
added by Andrew. But there are some like: gregkh-usb-usb-gotemp
that have no description at all and only the patch name records who
made the patch.
A really ugly case is acx1xx-wireless-driver patch, which
appears to have multiple authors and a serious history
before Andrew got it.
>From acx1xx-wireless-driver.patch
> acx100.sourceforge.net (Andreas Mohr <andi@rhlx01.fht-esslingen.de>) ->
> -> Denis Vlasenko <vda@ilport.com.ua>
> -> Jeff Garzik <jgarzik@pobox.com>
> -> me
>
> DESC
> acx1xx-wireless-driver-usb-is-bust
> EDESC
> From: Andrew Morton <akpm@osdl.org>
>
> drivers/net/wireless/tiacx/usb.c:1116: `URB_ASYNC_UNLINK' undeclared (first use in this function)
>
> Cc: Denis Vlasenko <vda@ilport.com.ua>
> DESC
> acx1xx-allow-modular-build
> EDESC
> From: Andrew Morton <akpm@osdl.org>
> DESC
> acx1xx-wireless-driver-spy_offset-went-away
> EDESC
> From: Andrew Morton <akpm@osdl.org>
>
> Cc: Denis Vlasenko <vda@ilport.com.ua>
> DESC
> acx update
> EDESC
> From: Denis Vlasenko <vda@ilport.com.ua>
>
> > > Attached is a patch which updates acx. All your changes are
> > > included too. allyesconfig build is fixed by unifying
> > > PCI and USB modules into one. 'acx_debug' parameter is renamed back
> > > to just 'debug' (because all previous versions used it and
> > > we don't want to add to user confusion).
> > >
> > > Please apply.
> > >
> > > Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
> >
> > I missed a spy_offset fix. Updated patch is attached.
> > Also it is at
> > http://195.66.192.167/linux/acx_patches/linux-2.6.13-mm2acx-2.patch.bz2
>
> Oh no. Yes. I forgot to remove some standalone build aids.
>
> DESC
> acx-update 2
> EDESC
> From: Denis Vlasenko <vda@ilport.com.ua>
>
> [20051016] 0.3.13
> * Revert 20051013 fix, we have one which actually works.
> Thanks Jacek Jablonski <yacek87@gmail.com> for testing!
>
> [20051013]
> * trying to fix "yet another similar bug"
> * usb fix by Carlos Martin
>
> [20051012] 0.3.12
> * acx_l_clean_tx_desc bug fixed - was stopping tx completely
> at high load. (It seems there exists yet another similar bug!)
> * "unknown IE" dump was 2 bytes too short - fixed
> * DUP logging made less noisy
> * another usb fix by Carlos Martin <carlosmn@gmail.com>
>
> [20051003]
> * several usb fixes by Carlos Martin <carlosmn@gmail.com> - thanks!
> * unknown IE logging made less noisy
> * few unknown IEs added to the growing collection
> * version bump to 0.3.11
>
> [20050916]
> * fix bogus MTU handling, add ability to change MTU
> * fix WLAN_DATA_MAXLEN: 2312 -> 2304
> * version bump to 0.3.10
>
> [20050915]
> * by popular request default mode is 'managed'
> * empty handler for EID 7 (country info) is added
> * fix 'timer not started - iface is not up'
> * tx[host]desc micro optimizations
> * version bump to 0.3.9
>
> [20050914]
> * tx[host]desc ring workings brought a bit back to two-hostdesc
> scheme. This is an attempt to fix weird WG311v2 bug.
> I still fail to understand how same chip with same fw can
> work for me but do not work for a WG311v2 owner. Mystery.
> * README updated
> * version bump to 0.3.8
>
> [20050913]
> * variable and fields with awful names renamed
> * a few fields dropped (they had constant values)
> * small optimization to acx_l_clean_tx_desc()
> * version bump to 0.3.7
origin
git-acpi
git-agpgart
git-alsa
git-block
git-cfq
git-cifs
git-dvb
git-gfs2
git-ia64
git-ieee1394
git-infiniband
git-intelfb
sane-menuconfig-colours
git-klibc
git-hdrcleanup
git-hdrinstall
git-libata-all
libata_resume_fix
git-mips
git-mtd
git-netdev-all
git-nfs
git-ocfs2
git-powerpc
git-rbtree
git-sas
gregkh-pci-acpiphp-configure-_prt-v3
gregkh-pci-acpiphp-hotplug-slot-hotplug
gregkh-pci-acpiphp-host-and-p2p-hotplug
gregkh-pci-acpiphp-turn-off-slot-power-at-error-case
gregkh-pci-pci-legacy-i-o-port-free-driver-changes-to-generic-pci-code
gregkh-pci-pci-legacy-i-o-port-free-driver-update-documentation-pci_txt
gregkh-pci-pci-legacy-i-o-port-free-driver-make-intel-e1000-driver-legacy-i-o-port-free
gregkh-pci-pci-64-bit-resources-drivers-pci-changes
gregkh-pci-pci-64-bit-resources-drivers-media-changes
gregkh-pci-pci-64-bit-resources-drivers-net-changes
gregkh-pci-pci-64-bit-resources-drivers-pcmcia-changes
gregkh-pci-pci-64-bit-resources-drivers-others-changes
gregkh-pci-pci-msi-abstractions-and-support-for-altix
git-pcmcia
git-scsi-target
gregkh-usb-usb-gotemp
git-supertrak
git-watchdog
x86_64-mm-defconfig-update
x86_64-mm-memset-always-inline
x86_64-mm-amd-core-cpuid
x86_64-mm-amd-cpuid4
x86_64-mm-alternatives
x86_64-mm-ia32-unistd-cleanup
x86_64-mm-topology-comment
x86_64-mm-new-compat-ptrace
x86_64-mm-disable-agp-resource-check
x86_64-mm-new-northbridge
x86_64-mm-iommu-warning
x86_64-mm-i386-up-generic-arch
x86_64-mm-iommu-enodev
x86_64-mm-compat-printk
x86_64-mm-i386-numa-summit-check
x86_64-mm-fix-b44-checks
x86_64-mm-nommu-warning
git-cryptodev
mm
acx1xx-wireless-driver
reiser4-export-find_get_pages
kgdb-core-lite
kgdb-8250
kgdb-netpoll_pass_skb_to_rx_hook
kgdb-eth
kgdb-i386-lite
kgdb-cfi_annotations
kgdb-sysrq_bugfix
kgdb-module
kgdb-core
kgdb-i386
journal_add_journal_head-debug
list_del-debug
unplug-can-sleep
firestream-warnings
git-viro-bird-m32r
git-viro-bird-m68k
git-viro-bird-frv
git-viro-bird-upf
git-viro-bird-volatile
Eric
^ permalink raw reply
* Re: git-svn vs. $Id$
From: Tommi Virtanen @ 2006-05-16 18:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605161037220.3866@g5.osdl.org>
Linus Torvalds wrote:
> Isn't there some flag to svn to avoid keyword expansion, like "-ko" to
> CVS?
>
> Any import script definitely should avoid keyword expansion (and that's
> true whether you end up wanting to use keywords or not).
Well, yes, I agree. But, at least git-svn.txt says this:
BUGS
----
...
svn:keywords can't be ignored in Subversion (at least I don't know of
a way to ignore them).
I guess one might be able to reach that information through the svn API.
Or just propget svn:keywords and sed s/\$Id\(:[^$]*\)\$/$Id$/ all files
with keywords, for all relevant keywords. Eww.
--
Inoi Oy, Tykistökatu 4 D (4. krs), FI-20520 Turku, Finland
http://www.inoi.fi/
Mobile +358 40 762 5656
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport
From: Junio C Hamano @ 2006-05-16 19:01 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linus Torvalds, git
In-Reply-To: <m1bqtx6el6.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Given the ugliness in -mm making it an error to have an
> non-attributed patch would result in people specifying --author
> when they really don't know who the author is, giving us much
> less reliable information.
>
> Possibly what we need is an option to not make it an error so that
> people doing this kind of thing in their own trees have useful
> information.
I agree it is probably a good way to error by default, optinally
allowing to say "don't care". I do not think Linus would pull
from such a tree or trees branched from it into his official
tree, so I do not think we would need to worry about commits
with incomplete information propagating for this particular
"gitified mm" usage. But as a general purpose tool to produce
"gitified quilt series" tree, we would.
It depends on the expected use of the resulting gitified mm
tree.
If it is for an individual developer to futz with and tweak
upon, and the end result from the work leaves such a "gitified
quilt series" repository only as a patch form, then not having
to figure out and specify authorship information to many patches
is probably a plus; the information will not be part of the
official history recorded elsewhere anyway.
However, if it is to produce a reference git tree to point
people at, (i.e. the quiltimport script is run once per a series
by somebody and the result is published for public use), I would
imagine we would want to have the attribution straight, so if
the tool has to "guess", it should either error out or go
interactive and ask.
^ permalink raw reply
* [PATCH] improve depth heuristic for maximum delta size
From: Nicolas Pitre @ 2006-05-16 20:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pzqhh3t.fsf@assigned-by-dhcp.cox.net>
This provides a linear decrement on the penalty related to delta depth
instead of being an 1/x function. With this another 5% reduction is
observed on packs for both the GIT repo and the Linux kernel repo, as
well as fixing a pack size regression in another sample repo I have.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Mon, 15 May 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > @@ -1038,8 +1038,8 @@ static int try_delta(struct unpacked *tr
> >
> > /* Now some size filtering euristics. */
> > size = trg_entry->size;
> > - max_size = size / 2 - 20;
> > - if (trg_entry->delta)
> > + max_size = (size/2 - 20) / (src_entry->depth + 1);
> > + if (trg_entry->delta && trg_entry->delta_size <= max_size)
> > max_size = trg_entry->delta_size-1;
> > src_size = src_entry->size;
> > sizediff = src_size < size ? size - src_size : 0;
>
> At the first glance, this seems rather too agressive. It makes
> me wonder if it is a good balance to penalize the second
> generation base by requiring it to produce a small delta that is
> at most half as we normally would (and the third generation a
> third), or maybe the penalty should kick in more gradually, like
> e.g. ((max_depth * 2 - src_entry->depth) / (max_depth * 2).
You are right. However your formula converge towards 0.5 which is not
enough to be sure the bad effect with early eviction of max depth object
from the object window won't come back. I prefer this patch with a
formula converging toward 0.
diff --git a/pack-objects.c b/pack-objects.c
index 566a2a2..3116020 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -1036,9 +1036,12 @@ static int try_delta(struct unpacked *tr
if (src_entry->depth >= max_depth)
return 0;
- /* Now some size filtering euristics. */
+ /* Now some size filtering heuristics. */
size = trg_entry->size;
- max_size = (size/2 - 20) / (src_entry->depth + 1);
+ max_size = size/2 - 20;
+ max_size = max_size * (max_depth - src_entry->depth) / max_depth;
+ if (max_size == 0)
+ return 0;
if (trg_entry->delta && trg_entry->delta_size <= max_size)
max_size = trg_entry->delta_size-1;
src_size = src_entry->size;
^ permalink raw reply related
* Re: let's meet
From: Randal L. Schwartz @ 2006-05-16 20:34 UTC (permalink / raw)
To: git
In-Reply-To: <602115DC.2C05E9D@arsenal.co.uk>
>>>>> "Luke" == Luke <oxwacpp@arsenal.co.uk> writes:
Luke> Hire,
Luke> i am here sittiang in the internet caffe. Found your email a!nd
Luke> decided to write. I might be coming to your p!lace in 14 days,
Luke> so I decided to email you. May be we ca!n meet? I am 25 y.o.
Luke> girl. I have a picture if you want. No need to reply here as
Luke> this is not my email. Write me at ex@datetodayy.com
I hope she has a big table. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: let's meet
From: Junio C Hamano @ 2006-05-16 20:40 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86odxxn1yc.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Luke" == Luke <oxwacpp@arsenal.co.uk> writes:
>
> Luke> Hire,
> Luke> i am here sittiang in the internet caffe. Found your email a!nd
> Luke> decided to write. I might be coming to your p!lace in 14 days,
> Luke> so I decided to email you. May be we ca!n meet? I am 25 y.o.
> Luke> girl. I have a picture if you want. No need to reply here as
> Luke> this is not my email. Write me at ex@datetodayy.com
>
> I hope she has a big table. :)
Huh?
She's coming to *your* place, so you are the one to prepare a
big table to cover the locations we all live---perhaps "earth"?
;-)
^ permalink raw reply
* Re: [RFC] Add "rcs format diff" support
From: Al Viro @ 2006-05-16 20:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List, Al Viro, Davide Libenzi
In-Reply-To: <20060514001214.GB27946@ftp.linux.org.uk>
Use:
diff-remap-data <dir1> <dir2> >map
or
git-remap-data <git-diff arguments> >map
will build information for remapper,
git-remap <map> <options>
will do line numbers remapping.
git-remap is a filter. It takes map as argument and, in the simplest form,
will look at the lines in stdin that have form
<filename>:<number>:<text>
If the indicated line from old tree had survived into the new one, we will
get
N:<new-filename>:<new-number>:<text>
on the output. If it hadn't, we get
O:<filename>:<number>:<text>
Lines that do not have such form are passed unchanged.
Even that is already very useful for log comparison. E.g. if old-log is
from the old tree and new-log is from the new one, we can do
git-remap map <old-log >foo
git-remap /dev/null <new-log >bar
diff -u foo bar
and have the noise due to line number changes excluded (empty map means
identity mapping, so the second line will simply slap N: on all lines of
form <filename>:<number>:<text> in new-log).
Note that it's not just for build logs; the thing is useful for sparse logs,
grep -n output, etc., etc.
Behaviour described above is the default; what _really_ happens is
that we take lines of form
<original_prefix><filename>:<number>:<text>
and replace them with
<prefix_for_new><new-filename>:<new-number>:<text>
or
<prefix_for_old><filename>:<number>:<text>
Defaults are :", "N:" and "O:" resp.; what it gives us is the ability to
do multiple remappings. IOW, we can say
diff-remap-data old-tree newer-tree > map1
diff-remap-data newer-tree current-tree > map2
git-remap -o old: map1 <old-log | git-remap -p N: -o newer: -n current: map2>foo
and get lines that didn't make it into the newer tree marked with old: and
otherwise be unchanged, ones that made it to newer, but not the current to
be marked with newer: and have the filenames/line numbers remapped and ones
that made it all the way be marked with current: and remapped all the way
to current tree.
That's quite useful when you want to carry logs for a while, basically using
them as annotated TODO ("logs" here can very well be results of grep -n with
annotations added to them). You can have all still relevant bits stay with
the locations in text and see what had fallen out.
Note on relation to git:
* git-remap, despite the name, doesn't need git to work
* diff-remap-data doesn't need git to work
* git-remap-data _does_ need it. Aside of working on revisions in
git repository instead of a couple of directory trees, it generates slightly
better map than diff-remap-data does. I.e. it manages to remap more lines -
it does notice renames.
This stuff lives on ftp.linux.org.uk/pub/people/viro/remapper/; I'm not
sure what to do with it wrt distributing - submit for inclusion into
git, or leave that sucker standalone. It can be used without git, but
OTOH having it in git would make my life easier - I wouldn't have to
think about packaging it myself ;-)
Seriously,
a) feel free to play with it; hopefully it will be useful.
b) review and comments are welcome.
c) so would any thoughts regarding the right way to distribute it.
^ permalink raw reply
* Merge with local conflicts in new files
From: Santi @ 2006-05-16 22:00 UTC (permalink / raw)
To: git, Junio C Hamano
Hi *,
In the case of:
- You merge from a branch with new files
- You have these files in the working directory
- You do not have these files in the HEAD.
The end result is that you lose the content of these files.
So an additional check for the merge is to check for these dirty
but not in HEAD files.
Here is a test that reproduce it. I expect the merge to fail and
with the content of foo being bar.
test_description='Test merge with local conflicts in new files'
. ./test-lib.sh
test_expect_success 'prepare repository' \
'echo "Hello" > init &&
git add init &&
git commit -m "Initial commit" &&
git branch B &&
echo "foo" > foo &&
git add foo &&
git commit -m "File: foo" &&
git checkout B &&
echo "bar" > foo '
test_expect_code 1 'Merge with local conflicts in new files' 'git
merge "merge msg" B master'
test_done
Thanks.
^ permalink raw reply
* "git add $ignored_file" fail
From: Santi @ 2006-05-16 22:07 UTC (permalink / raw)
To: git, Junio C Hamano
Hi *,
When you try to add ignored files with the git-add command it
fails because the call to:
git-ls-files -z \
--exclude-from="$GIT_DIR/info/exclude" \
--others --exclude-per-directory=.gitignore
does not output this file because it is ignored. I know I can do it with:
git-update-index --add $ignored_file
I understand the behaviour of git-ls-files but I think it is no the
expected for git-add, at least for me.
Thanks
Santi
^ permalink raw reply
* Re: Merge with local conflicts in new files
From: Santi @ 2006-05-16 22:12 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <8aa486160605161500m1dd8428cj@mail.gmail.com>
Sorry, the test is wrong. Use this:
test_description='Test merge with local conflicts in new files'
. ./test-lib.sh
test_expect_success 'prepare repository' \
'echo "Hello" > init &&
git add init &&
git commit -m "Initial commit" &&
git checkout -b B &&
echo "foo" > foo &&
git add foo &&
git commit -m "File: foo" &&
git checkout master &&
echo "bar" > foo &&
'
test_expect_code 1 'Merge with local conflicts in new files' 'git
merge "merge msg" HEAD B'
test_done
^ permalink raw reply
* Ouput of git diff with <ent>:<path>
From: Santi @ 2006-05-16 22:24 UTC (permalink / raw)
To: git, Junio C Hamano
Hi *,
just curious if this is the expected output. I find this syntax
very usefull but the "a/v1.3.3:" of even without the tree "a/:" a bit
confusing. And I didn't expect the rename from/to neither the
similarity index 0%.
diff --git a/v1.3.3:Makefile b/Makefile
similarity index 0%
rename from v1.3.3:Makefile
rename to Makefile
index b808eca..55d1937 100644
--- a/v1.3.3:Makefile
+++ b/Makefile
Thanks.
Santi
^ 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