* [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Gerrit Pape @ 2007-10-26 14:15 UTC (permalink / raw)
To: git, Junio C Hamano
When saving patches to a maildir with e.g. mutt, the files are put into
the new/ subdirectory of the maildir, not cur/. This makes git-am state
"Nothing to do.". This patch lets git-mailsplit fallback to new/ if the
cur/ subdirectory is empty.
This was reported by Joey Hess through
http://bugs.debian.org/447396
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
Documentation/git-am.txt | 3 ++-
builtin-mailsplit.c | 5 +++++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index e4a6b3a..49f79f6 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -26,7 +26,8 @@ OPTIONS
<mbox>|<Maildir>...::
The list of mailbox files to read patches from. If you do not
supply this argument, reads from the standard input. If you supply
- directories, they'll be treated as Maildirs.
+ directories, they'll be treated as Maildirs, which should contain
+ the patches either in the cur/ subdirectory, or in new/.
-s, --signoff::
Add `Signed-off-by:` line to the commit message, using
diff --git a/builtin-mailsplit.c b/builtin-mailsplit.c
index 43fc373..eaf3cbe 100644
--- a/builtin-mailsplit.c
+++ b/builtin-mailsplit.c
@@ -131,6 +131,11 @@ static int split_maildir(const char *maildir, const char *dir,
snprintf(curdir, sizeof(curdir), "%s/cur", maildir);
if (populate_maildir_list(&list, curdir) < 0)
goto out;
+ if (list.nr == 0) {
+ snprintf(curdir, sizeof(curdir), "%s/new", maildir);
+ if (populate_maildir_list(&list, curdir) < 0)
+ goto out;
+ }
for (i = 0; i < list.nr; i++) {
FILE *f;
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Jeff King @ 2007-10-26 11:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git, gitster
In-Reply-To: <20071026114331.GA2693@coredump.intra.peff.net>
On Fri, Oct 26, 2007 at 07:43:32AM -0400, Jeff King wrote:
> Reasonable, although perhaps it should mention what I suspect might be a
> common workflow for this feature: CVS emulation. I.e., there is a
> central repo, which is the only thing considered "published". Developers
> make commits in their local repo, and then rebase their changes onto the
> HEAD before pushing. The only difference from CVS is that you don't
> actually get to commit in CVS, you have to do the rebase with your
> working tree. :)
Actually, I think I've just restated Junio's comment somewhat, so the
change you made in response to him is an improvement. Sorry for the
noise.
-Peff
^ permalink raw reply
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Jeff King @ 2007-10-26 11:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git, gitster
In-Reply-To: <Pine.LNX.4.64.0710260007450.4362@racer.site>
On Fri, Oct 26, 2007 at 12:10:08AM +0100, Johannes Schindelin wrote:
> Fair enough.
>
> How about this in the man page:
>
> \--rebase::
> Instead of a merge, perform a rebase after fetching.
> *NOTE:* Never do this on branches you plan to publish! This
> command will _destroy_ history, and is thus only suitable for
> topic branches to be submitted to another committer.
Reasonable, although perhaps it should mention what I suspect might be a
common workflow for this feature: CVS emulation. I.e., there is a
central repo, which is the only thing considered "published". Developers
make commits in their local repo, and then rebase their changes onto the
HEAD before pushing. The only difference from CVS is that you don't
actually get to commit in CVS, you have to do the rebase with your
working tree. :)
I'm imagining a "pull.rebase = 1" config option, and handing this out to
developers accustomed to CVS.
-Peff
^ permalink raw reply
* [PATCH] hooks-pre-commit: use \t, rather than a literal TAB in regexp
From: Jim Meyering @ 2007-10-26 10:48 UTC (permalink / raw)
To: git list
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
templates/hooks--pre-commit | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 18b8730..a19279b 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -58,7 +58,7 @@ perl -e '
if (/\s$/) {
bad_line("trailing whitespace", $_);
}
- if (/^\s* /) {
+ if (/^\s* \t/) {
bad_line("indent SP followed by a TAB", $_);
}
if (/^(?:[<>=]){7}/) {
--
1.5.3.4.383.gd90a7
^ permalink raw reply related
* stg branch --create test v2.6.24-rc1 doesn't work
From: Aneesh Kumar @ 2007-10-26 10:42 UTC (permalink / raw)
To: catalin.marinas, kha, Git Mailing List
$ stg branch --create test v2.6.24-rc1
Checking for changes in the working directory ... done
Don't know how to determine parent branch from "v2.6.24-rc1"
Branch "test" created
[test@linux-review-ext]$ git log
Throws an error/warning in the above command.
Also import then gives
[test@linux-review-ext]$ stg import
/home/opensource/patches/ext4-patch-queue/ext4_mballoc_freespace_accounting_fix.patch
Checking for changes in the working directory ... done
fatal: cebdeed27b068dcc3e7c311d7ec0d9c33b5138c2 is not a valid 'commit' object
stg import: git-commit-tree failed with code 128
^ permalink raw reply
* Re: [PATCH] Make rebase smarter
From: Johannes Schindelin @ 2007-10-26 9:57 UTC (permalink / raw)
To: Steven Walter; +Cc: git, federico
In-Reply-To: <1193373682-3608-1-git-send-email-stevenrwalter@gmail.com>
Hi,
On Fri, 26 Oct 2007, Steven Walter wrote:
> It is a common workflow to run "git fetch; git rebase origin/<foo>"
> Where foo is the remote tracking branch. git-rebase should default to
> using the remote tracking branch if no other ref is given.
This is potentially dangerous, as git-rebase does not use a detached HEAD
to replay the operations. Therefore you cannot go back easily when
you started "git rebase" just to see its usage, and instead it did
unwanted things.
So I really think that you need a patch before this one, so that
git reset --hard <branchname>@{1}
goes back to the pre-merge state after an inadvertent rebase. (Note: this
behaviour is already implemented in rebase -i, because detached HEAD was
available at that time, as opposed to the time when git-rebase was
written.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Johannes Schindelin @ 2007-10-26 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v3avy21il.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 25 Oct 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 25 Oct 2007, Linus Torvalds wrote:
> >
> >> On Thu, 25 Oct 2007, Johannes Schindelin wrote:
> >> >
> >> > This behavior is more desirable than fetch + pull when a topic
> >> > branch is ready to be submitted.
> >>
> >> I'd like there to be some *big*warning* about how this destroys
> >> history and how you must not do this if you expose your history
> >> anywhere else.
> >>
> >> I think it's a perfectly fine history, but if you have already pushed
> >> out your history somewhere else, you're now really screwed. In ways
> >> that a *real* merge will never screw you.
> >>
> >> So the "--rebase" option really is only good for the lowest-level
> >> developers. And that should be documented.
> >
> > Fair enough.
> >
> > How about this in the man page:
> >
> > \--rebase::
> > Instead of a merge, perform a rebase after fetching.
> > *NOTE:* Never do this on branches you plan to publish! This
> > command will _destroy_ history, and is thus only suitable for
> > topic branches to be submitted to another committer.
>
> Nits.
>
> (1) This "operation" will "rewrite" history.
Okay.
> (2) This is not suitable for people who publish their trees and
> let others fetch and work off of them.
>
> Rebase is fine for e-mail submitting contributors as your
> description above suggests, but as your proposed commit log
> message said, it is also perfectly appropriate if your
> interaction with the outside world is "fetch + rebase +
> push". You are not limited to "submitted to another
> committer".
Well, originally I did not want to document it at all. But I already
heard the complaints about that in my inner ear. So I documented it,
sparsely, in the hope that those who do not know the implications will not
dare to use it. After Linus' complaint, I tried to make this shooing away
more explicit.
I do not want to go into _that_ many details here, since the place to look
for it is git-rebase.txt. Probably I should have done that in the first
place.
So how about this instead:
\--rebase::
Instead of a merge, perform a rebase after fetching.
*NOTE:* This is a potentially _dangerous_ mode of operation.
It rewrites history, which does not bode well when you
published that history already. Do _not_ use this option
unless you have read gitlink:git-rebase[1] carefully.
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued
From: David Kastrup @ 2007-10-26 9:17 UTC (permalink / raw)
To: git
In-Reply-To: <20071025202744.GE31888@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Thu, Oct 25, 2007 at 10:19:58PM +0200, Andreas Ericsson wrote:
>> Federico Mena Quintero wrote:
>>> On Thu, 2007-10-25 at 12:38 -0400, J. Bruce Fields wrote:
>>>> Also, there's
>>>> the restriction that we'd like to keep it looking good in plain ascii,
>>>> so diagrams have to be done in ascii somehow.
>>> Hmm, what's the rationale for this? I'd assume that most people read
>>> the user's manual as a web page (or as bedside reading if they can print
>>> a PDF thereof), where diagrams can be pretty.
>>
>> man pages.
>
> I think he's talking about Documentation/user-manual.txt, which
> isn't turned into man pages. (Might be nice if it could be though,
> I suppose.)
I think it would be nicer if the man pages could be turned into an
appendix in the user manual.
I had no success in persuading the toolchain to do that, however.
_WAY_ above my head to figure out the interaction of Docbook, Asciidoc
and similar in order to achieve that effect.
--
David Kastrup
^ permalink raw reply
* [PATCH] git-fetch: print informative messages to stdout, not stderr
From: Gerrit Pape @ 2007-10-26 8:53 UTC (permalink / raw)
To: git, Junio C Hamano
git-fetch writes informations about storing tags and the like to stderr,
which should only be used for errors. This patch changes it to use
stdout instead.
This was noticed by Joey Hess and asked for through
http://bugs.debian.org/447395
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
builtin-fetch.c | 32 ++++++++++++--------------------
1 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index b9d2b0c..2dbfcb6 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -125,7 +125,7 @@ static struct ref *get_ref_map(struct transport *transport,
static void show_new(enum object_type type, unsigned char *sha1_new)
{
- fprintf(stderr, " %s: %s\n", typename(type),
+ printf(" %s: %s\n", typename(type),
find_unique_abbrev(sha1_new, DEFAULT_ABBREV));
}
@@ -165,7 +165,7 @@ static int update_local_ref(struct ref *ref,
if (!*ref->name) {
/* Not storing */
if (verbose) {
- fprintf(stderr, "* fetched %s\n", note);
+ printf("* fetched %s\n", note);
show_new(type, ref->new_sha1);
}
return 0;
@@ -173,8 +173,7 @@ static int update_local_ref(struct ref *ref,
if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
if (verbose) {
- fprintf(stderr, "* %s: same as %s\n",
- ref->name, note);
+ printf("* %s: same as %s\n", ref->name, note);
show_new(type, ref->new_sha1);
}
return 0;
@@ -196,8 +195,7 @@ static int update_local_ref(struct ref *ref,
if (!is_null_sha1(ref->old_sha1) &&
!prefixcmp(ref->name, "refs/tags/")) {
- fprintf(stderr, "* %s: updating with %s\n",
- ref->name, note);
+ printf("* %s: updating with %s\n", ref->name, note);
show_new(type, ref->new_sha1);
return s_update_ref("updating tag", ref, 0);
}
@@ -210,8 +208,7 @@ static int update_local_ref(struct ref *ref,
msg = "storing tag";
else
msg = "storing head";
- fprintf(stderr, "* %s: storing %s\n",
- ref->name, note);
+ printf("* %s: storing %s\n", ref->name, note);
show_new(type, ref->new_sha1);
return s_update_ref(msg, ref, 0);
}
@@ -220,23 +217,19 @@ static int update_local_ref(struct ref *ref,
strcpy(newh, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));
if (in_merge_bases(current, &updated, 1)) {
- fprintf(stderr, "* %s: fast forward to %s\n",
- ref->name, note);
- fprintf(stderr, " old..new: %s..%s\n", oldh, newh);
+ printf("* %s: fast forward to %s\n", ref->name, note);
+ printf(" old..new: %s..%s\n", oldh, newh);
return s_update_ref("fast forward", ref, 1);
}
if (!force && !ref->force) {
- fprintf(stderr,
- "* %s: not updating to non-fast forward %s\n",
+ printf("* %s: not updating to non-fast forward %s\n",
ref->name, note);
- fprintf(stderr,
- " old...new: %s...%s\n", oldh, newh);
+ printf(" old...new: %s...%s\n", oldh, newh);
return 1;
}
- fprintf(stderr,
- "* %s: forcing update to non-fast forward %s\n",
+ printf("* %s: forcing update to non-fast forward %s\n",
ref->name, note);
- fprintf(stderr, " old...new: %s...%s\n", oldh, newh);
+ printf(" old...new: %s...%s\n", oldh, newh);
return s_update_ref("forced-update", ref, 1);
}
@@ -368,8 +361,7 @@ static struct ref *find_non_local_tags(struct transport *transport,
if (!path_list_has_path(&existing_refs, ref_name) &&
!path_list_has_path(&new_refs, ref_name) &&
lookup_object(ref->old_sha1)) {
- fprintf(stderr, "Auto-following %s\n",
- ref_name);
+ printf("Auto-following %s\n", ref_name);
path_list_insert(ref_name, &new_refs);
--
1.5.3.4
^ permalink raw reply related
* Re: How to run git-gui always in English?
From: Peter Karlsson @ 2007-10-26 8:00 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Shawn O. Pearce, Git Mailing List
In-Reply-To: <CCAD0DE0-65D4-4FEC-B02F-658010FECD04@zib.de>
Steffen Prohaska:
> There are a lot of efforts going on to localize git-gui, including
> technical terms like "push". Personally I don't understand what this
> should be useful for. The command is called "git push"s. So, why should it
> be named differently in the gui.
Not that I agree that "push" is a technical word, but perhaps you have a
point. Why should there be such words in the GUI to start with? It's a GUI,
trying to abstract away the command line. Why not have a button "Send" or a
menu entry "Send changes to server", mimicing the "git push" command line
option? Using command line names or showing protocol data directly in a
user-oriented GUI is most often a bad idea.
Or perhaps what we need is an actual translation from "gitish" to English,
which would have
msgid "Push"
msgstr "Send changes to server"
?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [PATCH] Fix regression in fast-import.c due to strbufs.
From: Pierre Habouzit @ 2007-10-26 7:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: cpettitt, Git Mailing List
In-Reply-To: <20071026065301.GL14735@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]
Without this strbuf_release, it yields a double free later, the command is
in fact stashed, and this is not a memory leak.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
On Fri, Oct 26, 2007 at 06:53:01AM +0000, Shawn O. Pearce wrote:
> cpettitt <cpettitt@gmail.com> wrote:
> > I'm seeing the following errors when I run git-fast-import (on Intel
> > OSX) with some data from a git-p4 import:
> ....
> > I believe these errors started showing up in commit
> > b449f4cfc972929b638b90d375b8960c37790618. I did a bisect on
> > fast-import.c and this was the first commit for that file that
> > exhibits this bug with the input.
> >
> > I thought I would check with the list to see if this is a known issue
> > before I spend time trying to dig into it.
>
> It is a known issue. Someone else has reported the same thing,
> and bisecting pointed at the same commit. But they weren't able
> to supply their input data for debugging by Pierre or myself as it
> was a private project and they haven't had a chance to attempt to
> debug it on their own.
>
> Any light you can shed on the problem would be most appreciated.
Wait, I believe I found the problem thanks to the "free" that fails.
Could you please try that patch ? looking at the diff again, and
knowing the issue is with an rc->buf (which are old command_buf
stashed buffers) it looks like I migrated cmd_data improperly.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
fast-import.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 6f888f6..f93d7d6 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1616,6 +1616,7 @@ static void cmd_data(struct strbuf *sb)
char *term = xstrdup(command_buf.buf + 5 + 2);
size_t term_len = command_buf.len - 5 - 2;
+ strbuf_detach(&command_buf, NULL);
for (;;) {
if (strbuf_getline(&command_buf, stdin, '\n') == EOF)
die("EOF in data (terminator '%s' not found)", term);
--
1.5.3.4.1358.gfae55-dirty
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-26 7:53 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Junio C Hamano, Theodore Tso, Johannes Schindelin, Peter Baumann,
J. Bruce Fields, Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <D38E4717-CF67-4897-983E-2B45CA217C11@zib.de>
Steffen Prohaska wrote:
>
> On Oct 25, 2007, at 10:18 PM, Andreas Ericsson wrote:
>
>> Junio C Hamano wrote:
>>> Andreas Ericsson <ae@op5.se> writes:
>>
>>> With that in mind, how about making "git checkout foo", after
>>> foo is set up thusly, to show:
>>> git log --pretty=oneline --left-right origin/pu...foo
>>> if (and only if) they have diverged? Then you can deal with the
>>> staleness of local tracking fork 'foo' in any way you want.
>>> You could even go one step further and make this "checkout foo",
>>> in addition to or instead of showing the above left-right log,
>>> - automatically run "git merge origin/pu" if it is a
>>> fast-forward, and say it did _not_ run that merge if it is
>>> not a fast-forward;
>>> - automatically run "git merge origin/pu" always, even if it is
>>> not a fast-forward;
>>> - automatically run "git rebase origin/pu" always;
>>> Would that make your life easier?
>>
>> That it would, except the confusion would then be that it's automatically
>> rebased for the branches one currently hasn't got checked out while
>> pulling,
>> and the branch that *is* checked out gets merged (crazy, yes), so those
>> who prefer the rebase would get what they want by doing something
>> completely
>> bonkers, such as:
>>
>> git checkout -b just-gonna-pull HEAD^
>> git pull
>> git checkout whatever-other-branch-they-were-on
>>
>> (yes, "aggresively ignorant", I think Ted said in an earlier mail)
>>
>> It'd probably be better to go with Dscho's suggestion, although I'm
>> not quite
>> sure what that was any more. It involved automagical rebasing on fetch
>> or pull
>> though.
>
> git pull's automagic and the automatic behaviour of git checkout
> proposed by Junio should always do the same. git pull should
> be changed to act a if your three commands were fused into it
> (but obviously implemented differently).
>
I think it would be better to implement it as a different command that
would do all those weird and tedious dwim things that suit a particular
kind of developer, but only so long as those operations succeed without
conflicts.
So for example the flow could go something like this;
---
read_branch_merge_config();
git fetch
if prefetch(local == remote_tracking)
set ref local to match ref remote_tracking;
else if (--safe-rebase)
try_rebase local onto remote_tracking;
---
It's such a common operation that I really do think it's worth
having support for it. Perhaps with a "--try-rebase" option to
git-pull.
If we then add a a "--push-after-pull" (to work on the current
branch only) we have the "git sync" alias readily available to
accommodate the average reluctant git user, and I'm sure gui
hackers could do wonders with it, especially on windows, where
people seem accustomed to a lot of things happening when clicking
a single button.
> I think teaching "git checkout" a dwim mode is quite
> interesting. The required work to bring a local branch
> up-to-date with a remote branch is deferred until really needed.
> An then "git checkout" does the right thing. A lot of automagic
> but definitely intriguing.
>
Yup, and it can be done with a post-checkout hook (which I notice
there are no examples for, so I've added that to my ever-growing
todo).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Make rebase smarter
From: Andreas Ericsson @ 2007-10-26 7:42 UTC (permalink / raw)
To: Steven Walter; +Cc: git, federico
In-Reply-To: <1193373682-3608-1-git-send-email-stevenrwalter@gmail.com>
Steven Walter wrote:
> It is a common workflow to run "git fetch; git rebase origin/<foo>" Where
> foo is the remote tracking branch. git-rebase should default to using
> the remote tracking branch if no other ref is given.
>
I like it. :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Karl Hasselström @ 2007-10-26 7:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Randal L. Schwartz, git
In-Reply-To: <alpine.LFD.0.9999.0710251344220.22100@xanadu.home>
On 2007-10-25 13:46:04 -0400, Nicolas Pitre wrote:
> On Thu, 25 Oct 2007, Karl Hasselström wrote:
>
> > On 2007-10-25 07:32:36 -0700, Randal L. Schwartz wrote:
> >
> > > And when are we gonna get "fast forward only" for git-merge?
> >
> > I'd like that too. For cases when I know I don't have to do a
> > merge, and want git to yell at me if I'm mistaken. For example, in
> > a repository that tracks an upstream so I can build the latest
> > version, but where I don't normally do any development.
>
> Isn't that called a remote branch that gets updated with "git
> fetch'?
Sure, I could use a detached HEAD instead of a local branch. However,
that'll still not warn me that merging in another branch won't be a
fast-forward.
> You can even trick Git into not using the refs/remotes/ namespace
> for them if you wish.
I'm not sure what'll happen if git fetch tries to update a branch that
I've made local changes to, but I don't imagine it's anything
productive. If not forced it'll fail, and if forced it'll lose my
local commits. The former might actually be sort of what I want (git
complains when I have local commits), but I'm rather fond of the
refs/remotes/ stuff, so this solution sounds like a hack to me. What I
really want is an "extra careful" merge that is guaranteed to do
nothing but a fast-forward if it succeeds.
As is, it's a two-line shell script, though, so it isn't that
important.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: stgit restrictions on patch names
From: Karl Hasselström @ 2007-10-26 7:29 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, GIT list
In-Reply-To: <20071025194808.GV26436@nan92-1-81-57-214-146.fbx.proxad.net>
On 2007-10-25 21:48:08 +0200, Yann Dirson wrote:
> Do we want to:
>
> - implement a mechanism for checking beforehand that the operation
> will not fail? Seems awkward to duplicate checks already found
> elsewhere.
Duplication is bad. Calling the same verification function more times
than necessary is still bad, but maybe not so bad that it wouldn't be
OK.
> - wait for proper transactions so we can rollback on error ?
Yes, this is what we should aim for. I'm working on code that'll
eventually give us this if it pans out.
> - on clone error, delete the newly-created stack ? I'd vote for this
> one, until the previous one gets done.
Seems reasonable.
> => is there any particular reason why we would refuse "+" ?
Not that I can think of at the moment, except maybe future-proofing.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] fast-import: Add ability to copy a path from an arbitrary commit
From: Shawn O. Pearce @ 2007-10-26 7:01 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <20071020155749.29528.9258.julian@quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> wrote:
> This adds the ability to copy a path from an arbitrary commit instead
> of just from the current commit. This is done using the 'K' version
> of the filecopy sub-command.
So the reason I didn't apply this earlier when I was playing the role
of "interim maintainer" was four fold:
- There's no test cases for this new 'K' command. Everything else
in fast-import has at least one test case for it, this should
as well.
- There's a huge memory leak every time you use the 'K' command.
See below in the code for where.
- The documentation doesn't talk about the special "/" source path.
- I was really busy and just forgot to reply to this email.
Other than that I think this is good. I've just been too busy
to do it myself, and I'm glad that you took it upon yourself to
remedy that.
> diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
> index d511967..89aefea 100644
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -534,6 +534,17 @@ location has been copied to the destination any future commands
> applied to the source location will not impact the destination of
> the copy.
>
> +It is also possible to copy a file or directory from a commit other
> +than the current one.
> +
> +....
> + 'K' <dataref> SP <path> SP <path> LF
> +....
> +
> +where `<dataref>` is a reference (see `filemodify` above) to the
> +commit that the first (source) `<path>` is located in, the second
> +`<path>` is the destination.
> +
This should talk about the special case of the first (src) <path>
being able to be "/" to copy the entire tree. If I follow your
implementation right a src_path of "/" also causes the destination
path to be ignored entirely. Which means you cannot copy another
branch into a subdirectory of this branch (aka one direction of
the subtree merge strategy).
> diff --git a/fast-import.c b/fast-import.c
> index e9c80be..9537c63 100644
> --- a/fast-import.c
> +++ b/fast-import.c
...
> +static void copy_from_commit(
> + unsigned char *src_commit, const char *src_path,
> + struct branch *dest_br, const char *dest_path)
...
> + load_tree(&src_br.branch_tree);
This is a huge memory leak. You never unload this tree and return
its data onto the freelists so we'll leak everything that wasn't
moved into the destination tree.
--
Shawn.
^ permalink raw reply
* Re: git-fast-import segfaults
From: Shawn O. Pearce @ 2007-10-26 6:53 UTC (permalink / raw)
To: cpettitt, Pierre Habouzit; +Cc: Git Mailing List
In-Reply-To: <de47e4420710251729j5858481cg69146385a2ed798d@mail.gmail.com>
cpettitt <cpettitt@gmail.com> wrote:
> I'm seeing the following errors when I run git-fast-import (on Intel
> OSX) with some data from a git-p4 import:
...
> I believe these errors started showing up in commit
> b449f4cfc972929b638b90d375b8960c37790618. I did a bisect on
> fast-import.c and this was the first commit for that file that
> exhibits this bug with the input.
>
> I thought I would check with the list to see if this is a known issue
> before I spend time trying to dig into it.
It is a known issue. Someone else has reported the same thing,
and bisecting pointed at the same commit. But they weren't able
to supply their input data for debugging by Pierre or myself as it
was a private project and they haven't had a chance to attempt to
debug it on their own.
Any light you can shed on the problem would be most appreciated.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Bisect run: "skip" current commit if script exit code is 125.
From: Benoit SIGOURE @ 2007-10-26 6:25 UTC (permalink / raw)
To: Christian Couder; +Cc: git list
In-Reply-To: <20071026053937.2831a89b.chriscool@tuxfamily.org>
[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]
On Oct 26, 2007, at 5:39 AM, Christian Couder wrote:
> This is incompatible with previous versions because an exit code
> of 125 used to mark current commit as "bad". But hopefully this exit
> code is not much used by test scripts or other programs. (126 and 127
> are used by bash.)
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> Documentation/git-bisect.txt | 8 ++++++--
> git-bisect.sh | 11 ++++++++++-
> t/t6030-bisect-porcelain.sh | 40 +++++++++++++++++++++++++++++++
> +++++++++
> 3 files changed, 56 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-
> bisect.txt
> index 785f381..14b7a95 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -183,13 +183,17 @@ $ git bisect run my_script
>
> Note that the "run" script (`my_script` in the above example) should
> exit with code 0 in case the current source code is good and with a
> -code between 1 and 127 (included) in case the current source code is
> -bad.
> +code between 1 and 127 (included), except 125 that is special, in
> case
> +the current source code is bad.
>
> Any other exit code will abort the automatic bisect process. (A
> program that does "exit(-1)" leaves $? = 255, see exit(3) manual
> page,
> the value is chopped with "& 0377".)
>
> +The special exit code 125 should be used when the current source code
> +cannot be tested. If the "run" script exits with this code, the
> current
> +revision will be "skip"ped, see `git bisect skip` above.
> +
> You may often find that during bisect you want to have near-constant
> tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
> "revision that does not have this commit needs this patch applied to
Since exit 77 is already used by automake to mean "skip", wouldn't it
be better to do the same thing here?
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Steffen Prohaska @ 2007-10-26 6:18 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Junio C Hamano, Theodore Tso, Johannes Schindelin, Peter Baumann,
J. Bruce Fields, Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <4720FA00.1050805@op5.se>
On Oct 25, 2007, at 10:18 PM, Andreas Ericsson wrote:
> Junio C Hamano wrote:
>> Andreas Ericsson <ae@op5.se> writes:
>
>> With that in mind, how about making "git checkout foo", after
>> foo is set up thusly, to show:
>> git log --pretty=oneline --left-right origin/pu...foo
>> if (and only if) they have diverged? Then you can deal with the
>> staleness of local tracking fork 'foo' in any way you want.
>> You could even go one step further and make this "checkout foo",
>> in addition to or instead of showing the above left-right log,
>> - automatically run "git merge origin/pu" if it is a
>> fast-forward, and say it did _not_ run that merge if it is
>> not a fast-forward;
>> - automatically run "git merge origin/pu" always, even if it is
>> not a fast-forward;
>> - automatically run "git rebase origin/pu" always;
>> Would that make your life easier?
>
> That it would, except the confusion would then be that it's
> automatically
> rebased for the branches one currently hasn't got checked out while
> pulling,
> and the branch that *is* checked out gets merged (crazy, yes), so
> those
> who prefer the rebase would get what they want by doing something
> completely
> bonkers, such as:
>
> git checkout -b just-gonna-pull HEAD^
> git pull
> git checkout whatever-other-branch-they-were-on
>
> (yes, "aggresively ignorant", I think Ted said in an earlier mail)
>
> It'd probably be better to go with Dscho's suggestion, although I'm
> not quite
> sure what that was any more. It involved automagical rebasing on
> fetch or pull
> though.
git pull's automagic and the automatic behaviour of git checkout
proposed by Junio should always do the same. git pull should
be changed to act a if your three commands were fused into it
(but obviously implemented differently).
I think teaching "git checkout" a dwim mode is quite
interesting. The required work to bring a local branch
up-to-date with a remote branch is deferred until really needed.
An then "git checkout" does the right thing. A lot of automagic
but definitely intriguing.
Steffen
^ permalink raw reply
* [PATCH] Make rebase smarter
From: Steven Walter @ 2007-10-26 4:41 UTC (permalink / raw)
To: git, federico; +Cc: Steven Walter
In-Reply-To: <1193328386.4522.352.camel@cacharro.xalalinux.org>
It is a common workflow to run "git fetch; git rebase origin/<foo>" Where
foo is the remote tracking branch. git-rebase should default to using
the remote tracking branch if no other ref is given.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
---
git-rebase.sh | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 058fcac..1a2b51b 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -261,8 +261,19 @@ case "$diff" in
;;
esac
-# The upstream head must be given. Make sure it is valid.
upstream_name="$1"
+# Default to the remote tracking branch if we have one
+if [ -z "$upstream_name" ]
+then
+ curr_branch=$(git symbolic-ref -q HEAD)
+ curr_branch=${curr_branch//refs\/heads\//}
+ merge=$(git config branch.$curr_branch.merge)
+ remote=$(git config branch.$curr_branch.remote)
+ fetch=$(git config remote.$remote.fetch)
+
+ expanded=$(git fetch--tool expand-refs-wildcard "0000000000000000000000000000000000000000 $merge" "$remote" "$fetch")
+ upstream_name=${expanded/#*:/}
+fi
upstream=`git rev-parse --verify "${upstream_name}^0"` ||
die "invalid upstream $upstream_name"
--
1.5.3.4.1.gb4ad62-dirty
^ permalink raw reply related
* [PATCH] Test suite: reset TERM to its previous value after testing.
From: Christian Couder @ 2007-10-26 4:13 UTC (permalink / raw)
To: Junio Hamano, Pierre Habouzit; +Cc: git
Using konsole, I get no colored output at the end of "t7005-editor.sh"
without this patch.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t7005-editor.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
This patch should be applied on top of Pierre Habouzit's
"Add some fancy colors in the test library when terminal supports it."
patch.
diff --git a/t/t7005-editor.sh b/t/t7005-editor.sh
index 28643b0..01cc0c0 100755
--- a/t/t7005-editor.sh
+++ b/t/t7005-editor.sh
@@ -4,6 +4,8 @@ test_description='GIT_EDITOR, core.editor, and stuff'
. ./test-lib.sh
+OLD_TERM="$TERM"
+
for i in GIT_EDITOR core_editor EDITOR VISUAL vi
do
cat >e-$i.sh <<-EOF
@@ -88,4 +90,6 @@ do
'
done
+TERM="$OLD_TERM"
+
test_done
--
1.5.3.4.1494.g253d
^ permalink raw reply related
* [PATCH] Bisect run: "skip" current commit if script exit code is 125.
From: Christian Couder @ 2007-10-26 3:39 UTC (permalink / raw)
To: Junio Hamano, Shawn O. Pearce, Johannes Schindelin; +Cc: git
This is incompatible with previous versions because an exit code
of 125 used to mark current commit as "bad". But hopefully this exit
code is not much used by test scripts or other programs. (126 and 127
are used by bash.)
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-bisect.txt | 8 ++++++--
git-bisect.sh | 11 ++++++++++-
t/t6030-bisect-porcelain.sh | 40 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 785f381..14b7a95 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -183,13 +183,17 @@ $ git bisect run my_script
Note that the "run" script (`my_script` in the above example) should
exit with code 0 in case the current source code is good and with a
-code between 1 and 127 (included) in case the current source code is
-bad.
+code between 1 and 127 (included), except 125 that is special, in case
+the current source code is bad.
Any other exit code will abort the automatic bisect process. (A
program that does "exit(-1)" leaves $? = 255, see exit(3) manual page,
the value is chopped with "& 0377".)
+The special exit code 125 should be used when the current source code
+cannot be tested. If the "run" script exits with this code, the current
+revision will be "skip"ped, see `git bisect skip` above.
+
You may often find that during bisect you want to have near-constant
tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
"revision that does not have this commit needs this patch applied to
diff --git a/git-bisect.sh b/git-bisect.sh
index f8d0099..180c6c2 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -392,7 +392,10 @@ bisect_run () {
fi
# Find current state depending on run success or failure.
- if [ $res -gt 0 ]; then
+ # A special exit code of 125 means cannot test.
+ if [ $res -eq 125 ]; then
+ state='skip'
+ elif [ $res -gt 0 ]; then
state='bad'
else
state='good'
@@ -404,6 +407,12 @@ bisect_run () {
cat "$GIT_DIR/BISECT_RUN"
+ if grep "first bad commit could be any of" "$GIT_DIR/BISECT_RUN" \
+ > /dev/null; then
+ echo >&2 "bisect run cannot continue any more"
+ exit $res
+ fi
+
if [ $res -ne 0 ]; then
echo >&2 "bisect run failed:"
echo >&2 "'bisect_state $state' exited with error code $res"
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 16d0c4a..53956c0 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -177,6 +177,46 @@ test_expect_success 'bisect skip and bisect replay' '
git bisect reset
'
+HASH6=
+test_expect_success 'bisect run & skip: cannot tell between 2' '
+ add_line_into_file "6: Yet a line." hello &&
+ HASH6=$(git rev-parse --verify HEAD) &&
+ echo "#"\!"/bin/sh" > test_script.sh &&
+ echo "tail -1 hello | grep Ciao > /dev/null && exit 125" >> test_script.sh &&
+ echo "grep line hello > /dev/null" >> test_script.sh &&
+ echo "test \$? -ne 0" >> test_script.sh &&
+ chmod +x test_script.sh &&
+ git bisect start $HASH6 $HASH1 &&
+ if git bisect run ./test_script.sh > my_bisect_log.txt
+ then
+ echo Oops, should have failed.
+ false
+ else
+ test $? -eq 2 &&
+ grep "first bad commit could be any of" my_bisect_log.txt &&
+ ! grep $HASH3 my_bisect_log.txt &&
+ ! grep $HASH6 my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ grep $HASH5 my_bisect_log.txt
+ fi
+'
+
+HASH7=
+test_expect_success 'bisect run & skip: find first bad' '
+ git bisect reset &&
+ add_line_into_file "7: Should be the last line." hello &&
+ HASH7=$(git rev-parse --verify HEAD) &&
+ echo "#"\!"/bin/sh" > test_script.sh &&
+ echo "tail -1 hello | grep Ciao > /dev/null && exit 125" >> test_script.sh &&
+ echo "tail -1 hello | grep day > /dev/null && exit 125" >> test_script.sh &&
+ echo "grep Yet hello > /dev/null" >> test_script.sh &&
+ echo "test \$? -ne 0" >> test_script.sh &&
+ chmod +x test_script.sh &&
+ git bisect start $HASH7 $HASH1 &&
+ git bisect run ./test_script.sh > my_bisect_log.txt &&
+ grep "$HASH6 is first bad commit" my_bisect_log.txt
+'
+
#
#
test_done
--
1.5.3.4.1494.g253d
^ permalink raw reply related
* Re: Git and Windows
From: Bo Yang @ 2007-10-26 2:40 UTC (permalink / raw)
Cc: git
In-Reply-To: <Pine.LNX.4.64.0710251517350.25221@racer.site>
Johannes Schindelin :
> Hi,
>
> On Thu, 25 Oct 2007, Bo Yang wrote:
>
>
>> I am a new comer to this list but I have used git for two week
>> development control. I think it is a very cool tool, the only flaw is
>> that I have not found Windows version of it. Does git just aim at Linux
>> kernel development? Is there any plan or in the future to migrate it to
>> windows?
>>
>
> Funny. The first three hits I get from Google are
>
> Wikipedia,
> GitWiki and
> msysgit
>
> The first two pointing to the third. And happily enough, there is a
> Download page at the third site. Oh, and it has a description what its
> affiliation with git is.
>
So, if I want to get invovled with the Windows version git development,
I should download the Gitme, right?
Regards!
Bo
^ permalink raw reply
* git-fast-import segfaults
From: cpettitt @ 2007-10-26 0:29 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <de47e4420710251726nb45a19fk15b3105b735a74f8@mail.gmail.com>
I'm seeing the following errors when I run git-fast-import (on Intel
OSX) with some data from a git-p4 import:
[cpettitt@gish scratch2]$ rm -rf .git; git init; git-fast-import < ~/writer.out
Initialized empty Git repository in .git/
git-fast-import(23021) malloc: *** error for object 0x500e50: double free
git-fast-import(23021) malloc: *** set a breakpoint in szone_error to debug
git-fast-import(23021) malloc: *** Deallocation of a pointer not
malloced: 0x501a80; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
git-fast-import(23021) malloc: *** error for object 0x5020a0: double free
git-fast-import(23021) malloc: *** set a breakpoint in szone_error to debug
git-fast-import(23021) malloc: *** Deallocation of a pointer not
malloced: 0x5007e0; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
git-fast-import(23021) malloc: *** Deallocation of a pointer not
malloced: 0x5006e0; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
git-fast-import(23021) malloc: *** Deallocation of a pointer not
malloced: 0x501e10; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
git-fast-import(23021) malloc: *** Deallocation of a pointer not
malloced: 0x502190; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
git-fast-import(23021) malloc: *** error for object 0x500280: double free
git-fast-import(23021) malloc: *** set a breakpoint in szone_error to debug
git-fast-import(23021) malloc: *** Deallocation of a pointer not
malloced: 0x5009c0; This could be a double free(), or free() called
with the middle of an allocated block; Try setting environment
variable MallocHelp to see tools to help debug
git-fast-import(23021) malloc: *** error for object 0x500b00:
incorrect checksum for freed object - object was probably modified
after being freed, break at szone_error to debug
git-fast-import(23021) malloc: *** set a breakpoint in szone_error to debug
Segmentation fault
I start getting free errors at fast-import.c:1577:
rc = rc_free;
if (rc)
rc_free = rc->next;
else {
rc = cmd_hist.next;
cmd_hist.next = rc->next;
cmd_hist.next->prev = &cmd_hist;
free(rc->buf); // <-- error is emitted
in free here
}
I believe these errors started showing up in commit
b449f4cfc972929b638b90d375b8960c37790618. I did a bisect on
fast-import.c and this was the first commit for that file that
exhibits this bug with the input.
I thought I would check with the list to see if this is a known issue
before I spend time trying to dig into it.
^ permalink raw reply
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Junio C Hamano @ 2007-10-25 23:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git, gitster
In-Reply-To: <Pine.LNX.4.64.0710260007450.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 25 Oct 2007, Linus Torvalds wrote:
>
>> On Thu, 25 Oct 2007, Johannes Schindelin wrote:
>> >
>> > This behavior is more desirable than fetch + pull when a topic branch
>> > is ready to be submitted.
>>
>> I'd like there to be some *big*warning* about how this destroys history
>> and how you must not do this if you expose your history anywhere else.
>>
>> I think it's a perfectly fine history, but if you have already pushed out
>> your history somewhere else, you're now really screwed. In ways that a
>> *real* merge will never screw you.
>>
>> So the "--rebase" option really is only good for the lowest-level
>> developers. And that should be documented.
>
> Fair enough.
>
> How about this in the man page:
>
> \--rebase::
> Instead of a merge, perform a rebase after fetching.
> *NOTE:* Never do this on branches you plan to publish! This
> command will _destroy_ history, and is thus only suitable for
> topic branches to be submitted to another committer.
Nits.
(1) This "operation" will "rewrite" history.
You are not describing a command, but just one mode of operation
of a command, whose other modes of operation do not share this
history altering behaviour.
The history is rewritten and made hard to work with for others
who have previous incarnation of that history. If it happens
that nobody shared that previously published history nobody
needs to suffer. In that sense, there is something _usable_
depending on who you are. Destroy feels a bit too strong a
word.
(2) This is not suitable for people who publish their trees and
let others fetch and work off of them.
Rebase is fine for e-mail submitting contributors as your
description above suggests, but as your proposed commit log
message said, it is also perfectly appropriate if your
interaction with the outside world is "fetch + rebase +
push". You are not limited to "submitted to another
committer".
^ 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