* [RFC] git email submissions
From: Jeff Garzik @ 2005-11-16 14:38 UTC (permalink / raw)
To: Git Mailing List
For people without _any_ hosting, it would be nice to give them a method
to submit some git changes via email.
It seems like most of the necessary stuff is already present in git to
bundle up a set of changes. The open questions in my mind are
- what form would the emails take? MIME-attach a .pack file, plus a
GPG-signed sha1sum in a separate attachment?
- what's the easiest user interface for selecting the changes? for my
usage, it would be
GIT_GPG_AUTHOR=jgarzik... \
GIT_DEF_HEADERS=./email.headers \
git-mkmail --sign master..upstream > email.rfc822
Enter GPG passphrase:
- what user interface does a kernel maintainer use, to merge changes
submitted using this method?
- is this all pointless, since the submittor could just email patches?
[IMO no, git trees are better merges than emailed patches]
Overall, I was thinking it would be nice to have some way to safely
transmit a small part of a git tree, including all history information,
since its easier to merge git trees than patches.
And for someone without the resources to obtain hosting, email may be
the only way to publish a git sub-tree.
Jeff
^ permalink raw reply
* Re: [PATCH] Stgit - gitmergeonefile.py: handle removal vs. changes
From: Blaisorblade @ 2005-11-16 14:44 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0511150154y2d2af24ck@mail.gmail.com>
On Tuesday 15 November 2005 10:54, Catalin Marinas wrote:
> On 13/11/05, Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> wrote:
> > I just got a "removal vs. changed" conflict, which is unhandled by StGit.
> > That is taken from git-merge-one-file resolver, but is bad, as stg
> > resolved does not handle unmerged entries (and probably it should be
> > fixed too).
> I think it 'stg resolved' should be fixed as well (in case there are
> unmerged entries for other reasons).
Yep, I was thinking that too but was too lazy to implement.
Actually, with .git/commits we are reimplementing handling of "unmerged"
entries... it could be better to use the "unmerged entry" stgit idea. So "stg
resolved" should modify the entries by itself.
> My initial idea was to make
> gitmergeonefile not to leave any unmerged entries in the index. As you
> could see, there are cases where it failed.
Yep... it seems you took examples from git-merge-one-file, but that's lacking
(but it's low-level so it's appropriate for it - it must leave unmerged
entries when there are conflicts).
> I can see the following scenarios for a file:
In both cases, we're going to have a conflict, so we leave file.
{older,remote,local} as appropriate and already done.
> 1. deleted in the base and modified by the patch. It should leave the
> file in the tree together with file.older.
Why not leaving file.remote? We already do that in general, so we have a
duplicate, but it's easier to understand.
> Another option would be to
> remove the file and leave both file.older and file.remote in the tree
> (here .remote means the version in the patch)
I remember that at times, but .remote is very confusing... I see that's the
mishandling is induced by various sources, maybe including "merge" itself,
but that program (and possibly others) supports changing the labels, and this
should probably be done (using "original", "patched" and "upstream"
probably).
> but I would prefer the
> first one.
> 2. changed in the base but deleted by the patch. It should remove the
> file from the tree but leave file.older and file.local. The other
> option is to leave the file in the tree but, as above, I prefer the
> first one.
The policy about when to remove the file and when to leave it is very
personal... the user must anyway solve the conflict in some smart way...
about the defaults, anything would do, but if we really care we could leave
the user the choice.
For the Linux kernel, my experience is that when a file is removed it's either
because it's renamed, it's refactored, or it's removed. In all these cases,
there's often little interest in reviving it in the patch... However it's
just a slight preference.
> Maybe StGIT should try to track the renaming as well but I haven't
> played with this feature in GIT at all.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: stgit truncates binary files to zero length when applying patches
From: Karl Hasselström @ 2005-11-16 13:03 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0511160431r6c852e5fn@mail.gmail.com>
On 2005-11-16 12:31:27 +0000, Catalin Marinas wrote:
> On 16/11/05, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2005-11-16 11:11:56 +0000, Catalin Marinas wrote:
> >
> > > Unfortunately, git-apply doesn't fail for patches including
> > > binary files and simply creates an empty file. I think git-apply
> > > should be changed to fail to apply this kind of patches.
> >
> > Yes, at least if stgit is going to continue to use it like this.
> > Refusing to handle binary files is somewhat disappointing, but
> > still OK; agreeing to handle them and then silently wiping them is
> > a bit less OK.
>
> A workaround for this would be to add a config option for StGIT to
> always use the three-way merge for pushing patches. The problem with
> this is speed since git-diff-tree | git-apply is much faster (and
> pretty safe since fuzzy patching is not allowed) and most of the
> patches would apply cleanly with only this.
The proper fix has to be to convince git-apply to either handle
patches with binary files, or to make it fail; in both cases, stgit
will be fine. If the former is somehow intractable or undesirable, and
the latter would break existing callers (and/or inconvenience users),
perhaps it could fail on binary files only when a --text-only flag was
given.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: stgit truncates binary files to zero length when applying patches
From: Catalin Marinas @ 2005-11-16 12:31 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20051116115449.GA5933@diana.vm.bytemark.co.uk>
On 16/11/05, Karl Hasselström <kha@treskal.com> wrote:
> On 2005-11-16 11:11:56 +0000, Catalin Marinas wrote:
> > Unfortunately, git-apply doesn't fail for patches including binary
> > files and simply creates an empty file. I think git-apply should be
> > changed to fail to apply this kind of patches.
>
> Yes, at least if stgit is going to continue to use it like this.
> Refusing to handle binary files is somewhat disappointing, but still
> OK; agreeing to handle them and then silently wiping them is a bit
> less OK.
A workaround for this would be to add a config option for StGIT to
always use the three-way merge for pushing patches. The problem with
this is speed since git-diff-tree | git-apply is much faster (and
pretty safe since fuzzy patching is not allowed) and most of the
patches would apply cleanly with only this.
--
Catalin
^ permalink raw reply
* [QUESTION] Access to a huge GIT repository.
From: Franck @ 2005-11-16 12:24 UTC (permalink / raw)
To: Git Mailing List
Hi,
I'm trying to clone a small part of a big repository. This repository
contains several branchs that are useless for me. Actually this
repository is the linux-mips one, and branchs are used to track each
kernel minor version. That is to say it contains 4 branchs which are
linux-2.0, linux-2.2, linux-2.4 and master (linux-2.6).
I'd like to clone this repository without grabbing linux-2.0,
linux-2.2, linux-2.4 branchs. I tried several things like:
$ git init-db
$ git fetch rsync://ftp.linux-mips.org/git/linux.git master
But all tries download every objects of each branchs. I believe that's
because of (a) the protocol used to access of the remote repo (b) the
master branch has been created from linux-2.4 branch so its first
commit object contains a branch 2.4 commit obj as parent object (let's
call it the "father" object). Is that correct ?
So I downloaded the whole thing, and try to remove "father" object and
right after run a 'git prune'. But unfortunately I can't find it
anywhere in .git directory. I did:
$ git-verify-pack < .git/objects/pack/*.idx
$ git-unpack-objects < .git/objects/pack/*.pack
But I can't find "father object" anywhere in .git/objects directory.
Still it's referenced by .git/objects/pack/pack-....idx file.
Can anybody give me some advices ?
Thanks
--
Franck
^ permalink raw reply
* Re: stgit truncates binary files to zero length when applying patches
From: Karl Hasselström @ 2005-11-16 11:54 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0511160311k725526d8v@mail.gmail.com>
On 2005-11-16 11:11:56 +0000, Catalin Marinas wrote:
> On 15/11/05, Karl Hasselström <kha@treskal.com> wrote:
>
> > When applying patches and not fast-forwarding, stgit truncates the
> > binary files to zero length:
>
> I've never tried binaries with StGIT before.
I don't blame you. Binary patches aren't something I normally create
either. It's just that I find stgit patches a good way to logically
structure a largeish change that I'm working on before committing it.
(I could probably accoplish the same thing with one branch instead of
each stgit patch, but then it would be quite a lot of work to manually
push updates through all the branches.)
> When pushing a patch, if a merge is needed (like in your case, the
> base of the foo patch has changed), StGIT first tries "git-diff-tree
> | git-apply" for speed reasons. If this fails, it falls back to a
> three-way merge.
>
> Unfortunately, git-apply doesn't fail for patches including binary
> files and simply creates an empty file. I think git-apply should be
> changed to fail to apply this kind of patches.
Yes, at least if stgit is going to continue to use it like this.
Refusing to handle binary files is somewhat disappointing, but still
OK; agreeing to handle them and then silently wiping them is a bit
less OK. (But don't worry; it is a perfect world, after all, so of
course I had backups. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: stgit truncates binary files to zero length when applying patches
From: Catalin Marinas @ 2005-11-16 11:11 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20051115144223.GA18111@diana.vm.bytemark.co.uk>
On 15/11/05, Karl Hasselström <kha@treskal.com> wrote:
> When applying patches and not fast-forwarding, stgit truncates the
> binary files to zero length:
I've never tried binaries with StGIT before. When pushing a patch, if
a merge is needed (like in your case, the base of the foo patch has
changed), StGIT first tries "git-diff-tree | git-apply" for speed
reasons. If this fails, it falls back to a three-way merge.
Unfortunately, git-apply doesn't fail for patches including binary
files and simply creates an empty file. I think git-apply should be
changed to fail to apply this kind of patches.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Add option USE_INPLACE to Makefile
From: Johannes Schindelin @ 2005-11-16 11:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsp19eg7.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 16 Nov 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Now, *I* know what I have to put into config.mak, but I would hate the
> > project if I was new to it, tried to play around with it, and nothing
> > would work in spite of being compiled with just one warning, thank you.
>
> Hmph. That certainly sounds like what I might do. Especially
> the part "play around before installing", so I am *very*
> sympathetic.
>
> OTOH, I do not particularly want to advertise/encourage in-place
> use. Once you built today's git ;-), wouldn't you cd somewhere
> else and use it for your real work? That would mean you have
> one location on your PATH that you keep the latest git build
> and I am not sure why being able to run in-place is such a big
> deal. Is it because $HOME is under a tight quota?
Okay. So it would be better to provide a short snippet in INSTALL which
can be copied into config.mak?
> > Just a safety measure for the price of two lines. When I check out a new
> > project, I do "make", play around with it, and then do "make install". If
> > I had to set "export USE_INPLACE=1", "make install" should barf, because
> > the compiled programs are not meant to be used anywhere else.
>
> OK. That's sensible.
Well, the patch was untested, and wrong (template_dir was bogus). But I
agree that it might be a better idea to deprecate that behaviour.
I *will* learn to "make install" after "make", and not spend hours just to
find that ./git called the old installed binaries.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix git_config_set() for mean cases
From: Johannes Schindelin @ 2005-11-16 9:47 UTC (permalink / raw)
To: git, junkio
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5883 bytes --]
There were problems when the keys´ case didn´t match, and also when the
section was in the same line as the key.
This patch also adds a test case, so you see that it works now.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
I shoulda started by writing those tests. This patch is on top
of my earlier patch, which worked only in the nice cases. It
now needs git-config-set, though.
config.c | 42 ++++++++++++++----
t/t1300-config-set.sh | 112 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 144 insertions(+), 10 deletions(-)
create mode 100644 t/t1300-config-set.sh
applies-to: ae3c1e28a1df80086033825ac68fdf4c6c835eee
e326b690c85a648ffcbbc63e69333a7100a07892
diff --git a/config.c b/config.c
index 3b883b2..9315351 100644
--- a/config.c
+++ b/config.c
@@ -255,7 +255,7 @@ int git_config(config_fn_t fn)
static struct {
int baselen;
- const char* key;
+ char* key;
const char* value;
off_t offset;
enum { START, SECTION_SEEN, SECTION_END_SEEN, KEY_SEEN } state;
@@ -270,10 +270,10 @@ static int store_aux(const char* key, co
break;
case SECTION_SEEN:
if (strncmp(key, store.key, store.baselen+1)) {
- store.offset = ftell(config_file);
store.state = SECTION_END_SEEN;
break;
- }
+ } else
+ store.offset = ftell(config_file);
case SECTION_END_SEEN:
case START:
if (!strcmp(key, store.key)) {
@@ -326,18 +326,21 @@ int git_config_set(const char* key, cons
return 2;
}
+ store.key = strdup(key);
for (i = 0; key[i]; i++)
if (i != store.baselen && !isalpha(key[i])) {
fprintf(stderr, "invalid key: %s\n", key);
+ free(store.key);
return 1;
- }
+ } else
+ store.key[i] = tolower(key[i]);
- store.key = key;
store.value = value;
fd = open(lock_file, O_WRONLY | O_CREAT | O_EXCL, 0666);
if (fd < 0) {
fprintf(stderr, "could not lock config file\n");
+ free(store.key);
return -1;
}
@@ -349,6 +352,9 @@ int git_config_set(const char* key, cons
"#\n"
"\n";
+ free(store.key);
+ store.key = (char*)key;
+
write(fd, contents, sizeof(contents)-1);
store_write_section(fd);
store_write_pair(fd);
@@ -362,25 +368,41 @@ int git_config_set(const char* key, cons
if (git_config(store_aux)) {
fprintf(stderr, "invalid config file\n");
+ free(store.key);
return 3;
}
+ free(store.key);
+ store.key = (char*)key;
+
in_fd = open(config_file, O_RDONLY, 0666);
contents = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, in_fd, 0);
close(in_fd);
if (store.offset == 0)
- offset = st.st_size;
- else {
+ store.offset = offset = st.st_size;
+ else if (store.state != KEY_SEEN) {
+ offset = store.offset;
+ } else {
+ int equal_offset = st.st_size,
+ bracket_offset = st.st_size;
for (offset = store.offset-2; offset > 0
- && contents[offset] != '\n'; offset--);
- offset++;
+ && contents[offset] != '\n'; offset--)
+ switch (contents[offset]) {
+ case '=': equal_offset = offset; break;
+ case ']': bracket_offset = offset; break;
+ }
+ if (bracket_offset < equal_offset) {
+ contents[bracket_offset+1] = '\n';
+ offset = bracket_offset+2;
+ } else
+ offset++;
}
write(fd, contents, offset);
if (store.state == START)
store_write_section(fd);
store_write_pair(fd);
- if (store.offset > offset)
+ if (store.offset < st.st_size)
write(fd, contents + store.offset,
st.st_size - store.offset);
diff --git a/t/t1300-config-set.sh b/t/t1300-config-set.sh
new file mode 100644
index 0000000..48d4ff1
--- /dev/null
+++ b/t/t1300-config-set.sh
@@ -0,0 +1,112 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Johannes Schindelin
+#
+
+test_description='Test git-config-set in different settings'
+
+. ./test-lib.sh
+
+test -f .git/config && rm .git/config
+
+git-config-set core.penguin "little blue"
+
+cat > expect.1 << EOF
+#
+# This is the config file
+#
+
+[core]
+ penguin = little blue
+EOF
+
+test_expect_success 'initial' 'cmp .git/config expect.1'
+
+git-config-set Core.Movie BadPhysics
+
+cat > expect.2 << EOF
+#
+# This is the config file
+#
+
+[core]
+ penguin = little blue
+ Movie = BadPhysics
+EOF
+
+test_expect_success 'mixed case' 'cmp .git/config expect.2'
+
+git-config-set Cores.WhatEver Second
+
+cat > expect.3 << EOF
+#
+# This is the config file
+#
+
+[core]
+ penguin = little blue
+ Movie = BadPhysics
+[Cores]
+ WhatEver = Second
+EOF
+
+test_expect_success 'similar section' 'cmp .git/config expect.3'
+
+git-config-set CORE.UPPERCASE true
+
+cat > expect.4 << EOF
+#
+# This is the config file
+#
+
+[core]
+ penguin = little blue
+ Movie = BadPhysics
+ UPPERCASE = true
+[Cores]
+ WhatEver = Second
+EOF
+
+test_expect_success 'similar section' 'cmp .git/config expect.4'
+
+cat > .git/config << EOF
+[beta] ; silly comment # another comment
+noIndent= sillyValue ; ´nother silly comment
+
+# empty line
+ ; comment
+ haha ="beta" # last silly comment
+[nextSection] noNewline = ouch
+EOF
+
+git-config-set beta.haha alpha
+
+cat > expect.5 << EOF
+[beta] ; silly comment # another comment
+noIndent= sillyValue ; ´nother silly comment
+
+# empty line
+ ; comment
+ haha = alpha
+[nextSection] noNewline = ouch
+EOF
+
+test_expect_success 'really mean test' 'cmp .git/config expect.5'
+
+git-config-set nextsection.nonewline wow
+
+cat > expect.6 << EOF
+[beta] ; silly comment # another comment
+noIndent= sillyValue ; ´nother silly comment
+
+# empty line
+ ; comment
+ haha = alpha
+[nextSection]
+ nonewline = wow
+EOF
+
+test_expect_success 'really really mean test' 'cmp .git/config expect.6'
+
+test_done
+
---
0.99.9.GIT
^ permalink raw reply related
* Re: Cogito and --exclude vs --exclude-per-directory
From: Karl Hasselström @ 2005-11-16 9:38 UTC (permalink / raw)
To: git
In-Reply-To: <20051116093630.GA2783@diana.vm.bytemark.co.uk>
On 2005-11-16 10:36:30 +0100, Karl Hasselström wrote:
> [Note: this experiment was done with git 0.99.9g and Cogito 0.15.1,
> so ]
. . . please scream if I should just upgrade to fix all my problems.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Cogito and --exclude vs --exclude-per-directory
From: Karl Hasselström @ 2005-11-16 9:36 UTC (permalink / raw)
To: git
[Note: this experiment was done with git 0.99.9g and Cogito 0.15.1, so ]
It seems that --exclude patterns always take precedence over
--exclude-per-directory patterns. For example:
$ ls -a
./ ../ .bar bar.txt .foo foo.txt .git/ .gitignore
$ cat .gitignore
!.bar
$ git-ls-files -o --exclude='.*' --exclude='!.bar'
.bar
bar.txt
foo.txt
$ git-ls-files -o --exclude='.*' --exclude-per-directory=.gitignore
bar.txt
foo.txt
Is this the intended behavior?
Since Cogito specifies a few "default" ignore patterns with --exclude,
(such as .* and *.o) these become impossible to override with !
patterns in .gitignore files. In effect, the default patterns are
given priority over user-supplied patterns.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] git-am: --resolved.
From: Junio C Hamano @ 2005-11-16 9:26 UTC (permalink / raw)
To: git
In-Reply-To: <7voe4lfpxm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> - Patch C does not apply. git-am stops here, with conflicts to
> be resolved in the working tree. Yet-to-be-applied D and E
> are still kept in .dotest/ directory at this point. What the
> user does is exactly the same as fixing up unapplicable patch
> when running git-am:
>
> - Resolve conflict just like any merge conflicts.
>
> - "git diff -p --full-index HEAD >.dotest/patch" to pretend
> as if you received a perfect, applicable patch.
>
> - "git reset --hard", to pretend you have not tried to apply
> that patch yet.
>
> [Side note] I think the latter two steps can and should be
> made into a short-hand to tell "git-am" that the conflicting
> patch is resolved. "git-am --resolved", perhaps?
It turns out that the above "diff >.dotest/patch && reset --hard"
was unnecessary. Instead, the above workflow would read:
- Resolve conflict just like any merge conflicts.
- Do necessary 'git-update-index' to prepare your index to
record the result of the patch application.
- "git am --resolved".
What it does is just record the current index as tree, along
with the commit log message and authorship information taken
from the e-mail. No diff & patch is involved. Oh, and you can
do this in a dirty working tree as long as your index is clean
and dirty paths do not interfere with the patch application.
The patch I am posting here is against the tip of the master, if
somebody wants to try it out. Proposed updates branch has an
equivalent patch on top of the reworked rebase series.
-- >8 --
After failed patch application, you can manually apply the patch
(this includes resolving the conflicted merge after git-am falls
back to 3-way merge) and run git-update-index on necessary paths
to prepare the index file in a shape a successful patch
application should have produced. Then re-running git-am --resolved
would record the resulting index file along with the commit log
information taken from the patch e-mail.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-am.sh | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++-----------
1 files changed, 53 insertions(+), 12 deletions(-)
applies-to: 1e3fcf60526c196a46433e6947c9104ca236f230
3efc3e216c8a64fae53a15767064162ee431f57e
diff --git a/git-am.sh b/git-am.sh
index 38841d9..98a390a 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -3,16 +3,10 @@
#
. git-sh-setup || die "Not a git archive"
-files=$(git-diff-index --cached --name-only HEAD) || exit
-if [ "$files" ]; then
- echo "Dirty index: cannot apply patches (dirty: $files)" >&2
- exit 1
-fi
-
usage () {
echo >&2 "usage: $0 [--signoff] [--dotest=<dir>] [--utf8] [--3way] <mbox>"
echo >&2 " or, when resuming"
- echo >&2 " $0 [--skip]"
+ echo >&2 " $0 [--skip | --resolved]"
exit 1;
}
@@ -104,7 +98,7 @@ fall_back_3way () {
}
prec=4
-dotest=.dotest sign= utf8= keep= skip= interactive=
+dotest=.dotest sign= utf8= keep= skip= interactive= resolved=
while case "$#" in 0) break;; esac
do
@@ -128,6 +122,9 @@ do
-k|--k|--ke|--kee|--keep)
keep=t; shift ;;
+ -r|--r|--re|--res|--reso|--resol|--resolv|--resolve|--resolved)
+ resolved=t; shift ;;
+
--sk|--ski|--skip)
skip=t; shift ;;
@@ -140,6 +137,8 @@ do
esac
done
+# If the dotest directory exists, but we have finished applying all the
+# patches in them, clear it out.
if test -d "$dotest" &&
last=$(cat "$dotest/last") &&
next=$(cat "$dotest/next") &&
@@ -155,9 +154,9 @@ then
die "previous dotest directory $dotest still exists but mbox given."
resume=yes
else
- # Make sure we are not given --skip
- test ",$skip," = ,, ||
- die "we are not resuming."
+ # Make sure we are not given --skip nor --resolved
+ test ",$skip,$resolved," = ,,, ||
+ die "we are not resuming."
# Start afresh.
mkdir -p "$dotest" || exit
@@ -170,12 +169,24 @@ else
exit 1
}
+ # -s, -u and -k flags are kept for the resuming session after
+ # a patch failure.
+ # -3 and -i can and must be given when resuming.
echo "$sign" >"$dotest/sign"
echo "$utf8" >"$dotest/utf8"
echo "$keep" >"$dotest/keep"
echo 1 >"$dotest/next"
fi
+case "$resolved" in
+'')
+ files=$(git-diff-index --cached --name-only HEAD) || exit
+ if [ "$files" ]; then
+ echo "Dirty index: cannot apply patches (dirty: $files)" >&2
+ exit 1
+ fi
+esac
+
if test "$(cat "$dotest/utf8")" = t
then
utf8=-u
@@ -216,6 +227,15 @@ do
go_next
continue
}
+
+ # If we are not resuming, parse and extract the patch information
+ # into separate files:
+ # - info records the authorship and title
+ # - msg is the rest of commit log message
+ # - patch is the patch body.
+ #
+ # When we are resuming, these files are either already prepared
+ # by the user, or the user can tell us to do so by --resolved flag.
case "$resume" in
'')
git-mailinfo $keep $utf8 "$dotest/msg" "$dotest/patch" \
@@ -263,6 +283,13 @@ do
fi
} >"$dotest/final-commit"
;;
+ *)
+ case "$resolved,$interactive" in
+ tt)
+ # This is used only for interactive view option.
+ git-diff-index -p --cached HEAD >"$dotest/patch"
+ ;;
+ esac
esac
resume=
@@ -310,7 +337,21 @@ do
echo "Applying '$SUBJECT'"
echo
- git-apply --index "$dotest/patch"; apply_status=$?
+ case "$resolved" in
+ '')
+ git-apply --index "$dotest/patch"
+ apply_status=$?
+ ;;
+ t)
+ # Resolved means the user did all the hard work, and
+ # we do not have to do any patch application. Just
+ # trust what the user has in the index file and the
+ # working tree.
+ resolved=
+ apply_status=0
+ ;;
+ esac
+
if test $apply_status = 1 && test "$threeway" = t
then
if (fall_back_3way)
---
0.99.9.GIT
^ permalink raw reply related
* Re: Deprecate --cache.* ?
From: Josef Weidendorfer @ 2005-11-16 9:18 UTC (permalink / raw)
To: git
In-Reply-To: <7vsltxazyf.fsf@assigned-by-dhcp.cox.net>
On Wednesday 16 November 2005 07:06, Junio C Hamano wrote:
> Lukas Sandström <lukass@etek.chalmers.se> writes:
>
> > Backward compability could be ensured by having both versions of the flags
> > around for a while and issuing a warning when the old form is used.
> >
> > Good idea? Bad? Stupid? Do we want to keep "cache" around?
>
> I agree that may be a logical move, with proper b/c slack, but I
> am not _so_ enthused about this...
Probably, as your fingers are trained. I just tried it to write 10
times as fast as possible: cache, and afterwards index; and writing
cache *is* faster ;-)
But for someone new to git, these options must be totally confusing
and coming out of nowhere. Not that I use these often - I am a
Cogito user.
Practically, the opinion of people using these options often should
count, as it will be inconvenient for them. Rare users can look up
the man page.
Josef
^ permalink raw reply
* Re: [PATCH] Add option USE_INPLACE to Makefile
From: Junio C Hamano @ 2005-11-16 8:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511160903360.16063@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Now, *I* know what I have to put into config.mak, but I would hate the
> project if I was new to it, tried to play around with it, and nothing
> would work in spite of being compiled with just one warning, thank you.
Hmph. That certainly sounds like what I might do. Especially
the part "play around before installing", so I am *very*
sympathetic.
OTOH, I do not particularly want to advertise/encourage in-place
use. Once you built today's git ;-), wouldn't you cd somewhere
else and use it for your real work? That would mean you have
one location on your PATH that you keep the latest git build
and I am not sure why being able to run in-place is such a big
deal. Is it because $HOME is under a tight quota?
> Just a safety measure for the price of two lines. When I check out a new
> project, I do "make", play around with it, and then do "make install". If
> I had to set "export USE_INPLACE=1", "make install" should barf, because
> the compiled programs are not meant to be used anywhere else.
OK. That's sensible.
^ permalink raw reply
* Re: [PATCH] git wrapper: basic fixes.
From: Johannes Schindelin @ 2005-11-16 8:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vfypxawok.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Tue, 15 Nov 2005, Junio C Hamano wrote:
> - Lose use of glob(); read from exec_path and do sorting
> ourselves -- it is not that much more work.
Clearly a better fix than my patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add option USE_INPLACE to Makefile
From: Johannes Schindelin @ 2005-11-16 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzk5cmnd.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 15 Nov 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > and you no longer need to worry about setting variables like
> > GIT_EXEC_PATH and GIT_PYTHON_PATH.
>
> I think you can already do this in the config.mak mechanism
> added by, ... (goes and asks git-whatchanged about it),...
> *you*, no?
Yes.
But I imagined a programmer new to git. And then I looked at the situation
I had yesterday after pulling to 97fc6c5f.. in which I was able to build
just fine, but calls like "git diff" no longer worked.
Now, *I* know what I have to put into config.mak, but I would hate the
project if I was new to it, tried to play around with it, and nothing
would work in spite of being compiled with just one warning, thank you.
> You know you are not installing things anyway if you do that, so
> I do not see much point hiding the install target and friends
> either.
Just a safety measure for the price of two lines. When I check out a new
project, I do "make", play around with it, and then do "make install". If
I had to set "export USE_INPLACE=1", "make install" should barf, because
the compiled programs are not meant to be used anywhere else.
Having said that, I probably should have called it an RFC, not a PATCH.
Sorry.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Give python a chance to find "backported" modules
From: Johannes Schindelin @ 2005-11-16 8:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveytcmus.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 15 Nov 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > python 2.2.1 is perfectly capable of executing git-merge-recursive,
> > provided that it finds heapq and sets. All you have to do is to steal
> > heapq.py and sets.py from python 2.3 or newer, and drop them in your
> > GIT_PYTHON_PATH.
>
> Fair enough. But I do not think we would want to go further
> than this. Especially, shipping a copy of heapq and sets like
> we did for subprocess.
Yes. That was my intention.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] git --help COMMAND brings up the git-COMMAND man-page., take two
From: Junio C Hamano @ 2005-11-16 7:29 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <437AAB48.7090904@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> The way this made it into the actual tree was to call /usr/bin/man, but
> still using execlp(). This is clearly bogus. There *ARE* good reasons
> to use PATH resolutions for this, since man is one of the interactive
> commands the user may want to wrapper.
Oh, that was my call, so please do not blame Andreas.
I just sent out a proposed patch to address all the points
discussed on the list for the last several hours.
^ permalink raw reply
* [PATCH] git wrapper: basic fixes.
From: Junio C Hamano @ 2005-11-16 7:17 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <437AD82B.1050404@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> PATH_TO_MAN *was* the original. This is the updated version. I think
> Junio imported the wrong one by mistake, cause I sent this one
> specifically to fix the first one.
Actually, I already had the original three in my tree before I
sent out the message about problems like PATH_TO_MAN and
getcwd/chdir pair, because they were not such a big deal to fix
later in-tree, and I wanted to have the rest.
How does this one look, on top of what we have on the "master"
branch?
-- >8 --
Updates to fix the nits found during the list discussion.
- Lose PATH_TO_MAN; just rely on execlp() to find whereever the
"man" command is installed.
- Do not randomly chdir(), but concatenate to the current
working directory only if the given path is not absolute.
- Lose use of glob(); read from exec_path and do sorting
ourselves -- it is not that much more work.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git.c | 152 +++++++++++++++++++++++++++++++++++++++++------------------------
1 files changed, 97 insertions(+), 55 deletions(-)
applies-to: 1a3192c27df352fb11cb1f430ad174ecd90a3734
7dbc2c0402d728a206d4f1bc59729bf3a5cc4455
diff --git a/git.c b/git.c
index 583923d..b9b8c62 100644
--- a/git.c
+++ b/git.c
@@ -1,11 +1,13 @@
#include <stdio.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <dirent.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <limits.h>
#include <stdarg.h>
-#include <glob.h>
#ifndef PATH_MAX
# define PATH_MAX 4096
@@ -14,12 +16,6 @@
static const char git_usage[] =
"Usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ ARGS ]";
-struct string_list {
- size_t len;
- char *str;
- struct string_list *next;
-};
-
/* most gui terms set COLUMNS (although some don't export it) */
static int term_columns(void)
{
@@ -32,30 +28,69 @@ static int term_columns(void)
return 80;
}
+static void oom(void)
+{
+ fprintf(stderr, "git: out of memory\n");
+ exit(1);
+}
+
static inline void mput_char(char c, unsigned int num)
{
while(num--)
putchar(c);
}
-static void pretty_print_string_list(struct string_list *list, int longest)
+static struct cmdname {
+ size_t len;
+ char name[1];
+} **cmdname;
+static int cmdname_alloc, cmdname_cnt;
+
+static void add_cmdname(const char *name, int len)
+{
+ struct cmdname *ent;
+ if (cmdname_alloc <= cmdname_cnt) {
+ cmdname_alloc = cmdname_alloc + 200;
+ cmdname = realloc(cmdname, cmdname_alloc * sizeof(*cmdname));
+ if (!cmdname)
+ oom();
+ }
+ ent = malloc(sizeof(*ent) + len);
+ if (!ent)
+ oom();
+ ent->len = len;
+ memcpy(ent->name, name, len+1);
+ cmdname[cmdname_cnt++] = ent;
+}
+
+static int cmdname_compare(const void *a_, const void *b_)
+{
+ struct cmdname *a = *(struct cmdname **)a_;
+ struct cmdname *b = *(struct cmdname **)b_;
+ return strcmp(a->name, b->name);
+}
+
+static void pretty_print_string_list(struct cmdname **cmdname, int longest)
{
int cols = 1;
int space = longest + 1; /* min 1 SP between words */
int max_cols = term_columns() - 1; /* don't print *on* the edge */
+ int i;
if (space < max_cols)
cols = max_cols / space;
- while (list) {
+ qsort(cmdname, cmdname_cnt, sizeof(*cmdname), cmdname_compare);
+
+ for (i = 0; i < cmdname_cnt; ) {
int c;
printf(" ");
- for (c = cols; c && list; list = list->next) {
- printf("%s", list->str);
+ for (c = cols; c && i < cmdname_cnt; i++) {
+ printf("%s", cmdname[i]->name);
if (--c)
- mput_char(' ', space - list->len);
+ mput_char(' ', space - cmdname[i]->len);
}
putchar('\n');
}
@@ -63,54 +98,53 @@ static void pretty_print_string_list(str
static void list_commands(const char *exec_path, const char *pattern)
{
- struct string_list *list = NULL, *tail = NULL;
- unsigned int longest = 0, i;
- glob_t gl;
+ unsigned int longest = 0;
+ char path[PATH_MAX];
+ int dirlen;
+ DIR *dir = opendir(exec_path);
+ struct dirent *de;
- if (chdir(exec_path) < 0) {
- printf("git: '%s': %s\n", exec_path, strerror(errno));
+ if (!dir) {
+ fprintf(stderr, "git: '%s': %s\n", exec_path, strerror(errno));
exit(1);
}
- i = glob(pattern, 0, NULL, &gl);
- switch(i) {
- case GLOB_NOSPACE:
- puts("Out of memory when running glob()");
- exit(2);
- case GLOB_ABORTED:
- printf("'%s': Read error: %s\n", exec_path, strerror(errno));
- exit(2);
- case GLOB_NOMATCH:
- printf("No git commands available in '%s'.\n", exec_path);
- printf("Do you need to specify --exec-path or set GIT_EXEC_PATH?\n");
+ dirlen = strlen(exec_path);
+ if (PATH_MAX - 20 < dirlen) {
+ fprintf(stderr, "git: insanely long exec-path '%s'\n",
+ exec_path);
exit(1);
}
- for (i = 0; i < gl.gl_pathc; i++) {
- int len = strlen(gl.gl_pathv[i] + 4);
+ memcpy(path, exec_path, dirlen);
+ path[dirlen++] = '/';
+
+ while ((de = readdir(dir)) != NULL) {
+ struct stat st;
+ int entlen;
- if (access(gl.gl_pathv[i], X_OK))
+ if (strncmp(de->d_name, "git-", 4))
+ continue;
+ strcpy(path+dirlen, de->d_name);
+ if (stat(path, &st) || /* stat, not lstat */
+ !S_ISREG(st.st_mode) ||
+ !(st.st_mode & S_IXUSR))
continue;
- if (longest < len)
- longest = len;
+ entlen = strlen(de->d_name);
- if (!tail)
- tail = list = malloc(sizeof(struct string_list));
- else {
- tail->next = malloc(sizeof(struct string_list));
- tail = tail->next;
- }
- tail->len = len;
- tail->str = gl.gl_pathv[i] + 4;
- tail->next = NULL;
+ if (longest < entlen)
+ longest = entlen;
+
+ add_cmdname(de->d_name + 4, entlen-4);
}
+ closedir(dir);
printf("git commands available in '%s'\n", exec_path);
printf("----------------------------");
mput_char('-', strlen(exec_path));
putchar('\n');
- pretty_print_string_list(list, longest);
+ pretty_print_string_list(cmdname, longest - 4);
putchar('\n');
}
@@ -146,7 +180,7 @@ static void prepend_to_path(const char *
int path_len = len;
if (!old_path)
- old_path = "/bin:/usr/bin:.";
+ old_path = "/usr/local/bin:/usr/bin:/bin";
path_len = len + strlen(old_path) + 1;
@@ -160,8 +194,6 @@ static void prepend_to_path(const char *
setenv("PATH", path, 1);
}
-/* has anyone seen 'man' installed anywhere else than in /usr/bin? */
-#define PATH_TO_MAN "/usr/bin/man"
static void show_man_page(char *git_cmd)
{
char *page;
@@ -177,7 +209,7 @@ static void show_man_page(char *git_cmd)
page[page_len] = 0;
}
- execlp(PATH_TO_MAN, "man", page, NULL);
+ execlp("man", "man", page, NULL);
}
int main(int argc, char **argv, char **envp)
@@ -226,15 +258,25 @@ int main(int argc, char **argv, char **e
show_man_page(argv[i]);
}
- /* allow relative paths, but run with exact */
- if (chdir(exec_path)) {
- printf("git: '%s': %s\n", exec_path, strerror(errno));
- exit (1);
- }
-
- getcwd(git_command, sizeof(git_command));
- chdir(wd);
+ if (*exec_path != '/') {
+ if (!getcwd(git_command, sizeof(git_command))) {
+ fprintf(stderr,
+ "git: cannot determine current directory");
+ exit(1);
+ }
+ len = strlen(git_command);
+ /* Trivial cleanup */
+ while (!strncmp(exec_path, "./", 2)) {
+ exec_path += 2;
+ while (*exec_path == '/')
+ *exec_path++;
+ }
+ snprintf(git_command + len, sizeof(git_command) - len,
+ "/%s", exec_path);
+ }
+ else
+ strcpy(git_command, exec_path);
len = strlen(git_command);
prepend_to_path(git_command, len);
---
0.99.9.GIT
^ permalink raw reply related
* Re: fix git-pack-redundant crashing sometimes
From: Alex Riesen @ 2005-11-16 7:01 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, junkio
In-Reply-To: <437A6B8A.8060905@etek.chalmers.se>
On 11/16/05, Lukas Sandström <lukass@etek.chalmers.se> wrote:
> OTOH, I might be wrong and it could very well be an infinite loop.
> Mind running it over the night? I won't look further into this in
> 20 hours or so anyway.
You missed by some minutes and I fell asleep :) Now, it is some 12
hours until I get to the machine with the lot of packs.
^ permalink raw reply
* Re: [PATCH 3/3] git --help COMMAND brings up the git-COMMAND man-page., take two
From: Andreas Ericsson @ 2005-11-16 6:56 UTC (permalink / raw)
To: git
In-Reply-To: <437AAB48.7090904@zytor.com>
H. Peter Anvin wrote:
> Andreas Ericsson wrote:
>> +
>> + execlp("man", "man", page, NULL);
>> +}
>> +
>
>
> The way this made it into the actual tree was to call /usr/bin/man, but
> still using execlp(). This is clearly bogus. There *ARE* good reasons
> to use PATH resolutions for this, since man is one of the interactive
> commands the user may want to wrapper.
>
Everyone agrees. I just brained the original implementation.
> So please drop PATH_TO_MAN that made it into the repository and revert
> to the original patch.
>
PATH_TO_MAN *was* the original. This is the updated version. I think
Junio imported the wrong one by mistake, cause I sent this one
specifically to fix the first one.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Fix compilation of git.c
From: Andreas Ericsson @ 2005-11-16 6:54 UTC (permalink / raw)
To: git
In-Reply-To: <7v4q6de1oc.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>
>>Some systems do not define GLOB_ABORTED and GLOB_NOMATCH.
>
>
> That's true, but the glob does not distinguish executables and
> others anyway, do wouldn't it be more portable and easier to do
> readdir, stat and list in the loop?
>
Got one implementation of that too, but it doesn't sort the command list
and I thought it was nice to have them that way while too lazy to
implement myself.
OTOH, that switch/case thing was for debugging (forgot prefix=/usr when
compiling...). I'm perfectly fine with
if (glob(....)) {
error_out("friendly message");
}
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Deprecate --cache.* ?
From: Junio C Hamano @ 2005-11-16 6:06 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git
In-Reply-To: <437A5F08.7020908@etek.chalmers.se>
Lukas Sandström <lukass@etek.chalmers.se> writes:
> Backward compability could be ensured by having both versions of the flags
> around for a while and issuing a warning when the old form is used.
>
> Good idea? Bad? Stupid? Do we want to keep "cache" around?
I agree that may be a logical move, with proper b/c slack, but I
am not _so_ enthused about this...
^ permalink raw reply
* Re: pushing patches to an imap folder
From: Martin Langhoff @ 2005-11-16 3:45 UTC (permalink / raw)
To: Mike McCormack; +Cc: Junio C Hamano, git, Kevin Geiss
In-Reply-To: <4379B9F6.5020402@codeweavers.com>
On 11/15/05, Mike McCormack <mike@codeweavers.com> wrote:
> It will probably be maintained in parallel with the Wine CVS for a
> while, unless somebody writes a GIT->CVS gateway.
The missing 'git-cvsexport' command should be the missing part for the
gateway. I am not hacking on it right now, but Kevin seemed to be
getting started in that direction. If not, I'll probably hack
something together eventually.
I don't have any project currently migrating to GIT... yet ;-)
martin
^ permalink raw reply
* Re: [PATCH 3/3] git --help COMMAND brings up the git-COMMAND man-page., take two
From: H. Peter Anvin @ 2005-11-16 3:45 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20051116002318.A46C55BF97@nox.op5.se>
Andreas Ericsson wrote:
>
> +static void show_man_page(char *git_cmd)
> +{
> + char *page;
> +
> + if (!strncmp(git_cmd, "git", 3))
> + page = git_cmd;
> + else {
> + int page_len = strlen(git_cmd) + 4;
> +
> + page = malloc(page_len + 1);
> + strcpy(page, "git-");
> + strcpy(page + 4, git_cmd);
> + page[page_len] = 0;
> + }
> +
> + execlp("man", "man", page, NULL);
> +}
> +
The way this made it into the actual tree was to call /usr/bin/man, but
still using execlp(). This is clearly bogus. There *ARE* good reasons
to use PATH resolutions for this, since man is one of the interactive
commands the user may want to wrapper.
So please drop PATH_TO_MAN that made it into the repository and revert
to the original patch.
-hpa
^ 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