* StGIT usage
From: Don Zickus @ 2005-12-14 16:44 UTC (permalink / raw)
Cc: git
I couldn't find in the StGIT documentation on how to use a 'series'
file or to pull a whole bunch of patches from a directory. It seems
the import command could only handle a patch at a time. Any
tips/help?
Cheers,
Don
^ permalink raw reply
* Re: new file leaked onto release branch
From: Linus Torvalds @ 2005-12-14 16:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Len Brown, git
In-Reply-To: <7vmzj4yq3l.fsf@assigned-by-dhcp.cox.net>
On Wed, 14 Dec 2005, Junio C Hamano wrote:
>
> Gahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh.
>
> Forget about what I said. Although all of what I said above are
> correct, I do not think it applies to your case at all --- these
> commits do not appear to be created by git-pull nor git-merge,
> and honestly, they look quite bogus. There is something else
> going on.
>
> $ git cat-file commit 9115a6
> tree da65904b8c0c0bc6c778b39bc25d06e07ca7c82c
> parent 927fe18397b3b1194a5b26b1d388d97e391e5fd2
> parent e4f5c82a92c2a546a16af1614114eec19120e40a
> author Len Brown <len.brown@intel.com> 1133904460 -0500
> committer Len Brown <len.brown@intel.com> 1133904460 -0500
>
> Auto-update from upstream
>
> $ git-merge-base 9115a6^1 9115a6^2; git-rev-parse 9115a6^2
> e4f5c82a92c2a546a16af1614114eec19120e40a
> e4f5c82a92c2a546a16af1614114eec19120e40a
Argh.
Len, how old a git are you using? "git-merge" really should _never_ have
done this, but old (and I mean really old) git merges sometimes got
confused with the base parent and would create a merge even when it was
unnecessary.
Linus
^ permalink raw reply
* Re: [PATCH] Make git-send-pack exit with error when some refs cou ldn't be pushed out
From: Jon Loeliger @ 2005-12-14 16:15 UTC (permalink / raw)
To: Git List
In-Reply-To: <20051214023005.GS10680@pasky.or.cz>
On Tue, 2005-12-13 at 20:30, Petr Baudis wrote:
>
> Jonas only reported it on IRC as weird cg-commit behaviour (which it
Gah. Are we IRCing now too these days? Did I miss a step
or an announcment? I thought we were all doing a reasonably
good job of communicating here on list... And if I do need
to sit-n-watch some IRC channel somewhere to get a complete
git-fix, please let me know what it is! :-)
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 5/11] git-applypatch: Usage string clean-up, emit usage string at incorrect invocation
From: Timo Hirvonen @ 2005-12-14 12:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: freku045, git
In-Reply-To: <7vfyow45l2.fsf@assigned-by-dhcp.cox.net>
On Tue, 13 Dec 2005 21:20:57 -0800
Junio C Hamano <junkio@cox.net> wrote:
> freku045@student.liu.se writes:
>
> > . git-sh-setup
> >
> > +[[ "$#" = "3" || "$#" = "4" ]] || usage
> > +
>
> I do not see much advantage to use [[...]] construct here.
[[ ]] is bashishm. Does not work with ash.
test $# -ge 3 && test $# -le 4 || usage
You don't need to quote $# because it is always defined (and always
non-negative integer). You can't unset or set it.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* RE: [ANNOUNCE] gitkdiff 0.1
From: KRONSTORFER Horst @ 2005-12-14 12:03 UTC (permalink / raw)
To: Tejun Heo; +Cc: git
> Tejun Heo wrote:
>Sven Verdoolaege wrote:
>> On Fri, Dec 09, 2005 at 10:45:33AM +0000, Horst Kronstorfer wrote:
>>
>>>Tejun Heo <htejun <at> gmail.com> writes:
>>>
>>>
>>>> http://home-tj.org/gitui/files/gitui-200504281405.tar.gz
>>>
>>>link is dead. any alternatives available?
>>>
>>
>> Probably not what you meant, but I think dirdiff does something similar.
>> Some changes again Paul's version are available from
>>
>> http://www.liacs.nl/~sverdool/gitweb.cgi?p=dirdiff.git;a=summary
>>
>http://home-tj.org/wiki/index.php/Mtkdiff
>--
>tejun
thanx for the link. app is really useful.
maybe you could state the app's dependencies on your wiki.
afaict that would be:
http://www.tcl.tk/ >= 8.4
http://cyberelk.net/tim/patchutils/
http://invisible-island.net/diffstat/
-h
^ permalink raw reply
* Re: git cole give unexpected error message
From: Petr Baudis @ 2005-12-14 11:41 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <439FE7AD.6080602@op5.se>
Dear diary, on Wed, Dec 14, 2005 at 10:36:45AM CET, I got a letter
where Andreas Ericsson <ae@op5.se> said that...
> Petr Baudis wrote:
> >Dear diary, on Tue, Dec 13, 2005 at 10:28:20PM CET, I got a letter
> >where Sam Ravnborg <sam@ravnborg.org> said that...
> >
> >>cogito being a nice porcelain gives the git errormessage but manage to
> >>clean up when the clone fails.
> >>So also cogito would benefit from a more descriptive errormessage.
> >
> >
> >Well, git clone can fail for many reasons and I don't think the "no such
> >repository" one is completely overwhelming, so hinting that by Cogito
> >could be quite confusing (theme of the day: usability ;-)).
> >
> >The real solution would be proper error reporting by the git daemon.
> >
>
> But that would open up for an information disclosure. If someone's
> hacking on a patch, please make it configurable at least.
When it breaks at this stage, it's either some bad internal error (I
guess memory allocation error might do this), permission problem, or
repository not being found. We might then report a more generic error
message "Repository not found or access denied.".
--
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: new file leaked onto release branch
From: Brown, Len @ 2005-12-14 9:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]
>What do you use to create these "Auto-update" commits, and how
>can I help you to fix it?
I use the attached script, which I pasted from
git/Documentation/howto/using-topic-branches.txt
git.update linus
to get the latest stuff from Linus onto the linus branch
git.update release
to pull linus branch into my release branch
git.update release
to pull linus branch into my test branch
I also use the git.merge script to pull topic branches
into either release or test, or to pull release into test.
I used git.merge to pull release into acpica because
acpica had fallen behind the base at one point, and this
may be where the issue happened.
in the case of the acpica topic branch, it was not pulled
back into either release or into test after the file in question
was added. Indeed, you can pull the acpica branch from the tree
on kernel.org.
I'm trying to remember if there were git error message along the way.
I do remember an issue with a commit where I had re-named a file
and git didn't recognize it as such. so I put this in my git.commit
wrapper:
git-udpate-index --add --remove `quilt files`
git commit
dunno if that may be related to the issue at hand.
I don't really understand this index stuff...
thanks,
-Len
[-- Attachment #2: git.update --]
[-- Type: application/octet-stream, Size: 624 bytes --]
#!/bin/bash
# Update a branch in my GIT tree. If the branch to be updated
# is "linus", then pull from kernel.org. Otherwise merge local
# linus branch into test|release branch
case "$1" in
test|release)
git checkout $1 && git merge "Auto-update from upstream" $1 linus
;;
linus)
before=$(cat .git/refs/heads/linus)
git fetch linus
after=$(cat .git/refs/heads/linus)
if [ $before != $after ]
then
git-whatchanged $after ^$before | git-shortlog
fi
;;
*)
echo "Usage: $0 linus|test|release" 1>&2
exit 1
;;
esac
[-- Attachment #3: git.merge --]
[-- Type: application/octet-stream, Size: 549 bytes --]
#!/bin/bash
# Merge a branch into either the test or release branch
pname=$0
usage()
{
echo "Usage: $pname branch test|release" 1>&2
exit 1
}
if [ ! -f .git/refs/heads/"$1" ]
then
echo "Can't see branch <$1>" 1>&2
usage
fi
case "$2" in
test|release)
if [ $(git-rev-list $1 ^$2 | wc -c) -eq 0 ]
then
echo $1 already merged into $2 1>&2
exit 1
fi
git checkout $2 && git merge "Pull $1 into $2 branch" $2 $1
;;
*)
usage
;;
esac
^ permalink raw reply
* RE: new file leaked onto release branch
From: Brown, Len @ 2005-12-14 9:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
>> I package up a tar-file for the remote machines with
>> git-tar-tree $BRANCH $REPO | gzip -1 > $TARFILE
>> But I still need to generate a patch containing all the local
>> changes that I haven't checked into git yet.
>
>Let me understand what you have correctly:
>
> You have the latest commit, changes needed to be tested in
> working tree, and index is somewhere in-between, because of
> "git-update-index --add" you did for patch generation; but
> ideally you would want to keep HEAD and index in sync.
Right, I updated the index so that git diff would work.
I guess I don't really have my head around the index concept.
Yes, it seems perhaps that HEAD and index disagreeing about what is
in the repo is what caused the problem at hand.
>And you need a way to do the above tar-tree + patch equivanent
>to move what you have in your working tree to other machines for
>pre-commit testing. Some random thoughts on ways to do it.
>
>(1) NFS with "make O=dir/to/store/output/files/"?
I think I prefer the build boxes to be more independent.
They build about a dozen kernels from scratch each,
so I can't really keep my working repo frozen for
the duration of the builds.
Also, sometimes I have them building different branches
and different versions, depending on what is going on.
Also, sometimes I apply a local test patch to the
build box that isn't (yet) shared with the other boxes.
>(2) Do you have git on other build boxes? Perhaps
>
> mainbox$ edit on "acpica" branch
> mainbox$ git checkout -b build-test ;# branch from it
> mainbox$ git add some files
> mainbox$ git commit -a -m "Build test $(date)" ;# take all
>
> mainbox$ ssh i386box
> i386box$ git pull mainbox:/home/lnx/.git build-test
> Fast forward.
> i386box$ make ;# happy
>
> mainbox$ git checkout acpica ; git pull . build-test ;#
>fast forward
sure, I have git everwhere. But check-in is not a lightweight
process for me -- I like to get the contributor & comments right
on the check-in as if I'm creating permanent history. I hate
checking in a patch just to have to check in a build fix for
it 20 minutes later.
this is why I use quilt. I just pop the patches, fix the
broken one, and push them back. after build and boot tests,
that is when I do the git commit.
>(3) Tarball approach, but taking the local modifications along
> as well:
>
> mainbox$ git update-index all-changed-paths-not-just-add
> mainbox$ git-tar-tree $(git-write-tree) $REPO | gzip >$TARFILE
> mainbox$ git reset ;# unregisters all mods since HEAD from index
> mainbox$ scp $TARFILE i386box:/home/lnx/
>
>I suspect the last one is the least disruptive to your existing
>workflow.
yes, this is along the lines of what I do now.
do these steps capture the changed uncommited source files in
my repo?
actually, since the mis-hap with the update-index, what I do now
is a make clean mrproper, move the .git directory out of the source tree
tar what is left, and then restore the .git directory...
this has the nice side effect of taking along the quilt patches directory,
and sometimes I've found it useful to do individual build/test
between patches in the quilt stack, though I'd probably lose track
of what I'm doing if I did that all the time.
thanks,
-Len
^ permalink raw reply
* Re: new file leaked onto release branch
From: Junio C Hamano @ 2005-12-14 9:39 UTC (permalink / raw)
To: Len Brown; +Cc: git
In-Reply-To: <200512140257.03975.len.brown@intel.com>
Len Brown <len.brown@intel.com> writes:
> I'm suspecting that this issue is technically a pilot error of me issuing
> git-updated-index at the wrong time, but perhaps the list
> should be aware of this type of issue.
Merging is so fundamental to git workflow, and it is not
supposed to be prone to pilot errors, so I am puzzled and
very worried, so I am still awake.
Even if you added some file to the index prior to merge, this
sequence:
$ git checkout one-branch
$ git add some-file
$ git pull . another-branch
should *never* succeed. It should always fail, saying:
fatal: Entry 'some-file' would be overwritten by merge. Cannot merge.
and I just tried it with both recursive (default) and resolve
merge strategies. They both do the right thing.
One exception is if you did something like this:
$ git checkout one-branch
$ git pull . another-branch ;# oops, merge conflicts!
$ edit conflicted files and fix
$ git update-index --add some-file
$ git commit
You can introduce unrelated changes to commits like that. Lemme
see what your release.broken looks like.
Gahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh.
Forget about what I said. Although all of what I said above are
correct, I do not think it applies to your case at all --- these
commits do not appear to be created by git-pull nor git-merge,
and honestly, they look quite bogus. There is something else
going on.
$ git cat-file commit 9115a6
tree da65904b8c0c0bc6c778b39bc25d06e07ca7c82c
parent 927fe18397b3b1194a5b26b1d388d97e391e5fd2
parent e4f5c82a92c2a546a16af1614114eec19120e40a
author Len Brown <len.brown@intel.com> 1133904460 -0500
committer Len Brown <len.brown@intel.com> 1133904460 -0500
Auto-update from upstream
$ git-merge-base 9115a6^1 9115a6^2; git-rev-parse 9115a6^2
e4f5c82a92c2a546a16af1614114eec19120e40a
e4f5c82a92c2a546a16af1614114eec19120e40a
What is this "Auto-update from upstream" merge? It is not a
merge at all, not even a fast forward. Your branch tip was
927fe1 and the other branch tip e4f5c8 was behind. In fact, I
just tried it and both of my attempts correctly said "Already
up-to-date.", with or without local changes to the index.
$ git show-branch --sha1-name --topo-order lenb/merge*
* [lenb/mergetest] Pull 5165 into release branch
! [lenb/mergeother] V4L/DVB (3087) fix analog NTSC for pcHDTV 3000
--
+ [927fe18] Pull 5165 into release branch
+ [1e48396] [ACPI] correct earlier SMP deep C-states on HT patch
++ [e4f5c82] V4L/DVB (3087) fix analog NTSC for pcHDTV 3000
$ git pull . lenb/mergeother
Already up-to-date.
What do you use to create these "Auto-update" commits?
I think 9115a6 commit should not *even* *exist*. The merge
between 927fe1 and e4f5c8 should have resulted in "Oh, we are
already up-to-date and they are behind, so there is nothing for
us to do".
Or if your tool somehow records your tree as the second parent
(goes against the usual convention but is a valid thing to do),
it should have resulted in "Updating from e4f5c8... to 927fe1.
Fast forward".
In either case, 9115a6 commit should never have been created in
the first place.
What do you use to create these "Auto-update" commits, and how
can I help you to fix it?
^ permalink raw reply
* Re: git cole give unexpected error message
From: Andreas Ericsson @ 2005-12-14 9:36 UTC (permalink / raw)
To: git
In-Reply-To: <20051213222829.GE22159@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Tue, Dec 13, 2005 at 10:28:20PM CET, I got a letter
> where Sam Ravnborg <sam@ravnborg.org> said that...
>
>>cogito being a nice porcelain gives the git errormessage but manage to
>>clean up when the clone fails.
>>So also cogito would benefit from a more descriptive errormessage.
>
>
> Well, git clone can fail for many reasons and I don't think the "no such
> repository" one is completely overwhelming, so hinting that by Cogito
> could be quite confusing (theme of the day: usability ;-)).
>
> The real solution would be proper error reporting by the git daemon.
>
But that would open up for an information disclosure. If someone's
hacking on a patch, please make it configurable at least.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-am support for naked email messages (take 2)
From: Martin Langhoff @ 2005-12-14 8:38 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <439FBE1B.4050601@zytor.com>
On 12/14/05, H. Peter Anvin <hpa@zytor.com> wrote:
> This allows git-am to accept single-message files as well as mboxes.
> Unlike the previous version, this one doesn't need to be explicitly told
> which one it is; rather, it looks to see if the first line is a From
> line and uses it to select mbox mode or not.
Yes, please. These changes to git-am/git-mailsplit are very welcome by
those that don't use mbox-based MUAs. The whole workflow if git-am is
really trying if you are IMAP or Gmail/webmail based.
BTW, I recently had a go at using a Perl Gmail library to fetch
messages with a particular label into an mbox, but the library didn't
work, and I don't want to be chasing the taillights of gmails internal
API. If the python Gmail library works better, I may have a go at
learning python ;-)
cheers,
martin
^ permalink raw reply
* Re: new file leaked onto release branch
From: Junio C Hamano @ 2005-12-14 8:37 UTC (permalink / raw)
To: Len Brown; +Cc: git
In-Reply-To: <200512140257.03975.len.brown@intel.com>
Len Brown <len.brown@intel.com> writes:
> Somehow a new file leaked from my "acpica" branch onto my "release" branch
> without me pulling "acpica" into "release".
I'll take a look at your "broken" branch later today (but will
go to bed first ;-), so please leave it around.
> I package up a tar-file for the remote machines with
> git-tar-tree $BRANCH $REPO | gzip -1 > $TARFILE
> But I still need to generate a patch containing all the local
> changes that I haven't checked into git yet.
Let me understand what you have correctly:
You have the latest commit, changes needed to be tested in
working tree, and index is somewhere in-between, because of
"git-update-index --add" you did for patch generation; but
ideally you would want to keep HEAD and index in sync.
And you need a way to do the above tar-tree + patch equivanent
to move what you have in your working tree to other machines for
pre-commit testing. Some random thoughts on ways to do it.
(1) NFS with "make O=dir/to/store/output/files/"?
(2) Do you have git on other build boxes? Perhaps
mainbox$ edit on "acpica" branch
mainbox$ git checkout -b build-test ;# branch from it
mainbox$ git add some files
mainbox$ git commit -a -m "Build test $(date)" ;# take all
mainbox$ ssh i386box
i386box$ git pull mainbox:/home/lnx/.git build-test
Fast forward.
i386box$ make ;# happy
mainbox$ git checkout acpica ; git pull . build-test ;# fast forward
(3) Tarball approach, but taking the local modifications along
as well:
mainbox$ git update-index all-changed-paths-not-just-add
mainbox$ git-tar-tree $(git-write-tree) $REPO | gzip >$TARFILE
mainbox$ git reset ;# unregisters all mods since HEAD from index
mainbox$ scp $TARFILE i386box:/home/lnx/
I suspect the last one is the least disruptive to your existing
workflow.
^ permalink raw reply
* new file leaked onto release branch
From: Len Brown @ 2005-12-14 7:57 UTC (permalink / raw)
To: git
I'm suspecting that this issue is technically a pilot error of me issuing
git-updated-index at the wrong time, but perhaps the list
should be aware of this type of issue. And perhaps somebody
can suggest a better work flow that is immune to this?
Somehow a new file leaked from my "acpica" branch onto my "release" branch
without me pulling "acpica" into "release".
I use the latest git and I follow Tony's Documentation/howto/using-topic-branches.txt.
The new file, rsinfo.c, was added in one of the patches in the acpi branch,
but then was sucked into the release branch in this commit:
9115a6c787596e687df03010d97fccc5e0762506
which is on the release.broken branch of this tree:
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
Even though the file didn't exist on either of the parents of the merge.
I think I probably did a git-update-index while working on the acpica
branch, and then git remembered that while I was on the release branch
doing a routine pull from linus to make sure I was up-to-date before
doing a push to kernel.org.
why did I do this?
I use quilt to manage a stack of patches in my repo.
I like to build them on several build machines (i386, x86_64, ia64)
before doing a git commit.
I package up a tar-file for the remote machines with
git-tar-tree $BRANCH $REPO | gzip -1 > $TARFILE
But I still need to generate a patch containing all the local
changes that I haven't checked into git yet.
git diff > my.patch
does this for me. But when it failed to pick up a new file,
I manually did a git-update-index --add IIR, and that seems
to be how rsinfo.c got sucked into the subsequent git pull from linus.
perhaps somebody has a better idiom for packaging up a current
working tree for a remote build machine to crunch on it?
thanks,
-Len
^ permalink raw reply
* [PATCH] git-am support for naked email messages (take 2)
From: H. Peter Anvin @ 2005-12-14 6:39 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
This allows git-am to accept single-message files as well as mboxes.
Unlike the previous version, this one doesn't need to be explicitly told
which one it is; rather, it looks to see if the first line is a From
line and uses it to select mbox mode or not.
I moved the logic to do all this into git-mailsplit, which got a new
user interface as result, although the old interface is still available
for backwards compatibility.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 5170 bytes --]
diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt
index 03a9477..e0703e9 100644
--- a/Documentation/git-mailsplit.txt
+++ b/Documentation/git-mailsplit.txt
@@ -7,7 +7,7 @@ git-mailsplit - Totally braindamaged mbo
SYNOPSIS
--------
-'git-mailsplit' [-d<prec>] [<mbox>] <directory>
+'git-mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>...]
DESCRIPTION
-----------
@@ -23,11 +23,18 @@ OPTIONS
<directory>::
Directory in which to place the individual messages.
+-b::
+ If any file doesn't begin with a From line, assume it is a
+ single mail message instead of signalling error.
+
-d<prec>::
Instead of the default 4 digits with leading zeros,
different precision can be specified for the generated
filenames.
+-f<nn>::
+ Skip the first <nn> numbers, for example if -f3 is specified,
+ start the numbering with 0004.
Author
------
diff --git a/git-am.sh b/git-am.sh
index 6ed527c..f143b7e 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -164,10 +164,7 @@ else
# Start afresh.
mkdir -p "$dotest" || exit
- # cat does the right thing for us, including '-' to mean
- # standard input.
- cat "$@" |
- git-mailsplit -d$prec "$dotest/" >"$dotest/last" || {
+ git-mailsplit -d"$prec" -o"$dotest" -b -- "$@" > "$dotest/last" || {
rm -fr "$dotest"
exit 1
}
diff --git a/mailsplit.c b/mailsplit.c
index 189f4ed..f49cbf7 100644
--- a/mailsplit.c
+++ b/mailsplit.c
@@ -15,7 +15,7 @@
#include "cache.h"
static const char git_mailsplit_usage[] =
-"git-mailsplit [-d<prec>] [<mbox>] <directory>";
+"git-mailsplit [-d<prec>] [-f<n>] [-b] -o<directory> <mbox>...";
static int is_from_line(const char *line, int len)
{
@@ -56,14 +56,15 @@ static char buf[4096];
* the Unix "From " line. Write it into the specified
* file.
*/
-static int split_one(FILE *mbox, const char *name)
+static int split_one(FILE *mbox, const char *name, int allow_bare)
{
FILE *output = NULL;
int len = strlen(buf);
int fd;
int status = 0;
+ int is_bare = !is_from_line(buf, len);
- if (!is_from_line(buf, len))
+ if (is_bare && !allow_bare)
goto corrupt;
fd = open(name, O_WRONLY | O_CREAT | O_EXCL, 0666);
@@ -88,7 +89,7 @@ static int split_one(FILE *mbox, const c
die("cannot read mbox");
}
len = strlen(buf);
- if (!is_partial && is_from_line(buf, len))
+ if (!is_partial && !is_bare && is_from_line(buf, len))
break; /* done with one message */
}
fclose(output);
@@ -104,54 +105,84 @@ static int split_one(FILE *mbox, const c
int main(int argc, const char **argv)
{
- int i, nr, nr_prec = 4;
- FILE *mbox = NULL;
+ int nr = 0, nr_prec = 4;
+ int allow_bare = 0;
+ const char *dir = NULL;
+ const char **argp;
+ static const char *stdin_only[] = { "-", NULL };
+ char *name;
- for (i = 1; i < argc; i++) {
- const char *arg = argv[i];
+ for (argp = argv+1; *argp; argp++) {
+ const char *arg = *argp;
if (arg[0] != '-')
break;
/* do flags here */
- if (!strncmp(arg, "-d", 2)) {
- nr_prec = strtol(arg + 2, NULL, 10);
+ if ( arg[1] == 'd' ) {
+ nr_prec = strtol(arg+2, NULL, 10);
if (nr_prec < 3 || 10 <= nr_prec)
usage(git_mailsplit_usage);
continue;
+ } else if ( arg[1] == 'f' ) {
+ nr = strtol(arg+2, NULL, 10);
+ } else if ( arg[1] == 'b' && !arg[2] ) {
+ allow_bare = 1;
+ } else if ( arg[1] == 'o' && arg[2] ) {
+ dir = arg+2;
+ } else if ( arg[1] == '-' && !arg[2] ) {
+ argp++; /* -- marks end of options */
+ break;
+ } else {
+ die("unknown option: %s", arg);
}
}
- /* Either one remaining arg (dir), or two (mbox and dir) */
- switch (argc - i) {
- case 1:
- mbox = stdin;
- break;
- case 2:
- if ((mbox = fopen(argv[i], "r")) == NULL)
- die("cannot open mbox %s for reading", argv[i]);
- break;
- default:
- usage(git_mailsplit_usage);
+ if ( !dir ) {
+ /* Backwards compatibility: if no -o specified, accept
+ <mbox> <dir> or just <dir> */
+ switch (argc - (argp-argv)) {
+ case 1:
+ dir = argp[0];
+ argp = stdin_only;
+ break;
+ case 2:
+ stdin_only[0] = argp[0];
+ dir = argp[1];
+ argp = stdin_only;
+ break;
+ default:
+ usage(git_mailsplit_usage);
+ }
+ } else {
+ /* New usage: if no more argument, parse stdin */
+ if ( !*argp )
+ argp = stdin_only;
}
- if (chdir(argv[argc - 1]) < 0)
- usage(git_mailsplit_usage);
-
- nr = 0;
- if (fgets(buf, sizeof(buf), mbox) == NULL)
- die("cannot read mbox");
- for (;;) {
- char name[10];
+ name = xmalloc(strlen(dir)+2+3*sizeof nr);
- sprintf(name, "%0*d", nr_prec, ++nr);
- switch (split_one(mbox, name)) {
- case 0:
- break;
- case 1:
- printf("%d\n", nr);
- return 0;
- default:
- exit(1);
+ while ( argp ) {
+ const char *file = *argp++;
+ FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "rt");
+ int file_done = 0;
+
+ if ( !f )
+ die ("cannot open mbox %s", file);
+
+ if (fgets(buf, sizeof(buf), f) == NULL)
+ die("cannot read mbox %s", file);
+
+ while (!file_done) {
+ char name[10];
+
+ sprintf(name, "%s/%0*d", dir, nr_prec, ++nr);
+ file_done = split_one(f, name, allow_bare);
}
+
+ if (f != stdin)
+ fclose(f);
}
+
+ printf("%d\n", nr);
+ return 0;
}
^ permalink raw reply related
* Re: [PATCH 5/11] git-applypatch: Usage string clean-up, emit usage string at incorrect invocation
From: Junio C Hamano @ 2005-12-14 5:20 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <11345130311492-git-send-email-freku045@student.liu.se>
freku045@student.liu.se writes:
> . git-sh-setup
>
> +[[ "$#" = "3" || "$#" = "4" ]] || usage
> +
I do not see much advantage to use [[...]] construct here.
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_04
talks about [[ ... ]] being "some implementations causing
unspecified results".
^ permalink raw reply
* Re: [PATCH] Make git-send-pack exit with error when some refs couldn't be pushed out
From: Petr Baudis @ 2005-12-14 2:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqzk5tx1.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Dec 14, 2005 at 02:50:02AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> However, I am not quite sure if the recent change to Cogito to
> update the mirror of remote branch is a good one. Since I am
> not a Cogito user, I did not question it when I saw the change,
> but I wondered what you are using the cached "remote ref is
> supposed to be pointing at this commit" knowledge for. If it is
> only "pretending to have fetched the remote branch immediately
> after we pushed into it before anybody else touched the same
> remote branch", then it probably is benign.
Exactly, we're just pretending that. It's useful since cg-fetch's
diff-tree output is less confusing then, cg-log -r <remotebranch> and
cg-diff -r ... gives expected results, etc.
> But this bit puzzles and worries me:
>
> > ... otherwise
> > it gets out of sync, which can lead even to loss of commits on the local
> > side (this happenned to Jonas Fonseca - thanks for the report, BTW).
>
> I do not remember seeing that report so I do not know how that
> lossage happens with unreleased Cogito, but I suspect there is
> something very fishy going on here. I presume it happens when
> the next fetch/pull from the remote is run, but if the locally
> cached information can affect the next fetch/pull in such a way,
> wouldn't updates by other people to the shared remote repository
> branch also cause things to go out-of-sync and cause the same
> breakage?
Jonas only reported it on IRC as weird cg-commit behaviour (which it
appeared to be, but the cause turned out to be this and the nice
side-effect that this kind of breakage cannot lose you actual data at
least, just metadata).
If the push really happened, this shouldn't be a problem, since then we
get into a "fast-forward relation" to the remote branch, and commits by
other people don't affect it either, since they don't break this
relation. The "interesting behaviour" Cogito implements happens only if
your current HEAD == <the_old_remote_head>, which can't happen when
other people commit, only when you push it out to the remote head.
What kicks in is the fast-forward behaviour change I proposed quite some
time ago on the mailing list and got zero feedback about --- when
updating from a remote branch, the Cogito 0.17pre's fast-forward test
is extended from
if (head ancestor_of remote_new)
to
if (head ancestor_of remote_new OR head == remote_old)
which will make fast-forward able to follow even remote rebases
and should have no negative side-effects as long as remote_old
was correct (which it is except when our bug comes out). So in
the reported case, remote_old was set to head, while remote_new
stayed as before, and Cogito therefore thought that the remote
branch just got rebased from head to remote_new, and adjusted
the head appropriately.
--
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: [PATCH] git-am --one
From: Junio C Hamano @ 2005-12-14 2:06 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <439F7105.9050302@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> This is a multi-part message in MIME format.
> --------------080605010801030702080802
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
BTW, this is totally offtopic, but I find it somewhat puzzling
to see somebody like you, one of Linus' trusted lieutenants, is
sending a patch as an attachment.
^ permalink raw reply
* Re: [PATCH] git-am --one
From: H. Peter Anvin @ 2005-12-14 1:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ja85tqe.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Another thing you may probably want is to loop over "$@", so
> that the flag is not --one anymore, but --2822 (or --bare as
> opposed to mbox format) and do something like this:
>
> case "$series_of_2822_messages" in
> '') ... original code ... ;;
> *)
> i=1
> for input
> do
> this=`printf "%${prec}d" $i
> cp "$input" "$dotest/$this"
> i=$(($i+1))
> done
> printf "%${prec}d" $# >"$dotest/last"
> ;;
> esac
>
That is definitely a good idea. I'll mess with it a bit.
-hpa
^ permalink raw reply
* Re: [PATCH] git-am --one
From: Junio C Hamano @ 2005-12-14 1:54 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <439F79B3.6000309@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Junio C Hamano wrote:
>> I understand the motivation, but I suspect skipping mailsplit
>> might be simpler, like this untested code perhaps?
>> case "$one" in
>> '')
>> ... original code ...
>> ;;
>> *)
>> one=`printf "%${prec}d" 1`
>> cat "$@" >"$dotest/$one"
>> echo "$one" >"$dotest/last"
>> ;;
>> esac
>>
>
> If that works, great. I just implemented it in the "most obviously
> correct" way, meaning with as few changes as possible.
Another thing you may probably want is to loop over "$@", so
that the flag is not --one anymore, but --2822 (or --bare as
opposed to mbox format) and do something like this:
case "$series_of_2822_messages" in
'') ... original code ... ;;
*)
i=1
for input
do
this=`printf "%${prec}d" $i
cp "$input" "$dotest/$this"
i=$(($i+1))
done
printf "%${prec}d" $# >"$dotest/last"
;;
esac
^ permalink raw reply
* Re: [PATCH] Make git-send-pack exit with error when some refs couldn't be pushed out
From: Junio C Hamano @ 2005-12-14 1:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051214004540.15040.93518.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> In case some refs couldn't be pushed out due to an error (mostly the
> not-a-proper-subset error), make git-send-pack exit with non-zero status
> after the push is over (that is, it still tries to push out the rest
> of the refs).
I agree this change to send-pack is a good fix (I haven't looked
at the code, but the above description describes a good fix).
However, I am not quite sure if the recent change to Cogito to
update the mirror of remote branch is a good one. Since I am
not a Cogito user, I did not question it when I saw the change,
but I wondered what you are using the cached "remote ref is
supposed to be pointing at this commit" knowledge for. If it is
only "pretending to have fetched the remote branch immediately
after we pushed into it before anybody else touched the same
remote branch", then it probably is benign. But this bit
puzzles and worries me:
> ... otherwise
> it gets out of sync, which can lead even to loss of commits on the local
> side (this happenned to Jonas Fonseca - thanks for the report, BTW).
I do not remember seeing that report so I do not know how that
lossage happens with unreleased Cogito, but I suspect there is
something very fishy going on here. I presume it happens when
the next fetch/pull from the remote is run, but if the locally
cached information can affect the next fetch/pull in such a way,
wouldn't updates by other people to the shared remote repository
branch also cause things to go out-of-sync and cause the same
breakage?
^ permalink raw reply
* Re: [PATCH] git-am --one
From: H. Peter Anvin @ 2005-12-14 1:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy82o5uss.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> I understand the motivation, but I suspect skipping mailsplit
> might be simpler, like this untested code perhaps?
>
> case "$one" in
> '')
> ... original code ...
> ;;
> *)
> one=`printf "%${prec}d" 1`
> cat "$@" >"$dotest/$one"
> echo "$one" >"$dotest/last"
> ;;
> esac
>
If that works, great. I just implemented it in the "most obviously
correct" way, meaning with as few changes as possible.
-hpa
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.16.1
From: Paul Dickson @ 2005-12-14 1:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051213223114.GF22159@pasky.or.cz>
On Tue, 13 Dec 2005 23:31:14 +0100, Petr Baudis wrote:
> But the spec file also makes the 'doc' and 'install-doc' targets. When
> you act as a packager, asciidoc becomes a reasonable build-time
> requirement.
My mistake. They weren't part of the 15.1 RPM and I didn't check after I
installed 16.1. They are there now.
-Paul
^ permalink raw reply
* Re: [PATCH] git-am --one
From: Junio C Hamano @ 2005-12-14 1:30 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <439F7105.9050302@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> This patch adds the --one (-o) option to git-am, to apply a single
> message in RFC 2822 format, as opposed to an mbox. With some MUAs it's
> a lot easier to save individual messages than with mboxes, and either
> way the user may want to control the ordering if there are known
> interdependencies.
> + # standard input. To prepend the header, we thus want a
> + # second cat, sigh...
> + if test "$one" = t
> + then
> + LANG=C date +'From - %a %b %d %T %Y' > "$dotest"/fakefrom
> + fakefrom="$dotest"/fakefrom
> + else
> + fakefrom=/dev/null
> + fi
> + cat "$@" | cat "$fakefrom" - |
> git-mailsplit -d$prec "$dotest/" >"$dotest/last" || {
> rm -fr "$dotest"
> exit 1
I understand the motivation, but I suspect skipping mailsplit
might be simpler, like this untested code perhaps?
case "$one" in
'')
... original code ...
;;
*)
one=`printf "%${prec}d" 1`
cat "$@" >"$dotest/$one"
echo "$one" >"$dotest/last"
;;
esac
^ permalink raw reply
* [PATCH] git-am --one
From: H. Peter Anvin @ 2005-12-14 1:10 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 344 bytes --]
This patch adds the --one (-o) option to git-am, to apply a single
message in RFC 2822 format, as opposed to an mbox. With some MUAs it's
a lot easier to save individual messages than with mboxes, and either
way the user may want to control the ordering if there are known
interdependencies.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
[-- Attachment #2: git-am-one --]
[-- Type: text/plain, Size: 2100 bytes --]
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index a415fe2..bec5c84 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -8,7 +8,7 @@ git-am - Apply a series of patches in a
SYNOPSIS
--------
-'git-am' [--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way] <mbox>...
+'git-am' [--one] [--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way] <mbox>...
'git-am' [--skip | --resolved]
DESCRIPTION
@@ -19,6 +19,10 @@ current branch.
OPTIONS
-------
+--one::
+ Indicates that <mbox> contains a single message in RFC 2822
+ format, without mbox-style separators.
+
--signoff::
Add `Signed-off-by:` line to the commit message, using
the committer identity of yourself.
diff --git a/git-am.sh b/git-am.sh
index 6ed527c..9628651 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -4,7 +4,7 @@
. git-sh-setup
usage () {
- echo >&2 "usage: $0 [--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way] <mbox>"
+ echo >&2 "usage: $0 [--one] [--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way] <mbox>"
echo >&2 " or, when resuming"
echo >&2 " $0 [--skip | --resolved]"
exit 1;
@@ -98,11 +98,13 @@ fall_back_3way () {
}
prec=4
-dotest=.dotest sign= utf8= keep= skip= interactive= resolved= binary=
+dotest=.dotest sign= utf8= keep= skip= interactive= resolved= binary= one=
while case "$#" in 0) break;; esac
do
case "$1" in
+ -o|--o|--on|--one)
+ one=t; shift;;
-d=*|--d=*|--do=*|--dot=*|--dote=*|--dotes=*|--dotest=*)
dotest=`expr "$1" : '-[^=]*=\(.*\)'`; shift ;;
-d|--d|--do|--dot|--dote|--dotes|--dotest)
@@ -165,8 +167,16 @@ else
mkdir -p "$dotest" || exit
# cat does the right thing for us, including '-' to mean
- # standard input.
- cat "$@" |
+ # standard input. To prepend the header, we thus want a
+ # second cat, sigh...
+ if test "$one" = t
+ then
+ LANG=C date +'From - %a %b %d %T %Y' > "$dotest"/fakefrom
+ fakefrom="$dotest"/fakefrom
+ else
+ fakefrom=/dev/null
+ fi
+ cat "$@" | cat "$fakefrom" - |
git-mailsplit -d$prec "$dotest/" >"$dotest/last" || {
rm -fr "$dotest"
exit 1
^ permalink raw reply related
* [PATCH] Make git-send-pack exit with error when some refs couldn't be pushed out
From: Petr Baudis @ 2005-12-14 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In case some refs couldn't be pushed out due to an error (mostly the
not-a-proper-subset error), make git-send-pack exit with non-zero status
after the push is over (that is, it still tries to push out the rest
of the refs).
Cogito (0.17pre only, 0.16 is unaffected) needs to know that the push
failed so that it won't update its remote branch head pointer - otherwise
it gets out of sync, which can lead even to loss of commits on the local
side (this happenned to Jonas Fonseca - thanks for the report, BTW).
I sort of expected that git-send-pack would return an error in case
of a failure, so just applying this should magically fix Cogito.
I don't insist on this particular solution though - a fetch-pack-alike
approach where I get the list of changed refs on stdout is fine too
(currently I get something on stderr, but I'm reluctant to grab stderr
of GIT commands and try to heuristically mangle it).
At any rate, please consider this a major problem from Cogito perspective.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
send-pack.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index f61c15c..6ce0d9f 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -179,6 +179,7 @@ static int send_pack(int in, int out, in
{
struct ref *ref;
int new_refs;
+ int ret = 0;
/* No funny business with the matcher */
remote_tail = get_remote_heads(in, &remote_refs, 0, NULL, 1);
@@ -232,6 +233,7 @@ static int send_pack(int in, int out, in
error("remote '%s' object %s does not "
"exist on local",
ref->name, sha1_to_hex(ref->old_sha1));
+ ret = -2;
continue;
}
@@ -245,12 +247,14 @@ static int send_pack(int in, int out, in
error("remote ref '%s' is not a strict "
"subset of local ref '%s'.", ref->name,
ref->peer_ref->name);
+ ret = -2;
continue;
}
}
memcpy(ref->new_sha1, ref->peer_ref->new_sha1, 20);
if (is_zero_sha1(ref->new_sha1)) {
error("cannot happen anymore");
+ ret = -3;
continue;
}
new_refs++;
@@ -267,7 +271,7 @@ static int send_pack(int in, int out, in
if (new_refs)
pack_objects(out, remote_refs);
close(out);
- return 0;
+ return ret;
}
^ permalink raw reply related
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