contrib/ area

contrib/ area

[Junio C Hamano]

As some of you may be aware, I've added contrib/ area to git.git
repository.  Currently there are git-svn from Eric and gitview
from Aneesh.

The intention is to keep interesting tools around git, maybe
even experimental ones, to give users an easier access to them,
and to give tools wider exposure, so that they can be improved
faster.

I am expecting not to touch them myself that much.  As far as my
day-to-day operation is concerned, contrib/git-svn is owned by
Eric and contrib/gitview by Aneesh.  I am willing to help if
users of these components and the contrib/ subtree "owners" have
technical/design issues to resolve, but the initiative to fix
and/or enhance things _must_ be on the side of the subtree
owners.  IOW, I won't be actively looking for bugs and rooms for
enhancements in them as the git maintainer -- I may only do so
just as one of the users when I want to scratch my own itch.  If
you have patches to things in contrib/ area, the patch should be
first sent to the primary author, and then the primary author
should ack and forward it to me (git pull request is nicer).
This is the same way as how I treated gitk, so you know the
drill.

I expect that things that start their life in the contrib/ area
to graduate out of contrib/ once they mature, either by becoming
projects on their own, or moving to the toplevel directory.  On
the other hand, I expect I'll be proposing removal of disused
and inactive ones from time to time.

By the way, I have to admit that merging these two were a bit
painful for me.  They came as text attachments to e-mail
messages, and I ended up hand committing with --author flag,
while fixing up whitespaces in them [*1*].  I do not want to do
that again.  So if you have new things to add to the contrib/
area, please first propose it on the list, and after a list
discussion proves there are some general interests (it does not
have to be a list-wide consensus for a tool targeted to a
relatively narrow audience -- for example I do not work with
projects whose upstream is svn, so I have no use for git-svn
myself), submit a patch to create a subdirectory of contrib/ and
put your stuff there.

One final request to Aneesh.  Could you send a patch to add a
bit of blurb and introductory text in contrib/gitview/README,
please?  As it stands, it would be hard to get as much exposure
as we had hoped by just having it in git.git repository.

[Footnote]

*1* I _am_ picky about whitespaces, and I would encourage people
to enable the pre-commit example hook.

Re: contrib/ area

[Alexandre Julliard]

Junio C Hamano <junkio@cox.net> writes:

> By the way, I have to admit that merging these two were a bit
> painful for me.  They came as text attachments to e-mail
> messages, and I ended up hand committing with --author flag,
> while fixing up whitespaces in them [*1*].  I do not want to do
> that again.  So if you have new things to add to the contrib/
> area, please first propose it on the list, and after a list
> discussion proves there are some general interests (it does not
> have to be a list-wide consensus for a tool targeted to a
> relatively narrow audience -- for example I do not work with
> projects whose upstream is svn, so I have no use for git-svn
> myself), submit a patch to create a subdirectory of contrib/ and
> put your stuff there.

Is there interest in an emacs interface for git?  I posted a first
version (http://marc.theaimsgroup.com/?l=git&m=113313040724346&w=2)
some time ago, I'd be happy to send you a patch with my latest version
if you want to include it.

-- 
Alexandre Julliard
julliard@winehq.org

Re: contrib/ area

[Martin Langhoff]

On 2/18/06, Alexandre Julliard <julliard@winehq.org> wrote:
> Is there interest in an emacs interface for git?  I posted a first
> version (http://marc.theaimsgroup.com/?l=git&m=113313040724346&w=2)
> some time ago, I'd be happy to send you a patch with my latest version
> if you want to include it.

Yes, please. I'd really like to see it help handle conflicts, and
provide multi-pane views during merges. We are in love with emacs diff
mode for conflict resolution when you end up with .rej files, but it
doesn't kick in properly with the inline conflict markers :-(

cheers,


m

Re: contrib/ area

[Junio C Hamano]

Alexandre Julliard <julliard@winehq.org> writes:

> Is there interest in an emacs interface for git?  I posted a first
> version (http://marc.theaimsgroup.com/?l=git&m=113313040724346&w=2)
> some time ago, I'd be happy to send you a patch with my latest version
> if you want to include it.

Martin already said he wants it, and I would second that.  VC
backend is one of the things I kept in the TODO list for quite a
while (I think since early September 2005)...

Re: contrib/ area

[Alexandre Julliard]

Junio C Hamano <junkio@cox.net> writes:

> Alexandre Julliard <julliard@winehq.org> writes:
>
>> Is there interest in an emacs interface for git?  I posted a first
>> version (http://marc.theaimsgroup.com/?l=git&m=113313040724346&w=2)
>> some time ago, I'd be happy to send you a patch with my latest version
>> if you want to include it.
>
> Martin already said he wants it, and I would second that.  VC
> backend is one of the things I kept in the TODO list for quite a
> while (I think since early September 2005)...

Actually the interface I wrote (patch in separate mail) is not an
emacs VC backend, it's a project tree browser similar to pcl-cvs. It's
IMO a much better fit to the git philosophy than the per-file VC
hooks. But I'm planning to add VC backend support eventually...

-- 
Alexandre Julliard
julliard@winehq.org

Re: contrib/ area

[Sam Vilain]

Alexandre Julliard wrote:
> Is there interest in an emacs interface for git?  I posted a first
> version (http://marc.theaimsgroup.com/?l=git&m=113313040724346&w=2)
> some time ago, I'd be happy to send you a patch with my latest version
> if you want to include it.

Out of interest, why did you choose not to make this a vc- plug-in?

Sam.

Re: contrib/ area

[Alexandre Julliard]

Sam Vilain <sam@vilain.net> writes:

> Alexandre Julliard wrote:
>> Is there interest in an emacs interface for git?  I posted a first
>> version (http://marc.theaimsgroup.com/?l=git&m=113313040724346&w=2)
>> some time ago, I'd be happy to send you a patch with my latest version
>> if you want to include it.
>
> Out of interest, why did you choose not to make this a vc- plug-in?

For the same reason that there are both vc-cvs and pcl-cvs modes, they
are completely different approaches to the user interface. The VC mode
is purely file-oriented, and is very limited in its ability to handle
project-wide changes. It has its uses, but IMO there's no way to
exploit the full capabilities of a tool like git (or even CVS) with
the VC interface.

-- 
Alexandre Julliard
julliard@winehq.org

Re: contrib/ area

[Aneesh Kumar]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

On 2/17/06, Junio C Hamano <junkio@cox.net> wrote:
>
>
> One final request to Aneesh.  Could you send a patch to add a
> bit of blurb and introductory text in contrib/gitview/README,
> please?  As it stands, it would be hard to get as much exposure
> as we had hoped by just having it in git.git repository.
>


Attaching below the same in the form of patch generated by git format-patch

-aneesh

[-- Attachment #2: 0001-Add-a-README-for-gitview.txt --]
[-- Type: text/plain, Size: 1296 bytes --]

From nobody Mon Sep 17 00:00:00 2001
From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Date: Fri Feb 17 18:18:36 2006 +0530
Subject: Add a README for gitview

---

 contrib/gitview/gitview.txt |   38 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 38 insertions(+), 0 deletions(-)
 create mode 100644 contrib/gitview/gitview.txt

36acfaffcbb86bb4c8d2634ea84306a451a9c19b
diff --git a/contrib/gitview/gitview.txt b/contrib/gitview/gitview.txt
new file mode 100644
index 0000000..171295a
--- /dev/null
+++ b/contrib/gitview/gitview.txt
@@ -0,0 +1,38 @@
+gitview(1)
+==========
+
+NAME
+----
+gitview - A GTK based repository browser for git
+
+SYNOPSIS
+--------
+'gitview'  [options] [args]
+
+DESCRIPTION
+---------
+
+Dependencies
+
+* Python 2.4
+* PyGTK 2.8 or later
+* PyCairo 1.0 or later
+
+OPTIONS
+------
+	--without-diff
+		If the user doesn't want to list the commit diffs in the main window. This may speed up the repository browsing.
+
+	<args>
+		All the valid option for git-rev-list(1)
+
+EXAMPLES
+------
+	gitview v2.6.12.. include/scsi drivers/scsi
+	  Show as the changes since version v2.6.12 that changed any file in the include/scsi
+	  or drivers/scsi subdirectories
+
+	gitk --since=2.weeks.ago
+	  Show the changes during the last two weeks 
+
+	
-- 
1.2.0-dirty

Re: contrib/ area

[Junio C Hamano]

Aneesh Kumar <aneesh.kumar@gmail.com> writes:

> Attaching below the same in the form of patch generated by git format-patch

I'll let it pass this time, but you forgot a sign-off and
perhaps forgot to read Documentation/SubmittingPatches ;-).

Re: contrib/ area

[Aneesh Kumar]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On 2/18/06, Junio C Hamano <junkio@cox.net> wrote:
> Aneesh Kumar <aneesh.kumar@gmail.com> writes:
>
> > Attaching below the same in the form of patch generated by git format-patch
>
> I'll let it pass this time, but you forgot a sign-off and
> perhaps forgot to read Documentation/SubmittingPatches ;-).
>
>

How about sending the patches as attachment below. I am not sure how
to inline patches in gmail.

-aneesh

[-- Attachment #2: 0001-Fix-a-typo.txt --]
[-- Type: text/plain, Size: 791 bytes --]

>From nobody Mon Sep 17 00:00:00 2001
From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Date: Sat Feb 18 13:54:50 2006 +0530
Subject: Fix a typo
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>

---

 contrib/gitview/gitview.txt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

3cca8b8cf1840cf7179ffc89ce52fe2c012beaf6
diff --git a/contrib/gitview/gitview.txt b/contrib/gitview/gitview.txt
index 171295a..fcf759c 100644
--- a/contrib/gitview/gitview.txt
+++ b/contrib/gitview/gitview.txt
@@ -32,7 +32,7 @@ EXAMPLES
 	  Show as the changes since version v2.6.12 that changed any file in the include/scsi
 	  or drivers/scsi subdirectories
 
-	gitk --since=2.weeks.ago
+	gitview --since=2.weeks.ago
 	  Show the changes during the last two weeks 
 
 	
-- 
1.2.1.g45d2-dirty

Re: contrib/ area

[Junio C Hamano]

"Aneesh Kumar" <aneesh.kumar@gmail.com> writes:

> How about sending the patches as attachment below. I am not sure how
> to inline patches in gmail.

For some reason, attachment is usually frowned upon, but if you
cannot do anything else, then at least please do _not_ hide the
commit log message in the attachment.

The short description of the patch should be on the Subject:
line.  Make sure it makes sense if your short description
appeared in "git log --pretty=short" output without the rest of
the commit log message.  "Fix a typo" is an example of bad
description -- you cannot tell typo in what part of the tree was
fixed by the commit.

And the rest of the log message, including the sign-off,
should be in the main text.  Also short administrative message
should come *after* the three-dash separators.

So, I would have done the message I am replying to like this:

***	From: "Aneesh Kumar" <aneesh.kumar@gmail.com>
	To: gitster
	cc: git@vger.kernel.org
        Subject: gitview: typofix in documentation
***	Date: Sat Feb 18 13:54:50 2006 +0530

	I forgot to change the name of the program when I copy &
	pasted.

	Signed-off-by: An Ku <an.ku@g.com>

	---

          On 2/18/06, Junio C Hamano <junkio@cox.net> wrote:
          > Aneesh Kumar <aneesh.kumar@gmail.com> writes:
          >
          > > Attaching below the same in the form of patch genera...
          >
          > I'll let it pass this time, but you forgot a sign-off ...
          > perhaps forgot to read Documentation/SubmittingPatches...
          >

          How about sending the patches as attachment below. I am not
          sure how to inline patches in gmail.

          -aneesh

	[git-diff output comes here, preferrably inline but
	 otherwise as a text/plain attachment.]

Let your MUA fill in *** lines.  You _could_ override them with
the first lines of the _body_ of your message like this if you
really need it.  Most of the time you shouldn't care.


***	From: "Aneesh Kumar" <aneesh.kumar@gmail.com>
	To: gitster
	cc: git@vger.kernel.org
        Subject: gitview: typofix in documentation
***	Date: Sat Feb 18 13:54:50 2006 +0530

	From: "An Ku" <an.ku@gmail.com>
        Date: Fri Feb 17 10:00:00 2006 +0530

	I forgot to change the name of the program when I copy &
	pasted.

	Signed-off-by: An Ku <an.ku@g.com>

	---
	...

Re: contrib/ area

[Ben Clifford]

> As some of you may be aware, I've added contrib/ area to git.git
> repository.  Currently there are git-svn from Eric and gitview
> from Aneesh.
>
> The intention is to keep interesting tools around git, maybe
> even experimental ones, to give users an easier access to them,
> and to give tools wider exposure, so that they can be improved
> faster.

I have been keeping some (lazily-maintained) bash completion code at:

http://www.hawaga.org.uk/ben/tech/gitcompletion/

It isn't clear to me whether it should stay there or be merged into 
git/contrib/.

Cogito has the cogito bits of the above already included.

Stg doesn't.

The path of least resistence for me is to keep it at the above 
hawaga.org.uk URL, but it may be that some people would prefer it in the 
main repos.

Ben

-- 

Re: contrib/ area

[Junio C Hamano]

Ben Clifford <benc@hawaga.org.uk> writes:

> I have been keeping some (lazily-maintained) bash completion code at:
>
> http://www.hawaga.org.uk/ben/tech/gitcompletion/
>
> It isn't clear to me whether it should stay there or be merged into
> git/contrib/.
> ...
> The path of least resistence for me is to keep it at the above
> hawaga.org.uk URL, but it may be that some people would prefer it in
> the main repos.

I am OK either way.  They are small enough to be in contrib/
area, and bash users may appreciate easier availability.  What I
would _refuse_ to do is to maintain code for other people ;-).
As long as you or somebody else is going to keep them updated as
needed, I do not mind carrying them in contrib/.

As a practice for doing "even cooler merge", I did the
following, to see if I can treat it just like I treat gitk.

    (1) give you a topic branch.
    $ git checkout -b bc/completion master

    (2) fetch your tip
    $ git fetch http://www.hawaga.org.uk/gitcompletion.git/

    (3) for a practice of a later "renaming" merge, pretend you were
        one rev behind than you actually are.
    $ COMMIT=`git rev-parse FETCH_HEAD^`

    (4) extract things under contrib/completion/
    $ git read-tree $COMMIT
    $ git checkout-index --prefix=contrib/completion/ -a

    (5) throw the index away, and add the files back into the real index.
    $ git reset
    $ git add contrib/completion

    (6) write the result of "even cooler merge" out, with a merge
        commit message:
    $ T=`git-write-tree`
    $ sed -e 's/^[0-9a-f]*/'$COMMIT/ <.git/FETCH_HEAD |
      git-fmt-merge-msg |
      git commit-tree $T -p `git rev-parse HEAD` -p $COMMIT

    (7) a practice of later merge
    $ git pull -s recursive http://www.hawaga.org.uk/gitcompletion.git/

The result is sitting at the tip of "pu" branch.

Re: contrib/ area

[Petr Baudis]

Dear diary, on Tue, Feb 21, 2006 at 06:10:05AM CET, I got a letter
where Ben Clifford <benc@hawaga.org.uk> said that...
> > As a practice for doing "even cooler merge", I did the
> > following, to see if I can treat it just like I treat gitk.
> 
> neat.
> 
> one thing that bothers me a bit about that is that the cogito code
> then ends up in both the git and cogito repositories (actually the way
> its done manually for cogito contrib/ at the moment bothers me
> anyway).

Well, in the long term, Jonas is working on a bash completion generated
automagically from the cg sources (anything maintained externally is bad
'coz it gets out of sync, mm'kay? ;).

In the short term, I can just accept patches from you - they do not even
need to get the filenames right, I can rewrite that.  You see, I don't
have the cool recursive merge strategy so merging into a subdirectory is
painful (and that bothers me too; we'll see yet).

Thanks,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams