* Re: [PATCH 3/3] Teach git-index-pack how to keep a pack file.
From: Jakub Narebski @ 2006-10-29 10:49 UTC (permalink / raw)
To: git
In-Reply-To: <20061029094159.GE3847@spearce.org>
Shawn Pearce wrote:
> +--keep::
> + Before moving the index into its final destination
> + create an empty .keep file for the associated pack file.
> + This option is usually necessary with --stdin to prevent a
> + simultaneous gitlink:git-repack[1] process from deleting
> + the newly constructed pack and index before refs can be
> + updated to use objects contained in the pack.
> +
> +--keep='why'::
> + Like --keep create a .keep file before moving the index into
> + its final destination, but rather than creating an empty file
> + place 'why' followed by an LF into the .keep file. The 'why'
> + message can later be searched for within all .keep files to
> + locate any which have outlived their usefulness.
Wouldn't it be better to use 'git-index-pack', perhaps with source URL if
possible, as the default 'why'?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-29 10:59 UTC (permalink / raw)
To: git
In-Reply-To: <200610290116.19796.jnareb@gmail.com>
I had to resend the patch due to "DOT info" being on list of banned
words...
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Junio C Hamano @ 2006-10-29 11:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610291122.30852.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Changes:
> * "gitweb diff header" which looked for example like below:
> file:_<sha1 before>_ -> file:_<sha1 after>_
> where 'file' is file type and '<sha1>' is full sha1 of blob, is link
> and uses default link style is changed to
> diff --git a/<file before> b/<file after>
> where <file> is hidden link (i.e. underline on hover, only)
> to appropriate version of file. If file is added, a/<file> is not
> hyperlinked, if file is deleted, b/<file> is not hyperlinked.
I do not have time to look at the code right now, but here are
quick comments on the output.
I personally do not mind "hidden" but it might be more obvious
to make them normal links -- the filenames in the header are not
part of long text people need to "read". On the other hand,
it feels a bit wasteful to have these hidden links both on "diff
--git" line *and* ---/+++ lines (these three are very close to
each other).
> * there is added "extended diff header", with <path> and <hash>
> hyperlinked (and <hash> shortened to 7 characters), and <mode>
> explained: '<mode>' is extnded to '<mode>/<symbolic mode> (<file type>)'.
It somehow feels that deviating from what "git diff" gives makes
it very distracting; I would feel better if "/-rw-r--r-- (file)"
were not there.
Also I think arguing over 7 or 8 hexdigits is pointless; if you
are reading this from "git diff", it is probably the easiest to
match what "git diff" gave you. One thing we _might_ want to do
in the future is to change "git diff" to use DEFAULT_ABBREV
hexdigits at the minimum but more if needed to disambiguate; I
think it currently does not do the "more if needed" part.
> * <file> hyperlinking should work also when <file> is originally
> quoted. For now we present filename quoted. This needed changes to
> parse_difftree_raw_line subroutine.
This feels Ok.
> * from-file/to-file two-line header lines have slightly darker color
> than removed/added lines.
This visually feels right.
> * chunk header has now delicate line above for easier finding chunk
> boundary, and top margin of 1px.
This visually feels right.
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-29 12:01 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <m3fyd77gsn.fsf@iny.iki.fi>
Ilpo Nyyssönen wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Ilpo Nyyssönen wrote:
>>
>>> Usability:
>>>
>>> I have used bzr, bk for development and git very little for following
>>> kernel development. I have followed this discussion quite well.
>>>
>>> 1. It is easier to start using something you are already familiar
>>> with. (Just try to use Mac OS X with a Windows or Linux background.)
>>>
>>> G: Something totally new and so no points from here. The way of using
>>> git is just so different from any other similar software.
>>>
>>> B: Quite clearly gets points from this. Normal branches work quite
>>> like many other software, the checkout stuff works like CVS and SVN.
>>
>> I find for example concept of branches in Git extremly easy to
>> understand.
>
> Might be, but the point was: Git is harder as it is not like others.
> In other hand one can see Bazaar like other distributed SCMs and even
> like the not distributed ones as it has the checkout stuff.
>
> You can give Bazaar for me, a bk user, and I can understand what to do
> with the branches that are like bk clones. (The repository stuff is
> later development and still optional.) Switching a CVS environment to
> Bazaar one can be done so that most of the users can be just told to
> use bzr checkout and they don't have to care about pushing.
That is of course because you are familiar with branch-centric distributed
SCM, namely BitKeeper, when trying Bazaar-NG. IMHO branch-centric view
is somewhat limiting; you can always use repository-centric SCM with
one-live-branch-per-repository paradigm and emulate branch-centric SCM,
which is not (or not always) the case for branch-centric SCM. Branch-centric
and repo-centric SCM promote different workflows, namely parallel uncommited
work on few development branches for branch-centric SCM, one-change
per-commit multiple temporary and feature branches for repo-centric SCM.
Breaking from CVS update-then-commit stupid model is IMHO very, very good
idea. On the par of breaking from CVS "model" of branches. In my opinion
CVS had one very good idea (perhaps it wasn't originally CVS idea), namely
using merge instead of locking files for editing; well that and the fact
that it tried (emphasisis on tried) to treat module as a whole, allowing
for multi-file change commits.
Take for example the case of WordProcessors: if they all would only emulate
the UI of leading one (most commonly used), no progress would be made.
> But with git, I clone some repository. Now it is totally new to
> understand that I didn't clone only single branch. It's like nothing
> else and that's what I saw when I first looked at it. I might have
> even not noticed the branch stuff and just cloned it further.
That's the shift of paradigm. Instead of one-branch-per-repository, and
one-branch-per-developer workflow which I think usually stems from that, we
have one-repository-per-developer (usually), and heavily nonlinear
development.
>> On the other side breaking with traditional concepts of _centralized_ SCM
>> in _distributed_ SCM (and geared towards distributed usage) is IMVHO a
>> good idea. And breaking with the cruft of bad ideas of CVS is very good
>> idea.
>
> Breaking concepts can be a good idea and I somewhat think that git
> needed to do what it did. But do remember that it came with a cost:
> git is harder to understand and use. You first have to understand that
> it is different and how it is different.
The same could be said about moving from MS-DOS or later MS Windows to the
world of UNIX.
But yes, I understand and agree that being different than others can be
disadvantage... and can be advantage.
>> I don't understand the confusion between "git branch" and "git clone"
>> commands... unless you are confused by Bazaar-NG branch-centric approach
>> which mixes branch with repository.
>
> Those commands do so different things in different SCMs. Just look at
> the differences bk clone, git clone, git branch and bzr branch. You
> have both. At the point where I didn't yet understand that I cloned
> more than a one branch, git branch is very odd looking command.
I for example didn't understand "bzr branch" concept, being familiar rather
with "git branch".
>> Which long lasting operations lack progress bar/progress reporting?
>> "git clone" and "git fetch"/"git pull" both have progress report
>
> First note that I didn't notice git repack until recently so things
> got slower until that.
>
> At least some points they just tell that they are doing something, but
> not how much of it has been done and how much is still to do. Look at
> Bazaar and you'll see the difference, it has progress bars.
Well, having progress bars for operations which are usually fast and one
step is in my opinion stupid idea. Even if there are combinations of
options which makes them slow (for example using so called pickaxe,
e.g. "git log -S'fragment' -- file" to find revisions which introduced
'fragment' to 'file').
I'll ask again: _which_ git commands you find lacking progress reporting?
>>> You can't just diff branchA/foo branchB/foo.
>>
>> You can: either using "git diff branchA branchB -- foo" which means
>
> Exactly my point: it forces you to use git more. In Bazaar I can do
> this without Bazaar commands. I could even do it with some Windows GUI
> stuff, take two files or directories and compare.
>
> As you need to use git commands more than bzr commands, git has bigger
> requirements for usability.
But git commands are more powerfull than equivalent GNU commands. git-diff
is more powerfull than GNU diff (for example it can detect renames and
copying, it shows mode changes, it can show diff for merge using "combined
diff" format), git-grep is more powerfull than GNU grep (for example Linus
finds himself to put files in git repository to use git-grep instead of
combination of GNU find and GNU grep).
And don't forget about _cost_ of doing that abovementioned way, namely
having to keep two copies of working area (differing in revision, of
course).
>>> You can't just open file from old branch to check
>>> something while you are developing in some new branch.
>>
>> You can view file from old branch via "git cat-file -p old-branch:file".
Or you can "git commit -a -m 'TEMP'" to save changes, "git checkout
<branch>" to switch to other branch, perhaps git-clean, hack; hack; hack;
commit changes, swotch back to branch, and wiether amend the commit or reset
index and HEAD (but not working area).
> Same thing here, in Bazaar, I can just open the file from the other
> branch. I can also compile and run the other branch while I have the
> other open.
Do you really often compile and run other branch while developing on other?
> Essentially I would need a separate git repository for each branch
> anyway. In Bazaar I can use the same.
Well, that's a fact that git lacks somewhat (but not lack completly) support
for multiple independent workplaces for the same repository (link+separate
index+separate HEAD), and lacks somewhat (but not completely) support for
sharing object database between repositories aka. bzr model (you have to be
very careful with pruning).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-29 12:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viri34a3k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Changes:
>> * "gitweb diff header" which looked for example like below:
>> file:_<sha1 before>_ -> file:_<sha1 after>_
>> where 'file' is file type and '<sha1>' is full sha1 of blob, is link
>> and uses default link style is changed to
>> diff --git a/<file before> b/<file after>
>> where <file> is hidden link (i.e. underline on hover, only)
>> to appropriate version of file. If file is added, a/<file> is not
>> hyperlinked, if file is deleted, b/<file> is not hyperlinked.
>
> I do not have time to look at the code right now, but here are
> quick comments on the output.
Code is a bit horrible I think in trying to be smart and avoid
code repetition.
> I personally do not mind "hidden" but it might be more obvious
> to make them normal links -- the filenames in the header are not
> part of long text people need to "read". On the other hand,
> it feels a bit wasteful to have these hidden links both on "diff
> --git" line *and* ---/+++ lines (these three are very close to
> each other).
Good idea. We have lost visible links with the change. And easy to
implement: just remove style override for .diff.header a.list from
CSS (or what would be better but harder to code remove "list" class
from <a> element in "git header").
Originally there was visible link with full sha1 of blob as text,
and hidden link with filename as text; perhaps dropping the latter
---/+++ line link is better idea (here hyperlink should I think be
hidden, if there is any, to match git-diff and GNU diff -u output).
And this would simplify code somewhat...
The hidden (but here I think we can change to not-hidden links) links
in the "index" extended header line are to stay I think: this is the
only place where we can have links to all the versions of file in the
future combined commitdiff format.
>> * there is added "extended diff header", with <path> and <hash>
>> hyperlinked (and <hash> shortened to 7 characters), and <mode>
>> explained: '<mode>' is extnded to '<mode>/<symbolic mode> (<file type>)'.
>
> It somehow feels that deviating from what "git diff" gives makes
> it very distracting; I would feel better if "/-rw-r--r-- (file)"
> were not there.
Well, the old version had "(<file type>)" in gitweb diff header.
Not all git/gitweb users are familiar with POSIX numeric modes;
perhaps changing the style (color for example) of added stuff
to mark it as added would be enough?
> Also I think arguing over 7 or 8 hexdigits is pointless; if you
> are reading this from "git diff", it is probably the easiest to
> match what "git diff" gave you. One thing we _might_ want to do
> in the future is to change "git diff" to use DEFAULT_ABBREV
> hexdigits at the minimum but more if needed to disambiguate; I
> think it currently does not do the "more if needed" part.
I used 7 hexdigits because git-diff uses 7 by default.
>> * <file> hyperlinking should work also when <file> is originally
>> quoted. For now we present filename quoted. This needed changes to
>> parse_difftree_raw_line subroutine.
>
> This feels Ok.
I'm not sure if we shouldn't unquote filename always, or at least
remove double quotes surrounding filename, or [ab]/filename. The decision
to leave visible filename quoted was based on the troubles to code
it correctly in "git diff" header where one of the filenames might
not be hyperlinked: if file was added or deleted.
>> * from-file/to-file two-line header lines have slightly darker color
>> than removed/added lines.
>
> This visually feels right.
What is left is fine-tuning the color.
>> * chunk header has now delicate line above for easier finding chunk
>> boundary, and top margin of 1px.
>
> This visually feels right.
What is left is fine-tuning the line and vertical space.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Anand Kumria @ 2006-10-29 12:44 UTC (permalink / raw)
To: git
In-Reply-To: <200610291122.30852.jnareb@gmail.com>
On Sun, 29 Oct 2006 11:22:30 +0100, Jakub Narebski wrote:
> You should be able to check new commitdiff view at
> http://roke_DOT_dyndns_DOT_info/cgi-bin/gitweb/gitweb.cgi
> (URL mangling courtesy vger banned words list, aaaarrghhh)
> if I didn't screwed something again with firewall, and when my machine
> is up; should be for at least an hour. Check for example:
> ?p=git.git;a=commitdiff;h=origin
> ?p=git.git;a=commitdiff;h=161332a521fe10c41979bcd493d95e2ac562b7f
> ?p=git.git;a=commitdiff;h=e12c095aa69d8aca0326eb11960427d9bf9e2db7
> ?p=git.git;a=commitdiff;h=82560983997c961d9deafe0074b787c8484c2e1d
> and compare to (for example)
> http://repo.or.cz/w/git.git?a=commitdiff;h=82560983997c961d9deafe0074b787c8484c2e1d
> or (even older gitweb)
> http://www.kernel.org/git/?p=git/git.git;a=commitdiff;h=887a612fef942dd3e7dae452e2dc582738b0fb41
> BTW. this gitweb has also my previous "Slight improvement" patch applied.
>
> Do you like it? What should be changed (code, output, style)?
I think your version looks a lot nicer but I believe that the commit
message area should be in a fixed-point font. In general it won't be a
problem but if anyone should choose to insert a diagram or something else
that assume a fixed-width display - it won't look good.
Anand
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-29 12:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200610291324.42566.jnareb@gmail.com>
Jakub Narebski wrote:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>>
>>> * there is added "extended diff header", with <path> and <hash>
>>> hyperlinked (and <hash> shortened to 7 characters), and <mode>
>>> explained: '<mode>' is extnded to '<mode>/<symbolic mode> (<file type>)'.
>>
>> It somehow feels that deviating from what "git diff" gives makes
>> it very distracting; I would feel better if "/-rw-r--r-- (file)"
>> were not there.
>
> Well, the old version had "(<file type>)" in gitweb diff header.
> Not all git/gitweb users are familiar with POSIX numeric modes;
> perhaps changing the style (color for example) of added stuff
> to mark it as added would be enough?
Or we could use the following code:
<abbr title="100755/-rwxr-xr-x (file)">100755</abbr>
which gives explanation on mouse-over.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-29 15:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viri34a3k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Changes:
[...]
>> * <file> hyperlinking should work also when <file> is originally
>> quoted. For now we present filename quoted. This needed changes to
>> parse_difftree_raw_line subroutine.
>
> This feels Ok.
Emphasisis on "should". Check
http://roke(.)dyndns(.)info/cgi-bin/gitweb/gitweb.cgi?p=git.git;a=commitdiff;h=gitweb/test
By the way, should we use quoted or unquoted filename?
--
Jakub Narebski
^ permalink raw reply
* [PATCH] Stgit: allow importing series files where patch names include slashes
From: Paolo 'Blaisorblade' Giarrusso @ 2006-10-29 17:35 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Do that by converting slashes in patch name to dashes. Actually one could think
that different quilt folders relate to topic branches, but I do not see an
obviously correct mapping nor users which would do that.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
stgit/commands/imprt.py | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/imprt.py b/stgit/commands/imprt.py
index 1b7dce8..c8cf42b 100644
--- a/stgit/commands/imprt.py
+++ b/stgit/commands/imprt.py
@@ -85,6 +85,11 @@ def __strip_patch_name(name):
return stripped
+def __replace_slashes_with_dashes(name):
+ stripped = name.replace('/', '-')
+
+ return stripped
+
def __parse_description(descr):
"""Parse the patch description and return the new description and
author information (if any).
@@ -299,6 +304,7 @@ def __import_series(filename, options):
if options.strip:
patch = __strip_patch_name(patch)
+ patch = __replace_slashes_with_dashes(patch);
if options.ignore and patch in applied:
print 'Ignoring already applied patch "%s"' % patch
continue
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
^ permalink raw reply related
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-29 17:50 UTC (permalink / raw)
To: git
In-Reply-To: <200610291122.30852.jnareb@gmail.com>
A couple of questions regarding new patchset/diff look for gitweb.
Currently patch starts with "git diff" header
diff --git a/file1 b/file2
then we have a couple of extended header lines
old|new|deleted file|new file mode <mode>
copy|rename from|to <path>
(dis)?similarity index <percent>
index <hash>..<hash> [<mode>]
then we have two-line from-file/to-file header
--- a/file1
+++ b/file2
then patch itself.
1. Which parts to convert to hyperlinks, and which to do not? Which
links have visible and which hidden (underline on mouseover, the same
color as neighbouring text)?
I think that a/file1 in "git diff" header should be turned into
visible hyperlink unless file is created, and b/file2 should be link
unless file is deleted.
Also both <hash>-es in "index" extended header lines should be turned
into links, as it is the only way to have hyperlink to all previous
versions of the file in the case of "combined diff" format (to be
added later). The question is if those hyperlinks should be visible;
I don't have compelling reason against. Should we use title attribute
to give filename perhaps, or is it unnecessary?
Currently file1 and file2 in "--- a/file1" and "+++ b/file2" are
turned into hidden links. Should we leave it, or should we remove
this link as we have similar link just above? If we decide to have
this link, should we also hyperlink <path> in "copy|rename" extended
header line?
2. Use quoted or unquoted filename, remove or leave surrounding quotes
in quoted filename? Should we unquote the not hyperlinked filename
in the case of creation/deletion? What should be span of link:
"a/_file1_", "_a/file1_", _"a/file1"_
"_file_", _"file"_
(where '_' marks beginning and end of link) for quoted filenames?
What should be span of link for unquoted filenames:
a/_file_, _a/file_
Currently gitweb uses a/_file_ in ---/+++ line.
3. How (and if) to explain numerical mode: the currently used
<mode>/<symbolic mode> (<file type>) e.g. 100755/-rwxr-xr-x (file).
Or <mode> (<file type>) should be enough? Should we mark the addition
compared to git-diff output? Or should we explain <mode> only on
mouseover, using for example:
<abbr title="100644/-rw-r--r-- (file)">100644</abbr>
or just
<abbr title="executable file">100755</abbr>?
--
Jakub Narebski
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-29 18:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <ei2563$m1u$1@sea.gmane.org>
On Sun, Oct 29, 2006 at 01:01:07PM +0100 I heard the voice of
Jakub Narebski, and lo! it spake thus:
>
> Branch-centric and repo-centric SCM promote different workflows,
> namely parallel uncommited work on few development branches for
> branch-centric SCM, one-change per-commit multiple temporary and
> feature branches for repo-centric SCM.
I don't think that follows at all.
> Do you really often compile and run other branch while developing on
> other?
Yes. And I do the same with older revisions along a given branch too,
where is where [lightweight] checkouts come in handy.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-29 18:39 UTC (permalink / raw)
To: Matthew D. Fuller; +Cc: bazaar-ng, git
In-Reply-To: <20061029182454.GT17019@over-yonder.net>
Matthew D. Fuller wrote:
> On Sun, Oct 29, 2006 at 01:01:07PM +0100 I heard the voice of
> Jakub Narebski, and lo! it spake thus:
>>
>> Do you really often compile and run other branch while developing on
>> other?
>
> Yes. And I do the same with older revisions along a given branch too,
> where is where [lightweight] checkouts come in handy.
Well, if you don't _work_ on other branch, you can alwaych checkout
the other branch or any given revision from a separate directory
using
git --git-dir=<path to repo> tar-tree <revision> | tar xf -
for example.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Junio C Hamano @ 2006-10-29 18:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610291850.46321.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> A couple of questions regarding new patchset/diff look for gitweb.
> Currently patch starts with "git diff" header
>
> diff --git a/file1 b/file2
>
> then we have a couple of extended header lines
>
> old|new|deleted file|new file mode <mode>
> copy|rename from|to <path>
> (dis)?similarity index <percent>
> index <hash>..<hash> [<mode>]
>
> then we have two-line from-file/to-file header
>
> --- a/file1
> +++ b/file2
>
> then patch itself.
Before answering 3 questions, I think we need to ask a bigger
question. What is the primary target audience of gitweb?
If it is for git-uninitiated, then staying as close to what GNU
diff would give would be a better idea. I would say we at least
can assume that the user has some familiarity with SCM, and
knows what kind of information is kept track of and is shown as
differences between versions, and what files, directories and
symlinks are, but not how git represents these. On the other
hand, if the user uses git to track a project (not necessarily
the project the user is looking at with gitweb) and is familiar
with the way git-diff presents these information, deviating from
git-diff output is distractiing.
At least to me /-rw-rw-... part made me feel uneasy for that
reason.
WIth that in mind, I'll think aloud what I would like if I were
not familiar with git:
* "diff --git a/file b/file" would not use /dev/null but
---/+++ does. If the former is shown as link, it should be
visible which side is a link and which side is not for
creation or deletion diff; otherwise you would need a second
to realize it is not a bug that clicking on a/file on the
"diff --git" line did not show anything for a creation diff.
* I think showing object names in "index xxx..yyy mode" line is
not very useful to humans (they are added for tools). I do
agree that we would want some clickable handle in combined
diff output, but people not familiar with git would not know
that "index xxx,yyy..zzz" is where you would find the
parents, so that line needs to be munged anyway.
Side note: Even though some git people (Luben, for example)
claim they recognize some abbreviated object names, I suspect
that are mostly recent commits and not blobs.
* Mode on the "index" line may be useful, but as you say 100644
is probably too git specific; however if our audience is
git-uninitiated, I doubt -rw-r--r-- is much better (it is
UNIXism, which I personally do not mind). Spelling them out
like "regular file", "executable file", or "symbolic link"
might be more readable. And spelling them out is more
technically correct; when git says 100644, it does _not_ mean
"-rw-r--r--", but it means "regular file, not executable"
(IOW, we borrowed the octal bits from POSIX but it means
slightly a different thing).
* So the above two together suggests that I probably would want
to see something like:
diff --git a/file b/file (regular file)
with a/file and b/file as visible links for one parent diff.
For combined,
diff --cc a/file b/file (regular file)
with perhaps a/file be a pop-up window that has a list of
links to parent blobs (b/file is a link to the merge result
blob), or maybe
diff --cc a/file (parent1 parent2) b/file (regular file)
where parent#N is a link to the blob in the parent (a/file is
not clickable, b/file is the link to the result blob).
* I think redundant links to blobs in extended headers (rename
from ... to ...) and ---/+++ lines are Ok, but as other
redundant links they probably are better kept half-hidden
(i.e. react to mouse-over like commit titles) to avoid visual
distraction.
* I think the filename quoting is better left as-is, since it
is a way to indicate something funny is going on.
One thing I noticed while browsing gitweb/ part is that we
quote byte values above 128; we might want to change
quote_c_style_counted() to either use unsigned char to avoid
this, or explicitly use signed char to keep this across
platforms (char could be unsigned char).
^ permalink raw reply
* Re: Generating docu in 1.4.3.3.g01929
From: Horst H. von Brand @ 2006-10-29 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, git, Horst H. von Brand
In-Reply-To: <7vmz7g8don.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
[...]
> and here is what I have:
>
> asciidoc-7.0.2-3.fc6
> xmlto-0.0.18-13.1
> python-2.4.3-18.fc6
> docbook-dtds-1.0-30.1
> package docbook-xsl is not installed
> flex-2.5.4a-41.fc6
> libxslt-1.1.17-1.1
> passivetex-1.25-5.1.1
> util-linux-2.13-0.44.fc6
> w3m-0.5.1-14.1
I've got:
asciidoc-7.0.2-3.fc6
xmlto-0.0.18-13.1
python-2.4.4-1.fc7
docbook-dtds-1.0-30.1
package docbook-xsl is not installed
flex-2.5.4a-41.fc6
libxslt-1.1.18-1
passivetex-1.25-5.1.1
util-linux-2.13-0.44.fc6
w3m-0.5.1-14.1
> "rpm -q --whatprovides docbook-xsl" says:
>
> docbook-style-xsl-1.69.1-5.1
docbook-style-xsl-1.69.1-5.1
Differences are (mine (Junio's)):
python-2.4.4-1.fc7 (python-2.4.3-18.fc6)
libxslt-1.1.18-1 (libxslt-1.1.17-1.1)
libxslt requires libxml2:
libxml2-2.6.27-1 (Fedora 6 has libxml2-2.6.26-2.1.1)
Getting the Fedora 6 libxslt (Junio's) and redoing git gives no errors.
Judging from the libxslt changelog <http://xmlsoft.org/XSLT/news.html> they
tightened up the processing, so I'd guess asciidoc is generating fishy XML
or xmlto is broken. I've no clue here... somebody knowledgeable who can
take a closer look or otherwise lend me a hand?
Thanks!
PS: I get similar errors with tig...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: [PATCH 3/3] Teach git-index-pack how to keep a pack file.
From: Junio C Hamano @ 2006-10-29 19:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Shawn Pearce
In-Reply-To: <ei210e$dfs$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Wouldn't it be better to use 'git-index-pack', perhaps with source URL if
> possible, as the default 'why'?
I think it is sensible that Shawn did keep="reason" because
git-index-pack usually cannot decide. .keep would be around for
at least three reasons:
- you as the repository owner want to keep the pack from
repacked because that is the big "initial clone" pack;
- somebody fetched with --keep and index-pack created .keep
flag, but somehow the fetch-pack after updating the refs
failed to remove the flag (or has not finished);
- somebody pushed into the repository with --keep but somehow
the receive-pack after updating the refs failed to remove the
flag (or has not finished);
For a shared repository settings, the person who cares about .keep
is the person who logged onto the machine with the repository and
ran "clone" (or "init-db && fetch-pack") to prepare the initial
state, and fetching would be done by smaller group of people
than pushing into it. So these three kinds need to be easily
distinguishable by the repository owner. The first kind would
not be usually removed; the second one the owner is likely to
know if that fetch is still running, and if it is known that
fetch is not running then .keep should probably be removed. The
third kind is harder to tell if it is safe to remove .keep
because usually more people can push into it than fetch into it.
It might be a good idea to leave process ID of the caller of the
index-pack as part of --keep="reason" string, along with the
timestamp to help the user decide if the .keep is leftover or
still in progress (the timestamp can be seen from ls -l *.keep
so it is not strictly needed).
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Luben Tuikov @ 2006-10-29 19:31 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <200610291122.30852.jnareb@gmail.com>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Changes:
> * "gitweb diff header" which looked for example like below:
> file:_<sha1 before>_ -> file:_<sha1 after>_
> where 'file' is file type and '<sha1>' is full sha1 of blob, is link
> and uses default link style is changed to
> diff --git a/<file before> b/<file after>
> where <file> is hidden link (i.e. underline on hover, only)
> to appropriate version of file. If file is added, a/<file> is not
> hyperlinked, if file is deleted, b/<file> is not hyperlinked.
I like it and I like the "hidden" links.
> * there is added "extended diff header", with <path> and <hash>
> hyperlinked (and <hash> shortened to 7 characters), and <mode>
> explained: '<mode>' is extnded to '<mode>/<symbolic mode> (<file type>)'.
I like that too, but would leave "100644/-rw-r--r-- (file)" out.
There is a bug in the code: the first index link is the same
as the second, while the first should upload the sha-7 it points to.
For example:
index 743f02b..c821e22
Both point to c821e22. Please fix that.
> * <file> hyperlinking should work also when <file> is originally
> quoted. For now we present filename quoted. This needed changes to
> parse_difftree_raw_line subroutine.
I didn't see where you've quoted file names, but I'm a bit hesitant
to quote anything unnecessarily in the visual output.
> * from-file/to-file two-line header lines have slightly darker color
> than removed/added lines.
Good.
> * chunk header has now delicate line above for easier finding chunk
> boundary, and top margin of 1px.
Good.
> Controversial ideas:
> * All links in patch header are hidden
Love those hidden gems.
> * Hashes are shortened to 7 characters
That's ok as long as the output is consisent with real git diff.
That is, a user using git can recognize this commitdiff output and a user
using this gitweb commitdiff output can recognize a git diff output.
> * Filenames are presented quoted
I wouldn't do that.
> * Marking of chunk beginning
I like the fine lines and their color as it is shown in your server.
> * No hyperlink for renamed from/to header (bug)
I'm sure you'll fix that.
Overall I like this patch. Why? Because it makes gitweb commitdiff
output as similar as possible to git-diff output. This is always a good
thing, since both beginners and advanced git users can recognize one
or the other depending where they are coming from (gitweb or git).
Luben
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.css | 46 ++++++++++++---
> gitweb/gitweb.perl | 159 ++++++++++++++++++++++++++++++---------------------
> 2 files changed, 131 insertions(+), 74 deletions(-)
>
> diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
> index 83d900d..3aeceed 100644
> --- a/gitweb/gitweb.css
> +++ b/gitweb/gitweb.css
> @@ -303,6 +303,33 @@ td.mode {
> font-family: monospace;
> }
>
> +
> +div.diff.header,
> +div.diff.extended_header {
> + white-space: normal;
> +}
> +
> +div.diff.header {
> + font-weight: bold;
> +
> + background-color: #edece6;
> +
> + margin-top: 4px;
> + padding: 4px 0px 2px 0px;
> + border: solid #d9d8d1;
> + border-width: 1px 0px 1px 0px;
> +}
> +
> +div.diff.extended_header,
> +div.diff.extended_header a.list {
> + color: #777777;
> +}
> +
> +div.diff.extended_header {
> + background-color: #f6f5ee;
> + padding: 2px 0px 2px 0px;
> +}
> +
> div.diff a.list {
> text-decoration: none;
> }
> @@ -312,31 +339,34 @@ div.diff a.list:hover {
> }
>
> div.diff.to_file a.list,
> -div.diff.to_file,
> +div.diff.to_file {
> + color: #007000;
> +}
> +
> div.diff.add {
> color: #008800;
> }
>
> div.diff.from_file a.list,
> -div.diff.from_file,
> +div.diff.from_file {
> + color: #aa0000;
> +}
> +
> div.diff.rem {
> color: #cc0000;
> }
>
> div.diff.chunk_header {
> color: #990099;
> + border: dotted #ffbbff;
> + border-width: 1px 0px 0px 0px;
> + margin-top: 1px;
> }
>
> div.diff.incomplete {
> color: #cccccc;
> }
>
> -div.diff_info {
> - font-family: monospace;
> - color: #000099;
> - background-color: #edece6;
> - font-style: italic;
> -}
>
> div.index_include {
> border: solid #d9d8d1;
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index cbab3c9..2d971ac 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1255,9 +1255,12 @@ sub parse_difftree_raw_line {
> $res{'status'} = $5;
> $res{'similarity'} = $6;
> if ($res{'status'} eq 'R' || $res{'status'} eq 'C') { # renamed or copied
> - ($res{'from_file'}, $res{'to_file'}) = map { unquote($_) } split("\t", $7);
> + ($res{'from_file_raw'}, $res{'to_file_raw'}) = split("\t", $7);
> + $res{'from_file'} = unquote($res{'from_file_raw'});
> + $res{'to_file'} = unquote($res{'to_file_raw'});
> } else {
> - $res{'file'} = unquote($7);
> + $res{'file_raw'} = $7;
> + $res{'file'} = unquote($res{'file_raw'});
> }
> }
> # 'c512b523472485aef4fff9e57b229d9d243c967f'
> @@ -2024,6 +2027,7 @@ sub git_patchset_body {
> my $in_header = 0;
> my $patch_found = 0;
> my $diffinfo;
> + my (@from_subst, @to_subst);
>
> print "<div class=\"patchset\">\n";
>
> @@ -2033,6 +2037,7 @@ sub git_patchset_body {
>
> if ($patch_line =~ m/^diff /) { # "git diff" header
> # beginning of patch (in patchset)
> +
> if ($patch_found) {
> # close previous patch
> print "</div>\n"; # class="patch"
> @@ -2042,11 +2047,59 @@ sub git_patchset_body {
> }
> print "<div class=\"patch\" id=\"patch". ($patch_idx+1) ."\">\n";
>
> + # read and prepare patch information
> if (ref($difftree->[$patch_idx]) eq "HASH") {
> + # pre-parsed (or generated by hand)
> $diffinfo = $difftree->[$patch_idx];
> } else {
> $diffinfo = parse_difftree_raw_line($difftree->[$patch_idx]);
> }
> + if ($diffinfo->{'status'} ne "A") { # not new (added) file
> + my $quot = '';
> + my $from_text;
> + my $file_raw = $diffinfo->{'from_file_raw'} || $diffinfo->{'file_raw'};
> + if ($file_raw =~ s/^"(.*)"$/\1/) {
> + $from_text = qq("a/$file_raw");
> + $quot = '"';
> + } else {
> + $from_text = qq(a/$file_raw);
> + }
> + my $file = $diffinfo->{'from_file'} || $diffinfo->{'file'};
> + my $from_link =
> + $cgi->a({-href => href(action=>"blob", hash_base=>$hash_base,
> + hash=>$diffinfo->{'from_id'}, file_name=>$file),
> + -class => "list"}, esc_html($file_raw));
> + my $hash_link =
> + $cgi->a({-href => href(action=>"blob", hash_base=>$hash_base,
> + hash=>$diffinfo->{'to_id'}, file_name=>$file),
> + -class => "list"}, substr($diffinfo->{'from_id'},0,7));
> + @from_subst =
> + ($from_text, "${quot}a/$from_link${quot}",
> + $diffinfo->{'from_id'} . '\.\.', "$hash_link..");
> + }
> + if ($diffinfo->{'status'} ne "D") { # not deleted file
> + my $quot = '';
> + my $to_text;
> + my $file_raw = $diffinfo->{'to_file_raw'} || $diffinfo->{'file_raw'};
> + if ($file_raw =~ s/^"(.*)"$/\1/) {
> + $to_text = qq("b/$file_raw");
> + $quot = '"';
> + } else {
> + $to_text = qq(b/$file_raw);
> + }
> + my $file = $diffinfo->{'to_file'} || $diffinfo->{'file'};
> + my $to_link =
> + $cgi->a({-href => href(action=>"blob", hash_base=>$hash_base,
> + hash=>$diffinfo->{'to_id'}, file_name=>$file),
> + -class => "list"}, esc_html($file_raw));
> + my $hash_link =
> + $cgi->a({-href => href(action=>"blob", hash_base=>$hash_base,
> + hash=>$diffinfo->{'to_id'}, file_name=>$file),
> + -class => "list"}, substr($diffinfo->{'to_id'},0,7));
> + @to_subst =
> + ($to_text, "${quot}b/$to_link${quot}",
> + '\.\.' . $diffinfo->{'to_id'}, "..$hash_link");
> + }
> $patch_idx++;
>
> # for now we skip empty patches
> @@ -2056,82 +2109,56 @@ sub git_patchset_body {
> next LINE;
> }
>
> - if ($diffinfo->{'status'} eq "A") { # added
> - print "<div class=\"diff_info\">" . file_type($diffinfo->{'to_mode'}) . ":" .
> - $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
> - hash=>$diffinfo->{'to_id'}, file_name=>$diffinfo->{'file'})},
> - $diffinfo->{'to_id'}) . " (new)" .
> - "</div>\n"; # class="diff_info"
> -
> - } elsif ($diffinfo->{'status'} eq "D") { # deleted
> - print "<div class=\"diff_info\">" . file_type($diffinfo->{'from_mode'}) . ":" .
> - $cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
> - hash=>$diffinfo->{'from_id'},
> file_name=>$diffinfo->{'file'})},
> - $diffinfo->{'from_id'}) . " (deleted)" .
> - "</div>\n"; # class="diff_info"
> -
> - } elsif ($diffinfo->{'status'} eq "R" || # renamed
> - $diffinfo->{'status'} eq "C" || # copied
> - $diffinfo->{'status'} eq "2") { # with two filenames (from git_blobdiff)
> - print "<div class=\"diff_info\">" .
> - file_type($diffinfo->{'from_mode'}) . ":" .
> - $cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
> - hash=>$diffinfo->{'from_id'},
> file_name=>$diffinfo->{'from_file'})},
> - $diffinfo->{'from_id'}) .
> - " -> " .
> - file_type($diffinfo->{'to_mode'}) . ":" .
> - $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
> - hash=>$diffinfo->{'to_id'},
> file_name=>$diffinfo->{'to_file'})},
> - $diffinfo->{'to_id'});
> - print "</div>\n"; # class="diff_info"
> -
> - } else { # modified, mode changed, ...
> - print "<div class=\"diff_info\">" .
> - file_type($diffinfo->{'from_mode'}) . ":" .
> - $cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
> - hash=>$diffinfo->{'from_id'},
> file_name=>$diffinfo->{'file'})},
> - $diffinfo->{'from_id'}) .
> - " -> " .
> - file_type($diffinfo->{'to_mode'}) . ":" .
> - $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
> - hash=>$diffinfo->{'to_id'}, file_name=>$diffinfo->{'file'})},
> - $diffinfo->{'to_id'});
> - print "</div>\n"; # class="diff_info"
> - }
> + # print "git diff" header
> + $patch_line =~ s/$from_subst[0]/$from_subst[1]/ if @from_subst;
> + $patch_line =~ s/$to_subst[0]/$to_subst[1]/ if @to_subst;
> + print "<div class=\"diff header\">$patch_line</div>\n";
>
> - #print "<div class=\"diff extended_header\">\n";
> + print "<div class=\"diff extended_header\">\n";
> $in_header = 1;
> next LINE;
> } # start of patch in patchset
>
> + if ($in_header) {
> + if ($patch_line !~ m/^---/) {
> + # match <path>
> + if ($patch_line =~ m|a/|) {
> + $patch_line =~ s/$from_subst[0]/$from_subst[1]/ if @from_subst;
> + }
> + if ($patch_line =~ m|b/|) {
> + $patch_line =~ s/$to_subst[0]/$to_subst[1]/ if @to_subst;
> + }
> + # match <mode>
> + if ($patch_line =~ m/\s(\d{6})$/) {
> + $patch_line .= '/' . mode_str($1) . ' (' . file_type($1) . ')';
> + }
> + # match <hash>
> + if ($patch_line =~ m/^index/) {
> + $patch_line =~ s/0{40}/'0' x 7/e;
> + $patch_line =~ s/$from_subst[2]/$from_subst[3]/ if @from_subst;
> + $patch_line =~ s/$to_subst[2]/$to_subst[3]/ if @to_subst;
> + }
> + print $patch_line . "<br/>\n";
>
> - if ($in_header && $patch_line =~ m/^---/) {
> - #print "</div>\n"; # class="diff extended_header"
> - $in_header = 0;
> + } else {
> + #$patch_line =~ m/^---/;
> + print "</div>\n"; # class="diff extended_header"
> + $in_header = 0;
> +
> + $patch_line =~ s/$from_subst[0]/$from_subst[1]/ if @from_subst;
> + print "<div class=\"diff from_file\">$patch_line</div>\n";
>
> - my $file = $diffinfo->{'from_file'};
> - $file ||= $diffinfo->{'file'};
> - $file = $cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
> - hash=>$diffinfo->{'from_id'}, file_name=>$file),
> - -class => "list"}, esc_html($file));
> - $patch_line =~ s|a/.*$|a/$file|g;
> - print "<div class=\"diff from_file\">$patch_line</div>\n";
> + $patch_line = <$fd>;
> + chomp $patch_line;
>
> - $patch_line = <$fd>;
> - chomp $patch_line;
> + #$patch_line =~ m/^+++/;
> + $patch_line =~ s/$to_subst[0]/$to_subst[1]/ if @to_subst;
> + print "<div class=\"diff to_file\">$patch_line</div>\n";
>
> - #$patch_line =~ m/^+++/;
> - $file = $diffinfo->{'to_file'};
> - $file ||= $diffinfo->{'file'};
> - $file = $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
> - hash=>$diffinfo->{'to_id'}, file_name=>$file),
> - -class => "list"}, esc_html($file));
> - $patch_line =~ s|b/.*|b/$file|g;
> - print "<div class=\"diff to_file\">$patch_line</div>\n";
> + }
>
> next LINE;
> }
> - next LINE if $in_header;
>
> print format_diff_line($patch_line);
> }
> --
> 1.4.3.3
>
>
>
> -------------------------------------------------------
>
> --
> Jakub Narebski
> Poland
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/2] git-send-email: Document support for local sendmail instead of SMTP server
From: Sergey Vlasov @ 2006-10-29 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git, Sergey Vlasov
Fix the --smtp-server option description to match reality.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
Documentation/git-send-email.txt | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 481b3f5..ec0e201 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -66,8 +66,11 @@ The options available are:
all that is output.
--smtp-server::
- If set, specifies the outgoing SMTP server to use. Defaults to
- localhost.
+ If set, specifies the outgoing SMTP server to use. A full
+ pathname of a sendmail-like program can be specified instead;
+ the program must support the `-i` option. Defaults to
+ `/usr/sbin/sendmail` or `/usr/lib/sendmail` if such program is
+ available, or to `localhost` otherwise.
--subject::
Specify the initial subject of the email thread.
--
1.4.3.3.ge502
^ permalink raw reply related
* [PATCH 2/2] git-send-email: Read the default SMTP server from the GIT config file
From: Sergey Vlasov @ 2006-10-29 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git, Sergey Vlasov
In-Reply-To: <11621502993406-git-send-email-vsu@altlinux.ru>
Make the default value for --smtp-server configurable through the
'sendemail.smtpserver' option in .git/config (or $HOME/.gitconfig).
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
Documentation/git-send-email.txt | 8 +++++---
git-send-email.perl | 3 +++
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index ec0e201..4c8d907 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -68,9 +68,11 @@ The options available are:
--smtp-server::
If set, specifies the outgoing SMTP server to use. A full
pathname of a sendmail-like program can be specified instead;
- the program must support the `-i` option. Defaults to
- `/usr/sbin/sendmail` or `/usr/lib/sendmail` if such program is
- available, or to `localhost` otherwise.
+ the program must support the `-i` option. Default value can
+ be specified by the 'sendemail.smtpserver' configuration
+ option; the built-in default is `/usr/sbin/sendmail` or
+ `/usr/lib/sendmail` if such program is available, or
+ `localhost` otherwise.
--subject::
Specify the initial subject of the email thread.
diff --git a/git-send-email.perl b/git-send-email.perl
index c42dc3b..4c87c20 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -231,6 +231,9 @@ if (!defined $initial_reply_to && $promp
}
if (!$smtp_server) {
+ $smtp_server = $repo->config('sendemail.smtpserver');
+}
+if (!$smtp_server) {
foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
if (-x $_) {
$smtp_server = $_;
--
1.4.3.3.ge502
^ permalink raw reply related
* Merging five months of Linux kernel history
From: Jan-Benedict Glaw @ 2006-10-29 19:32 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 914 bytes --]
Hi!
Due to a move to a new flat and other reasons, I wasn't able to
do daily merges from Linus's tree into our vax-linux tree.
My time situation has improved and I want to merge all the new
and shiny stuff, but it seems a straight "git pull" isn't the
best way to do that.
What I'd actually love to do is to go through all commits since the
last merge and pull/accept/cherry-pick then one by one. That way I'll
learn about new stuff. I'll specifically see generic changes that
imply arch-specific stuff, things I'll need to implement later on.
Is there any sane way to cluse such a large gap? I don't mind looking
through tenthousands of commits, as long as I get a chance to spot
"important" ones.
Thanks, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
the second :
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Luben Tuikov @ 2006-10-29 19:33 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git
In-Reply-To: <7viri34a3k.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> It somehow feels that deviating from what "git diff" gives makes
> it very distracting; I would feel better if "/-rw-r--r-- (file)"
> were not there.
Agree.
> Also I think arguing over 7 or 8 hexdigits is pointless; if you
> are reading this from "git diff", it is probably the easiest to
> match what "git diff" gave you. One thing we _might_ want to do
Agree.
Luben
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Luben Tuikov @ 2006-10-29 19:38 UTC (permalink / raw)
To: Anand Kumria, git
In-Reply-To: <ei27mu$q9s$1@sea.gmane.org>
--- Anand Kumria <wildfire@progsoc.org> wrote:
> I think your version looks a lot nicer but I believe that the commit
> message area should be in a fixed-point font. In general it won't be a
> problem but if anyone should choose to insert a diagram or something else
> that assume a fixed-width display - it won't look good.
Thanks for catching this!
Jakub, I believe I submitted a patch to change that to fixed point
and you can see the reasons in the commit message. See commit
4b7ce6e2d6ba088da50de1df38b040ea2c0b8f18.
Please change it to fixed point.
Luben
^ permalink raw reply
* Re: [PATCH 3/3] Teach git-index-pack how to keep a pack file.
From: Michael S. Tsirkin @ 2006-10-29 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Shawn Pearce
In-Reply-To: <7vr6wr0wa7.fsf@assigned-by-dhcp.cox.net>
Quoting r. Junio C Hamano <junkio@cox.net>:
> It might be a good idea to leave process ID of the caller of the
> index-pack as part of --keep="reason" string, along with the
> timestamp to help the user decide if the .keep is leftover or
> still in progress (the timestamp can be seen from ls -l *.keep
> so it is not strictly needed).
Add hostname to that, for repositories that reside on networked file systems.
--
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Luben Tuikov @ 2006-10-29 19:43 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git
In-Reply-To: <200610291635.09525.jnareb@gmail.com>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> >> Changes:
> [...]
> >> * <file> hyperlinking should work also when <file> is originally
> >> quoted. For now we present filename quoted. This needed changes to
> >> parse_difftree_raw_line subroutine.
> >
> > This feels Ok.
>
> Emphasisis on "should". Check
> http://roke(.)dyndns(.)info/cgi-bin/gitweb/gitweb.cgi?p=git.git;a=commitdiff;h=gitweb/test
>
> By the way, should we use quoted or unquoted filename?
For dear life, I cannot understand *WTF* is this argument about
"quoted" and "unquoted". Can this stop please? PLEASE?
Unquoted, natural, normal.
Luben
P.S. I don't want to punish the good people who do not put \n or \r or whatnot
in their filenames, just for this one ... "person" who does. UTF8 is a different
story.
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Luben Tuikov @ 2006-10-29 19:55 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <200610291850.46321.jnareb@gmail.com>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> A couple of questions regarding new patchset/diff look for gitweb.
> Currently patch starts with "git diff" header
>
> diff --git a/file1 b/file2
>
> then we have a couple of extended header lines
>
> old|new|deleted file|new file mode <mode>
> copy|rename from|to <path>
> (dis)?similarity index <percent>
> index <hash>..<hash> [<mode>]
>
> then we have two-line from-file/to-file header
First revert back to monospace in the commit message.
As I mentioned in that other email, where the person
didn't CC you and thus so I didn't, see commit
4b7ce6e2d6ba088da50de1df38b040ea2c0b8f18.
Can you please hyperlink what you had intended to
quote? I.e. filenames which can lead the user browsing to a
state (pre-rename, post-rename, etc). Thanks.
>
> --- a/file1
> +++ b/file2
>
> then patch itself.
>
>
> 1. Which parts to convert to hyperlinks, and which to do not? Which
> links have visible and which hidden (underline on mouseover, the same
> color as neighbouring text)?
I think the current state of your patch is good, sans the comments
received so far: monospace, that bug in the index links, etc.
Lets get that in, and then you can RFC another improvement on top of this.
> I think that a/file1 in "git diff" header should be turned into
> visible hyperlink unless file is created, and b/file2 should be link
> unless file is deleted.
This is intuitive and makes sense.
> Also both <hash>-es in "index" extended header lines should be turned
> into links, as it is the only way to have hyperlink to all previou
Fix the bug though.
> versions of the file in the case of "combined diff" format (to be
> added later). The question is if those hyperlinks should be visible;
I personally love little hidden gems, but some people like everything
to be overly obvious to them. Hidden gems are part of the learning,
but I'm sure I'm not going to convince everyone.
Hidden.
> I don't have compelling reason against. Should we use title attribute
> to give filename perhaps, or is it unnecessary?
>
> Currently file1 and file2 in "--- a/file1" and "+++ b/file2" are
> turned into hidden links. Should we leave it, or should we remove
> this link as we have similar link just above? If we decide to have
Leave it -- it's cool.
> this link, should we also hyperlink <path> in "copy|rename" extended
> header line?
If it makes sense.
> 2. Use quoted or unquoted filename, remove or leave surrounding quotes
> in quoted filename? Should we unquote the not hyperlinked filename
Are you familiar with the term "legalism"?
> in the case of creation/deletion? What should be span of link:
> "a/_file1_", "_a/file1_", _"a/file1"_
> "_file_", _"file"_
> (where '_' marks beginning and end of link) for quoted filenames?
> What should be span of link for unquoted filenames:
> a/_file_, _a/file_
> Currently gitweb uses a/_file_ in ---/+++ line.
Unquoted! Now that we've solved this "problem", lets move on to more
interesting things. ;-)
> 3. How (and if) to explain numerical mode: the currently used
Let's not explain it for now. Let's have your patch go in sans the
comments already posted. We can always debate on that later.
Thanks,
Luben
> <mode>/<symbolic mode> (<file type>) e.g. 100755/-rwxr-xr-x (file).
> Or <mode> (<file type>) should be enough? Should we mark the addition
> compared to git-diff output? Or should we explain <mode> only on
> mouseover, using for example:
> <abbr title="100644/-rw-r--r-- (file)">100644</abbr>
> or just
> <abbr title="executable file">100755</abbr>?
> --
> Jakub Narebski
> Poland
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 2/2] Swap the porcelain and plumbing commands in the git man page
From: Robin Rosenberg @ 2006-10-29 20:09 UTC (permalink / raw)
To: git
In-Reply-To: <20061029200940.11233.20277.stgit@lathund.dewire.com>
From: Robin Rosenberg <robin.rosenberg@dewire.com>
This makes the documentation less confusing to newcomers.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Documentation/git.txt | 364 +++++++++++++++++++++++++------------------------
1 files changed, 182 insertions(+), 182 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index fff07e1..0679e3c 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -72,188 +72,6 @@ GIT COMMANDS
We divide git into high level ("porcelain") commands and low level
("plumbing") commands.
-Low-level commands (plumbing)
------------------------------
-
-Although git includes its
-own porcelain layer, its low-level commands are sufficient to support
-development of alternative porcelains. Developers of such porcelains
-might start by reading about gitlink:git-update-index[1] and
-gitlink:git-read-tree[1].
-
-We divide the low-level commands into commands that manipulate objects (in
-the repository, index, and working tree), commands that interrogate and
-compare objects, and commands that move objects and references between
-repositories.
-
-Manipulation commands
-~~~~~~~~~~~~~~~~~~~~~
-gitlink:git-apply[1]::
- Reads a "diff -up1" or git generated patch file and
- applies it to the working tree.
-
-gitlink:git-checkout-index[1]::
- Copy files from the index to the working tree.
-
-gitlink:git-commit-tree[1]::
- Creates a new commit object.
-
-gitlink:git-hash-object[1]::
- Computes the object ID from a file.
-
-gitlink:git-index-pack[1]::
- Build pack idx file for an existing packed archive.
-
-gitlink:git-init-db[1]::
- Creates an empty git object database, or reinitialize an
- existing one.
-
-gitlink:git-merge-index[1]::
- Runs a merge for files needing merging.
-
-gitlink:git-mktag[1]::
- Creates a tag object.
-
-gitlink:git-mktree[1]::
- Build a tree-object from ls-tree formatted text.
-
-gitlink:git-pack-objects[1]::
- Creates a packed archive of objects.
-
-gitlink:git-prune-packed[1]::
- Remove extra objects that are already in pack files.
-
-gitlink:git-read-tree[1]::
- Reads tree information into the index.
-
-gitlink:git-repo-config[1]::
- Get and set options in .git/config.
-
-gitlink:git-unpack-objects[1]::
- Unpacks objects out of a packed archive.
-
-gitlink:git-update-index[1]::
- Registers files in the working tree to the index.
-
-gitlink:git-write-tree[1]::
- Creates a tree from the index.
-
-
-Interrogation commands
-~~~~~~~~~~~~~~~~~~~~~~
-
-gitlink:git-cat-file[1]::
- Provide content or type/size information for repository objects.
-
-gitlink:git-describe[1]::
- Show the most recent tag that is reachable from a commit.
-
-gitlink:git-diff-index[1]::
- Compares content and mode of blobs between the index and repository.
-
-gitlink:git-diff-files[1]::
- Compares files in the working tree and the index.
-
-gitlink:git-diff-stages[1]::
- Compares two "merge stages" in the index.
-
-gitlink:git-diff-tree[1]::
- Compares the content and mode of blobs found via two tree objects.
-
-gitlink:git-for-each-ref[1]::
- Output information on each ref.
-
-gitlink:git-fsck-objects[1]::
- Verifies the connectivity and validity of the objects in the database.
-
-gitlink:git-ls-files[1]::
- Information about files in the index and the working tree.
-
-gitlink:git-ls-tree[1]::
- Displays a tree object in human readable form.
-
-gitlink:git-merge-base[1]::
- Finds as good common ancestors as possible for a merge.
-
-gitlink:git-name-rev[1]::
- Find symbolic names for given revs.
-
-gitlink:git-pack-redundant[1]::
- Find redundant pack files.
-
-gitlink:git-rev-list[1]::
- Lists commit objects in reverse chronological order.
-
-gitlink:git-show-index[1]::
- Displays contents of a pack idx file.
-
-gitlink:git-tar-tree[1]::
- Creates a tar archive of the files in the named tree object.
-
-gitlink:git-unpack-file[1]::
- Creates a temporary file with a blob's contents.
-
-gitlink:git-var[1]::
- Displays a git logical variable.
-
-gitlink:git-verify-pack[1]::
- Validates packed git archive files.
-
-In general, the interrogate commands do not touch the files in
-the working tree.
-
-
-Synching repositories
-~~~~~~~~~~~~~~~~~~~~~
-
-gitlink:git-fetch-pack[1]::
- Updates from a remote repository (engine for ssh and
- local transport).
-
-gitlink:git-http-fetch[1]::
- Downloads a remote git repository via HTTP by walking
- commit chain.
-
-gitlink:git-local-fetch[1]::
- Duplicates another git repository on a local system by
- walking commit chain.
-
-gitlink:git-peek-remote[1]::
- Lists references on a remote repository using
- upload-pack protocol (engine for ssh and local
- transport).
-
-gitlink:git-receive-pack[1]::
- Invoked by 'git-send-pack' to receive what is pushed to it.
-
-gitlink:git-send-pack[1]::
- Pushes to a remote repository, intelligently.
-
-gitlink:git-http-push[1]::
- Push missing objects using HTTP/DAV.
-
-gitlink:git-shell[1]::
- Restricted shell for GIT-only SSH access.
-
-gitlink:git-ssh-fetch[1]::
- Pulls from a remote repository over ssh connection by
- walking commit chain.
-
-gitlink:git-ssh-upload[1]::
- Helper "server-side" program used by git-ssh-fetch.
-
-gitlink:git-update-server-info[1]::
- Updates auxiliary information on a dumb server to help
- clients discover references and packs on it.
-
-gitlink:git-upload-archive[1]::
- Invoked by 'git-archive' to send a generated archive.
-
-gitlink:git-upload-pack[1]::
- Invoked by 'git-fetch-pack' to push
- what are asked for.
-
-
High-level commands (porcelain)
-------------------------------
@@ -491,6 +309,188 @@ gitlink:git-stripspace[1]::
Filter out empty lines.
+Low-level commands (plumbing)
+-----------------------------
+
+Although git includes its
+own porcelain layer, its low-level commands are sufficient to support
+development of alternative porcelains. Developers of such porcelains
+might start by reading about gitlink:git-update-index[1] and
+gitlink:git-read-tree[1].
+
+We divide the low-level commands into commands that manipulate objects (in
+the repository, index, and working tree), commands that interrogate and
+compare objects, and commands that move objects and references between
+repositories.
+
+Manipulation commands
+~~~~~~~~~~~~~~~~~~~~~
+gitlink:git-apply[1]::
+ Reads a "diff -up1" or git generated patch file and
+ applies it to the working tree.
+
+gitlink:git-checkout-index[1]::
+ Copy files from the index to the working tree.
+
+gitlink:git-commit-tree[1]::
+ Creates a new commit object.
+
+gitlink:git-hash-object[1]::
+ Computes the object ID from a file.
+
+gitlink:git-index-pack[1]::
+ Build pack idx file for an existing packed archive.
+
+gitlink:git-init-db[1]::
+ Creates an empty git object database, or reinitialize an
+ existing one.
+
+gitlink:git-merge-index[1]::
+ Runs a merge for files needing merging.
+
+gitlink:git-mktag[1]::
+ Creates a tag object.
+
+gitlink:git-mktree[1]::
+ Build a tree-object from ls-tree formatted text.
+
+gitlink:git-pack-objects[1]::
+ Creates a packed archive of objects.
+
+gitlink:git-prune-packed[1]::
+ Remove extra objects that are already in pack files.
+
+gitlink:git-read-tree[1]::
+ Reads tree information into the index.
+
+gitlink:git-repo-config[1]::
+ Get and set options in .git/config.
+
+gitlink:git-unpack-objects[1]::
+ Unpacks objects out of a packed archive.
+
+gitlink:git-update-index[1]::
+ Registers files in the working tree to the index.
+
+gitlink:git-write-tree[1]::
+ Creates a tree from the index.
+
+
+Interrogation commands
+~~~~~~~~~~~~~~~~~~~~~~
+
+gitlink:git-cat-file[1]::
+ Provide content or type/size information for repository objects.
+
+gitlink:git-describe[1]::
+ Show the most recent tag that is reachable from a commit.
+
+gitlink:git-diff-index[1]::
+ Compares content and mode of blobs between the index and repository.
+
+gitlink:git-diff-files[1]::
+ Compares files in the working tree and the index.
+
+gitlink:git-diff-stages[1]::
+ Compares two "merge stages" in the index.
+
+gitlink:git-diff-tree[1]::
+ Compares the content and mode of blobs found via two tree objects.
+
+gitlink:git-for-each-ref[1]::
+ Output information on each ref.
+
+gitlink:git-fsck-objects[1]::
+ Verifies the connectivity and validity of the objects in the database.
+
+gitlink:git-ls-files[1]::
+ Information about files in the index and the working tree.
+
+gitlink:git-ls-tree[1]::
+ Displays a tree object in human readable form.
+
+gitlink:git-merge-base[1]::
+ Finds as good common ancestors as possible for a merge.
+
+gitlink:git-name-rev[1]::
+ Find symbolic names for given revs.
+
+gitlink:git-pack-redundant[1]::
+ Find redundant pack files.
+
+gitlink:git-rev-list[1]::
+ Lists commit objects in reverse chronological order.
+
+gitlink:git-show-index[1]::
+ Displays contents of a pack idx file.
+
+gitlink:git-tar-tree[1]::
+ Creates a tar archive of the files in the named tree object.
+
+gitlink:git-unpack-file[1]::
+ Creates a temporary file with a blob's contents.
+
+gitlink:git-var[1]::
+ Displays a git logical variable.
+
+gitlink:git-verify-pack[1]::
+ Validates packed git archive files.
+
+In general, the interrogate commands do not touch the files in
+the working tree.
+
+
+Synching repositories
+~~~~~~~~~~~~~~~~~~~~~
+
+gitlink:git-fetch-pack[1]::
+ Updates from a remote repository (engine for ssh and
+ local transport).
+
+gitlink:git-http-fetch[1]::
+ Downloads a remote git repository via HTTP by walking
+ commit chain.
+
+gitlink:git-local-fetch[1]::
+ Duplicates another git repository on a local system by
+ walking commit chain.
+
+gitlink:git-peek-remote[1]::
+ Lists references on a remote repository using
+ upload-pack protocol (engine for ssh and local
+ transport).
+
+gitlink:git-receive-pack[1]::
+ Invoked by 'git-send-pack' to receive what is pushed to it.
+
+gitlink:git-send-pack[1]::
+ Pushes to a remote repository, intelligently.
+
+gitlink:git-http-push[1]::
+ Push missing objects using HTTP/DAV.
+
+gitlink:git-shell[1]::
+ Restricted shell for GIT-only SSH access.
+
+gitlink:git-ssh-fetch[1]::
+ Pulls from a remote repository over ssh connection by
+ walking commit chain.
+
+gitlink:git-ssh-upload[1]::
+ Helper "server-side" program used by git-ssh-fetch.
+
+gitlink:git-update-server-info[1]::
+ Updates auxiliary information on a dumb server to help
+ clients discover references and packs on it.
+
+gitlink:git-upload-archive[1]::
+ Invoked by 'git-archive' to send a generated archive.
+
+gitlink:git-upload-pack[1]::
+ Invoked by 'git-fetch-pack' to push
+ what are asked for.
+
+
Configuration Mechanism
-----------------------
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox