* 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
* Re: Newbie questions regarding jgit
From: Jonas Fonseca @ 2008-11-11 22:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Farrukh Najmi, git
In-Reply-To: <20081111214434.GS2932@spearce.org>
On Tue, Nov 11, 2008 at 22:44, Shawn O. Pearce <spearce@spearce.org> wrote:
> Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
>> I would also like to have a public available maven repository for
>> JGit. If Shawn or Robin acks, I can look into hosting one in the SVN
>> area of the Google Code project page. Given the lack of a real release
>> cycle it probably only makes sense to have a snapshot repository.
>
> I have an account on kernel.org and was planning on hosting snapshots
> there, but I haven't had time to think about setting up a jgit area
> and pushing something into it. ;-)
If you prefer that ...
> We could also just host it in SVN in Google Code. I can give
> you admin rights on the egit project if you want to set it up and
> maintain it there. The downside is you need to use svn or git-svn
> to upload files to it, right?
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.
--
Jonas Fonseca
^ permalink raw reply
* [PATCH v2] git push: Interpret $GIT_DIR/branches in a Cogito compatible way
From: Martin Koegler @ 2008-11-11 21:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
Current git versions ignore everything after # (called <head> in the
following) when pushing. Older versions (before cf818348f1ab57),
interpret #<head> as part of the URL, which make git bail out.
As branches origin from Cogito, it is the best to correct this by
using the behaviour of cg-push:
push HEAD to remote refs/heads/<head>
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
Rebased to maint. One line dropped from commit message. Fixed typo,
reported by Mike Ralphson.
urls-remote.txt is unchanged between maint and next.
remote.c contains no changes in read_branches_file.
t5516 needed a manual invention.
Apart from merge problems (test ordering) in t5516, it should apply
to master or next too.
Documentation/urls-remotes.txt | 19 +++++++++++----
remote.c | 11 ++++++++
t/t5516-fetch-push.sh | 50 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt
index 504ae8a..41ec777 100644
--- a/Documentation/urls-remotes.txt
+++ b/Documentation/urls-remotes.txt
@@ -68,13 +68,22 @@ This file should have the following format:
------------
`<url>` is required; `#<head>` is optional.
-When you do not provide a refspec on the command line,
-git will use the following refspec, where `<head>` defaults to `master`,
-and `<repository>` is the name of this file
-you provided in the command line.
+
+Depending on the operation, git will use one of the following
+refspecs, if you don't provide one on the command line.
+`<branch>` is the name of this file in `$GIT_DIR/branches` and
+`<head>` defaults to `master`.
+
+git fetch uses:
+
+------------
+ refs/heads/<head>:refs/heads/<branch>
+------------
+
+git push uses:
------------
- refs/heads/<head>:<repository>
+ HEAD:refs/heads/<head>
------------
diff --git a/remote.c b/remote.c
index 7688f3b..91f1b7c 100644
--- a/remote.c
+++ b/remote.c
@@ -298,6 +298,17 @@ static void read_branches_file(struct remote *remote)
}
add_url_alias(remote, p);
add_fetch_refspec(remote, strbuf_detach(&branch, 0));
+ /*
+ * Cogito compatible push: push current HEAD to remote #branch
+ * (master if missing)
+ */
+ strbuf_init(&branch, 0);
+ strbuf_addstr(&branch, "HEAD");
+ if (frag)
+ strbuf_addf(&branch, ":refs/heads/%s", frag);
+ else
+ strbuf_addstr(&branch, ":refs/heads/master");
+ add_push_refspec(remote, strbuf_detach(&branch, 0));
remote->fetch_tags = 1; /* always auto-follow */
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 598664c..f9e8780 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -494,4 +494,54 @@ test_expect_success 'allow deleting an invalid remote ref' '
'
+test_expect_success 'fetch with branches' '
+ mk_empty &&
+ git branch second $the_first_commit &&
+ git checkout second &&
+ echo ".." > testrepo/.git/branches/branch1 &&
+ (cd testrepo &&
+ git fetch branch1 &&
+ r=$(git show-ref -s --verify refs/heads/branch1) &&
+ test "z$r" = "z$the_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ ) &&
+ git checkout master
+'
+
+test_expect_success 'fetch with branches containing #' '
+ mk_empty &&
+ echo "..#second" > testrepo/.git/branches/branch2 &&
+ (cd testrepo &&
+ git fetch branch2 &&
+ r=$(git show-ref -s --verify refs/heads/branch2) &&
+ test "z$r" = "z$the_first_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ ) &&
+ git checkout master
+'
+
+test_expect_success 'push with branches' '
+ mk_empty &&
+ git checkout second &&
+ echo "testrepo" > .git/branches/branch1 &&
+ git push branch1 &&
+ (cd testrepo &&
+ r=$(git show-ref -s --verify refs/heads/master) &&
+ test "z$r" = "z$the_first_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ )
+'
+
+test_expect_success 'push with branches containing #' '
+ mk_empty &&
+ echo "testrepo#branch3" > .git/branches/branch2 &&
+ git push branch2 &&
+ (cd testrepo &&
+ r=$(git show-ref -s --verify refs/heads/branch3) &&
+ test "z$r" = "z$the_first_commit" &&
+ test 1 = $(git for-each-ref refs/heads | wc -l)
+ ) &&
+ git checkout master
+'
+
test_done
--
1.5.6.5
^ permalink raw reply related
* Re: Newbie questions regarding jgit
From: Shawn O. Pearce @ 2008-11-11 21:44 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Farrukh Najmi, git
In-Reply-To: <2c6b72b30811111337v2fe23c75v25251838f721a007@mail.gmail.com>
Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
>
> I would also like to have a public available maven repository for
> JGit. If Shawn or Robin acks, I can look into hosting one in the SVN
> area of the Google Code project page. Given the lack of a real release
> cycle it probably only makes sense to have a snapshot repository.
I have an account on kernel.org and was planning on hosting snapshots
there, but I haven't had time to think about setting up a jgit area
and pushing something into it. ;-)
We could also just host it in SVN in Google Code. I can give
you admin rights on the egit project if you want to set it up and
maintain it there. The downside is you need to use svn or git-svn
to upload files to it, right?
--
Shawn.
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Jonas Fonseca @ 2008-11-11 21:37 UTC (permalink / raw)
To: Farrukh Najmi; +Cc: git
In-Reply-To: <4919EECB.7070408@wellfleetsoftware.com>
On Tue, Nov 11, 2008 at 21:44, Farrukh Najmi
<farrukh@wellfleetsoftware.com> wrote:
> Hi all,
Hello,
> I am git newbie and looking to use jgit in a servlet endpoint.
Sounds interesting. I have been thinking about how hard it would be to
write a very simpe jgitweb kind of thing and am very interested to
hear more about your experiences.
> Where can I find a public maven repo for gjit? It seems there is one
> somewhere because of the following file in src tree:
I would also like to have a public available maven repository for
JGit. If Shawn or Robin acks, I can look into hosting one in the SVN
area of the Google Code project page. Given the lack of a real release
cycle it probably only makes sense to have a snapshot repository.
> Now I am wondering where to begin to learn how to do the equivalent of the
> following commands via the gjit Java API:
>
> * git add /file/
> * git rm /file/
> * git mv /file
> * Whatever is the git way to get a specific version of a file
JGit currently has two APIs for working with the index, which will
allow you to add, remove and move data around in the tree. In nbgit I
ended up using GitIndex, which I found easier to figure out. As I
understand it, in the long run you want to use the DirCache API, but
it is still a work in progress.
> I am hoping that there aremore docs, samples, tutorials etc. somewhere that
> I am missing. Thanks for any help you can provide. Some pointers or code
> fragments would be terrific.
I started working on a tutorial for JGit, but didn't get very far so
it mostly consists of stub pages.
- http://code.google.com/docreader/#p=egit&s=egit&t=JGitTutorial
I have been working on moving the tutorial to maven project before
starting to write the more code heavy topics. This would make it
possible to include code snippets in the tutorial, while also allowing
to compile and test the examples.
--
Jonas Fonseca
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Junio C Hamano @ 2008-11-11 21:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200811080254.53202.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> * David Brown: Life with Git
> http://www.davidb.org/git/git-corp.pdf
I really enjoyed this talk, which was in a weird sense very encouraging.
By the way, one thing David talked about that is not in the PDF slides but
I found quite good to stress was the importance of good commit messages.
"Write in present tense, it will read much nicer and you'll appreciate it
after reading hundreds of them".
I'd actually say "imperative mood" instead of "present tense" (but they
look almost always the same in English), but in any case, it really gets
on my nerve to read commit message that talks things in past tense and I
often end up rewriting other people's commit log messages.
^ permalink raw reply
* Re: Newbie questions regarding jgit
From: Farrukh Najmi @ 2008-11-11 21:12 UTC (permalink / raw)
To: git
In-Reply-To: <4919EECB.7070408@wellfleetsoftware.com>
I should clarify that I am not using eclipse nor am I using any GUI. My
objective is to have Java API access to git from within a servlet using
jgit. At present, all I have to go on is javadoc and its not clear where
to begin if I simply wish to create, read and update files in a git repo
from within the servlet java code.
TIA for your help.
Farrukh Najmi wrote:
>
> Hi all,
>
> I am git newbie and looking to use jgit in a servlet endpoint.
>
> Where can I find a public maven repo for gjit? It seems there is one
> somewhere because of the following file in src tree:
>
> jgit-maven/jgit/pom.xml
>
> For now I have built the jar using /make_jgit.sh and installed the pom
> manually using m
>
> mvn install:install-file -DpomFile=jgit-maven/jgit/pom.xml
> -Dfile=jgit.jar
>
> I have added the following dependency to my maven project's pom.xml:
>
> <dependency>
> <groupId>org.spearce</groupId>
> <artifactId>jgit</artifactId>
> <version>0.4-SNAPSHOT</version>
> </dependency>
>
> Now I am wondering where to begin to learn how to do the equivalent of
> the following commands via the gjit Java API:
>
> * git add /file/
> * git rm /file/
> * git mv /file
> * Whatever is the git way to get a specific version of a file
>
>
> I am hoping that there aremore docs, samples, tutorials etc. somewhere
> that I am missing. Thanks for any help you can provide. Some pointers
> or code fragments would be terrific.
>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: Install issues
From: Junio C Hamano @ 2008-11-11 21:11 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Miklos Vajna, git
In-Reply-To: <20081110173101.3d76613b@pc09.procura.nl>
"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> --- 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 )
When you mean "grouping", using {} is much clearer to convey your
intention. Use of needless (subshell) forces the reader to wonder if you
wanted to do something that affects the environment for later commands
inside, and in this case you didn't.
Why do you have sparse check inside a backtick to produce a string to be
interpreted as a command to be executed?
How about doing this instead? 'sparse' without any parameter exits with
success status silently; when you do not have the command, the shell will
complain with "sparse: command not found" anyway, so you only need to
suggest "make 'test'" and nothing else.
-- >8 --
Subject: Makefile: help people who run 'make check' by mistake
The target to run self test is 'make test', but there are people who try
'make check' and worse yet do not have sparse installed.
Suggest 'make test' target when they do not have 'sparse'.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git c/Makefile w/Makefile
index 40309e1..d3137ca 100644
--- c/Makefile
+++ w/Makefile
@@ -1355,7 +1355,16 @@ check-sha1:: test-sha1$X
./test-sha1.sh
check: common-cmds.h
- for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
+ if sparse; \
+ then \
+ for i in *.c; \
+ do \
+ sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; \
+ done; \
+ else \
+ echo 2>&1 "Did you mean 'make test'?"; \
+ exit 1; \
+ fi
remove-dashes:
./fixup-builtins $(BUILT_INS) $(PROGRAMS) $(SCRIPTS)
^ 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