contrib/ area

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.

Junio C Hamano <junkio@cox.net> 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.

On 2/18/06, Alexandre Julliard <julliard@winehq.org> wrote:

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

Alexandre Julliard <julliard@winehq.org> writes:

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)...

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

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 wrote:

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

Sam.

Sam Vilain <sam@vilain.net> writes:

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.

On 2/17/06, Junio C Hamano <junkio@cox.net> wrote:

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

-aneesh

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

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

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

On 2/18/06, Junio C Hamano <junkio@cox.net> wrote:

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

-aneesh

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

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

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>

	---
	...

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

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

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.

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...

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,