* Re: [PATCH][RFC] Add git-archive-tree
From: Rene Scharfe @ 2006-09-04 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Franck Bui-Huu, Git Mailing List
In-Reply-To: <7vy7szmm1u.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> So to recap:
>
> - "git-archive-tree --format <foo> <foo specific options> <tree>"
> would know how to create <foo> format archive and send the result to
> stdout.
>
> - "git-download-archive <repo> <git-archive-tree-command-line>" would
> talk with "git-upload-archive" in the remote repository, give
> archive-tree command line to it and receives the result.
>
> - "git-upload-archive <repo>" is not used by the end user. Underlying
> git-archive-tree command line options are sent over the protocol from
> download-archive, just like upload-tar does.
>
> If this is what you mean, I think three of us are in agreement here.
Well, this is just _one_ of the positions I've taken on this topic, I
have to admit. Franck then convinced me that merging downloader and
archiver into one command is nice for users (less commands to remember,
keeps existing --remote option) even if it doesn't make sense
technically, because their implementations have nothing in common.
This is a bikeshed colour discussion, and I'm bad at it. I'll shut up
on this and simply follow the directions above.
>> My next steps will be to make traverse_tree() support path specs,
>> in order to achieve feature parity with read_tree_recursive(). I
>> hope that the former keeps being significantly faster than the
>> latter even after that.
>
> A thing that have been bothering me for some time in pathspec area is
> that we have two (eh perhaps three) quite different pathspec
> semantics.
>
> - diff-tree family (and anything based on revision.c including
> git-log) is a strict prefix directory match (e.g. no wildcards, and
> "Documentation/howto" matches the directory but not
> "Documentation/howto-index.sh")
>
> - ls-files family (ls-files used to be an one odd man out, but
> git-grep mimics it, and "git-commit <paths>" uses ls-files internally
> so they form a family) is prefix match with fnmatch match upon
> wildcard (e.g. "Documentation/howto" still matches the directory but
> not "Documentation/howto-index.sh", but you can say
> "Documentation/howto*" to match both, and you can even say
> "Document*").
>
> The former semantics is very friendly with "struct tree_desc" based
> traversal. Allowing pathspecs with ls-files style matching would
> probably more useful but more work. And there are at least four
> implementations of pathspec matcher with slightly different
> interfaces (ugh, sorry) if I am not mistaken: builtin-ls-files.c has
> one (match), tree-diff.c has another (interesting), builtin-grep.c
> has one (pathspec_matches), dir.c has another (match_pathspec).
>
> We might be able to share code with para-walk.c in "pu" (it is
> designed to walk zero or more trees optionally with index and working
> tree in parallel and we would be using it to walk only single tree
> without index nor working tree). That would give me an incentive to
> clean up the code ;-) Currently it is a ten "WIP" patch series.
>
> One thing it attempts to do on the side is to consolidate the
> diff-tree style ones into one by introducing another in read-cache.c
> (pathname_included) but it does not convert existing users of other
> matchers to use it yet.
Interesting. OK, I'll check out the existing implementations with an
eye on consolidation and also take a look around that scary place named
'pu'. ;-)
So far I have failed in creating a traverse_tree() function with path
spec match support which also is faster than read_tree_recursive().
Maybe the speed difference between 'git-tar-tree' and 'git-archive-tree
-ftar' is caused by something else. I keep on trying.
René
^ permalink raw reply
* Re: New git commit tool
From: Paul Mackerras @ 2006-09-04 21:51 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git, torvalds
In-Reply-To: <20060904195736.GB2752@diku.dk>
Jonas Fonseca writes:
> I am a Cogito user, so I am no used to running git-update-index and
> this seems to be a problem in this case:
>
> can't unset "indexpending(gitool)": no such element in array
Hmmm, I didn't think that could happen. :) It can only happen if some
file gets listed twice in the output from "git-diff-index HEAD".
Could you send me the output of "git-diff-index HEAD" and
"git-diff-index --cached HEAD" in that repository?
And no, you don't need to run git-update-index, gitool does that for
you.
Paul.
^ permalink raw reply
* git fetch of 2.6.18-rc5-mm1
From: Chris Smith @ 2006-09-04 21:42 UTC (permalink / raw)
To: git, Andrew Morton
n00b here.
Per Andrew Morton's release announcement boilerplate, which is:
git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git
v2.6.16-rc2-mm1
I tried:
git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git
v2.6.18-rc5-mm1
When I dropped in my .config and did
#make menuconfig
the tree showed its version as v2.6.16-rc2-mm1 still.
I can get a clean clone of the Linus tree, but not the -mm tree.
Additionally, navigating to
http://kernel.org/git/?o=age
and searching on "smurf" reveals this information:
linux/kernel/git/smurf/linux-trees.git Tree imports. The main branch
... Matthias Urlichs 6 months ago summary | shortlog | log
Request someone help me understand where I'm off track.
--
Christopher Smith
Pursuer of knowledge
^ permalink raw reply
* Re: New git commit tool
From: Linus Torvalds @ 2006-09-04 21:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17660.39046.767944.582869@cargo.ozlabs.ibm.com>
On Tue, 5 Sep 2006, Paul Mackerras wrote:
>
> I was calling it "gitt" for a long time, which is at least shorter and
> easier to type. I also thought of "tick" (anagram of tk + "ci" for
> check in), but maybe all that shows I've been doing too many cryptic
> crosswords lately. :) The "gitool" was by analogy with the "citool"
> of another system we've both used. I'm happy to change it if someone
> has a better idea...
I had kind of expected more of an integration with gitk, and just using
"gitk" as the generic name for "git tk interface", it would perhaps make
more sense to just interface it that way, and thus one logical (?) thing
to do would be to just make the command be
gitk commit
the same way we have "git commit". Hmm?
But maybe I'm just strange.
Linus
^ permalink raw reply
* Re: New git commit tool
From: Paul Mackerras @ 2006-09-04 21:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609040952550.27779@g5.osdl.org>
Linus Torvalds writes:
> I do have a fourth issue, which is that I hate "gitool" as a name. It
> either parses as "gi"+"tool", which makes no sense, or "git"+"ool", which
> also makes no sense. "gitk" was cute, "gitool" is just irritating ;)
I was calling it "gitt" for a long time, which is at least shorter and
easier to type. I also thought of "tick" (anagram of tk + "ci" for
check in), but maybe all that shows I've been doing too many cryptic
crosswords lately. :) The "gitool" was by analogy with the "citool"
of another system we've both used. I'm happy to change it if someone
has a better idea...
Paul.
^ permalink raw reply
* Re: [PATCH] git-repack: create new packs inside $PACKDIR, not cwd
From: Junio C Hamano @ 2006-09-04 20:16 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: git
In-Reply-To: <44FC041F.6010002@catalyst.net.nz>
"Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> writes:
> Ah, ok. I misunderstood the use of trap -- of course, re-reading the
> man pages, it makes sense.
However the more I think about it your original idea of using
.tmp-pack directly in .git/objects/pack/ *should* have worked
(modulo two repack instances using the same name, which is fixed
by $$ there). Not insisting on "pack-" prefix I consider is a
feature, but I do not see a reason to take a file that begin
with a dot.
Well, probably too late to deprecate, maybe not. I dunno.
^ permalink raw reply
* Re: [PATCH][RFC] Add git-archive-tree
From: Junio C Hamano @ 2006-09-04 20:09 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Franck Bui-Huu, Git Mailing List
In-Reply-To: <44FC6EDE.4010300@lsrfire.ath.cx>
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Franck Bui-Huu schrieb:
>>
>> Well I don't see why putting the remote operations in an other file. I
>> was more thinking on something like this:
>>
>> git-archive --format=<fmt> [--remote=<repo>] <tree-ish> [path...]
>
> My intention was to put both halves of the wire protocol implementation
> into the same source file. I still think this is a good idea, but of
> course it's independent from any command line interface considerations.
I think so too, and agree with your reasoning.
> No, git-upload-archive would accept only a single parameter: the path to
> the repository. It'd receive all other options via the wire protocol,
> just like git-upload-tar.
Same here.
> We could remove the existing commands git-upload-tar and git-zip-tree
> right now, as they were never part of a release, yet. git-upload-zip
> doesn't exist, yet, and git-tar-tree would probably survive as legacy
> interface, calling git-archive-tree internals. Junio, am I correct
> regarding the cool-blooded killing of unreleased commands?
>>> git-tar-tree is now called by git-upload-tar.
I do think leaving tar-tree vs upload-tar protocol alone would
not hurt development of this new archive vs upload-archive
protocol. Also 'git-tar-tree --remote' has been part of git for
some time now (1.4.2 has it). Having said that, I suspect
nobody really relies on that, and I think this restructuring is
a good change. Time to poll the userbase?
Do people get upset if we said "git-tar-tree
--remote=xyzzy.example.com" is no more, and you will
have to say "git-fetch-archive -f tar xyzzy.example.com"?
>>> Does it make sense to change the wire protocol to simply send the
>>> command line options one by one?
>>
>> That would make sense if the number of options grow up.
... or different archive backends want different kind of things
(tar-tree without compression would not want -z6 but zip-tree
would).
>> But if we allow
>> pathspec for remote operations, then we need to send them to the
>> uploader.
Yup.
> If we simply send each option to the downloader without understanding
> them then the uploader can be kept really simple. The protocol can be
> kept simple, and it would be future-proof: we will never have to update
> it. I'm a bit worried about the security implications of such a setup,
> strangely _because_ I can't see a way to exploit it right now (and
> because it allows arbitrary input, which we must be able to cope with
> anyway).
>>>
>>> The interface could be something like this:
>>>
>>> git-download-archive <repo> <git-archive-tree options...>
>>> git-upload-archive <directory>
>>>
>> I think it is, IMHO. And that's why I think we could have only one
>> command for building localy/remotely archive whatever the format.
>> git-archive should be a main procelain command, and we should get rid
>> of git-{tar,zip}-tree commands.
>
> OK, makes sense; users will never need to call git-upload-archive
> directly, and having a single command for all archiving is a good thing.
So to recap:
- "git-archive-tree --format <foo> <foo specific options> <tree>"
would know how to create <foo> format archive and send the result
to stdout.
- "git-download-archive <repo> <git-archive-tree-command-line>"
would talk with "git-upload-archive" in the remote repository,
give archive-tree command line to it and receives the result.
- "git-upload-archive <repo>" is not used by the end user.
Underlying git-archive-tree command line options are sent
over the protocol from download-archive, just like upload-tar
does.
If this is what you mean, I think three of us are in agreement
here.
> My next steps will be to make traverse_tree() support path specs, in
> order to achieve feature parity with read_tree_recursive(). I hope that
> the former keeps being significantly faster than the latter even after
> that.
A thing that have been bothering me for some time in pathspec
area is that we have two (eh perhaps three) quite different
pathspec semantics.
- diff-tree family (and anything based on revision.c including
git-log) is a strict prefix directory match (e.g. no
wildcards, and "Documentation/howto" matches the directory
but not "Documentation/howto-index.sh")
- ls-files family (ls-files used to be an one odd man out, but
git-grep mimics it, and "git-commit <paths>" uses ls-files
internally so they form a family) is prefix match with
fnmatch match upon wildcard (e.g. "Documentation/howto" still
matches the directory but not "Documentation/howto-index.sh",
but you can say "Documentation/howto*" to match both, and you
can even say "Document*").
The former semantics is very friendly with "struct tree_desc"
based traversal. Allowing pathspecs with ls-files style
matching would probably more useful but more work. And there
are at least four implementations of pathspec matcher with
slightly different interfaces (ugh, sorry) if I am not mistaken:
builtin-ls-files.c has one (match), tree-diff.c has another
(interesting), builtin-grep.c has one (pathspec_matches), dir.c
has another (match_pathspec).
We might be able to share code with para-walk.c in "pu" (it is
designed to walk zero or more trees optionally with index and
working tree in parallel and we would be using it to walk only
single tree without index nor working tree). That would give me
an incentive to clean up the code ;-) Currently it is a ten
"WIP" patch series.
One thing it attempts to do on the side is to consolidate the
diff-tree style ones into one by introducing another in
read-cache.c (pathname_included) but it does not convert
existing users of other matchers to use it yet.
^ permalink raw reply
* Re: New git commit tool
From: Jonas Fonseca @ 2006-09-04 19:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, torvalds
In-Reply-To: <17660.4995.977221.767112@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote Mon, Sep 04, 2006:
> Comments and suggestions are welcome.
While doing my best to misuse gitool here is what happened ...
1. To try out gitool I did the following:
$ mkdir gitool
$ cd gitool
$ git init-db
$ wget http://ozlabs.org/~paulus/gitool
$ git add gitool
Oops, forgot to make it executable ...
$ chmod +x gitool
$ ./gitool
I am a Cogito user, so I am no used to running git-update-index and
this seems to be a problem in this case:
can't unset "indexpending(gitool)": no such element in array
can't unset "indexpending(gitool)": no such element in array
while executing
"unset indexpending($f)"
(procedure "readfmod" line 92)
invoked from within
"readfmod file11 0"
2. When closing the window while the "Application Error" is still open
causes the following error:
bgerror failed to handle background error.
Original error: can't unset "indexpending(gitool)": no such element in array
Error in bgerror: can't invoke "grab" command: application has been destroyed
bgerror failed to handle background error.
Original error: invalid command name ".ptop.comm.t"
Error in bgerror: can't invoke "tk" command: application has been destroyed
Maybe it should be ignored.
3. Finally, I find the difference between clicking on a file name
versus clicking on a file icon a bit strange. I continue on the
example above, first modifying gitool and then creating a new file,
so a file is listed both under "Modified files" and "Untracked/new
files".
1. Click on the file name of the modified file to see the diff
in the content buffer.
2. Click on the file icon of the untracked file to add it. State
shows "Added" and the content buffer is cleared.
I have to press the file name to see the content of the added file.
Maybe it should show the content regardless of whether the file name
or icon was pressed.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: Add GIT favicon, assuming image/png type
From: Jakub Narebski @ 2006-09-04 18:34 UTC (permalink / raw)
To: git
In-Reply-To: <200609042032.13742.jnareb@gmail.com>
Jakub Narebski wrote:
> index 199fbe87384cd3f4686916277dd124cefc751e8a..f3b762de92e579300eba3f53ee26b2a80b4e76c7 100644
Hmmm... I do wonder why --binary implies --full-index option.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH][RFC] Add git-archive-tree
From: Rene Scharfe @ 2006-09-04 18:22 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <cda58cb80609021313p5156a14du4895e53387dd24dc@mail.gmail.com>
Franck Bui-Huu schrieb:
> 2006/9/2, Rene Scharfe <rene.scharfe@lsrfire.ath.cx>:
>> The two patches I sent are what I have been able to come up with so far.
>> The next step would be to add archive-neutral upload and download
>> support.
>>
>> Having thought a bit about it I propose to keep git-archive-tree for
>> local operations, only. It can be called by the uploader just like
>
> Well I don't see why putting the remote operations in an other file. I
> was more thinking on something like this:
>
> git-archive --format=<fmt> [--remote=<repo>] <tree-ish> [path...]
My intention was to put both halves of the wire protocol implementation
into the same source file. I still think this is a good idea, but of
course it's independent from any command line interface considerations.
Internally, remote and local operations do completely different things,
so it doesn't make sense to mix them. But users probably don't care
about such details and may prefer a single command to express "gimme
that archive, no matter if it's made here or there". OK, sort of.
> This main porcelain function would call directly functions provided by
> archivers lib. We will need to define an API which git-archive will
> use for local operations.
Yes, this would be write_archive_fn_t in archive.h.
> Symetrically, on the sever side we would have:
>
> git-upload-archive --format=<fmt> <repo> [path...]
No, git-upload-archive would accept only a single parameter: the path to
the repository. It'd receive all other options via the wire protocol,
just like git-upload-tar.
> used by git-daemon. It will deal with protocol, paths and use archiver's
> lib.
Except if you meant by this that git-daemon would handle the protocol
etc., which I'd disagree with ("It" is slightly ambiguous here).
> Eventually, we would have 2 commands:
>
> git-archive
> git-upload-archive
>
> and get ride of
>
> git-tar-tree
> git-zip-tree
> git-upload-tar
> git-upload-zip
Let's keep the git-<verb>-<object> nomenclature used for most commands
for the sake of consistency. In both cases you'd only type
git-archiv<TAB> anyway. ;-)
We could remove the existing commands git-upload-tar and git-zip-tree
right now, as they were never part of a release, yet. git-upload-zip
doesn't exist, yet, and git-tar-tree would probably survive as legacy
interface, calling git-archive-tree internals. Junio, am I correct
regarding the cool-blooded killing of unreleased commands?
>> git-tar-tree is now called by git-upload-tar. As Franck suggested, the
>> uploader should allow the list of archive formats it supports to be
>> restricted in a config file. The range of allowed compression levels
>> should also be configurable.
>>
>> Does it make sense to change the wire protocol to simply send the
>> command line options one by one?
>
> That would make sense if the number of options grow up. Currently the
> remote protocol had been written by Junio, I just pick up that part
> from git-tar-tree and put it into git-archive. But if we allow
> pathspec for remote operations, then we need to send them to the
> uploader.
If we simply send each option to the downloader without understanding
them then the uploader can be kept really simple. The protocol can be
kept simple, and it would be future-proof: we will never have to update
it. I'm a bit worried about the security implications of such a setup,
strangely _because_ I can't see a way to exploit it right now (and
because it allows arbitrary input, which we must be able to cope with
anyway).
>>
>> The interface could be something like this:
>>
>> git-download-archive <repo> <git-archive-tree options...>
>> git-upload-archive <directory>
>>
>> Or, if the big number of git command names is a concern:
>>
>
> I think it is, IMHO. And that's why I think we could have only one
> command for building localy/remotely archive whatever the format.
> git-archive should be a main procelain command, and we should get rid
> of git-{tar,zip}-tree commands.
OK, makes sense; users will never need to call git-upload-archive
directly, and having a single command for all archiving is a good thing.
My next steps will be to make traverse_tree() support path specs, in
order to achieve feature parity with read_tree_recursive(). I hope that
the former keeps being significantly faster than the latter even after
that. If it works out I'm going to convert git-zip-tree to use
traverse_tree().
Other tasks: morphing git-upload-tar into git-upload-archive,
replacing/enhancing the protocol, and adding a matching uploader
(--remote= option handler). I won't start with that stuff until I get
the performance sorted out. I hope this keeps me from stepping on your
toes (again), Franck. ;-)
Thanks,
René
^ permalink raw reply
* [PATCH 1/4] gitweb: Add GIT favicon, assuming image/png type
From: Jakub Narebski @ 2006-09-04 18:32 UTC (permalink / raw)
To: git
In-Reply-To: <200609041813.49103.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Corrected version, with the actual binary diff
(that was the version sent earlier, by the way).
Makefile | 2 ++
gitweb/git-favicon.png | Bin
gitweb/gitweb.perl | 5 +++++
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 199fbe87384cd3f4686916277dd124cefc751e8a..f3b762de92e579300eba3f53ee26b2a80b4e76c7 100644
--- a/Makefile
+++ b/Makefile
@@ -137,6 +137,7 @@ GITWEB_LIST =
GITWEB_HOMETEXT = indextext.html
GITWEB_CSS = gitweb.css
GITWEB_LOGO = git-logo.png
+GITWEB_FAVICON = git-favicon.png
export prefix bindir gitexecdir template_dir GIT_PYTHON_DIR
@@ -674,6 +675,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_HOMETEXT++|$(GITWEB_HOMETEXT)|g' \
-e 's|++GITWEB_CSS++|$(GITWEB_CSS)|g' \
-e 's|++GITWEB_LOGO++|$(GITWEB_LOGO)|g' \
+ -e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \
$< >$@+
chmod +x $@+
mv $@+ $@
diff --git a/gitweb/git-favicon.png b/gitweb/git-favicon.png
new file mode 100644
index 0000000000000000000000000000000000000000..de637c0608090162a6ce6b51d5f9bfe512cf8bcf
GIT binary patch
literal 164
zc-rd>@N?(olHy`uVBq!ia0vp^0wB!93?!50ihlx9JOMr-t_OgO28RD&a4c8tKak5=
z;1OBOz`!jG!i)^F=12eq?L1u^Ln;_q4{j86a1dcV@b%g0mmUiOK9(+Io+#BK-XURJ
z*52lzAh4o%_q+oa1XgVS7Wa3@eurhH>!fs<8s*Qab3eLq`JX({BnD4cKbLh*2~7aN
C3N}^%
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7961945630e44e94649f3ccd9f96a962c94af0d9..bebaa0fb1e93995da8ea19af8b70a453b9572488 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -48,6 +48,8 @@ # URI of default stylesheet
our $stylesheet = "++GITWEB_CSS++";
# URI of GIT logo
our $logo = "++GITWEB_LOGO++";
+# URI of GIT favicon, assumed to be image/png type
+our $favicon = "++GITWEB_FAVICON++";
# source of projects list
our $projects_list = "++GITWEB_LIST++";
@@ -1192,6 +1194,9 @@ EOF
'href="%s" type="application/rss+xml"/>'."\n",
esc_param($project), href(action=>"rss"));
}
+ if (defined $favicon) {
+ print qq(<link rel="shortcut icon" href="$favicon" type="image/png"/>\n);
+ }
print "</head>\n" .
"<body>\n" .
--
1.4.1.1
^ permalink raw reply related
* Re: PATCH 1/4] gitweb: Add GIT favicon, assuming image/png type
From: Linus Torvalds @ 2006-09-04 17:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200609041813.49103.jnareb@gmail.com>
On Mon, 4 Sep 2006, Jakub Narebski wrote:
>
> This is my first post with binary patch. I'd rather not send file
> git-favicon.png as an attachement due to filtering.
You forgot the "--binary" flag, so it didn't actually create a binary
patch, it just did the "Binary files .. differ" thing:
> diff --git a/gitweb/git-favicon.png b/gitweb/git-favicon.png
> new file mode 100644
> index 0000000..de637c0
> Binary files /dev/null and b/gitweb/git-favicon.png differ
See diff.c: builtin_diff() for the logic:
...
if (o->binary)
emit_binary_diff(&mf1, &mf2);
else
printf("Binary files %s and %s differ\n",
lbl[0], lbl[1]);
...
ie the default is to act like a regular "diff", and we do the extended git
binary diffs only if you ask for them explicitly.
(Of course, since we do the _other_ extended git diff headers regardless,
maybe that doesn't make much sense. On the other hand, the normal extended
git diff headers are compatible with normal patches, so there is a real
difference, and so arguably the "--binary" flag makes tons of sense).
Linus
^ permalink raw reply
* Re: New git commit tool
From: Linus Torvalds @ 2006-09-04 17:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17660.4995.977221.767112@cargo.ozlabs.ibm.com>
On Mon, 4 Sep 2006, Paul Mackerras wrote:
>
> Files can also be partly checked in, for example, if changes were made
> and checked in, and then further changes were made. Clicking on such
> a file will show a 3-way diff (HEAD vs. checked-in state vs. working
> file), provided Junio applies my patch to diff-lib.c. :)
I like the feature, but not necessarily how it's been done. I see three
problems:
a) the three-way diff makes it hard to see what you would _actually_ check
in (if you use the index state), because it (by design, of course)
mixes in not just the data you check in, but also the current state.
b) if you ever click the icon to mark the whole file for checkin, you've
now forever lost the old index state (ie it seems to do the equivalent
of "git-update-index" into the main index). So you can't recover from
mistakenly clicking on the icon.
c) there's no way to exit gracefully without saving the changes you've
done (related to (b), but also something you might want to do
regardless of any half-way-updated index state).
Now, the second and third problem are really one and the same, I guess. It
all boils down to the fact that I think one reasonable usage-case is that
you ran out of time and had to do something else, and you have two cases:
you _want_ to start up the next time with the half-way done thing (ie
you've marked certain files for committing), or you decide that you would
much prefer to restart from the beginning for next time around. Both are
entirely valid cases, and right now your git commit tool makes it
impossible to do the latter.
So for problems (b)-(c), I _think_ the right answer is to do all the index
work in a new temporary copy of the index, and only on commit (or on "quit
and save current work") do you actually write back to the old index file.
That way, you can also always re-read the original index file to get the
previous state..
As to (a) - I think it would in many ways be nicer if you could have some
way to in addition to the three-way diff also show the regular two-way
diffs for
(i) what would you actually commit
(ii) what are the _additional_ changes there in that file
which is what you'd normally want to see, I think. The three-way diff
shows that, of course, but in a form that most people wouldn't understand,
methinks.
I do have a fourth issue, which is that I hate "gitool" as a name. It
either parses as "gi"+"tool", which makes no sense, or "git"+"ool", which
also makes no sense. "gitk" was cute, "gitool" is just irritating ;)
That said, it definitely has potential.
Linus
^ permalink raw reply
* PATCH 1/4] gitweb: Add GIT favicon, assuming image/png type
From: Jakub Narebski @ 2006-09-04 16:13 UTC (permalink / raw)
To: git
In-Reply-To: <200609041810.09838.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is my first post with binary patch. I'd rather not send file
git-favicon.png as an attachement due to filtering.
You can see (and download) the favicon istelf at
http://git.or.cz/gitwiki/GitRelatedLogos
(the first favicon).
Makefile | 2 ++
gitweb/git-favicon.png | Bin
gitweb/gitweb.perl | 5 +++++
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 199fbe8..f3b762d 100644
--- a/Makefile
+++ b/Makefile
@@ -137,6 +137,7 @@ GITWEB_LIST =
GITWEB_HOMETEXT = indextext.html
GITWEB_CSS = gitweb.css
GITWEB_LOGO = git-logo.png
+GITWEB_FAVICON = git-favicon.png
export prefix bindir gitexecdir template_dir GIT_PYTHON_DIR
@@ -674,6 +675,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_HOMETEXT++|$(GITWEB_HOMETEXT)|g' \
-e 's|++GITWEB_CSS++|$(GITWEB_CSS)|g' \
-e 's|++GITWEB_LOGO++|$(GITWEB_LOGO)|g' \
+ -e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \
$< >$@+
chmod +x $@+
mv $@+ $@
diff --git a/gitweb/git-favicon.png b/gitweb/git-favicon.png
new file mode 100644
index 0000000..de637c0
Binary files /dev/null and b/gitweb/git-favicon.png differ
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7961945..bebaa0f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -48,6 +48,8 @@ # URI of default stylesheet
our $stylesheet = "++GITWEB_CSS++";
# URI of GIT logo
our $logo = "++GITWEB_LOGO++";
+# URI of GIT favicon, assumed to be image/png type
+our $favicon = "++GITWEB_FAVICON++";
# source of projects list
our $projects_list = "++GITWEB_LIST++";
@@ -1192,6 +1194,9 @@ EOF
'href="%s" type="application/rss+xml"/>'."\n",
esc_param($project), href(action=>"rss"));
}
+ if (defined $favicon) {
+ print qq(<link rel="shortcut icon" href="$favicon" type="image/png"/>\n);
+ }
print "</head>\n" .
"<body>\n" .
--
1.4.1.1
^ permalink raw reply related
* [PATCH 3/4] gitweb: Divide page path into directories -- path's "breadcrumbs"
From: Jakub Narebski @ 2006-09-04 16:17 UTC (permalink / raw)
To: git
In-Reply-To: <200609041810.09838.jnareb@gmail.com>
Divide page path into directories, so that each part of path links to
the "tree" view of the $hash_base (or HEAD, if $hash_base is not set)
version of the directory.
If the entity is blob, final part (basename) links to $hash_base or
HEAD revision of the "raw" blob ("blob_plain" view). If the entity is
tree, link to the "tree" view.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 29 +++++++++++++++++++++--------
1 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3b5c0e2..4240a30 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1375,19 +1375,32 @@ sub git_print_page_path {
if (!defined $name) {
print "<div class=\"page_path\">/</div>\n";
- } elsif (defined $type && $type eq 'blob') {
+ } else {
+ my @dirname = split '/', $name;
+ my $basename = pop @dirname;
+ my $fullname = '';
+
print "<div class=\"page_path\">";
- if (defined $hb) {
+ foreach my $dir (@dirname) {
+ $fullname .= $dir . '/';
+ print $cgi->a({-href => href(action=>"tree", file_name=>$fullname,
+ hash_base=>$hb),
+ -title => $fullname}, esc_html($dir));
+ print "/";
+ }
+ if (defined $type && $type eq 'blob') {
print $cgi->a({-href => href(action=>"blob_plain", file_name=>$file_name,
- hash_base=>$hb)},
- esc_html($name));
+ hash_base=>$hb),
+ -title => $name}, esc_html($basename));
+ } elsif (defined $type && $type eq 'tree') {
+ print $cgi->a({-href => href(action=>"tree", file_name=>$file_name,
+ hash_base=>$hb),
+ -title => $name}, esc_html($basename));
+ print "/";
} else {
- print $cgi->a({-href => href(action=>"blob_plain", file_name=>$file_name)},
- esc_html($name));
+ print esc_html($basename);
}
print "<br/></div>\n";
- } else {
- print "<div class=\"page_path\">" . esc_html($name) . "<br/></div>\n";
}
}
--
1.4.1.1
^ permalink raw reply related
* [PATCH 0/4] gitweb: Some improvements
From: Jakub Narebski @ 2006-09-04 16:10 UTC (permalink / raw)
To: git
This is small series of patches, applicable both to 'master' and 'next',
which adds simple improvements, or in the case of last patch
fix bug/typo.
First two patches were sent earlier, I don't know if they were dropped
or forgotten.
---
Diffstat:
Makefile | 2 ++
gitweb/git-favicon.png | Bin
gitweb/gitweb.perl | 44 +++++++++++++++++++++++++++++++-------------
3 files changed, 33 insertions(+), 13 deletions(-)
Shortlog:
gitweb: Add GIT favicon, assuming image/png type.
gitweb: Change the name of diff to parent link in "commit" view to "diff"
gitweb: Divide page path into directories -- path's "breadcrumbs"
gitweb: Correct typo: '==' instead of 'eq' in git_difftree_body
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* [PATCH 4/4] gitweb: Correct typo: '==' instead of 'eq' in git_difftree_body
From: Jakub Narebski @ 2006-09-04 16:19 UTC (permalink / raw)
To: git
In-Reply-To: <200609041810.09838.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This caused that the "commitdiff" version, with "patch" link to anchor
instead of "diff" link to "blobdiff" view was used even in "commit" view.
gitweb/gitweb.perl | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4240a30..e7d7bd7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1519,7 +1519,7 @@ sub git_difftree_body {
$cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
hash_base=>$hash, file_name=>$diff{'file'})},
"blob");
- if ($action == "commitdiff") {
+ if ($action eq 'commitdiff') {
# link to patch
$patchno++;
print " | " .
@@ -1540,7 +1540,7 @@ sub git_difftree_body {
hash_base=>$parent, file_name=>$diff{'file'})},
"blob") .
" | ";
- if ($action == "commitdiff") {
+ if ($action eq 'commitdiff') {
# link to patch
$patchno++;
print " | " .
@@ -1586,7 +1586,7 @@ sub git_difftree_body {
hash_base=>$hash, file_name=>$diff{'file'})},
"blob");
if ($diff{'to_id'} ne $diff{'from_id'}) { # modified
- if ($action == "commitdiff") {
+ if ($action eq 'commitdiff') {
# link to patch
$patchno++;
print " | " .
@@ -1628,7 +1628,7 @@ sub git_difftree_body {
hash=>$diff{'to_id'}, file_name=>$diff{'to_file'})},
"blob");
if ($diff{'to_id'} ne $diff{'from_id'}) {
- if ($action == "commitdiff") {
+ if ($action eq 'commitdiff') {
# link to patch
$patchno++;
print " | " .
--
1.4.1.1
^ permalink raw reply related
* [PATCH 2/4] gitweb: Change the name of diff to parent link in "commit" view to "diff"
From: Jakub Narebski @ 2006-09-04 16:15 UTC (permalink / raw)
To: git
In-Reply-To: <200609041810.09838.jnareb@gmail.com>
Change the name of diff to parent (current commit to one of parents)
link in "commit" view (git_commit subroutine) from "commitdiff" to
"diff". Let's leave "commitdiff" for equivalent of git-show, or
git-diff-tree with one revision, i.e. diff for a given commit to its
parent (parents).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
The commit message is barely smaller than the diff itself, but it
is expected as commit message tell the why behind the change.
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bebaa0f..3b5c0e2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2758,7 +2758,7 @@ sub git_commit {
"<td class=\"link\">" .
$cgi->a({-href => href(action=>"commit", hash=>$par)}, "commit") .
" | " .
- $cgi->a({-href => href(action=>"commitdiff", hash=>$hash, hash_parent=>$par)}, "commitdiff") .
+ $cgi->a({-href => href(action=>"commitdiff", hash=>$hash, hash_parent=>$par)}, "diff") .
"</td>" .
"</tr>\n";
}
--
1.4.1.1
^ permalink raw reply related
* Fix git-fsck-objects SIGSEGV/divide-by-zero
From: Linus Torvalds @ 2006-09-04 15:34 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
If you try to fsck a repository that isn't entirely empty, but that has no
inter-object references (ie all the objects are blobs, and don't refer to
anything else), git-fsck-objects currently fails.
This probably cannot happen in practice, but can be tested with something
like
git init-db
touch dummy
git add dummy
git fsck-objects
where the fsck will die by a divide-by-zero when it tries to look up the
references from the one object it found (hash_obj() will do a modulus by
refs_hash_size).
On some other archiectures (ppc, sparc) the divide-by-zero will go
unnoticed, and we'll instead SIGSEGV when we hit the "refs_hash[j]"
access.
So move the test that should protect against this from mark_reachable()
into lookup_object_refs(), which incidentally in the process also fixes
mark_reachable() itself (it used to not mark the one object that _was_
reachable, because it decided that it had no refs too early).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/object-refs.c b/object-refs.c
index b0034e4..98ea100 100644
--- a/object-refs.c
+++ b/object-refs.c
@@ -55,9 +55,13 @@ static void add_object_refs(struct objec
struct object_refs *lookup_object_refs(struct object *obj)
{
- int j = hash_obj(obj, refs_hash_size);
struct object_refs *ref;
+ int j;
+ /* nothing to lookup */
+ if (!refs_hash_size)
+ return NULL;
+ j = hash_obj(obj, refs_hash_size);
while ((ref = refs_hash[j]) != NULL) {
if (ref->base == obj)
break;
@@ -125,9 +129,6 @@ void mark_reachable(struct object *obj,
if (!track_object_refs)
die("cannot do reachability with object refs turned off");
- /* nothing to lookup */
- if (!refs_hash_size)
- return;
/* If we've been here already, don't bother */
if (obj->flags & mask)
return;
^ permalink raw reply related
* Re: [PATCH] pack-objects: re-validate data we copy from elsewhere.
From: Linus Torvalds @ 2006-09-04 15:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhczos2ak.fsf@assigned-by-dhcp.cox.net>
On Sun, 3 Sep 2006, Junio C Hamano wrote:
>
> So here is a patch against "master" which contains none of the
> earlier patches in this thread.
Ok, this looks good. It only adds two extra seconds for me (after fixing
the patch: "unpack_object_header_gently()" was static to sha1_file.c so
your patch wouldn't actually compile on its own), and it should be a lot
less prone to problems.
Linus
^ permalink raw reply
* Re: New git commit tool
From: Jakub Narebski @ 2006-09-04 12:26 UTC (permalink / raw)
To: git
In-Reply-To: <17660.4995.977221.767112@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
[...]
Added preliminary entry to GitWiki
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#gitool
Please, when adding new tool, announce it also in GitWiki...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
--
VGER BF report: U 0.98878
^ permalink raw reply
* Re: [PATCH] git-repack: clear out tmp packfiles from $PACKDIR instead of cwd
From: Martin Langhoff @ 2006-09-04 12:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edgndv$mtv$1@sea.gmane.org>
On 9/4/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Martin Langhoff wrote:
>
> > On 9/4/06, Martin Langhoff <martin@catalyst.net.nz> wrote:
> >> Temp packfiles should never be created in cwd anyway ;-)
> >
> > Note! Applies after "git-repack: create new packs inside $PACKDIR, not cwd"
> >
> >> VGER BF report: U 0.983488
> >
> > Hilarious!
>
> Isn't 'U' for Undecided? (and 'H' for Ham)?
Maybe -- but the score is really high. This patch was part of a series
of 2 actually. The other one had a score of 1.6 and got bounced. :-/
martin
--
VGER BF report: U 0.558927
^ permalink raw reply
* [PATCH] Do 3-way diff between HEAD, index and working directory
From: Paul Mackerras @ 2006-09-04 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This implements a 3-way diff between the HEAD commit, the state in the
index, and the working directory. This is like the n-way diff for a
merge, and uses much of the same code. It is invoked with the -c flag
to git-diff-index, which it already accepted and did nothing with.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Junio, does this look right? It seems to work OK, and I need it for
my new git commit tool, for the cases where the user has done a
checkin and then further modified the working file. It will be needed
even more when I implement partial checkins within a file.
Thanks,
Paul.
diff --git a/diff-lib.c b/diff-lib.c
index 9edfa92..fc69fb9 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -213,6 +213,31 @@ static int show_modified(struct rev_info
return -1;
}
+ if (revs->combine_merges && !cached &&
+ (hashcmp(sha1, old->sha1) || hashcmp(old->sha1, new->sha1))) {
+ struct combine_diff_path *p;
+ int pathlen = ce_namelen(new);
+
+ p = xmalloc(combine_diff_path_size(2, pathlen));
+ p->path = (char *) &p->parent[2];
+ p->next = NULL;
+ p->len = pathlen;
+ memcpy(p->path, new->name, pathlen);
+ p->path[pathlen] = 0;
+ p->mode = ntohl(mode);
+ hashclr(p->sha1);
+ memset(p->parent, 0, 2 * sizeof(struct combine_diff_parent));
+ p->parent[0].status = DIFF_STATUS_MODIFIED;
+ p->parent[0].mode = ntohl(new->ce_mode);
+ hashcpy(p->parent[0].sha1, new->sha1);
+ p->parent[1].status = DIFF_STATUS_MODIFIED;
+ p->parent[1].mode = ntohl(old->ce_mode);
+ hashcpy(p->parent[1].sha1, old->sha1);
+ show_combined_diff(p, 2, revs->dense_combined_merges, revs);
+ free(p);
+ return 0;
+ }
+
oldmode = old->ce_mode;
if (mode == oldmode && !hashcmp(sha1, old->sha1) &&
!revs->diffopt.find_copies_harder)
--
VGER BF report: U 0.519891
^ permalink raw reply related
* New git commit tool
From: Paul Mackerras @ 2006-09-04 11:52 UTC (permalink / raw)
To: git; +Cc: torvalds
I have been working on a tool for creating commits, and I think it is
now far enough along to be useful. I added it to the 'new' branch of
my gitk.git repository (git://git.kernel.org/pub/scm/gitk/gitk.git) or
you can fetch it from http://ozlabs.org/~paulus/gitool.
The way it works is that one "checks in" a set of changes, types a
message into the lower pane, then clicks the "Commit" button to create
the commit. When the commit has been created, the tool exits.
The changes that have been checked in are recorded in the index.
Gitool can also undo checkins, restoring the index state for a file to
the original state (i.e. the state in the current HEAD commit).
At the top, gitool displays two lists of filenames, with an icon
beside each name. The left-hand list shows modified files (whether
checked in or not), and the right-hand list shows new files (those
just added, and untracked files). Clicking on the icon changes the
state of a file, alternating between not-checked-in and checked-in.
Clicking on the filename displays something useful; for a modified
file, it shows the changes made; for a new or untracked file, it shows
the contents of the file.
Files can also be partly checked in, for example, if changes were made
and checked in, and then further changes were made. Clicking on such
a file will show a 3-way diff (HEAD vs. checked-in state vs. working
file), provided Junio applies my patch to diff-lib.c. :)
Gitool doesn't handle merge commits yet, but that is something I want
to implement soon, hopefully with the ability to resolve merge
conflicts in the tool. There are quite a few other features I want to
implement as well (key bindings, font size selection, persistent
geometry).
Comments and suggestions are welcome. Patches are even more
welcome. :)
Paul.
--
VGER BF report: U 0.977306
^ permalink raw reply
* Re: [PATCH] git-repack: create new packs inside $PACKDIR, not cwd
From: Martin Langhoff (CatalystIT) @ 2006-09-04 10:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkp0ndmj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> writes:
>
>
>>BTW, I think there's a small error.
>>
>>Your packtmp includes $$ which means that rm -f "$PACKTMP" will only
>>clear out old packs..
>
>
> That was deliberate. I hate programs that clean things up
> behind user's back. The first "rm" is to get rid of what would
> collide with what we are going to do (i.e. protecting ourselves)
> and "trap rm" is to make sure we do not leave the cruft we know
> we are going to create. I'd rather leave other people's cruft
> around, unless the purpose of the command is to clean things up,
> and repack is hardly that.
>
Ah, ok. I misunderstood the use of trap -- of course, re-reading the man
pages, it makes sense.
A-ok with me, then, and sorry about the noise.
martin
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
--
VGER BF report: H 0.0618878
^ 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