* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Jakub Narebski @ 2008-07-20 22:29 UTC (permalink / raw)
To: git
Cc: Sam Vilain, Joshua Roys, Sverre Rabbelier, Sverre Rabbelier,
David Symonds, Lea Wiemann, John Hawley, Marek Zawirski,
Shawn O. Pearce, Miklos Vajna, Johannes Schindelin, Stephan Beyer,
Christian Couder, Daniel Barkalow
In-Reply-To: <200807080227.43515.jnareb@gmail.com>
On Tue, 8 July 2008, Jakub Narebski wrote:
> I'd very much like to have (or perhaps to wrote) some sort of interim
> progress report for Google Summer of Code 2008 projects on
> http://git.or.cz/gitwiki/SoC2008Projects. Therefore I'd like you to
> expand and/or correct those mini-summaries below.
Here is a bit late summary of this thread (and of information gathered
elsewhere). I'll try to add this information to wiki page in approx
two days from now... of course unless project student or mentor wouldn't
do it first.
1. GitTorrent
Student: Joshua Roys
Mentor: Sam Vilain
I never got more response than "it is going slower than I would like,
[...] Other than that, it's going well, I think." from Joshua Roys.
Mailing list archives for gittorrent mailing list doesn't show anything
interesting, either (last post is from 2007).
http://lists.utsl.gen.nz/pipermail/gittorrent/
Besides canonical repository gitweb
http://utsl.gen.nz/gitweb/?p=VCS-Git-Torrent
there is also mirror at
http://repo.or.cz/w/VCS-Git-Torrent.git
There is some activity there... but no summary of it anywhere I could
find. (I wonder if this was the project Johannes and Shawn were talking
about of "going dark" in GSoC 2008 podcast 018...)
2. git-statistics
Student: Sverre Rabbelier
Mentor: David Symonds
There were some posts about how git-statistics can be used:
http://thread.gmane.org/gmane.comp.version-control.git/81534
http://thread.gmane.org/gmane.comp.version-control.git/82027
There is post with link to different git.git statictics:
"[GitStats] Bling bling or some statistics on the git.git repository"
http://thread.gmane.org/gmane.comp.version-control.git/88174
A short listing of metrics done:
* stats.py author -d: Shows file activity of a specific developer
measured in how often they made a modification to a file and total
lines added/removed (much like a diffstat, but now for a specific
developer instead of one commit).
* stats.py author -f: Shows file activity of a specific file measured
in how often they made a modification to a file, could be extended to
also count changes like "author -d"
* stats.py branch -b: Shows which branch a specific file belongs to,
for more information on this metric see below
* stats.py commit -v: Shows all commits that are reverted by the
specified commit, will be extended to allow detection of partial
reverts
* stats.py diff -e: Shows whether two specific commits introduce the
same changes
* stats.py diff -e -n: ditto, but ignores what changes were made, only
looks at the changed lines
* stats.py diff -e -i: ditto, but inverts the comparison, instead of
comparing addition with addition and deletions with deletions, the
additions of the first diff are compared with the deletions of the
second diff, and vise versa. This way a revert is easily detected.
* stats.py index -t: Shows which commits touched the same paths as the
staged changes
3. Gitweb caching
Student: Lea Wiemann
Mentor: John 'warthog' Hawley
Lea has chosen caching data and memcached as example (primary) caching
engine, wrote Git::Repo object-oriented Perl interface to git, used
it in gitweb, and added caching to gitweb.
Additionally tests for old Git.pm (simple), Git::Repo and friends, and
Mechanize based gitweb test were added. Mechanize tests detected a few
bugs in current gitweb code: using Git::Repo and adding caching didn't
create any new errors.
Currently first round of patches were send, and second version
incorporating comments from is in progress. There is a test site
(live demo) up and running on one of the kernel.org machines:
http://odin3.kernel.org/git-lewiemann/
You can find first version of patches in 'pu' branch.
4. Eclipse plugin push support
Student: Marek Zawirski
Mentor: Shawn O. Pearce
Thus far Marek has completed generation of packs, including delta
re-use from packs using either v1 or v2 index, including taking
advantage of the CRC inside the v2 index to accelerate a safe reuse.
This code permits jgit to write a valid pack.
The packing code does not (yet) search for a delta base, or create
a new delta for an undeltified object. Packing loose objects packs
them as whole objects in the pack file, resulting in little to no
reduction over their loose object size. This is not a limitation
of Java. Marek and I simply decided that protocol support was more
important than really tight network transport at this point in time.
As a result of being able to create pack files Marek was able to
implement the client side of git-push for the native pack transfer
service, aka push over SSH, push to another local repository (by
forking 'git receive-pack') and push over anonymous git://.
Using Marek's pack generation code Shawn added support for push over
the dumb sftp:// and amazon-s3:// protocols, with the latter also
supporting transparent client side encryption.
5. git-merge builtin
Student: Miklos Vajna
Mentor: Johannes Schindelin
> In "What's cooking in git.git (topics)" Junio C Hamano wrote:
>
> It already is beginning to become clear what 1.6.0 will look like.
> [...]
> * git-merge will be rewritten in C.
It is already in git as 1c7b76b (Build in merge).
In Documentation/RelNotes-1.6.0.txt you can find the following:
"* git-merge has been reimplemented in C."
6. git-sequencer
Student: Stephan Beyer
Mentor: Christian Couder, Daniel Barkalow
It started with discussion over TODO file format:
http://thread.gmane.org/gmane.comp.version-control.git/84230
Now there is prototype shell script implementation (which has some
limitations because it is prototype) in "git sequencer prototype"
http://thread.gmane.org/gmane.comp.version-control.git/86985
http://thread.gmane.org/gmane.comp.version-control.git/88754
The latter thread includes migration of git-am, git-rebase, and
interactive rebase to sequencer.
> Stephan Beyer wrote:
> I'm using sequencer-based git-am and git-rebase-i and also
> git-sequencer itself for around 2-3 weeks now. So, for me, it is
> reality-proven [...]
There were some problems with sequencer based implementation of
"git am --rebasing", or sequencer based patch application driven
ordinary rebase, but I think there were resolved.
Stephen have started the builtin sequencer (but till now no patches
were sent to list: seems to be work in progress).
Some performance benchmarks:
* applying 45 patches with git-am
- 3 seconds using the original
- 8 seconds using the (scripted) sequencer-based one
* rebasing 100 commits
- 4.8 seconds using the original
- 10.1 seconds using the (scripted) sequencer-based one
- 1.7 seconds using builtin sequencer
SUMMARY:
========
From those projects, "git-merge builtin" did what it was meant to do
already. "Eclipse plugin push support" and "git-statistics" did
minimum what it was meant to do already, and it looks like it would be
finished before August 11. "Gitweb caching" is after first round of
patches, "git-sequencer" looks like already done; I don't know what is
the state of "GitTorrent" project.
Please correct any mistakes in this summary / writeup. Thanks in
advance.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-shell needs $(COMPAT_OBJS)
From: Johannes Schindelin @ 2008-07-20 22:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vzloc2odx.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 20 Jul 2008, Junio C Hamano wrote:
> Why do we care about the size of git-shell so much in the first place
> anyway to begin with?
It was not me who proposed it, but I guess it was for auditing purposes:
git-shell is often the only point of entry for certain untrusted ssh
users, and the less code is linked, the less code has to be analyzed for
reachability (and then for security holes).
Ciao,
Dscho
^ permalink raw reply
* Re: Git Branding Overview, Re: Git.or.cz Experimental Design
From: Petr Baudis @ 2008-07-20 22:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Baldwin, git
In-Reply-To: <m3od4sw7qj.fsf@localhost.localdomain>
On Sun, Jul 20, 2008 at 02:44:54PM -0700, Jakub Narebski wrote:
> P.P.S. Petr, do you know what's the matter with Git Wiki? It looks
> like moin4wiki (Wikipeda-like syntax) parser is installed halfway in.
As I try to mention frequently, I don't really maintain the Wiki at all.
The Wikipedia syntax is a manual hack that has a weird history across
random moinwiki upgrade on the machine, randomly disappearing as Debian
decides to upgrade the moinwiki package. I have readded the hack now.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] git-shell needs $(COMPAT_OBJS)
From: Junio C Hamano @ 2008-07-20 22:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0807210034050.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 20 Jul 2008, Junio C Hamano wrote:
>
>> Why do we care about the size of git-shell so much in the first place
>> anyway to begin with?
>
> It was not me who proposed it, but I guess it was for auditing purposes:
> git-shell is often the only point of entry for certain untrusted ssh
> users, and the less code is linked, the less code has to be analyzed for
> reachability (and then for security holes).
That's a rather misguided approach, isn't it?
After all, the work requested by the end user will be handled by code in
the main git executable by spawning a subprocess, and you are auditing the
codepath that leads to the spawning anyway.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Petr Baudis @ 2008-07-20 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3am5iae8.fsf@gitster.siamese.dyndns.org>
On Sat, Jul 19, 2008 at 06:58:55PM -0700, Junio C Hamano wrote:
> * pb/submodule (Wed Jul 16 21:11:40 2008 +0200) 7 commits
> . t7403: Submodule git mv, git rm testsuite
> . git rm: Support for removing submodules
> . git mv: Support moving submodules
> . submodule.*: Introduce simple C interface for submodule lookup by
> path
> . git submodule add: Fix naming clash handling
> . t7400: Add short "git submodule add" testsuite
> . git-mv: Remove dead code branch
>
> Long overdue usability improvement series for submodule. Very much
> welcomed. It would be nice to have some submodule improvements in 1.6.0,
> but it would take us a few more rounds to hit 'next' with this, and it
> will not be in 'master' when 1.6.0 ships.
Do you think this would create serious problems?
One thing this patch series depends on now is changing the git mv
semantics in a rather non-trivial way, which is something we might want
to do in a major release instead of within the 1.6 series.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Sverre Rabbelier @ 2008-07-20 22:43 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Sam Vilain, Joshua Roys, David Symonds, Lea Wiemann,
John Hawley, Marek Zawirski, Shawn O. Pearce, Miklos Vajna,
Johannes Schindelin, Stephan Beyer, Christian Couder,
Daniel Barkalow
In-Reply-To: <200807210029.31543.jnareb@gmail.com>
On Mon, Jul 21, 2008 at 12:29 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Here is a bit late summary of this thread (and of information gathered
> elsewhere). I'll try to add this information to wiki page in approx
> two days from now... of course unless project student or mentor wouldn't
> do it first.
I've been feeling guilty about not writing a summary yet, sorry for that :(.
> 2. git-statistics
>
> Student: Sverre Rabbelier
> Mentor: David Symonds
>
> There were some posts about how git-statistics can be used:
> http://thread.gmane.org/gmane.comp.version-control.git/81534
> http://thread.gmane.org/gmane.comp.version-control.git/82027
> There is post with link to different git.git statictics:
> "[GitStats] Bling bling or some statistics on the git.git repository"
> http://thread.gmane.org/gmane.comp.version-control.git/88174
>
> A short listing of metrics done:
> * stats.py author -d: Shows file activity of a specific developer
> measured in how often they made a modification to a file and total
> lines added/removed (much like a diffstat, but now for a specific
> developer instead of one commit).
> * stats.py author -f: Shows file activity of a specific file measured
> in how often they made a modification to a file, could be extended to
> also count changes like "author -d"
* stats.py bug -t: Calculates a 'score' for a specific commit,
representing how likely it is to be a bugfix. There are four metrics
used to determine this: "Commits x reverts another commit y", "Commit
x belongs to one of the specified branches (e.g., 'maint')", "The diff
for commit x contains a specific phrase", "The msg for commit x
contains a specific phrase". A rating can be given to each metric by
the user.
* stats.py bug -a: Aggregates the 'bug -t' metric over a range of
commits. The default is the last 10 commits on HEAD. This routine is
optimized to not recalculate metrics/to not redo work that was
already done in a 'bug -t' call for another commit. As such there is a
set setup time to determine the type of the first commit, after which
calculation time increases at a much lower pace. (So 'bug -a' on 10
commits might take 4 seconds, and running it over 11 commits might
take only 4.5".)
> * stats.py branch -b: Shows which branch a specific file belongs to,
a commit 'belongs to' a branch when the commit is made on that branch.
> * stats.py commit -v: Shows all commits that are reverted by the
> specified commit, will be extended to allow detection of partial
> reverts
This has been moved to 'diff -r'.
> * stats.py diff -e: Shows whether two specific commits introduce the
> same changes
> * stats.py diff -e -n: ditto, but ignores what changes were made, only
> looks at the changed lines
> * stats.py diff -e -i: ditto, but inverts the comparison, instead of
> comparing addition with addition and deletions with deletions, the
> additions of the first diff are compared with the deletions of the
> second diff, and vise versa. This way a revert is easily detected.
> * stats.py index -t: Shows which commits touched the same paths as the
> staged changes
I think the rest is a nice summary of what I've been doing :).
> SUMMARY:
> ========
> [...] "git-statistics" did a minimum what it was meant to do already, and it looks like it would be finished before August 11. [..]
My deadline is August 1 since my vacation starts then and I can't work
during my vacation (all hail American tax laws), but David is
confident that I will have a finished product before then, and I plan
not to let him down on that expectation.
> Please correct any mistakes in this summary / writeup.
I tried to as best as I could :).
> Thanks in advance.
No, thank you! Thanks for writing up this summary, very nicely done.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Sverre Rabbelier @ 2008-07-20 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vsku44679.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 11:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I could make "What's cooking" not a follow-up to the previous issue, or
> perhaps add "(volume 1.6.0, issue 28)" at the end of the Subject.
The downside of this is that it'll be less easy to see the difference
with the previous version. GMail tries to mark text that appeared a
previous mail in purple, so new text 'stands out' in the regular black
(it's not that good at it though).
So WRT to not making them follow ups, an improvement would be a diff
with the previous version online somewhere, although I guess the
http://tinyurl.com/todobranch is exactly that modulo your (Junio's)
comments on the topics.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] git-shell needs $(COMPAT_OBJS)
From: Junio C Hamano @ 2008-07-20 22:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <7vzloc2odx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
>> On Sonntag, 20. Juli 2008, Johannes Sixt wrote:
>>> -git-shell$X: compat/strlcpy.o abspath.o ctype.o exec_cmd.o quote.o
>>> strbuf.o usage.o wrapper.o shell.o
>>> +git-shell$X: abspath.o ctype.o
>>> exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o $(COMPAT_OBJS)
>>
>> Unfortunately, that's only half the deal. If we compile with NO_PREAD=1, this
>> needs read_in_full(),...
>
> Well, if compat/* implementations use anything outside compat/ left and
> right, then all bets are off.
If compat/ layer tries to really be about "compatibility", they should not
be using things like xmalloc() that call release_pack_meory() that is in
sha1_file.c. From a quick glance, mingw.c, mmap.c, pread.c are major
offenders, but others such as setenv.c seem to be carefully written.
Perhaps we should apply a variant of your patch to allow linking from
compat/ routines to git-shell, so that people affected by the compat layer
functions that call outside compat layer have incentive to fix them.
Makefile | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 2b670d7..551bde9 100644
--- a/Makefile
+++ b/Makefile
@@ -324,6 +324,7 @@ endif
export PERL_PATH
LIB_FILE=libgit.a
+COMPAT_LIB = compat/lib.a
XDIFF_LIB=xdiff/lib.a
LIB_H += archive.h
@@ -1203,8 +1204,11 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-git-shell$X: compat/strlcpy.o abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o
- $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^)
+$(COMPAT_LIB): $(COMPAT_OBJS)
+ $(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(COMPAT_OBJS)
+
+git-shell$X: abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o $(COMPAT_LIB)
+ $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(COMPAT_LIB)
$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)
@@ -1402,7 +1406,7 @@ distclean: clean
clean:
$(RM) *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o xdiff/*.o \
- $(LIB_FILE) $(XDIFF_LIB)
+ $(LIB_FILE) $(XDIFF_LIB) $(COMPAT_LIB)
$(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
$(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
^ permalink raw reply related
* [PATCH] Add a notice to the doc of git-ls-tree.
From: Steve Frécinaux @ 2008-07-20 22:25 UTC (permalink / raw)
To: git; +Cc: Steve Frécinaux
The notice covers this behaviour:
if you are in the git/ subdirectory of your repository, it will pick
the tree corresponding to that directory instead of the root one if you
specify the root tree object id.
Compare the output of both of those commands:
git-ls-tree cb44e6571708aa2792c73a289d87586fe3c0c362
git-cat-file -p cb44e6571708aa2792c73a289d87586fe3c0c362
---
Documentation/git-ls-tree.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index 1cdec22..7cba394 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -21,6 +21,10 @@ though - 'paths' denote just a list of patterns to match, e.g. so specifying
directory name (without '-r') will behave differently, and order of the
arguments does not matter.
+Note that if you give ls-tree the sha1 id of a parent of the tree
+corresponding to the directory you're in, it will resolve that tree and list
+its contents instead of listing the contents of the tree you gave.
+
OPTIONS
-------
<tree-ish>::
--
1.5.6.2
^ permalink raw reply related
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Stephan Beyer @ 2008-07-20 22:57 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Sam Vilain, Joshua Roys, Sverre Rabbelier, Sverre Rabbelier,
David Symonds, Lea Wiemann, John Hawley, Marek Zawirski,
Shawn O. Pearce, Miklos Vajna, Johannes Schindelin,
Christian Couder, Daniel Barkalow
In-Reply-To: <200807210029.31543.jnareb@gmail.com>
Hi,
what you write is quite detailed :)
Jakub Narebski wrote:
> 6. git-sequencer
>
[...]
> There were some problems with sequencer based implementation of
> "git am --rebasing", or sequencer based patch application driven
> ordinary rebase, but I think there were resolved.
They were resolved, but there is a new problem that occured in the
am --abort thread of Junio: the sequencer-based git-am does not work
on dirty working tree.
I've also fixed some other minor issues and have not yet sent this to
the list (because I think I stumble over even more while writing the
builtin-sequencer.)
> Stephen have started the builtin sequencer (but till now no patches
> were sent to list: seems to be work in progress).
Right.
> Some performance benchmarks:
> * applying 45 patches with git-am
> - 3 seconds using the original
> - 8 seconds using the (scripted) sequencer-based one
> * rebasing 100 commits
> - 4.8 seconds using the original
> - 10.1 seconds using the (scripted) sequencer-based one
> - 1.7 seconds using builtin sequencer
:)
I think I'm going to format-patch the same 100 test commits and then I
change the "applying 45 patches with git-am" part on the Wiki.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Sverre Rabbelier @ 2008-07-20 22:58 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Johannes Schindelin, Nanako Shiraishi, git
In-Reply-To: <20080720203306.GO10347@genesis.frugalware.org>
On Sun, Jul 20, 2008 at 10:33 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
>> Whatever happened to quotes?
>>
>> $ git merge -s subtree -Xpath="git-gui git-gui/master"
>
> Read again what did you wrote. ;-)
>
> The current form is
>
> git merge -s subtree git-gui/master, so at most it could be
>
> $ git merge -s subtree -Xpath="git-gui" git-gui/master
Meh, what I ofcourse mean was:
$ git merge -s subtree -X"path=git-gui" git-gui/master
But that looks rather awkward, which is probably why I typed it the
way I did? Maybe something like....
$ git merge -s subtree -X(--path=git-gui --foo=bar) git-gui/master
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-20 23:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080720224040.GG32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Do you think this would create serious problems?
>
> One thing this patch series depends on now is changing the git mv
> semantics in a rather non-trivial way, which is something we might want
> to do in a major release instead of within the 1.6 series.
The change to git-mv perhaps is necessary to happen between a major
release boundary. I do not know if the current round of patch to do so
will become ready in time for 1.6.0. The rename-ce-at patch I looked at
did not look like it was.
^ permalink raw reply
* Re: [PATCH] git-shell needs $(COMPAT_OBJS)
From: Miklos Vajna @ 2008-07-20 23:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <7vprp82nb6.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
On Sun, Jul 20, 2008 at 03:38:53PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> That's a rather misguided approach, isn't it?
>
> After all, the work requested by the end user will be handled by code in
> the main git executable by spawning a subprocess, and you are auditing the
> codepath that leads to the spawning anyway.
Hm, but then what's the purpose of having git-shell as a not-builtin?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Add a notice to the doc of git-ls-tree.
From: Petr Baudis @ 2008-07-20 23:08 UTC (permalink / raw)
To: Steve Frécinaux; +Cc: git
In-Reply-To: <1216592735-23789-1-git-send-email-code@istique.net>
On Mon, Jul 21, 2008 at 12:25:35AM +0200, Steve Frécinaux wrote:
> The notice covers this behaviour:
> if you are in the git/ subdirectory of your repository, it will pick
> the tree corresponding to that directory instead of the root one if you
> specify the root tree object id.
>
> Compare the output of both of those commands:
> git-ls-tree cb44e6571708aa2792c73a289d87586fe3c0c362
> git-cat-file -p cb44e6571708aa2792c73a289d87586fe3c0c362
> ---
> Documentation/git-ls-tree.txt | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
> index 1cdec22..7cba394 100644
> --- a/Documentation/git-ls-tree.txt
> +++ b/Documentation/git-ls-tree.txt
> @@ -21,6 +21,10 @@ though - 'paths' denote just a list of patterns to match, e.g. so specifying
> directory name (without '-r') will behave differently, and order of the
> arguments does not matter.
>
> +Note that if you give ls-tree the sha1 id of a parent of the tree
> +corresponding to the directory you're in, it will resolve that tree and list
> +its contents instead of listing the contents of the tree you gave.
> +
> OPTIONS
> -------
> <tree-ish>::
It's hard to make out what do you mean, the patch description is much
clearer, paradoxically. Also, this in fact holds for the root tree
instead of the parent tree, and the behaviour changes from "weird" to
"simply broken" when you try to list a tree object that is _not_ the
root project tree from within a subdirectory:
git$ git ls-tree HEAD Documentation
040000 tree 066c25e86a44d4c7bde2d3e9b91e6891d752efa1 Documentation
git/Documentation$ git ls-tree 066c25e86a44d4c7bde2d3e9b91e6891d752efa1
git/Documentation$
I think that ls-tree simply shouldn't auto-fill its pathspec based on
current prefix in case no pathspec was supplied. Patch to follow.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH] git-shell needs $(COMPAT_OBJS)
From: Junio C Hamano @ 2008-07-20 23:12 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <7vhcak2mip.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Perhaps we should apply a variant of your patch to allow linking from
> compat/ routines to git-shell, so that people affected by the compat layer
> functions that call outside compat layer have incentive to fix them.
So the previous one will be queued in 'pu' as...
Link shell with compat layer functions
This in the short term will break on platforms that use compat implemenations
that call outside compat layer, but that is exactly what we want. To give
incentive to fix things for people who are affected and more importantly have
environment to test their fixes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
and here is an example to fix pread for you, even I do not need it,
though.
-- >8 --
Move read_in_full() and write_in_full() to wrapper.c
A few compat/* layer functions call these functions, but we would really
want to keep them thin, without depending too much on the libgit proper.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
wrapper.c | 38 ++++++++++++++++++++++++++++++++++++++
write_or_die.c | 38 --------------------------------------
2 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/wrapper.c b/wrapper.c
index 4e04f76..93562f0 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -133,6 +133,44 @@ ssize_t xwrite(int fd, const void *buf, size_t len)
}
}
+ssize_t read_in_full(int fd, void *buf, size_t count)
+{
+ char *p = buf;
+ ssize_t total = 0;
+
+ while (count > 0) {
+ ssize_t loaded = xread(fd, p, count);
+ if (loaded <= 0)
+ return total ? total : loaded;
+ count -= loaded;
+ p += loaded;
+ total += loaded;
+ }
+
+ return total;
+}
+
+ssize_t write_in_full(int fd, const void *buf, size_t count)
+{
+ const char *p = buf;
+ ssize_t total = 0;
+
+ while (count > 0) {
+ ssize_t written = xwrite(fd, p, count);
+ if (written < 0)
+ return -1;
+ if (!written) {
+ errno = ENOSPC;
+ return -1;
+ }
+ count -= written;
+ p += written;
+ total += written;
+ }
+
+ return total;
+}
+
int xdup(int fd)
{
int ret = dup(fd);
diff --git a/write_or_die.c b/write_or_die.c
index e4c8e22..4c29255 100644
--- a/write_or_die.c
+++ b/write_or_die.c
@@ -45,44 +45,6 @@ void maybe_flush_or_die(FILE *f, const char *desc)
}
}
-ssize_t read_in_full(int fd, void *buf, size_t count)
-{
- char *p = buf;
- ssize_t total = 0;
-
- while (count > 0) {
- ssize_t loaded = xread(fd, p, count);
- if (loaded <= 0)
- return total ? total : loaded;
- count -= loaded;
- p += loaded;
- total += loaded;
- }
-
- return total;
-}
-
-ssize_t write_in_full(int fd, const void *buf, size_t count)
-{
- const char *p = buf;
- ssize_t total = 0;
-
- while (count > 0) {
- ssize_t written = xwrite(fd, p, count);
- if (written < 0)
- return -1;
- if (!written) {
- errno = ENOSPC;
- return -1;
- }
- count -= written;
- p += written;
- total += written;
- }
-
- return total;
-}
-
void fsync_or_die(int fd, const char *msg)
{
if (fsync(fd) < 0) {
^ permalink raw reply related
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Junio C Hamano @ 2008-07-20 23:16 UTC (permalink / raw)
To: sverre; +Cc: Junio C Hamano, Miklos Vajna, git
In-Reply-To: <bd6139dc0807201550v27d6db3epd0d0b4bc663e0351@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> On Sun, Jul 20, 2008 at 11:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I could make "What's cooking" not a follow-up to the previous issue, or
>> perhaps add "(volume 1.6.0, issue 28)" at the end of the Subject.
>
> The downside of this is that it'll be less easy to see the difference
> with the previous version.
My vague recollection is that it was Pasky who complained long time ago
when "What's in" was not a follow-up to its previous round, which led me
to switch my workflow to send them in the current form. You cannot
satisfy certain people no matter what you do.
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Sverre Rabbelier @ 2008-07-20 23:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7v3am42lk2.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 21, 2008 at 1:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> On Sun, Jul 20, 2008 at 11:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> I could make "What's cooking" not a follow-up to the previous issue, or
>>> perhaps add "(volume 1.6.0, issue 28)" at the end of the Subject.
>>
>> The downside of this is that it'll be less easy to see the difference
>> with the previous version.
>
> My vague recollection is that it was Pasky who complained long time ago
> when "What's in" was not a follow-up to its previous round, which led me
> to switch my workflow to send them in the current form. You cannot
> satisfy certain people no matter what you do.
Add an interdiff at the bottom of the mail? You can't satisfy
everybody no matter what you do, but you can come quite far, it
usually means you have to do a lot of work to do so though.
^ permalink raw reply
* Re: [PATCH] Add a notice to the doc of git-ls-tree.
From: Steve Frécinaux @ 2008-07-20 23:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Steve Frécinaux, git
In-Reply-To: <20080720230846.GH32184@machine.or.cz>
> It's hard to make out what do you mean, the patch description is much
> clearer, paradoxically.
It is hard to explain such a strange behaviour with a description that
is both short and generic enough... But I agree with you. I just got
bitten by this and I thought it was important enough to be specified.
> Also, this in fact holds for the root tree
> instead of the parent tree, and the behaviour changes from "weird" to
> "simply broken" when you try to list a tree object that is _not_ the
> root project tree from within a subdirectory:
>
> git$ git ls-tree HEAD Documentation
> 040000 tree 066c25e86a44d4c7bde2d3e9b91e6891d752efa1 Documentation
> git/Documentation$ git ls-tree 066c25e86a44d4c7bde2d3e9b91e6891d752efa1
> git/Documentation$
>
> I think that ls-tree simply shouldn't auto-fill its pathspec based on
> current prefix in case no pathspec was supplied. Patch to follow.
I also thought this behaviour was broken. But I didn't want to patch
it because I was afraid of breaking things that would rely on it,
despite it seems unexpected enough not to be used...
^ permalink raw reply
* Re: [PATCH] Add a notice to the doc of git-ls-tree.
From: Junio C Hamano @ 2008-07-20 23:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: Steve Frécinaux, git
In-Reply-To: <20080720230846.GH32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I think that ls-tree simply shouldn't auto-fill its pathspec based on
> current prefix in case no pathspec was supplied. Patch to follow.
Have you dug the list archive from mid-to-late December 2005 that prompted
the current behaviour (and introduction of --full-name)? I haven't. A
change to always do the --full-name can only be justified by doing so and
rehashing the issues.
On the other hand, "fix" is welcome.
^ permalink raw reply
* Re: [PATCH] Add a notice to the doc of git-ls-tree.
From: Petr Baudis @ 2008-07-20 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steve Frécinaux, git
In-Reply-To: <7vy73w16nj.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 04:24:00PM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > I think that ls-tree simply shouldn't auto-fill its pathspec based on
> > current prefix in case no pathspec was supplied. Patch to follow.
>
> Have you dug the list archive from mid-to-late December 2005 that prompted
> the current behaviour (and introduction of --full-name)? I haven't. A
> change to always do the --full-name can only be justified by doing so and
> rehashing the issues.
>
> On the other hand, "fix" is welcome.
You are right, now that I understand the issue better, there's no good
fix for this except perhaps introducing --no-prefix, which is not my
itch to scratch. Here's my original wording improvement:
Note that if you are within a subdirectory of your working copy,
'git ls-tree' will automatically prepend the subdirectory prefix
to the specified paths, and assume the prefix specified in case
no paths were given - no matter what the tree object is! Thus,
within a subdirectory, 'git ls-tree' behaves as expected only
when run on a root tree object.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH] Add a notice to the doc of git-ls-tree.
From: Junio C Hamano @ 2008-07-20 23:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: Steve Frécinaux, git
In-Reply-To: <7vy73w16nj.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> I think that ls-tree simply shouldn't auto-fill its pathspec based on
>> current prefix in case no pathspec was supplied. Patch to follow.
>
> Have you dug the list archive from mid-to-late December 2005 that prompted
> the current behaviour (and introduction of --full-name)? I haven't.
Now, I did:
http://thread.gmane.org/gmane.comp.version-control.git/13028/focus=13135
I think the answer is --full-name (cf. a69dd58 (ls-tree: chomp leading
directories when run from a subdirectory, 2005-12-23)).
^ permalink raw reply
* Re: [PATCH 2/2] git-add -a: add all files
From: Jeff King @ 2008-07-20 23:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jay Soffian, Johannes Schindelin, Tarmigan, git, Michael J Gruber
In-Reply-To: <7v4p6k8l36.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 11:30:21AM -0700, Junio C Hamano wrote:
> So for such people who would find "add -A" useful, "commit -a" will not be
> "unrelated changes in the same commit". And for such people, I would even
> say "commit -A" would be even more useful, too.
>
> I'll never be in that camp of perfect people myself, though..
I don't claim to be perfect, but I do use "commit -a" and I haven't ever
had a problem committing unrelated changes. My secret is to keep a good
.gitignore, and to peek at "git status" and "git diff" before
committing. So it's just a shorthand because after seeing that
everything is ready for commit, I'm too lazy to type each filename. I
also use "git add ." for the same purpose if files are to be added.
But note that avoiding "-a" doesn't save you from unrelated changes
anyway; it only saves you from changes in unrelated files. You still
have to look below the file granularity with "git diff" to avoid (for
example) a debugging printf. I often will use "git add -i" if I have a
lot of complex changes, even if I end up staging _everything_. But it
lets me say "yes, this should go in" for each hunk.
So maybe I will use "git add -A", but I have to admit to not really
having felt its lack to this point. However, something Lars said makes
me wonder: do people _really_ want this as an option to add? I seem to
recall the primary request for this being the "undisciplined" approach
you gave ("I have a project that periodically gets data dumped by an
external program, and I want to commit it all"). In that case, the next
step is always commit, so what would be most convenient is "commit -A".
But again, I haven ever felt the lack of this feature; such usage for me
always goes in scripts, where I am more than happy to write out "add .
&& add -u && commit".
-Peff
^ permalink raw reply
* [PATCH v2] Ensure that SSH runs in non-interactive mode
From: Fredrik Tolf @ 2008-07-21 0:00 UTC (permalink / raw)
To: git; +Cc: Fredrik Tolf
OpenSSH has the nice feature that it sets the IP TOS value of its
connection depending on usage. When used in interactive mode, it
is set to Minimize-Delay, and other wise to Maximize-Throughput. Its
usage by Git is best served by Maximize-Throughput, for obvious
reasons.
However, it seems to use a DWIM heuristic for detecting interactive
mode. The current implementation enters interactive mode if either
a PTY is allocated or X11 forwarding is enabled, and even though Git
SSH:ing does not allocate a PTY, X11 forwarding is often turned on
by default.
This patch allows the Git config file to specify the SSH command to
use and its parameters in a rather flexible manner. It should also be
enough to configure Git to use other SSH implementations than OpenSSH.
Signed-off-by: Fredrik Tolf <fredrik@dolda2000.com>
---
I'm following my previous SSH patch up with this one, which should at
least solve the problems discussed, and probably some more. If anything,
it might be considered a bit overkill for the problem at hand.
I assume it might have to be documented as well, if people approve of it.
connect.c | 130 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------
1 files changed, 117 insertions(+), 13 deletions(-)
diff --git a/connect.c b/connect.c
index 574f42f..46379fa 100644
--- a/connect.c
+++ b/connect.c
@@ -474,6 +474,114 @@ char *get_port(char *host)
return NULL;
}
+static char *git_ssh_command;
+static struct {
+ char *name;
+ char *exp;
+} ssh_templates[] = {
+ {"openssh", "ssh -xT %P-p %p %h"},
+ {"plink", "plink %P-P %p %h"},
+ {NULL, NULL}
+};
+
+static int git_ssh_command_options(const char *var, const char *value, void *cb)
+{
+ int i;
+
+ if(!strcmp(var, "core.sshcommand")) {
+ if(git_ssh_command)
+ return 0;
+ if(!value)
+ return config_error_nonbool(var);
+ if(strchr(value, ' ')) {
+ git_ssh_command = xstrdup(value);
+ } else {
+ for(i = 0; ssh_templates[i].name; i++) {
+ if(!strcmp(ssh_templates[i].name, value)) {
+ git_ssh_command = xstrdup(ssh_templates[i].exp);
+ break;
+ }
+ }
+ if(git_ssh_command == NULL)
+ git_ssh_command = xstrdup(value);
+ }
+ }
+
+ return git_default_config(var, value, cb);
+}
+
+static char *ssh_arg_subst(char *arg, const char *host, const char *port)
+{
+ if(!strncmp(arg, "%P", 2)) {
+ if(!port)
+ return NULL;
+ return xstrdup(arg + 2);
+ } else if(!strcmp(arg, "%p")) {
+ if(!port)
+ return NULL;
+ return xstrdup(port);
+ } else if(!strcmp(arg, "%h")) {
+ return xstrdup(host);
+ }
+ return arg;
+}
+
+static const char **setup_ssh_command(const char *host, const char *port, int extra_args)
+{
+ char **argv;
+ char *tok, *buf;
+ int i, sz;
+
+ if((buf = getenv("GIT_SSH")) != NULL) {
+ if(port) {
+ argv = xcalloc(5 + extra_args, sizeof(*argv));
+ argv[0] = xstrdup(buf);
+ argv[1] = xstrdup("-p");
+ argv[2] = xstrdup(port);
+ argv[3] = xstrdup(host);
+ } else {
+ argv = xcalloc(3 + extra_args, sizeof(*argv));
+ argv[0] = xstrdup(buf);
+ argv[1] = xstrdup(host);
+ }
+ return (const char **)argv;
+ }
+
+ git_config(git_ssh_command_options, NULL);
+ if(git_ssh_command == NULL)
+ buf = xstrdup(ssh_templates[0].exp);
+ else
+ buf = xstrdup(git_ssh_command);
+
+ argv = xmalloc((sz = 5) * sizeof(*argv));
+ for(i = 0, tok = strtok(buf, " "); tok != NULL; tok = strtok(NULL, " ")) {
+ argv[i++] = xstrdup(tok);
+ if(sz - i < 1)
+ argv = xrealloc(argv, (sz += 5) * sizeof(*argv));
+ }
+ argv[i] = NULL;
+ argv = xrealloc(argv, ((sz = i) + extra_args + 1) * sizeof(*argv));
+ free(buf);
+
+ for(i = 0; i < sz;) {
+ buf = ssh_arg_subst(argv[i], host, port);
+ if(buf == argv[i]) {
+ i++;
+ continue;
+ } else if(buf == NULL) {
+ free(argv[i]);
+ memmove(argv + i, argv + i + 1, sizeof(*argv) * (sz-- - i));
+ continue;
+ } else {
+ free(argv[i]);
+ argv[i] = buf;
+ i++;
+ }
+ }
+
+ return (const char **)argv;
+}
+
static struct child_process no_fork;
/*
@@ -596,19 +704,12 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
die("command line too long");
conn->in = conn->out = -1;
- conn->argv = arg = xcalloc(6, sizeof(*arg));
if (protocol == PROTO_SSH) {
- const char *ssh = getenv("GIT_SSH");
- if (!ssh) ssh = "ssh";
-
- *arg++ = ssh;
- if (port) {
- *arg++ = "-p";
- *arg++ = port;
- }
- *arg++ = host;
+ conn->argv = setup_ssh_command(host, port, 1);
+ for(arg = conn->argv; *arg; arg++);
}
else {
+ conn->argv = arg = xcalloc(6, sizeof(*arg));
/* remove these from the environment */
const char *env[] = {
ALTERNATE_DB_ENVIRONMENT,
@@ -620,10 +721,10 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
NULL
};
conn->env = env;
- *arg++ = "sh";
- *arg++ = "-c";
+ *arg++ = xstrdup("sh");
+ *arg++ = xstrdup("-c");
}
- *arg++ = cmd.buf;
+ *arg++ = xstrdup(cmd.buf);
*arg = NULL;
if (start_command(conn))
@@ -640,11 +741,14 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
int finish_connect(struct child_process *conn)
{
+ const char **argp;
int code;
if (!conn || conn == &no_fork)
return 0;
code = finish_command(conn);
+ for(argp = conn->argv; *argp; argp++)
+ free((void *)*argp);
free(conn->argv);
free(conn);
return code;
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH 2/2] git-add -a: add all files
From: Junio C Hamano @ 2008-07-21 0:06 UTC (permalink / raw)
To: Jeff King
Cc: Jay Soffian, Johannes Schindelin, Tarmigan, git, Michael J Gruber
In-Reply-To: <20080720235933.GA12454@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But again, I haven ever felt the lack of this feature; such usage for me
> always goes in scripts, where I am more than happy to write out "add .
> && add -u && commit".
The reason we did not have such "feature" so far was not because somebody
high in the git foodchain was opposed to the idea, but simply because
nobody came up with a usable patch to do so.
I do not have anything fundamentally against "add -A" nor "commit -A". To
me, this is in "perhaps nice to have for some people, but I would not use
it myself and I wouldn't bother" category, not in "I'm opposed -- it would
promote bad workflow" cateogry.
^ permalink raw reply
* Re: [PATCH] Add a notice to the doc of git-ls-tree.
From: Petr Baudis @ 2008-07-21 0:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steve Frécinaux, git
In-Reply-To: <7vtzek15b5.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 04:53:02PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Petr Baudis <pasky@suse.cz> writes:
> >
> >> I think that ls-tree simply shouldn't auto-fill its pathspec based on
> >> current prefix in case no pathspec was supplied. Patch to follow.
> >
> > Have you dug the list archive from mid-to-late December 2005 that prompted
> > the current behaviour (and introduction of --full-name)? I haven't.
>
> Now, I did:
>
> http://thread.gmane.org/gmane.comp.version-control.git/13028/focus=13135
>
> I think the answer is --full-name (cf. a69dd58 (ls-tree: chomp leading
> directories when run from a subdirectory, 2005-12-23)).
I don't understand your point now. --full-name cares only about the
displaying part; do you suggest that it should be extended to also turn
off prepending the prefix during the filtering phase? That would make a
lot of sense, if you are not worried about compatibility trouble.
--
Petr "Pasky, missing something" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox