* Re: [PATCH] Add maven distribution management info for the new snapshot repository
From: Shawn O. Pearce @ 2008-11-12 0:58 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Jonas Fonseca, Farrukh Najmi, git
In-Reply-To: <20081111234858.GA17662@diku.dk>
Jonas Fonseca <fonseca@diku.dk> wrote:
> Shawn O. Pearce <spearce@spearce.org> wrote Tue, Nov 11, 2008:
> > Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> > > I don't think admin rights are necessary as long as I have
> > > "commit"/webdav access. And no svn or git-svn interaction should be
> > > needed to upload to the maven repository.
> >
> > Then have at it. It sounds like it would be worthwhile setting up.
>
> Instructions at http://code.google.com/p/egit/wiki/ConfiguringMaven
>
> diff --git a/jgit-maven/jgit/pom.xml b/jgit-maven/jgit/pom.xml
> index a123470..c370783 100644
> --- a/jgit-maven/jgit/pom.xml
> +++ b/jgit-maven/jgit/pom.xml
> @@ -185,4 +185,12 @@ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> <scope>compile</scope>
> </dependency>
> </dependencies>
> + <distributionManagement>
> + <snapshotRepository>
> + <id>jgit-maven-snapshot-repository</id>
> + <name>JGit Maven Snapshot Repository</name>
> + <url>dav:https://egit.googlecode.com/svn/maven/snapshot-repository/</url>
Shouldn't that be http:// and not https:// ?
The https interface asked me for a username/password, the
http:// one doesn't. We want this to be public, don't we?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Junio C Hamano @ 2008-11-12 0:57 UTC (permalink / raw)
To: Jeff King
Cc: David Symonds, Björn Steinbrink, Johannes Schindelin, git,
Stephan Beyer
In-Reply-To: <20081111012210.GA26920@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> To me, what is really being asked with "git diff --staged" (or "git
> diff --cached" for that matter), is "what is staged?"
Ok, "what is staged (in index)?", relative to the named commit which
defaults to HEAD, is a good argument. Let's apply it.
^ permalink raw reply
* Re: [PATCH v2] git push: Interpret $GIT_DIR/branches in a Cogito compatible way
From: Junio C Hamano @ 2008-11-12 0:52 UTC (permalink / raw)
To: Martin Koegler; +Cc: git
In-Reply-To: <1226440260-26943-1-git-send-email-mkoegler@auto.tuwien.ac.at>
Thanks, will start cooking in 'next'.
^ permalink raw reply
* Re: [PATCH] Fix non-literal format in printf-style calls
From: Junio C Hamano @ 2008-11-12 0:51 UTC (permalink / raw)
To: Daniel Lowe; +Cc: git
In-Reply-To: <1226351272-22253-1-git-send-email-dlowe@bitmuse.com>
Thanks, will apply to 'maint' and 'master' after splitting.
^ permalink raw reply
* Re: [PATCH] git-submodule: Avoid printing a spurious message.
From: Junio C Hamano @ 2008-11-12 0:51 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87myg67ywz.fsf@wine.dyndns.org>
Good eyes, thanks. Will apply to 'maint'.
^ permalink raw reply
* Re: [PATCH] git ls-remote: make usage string match manpage
From: Junio C Hamano @ 2008-11-12 0:50 UTC (permalink / raw)
To: Stefan Naewe; +Cc: git
In-Reply-To: <1226418751-18747-1-git-send-email-stefan.naewe@atlas-elektronik.com>
Thanks, will apply.
^ permalink raw reply
* Re: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
From: Junio C Hamano @ 2008-11-12 0:50 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Han-Wen Nienhuys, John Chapman, git
In-Reply-To: <200811101046.01543.simon@lst.de>
Simon Hausmann <simon@lst.de> writes:
> On Sunday 09 November 2008 Junio C Hamano, wrote:
>> These are patches to fast-import/git-p4, which you two seem to in charge
>> of.
>>
>> From: John Chapman <thestar@fussycoder.id.au>
>> Subject: [PATCH 1/2] Added support for purged files and also optimised
>> memory usage. Date: Sat, 8 Nov 2008 14:22:48 +1100
>> Message-Id: <1226114569-8506-1-git-send-email-thestar@fussycoder.id.au>
>>
>> From: John Chapman <thestar@fussycoder.id.au>
>> Subject: [PATCH 2/2] Cached the git configuration, which is now
>> noticibly faster on windows. Date: Sat, 8 Nov 2008 14:22:49 +1100
>> Message-Id: <1226114569-8506-2-git-send-email-thestar@fussycoder.id.au>
>>
>> It was unfortunately not immediately obvious from the Subject: line what
>> these patches are about, and I am guessing you missed them because of that.
>
> Ack on both patches. The second one could be done better, as suggested
> in the follow-ups, but both are clearly an improvement :)
Thanks, both of you. Will apply.
^ permalink raw reply
* Re: [PATCH 3/4] git-remote rename: support branches->config migration
From: Junio C Hamano @ 2008-11-12 0:49 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <b32cf68df41e417079a49dc02e46ffc0c571029b.1226349595.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> This is similar to the remotes->config one, but it makes the
> branches->config conversion possible.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
> builtin-remote.c | 2 ++
> t/t5505-remote.sh | 12 ++++++++++++
> 2 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-remote.c b/builtin-remote.c
> index d9d0ba3..3af1876 100644
> --- a/builtin-remote.c
> +++ b/builtin-remote.c
> @@ -384,6 +384,8 @@ static int migrate_file(struct remote *remote)
> remote->fetch_refspec[i], buf.buf);
> if (remote->origin == REMOTE_REMOTES)
> path = git_path("remotes/%s", remote->name);
> + else if (remote->origin == REMOTE_BRANCHES)
> + path = git_path("branches/%s", remote->name);
There is something fishy going on between 2/4 and 3/4. 2/4 was advertised
to migrate remotes to config and had a call to migrate_file() for that
purpose. Here this one now allows to convert branches but there is no
change to the callsite of migrate_file().
Which would mean that 2/4 would convert branches/foo too. And this one is
only to remove the leftover branches/foo file.
Or am I utterly confused?
^ permalink raw reply
* Re: [PATCH 1/2] Document "git log --source"
From: Junio C Hamano @ 2008-11-12 0:48 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Santi Béjar
In-Reply-To: <20081110185815.6117@nanako3.lavabit.com>
Thanks; will queue this one, but Santi said he'll work on a replacement
for 2/2 so I'll drop 2/2 from you for now.
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Kyle Moffett @ 2008-11-12 0:44 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <20081109014926.GA31276@coredump.intra.peff.net>
On Sat, Nov 8, 2008 at 8:49 PM, Jeff King <peff@peff.net> wrote:
> The behavior is configurable via receive.denyCurrentBranch,
> defaulting to "warn" so as not to break existing setups
> (though it may, after a deprecation period, switch to
> "refuse" by default). For users who know what they are doing
> and want to silence the warning (e.g., because they have a
> post-receive hook that reconciles the HEAD and working
> tree), they can turn off the warning by setting it to false
> or "ignore".
Hmm, I wonder if it would be possible to also add a "detach" variant;
which would create a detached-HEAD at the current commit when
automatically receiving a push to the working branch. I have a
post-receive script that does so right now on a couple repositories.
It's still a little confusing to someone actively working in the
repository being pushed to, but it's much easier to explain than the
current default behavior.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [PATCH] git-submodule: Avoid printing a spurious message.
From: Johannes Schindelin @ 2008-11-12 0:07 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87myg67ywz.fsf@wine.dyndns.org>
Hi,
On Tue, 11 Nov 2008, Alexandre Julliard wrote:
> Fix 'git submodule update' to avoid printing a spurious "Maybe you want
> to use 'update --init'?" once for every uninitialized submodule it
> encounters.
>
> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
> ---
> git-submodule.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index b63e5c3..220d94e 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -323,7 +323,7 @@ cmd_update()
> # Only mention uninitialized submodules when its
> # path have been specified
> test "$#" != "0" &&
> - say "Submodule path '$path' not initialized"
> + say "Submodule path '$path' not initialized" &&
> say "Maybe you want to use 'update --init'?"
> continue
> fi
Ooops, thanks (& ACK).
Ciao,
Dscho
^ permalink raw reply
* Re: [take 2] git send-email updates
From: Junio C Hamano @ 2008-11-12 0:14 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20081111221351.GE10073@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> Oh you mean that if one use --no-format-patch you don't wan't _any_
> option to be passed to format-patch?
The option name --no-format-patch sounded like "I do not want you to act
as a frontend, ever", i.e. if you type master..next by mistake on the
command line, the command would barf when the option is given. Not even
"pass to format-patch", but "do not run format-patch to begin with".
It is not a big deal especially for interactive use (and that is why I
said "somewhat" unfortunate).
> If we're really doing this, then maybe we want a 5-state kind of option:
> 1 disallow any file name ;
> 2 if conflict, chose the revision ;
> 3 barf if any conflict arises (default) ;
> 4 if conflict chose the file ;
> 5 disallow any kind of revision argument.
>
> My proposal implements 2 as --format-patch, 3 as default, and 4 as
> --no-format-patch. You propose basically (5) for --no-format-patch
> instead, well I say this makes sense, but it's somehow "sad" not to have
> (1) too in that case.
Actually, "send-email --format-patch master..fixes Documentation/" may be
a useful command to send out only documentation fixes. For such a usage,
Documentation/ should not be taken as a maildir. If we would want to
support such usage (and I'd say why not), a token can fall into one (or
two) of three categories:
- can it be a rev?
- is it a tracked path (either blob or a leading dir)?
- is it a file/dir that is not tracked?
The first two would be format-patch candidate. The last one is the
traditional mail source. Because the latter two are disjoint set, and
because it does not matter if you have a tracked file 'master' and a
branch 'master' in your repo (either will be passed to format-patch
anyway), the actual disambiguity is reduced, but it still is different
from what you have in your patch, I suspect.
As to options, how about doing this:
--no-format-patch means never ever run format-patch, behave exactly as
before;
--format-patch means what you have in your patch. guess and favor
format-patch parameter when ambiguous;
without either option, guess and favor mbox/maildir but still run
format-patch if remaining parameters and options need to
(e.g. "send-email my-cover-letter origin/master..master" will find
my-cover-letter which is not tracked and take it as mbox, and grab
patches from commits between origin/master..master, and send all of
them).
^ permalink raw reply
* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Jonas Fonseca @ 2008-11-12 0:04 UTC (permalink / raw)
To: Piotr Findeisen; +Cc: git
In-Reply-To: <ddb82bf60811100214j4246cf25yc1263c2ae8cd10fc@mail.gmail.com>
Piotr Findeisen <piotr.findeisen@gmail.com> wrote Mon, Nov 10, 2008:
> > This would also fix the usage of "--" in the manpages, e.g.
> >
> > You've now initialized the working directory--you may notice ...
> >
> > in gittutorial(7). On my setup, with "--" replaced with "—", I get the
> > following nroff code:
>
> On my machine, make gittutorial.7 produces manpage that displays "--"
> in this place :)
At least you don't loose anything compared to the current behavior. ;)
> > You've now initialized the working directory\(emyou may notice
>
> Anyway, this may be a good idea to use unambiguous "—" (though people
> writing docs may be used to using "--" as a punctuation). I can run
> through the Documentation replacing "\w--\w" with m-dash, if you want.
I would like to see such a patch.
--
Jonas Fonseca
^ permalink raw reply
* Re: Install issues
From: H.Merijn Brand @ 2008-11-11 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Boyd Lynn Gerber, Miklos Vajna, git
In-Reply-To: <7vzlk5x21p.fsf@gitster.siamese.dyndns.org>
On Tue, 11 Nov 2008 15:42:26 -0800, Junio C Hamano <gitster@pobox.com>
wrote:
> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>
> > On Tue, 11 Nov 2008 16:03:50 -0700, Boyd Lynn Gerber <gerberb@zenez.com> wrote:
> >
> >> Here is a check list I use to make sure my patches are OK.
> >>
> >> http://repo.or.cz/w/git.git?a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD
> >> ...
> >> > I'm by now way offended or scared away if you reject these kind of
> > ^
> > /me meant "no" where he wrote "now" :( :(
> > I can imagine people interpreting that sentence very very wrong.
>
> That is not even "interpretation". You _literally_ wrote the exact
> opposite of what you meant ;-).
I'm really really sorry. That must have sounded harsh.
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* [PATCH] Add maven distribution management info for the new snapshot repository
From: Jonas Fonseca @ 2008-11-11 23:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jonas Fonseca, Farrukh Najmi, git
In-Reply-To: <20081111231106.GT2932@spearce.org>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
jgit-maven/jgit/pom.xml | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
Shawn O. Pearce <spearce@spearce.org> wrote Tue, Nov 11, 2008:
> Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> > I don't think admin rights are necessary as long as I have
> > "commit"/webdav access. And no svn or git-svn interaction should be
> > needed to upload to the maven repository.
>
> Then have at it. It sounds like it would be worthwhile setting up.
Instructions at http://code.google.com/p/egit/wiki/ConfiguringMaven
diff --git a/jgit-maven/jgit/pom.xml b/jgit-maven/jgit/pom.xml
index a123470..c370783 100644
--- a/jgit-maven/jgit/pom.xml
+++ b/jgit-maven/jgit/pom.xml
@@ -185,4 +185,12 @@ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
<scope>compile</scope>
</dependency>
</dependencies>
+ <distributionManagement>
+ <snapshotRepository>
+ <id>jgit-maven-snapshot-repository</id>
+ <name>JGit Maven Snapshot Repository</name>
+ <url>dav:https://egit.googlecode.com/svn/maven/snapshot-repository/</url>
+ <uniqueVersion>true</uniqueVersion>
+ </snapshotRepository>
+ </distributionManagement>
</project>
--
1.6.0.3.866.gc189b
--
Jonas Fonseca
^ permalink raw reply related
* Re: Install issues
From: Junio C Hamano @ 2008-11-11 23:42 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Boyd Lynn Gerber, Miklos Vajna, git
In-Reply-To: <20081112003547.38081e09@pc09.procura.nl>
"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> On Tue, 11 Nov 2008 16:03:50 -0700, Boyd Lynn Gerber <gerberb@zenez.com> wrote:
>
>> Here is a check list I use to make sure my patches are OK.
>>
>> http://repo.or.cz/w/git.git?a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD
>> ...
>> > I'm by now way offended or scared away if you reject these kind of
> ^
> /me meant "no" where he wrote "now" :( :(
> I can imagine people interpreting that sentence very very wrong.
That is not even "interpretation". You _literally_ wrote the exact
opposite of what you meant ;-).
^ permalink raw reply
* Re: importing mercurial patch
From: Ondrej Certik @ 2008-11-11 23:36 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0811111454330.30769@pacific.mpi-cbg.de>
Hi Johannes!
On Tue, Nov 11, 2008 at 3:41 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 11 Nov 2008, Ondrej Certik wrote:
>
>> But imho if git supported mercurial patches, life would be a lot easier.
>
> Mine would not be.
Because you don't use Mercurial, or is there also some other reason?
> BTW I had to be online (which is not always the case when I read email) to
> access the pastebin, which made it more of a hassle to look at it than I
> deem necessary. Besides, it is bad because in 3 days, that pastie will be
> gone. Not nice.
You are right, sorry about that.
>
> So here is it, for the pleasure of others:
>
> # HG changeset patch
> # User Vinzent Steinberg <vinzent.steinberg@gmail.com>
> # Date 1226338168 -3600
> # Node ID 23efeaf89f7089d94307526ec0536eb6f4382213
> # Parent dab6435e04fd083d66bbfa897cbe15ab9660b9e6
> <commit subject>
>
> <commit body>
>
> diff -r <commit name> -r <commit name> <filename>
> --- a/<filename> <date>
> --- b/<filename> <date>
> @@ <line range pair> @@
> ...
>
> So what I suggest is that you familiarize yourself with
> builtin-mailsplit.c. Basically you'd need to enhance the is_from_line()
> function to check this:
>
> const char *hg_patch_preamble = "# HG changeset patch\n";
>
> if (len >= strlen(hg_patch_preamble) && !memcmp(line,
> hg_patch_preamble, strlen(hg_patch_preamble))
> return 1;
>
> Then you need to familiarize yourself with builtin-mailinfo.c. In
> function mailinfo(), you'd need to work on this:
>
> /* process the email header */
> while (read_one_header_line(&line, fin))
> check_header(&line, p_hdr_data, 1);
>
> I'd suggest to make the function read_one_header_line() into a
> handle_one_header_line(), and replace the while loop with this:
>
> if (!strbuf_getline(&line, fin)) {
> if (!strcmp(line.buf, "# HG changeset patch\n"))
> while (handle_one_hg_header_line(&line,
> p_hdr_data, fin))
> strbuf_getline(&line, fin);
> else
> while (handle_one_header_line(&line, fin)) {
> check_header(&line, p_hdr_data, 1);
> strbuf_getline(&line, fin);
> }
> }
>
> Implementing handle_one_hg_header_line() should be a breeze:
>
> static int handle_one_hg_header_line(struct strbuf *line,
> struct strbuf *hdr_data[], FILE *in)
> {
> if (line.buf[0] != '#') {
> strbuf_addbuf(hdr_data[1], line);
> return 0; /* no more headers */
> }
>
> if (!prefixcmp(line.buf, "# User "))
> strbuf_addstr(hdr_data[0], line.buf + 7);
> else if (!prefixcmp(line.buf, "# Date "))
> strbuf_addstr(hdr_data[2], line.buf + 7);
> return 1;
> }
>
> Okay, this is all utterly untested, and you probably need to trim the
> newlines from the lines first, and maybe you need to replace the
> hdr_data[] entries instead of adding to them, but now you have a starting
> point.
Thanks a lot for the detailed help, I'll give it a shot and report
back in couple days, hopefully with a working patch. :)
Ondrej
^ permalink raw reply
* Re: Install issues
From: H.Merijn Brand @ 2008-11-11 23:35 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Junio C Hamano, Miklos Vajna, git
In-Reply-To: <alpine.LNX.2.00.0811111554530.19159@suse104.zenez.com>
On Tue, 11 Nov 2008 16:03:50 -0700, Boyd Lynn Gerber <gerberb@zenez.com> wrote:
> Here is a check list I use to make sure my patches are OK.
>
> http://repo.or.cz/w/git.git?a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD
> ...
> > I'm by now way offended or scared away if you reject these kind of
^
/me meant "no" where he wrote "now" :( :(
I can imagine people interpreting that sentence very very wrong.
> > patches
>
> The crowed here may seem harsh but they really are not. They just have a
> lot to do and getting things to them in a format that is easy to follow
> and uses the above URL guildlines assists them in looking at the patches,
> commit messages and sign-off. Git requires a sign-off in order for them
> to use the patches. It is a way to make sure everything is kept above
> board and proper. This allow ever line of code to have a resource as to
> where and whence it ...
>
> Do not give up. Just try to do things in a manner that is easy to allow
> your patches into Git.
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Junio C Hamano @ 2008-11-11 23:23 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Schindelin, git
In-Reply-To: <20081111063904.7da4df94.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> This subcommand should be used when you have a branch or a part of a
> branch that isn't easily bisectable because of a bug that has been
> fixed latter.
While I acknowledge your effort to make bisect easier to use, I do
not think this is going in the right direction, from the point of view of
the workflow.
I do agree that the issue it tries to solve is a problem in real life.
When you want to hunt for a bug, it is certainly possible that your tests
fail for a bug that is unrelated to what you are hunting for for a range
of commits. Borrowing from your picture:
...--O--A--X1--X2--...--Xn--B--...
non of the commit marked as Xi may not be testable.
But at that point, will you really spend time to rebuild history between A
and B by fixing an unrelated bug that hinders your bisect, so that you can
have a parallel history that is bisectable? I doubt anybody would.
Even if we assume that somebody wants to adopt the workflow to first fix
an unrelated bug (that may be totally uninteresting for the purpose of
solving the original issue he set out to figure out) to rewrite the
history, what he first needs to do is to find out what part of the history
to rewrite. IOW, he needs to know A and B (and in general, the history is
not even linear). Maybe he guesses what A and B is. But for one thing,
after making the guess, he would certainly test A and B to see if the
original issue exists at these commits. The sequence of commits Xi become
irrelevant if A turns out to be bad or B turns out to be good.
And if A is good and B is bad, then the _original bug_ is in the very
sequence of Xi you are going to rewrite. By the time you made a rewritten
history with sequence of commits Yi to be grafted like this:
C--Y1--Y2--...--Yn
/
...--O--A--X1--X2--...--Xn--B--...
to make it bisectable, it is very likely that you would have already seen
the original bug.
In such a case where you need to figure out what an unrelated bug is, and
which commit A and B are involved while bisecting, I think you are much
better off using bisect skip, as Johannes mentioned earlier.
On the other hand, if you already have a well-known bug that was
introduced at A whose fix at B is also very well-known, you would not even
need a separate "bisect replace" command nor replace_parents() machinery
only for the purpose of bisection, would you? In such a case I think you
can just use a usual graft.
I have a separate idea make 'grafts' easier on object transfer, that is
somewhat related to this one, by the way. Instead of making the grafts
completely a local matter as we do now, we can reserve refs/replace/
namespace, and record a new commit object to replace an existing commit
whose object name is $sha1 as refs/replace/$sha1. We make almost all the
commands except object enumeration (fsck, receive-pack, send-pack, prune,
etc. Roughly speaking, anything that involves "rev-list --objects") honor
this commit replacement, so that any time you ask for commit $sha1, the
object layer gives you the replacement commit object back. In this way,
you can clone or fetch from such a repository (along with refs in
refs/replace/ hierarchy) and fsck/prune won't lose the original parents
(because it does not see replacements). Things like paranoid update hook
needs to become very careful about refs/replace/ for security reasons, but
I think this would make the grafts much easier to use.
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Johannes Schindelin @ 2008-11-11 23:26 UTC (permalink / raw)
To: Jonas Fonseca
Cc: Jakub Narebski, Steven Grimm, Shawn O. Pearce, Robin Rosenberg,
git, Jeff King, Petr Baudis, Tim Ansell
In-Reply-To: <2c6b72b30811111405u52824e2bg246912ec6dae2162@mail.gmail.com>
Hi,
On Tue, 11 Nov 2008, Jonas Fonseca wrote:
> On Mon, Nov 10, 2008 at 00:52, Jakub Narebski <jnareb@gmail.com> wrote:
> > Would it be possible to publish PDF version sowehere, for example
> > as attachement to http://git.or.cz/gitwiki/GitTogether? My old
> > web browser doesn't support Google Docs...
>
> http://docs.google.com/MiscCommands?command=saveasdoc&docID=dhhs72s2_1wtzbnsnj&exportFormat=pdf
I also included whatever I could grab (did not take care of mugwumps html
pages yet) into my presentations branch.
Ciao,
Dscho
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Shawn O. Pearce @ 2008-11-11 23:11 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Farrukh Najmi, git
In-Reply-To: <2c6b72b30811111401i3c995889n54407243a1072599@mail.gmail.com>
Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
>
> I don't think admin rights are necessary as long as I have
> "commit"/webdav access. And no svn or git-svn interaction should be
> needed to upload to the maven repository.
>
> Take a look at the distributionManagement section of the
> google-maven-repository:
>
> - http://google-maven-repository.googlecode.com/svn/repository/com/google/google/1/google-1.pom
>
> Looks pretty easy to set up. About maintaining it, I don't mind doing
> "mvn deploy" once in a while, but some kind of update policy should
> probably be worked out in any case.
Then have at it. It sounds like it would be worthwhile setting up.
--
Shawn.
^ permalink raw reply
* Re: Install issues
From: Boyd Lynn Gerber @ 2008-11-11 23:03 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Junio C Hamano, Miklos Vajna, git
In-Reply-To: <20081111190243.7044d6cb@pc09.procura.nl>
On Tue, 11 Nov 2008, H.Merijn Brand wrote:
> On Tue, 11 Nov 2008 09:47:00 -0800, Junio C Hamano <gitster@pobox.com>
> wrote:
>> Miklos Vajna <vmiklos@frugalware.org> writes:
>>> On Mon, Nov 10, 2008 at 05:31:01PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
>>>> --- Makefile.org 2008-11-10 17:29:53.000000000 +0100
>>>> +++ Makefile 2008-11-10 17:29:39.000000000 +0100
>>>> @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
>>>> ./test-sha1.sh
>>>>
>>>> check: common-cmds.h
>>>> + @`sparse </dev/null 2>/dev/null` || (\
>>>> + echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
>>>> + echo "Did you mean 'make test' instead?" ;\
>>>> + exit 1 )
>>>> for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
>>>
>>> Please read Documentation/SubmittingPatches, your patch lacks a signoff
>>> and a commit message.
Here is a check list I use to make sure my patches are OK.
http://repo.or.cz/w/git.git?a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD
...
> I'm by now way offended or scared away if you reject these kind of
> patches
The crowed here may seem harsh but they really are not. They just have a
lot to do and getting things to them in a format that is easy to follow
and uses the above URL guildlines assists them in looking at the patches,
commit messages and sign-off. Git requires a sign-off in order for them
to use the patches. It is a way to make sure everything is kept above
board and proper. This allow ever line of code to have a resource as to
where and whence it ...
Do not give up. Just try to do things in a manner that is easy to allow
your patches into Git.
Good Luck,
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Tait @ 2008-11-11 22:14 UTC (permalink / raw)
To: Git Mailing List; +Cc: Ian Hilt, Francis Galiegue
In-Reply-To: <alpine.LFD.2.00.0811111542230.24205@sys-0.hiltweb.site>
> > > > > > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
> > > > >
> > > > > Greedy operators are only supported with perl 5.10 or more... I think
> > > > > it's a bad idea to use them...
> > > >
> > > > The problem here was that a space should follow the field, but it may
> > > > not. The user may unwarily backup over it. "\s*" would match this
> > > > case.
> > > >
> > > > But if there is a space, it is included in the "(.+)".
> > >
> > > Not in any version of Perl to which I have access.
> > >
> >
> > And if you see a space in (.+), your regex engine is buggy anyway.
>
> So what does this script produce on your systems?
>
> --8<--
> #!/usr/bin/perl -Tw
> use strict;
> my $ws = "To: \nCc:";
>
> $ws =~ /^To:\s*(.+)\s*\nCc:/ism;
>
> if ($1 eq ' ') {
> print "\$1 is equal to a space.\n";
> }
> -->8--
It does match a space in that case. I misunderstood the problem this was
trying to solve. (Sorry for the confusion.)
^ permalink raw reply
* Re: [take 2] git send-email updates
From: Pierre Habouzit @ 2008-11-11 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4p2e0zus.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]
On Tue, Nov 11, 2008 at 08:30:51PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > The last patch is dropped for now (the automatic --compose stuff)
> > because I'm not sure which option to add, and that I don't care enough
> > about it to spend more time on it.
> >
> > I think I've incorporated most of the stuff people asked about in this
> > series.
> >
> > [PATCH 1/4] git send-email: make the message file name more specific.
> > [PATCH 2/4] git send-email: interpret unknown files as revision lists
> > [PATCH 3/4] git send-email: add --annotate option
> > [PATCH 4/4] git send-email: ask less questions when --compose is used.
>
> Thanks.
>
> It is somewhat unfortunate that an explicit --no-format-patch works
> exactly the same way as not giving the option at all.
Unless I'm mistaken in my code, and I may really be, it doesn't.
--format-patch says that in case of conflicts, the "revision" kind of
argument wins, --no-format-patch says that the "file" one wins, without
any it dies with an error. It's really a tristate, but maybe I missed
your point ?
> I would have expected that it would guess and warn if you did not give
> either, and it would not even guess (i.e. file is mbox, dir is
> maildir) and error out if there is a leftover option in @rev_list_opts
> if the user explicitly asked the command not act as a frontend to
> format patch.
Oh you mean that if one use --no-format-patch you don't wan't _any_
option to be passed to format-patch ? Hmmm I don't know, both what I did
and that are sane, I don't really know what to chose. But if we're going
to go down this road, _your_ --no-format-patch and --format-patch don't
quite do the opposite, as --format-patch still allows files to be passed
to it.
If we're really doing this, then maybe we want a 5-state kind of option:
1 disallow any file name ;
2 if conflict, chose the revision ;
3 barf if any conflict arises (default) ;
4 if conflict chose the file ;
5 disallow any kind of revision argument.
My proposal implements 2 as --format-patch, 3 as default, and 4 as
--no-format-patch. You propose basically (5) for --no-format-patch
instead, well I say this makes sense, but it's somehow "sad" not to have
(1) too in that case.
But in the end, I believe this _may_ quite be slightly over-engineered in
the end ;) I would gladly implement the combination people like most, as
soon as I can pass format-patch option a way or the other, I'm happy :)
> I will queue the series in 'pu' because I suspect you would like a chance
> to amend out a "print foo" from the second commit ;-)
*ooops*
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Jonas Fonseca @ 2008-11-11 22:05 UTC (permalink / raw)
To: Jakub Narebski
Cc: Steven Grimm, Shawn O. Pearce, Robin Rosenberg, git, Jeff King,
Petr Baudis, Tim Ansell
In-Reply-To: <200811100052.16740.jnareb@gmail.com>
On Mon, Nov 10, 2008 at 00:52, Jakub Narebski <jnareb@gmail.com> wrote:
> Would it be possible to publish PDF version sowehere, for example
> as attachement to http://git.or.cz/gitwiki/GitTogether? My old
> web browser doesn't support Google Docs...
http://docs.google.com/MiscCommands?command=saveasdoc&docID=dhhs72s2_1wtzbnsnj&exportFormat=pdf
--
Jonas Fonseca
^ 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