* Re: commit summary, --pretty=short and other tools
From: Johannes Schindelin @ 2007-09-18 10:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Benoit SIGOURE, Mike Hommey, git
In-Reply-To: <46EF7BF7.3070107@op5.se>
Hi,
On Tue, 18 Sep 2007, Andreas Ericsson wrote:
> const char *find_commit_subject_end(const char *commit_msg)
> {
> const char *dot, *paragraph_end;
> paragraph_end = strstr(commit_msg, "\n\n");
> dot = strchr(commit_msg, '.');
> return min_non_null(dot, paragraph_end); }
>
> would probably get it right very nearly always.
Counterexample (not even mentioning the missing handling of NULL):
http://brick.kernel.dk/git/?p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa
And no, the responsible developer showed a strong unwillingness to adapt
to better tools and workflows.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/5] More builtin-fetch fixes
From: Andreas Ericsson @ 2007-09-18 10:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Daniel Barkalow, git
In-Reply-To: <20070918085444.GN3099@spearce.org>
Shawn O. Pearce wrote:
> but for some of the really common cases we are quite
> happy with builtin-fetch. Especially its performance as we're
> seeing speedups of 25x or more on Cygwin/Windows.
>
Excellent news, and great job. :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Johannes Schindelin @ 2007-09-18 10:16 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <20070918072627.GB3506@coredump.intra.peff.net>
Hi,
On Tue, 18 Sep 2007, Jeff King wrote:
> This is based on the git-import.sh script, but is a little
> more robust and efficient. More importantly, it should
> serve as a quick template for interfacing fast-import with
> perl scripts.
Yes, please! Maybe somebody will then grab the low-hanging fruit of
writing a "git-fast-export", which can be used to dump a complete
repository in text format?
Ciao,
Dscho
^ permalink raw reply
* Re: commit summary, --pretty=short and other tools
From: Andreas Ericsson @ 2007-09-18 10:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Benoit SIGOURE, Mike Hommey, git
In-Reply-To: <Pine.LNX.4.64.0709181109130.28586@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Sep 2007, Andreas Ericsson wrote:
>
>> const char *find_commit_subject_end(const char *commit_msg)
>> {
>> const char *dot, *paragraph_end;
>> paragraph_end = strstr(commit_msg, "\n\n");
>> dot = strchr(commit_msg, '.');
>> return min_non_null(dot, paragraph_end); }
>>
>> would probably get it right very nearly always.
>
> Counterexample (not even mentioning the missing handling of NULL):
>
Well, pseudo code doesn't have to handle NULL's, as it never gets bad
pseudo-input ;-)
> http://brick.kernel.dk/git/?p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa
>
> And no, the responsible developer showed a strong unwillingness to adapt
> to better tools and workflows.
>
Hmm, how about any interpunctuation char or newline followed by newline or
the first dot?
It would cover this case and not be overly hard to code.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: commit summary, --pretty=short and other tools
From: Benoit SIGOURE @ 2007-09-18 10:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, Mike Hommey, git
In-Reply-To: <Pine.LNX.4.64.0709181109130.28586@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]
On Sep 18, 2007, at 12:13 PM, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Sep 2007, Andreas Ericsson wrote:
>
>> const char *find_commit_subject_end(const char *commit_msg)
>> {
>> const char *dot, *paragraph_end;
>> paragraph_end = strstr(commit_msg, "\n\n");
>> dot = strchr(commit_msg, '.');
>> return min_non_null(dot, paragraph_end); }
>>
>> would probably get it right very nearly always.
>
> Counterexample (not even mentioning the missing handling of NULL):
>
> http://brick.kernel.dk/git/?
> p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa
>
> And no, the responsible developer showed a strong unwillingness to
> adapt
> to better tools and workflows.
>
OK, look, I think this is the typical case where there is no single
solution to fit all use cases.
To handle this specific case, you could say "OK let's stop at
punctuation symbols then". But what if my commit message is "Add
namespace::member whatever."
If there is a single line followed by a blank line: it's a git-style
commit message, do what was done before.
Otherwise, we need some heuristic to find the relevant part of the
commit message (if there is such a relevant part in the first place!).
--
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: [PATCH] contrib/fast-import: add perl version of simple example
From: Andreas Ericsson @ 2007-09-18 10:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0709181115250.28586@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Sep 2007, Jeff King wrote:
>
>> This is based on the git-import.sh script, but is a little
>> more robust and efficient. More importantly, it should
>> serve as a quick template for interfacing fast-import with
>> perl scripts.
>
> Yes, please! Maybe somebody will then grab the low-hanging fruit of
> writing a "git-fast-export", which can be used to dump a complete
> repository in text format?
>
I thought that was already taken care of since format-patch handles
--root flag properly?
Otherwise, "git repack -a --window=0 --depth=0" should provide an
easily parseable dump of an entire repo.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Jeff King @ 2007-09-18 10:30 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <46EFA84C.3080906@op5.se>
On Tue, Sep 18, 2007 at 12:28:28PM +0200, Andreas Ericsson wrote:
>> Yes, please! Maybe somebody will then grab the low-hanging fruit of
>> writing a "git-fast-export", which can be used to dump a complete
>> repository in text format?
>
> I thought that was already taken care of since format-patch handles
> --root flag properly?
>
> Otherwise, "git repack -a --window=0 --depth=0" should provide an
> easily parseable dump of an entire repo.
I think he means a dump that you can meaningfully edit with sed or a
text editor. And even nicer, one that could be fed back into
git-fast-import. So you could do something like:
git-fast-export A..B >dump
vi dump
git-fast-import <dump
to rewrite history in a very flexible way.
-Peff
^ permalink raw reply
* Re: commit summary, --pretty=short and other tools
From: Johannes Schindelin @ 2007-09-18 10:54 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Andreas Ericsson, Mike Hommey, git
In-Reply-To: <CEE6032F-39FB-42D8-A57A-671E4E0875C7@lrde.epita.fr>
Hi,
On Tue, 18 Sep 2007, Benoit SIGOURE wrote:
> On Sep 18, 2007, at 12:13 PM, Johannes Schindelin wrote:
>
> > On Tue, 18 Sep 2007, Andreas Ericsson wrote:
> >
> > > const char *find_commit_subject_end(const char *commit_msg)
> > > {
> > > const char *dot, *paragraph_end;
> > > paragraph_end = strstr(commit_msg, "\n\n");
> > > dot = strchr(commit_msg, '.');
> > > return min_non_null(dot, paragraph_end); }
> > >
> > > would probably get it right very nearly always.
> >
> > Counterexample (not even mentioning the missing handling of NULL):
> >
> > http://brick.kernel.dk/git/?p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa
> >
> > And no, the responsible developer showed a strong unwillingness to adapt
> > to better tools and workflows.
> >
>
> OK, look, I think this is the typical case where there is no single solution
> to fit all use cases.
> To handle this specific case, you could say "OK let's stop at punctuation
> symbols then". But what if my commit message is "Add namespace::member
> whatever."
>
> If there is a single line followed by a blank line: it's a git-style commit
> message, do what was done before.
That's the current behaviour already. And has been for a long time.
> Otherwise, we need some heuristic to find the relevant part of the commit
> message (if there is such a relevant part in the first place!).
Or do we?
I was opposed to this change, since I think that there is really no way to
fit all exisiting (!) repositories.
And since oneline was always only meant as a hint, it might just as well
have stayed at "just one line, the first one".
Maybe you guys find a better method, such as providing a regular
expression in the config or something, but let's not do another change
that does not work for all cases.
Ciao,
Dscho
^ permalink raw reply
* [rfc] git submodules howto
From: Miklos Vajna @ 2007-09-18 10:55 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]
hi,
i saw several "is there any step by step howto on how to use git
submodules?" question on irc, and as far as i think there is none
available at the moment
here is how i use it at the moment:
$ mkdir lib
$ cd lib
$ git init
Initialized empty Git repository in .git/
$ echo "libmakefile" > Makefile
$ dg add Makefile
$ git commit -m "libmakefile"
Created initial commit 57c1dce: libmakefile
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 Makefile
$ cd ..
$ mkdir main
$ cd main
$ git init
Initialized empty Git repository in .git/
$ echo "main makefile" > Makefile
$ git add Makefile
$ git commit -m "main makefile"
Created initial commit 8935291: main makefile
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 Makefile
$ git submodule add ../lib lib
Initialized empty Git repository in /home/vmiklos/scm/git/sub/main/lib/.git/
0 blocks
$ git commit -m "added lib submodule"
Created commit 9dbfedf: added lib submodule
2 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 .gitmodules
create mode 160000 lib
$ cd ..
$ git clone main cloned
Initialized empty Git repository in /home/vmiklos/scm/git/sub/cloned/.git/
0 blocks
$ cd cloned
$ git submodule init
Submodule 'lib' (/home/vmiklos/scm/git/sub/lib/.git) registered for path 'lib'
$ git submodule update
Initialized empty Git repository in /home/vmiklos/scm/git/sub/cloned/lib/.git/
0 blocks
Submodule path 'lib': checked out '57c1dce0e083e9ee50d06111d6aa1523116c2e15'
$ cat Makefile
main makefile
$ cat lib/Makefile
libmakefile
my questions:
1) is this correct? :) i use it and it seem to do what i except, but
maybe it's not correct
2) does this worth adding to the documentation? maybe to a .txt under
Documentation/howto? or to git-submodule.txt?
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-fsck/lost-found's speed vs git-prune's
From: Johannes Schindelin @ 2007-09-18 11:13 UTC (permalink / raw)
To: Mike Hommey; +Cc: Junio C Hamano, git
In-Reply-To: <20070918095049.GA9388@glandium.org>
Hi,
On Tue, 18 Sep 2007, Mike Hommey wrote:
> On Tue, Sep 18, 2007 at 02:18:44AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > Mike Hommey <mh@glandium.org> writes:
> >
> > > I was wondering if that was to be expected for git-fsck to be
> > > significantly slower than git-prune (by several orders of magnitude) ?
> >
> > fsck validates objects are correct and sane. prune only looks
> > at reachability.
>
> Now, the speed difference makes sense, but I wouldn't expect lost-found
> to actually bother validating objects...
That's why we should get rid of lost-found, and only keep the --lost-found
option to git-fsck, to make it clear.
And I think that it is too rare that you lost objects and want to find
them, to warrant a fast version of it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Johannes Schindelin @ 2007-09-18 11:17 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jeff King, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <46EFA84C.3080906@op5.se>
Hi,
On Tue, 18 Sep 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > Maybe somebody will then grab the low-hanging fruit of writing a
> > "git-fast-export", which can be used to dump a complete repository in
> > text format?
>
> I thought that was already taken care of since format-patch handles
> --root flag properly?
Umm. Probably you forgot about merge commits, right? And about more than
one branch?
> Otherwise, "git repack -a --window=0 --depth=0" should provide an easily
> parseable dump of an entire repo.
This is not a dump. It is a log.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-18 11:19 UTC (permalink / raw)
To: Sam Vilain
Cc: Junio C Hamano, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <46EF9687.6070304@vilain.net>
On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> I think that writing a real fast-forward merge should only happen on
> dcommit, not git merge, because that is what is required for SVN.
I don't think git-svn has any way of knowing that the user wanted a
merge, unless a merge commit is present. So the user would have to
specify the set of commits which should be considered a merge during
dcommit (this would actually resemble how merges are performed in
subversion).
Sidenote: this might be slightly controversial, but I've sometimes
missed a --no-ff option to 'git merge' when working on plain git
repositories; IMHO preserving the 'logical' merge history when the
merge of a topic branch results in a fast-forward can be interesting.
--
larsh
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Johannes Schindelin @ 2007-09-18 11:18 UTC (permalink / raw)
To: Jeff King; +Cc: Andreas Ericsson, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <20070918103051.GA22239@coredump.intra.peff.net>
Hi,
On Tue, 18 Sep 2007, Jeff King wrote:
> I think he means a dump that you can meaningfully edit with sed or a
> text editor. And even nicer, one that could be fed back into
> git-fast-import. So you could do something like:
>
> git-fast-export A..B >dump
> vi dump
> git-fast-import <dump
>
> to rewrite history in a very flexible way.
Exactly what I meant. Some people seem to have problems with
filter-branch, but somehow no proper bug report, let alone fix, evolved
from that.
I guess these people are more comfortable with what you just described.
Ciao,
Dscho
^ permalink raw reply
* Re: diffcore-rename performance mode
From: Johannes Schindelin @ 2007-09-18 11:20 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20070918085413.GA11751@coredump.intra.peff.net>
Hi,
On Tue, 18 Sep 2007, Jeff King wrote:
> On Tue, Sep 18, 2007 at 01:49:50AM -0700, Junio C Hamano wrote:
>
> > > However, keeping around _just_ the cnt_data caused only about 100M
> > > of extra memory consumption (and gave the same performance boost).
> >
> > That would be an interesting and relatively low-hanging optimization.
>
> OK, I will work up a patch. Is it worth making it configurable?
Yes, I think it would be worth making it configurable... For example, one
of the machines I work on has only 128M.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Andreas Ericsson @ 2007-09-18 11:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0709181217200.28586@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Sep 2007, Jeff King wrote:
>
>> I think he means a dump that you can meaningfully edit with sed or a
>> text editor. And even nicer, one that could be fed back into
>> git-fast-import. So you could do something like:
>>
>> git-fast-export A..B >dump
>> vi dump
>> git-fast-import <dump
>>
>> to rewrite history in a very flexible way.
>
> Exactly what I meant. Some people seem to have problems with
> filter-branch, but somehow no proper bug report, let alone fix, evolved
> from that.
>
The main problem is that it in my use-cases fixes a nuisance, but not a
real problem, while the man-page SYNOPSIS consists of a full 5 lines, most
of which are far from obvious at a first glance. The seeming effort involved
just doesn't seem worth bothering with.
> I guess these people are more comfortable with what you just described.
>
I know I would be, especially since all changes would show up in an entirely
different repo. I know filter-branch is probably completely safe, but even a
0.1% risk of losing *anything* isn't worth taking to fix a small nuisance.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: commit summary, --pretty=short and other tools
From: Wincent Colaiuta @ 2007-09-18 11:43 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Johannes Schindelin, Andreas Ericsson, Mike Hommey, git
In-Reply-To: <CEE6032F-39FB-42D8-A57A-671E4E0875C7@lrde.epita.fr>
El 18/9/2007, a las 12:27, Benoit SIGOURE escribió:
> OK, look, I think this is the typical case where there is no single
> solution to fit all use cases.
> To handle this specific case, you could say "OK let's stop at
> punctuation symbols then". But what if my commit message is "Add
> namespace::member whatever."
Uh, I don't think you'd stop a punctuation symbol unless it was the
last non-whitespace character before the newline.
Even then, as Johannes says, "oneline" is only meant as a hint
anyway, so it doesn't really matter that much.
Wincent
^ permalink raw reply
* Re: [PATCH] git-send-email: Add a --cc-nobody option
From: Andreas Ericsson @ 2007-09-18 11:49 UTC (permalink / raw)
To: felipebalbi; +Cc: git, Felipe Balbi
In-Reply-To: <11901157221792-git-send-email-felipebalbi@users.sourceforge.net>
felipebalbi@users.sourceforge.net wrote:
> From: Felipe Balbi <felipe.lima@indt.org.br>
>
> This patch adds a --cc-nobody option to avoid sending emails
> to everybody but the ones listed by --to option.
>
Sounds much better than --suppress-all. Thanks
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Sam Vilain @ 2007-09-18 11:50 UTC (permalink / raw)
To: Lars Hjemli
Cc: Junio C Hamano, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <8c5c35580709180419i4500a2d4s8a997d45dd31944e@mail.gmail.com>
Lars Hjemli wrote:
> On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
>
>> I think that writing a real fast-forward merge should only happen on
>> dcommit, not git merge, because that is what is required for SVN.
>>
>
> I don't think git-svn has any way of knowing that the user wanted a
> merge, unless a merge commit is present. So the user would have to
> specify the set of commits which should be considered a merge during
> dcommit (this would actually resemble how merges are performed in
> subversion).
>
Sure it can. If you're committing to branch X, and the current tree has
a whole lot of commits above that, then it should do the only thing you
can do with SVN.
Which is write a squash commit, and set the "svn:merge" and/or
"svk:merge" properties to represent what happened.
> Sidenote: this might be slightly controversial, but I've sometimes
> missed a --no-ff option to 'git merge' when working on plain git
> repositories; IMHO preserving the 'logical' merge history when the
> merge of a topic branch results in a fast-forward can be interesting.
If you really want one, use git commit-tree directly.
Sam.
^ permalink raw reply
* Re: [PATCH] git-send-email: Add a --cc-nobody option
From: Felipe Balbi @ 2007-09-18 11:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Felipe Balbi
In-Reply-To: <46EFBB5A.7090505@op5.se>
On 9/18/07, Andreas Ericsson <ae@op5.se> wrote:
> felipebalbi@users.sourceforge.net wrote:
> > From: Felipe Balbi <felipe.lima@indt.org.br>
> >
> > This patch adds a --cc-nobody option to avoid sending emails
> > to everybody but the ones listed by --to option.
> >
>
> Sounds much better than --suppress-all. Thanks
Yeah, sure...
np :-)
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
>
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Sam Vilain @ 2007-09-18 11:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Andreas Ericsson, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0709181217200.28586@racer.site>
Johannes Schindelin wrote:
>> I think he means a dump that you can meaningfully edit with sed or a
>> text editor. And even nicer, one that could be fed back into
>> git-fast-import. So you could do something like:
>>
>> git-fast-export A..B >dump
>> vi dump
>> git-fast-import <dump
>>
>> to rewrite history in a very flexible way.
>>
>
> Exactly what I meant. Some people seem to have problems with
> filter-branch, but somehow no proper bug report, let alone fix, evolved
> from that.
>
> I guess these people are more comfortable with what you just described.
>
Guilty. my own filter-branch supports things like custom re-ordering of
commits prior to rewriting (eg, if you need to refer to one commit to
another in a commit message, you better make sure it happens in the
right order).
I personally want to be able to dump patches, including merges, to
git-format-patch format, in such a way that all other information (eg,
committer, date, etc) is preserved. And probably using something akin to
Message-Id: headers for a "patch UUID" which is what you need when
you're working with piles of patches like that.
Sam.
^ permalink raw reply
* Re: [PATCH] Mention that 'push .. master' is in explicit form master:refs/heads/master
From: Johannes Schindelin @ 2007-09-18 12:01 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <wsuomgyu.fsf@blue.sea.net>
Hi,
On Tue, 18 Sep 2007, Jari Aalto wrote:
> [no meaningful commit message]
Your patch is wrong. Try "git push origin <some-tag>". Works like a
charm, without starting a new branch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-18 12:03 UTC (permalink / raw)
To: Sam Vilain
Cc: Junio C Hamano, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <46EFBB9A.5070404@vilain.net>
[...sorry for making this such a long thread...]
On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> Lars Hjemli wrote:
> > On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> >
> >> I think that writing a real fast-forward merge should only happen on
> >> dcommit, not git merge, because that is what is required for SVN.
> >>
> >
> > I don't think git-svn has any way of knowing that the user wanted a
> > merge, unless a merge commit is present. So the user would have to
> > specify the set of commits which should be considered a merge during
> > dcommit (this would actually resemble how merges are performed in
> > subversion).
> >
>
> Sure it can. If you're committing to branch X, and the current tree has
> a whole lot of commits above that, then it should do the only thing you
> can do with SVN.
>
> Which is write a squash commit, and set the "svn:merge" and/or
> "svk:merge" properties to represent what happened.
I often have prepared a series of local commits which I _want_ to
preserve as different subversion revisions.
Also, doing a --squash means that I loose the merge history in git
(and then I need to edit the grafts file again)
>
> > Sidenote: this might be slightly controversial, but I've sometimes
> > missed a --no-ff option to 'git merge' when working on plain git
> > repositories; IMHO preserving the 'logical' merge history when the
> > merge of a topic branch results in a fast-forward can be interesting.
>
> If you really want one, use git commit-tree directly.
Yeah, that's an option, but --no-ff is somewhat less work ;-)
--
larsh
^ permalink raw reply
* Re: [rfc] git submodules howto
From: Johannes Schindelin @ 2007-09-18 12:03 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20070918105538.GL19019@genesis.frugalware.org>
Hi,
On Tue, 18 Sep 2007, Miklos Vajna wrote:
> i saw several "is there any step by step howto on how to use git
> submodules?" question on irc, and as far as i think there is none
> available at the moment
AFAICT there is one, on the git Wiki, since yesterday.
Ciao,
Dscho
^ permalink raw reply
* Re: [rfc] git submodules howto
From: Michael Smith @ 2007-09-18 12:10 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20070918105538.GL19019@genesis.frugalware.org>
On Tue, 18 Sep 2007, Miklos Vajna wrote:
> 1) is this correct? :) i use it and it seem to do what i except, but
> maybe it's not correct
Hi Miklos,
I had the same question, but you and I are both using it in a similar way
so that's encouraging.
I put something in the Wiki the other day.
http://git.or.cz/gitwiki/GitSubmoduleTutorial
Mike
^ permalink raw reply
* [PATCH] instaweb: added support Ruby's WEBrick server
From: mike dalessio @ 2007-09-18 12:16 UTC (permalink / raw)
To: git, mike, normalperson
running the webrick server with git requires Ruby and Ruby's YAML and
Webrick libraries (both of which come standard with Ruby). nice for
single-user standalone invocations.
the --httpd=webrick option generates a ruby script on the fly to read
httpd.conf options and invoke the web server via library call. this
script is placed in the .git/gitweb directory. it also generates a
shell script in a feeble attempt to invoke ruby in a portable manner,
which assumes that 'ruby' is in the user's $PATH.
Signed-off-by: Mike Dalessio <mike@csa.net>
---
Documentation/git-instaweb.txt | 3 +-
git-instaweb.sh | 44 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
index cec60ee..914fc4c 100644
--- a/Documentation/git-instaweb.txt
+++ b/Documentation/git-instaweb.txt
@@ -27,7 +27,8 @@ OPTIONS
The HTTP daemon command-line that will be executed.
Command-line options may be specified here, and the
configuration file will be added at the end of the command-line.
- Currently, lighttpd and apache2 are the only supported servers.
+ Currently, lighttpd, apache2 and webrick are the only supported
+ servers.
(Default: lighttpd)
-m|--module-path::
diff --git a/git-instaweb.sh b/git-instaweb.sh
index b79c6b6..803a754 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -37,7 +37,9 @@ start_httpd () {
else
# many httpds are installed in /usr/sbin or /usr/local/sbin
# these days and those are not in most users $PATHs
- for i in /usr/local/sbin /usr/sbin
+ # in addition, we may have generated a server script
+ # in $fqgitdir/gitweb.
+ for i in /usr/local/sbin /usr/sbin $fqgitdir/gitweb
do
if test -x "$i/$httpd_only"
then
@@ -137,6 +139,43 @@ GIT_DIR="$fqgitdir"
export GIT_EXEC_PATH GIT_DIR
+webrick_conf () {
+ # generate a standalone server script in $fqgitdir/gitweb.
+ cat > "$fqgitdir/gitweb/$httpd.rb" <<EOF
+require 'webrick'
+require 'yaml'
+options = YAML::load_file(ARGV[0])
+options[:StartCallback] = proc do
+ File.open(options[:PidFile],"w") do |f|
+ f.puts Process.pid
+ end
+end
+options[:ServerType] = WEBrick::Daemon
+server = WEBrick::HTTPServer.new(options)
+['INT', 'TERM'].each do |signal|
+ trap(signal) {server.shutdown}
+end
+server.start
+EOF
+ # generate a shell script to invoke the above ruby script,
+ # which assumes _ruby_ is in the user's $PATH. that's _one_
+ # portable way to run ruby, which could be installed anywhere,
+ # really.
+ cat > "$fqgitdir/gitweb/$httpd" <<EOF
+#! /bin/sh
+ruby $fqgitdir/gitweb/$httpd.rb \$*
+EOF
+ chmod +x "$fqgitdir/gitweb/$httpd"
+
+ cat > "$conf" <<EOF
+:Port: $port
+:DocumentRoot: "$fqgitdir/gitweb"
+:DirectoryIndex: ["gitweb.cgi"]
+:PidFile: "$fqgitdir/pid"
+EOF
+ test "$local" = true && echo ':BindAddress: "127.0.0.1"' >> "$conf"
+}
+
lighttpd_conf () {
cat > "$conf" <<EOF
server.document-root = "$fqgitdir/gitweb"
@@ -237,6 +276,9 @@ case "$httpd" in
*apache2*)
apache2_conf
;;
+webrick)
+ webrick_conf
+ ;;
*)
echo "Unknown httpd specified: $httpd"
exit 1
--
1.5.2.5
^ 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