* [EGIT PATCH 3/3] Align commit text properly in jgit glog
From: Robin Rosenberg @ 2008-10-01 19:31 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
In-Reply-To: <1222889493-12736-3-git-send-email-robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../org/spearce/jgit/awtui/AWTPlotRenderer.java | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/awtui/AWTPlotRenderer.java b/org.spearce.jgit/src/org/spearce/jgit/awtui/AWTPlotRenderer.java
index dc785ec..b6b715c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/awtui/AWTPlotRenderer.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/awtui/AWTPlotRenderer.java
@@ -109,10 +109,10 @@ protected void drawBoundaryDot(final int x, final int y, final int w,
@Override
protected void drawText(final String msg, final int x, final int y) {
- final int texty = g.getFontMetrics().getHeight()
- - g.getFontMetrics().getDescent();
+ final int texth = g.getFontMetrics().getHeight();
+ final int y0 = y - texth/2 + (cell.getHeight() - texth)/2;
g.setColor(cell.getForeground());
- g.drawString(msg, x, texty - (cell.getHeight() - y * 2));
+ g.drawString(msg, x, y0 + texth - g.getFontMetrics().getDescent());
}
@Override
--
1.6.0.1.310.gf789d0.dirty
^ permalink raw reply related
* [EGIT PATCH 0/3] jgit glog alignment fixes
From: Robin Rosenberg @ 2008-10-01 19:31 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <20081001143815.GV21310@spearce.org>
The series resent based upon review comments. Drop the unnecessary dispose
calls for system allocated colors (and thus all SWT related changed).
-- robin
^ permalink raw reply
* [PATCH] xdiff-interface.c: strip newline (and cr) from line before pattern matching
From: Brandon Casey @ 2008-10-01 19:28 UTC (permalink / raw)
To: Jonathan del Strother
Cc: Git Mailing List, Miklos Vajna, Johannes Schindelin,
Junio C Hamano, Andreas Ericsson
In-Reply-To: <mJtumbyBuR0sRaFjwb6O5_D_ps0fVfz6APTAAjYMixV0MvzP8nEZRw@cipher.nrlssc.navy.mil>
POSIX doth sayeth:
"In the regular expression processing described in IEEE Std 1003.1-2001,
the <newline> is regarded as an ordinary character and both a period and
a non-matching list can match one. ... Those utilities (like grep) that
do not allow <newline>s to match are responsible for eliminating any
<newline> from strings before matching against the RE."
Thus far git has not been removing the trailing newline from strings matched
against regular expression patterns. This has the effect that (quoting
Jonathan del Strother) "... a line containing just 'FUNCNAME' (terminated by
a newline) will be matched by the pattern '^(FUNCNAME.$)' but not
'^(FUNCNAME$)'", and more simply not '^FUNCNAME$'.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
This could be a little simpler if I knew what was guaranteed from xdiff.
Such as whether the len elements of line were guaranteed to be newline
terminated, or be greater than zero. But, the code in def_ff() in xemit.c
is wrapped in 'if (len > 0)', so..
-brandon
xdiff-interface.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/xdiff-interface.c b/xdiff-interface.c
index 8bab82e..61f5dab 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -191,12 +191,22 @@ struct ff_regs {
static long ff_regexp(const char *line, long len,
char *buffer, long buffer_size, void *priv)
{
- char *line_buffer = xstrndup(line, len); /* make NUL terminated */
+ char *line_buffer;
struct ff_regs *regs = priv;
regmatch_t pmatch[2];
int i;
int result = -1;
+ /* Exclude terminating newline (and cr) from matching */
+ if (len > 0 && line[len-1] == '\n') {
+ if (len > 1 && line[len-2] == '\r')
+ len -= 2;
+ else
+ len--;
+ }
+
+ line_buffer = xstrndup(line, len); /* make NUL terminated */
+
for (i = 0; i < regs->nr; i++) {
struct ff_reg *reg = regs->array + i;
if (!regexec(®->re, line_buffer, 2, pmatch, 0)) {
--
1.6.0.2.323.g7c850
^ permalink raw reply related
* Git at Better SCM Initiative comparison of VCS (long)
From: Jakub Narebski @ 2008-10-01 18:45 UTC (permalink / raw)
To: git, Alexey Mahotkin; +Cc: Dmitry Potapov, Shawn O. Pearce
In-Reply-To: <200809131906.18746.jnareb@gmail.com>
I think that the information about Git at Better SCM Initiative
comparison of various version control systems
http://better-scm.berlios.de/comparison/comparison.html
used also for versioncontrolblog "Version control systems comparison"
http://versioncontrolblog.com/comparison
needs a few corrections.
Therefore below you can find proposed changes, as discussed here on
this mailing list (this time CC-ing author of Git entry, Alexey
Mahotkin of versioncontrolblog). For each section (each compared
feature) I have put description, entry for one or more open source
distributed version control systems (for reference) and current entry
for Git, in email-quote like format (prefixed with "scm> "), then
proposed corrected entry (if it needs correction) and some comments
about it.
Contrary to previous post in this thread I did not comment this time
on the comparison itself, for example not well defined criteria, and
lack of tests or functional/use case description which would help to
check if SCM supports given feature.
I think this could be basis for Alexey to send corrections to
Better SCM comparison table.
Please comment
scm> <timestamp>
scm> $Id: scm-comparison.xml 322 2008-08-09 05:47:26Z shlomif $
scm> </timestamp>
Here just so you know on which version it is based on.
scm> <section id="repos_operations">
scm> <title>Repository Operations</title>
scm> <section id="atomic_commits">
scm> <title>Atomic Commits</title>
scm> <expl>
scm> Support for atomic commits means that if an
scm> operation on the repository is interrupted
scm> in the middle, the repository will not be
scm> left in an inconsistent state. Are the
scm> check-in operations atomic, or can
scm> interrupting an operation leave the
scm> repository in an intermediate state?
scm> </expl>
scm> <compare>
scm> <s id="cvs">No. CVS commits are not atomic.</s>
scm> <s id="bazaar">Yes. Commits are atomic.</s>
scm> <s id="mercurial">Yes.</s>
scm> <s id="git">Yes. Commits are atomic.</s>
scm> </compare>
scm> </section>
No comment here (beside the fact that table neds some unification, but
this is hardly the case for Better SCM comparison Git entry maintainer).
scm> <section id="move">
scm> <title>Files and Directories Moves or Renames</title>
scm> <expl>
scm> Does the system support moving a file or directory to
scm> a different location while still retaining the history
scm> of the file? <b>Note:</b> also see the next section
scm> about intelligent merging of renamed paths.
scm> </expl>
scm> <compare>
scm> <s id="bazaar">Yes. Renames are supported for files and directories.</s>
scm> <s id="mercurial">Yes. Renames are supported.</s>
scm> <s id="git">
scm> Renames are supported for most practical
scm> purposes. Git even detects renames when a file has been
scm> changed afterward the rename. However, due to a peculiar
scm> repository structure, renames are not recorded
scm> explicitly, and Git has to deduce them (which works well
scm> in practice).
scm> </s>
scm> </compare>
scm> </section>
I would propose to change it to something like the followig:
Renames are supported for most practical purposes[1]. By design Git
does heuristic <i>rename detection</i> (based on similarity score of
pathnames and file contents), instead of doing rename tracking. This
approach allows for more generic content tracking of code movement
(which usually happens much often than wholesame file renaming),
e.g. in "git blame -C -C".
Footnotes:
[1] "git log --follow <i>filename</i>" works only for very simple
history currently; rename detection can get confused by empty files
and files consisting mainly of boilerplate (e.g. license text).
Comments:
I am a bit unsure about need for footnote. Perhaps it should be simply
removed. Also, perhaps instead of "Renames are supported..." it should
be "File renames are supported...", although it looks like it would
improve soon: see thread on git mailing list about detecting wholesale
firectory renames (with ability to track directory splitting, like now
git is able to track contents movement across files).
scm> <section id="intelligent_renames">
scm> <title>Intelligent Merging after Moves or Renames</title>
scm> <expl>
scm> If the system keeps tracks of renames, does it support
scm> intelligent merging of the files in the history after
scm> the rename? (For example, changing a file in a renamed
scm> directory, and trying to merge it).
scm> </expl>
scm> <compare>
scm> <s id="bazaar">Yes. Renames are intelligent.</s>
scm> <s id="mercurial">
scm> No. <a
scm> href="http://hgbook.red-bean.com/hgbookch5.html#x9-1030005.4">the
scm> Mercurial book says:</a>
scm> "When you use the 'hg rename' command, Mercurial makes a
scm> copy of each source file, then deletes it and marks the
scm> file as removed. "
scm> </s>
scm> <s id="git">
scm> No. As detailed in the <a
scm> href="http://git.or.cz/gitwiki/GitFaq#rename-tracking">Git
scm> FAQ</a>:
scm> "Git has a rename command git mv, but that is just a
scm> convenience. The effect is indistinguishable from removing
scm> the file and adding another with different name and the
scm> same content."
scm> </s>
scm> </compare>
scm> </section>
This entry is incorrect[1]; it has to be changed to something like the
following proposal:
Yes, Git can deal with renamed files during merging, thanks to rename
detection.
Comments:
Git does apply change to renamed file, both if file itself is renamed,
and if directory it is in gets renamed (like in example in feature
description). What Git _currently_ doesn't support (at least for now,
with lack of detection of directories as a whole; this might change
soon) is with adding new files to the renamed directory: if one side
renamed directory and second side added new files in the old directory,
those new files would show at old name, not at new name.
There also might be two kinds of problems: first, if you are merging
old and/or much diverged branch rename detection can use much of CPU
power even if there are no renames present (this happened once or
twice). Second, if similarity based rename detection fail you would
not get conflict and will be left with two versions of a file in
working directory; this might happen for example if you renamed some
'sensitive' binary file (so small change results in large change in
representation) or change is too large compared to whole contents of
a file. In second case it is expected that requested from time to time
advisory rename tracking would help.
Hmmm... I wonder if the above problems with rename detection happen
more often than problems with, usually file-id based, rename tracking
used by other SCM.
Footnote:
=========
[1] It looks like we really need http://git.or.cz/gitwiki/FileRenames
BTW. I wonder if Mercurial entry isn't incorrect either...
scm> <section id="copy">
scm> <title>File and Directories Copies</title>
scm> <expl>
scm> Does the version control system support copying
scm> files or directories to a different location at the
scm> repository level, while retaining the history?
scm> </expl>
scm> <compare>
scm> <s id="bazaar">No. Copies are not supported.</s>
scm> <s id="mercurial">Yes. Copies are supported</s>
scm> <s id="git">No. Copies are not supported.</s>
scm> </compare>
scm> </section>
I would write that:
Copies detection is supported, but for performance reasons it is not
enabled by default.
Comments:
Perhaps we could mention here that there are two thresholds of copying
detection: checking only changed files and --detect-copies-harder. Also
worth of note might be the fact that git-blame has support for
detecting code copying, also across filenames.
scm> <section id="repos_clone">
scm> <title>Remote Repository Replication</title>
scm> <expl>
scm> Does the system support cloning a remote repository to get
scm> a functionally equivalent copy in the local system? That
scm> should be done without any special access to the remote
scm> server except for normal repository access.
scm> </expl>
scm> <compare>
scm> <s id="mercurial">Yes.</s>
scm> <s id="git">Yes. This is very intrinsic feature of Git.</s>
scm> </compare>
scm> </section>
In fact this is 'very intrinsic feature' of each distributed SCM...
In short: I think that simple 'Yes.' answer for Git would be better.
scm> <section id="push">
scm> <title>Propagating Changes to Parent Repositories</title>
scm> <expl>
scm> Can the system propagate changes from one repository to
scm> another?
scm> </expl>
scm> <compare>
scm> <s id="mercurial">Yes.</s>
scm> <s id="git">Yes. (The Linux kernel development process uses this extremely often).</s>
scm> </compare>
scm> </section>
Again I think that simple "Yes" would be sufficient. The sentence in
parentheses doesn't bring any new information, so IMHO should be
removed. Especially that Linux kernel uses also patch based wokflow
very extensively.
scm> <section id="permissions">
scm> <title>Repository Permissions</title>
scm> <expl>
scm> Is it possible to define permissions on access to different
scm> parts of a remote repository? Or is access open for all?
scm> </expl>
scm> <compare>
scm> <s id="bazaar">
scm> Basic access control can be implemented through a
scm> contributed hook script. ACL support for the
scm> Bazaar server is planned.
scm> </s>
scm> <s id="mercurial">
scm> Yes. It is possible to lock down repositories,
scm> subdirectories, or files using hooks.
scm> </s>
scm> <s id="git">
scm> No, but a single server can serve many repositories.
scm> Also, UNIX permissions can be used to some extent.
scm> </s>
Line-wrapped for better readibility.
scm> </compare>
scm> </section>
I think the answer should be here:
Yes. It is possible to lock down repositories, branches,
subdirectories, or files using hooks (see for example
<a href="">contrib/hooks/paranoid</a> example hook).
Comments:
Shawn, could you _please_ make documentation of 'paranoid' contrib hook
complete by documenting how to configure it to lock down directories
or files?
As the feature seems to be more about fine-grained access control
(by the way something that Karl Fogel in his "Prodicting OSS..." book
is against, as better solved by socual and not technological means)
I have not mentioned here things like web server permissions for WebDAV
access, UNIX file permissions, or tools like Gitosis or ssh_acl, which
are about access to repository as a whole.
scm> <section id="changesets">
scm> <title>Changesets' Support</title>
scm> <expl>
scm> Does the repository support changesets? Changesets are a way
scm> to group a number of modifications that are relevant to each
scm> other in one atomic package, that can be cancelled or
scm> propagated as needed.
scm> </expl>
scm> <compare>
scm> <s id="darcs">
scm> Yes. Changesets are supported.
scm> </s>
scm> <s id="mercurial">
scm> Yes. Changesets are supported.
scm> </s>
scm> <s id="git">
scm> Yes, Changesets are supported,
scm> and there's some flexibility in creating them.
scm> </s>
Line wrapped for better eradibility.
scm> </compare>
scm> </section>
In my opition, such an _empty_ addition ("there's some flexibility in
creating them") is totally unnecessary; it adds no solid information
(what does it mean "some flexibility") and should be removed.
I think the entry should simply state "Yes. Changesets are supported.";
see for example entry for Darcs (from which Iu the idea of having
"git add --interactive" was taken from).
Comments:
Description of this feature is not entirely clean, but I think
everybody knows what it meant to mean.
scm> <section id="annotate">
scm> <title>Tracking Line-wise File History</title>
scm> <expl>
scm> Does the version control system have an option to track the
scm> history of the file line-by-line? I.e., can it show for each line
scm> at which revision it was most recently changed, and by whom?
scm> </expl>
scm> <compare>
scm> <s id="mercurial">Yes. (hg annotate)</s>
scm> <s id="git">Yes. (git blame).</s>
scm> </compare>
scm> </section>
scm> </section>
This is O.K, but I wonder if it wouldn't be worth to add information
about unique (as far as I know) git-blame abilities, something like:
Yes. (git blame).
<a href="">git-blame</a> can be asked to detect moving lines in file
and between files; there exist GUI for blame ("git gui blame <file>").
Comments:
One would suspect that because Git is based towards whole project
history, and not per file history, git-blame is slow. To migitate
that there is incremental blame mode used to reduce latency in graphical
blame viewers like "git gui blame", contrib/blameview, or the one
in QGit.
But anegdotical evidence (meaning in this case discussion with Pieter
de Bie of vcscompare blog on #git IRC channel) shows that git-blame
is of similar performance that its equivalent in Mercurial and Bazaar.
(It is hard to compare with "cvs annotate" as for centralized SCM there
is matter of network speed; I don't know how it compares for local
access, i.e. repository and file/client on the same filesystem).
scm> <section id="features">
scm> <title>Features</title>
scm> <section id="work_on_dir">
scm> <title>Ability to Work only on One Directory of the Repository</title>
scm> <expl>
scm> Can the version control system checkout only one directory of
scm> the repository? Or restrict the check-ins to only one
scm> directory?
scm> </expl>
scm> <compare>
scm> <s id="bazaar">For checkouts: No. For checkins: Yes.</s>
scm> <s id="mercurial">
scm> It is possible to commit changes only in a subset of the
scm> tree. There are plans for partial checkouts.
scm> </s>
scm> <s id="git">
scm> No. However, commits could be restricted somewhat,
scm> see the "Repository Permissions".
scm> </s>
Again, re-wrapped for better readibility.
scm> </compare>
scm> </section>
I'm not sure if the entry for Git shouldn't read as:
No. All changes are made repository-wide.
as in for Aegis. On the other hand it is possible to restrict commits
and remote access to only some subset of the tree using hooks; also
there is work done on implementing partial/sparse checkout for Git by
Nguyễn Thái Ngọc Duy (pclouds). So perhaps it should read instead,
similarly to what we have for Mercurial:
It is possible to restrict commit via hooks to changes only in
a subset of the tree. Implementing partial/sparse checkouts is
work in progress.
Comments:
Again, as said in "Producting OSS..." it is better to implement such
restrictions using social rather that technical means; at least for
checkins; there are some reasons (disk space, protecting against
accidental changes, <insert your reason here>) for partial checkouts.
scm> <section id="tracking_uncommited_changes">
scm> <title>Tracking Uncommited Changes</title>
scm> <expl>
scm> Does the software have an ability to track the changes in the
scm> working copy that were not yet committed to the repository?
scm> </expl>
scm> <compare>
scm> <s id="mercurial">Yes. Using hg diff.</s>
scm> <s id="git">Yes.
scm> Also, branches are very lightweight in Git, and
scm> could be considered a kind of storage for "uncommitted" code
scm> in some workflows.
scm> </s>
A bit rewrapped, and indented.
scm> </compare>
scm> </section>
Perhaps we should add "Using git diff" here; the problem is with
[possible] difference between "git diff", "git diff HEAD", and
"git diff --cached".
I also think that the comment is not on subject; it is not closely
related to described feature, so it should be IMHO abandoned. The entry
should then read:
Yes. Using git diff.
Comments:
I don't think it is worth mentioning the fact that staging area in Git
(the index) is explicit and visible, and can be directly accessed. In
usual [newbie] workflows "git diff" works just fine...
scm> <section id="per_file_commit_messages">
scm> <title>Per-File Commit Messages</title>
scm> <expl>
scm> Does the system have a way to assign a per-file commit message
scm> to the changeset, as well as a per-changeset message?
scm> </expl>
scm> <compare>
scm> <s id="bitkeeper">Yes. It is possible to have a per-file
scm> commit message</s>
scm> <s id="mercurial">
scm> No.
scm> </s>
scm> <s id="git">
scm> No. Commit messages are per changeset.
scm> </s>
Re-wrapped.
scm> </compare>
scm> </section>
scm> </section>
Perhaps simple "No." as in case of Mercurial entry would be enough here?
Comments:
What is the reason somebody would want per-file commit message? They
cannot be terribly useful, as BitKeeper which taught Linus about
distributed version control has it, but Git doesn't.
scm> <section id="technical_status">
scm> <title>Technical Status</title>
scm> <section id="documentation">
scm> <title>Documentation</title>
scm> <expl>
scm> How well is the system documented? How easy is it to
scm> get started using it?
scm> </expl>
scm> <compare>
scm> <s id="darcs">
scm> Good. The manual contains a brief tutorial and a solid
scm> reference. Every sub-command can print its usage.
scm> Because the command-set is small and the model is
scm> simple, many users find it easy to get started.
scm> </s>
scm> <s id="git">
scm> Medium. The short help is too terse and obscure.
scm> The man pages are extensive, but tend to be confusing.
scm> The are many tutorials.
scm> </s>
Re-wrapped and re-indented for better readibilit.
scm> </compare>
scm> </section>
That of course depends on ones opinion. I would say "Good", now that
there is "Git User's Manual" distributed with Git, and now that there
started semi-official "Git Community Book" (http://book.git-scm.com).
So I would say:
Good. There is extensive <a href="">"Git User's Manual"<a/> distributed
with Git. There started semi-official <a href="http://book.git-scm.com">"Git
Community Book". There is manpage for each sub-command, and most commands
can print short usage.
Comments:
Backward compatibility^W^W Old impressions die hard,... And the meme
that git documentation is not user friendly is difficult to kill.
scm> <section id="ease_of_deployment">
scm> <title>Ease of Deployment</title>
scm> <expl>
scm> How easy is it to deploy the software? What are
scm> the dependencies and how can they be satisfied?
scm> </expl>
scm> <compare>
scm> <s id="mercurial">
scm> Excellent. Binary packages are available for all
scm> popular platforms. Building from source requires
scm> only Python 2.3 (or later) and a C compiler.
scm> </s>
scm> <s id="git">
scm> Good. Binary packages are available
scm> for modern platforms. C compiler and Perl are
scm> required. Requires cygwin on Windows, and has some
scm> UNIXisms.
scm> </s>
scm> </compare>
scm> </section>
Thanks to msysGit project it is not required to install Cygwin to have
Git on Windows. Also some commands are still written as shell scripts.
So I would say:
Good. Binary packages are available for modern platforms. On Windows
one can use either Cygwin, or native msysGit version. Requires Perl
and POSIX shell (and assorted shell tools) for some commands.
Comments:
I don't know what to do with "has some UNIXisms"; I think it is not
very relevant for this entry, and it shouldn't be here.
As I use Git only on Linux (and at one time used msysGit on MS Windows XP
and FAT filesystem on USB drive to fetch git.git only), I cannot say much
on ease of deployment on other operating systems, like Free/Open/NetBSD,
MacOS X, different Unices, and MS Windows. Perhaps it should be even
"Very good" here?
scm> <section id="command_set">
scm> <title>Command Set</title>
scm> <expl>
scm> What is the command set? How compatible is it with
scm> the commands of CVS (the current open-source defacto
scm> standard)?
scm> </expl>
scm> <compare>
scm> <s id="bitkeeper">
scm> A CVS-like command set with some easy-to-get-used-to
scm> complications due to its different way of work and
scm> philosophy.
scm> </s>
scm> <s id="bazaar">
scm> Tries to follow CVS conventions, but deviates
scm> where there is a different design.
scm> </s>
The same for Mercurial.
scm> <s id="git">
scm> Command set is very feature-rich, and not compatible
scm> with CVS.
scm> </s>
scm> </compare>
scm> </section>
I don't think the situation is that different than with Mercurial, so
perhaps it should simply read:
Tries to follow CVS conventions, but deviates where there is
a different design.
Although Git doesn't "try to follow CVS conventions", it does follow
BitKeeper convention, then transitively also CVS conventions. I would
agree with "feature-rich" comment, though ;-)
So perhaps something like
Command set is very feature-rich; compatibility with CVS conventions
are limited by differences in design.
scm> <section id="networking">
scm> <title>Networking Support</title>
scm> <expl>
scm> How good is the networking integration of the system?
scm> How compliant is it with existing protocols and infra-structure?
scm> </expl>
scm> <compare>
scm> <s id="bazaar">
scm> Excellent. Works natively over HTTP (read-only),
scm> FTP and SFTP without having Bazaar installed at
scm> the remote end. Works over HTTP, SSH and a custom
scm> protocol when talking to a remote Bazaar
scm> server. Supports RSYNC and WebDAV (experimental)
scm> through plugins.
scm> </s>
scm> <s id="mercurial">
scm> Excellent. Uses HTTP or ssh. Remote access also
scm> works safely without locks over read-only network
scm> filesystems.
scm> </s>
scm> <s id="git">
scm> Excellent. Can use native Git protocol, but works
scm> over rsync, ssh, HTTP and HTTPS also.
scm> </s>
Line-wrapped for better readibility.
scm> </compare>
scm> </section>
It could be written differently, but basically is O.K. Perhaps we
should state explicitely which protocols are read-only, and which allow
to push (publish) changes to server; which protocols require Git
installed on server and which can do without; perhaps also git-bundle
for off-line transport could be mentioned here.
scm> <section id="portability">
scm> <title>Portability</title>
scm> <expl>
scm> How portable is the version-control system to various
scm> operating systems, computer architectures, and other
scm> types of systems?
scm> </expl>
scm> <compare>
scm> <s id="mercurial">
scm> Excellent. Runs on all platforms supported by
scm> Python. Repositories are portable across CPU
scm> architectures and endian conventions.
scm> </s>
scm> <s id="perforce">
scm> Excellent. Runs on UNIX, Mac OS, BeOS and Windows.
scm> </s>
scm> <s id="git">
scm> The client works on most UNIXes, but not on native
scm> MS-Windows. The Cygwin build seems to be workable, though.
scm> </s>
Re-wrapped for better readibility.
scm> </compare>
scm> </section>
scm> </section>
There is native MS Windows implementation named msysGit. We can also
mention that Git runs on Linux, Free/Open/NetBSD, various Unices,
MacOX X.
The entry for Git lacks also single word descriptions, like "Excellent",
"Very good", "Good", "Medium", that most other SCM have in this part
(and "Windows only" for some).
So I would say something like the following:
Very good. Works on Linux, FreeBSD, MacOS X and various Unices. Works
on MS Windows either via Cygwin, or natively via msysGit.
Perhaps I would also add the following cautionary note:
There are some issues with case-insensitive (e.g. FAT) or filename-mangling
(MacOS HFS+) filesystems, but they can be worked around.
Comments:
I'm not sure if it should be "Very good" or "Excellent" here. I think
that this section is about number of systems SCM was ported to, not
how hard is to make it work (port Git) on some additional OS. I'm not
sure how complete msysGit is (git-svn and other Perl scripts), so I put
"Very good"; but it is improving, buth thanks to builtinification and
to efforts of msysGit maintainers and developers.
scm> <section id="user_interaces">
scm> <title>User Interfaces</title>
scm> <section id="web_interface">
scm> <title>Web Interface</title>
scm> <expl>
scm> Does the system have a WWW-based interface that can be
scm> used to browse the tree and the various revisions of the
scm> files, perform arbitrary diffs, etc?
scm> </expl>
scm> <compare>
scm> <s id="cvs">Yes.
scm> <a href="http://www.freebsd.org/projects/cvsweb.html">CVSweb</a>,
scm> <a href="http://www.viewvc.org/">ViewVC</a>,
scm> <a href="http://www.horde.org/chora/">Chora</a>,
scm> and <a href="http://wwcvs.republika.pl/">wwCVS</a>.
scm> </s>
scm> <s id="bazaar">
scm> Yes, several:
scm> <a href="http://www.lag.net/loggerhead/">Loggerhead</a>,
scm> <a href="http://goffredo-baroncelli.homelinux.net/bazaar/">Webserve</a>,
scm> <a href="http://mccormick.cx/dev/bzrweb/index.py/log/bzrweb/head">Bzrweb</a>,
scm> and
scm> <a href="http://bazaar-vcs.org/TracBzr">Trac</a>.
scm> </s>
scm> <s id="mercurial">Yes. The web interface is a bundled component.</s>
scm> <s id="git">
scm> Yes. Gitweb is included in distribution.
scm> </s>
scm> </compare>
scm> </section>
For other SCMs there are listed many different web interfaces.
So I would perhaps put here a list:
Yes. Gitweb (in Perl) is included in distribution, but there are
many other web interfaces:
<a href="http://hjemli.net/git/cgit/">cgit</a> (in C),
<a href="http://code.google.com/p/git-php/">git-php</a> and
<a href="http://people.proekspert.ee/peeter/blog/index.php?category=5">its fork<a> (in PHP),
<a href="http://viewgit.sourceforge.net/">ViewGit</a> (in PHP),
<a href="http://www.flameeyes.eu/projects#gitarella">Gitarella</a> (in Ruby)
Perhaps we should leave programming language used, as there is no such
information provided for other SCM listed in comparison.
Comments:
I have not put Wit by Daniel Chokola in Ruby/eRuby, as the site seems
to be down. I also didn't add GitStat which is not web interface but
offers instead web-based statistics about repository, and hosting
solutions such as Gitorious (in Ruby), InDefero (in PHP) and GitHub
(not open, in Ruby).
I'm also not sure which one of git-php implementations to list; perhaps
simply the first one, the one that has kind of homepage on Google Code.
scm> <section id="availability_of_guis">
scm> <title>Availability of Graphical User-Interfaces.</title>
scm> <expl>
scm> What is the availability of graphical user-interfaces for
scm> the system? How many GUI clients are present for it?
scm> </expl>
scm> <compare>
scm> <s id="bazaar">
scm> There are several graphical frontends in
scm> development,
scm> see <a href="http://bazaar-vcs.org/BzrPlugins">the Bazaar Plugins page</a>
scm> and <a href="http://bazaar-vcs.org/3rdPartyTools">the Third-party Tools page</a>.
scm> Notable
scm> are <a href="http://bazaar-vcs.org/QBzr">QBzr
scm> (Qt)</a> and
scm> <a href="http://bazaar-vcs.org/bzr-gtk">bzr-gtk (GTK+)</a>, which
scm> can be considered beta quality. Work is also
scm> being done on integrating Bazaar with Windows
scm> Explorer, Eclipse, Nautilus, and Meld.
scm> </s>
scm> <s id="mercurial">
scm> History viewing available with hgit extension;
scm> check-in extension (hgct) makes committing easier.
scm> Some third-party IDEs and GUI tools (e.g. eric3,
scm> meld) have integrated Mercurial support.
scm> </s>
scm> <s id="git">
scm> Gitk is included in distribution.
scm> Qgit and Git-gui tools are also available.
scm> </s>
Re-wrapped.
scm> </compare>
scm> </section>
scm> </section>
There is a question whether to list all (or at least more popular) GUI
tools, or list only built-in and perhaps one or two more, and direct
to Git Wiki for details, like below:
Gitk history viewer and Git-gui commit tool are included in distribution.
There are also other tools available, like
<a href="http://digilander.libero.it/mcostalba/">QGit</a> (Qt) nad
<a href="http://github.com/Caged/gitnub/wikis">GitNub</a> (MacOS);
see <a href="http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#gui">Interfaces,
Frontends And Tools</a> page on Git Wiki for a list.
I have listed two most popular GUI according to currently open survey
http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8
Comments:
Should there be mentioned integration and beginning of integration with
IDE, editors and other tools in the form of EGit (Eclipse Git plugin),
similar work for NetBeans and IntelliJ/JetBeans, Git TextMate bundle,
Emacs modes (git.el, vc-git.el, DVC, magit), and support from other
tools like PIDA and Meld? It is mentioned for other SCM, but it is
not GUI in exact meaning of this word.
scm> <section id="license">
scm> <title>License</title>
scm> <expl>
scm> What are the licensing terms for the software?
scm> </expl>
scm> <compare>
scm> <s id="mercurial">GNU GPL (open source)</s>
scm> <s id="git">GNU GPL v2 (open source).</s>
scm> </compare>
scm> </section>
scm> </section>
No comments here.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: interactive rebase not rebasing
From: Shawn O. Pearce @ 2008-10-01 18:31 UTC (permalink / raw)
To: Stephen Haberman; +Cc: Andreas Ericsson, git
In-Reply-To: <20081001121321.5761fc7e.stephen@exigencecorp.com>
Stephen Haberman <stephen@exigencecorp.com> wrote:
>
> > > I've attempted to do that. Now that I sent in the patch, if you could
> > > review it, I would appreciate your feedback.
> >
> > I'm heading home from work now. I'll look it over tonight or tomorrow
> > morning.
>
> Cool, thanks.
>
> Question: how taboo is it to just add another test file?
>
> I can suffer through getting it to work, but a t3409 would be much
> easier, and probably easier to read as well as a I could setup my own
> DAG instead of hacking onto 3404s.
Usually folks prefer to add stuff to an existing test file, but
if the DAG is already a mess and you need a different DAG I find
it easier to just add new test file. Thus far Junio hasn't pushed
back when I've done that. Maybe I'm just lucky. :-)
--
Shawn.
^ permalink raw reply
* [PATCH v2] fix openssl headers conflicting with custom SHA1 implementations
From: Nicolas Pitre @ 2008-10-01 18:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, git
In-Reply-To: <20081001163952.GJ21310@spearce.org>
On ARM I have the following compilation errors:
CC fast-import.o
In file included from cache.h:8,
from builtin.h:6,
from fast-import.c:142:
arm/sha1.h:14: error: conflicting types for 'SHA_CTX'
/usr/include/openssl/sha.h:105: error: previous declaration of 'SHA_CTX' was here
arm/sha1.h:16: error: conflicting types for 'SHA1_Init'
/usr/include/openssl/sha.h:115: error: previous declaration of 'SHA1_Init' was here
arm/sha1.h:17: error: conflicting types for 'SHA1_Update'
/usr/include/openssl/sha.h:116: error: previous declaration of 'SHA1_Update' was here
arm/sha1.h:18: error: conflicting types for 'SHA1_Final'
/usr/include/openssl/sha.h:117: error: previous declaration of 'SHA1_Final' was here
make: *** [fast-import.o] Error 1
This is because openssl header files are always included in
git-compat-util.h since commit 684ec6c63c whenever NO_OPENSSL is not
set, which somehow brings in <openssl/sha1.h> clashing with the custom
ARM version. Compilation of git is probably broken on PPC too for the
same reason.
Turns out that the only file requiring openssl/ssl.h and openssl/err.h
is imap-send.c. But only moving those problematic includes there
doesn't solve the issue as it also includes cache.h which brings in the
conflicting local SHA1 header file.
As suggested by Jeff King, the best solution is to rename our references
to SHA1 functions and structure to something git specific, and define those
according to the implementation used.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Wed, 1 Oct 2008, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Wed, 1 Oct 2008, Shawn O. Pearce wrote:
> > > Jeff King <peff@peff.net> wrote:
> > > > On Wed, Oct 01, 2008 at 08:54:58AM -0700, Shawn O. Pearce wrote:
> > > >
> > > > > I think its easy enough to just rename our SHA_CTX and SHA_*
> > > > > functions to something more git specific. Since its mostly a
global
> > > >
> > > > I think that is the cleanest and simplest solution. As for merging pain,
> > > > I think Junio would generally do a mechanical change like this as the
> > > > first thing after a release. However, in this case, I think we might
> > > > want it sooner if the conflict is causing breakage.
> > >
> > > Oh, yea, that's probably true. But with ARM broken according to
> > > Nico I'd almost just want this fixed in the upcoming 1.6.1 release.
> >
> > > Its simple enough to do. We can even do something like this during
> > > the transition period until right before the 1.6.1 final:
> >
> > Because it's easy to do then I'd do it sooner than later.
>
> Nico, are you going to write a patch for this?
Here it is. Tested with straight openssl, the mozilla version, and the
ARM version. Can't test the ppc version but this should look straight
forward enough.
arm/sha1.c | 16 ++++++++--------
arm/sha1.h | 15 ++++++++++-----
arm/sha1_arm.S | 4 ++--
builtin-unpack-objects.c | 10 +++++-----
cache.h | 8 +++++++-
csum-file.c | 8 ++++----
csum-file.h | 2 +-
diff.c | 12 ++++++------
fast-import.c | 18 +++++++++---------
http-push.c | 10 +++++-----
http-walker.c | 10 +++++-----
index-pack.c | 8 ++++----
mozilla-sha1/sha1.c | 18 +++++++++---------
mozilla-sha1/sha1.h | 13 +++++++++----
pack-check.c | 16 ++++++++--------
pack-write.c | 30 +++++++++++++++---------------
patch-id.c | 12 ++++++------
ppc/sha1.c | 18 +++++++++---------
ppc/sha1.h | 15 ++++++++++-----
ppc/sha1ppc.S | 4 ++--
read-cache.c | 28 ++++++++++++++--------------
rerere.c | 10 +++++-----
sha1_file.c | 10 +++++-----
test-sha1.c | 8 ++++----
24 files changed, 162 insertions(+), 141 deletions(-)
diff --git a/arm/sha1.c b/arm/sha1.c
index 9e3ae03..c61ad4a 100644
--- a/arm/sha1.c
+++ b/arm/sha1.c
@@ -8,9 +8,9 @@
#include <string.h>
#include "sha1.h"
-extern void sha_transform(uint32_t *hash, const unsigned char *data, uint32_t *W);
+extern void arm_sha_transform(uint32_t *hash, const unsigned char *data, uint32_t *W);
-void SHA1_Init(SHA_CTX *c)
+void arm_SHA1_Init(arm_SHA_CTX *c)
{
c->len = 0;
c->hash[0] = 0x67452301;
@@ -20,7 +20,7 @@ void SHA1_Init(SHA_CTX *c)
c->hash[4] = 0xc3d2e1f0;
}
-void SHA1_Update(SHA_CTX *c, const void *p, unsigned long n)
+void arm_SHA1_Update(arm_SHA_CTX *c, const void *p, unsigned long n)
{
uint32_t workspace[80];
unsigned int partial;
@@ -32,12 +32,12 @@ void SHA1_Update(SHA_CTX *c, const void *p, unsigned long n)
if (partial) {
done = 64 - partial;
memcpy(c->buffer + partial, p, done);
- sha_transform(c->hash, c->buffer, workspace);
+ arm_sha_transform(c->hash, c->buffer, workspace);
partial = 0;
} else
done = 0;
while (n >= done + 64) {
- sha_transform(c->hash, p + done, workspace);
+ arm_sha_transform(c->hash, p + done, workspace);
done += 64;
}
} else
@@ -46,7 +46,7 @@ void SHA1_Update(SHA_CTX *c, const void *p, unsigned long n)
memcpy(c->buffer + partial, p + done, n - done);
}
-void SHA1_Final(unsigned char *hash, SHA_CTX *c)
+void arm_SHA1_Final(unsigned char *hash, arm_SHA_CTX *c)
{
uint64_t bitlen;
uint32_t bitlen_hi, bitlen_lo;
@@ -57,7 +57,7 @@ void SHA1_Final(unsigned char *hash, SHA_CTX *c)
bitlen = c->len << 3;
offset = c->len & 0x3f;
padlen = ((offset < 56) ? 56 : (64 + 56)) - offset;
- SHA1_Update(c, padding, padlen);
+ arm_SHA1_Update(c, padding, padlen);
bitlen_hi = bitlen >> 32;
bitlen_lo = bitlen & 0xffffffff;
@@ -69,7 +69,7 @@ void SHA1_Final(unsigned char *hash, SHA_CTX *c)
bits[5] = bitlen_lo >> 16;
bits[6] = bitlen_lo >> 8;
bits[7] = bitlen_lo;
- SHA1_Update(c, bits, 8);
+ arm_SHA1_Update(c, bits, 8);
for (i = 0; i < 5; i++) {
uint32_t v = c->hash[i];
diff --git a/arm/sha1.h b/arm/sha1.h
index 3952646..b61b618 100644
--- a/arm/sha1.h
+++ b/arm/sha1.h
@@ -7,12 +7,17 @@
#include <stdint.h>
-typedef struct sha_context {
+typedef struct {
uint64_t len;
uint32_t hash[5];
unsigned char buffer[64];
-} SHA_CTX;
+} arm_SHA_CTX;
-void SHA1_Init(SHA_CTX *c);
-void SHA1_Update(SHA_CTX *c, const void *p, unsigned long n);
-void SHA1_Final(unsigned char *hash, SHA_CTX *c);
+void arm_SHA1_Init(arm_SHA_CTX *c);
+void arm_SHA1_Update(arm_SHA_CTX *c, const void *p, unsigned long n);
+void arm_SHA1_Final(unsigned char *hash, arm_SHA_CTX *c);
+
+#define git_SHA_CTX arm_SHA_CTX
+#define git_SHA1_Init arm_SHA1_Init
+#define git_SHA1_Update arm_SHA1_Update
+#define git_SHA1_Final arm_SHA1_Final
diff --git a/arm/sha1_arm.S b/arm/sha1_arm.S
index 8c1cb99..41e9263 100644
--- a/arm/sha1_arm.S
+++ b/arm/sha1_arm.S
@@ -10,7 +10,7 @@
*/
.text
- .globl sha_transform
+ .globl arm_sha_transform
/*
* void sha_transform(uint32_t *hash, const unsigned char *data, uint32_t *W);
@@ -18,7 +18,7 @@
* note: the "data" pointer may be unaligned.
*/
-sha_transform:
+arm_sha_transform:
stmfd sp!, {r4 - r8, lr}
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index 40b20f2..d2796b6 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -19,7 +19,7 @@ static const char unpack_usage[] = "git unpack-objects [-n] [-q] [-r] [--strict]
static unsigned char buffer[4096];
static unsigned int offset, len;
static off_t consumed_bytes;
-static SHA_CTX ctx;
+static git_SHA_CTX ctx;
/*
* When running under --strict mode, objects whose reachability are
@@ -59,7 +59,7 @@ static void *fill(int min)
if (min > sizeof(buffer))
die("cannot fill %d bytes", min);
if (offset) {
- SHA1_Update(&ctx, buffer, offset);
+ git_SHA1_Update(&ctx, buffer, offset);
memmove(buffer, buffer + offset, len);
offset = 0;
}
@@ -539,10 +539,10 @@ int cmd_unpack_objects(int argc, const char **argv, const char *prefix)
/* We don't take any non-flag arguments now.. Maybe some day */
usage(unpack_usage);
}
- SHA1_Init(&ctx);
+ git_SHA1_Init(&ctx);
unpack_all();
- SHA1_Update(&ctx, buffer, offset);
- SHA1_Final(sha1, &ctx);
+ git_SHA1_Update(&ctx, buffer, offset);
+ git_SHA1_Final(sha1, &ctx);
if (strict)
write_rest();
if (hashcmp(fill(20), sha1))
diff --git a/cache.h b/cache.h
index f4b8ddf..9ff1b2f 100644
--- a/cache.h
+++ b/cache.h
@@ -6,8 +6,14 @@
#include "hash.h"
#include SHA1_HEADER
-#include <zlib.h>
+#ifndef git_SHA_CTX
+#define git_SHA_CTX SHA_CTX
+#define git_SHA1_Init SHA1_Init
+#define git_SHA1_Update SHA1_Update
+#define git_SHA1_Final SHA1_Final
+#endif
+#include <zlib.h>
#if defined(NO_DEFLATE_BOUND) || ZLIB_VERNUM < 0x1200
#define deflateBound(c,s) ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)
#endif
diff --git a/csum-file.c b/csum-file.c
index bb70c75..717d29f 100644
--- a/csum-file.c
+++ b/csum-file.c
@@ -36,11 +36,11 @@ int sha1close(struct sha1file *f, unsigned char *result, unsigned int flags)
unsigned offset = f->offset;
if (offset) {
- SHA1_Update(&f->ctx, f->buffer, offset);
+ git_SHA1_Update(&f->ctx, f->buffer, offset);
sha1flush(f, f->buffer, offset);
f->offset = 0;
}
- SHA1_Final(f->buffer, &f->ctx);
+ git_SHA1_Final(f->buffer, &f->ctx);
if (result)
hashcpy(result, f->buffer);
if (flags & (CSUM_CLOSE | CSUM_FSYNC)) {
@@ -82,7 +82,7 @@ int sha1write(struct sha1file *f, void *buf, unsigned int count)
buf = (char *) buf + nr;
left -= nr;
if (!left) {
- SHA1_Update(&f->ctx, data, offset);
+ git_SHA1_Update(&f->ctx, data, offset);
sha1flush(f, data, offset);
offset = 0;
}
@@ -105,7 +105,7 @@ struct sha1file *sha1fd_throughput(int fd, const char *name, struct progress *tp
f->tp = tp;
f->name = name;
f->do_crc = 0;
- SHA1_Init(&f->ctx);
+ git_SHA1_Init(&f->ctx);
return f;
}
diff --git a/csum-file.h b/csum-file.h
index 72c9487..9e13342 100644
--- a/csum-file.h
+++ b/csum-file.h
@@ -7,7 +7,7 @@ struct progress;
struct sha1file {
int fd;
unsigned int offset;
- SHA_CTX ctx;
+ git_SHA_CTX ctx;
off_t total;
struct progress *tp;
const char *name;
diff --git a/diff.c b/diff.c
index b001d7b..e023348 100644
--- a/diff.c
+++ b/diff.c
@@ -3089,7 +3089,7 @@ static void diff_summary(FILE *file, struct diff_filepair *p)
}
struct patch_id_t {
- SHA_CTX *ctx;
+ git_SHA_CTX *ctx;
int patchlen;
};
@@ -3117,7 +3117,7 @@ static void patch_id_consume(void *priv, char *line, unsigned long len)
new_len = remove_space(line, len);
- SHA1_Update(data->ctx, line, new_len);
+ git_SHA1_Update(data->ctx, line, new_len);
data->patchlen += new_len;
}
@@ -3126,11 +3126,11 @@ static int diff_get_patch_id(struct diff_options *options, unsigned char *sha1)
{
struct diff_queue_struct *q = &diff_queued_diff;
int i;
- SHA_CTX ctx;
+ git_SHA_CTX ctx;
struct patch_id_t data;
char buffer[PATH_MAX * 4 + 20];
- SHA1_Init(&ctx);
+ git_SHA1_Init(&ctx);
memset(&data, 0, sizeof(struct patch_id_t));
data.ctx = &ctx;
@@ -3192,7 +3192,7 @@ static int diff_get_patch_id(struct diff_options *options, unsigned char *sha1)
len2, p->two->path,
len1, p->one->path,
len2, p->two->path);
- SHA1_Update(&ctx, buffer, len1);
+ git_SHA1_Update(&ctx, buffer, len1);
xpp.flags = XDF_NEED_MINIMAL;
xecfg.ctxlen = 3;
@@ -3201,7 +3201,7 @@ static int diff_get_patch_id(struct diff_options *options, unsigned char *sha1)
&xpp, &xecfg, &ecb);
}
- SHA1_Final(sha1, &ctx);
+ git_SHA1_Final(sha1, &ctx);
return 0;
}
diff --git a/fast-import.c b/fast-import.c
index ab6689a..3c035a5 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -845,7 +845,7 @@ static int oecmp (const void *a_, const void *b_)
static char *create_index(void)
{
static char tmpfile[PATH_MAX];
- SHA_CTX ctx;
+ git_SHA_CTX ctx;
struct sha1file *f;
struct object_entry **idx, **c, **last, *e;
struct object_entry_pool *o;
@@ -882,17 +882,17 @@ static char *create_index(void)
idx_fd = xmkstemp(tmpfile);
f = sha1fd(idx_fd, tmpfile);
sha1write(f, array, 256 * sizeof(int));
- SHA1_Init(&ctx);
+ git_SHA1_Init(&ctx);
for (c = idx; c != last; c++) {
uint32_t offset = htonl((*c)->offset);
sha1write(f, &offset, 4);
sha1write(f, (*c)->sha1, sizeof((*c)->sha1));
- SHA1_Update(&ctx, (*c)->sha1, 20);
+ git_SHA1_Update(&ctx, (*c)->sha1, 20);
}
sha1write(f, pack_data->sha1, sizeof(pack_data->sha1));
sha1close(f, NULL, CSUM_FSYNC);
free(idx);
- SHA1_Final(pack_data->sha1, &ctx);
+ git_SHA1_Final(pack_data->sha1, &ctx);
return tmpfile;
}
@@ -1033,15 +1033,15 @@ static int store_object(
unsigned char hdr[96];
unsigned char sha1[20];
unsigned long hdrlen, deltalen;
- SHA_CTX c;
+ git_SHA_CTX c;
z_stream s;
hdrlen = sprintf((char*)hdr,"%s %lu", typename(type),
(unsigned long)dat->len) + 1;
- SHA1_Init(&c);
- SHA1_Update(&c, hdr, hdrlen);
- SHA1_Update(&c, dat->buf, dat->len);
- SHA1_Final(sha1, &c);
+ git_SHA1_Init(&c);
+ git_SHA1_Update(&c, hdr, hdrlen);
+ git_SHA1_Update(&c, dat->buf, dat->len);
+ git_SHA1_Final(sha1, &c);
if (sha1out)
hashcpy(sha1out, sha1);
diff --git a/http-push.c b/http-push.c
index c9dd9a1..42f4d78 100644
--- a/http-push.c
+++ b/http-push.c
@@ -126,7 +126,7 @@ struct transfer_request
char errorstr[CURL_ERROR_SIZE];
long http_code;
unsigned char real_sha1[20];
- SHA_CTX c;
+ git_SHA_CTX c;
z_stream stream;
int zret;
int rename;
@@ -209,7 +209,7 @@ static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
request->stream.next_out = expn;
request->stream.avail_out = sizeof(expn);
request->zret = inflate(&request->stream, Z_SYNC_FLUSH);
- SHA1_Update(&request->c, expn,
+ git_SHA1_Update(&request->c, expn,
sizeof(expn) - request->stream.avail_out);
} while (request->stream.avail_in && request->zret == Z_OK);
data_received++;
@@ -270,7 +270,7 @@ static void start_fetch_loose(struct transfer_request *request)
inflateInit(&request->stream);
- SHA1_Init(&request->c);
+ git_SHA1_Init(&request->c);
url = xmalloc(strlen(remote->url) + 50);
request->url = xmalloc(strlen(remote->url) + 50);
@@ -310,7 +310,7 @@ static void start_fetch_loose(struct transfer_request *request)
if (prev_read == -1) {
memset(&request->stream, 0, sizeof(request->stream));
inflateInit(&request->stream);
- SHA1_Init(&request->c);
+ git_SHA1_Init(&request->c);
if (prev_posn>0) {
prev_posn = 0;
lseek(request->local_fileno, 0, SEEK_SET);
@@ -742,7 +742,7 @@ static void finish_request(struct transfer_request *request)
fprintf(stderr, "Warning: requested range invalid; we may already have all the data.\n");
inflateEnd(&request->stream);
- SHA1_Final(request->real_sha1, &request->c);
+ git_SHA1_Final(request->real_sha1, &request->c);
if (request->zret != Z_STREAM_END) {
unlink(request->tmpfile);
} else if (hashcmp(request->obj->sha1, request->real_sha1)) {
diff --git a/http-walker.c b/http-walker.c
index 9dc6b27..7271c7d 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -36,7 +36,7 @@ struct object_request
char errorstr[CURL_ERROR_SIZE];
long http_code;
unsigned char real_sha1[20];
- SHA_CTX c;
+ git_SHA_CTX c;
z_stream stream;
int zret;
int rename;
@@ -83,7 +83,7 @@ static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
obj_req->stream.next_out = expn;
obj_req->stream.avail_out = sizeof(expn);
obj_req->zret = inflate(&obj_req->stream, Z_SYNC_FLUSH);
- SHA1_Update(&obj_req->c, expn,
+ git_SHA1_Update(&obj_req->c, expn,
sizeof(expn) - obj_req->stream.avail_out);
} while (obj_req->stream.avail_in && obj_req->zret == Z_OK);
data_received++;
@@ -144,7 +144,7 @@ static void start_object_request(struct walker *walker,
inflateInit(&obj_req->stream);
- SHA1_Init(&obj_req->c);
+ git_SHA1_Init(&obj_req->c);
url = xmalloc(strlen(obj_req->repo->base) + 51);
obj_req->url = xmalloc(strlen(obj_req->repo->base) + 51);
@@ -184,7 +184,7 @@ static void start_object_request(struct walker *walker,
if (prev_read == -1) {
memset(&obj_req->stream, 0, sizeof(obj_req->stream));
inflateInit(&obj_req->stream);
- SHA1_Init(&obj_req->c);
+ git_SHA1_Init(&obj_req->c);
if (prev_posn>0) {
prev_posn = 0;
lseek(obj_req->local, 0, SEEK_SET);
@@ -244,7 +244,7 @@ static void finish_object_request(struct object_request *obj_req)
}
inflateEnd(&obj_req->stream);
- SHA1_Final(obj_req->real_sha1, &obj_req->c);
+ git_SHA1_Final(obj_req->real_sha1, &obj_req->c);
if (obj_req->zret != Z_STREAM_END) {
unlink(obj_req->tmpfile);
return;
diff --git a/index-pack.c b/index-pack.c
index 530d820..2e4c088 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -67,7 +67,7 @@ static struct progress *progress;
static unsigned char input_buffer[4096];
static unsigned int input_offset, input_len;
static off_t consumed_bytes;
-static SHA_CTX input_ctx;
+static git_SHA_CTX input_ctx;
static uint32_t input_crc32;
static int input_fd, output_fd, pack_fd;
@@ -119,7 +119,7 @@ static void flush(void)
if (input_offset) {
if (output_fd >= 0)
write_or_die(output_fd, input_buffer, input_offset);
- SHA1_Update(&input_ctx, input_buffer, input_offset);
+ git_SHA1_Update(&input_ctx, input_buffer, input_offset);
memmove(input_buffer, input_buffer + input_offset, input_len);
input_offset = 0;
}
@@ -188,7 +188,7 @@ static char *open_pack_file(char *pack_name)
output_fd = -1;
pack_fd = input_fd;
}
- SHA1_Init(&input_ctx);
+ git_SHA1_Init(&input_ctx);
return pack_name;
}
@@ -588,7 +588,7 @@ static void parse_pack_objects(unsigned char *sha1)
/* Check pack integrity */
flush();
- SHA1_Final(sha1, &input_ctx);
+ git_SHA1_Final(sha1, &input_ctx);
if (hashcmp(fill(20), sha1))
die("pack is corrupted (SHA1 mismatch)");
use(20);
diff --git a/mozilla-sha1/sha1.c b/mozilla-sha1/sha1.c
index 3f06b83..95a4ebf 100644
--- a/mozilla-sha1/sha1.c
+++ b/mozilla-sha1/sha1.c
@@ -35,9 +35,9 @@
#include "sha1.h"
-static void shaHashBlock(SHA_CTX *ctx);
+static void shaHashBlock(moz_SHA_CTX *ctx);
-void SHA1_Init(SHA_CTX *ctx) {
+void moz_SHA1_Init(moz_SHA_CTX *ctx) {
int i;
ctx->lenW = 0;
@@ -56,7 +56,7 @@ void SHA1_Init(SHA_CTX *ctx) {
}
-void SHA1_Update(SHA_CTX *ctx, const void *_dataIn, int len) {
+void moz_SHA1_Update(moz_SHA_CTX *ctx, const void *_dataIn, int len) {
const unsigned char *dataIn = _dataIn;
int i;
@@ -75,7 +75,7 @@ void SHA1_Update(SHA_CTX *ctx, const void *_dataIn, int len) {
}
-void SHA1_Final(unsigned char hashout[20], SHA_CTX *ctx) {
+void moz_SHA1_Final(unsigned char hashout[20], moz_SHA_CTX *ctx) {
unsigned char pad0x80 = 0x80;
unsigned char pad0x00 = 0x00;
unsigned char padlen[8];
@@ -91,10 +91,10 @@ void SHA1_Final(unsigned char hashout[20], SHA_CTX *ctx) {
padlen[5] = (unsigned char)((ctx->sizeLo >> 16) & 255);
padlen[6] = (unsigned char)((ctx->sizeLo >> 8) & 255);
padlen[7] = (unsigned char)((ctx->sizeLo >> 0) & 255);
- SHA1_Update(ctx, &pad0x80, 1);
+ moz_SHA1_Update(ctx, &pad0x80, 1);
while (ctx->lenW != 56)
- SHA1_Update(ctx, &pad0x00, 1);
- SHA1_Update(ctx, padlen, 8);
+ moz_SHA1_Update(ctx, &pad0x00, 1);
+ moz_SHA1_Update(ctx, padlen, 8);
/* Output hash
*/
@@ -106,13 +106,13 @@ void SHA1_Final(unsigned char hashout[20], SHA_CTX *ctx) {
/*
* Re-initialize the context (also zeroizes contents)
*/
- SHA1_Init(ctx);
+ moz_SHA1_Init(ctx);
}
#define SHA_ROT(X,n) (((X) << (n)) | ((X) >> (32-(n))))
-static void shaHashBlock(SHA_CTX *ctx) {
+static void shaHashBlock(moz_SHA_CTX *ctx) {
int t;
unsigned int A,B,C,D,E,TEMP;
diff --git a/mozilla-sha1/sha1.h b/mozilla-sha1/sha1.h
index 16f2d3d..aa48a46 100644
--- a/mozilla-sha1/sha1.h
+++ b/mozilla-sha1/sha1.h
@@ -38,8 +38,13 @@ typedef struct {
unsigned int W[80];
int lenW;
unsigned int sizeHi,sizeLo;
-} SHA_CTX;
+} moz_SHA_CTX;
-void SHA1_Init(SHA_CTX *ctx);
-void SHA1_Update(SHA_CTX *ctx, const void *dataIn, int len);
-void SHA1_Final(unsigned char hashout[20], SHA_CTX *ctx);
+void moz_SHA1_Init(moz_SHA_CTX *ctx);
+void moz_SHA1_Update(moz_SHA_CTX *ctx, const void *dataIn, int len);
+void moz_SHA1_Final(unsigned char hashout[20], moz_SHA_CTX *ctx);
+
+#define git_SHA_CTX moz_SHA_CTX
+#define git_SHA1_Init moz_SHA1_Init
+#define git_SHA1_Update moz_SHA1_Update
+#define git_SHA1_Final moz_SHA1_Final
diff --git a/pack-check.c b/pack-check.c
index f596bf2..90c33b1 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -47,7 +47,7 @@ static int verify_packfile(struct packed_git *p,
{
off_t index_size = p->index_size;
const unsigned char *index_base = p->index_data;
- SHA_CTX ctx;
+ git_SHA_CTX ctx;
unsigned char sha1[20], *pack_sig;
off_t offset = 0, pack_sig_ofs = p->pack_size - 20;
uint32_t nr_objects, i;
@@ -60,16 +60,16 @@ static int verify_packfile(struct packed_git *p,
* immediately.
*/
- SHA1_Init(&ctx);
+ git_SHA1_Init(&ctx);
while (offset < pack_sig_ofs) {
unsigned int remaining;
unsigned char *in = use_pack(p, w_curs, offset, &remaining);
offset += remaining;
if (offset > pack_sig_ofs)
remaining -= (unsigned int)(offset - pack_sig_ofs);
- SHA1_Update(&ctx, in, remaining);
+ git_SHA1_Update(&ctx, in, remaining);
}
- SHA1_Final(sha1, &ctx);
+ git_SHA1_Final(sha1, &ctx);
pack_sig = use_pack(p, w_curs, pack_sig_ofs, NULL);
if (hashcmp(sha1, pack_sig))
err = error("%s SHA1 checksum mismatch",
@@ -135,7 +135,7 @@ int verify_pack(struct packed_git *p)
{
off_t index_size;
const unsigned char *index_base;
- SHA_CTX ctx;
+ git_SHA_CTX ctx;
unsigned char sha1[20];
int err = 0;
struct pack_window *w_curs = NULL;
@@ -146,9 +146,9 @@ int verify_pack(struct packed_git *p)
index_base = p->index_data;
/* Verify SHA1 sum of the index file */
- SHA1_Init(&ctx);
- SHA1_Update(&ctx, index_base, (unsigned int)(index_size - 20));
- SHA1_Final(sha1, &ctx);
+ git_SHA1_Init(&ctx);
+ git_SHA1_Update(&ctx, index_base, (unsigned int)(index_size - 20));
+ git_SHA1_Final(sha1, &ctx);
if (hashcmp(sha1, index_base + index_size - 20))
err = error("Packfile index for %s SHA1 mismatch",
p->pack_name);
diff --git a/pack-write.c b/pack-write.c
index 3621f1d..b426006 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -25,7 +25,7 @@ char *write_idx_file(char *index_name, struct pack_idx_entry **objects,
off_t last_obj_offset = 0;
uint32_t array[256];
int i, fd;
- SHA_CTX ctx;
+ git_SHA_CTX ctx;
uint32_t index_version;
if (nr_objects) {
@@ -86,7 +86,7 @@ char *write_idx_file(char *index_name, struct pack_idx_entry **objects,
sha1write(f, array, 256 * 4);
/* compute the SHA1 hash of sorted object names. */
- SHA1_Init(&ctx);
+ git_SHA1_Init(&ctx);
/*
* Write the actual SHA1 entries..
@@ -99,7 +99,7 @@ char *write_idx_file(char *index_name, struct pack_idx_entry **objects,
sha1write(f, &offset, 4);
}
sha1write(f, obj->sha1, 20);
- SHA1_Update(&ctx, obj->sha1, 20);
+ git_SHA1_Update(&ctx, obj->sha1, 20);
}
if (index_version >= 2) {
@@ -140,7 +140,7 @@ char *write_idx_file(char *index_name, struct pack_idx_entry **objects,
sha1write(f, sha1, 20);
sha1close(f, NULL, CSUM_FSYNC);
- SHA1_Final(sha1, &ctx);
+ git_SHA1_Final(sha1, &ctx);
return index_name;
}
@@ -168,12 +168,12 @@ void fixup_pack_header_footer(int pack_fd,
off_t partial_pack_offset)
{
int aligned_sz, buf_sz = 8 * 1024;
- SHA_CTX old_sha1_ctx, new_sha1_ctx;
+ git_SHA_CTX old_sha1_ctx, new_sha1_ctx;
struct pack_header hdr;
char *buf;
- SHA1_Init(&old_sha1_ctx);
- SHA1_Init(&new_sha1_ctx);
+ git_SHA1_Init(&old_sha1_ctx);
+ git_SHA1_Init(&new_sha1_ctx);
if (lseek(pack_fd, 0, SEEK_SET) != 0)
die("Failed seeking to start of %s: %s", pack_name, strerror(errno));
@@ -181,9 +181,9 @@ void fixup_pack_header_footer(int pack_fd,
die("Unable to reread header of %s: %s", pack_name, strerror(errno));
if (lseek(pack_fd, 0, SEEK_SET) != 0)
die("Failed seeking to start of %s: %s", pack_name, strerror(errno));
- SHA1_Update(&old_sha1_ctx, &hdr, sizeof(hdr));
+ git_SHA1_Update(&old_sha1_ctx, &hdr, sizeof(hdr));
hdr.hdr_entries = htonl(object_count);
- SHA1_Update(&new_sha1_ctx, &hdr, sizeof(hdr));
+ git_SHA1_Update(&new_sha1_ctx, &hdr, sizeof(hdr));
write_or_die(pack_fd, &hdr, sizeof(hdr));
partial_pack_offset -= sizeof(hdr);
@@ -198,7 +198,7 @@ void fixup_pack_header_footer(int pack_fd,
break;
if (n < 0)
die("Failed to checksum %s: %s", pack_name, strerror(errno));
- SHA1_Update(&new_sha1_ctx, buf, n);
+ git_SHA1_Update(&new_sha1_ctx, buf, n);
aligned_sz -= n;
if (!aligned_sz)
@@ -207,11 +207,11 @@ void fixup_pack_header_footer(int pack_fd,
if (!partial_pack_sha1)
continue;
- SHA1_Update(&old_sha1_ctx, buf, n);
+ git_SHA1_Update(&old_sha1_ctx, buf, n);
partial_pack_offset -= n;
if (partial_pack_offset == 0) {
unsigned char sha1[20];
- SHA1_Final(sha1, &old_sha1_ctx);
+ git_SHA1_Final(sha1, &old_sha1_ctx);
if (hashcmp(sha1, partial_pack_sha1) != 0)
die("Unexpected checksum for %s "
"(disk corruption?)", pack_name);
@@ -220,7 +220,7 @@ void fixup_pack_header_footer(int pack_fd,
* pack, which also means making partial_pack_offset
* big enough not to matter anymore.
*/
- SHA1_Init(&old_sha1_ctx);
+ git_SHA1_Init(&old_sha1_ctx);
partial_pack_offset = ~partial_pack_offset;
partial_pack_offset -= MSB(partial_pack_offset, 1);
}
@@ -228,8 +228,8 @@ void fixup_pack_header_footer(int pack_fd,
free(buf);
if (partial_pack_sha1)
- SHA1_Final(partial_pack_sha1, &old_sha1_ctx);
- SHA1_Final(new_pack_sha1, &new_sha1_ctx);
+ git_SHA1_Final(partial_pack_sha1, &old_sha1_ctx);
+ git_SHA1_Final(new_pack_sha1, &new_sha1_ctx);
write_or_die(pack_fd, new_pack_sha1, 20);
fsync_or_die(pack_fd, pack_name);
}
diff --git a/patch-id.c b/patch-id.c
index 9349bc5..871f1d2 100644
--- a/patch-id.c
+++ b/patch-id.c
@@ -1,6 +1,6 @@
#include "cache.h"
-static void flush_current_id(int patchlen, unsigned char *id, SHA_CTX *c)
+static void flush_current_id(int patchlen, unsigned char *id, git_SHA_CTX *c)
{
unsigned char result[20];
char name[50];
@@ -8,10 +8,10 @@ static void flush_current_id(int patchlen, unsigned char *id, SHA_CTX *c)
if (!patchlen)
return;
- SHA1_Final(result, c);
+ git_SHA1_Final(result, c);
memcpy(name, sha1_to_hex(id), 41);
printf("%s %s\n", sha1_to_hex(result), name);
- SHA1_Init(c);
+ git_SHA1_Init(c);
}
static int remove_space(char *line)
@@ -31,10 +31,10 @@ static void generate_id_list(void)
{
static unsigned char sha1[20];
static char line[1000];
- SHA_CTX ctx;
+ git_SHA_CTX ctx;
int patchlen = 0;
- SHA1_Init(&ctx);
+ git_SHA1_Init(&ctx);
while (fgets(line, sizeof(line), stdin) != NULL) {
unsigned char n[20];
char *p = line;
@@ -67,7 +67,7 @@ static void generate_id_list(void)
/* Compute the sha without whitespace */
len = remove_space(line);
patchlen += len;
- SHA1_Update(&ctx, line, len);
+ git_SHA1_Update(&ctx, line, len);
}
flush_current_id(patchlen, sha1, &ctx);
}
diff --git a/ppc/sha1.c b/ppc/sha1.c
index 738e36c..ec6a192 100644
--- a/ppc/sha1.c
+++ b/ppc/sha1.c
@@ -10,10 +10,10 @@
#include <string.h>
#include "sha1.h"
-extern void sha1_core(uint32_t *hash, const unsigned char *p,
- unsigned int nblocks);
+extern void ppc_sha1_core(uint32_t *hash, const unsigned char *p,
+ unsigned int nblocks);
-int SHA1_Init(SHA_CTX *c)
+int ppc_SHA1_Init(ppc_SHA_CTX *c)
{
c->hash[0] = 0x67452301;
c->hash[1] = 0xEFCDAB89;
@@ -25,7 +25,7 @@ int SHA1_Init(SHA_CTX *c)
return 0;
}
-int SHA1_Update(SHA_CTX *c, const void *ptr, unsigned long n)
+int ppc_SHA1_Update(ppc_SHA_CTX *c, const void *ptr, unsigned long n)
{
unsigned long nb;
const unsigned char *p = ptr;
@@ -38,12 +38,12 @@ int SHA1_Update(SHA_CTX *c, const void *ptr, unsigned long n)
nb = n;
memcpy(&c->buf.b[c->cnt], p, nb);
if ((c->cnt += nb) == 64) {
- sha1_core(c->hash, c->buf.b, 1);
+ ppc_sha1_core(c->hash, c->buf.b, 1);
c->cnt = 0;
}
} else {
nb = n >> 6;
- sha1_core(c->hash, p, nb);
+ ppc_sha1_core(c->hash, p, nb);
nb <<= 6;
}
n -= nb;
@@ -52,7 +52,7 @@ int SHA1_Update(SHA_CTX *c, const void *ptr, unsigned long n)
return 0;
}
-int SHA1_Final(unsigned char *hash, SHA_CTX *c)
+int ppc_SHA1_Final(unsigned char *hash, ppc_SHA_CTX *c)
{
unsigned int cnt = c->cnt;
@@ -60,13 +60,13 @@ int SHA1_Final(unsigned char *hash, SHA_CTX *c)
if (cnt > 56) {
if (cnt < 64)
memset(&c->buf.b[cnt], 0, 64 - cnt);
- sha1_core(c->hash, c->buf.b, 1);
+ ppc_sha1_core(c->hash, c->buf.b, 1);
cnt = 0;
}
if (cnt < 56)
memset(&c->buf.b[cnt], 0, 56 - cnt);
c->buf.l[7] = c->len;
- sha1_core(c->hash, c->buf.b, 1);
+ ppc_sha1_core(c->hash, c->buf.b, 1);
memcpy(hash, c->hash, 20);
return 0;
}
diff --git a/ppc/sha1.h b/ppc/sha1.h
index c3c51aa..c405f73 100644
--- a/ppc/sha1.h
+++ b/ppc/sha1.h
@@ -5,7 +5,7 @@
*/
#include <stdint.h>
-typedef struct sha_context {
+typedef struct {
uint32_t hash[5];
uint32_t cnt;
uint64_t len;
@@ -13,8 +13,13 @@ typedef struct sha_context {
unsigned char b[64];
uint64_t l[8];
} buf;
-} SHA_CTX;
+} ppc_SHA_CTX;
-int SHA1_Init(SHA_CTX *c);
-int SHA1_Update(SHA_CTX *c, const void *p, unsigned long n);
-int SHA1_Final(unsigned char *hash, SHA_CTX *c);
+int ppc_SHA1_Init(ppc_SHA_CTX *c);
+int ppc_SHA1_Update(ppc_SHA_CTX *c, const void *p, unsigned long n);
+int ppc_SHA1_Final(unsigned char *hash, ppc_SHA_CTX *c);
+
+#define git_SHA_CTX ppc_SHA_CTX
+#define git_SHA1_Init ppc_SHA1_Init
+#define git_SHA1_Update ppc_SHA1_Update
+#define git_SHA1_Final ppc_SHA1_Final
diff --git a/ppc/sha1ppc.S b/ppc/sha1ppc.S
index f132696..1711eef 100644
--- a/ppc/sha1ppc.S
+++ b/ppc/sha1ppc.S
@@ -162,8 +162,8 @@ add RE(t),RE(t),%r0; rotlwi RB(t),RB(t),30
STEPUP4(fn, (t)+12, (s)+12,); \
STEPUP4(fn, (t)+16, (s)+16, loadk)
- .globl sha1_core
-sha1_core:
+ .globl ppc_sha1_core
+ppc_sha1_core:
stwu %r1,-80(%r1)
stmw %r13,4(%r1)
diff --git a/read-cache.c b/read-cache.c
index c5a8659..d7900f3 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1091,16 +1091,16 @@ struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really)
static int verify_hdr(struct cache_header *hdr, unsigned long size)
{
- SHA_CTX c;
+ git_SHA_CTX c;
unsigned char sha1[20];
if (hdr->hdr_signature != htonl(CACHE_SIGNATURE))
return error("bad signature");
if (hdr->hdr_version != htonl(2))
return error("bad index version");
- SHA1_Init(&c);
- SHA1_Update(&c, hdr, size - 20);
- SHA1_Final(sha1, &c);
+ git_SHA1_Init(&c);
+ git_SHA1_Update(&c, hdr, size - 20);
+ git_SHA1_Final(sha1, &c);
if (hashcmp(sha1, (unsigned char *)hdr + size - 20))
return error("bad index file sha1 signature");
return 0;
@@ -1297,11 +1297,11 @@ int unmerged_index(const struct index_state *istate)
static unsigned char write_buffer[WRITE_BUFFER_SIZE];
static unsigned long write_buffer_len;
-static int ce_write_flush(SHA_CTX *context, int fd)
+static int ce_write_flush(git_SHA_CTX *context, int fd)
{
unsigned int buffered = write_buffer_len;
if (buffered) {
- SHA1_Update(context, write_buffer, buffered);
+ git_SHA1_Update(context, write_buffer, buffered);
if (write_in_full(fd, write_buffer, buffered) != buffered)
return -1;
write_buffer_len = 0;
@@ -1309,7 +1309,7 @@ static int ce_write_flush(SHA_CTX *context, int fd)
return 0;
}
-static int ce_write(SHA_CTX *context, int fd, void *data, unsigned int len)
+static int ce_write(git_SHA_CTX *context, int fd, void *data, unsigned int len)
{
while (len) {
unsigned int buffered = write_buffer_len;
@@ -1331,7 +1331,7 @@ static int ce_write(SHA_CTX *context, int fd, void *data, unsigned int len)
return 0;
}
-static int write_index_ext_header(SHA_CTX *context, int fd,
+static int write_index_ext_header(git_SHA_CTX *context, int fd,
unsigned int ext, unsigned int sz)
{
ext = htonl(ext);
@@ -1340,13 +1340,13 @@ static int write_index_ext_header(SHA_CTX *context, int fd,
(ce_write(context, fd, &sz, 4) < 0)) ? -1 : 0;
}
-static int ce_flush(SHA_CTX *context, int fd)
+static int ce_flush(git_SHA_CTX *context, int fd)
{
unsigned int left = write_buffer_len;
if (left) {
write_buffer_len = 0;
- SHA1_Update(context, write_buffer, left);
+ git_SHA1_Update(context, write_buffer, left);
}
/* Flush first if not enough space for SHA1 signature */
@@ -1357,7 +1357,7 @@ static int ce_flush(SHA_CTX *context, int fd)
}
/* Append the SHA1 signature at the end */
- SHA1_Final(write_buffer + left, context);
+ git_SHA1_Final(write_buffer + left, context);
left += 20;
return (write_in_full(fd, write_buffer, left) != left) ? -1 : 0;
}
@@ -1411,7 +1411,7 @@ static void ce_smudge_racily_clean_entry(struct cache_entry *ce)
}
}
-static int ce_write_entry(SHA_CTX *c, int fd, struct cache_entry *ce)
+static int ce_write_entry(git_SHA_CTX *c, int fd, struct cache_entry *ce)
{
int size = ondisk_ce_size(ce);
struct ondisk_cache_entry *ondisk = xcalloc(1, size);
@@ -1435,7 +1435,7 @@ static int ce_write_entry(SHA_CTX *c, int fd, struct cache_entry *ce)
int write_index(const struct index_state *istate, int newfd)
{
- SHA_CTX c;
+ git_SHA_CTX c;
struct cache_header hdr;
int i, err, removed;
struct cache_entry **cache = istate->cache;
@@ -1449,7 +1449,7 @@ int write_index(const struct index_state *istate, int newfd)
hdr.hdr_version = htonl(2);
hdr.hdr_entries = htonl(entries - removed);
- SHA1_Init(&c);
+ git_SHA1_Init(&c);
if (ce_write(&c, newfd, &hdr, sizeof(hdr)) < 0)
return -1;
diff --git a/rerere.c b/rerere.c
index 8447cae..121f911 100644
--- a/rerere.c
+++ b/rerere.c
@@ -73,7 +73,7 @@ static int write_rr(struct string_list *rr, int out_fd)
static int handle_file(const char *path,
unsigned char *sha1, const char *output)
{
- SHA_CTX ctx;
+ git_SHA_CTX ctx;
char buf[1024];
int hunk_no = 0;
enum {
@@ -95,7 +95,7 @@ static int handle_file(const char *path,
}
if (sha1)
- SHA1_Init(&ctx);
+ git_SHA1_Init(&ctx);
strbuf_init(&one, 0);
strbuf_init(&two, 0);
@@ -127,9 +127,9 @@ static int handle_file(const char *path,
fputs(">>>>>>>\n", out);
}
if (sha1) {
- SHA1_Update(&ctx, one.buf ? one.buf : "",
+ git_SHA1_Update(&ctx, one.buf ? one.buf : "",
one.len + 1);
- SHA1_Update(&ctx, two.buf ? two.buf : "",
+ git_SHA1_Update(&ctx, two.buf ? two.buf : "",
two.len + 1);
}
strbuf_reset(&one);
@@ -154,7 +154,7 @@ static int handle_file(const char *path,
if (out)
fclose(out);
if (sha1)
- SHA1_Final(sha1, &ctx);
+ git_SHA1_Final(sha1, &ctx);
if (hunk != RR_CONTEXT) {
if (output)
unlink(output);
diff --git a/sha1_file.c b/sha1_file.c
index 70ff904..7515987 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2132,16 +2132,16 @@ static void write_sha1_file_prepare(const void *buf, unsigned long len,
const char *type, unsigned char *sha1,
char *hdr, int *hdrlen)
{
- SHA_CTX c;
+ git_SHA_CTX c;
/* Generate the header */
*hdrlen = sprintf(hdr, "%s %lu", type, len)+1;
/* Sha1.. */
- SHA1_Init(&c);
- SHA1_Update(&c, hdr, *hdrlen);
- SHA1_Update(&c, buf, len);
- SHA1_Final(sha1, &c);
+ git_SHA1_Init(&c);
+ git_SHA1_Update(&c, hdr, *hdrlen);
+ git_SHA1_Update(&c, buf, len);
+ git_SHA1_Final(sha1, &c);
}
/*
diff --git a/test-sha1.c b/test-sha1.c
index 78d7e98..9b98d07 100644
--- a/test-sha1.c
+++ b/test-sha1.c
@@ -2,7 +2,7 @@
int main(int ac, char **av)
{
- SHA_CTX ctx;
+ git_SHA_CTX ctx;
unsigned char sha1[20];
unsigned bufsz = 8192;
char *buffer;
@@ -20,7 +20,7 @@ int main(int ac, char **av)
die("OOPS");
}
- SHA1_Init(&ctx);
+ git_SHA1_Init(&ctx);
while (1) {
ssize_t sz, this_sz;
@@ -39,9 +39,9 @@ int main(int ac, char **av)
}
if (this_sz == 0)
break;
- SHA1_Update(&ctx, buffer, this_sz);
+ git_SHA1_Update(&ctx, buffer, this_sz);
}
- SHA1_Final(sha1, &ctx);
+ git_SHA1_Final(sha1, &ctx);
puts(sha1_to_hex(sha1));
exit(0);
}
^ permalink raw reply related
* Re: [EGIT PATCH 3/8] Dispose of allocated colors on finalize()
From: Robin Rosenberg @ 2008-10-01 17:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081001143718.GU21310@spearce.org>
onsdagen den 1 oktober 2008 16.37.18 skrev Shawn O. Pearce:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
[..]
> I think this is wrong. Any color that we get from
[...]
> What was the rationale for disposing of these resources? Did you
> identify that this is a resource leak somewhere? Because I'd like
> to make sure I actually understand the SWT resource model better
> so I don't commit mistakes in the future.
I read the Color javadoc, but not the getSystemColor one. You are right, drop this patch
and the "dispose" hunk in the next patch (which was also a
-- robin
^ permalink raw reply
* Re: interactive rebase not rebasing
From: Stephen Haberman @ 2008-10-01 17:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48E396AF.2000100@op5.se>
> > I've attempted to do that. Now that I sent in the patch, if you could
> > review it, I would appreciate your feedback.
>
> I'm heading home from work now. I'll look it over tonight or tomorrow
> morning.
Cool, thanks.
Question: how taboo is it to just add another test file?
I'm attempting to integrate my test into t3404, which is the existing
interactive rebase test. The two test_expect_success's I added worked
when I ran them at the start of the test and then reset --hard the
branches back for the other tests, but if I paste my tests where they
should probably be, in the middle after the other -p tests, they break
because the 10 or tests before this have screwed with the DAG already.
I can suffer through getting it to work, but a t3409 would be much
easier, and probably easier to read as well as a I could setup my own
DAG instead of hacking onto 3404s.
> Thanks for the confidence :-)
No problem. :-)
- Stephen
^ permalink raw reply
* Re: [PATCH, resent] fix openssl headers conflicting with custom SHA1 implementations
From: Shawn O. Pearce @ 2008-10-01 16:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0810011222090.3635@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Wed, 1 Oct 2008, Shawn O. Pearce wrote:
> > Jeff King <peff@peff.net> wrote:
> > > On Wed, Oct 01, 2008 at 08:54:58AM -0700, Shawn O. Pearce wrote:
> > >
> > > > I think its easy enough to just rename our SHA_CTX and SHA_*
> > > > functions to something more git specific. Since its mostly a global
> > >
> > > I think that is the cleanest and simplest solution. As for merging pain,
> > > I think Junio would generally do a mechanical change like this as the
> > > first thing after a release. However, in this case, I think we might
> > > want it sooner if the conflict is causing breakage.
> >
> > Oh, yea, that's probably true. But with ARM broken according to
> > Nico I'd almost just want this fixed in the upcoming 1.6.1 release.
>
> > Its simple enough to do. We can even do something like this during
> > the transition period until right before the 1.6.1 final:
>
> Because it's easy to do then I'd do it sooner than later.
Nico, are you going to write a patch for this? If not I'll do it
myself later today or tomorrow morning. I don't mind doing it,
I just don't want to duplicate work with you. I've got too much
else going on to waste my time that way.
Of course I'm wasting time on this email... ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH, resent] fix openssl headers conflicting with custom SHA1 implementations
From: Nicolas Pitre @ 2008-10-01 16:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, git
In-Reply-To: <20081001161047.GG21310@spearce.org>
On Wed, 1 Oct 2008, Shawn O. Pearce wrote:
> Jeff King <peff@peff.net> wrote:
> > On Wed, Oct 01, 2008 at 08:54:58AM -0700, Shawn O. Pearce wrote:
> >
> > > I think its easy enough to just rename our SHA_CTX and SHA_*
> > > functions to something more git specific. Since its mostly a global
> >
> > I think that is the cleanest and simplest solution. As for merging pain,
> > I think Junio would generally do a mechanical change like this as the
> > first thing after a release. However, in this case, I think we might
> > want it sooner if the conflict is causing breakage.
>
> Oh, yea, that's probably true. But with ARM broken according to
> Nico I'd almost just want this fixed in the upcoming 1.6.1 release.
Not only ARM, but PPC as well, and any configuration using the Mozilla
SHA1 implementation and linking openssl (although I don't know why one
would want that in the later case).
> Its simple enough to do. We can even do something like this during
> the transition period until right before the 1.6.1 final:
Because it's easy to do then I'd do it sooner than later. Right now the
master branch is broken for ARM and PPC which is not nice. And I don't
think there is much work to be merged which would conflict with such a
change.
Nicolas
^ permalink raw reply
* Re: [PATCH v2] git grep: Add "-z/--null" option as in GNU's grep.
From: Shawn O. Pearce @ 2008-10-01 16:17 UTC (permalink / raw)
To: Raphael Zimmerer; +Cc: git, Johannes.Schindelin, madcoder
In-Reply-To: <1222877475-2699-1-git-send-email-killekulla@rdrz.de>
Raphael Zimmerer <killekulla@rdrz.de> wrote:
> diff --git a/builtin-grep.c b/builtin-grep.c
> index 3a51662..2241324 100644
> --- a/builtin-grep.c
> +++ b/builtin-grep.c
> @@ -295,6 +295,9 @@ static int external_grep(struct grep_opt *opt, const char **paths, int cached)
> push_arg("-l");
> if (opt->unmatch_name_only)
> push_arg("-L");
> + if (opt->null_following_name)
> + // in GNU grep git's "-z" translates to "-Z"
> + push_arg("-Z");
We use /* */ style comments in Git. I've amended the patch with
the simple // -> /* */ translation.
The rest of this change looks good to me. Its queued for next.
--
Shawn.
^ permalink raw reply
* [PATCH v2] git grep: Add "-z/--null" option as in GNU's grep.
From: Raphael Zimmerer @ 2008-10-01 16:11 UTC (permalink / raw)
To: spearce; +Cc: git, Johannes.Schindelin, madcoder
In-Reply-To: <1222816390-9141-1-git-send-email-killekulla@rdrz.de>
Here's a trivial patch that adds "-z" and "--null" options to "git
grep". It was discussed on the mailing-list that git's "-z"
convention should be used instead of GNU grep's "-Z".
So things like 'git grep -l -z "$FOO" | xargs -0 sed -i "s/$FOO/$BOO/"'
do work now.
Signed-off-by: Raphael Zimmerer <killekulla@rdrz.de>
---
Changes from first patch:
* "-Z" -> "-z"
* use '\0' instead of 0
Regards
Raphael
Documentation/git-grep.txt | 6 ++++++
builtin-grep.c | 8 ++++++++
grep.c | 14 +++++++++++---
grep.h | 1 +
4 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index fa4d133..553da6c 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -15,6 +15,7 @@ SYNOPSIS
[-E | --extended-regexp] [-G | --basic-regexp]
[-F | --fixed-strings] [-n]
[-l | --files-with-matches] [-L | --files-without-match]
+ [-z | --null]
[-c | --count] [--all-match]
[-A <post-context>] [-B <pre-context>] [-C <context>]
[-f <file>] [-e] <pattern>
@@ -94,6 +95,11 @@ OPTIONS
For better compatibility with 'git-diff', --name-only is a
synonym for --files-with-matches.
+-z::
+--null::
+ Output \0 instead of the character that normally follows a
+ file name.
+
-c::
--count::
Instead of showing every matched line, show the number of
diff --git a/builtin-grep.c b/builtin-grep.c
index 3a51662..2241324 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -295,6 +295,9 @@ static int external_grep(struct grep_opt *opt, const char **paths, int cached)
push_arg("-l");
if (opt->unmatch_name_only)
push_arg("-L");
+ if (opt->null_following_name)
+ // in GNU grep git's "-z" translates to "-Z"
+ push_arg("-Z");
if (opt->count)
push_arg("-c");
if (opt->post_context || opt->pre_context) {
@@ -599,6 +602,11 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
opt.unmatch_name_only = 1;
continue;
}
+ if (!strcmp("-z", arg) ||
+ !strcmp("--null", arg)) {
+ opt.null_following_name = 1;
+ continue;
+ }
if (!strcmp("-c", arg) ||
!strcmp("--count", arg)) {
opt.count = 1;
diff --git a/grep.c b/grep.c
index 7063511..e2c190a 100644
--- a/grep.c
+++ b/grep.c
@@ -239,6 +239,8 @@ static int word_char(char ch)
static void show_line(struct grep_opt *opt, const char *bol, const char *eol,
const char *name, unsigned lno, char sign)
{
+ if (opt->null_following_name)
+ sign = '\0';
if (opt->pathname)
printf("%s%c", name, sign);
if (opt->linenum)
@@ -246,6 +248,11 @@ static void show_line(struct grep_opt *opt, const char *bol, const char *eol,
printf("%.*s\n", (int)(eol-bol), bol);
}
+static void show_name(struct grep_opt *opt, const char *name)
+{
+ printf("%s%c", name, opt->null_following_name ? '\0' : '\n');
+}
+
static int fixmatch(const char *pattern, char *line, regmatch_t *match)
{
char *hit = strstr(line, pattern);
@@ -489,7 +496,7 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
return 1;
}
if (opt->name_only) {
- printf("%s\n", name);
+ show_name(opt, name);
return 1;
}
/* Hit at this line. If we haven't shown the
@@ -555,7 +562,7 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
return 0;
if (opt->unmatch_name_only) {
/* We did not see any hit, so we want to show this */
- printf("%s\n", name);
+ show_name(opt, name);
return 1;
}
@@ -565,7 +572,8 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
* make it another option? For now suppress them.
*/
if (opt->count && count)
- printf("%s:%u\n", name, count);
+ printf("%s%c%u\n", name,
+ opt->null_following_name ? '\0' : ':', count);
return !!last_hit;
}
diff --git a/grep.h b/grep.h
index 59b3f87..45a222d 100644
--- a/grep.h
+++ b/grep.h
@@ -74,6 +74,7 @@ struct grep_opt {
unsigned extended:1;
unsigned relative:1;
unsigned pathname:1;
+ unsigned null_following_name:1;
int regflags;
unsigned pre_context;
unsigned post_context;
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH, resent] fix openssl headers conflicting with custom SHA1 implementations
From: Shawn O. Pearce @ 2008-10-01 16:10 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, git
In-Reply-To: <20081001160418.GA13917@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Wed, Oct 01, 2008 at 08:54:58AM -0700, Shawn O. Pearce wrote:
>
> > I think its easy enough to just rename our SHA_CTX and SHA_*
> > functions to something more git specific. Since its mostly a global
>
> I think that is the cleanest and simplest solution. As for merging pain,
> I think Junio would generally do a mechanical change like this as the
> first thing after a release. However, in this case, I think we might
> want it sooner if the conflict is causing breakage.
Oh, yea, that's probably true. But with ARM broken according to
Nico I'd almost just want this fixed in the upcoming 1.6.1 release.
Its simple enough to do. We can even do something like this during
the transition period until right before the 1.6.1 final:
diff --git a/cache.h b/cache.h
index 46f82bd..e77adf9 100644
--- a/cache.h
+++ b/cache.h
@@ -5,6 +5,10 @@
#include "strbuf.h"
#include "hash.h"
+#define SHA_CTX not_the_SHA_CTX_you_are_looking_for
+#define SHA1_Init not_the_SHA1_Init_you_are_looking_for
+#define SHA1_Update not_the_SHA1_Update_you_are_looking_for
+#define SHA1_Final not_the_SHA1_Final_you_are_looking_for
#include SHA1_HEADER
#include <zlib.h>
and we'll catch anything using the old symbol name. Only cache.h
includes the SHA1_HEADER so anyone using the (old) SHA_* functions
would hit these #defines and fall over the undefined symbol.
--
Shawn.
^ permalink raw reply related
* Re: [PATCH, resent] fix openssl headers conflicting with custom SHA1 implementations
From: Jeff King @ 2008-10-01 16:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, git
In-Reply-To: <20081001155458.GF21310@spearce.org>
On Wed, Oct 01, 2008 at 08:54:58AM -0700, Shawn O. Pearce wrote:
> > void ARM_SHA1_Init()
> >
> > and
> >
> > #define SHA1_Init ARM_SHA1_Init
>
> Ick. I agree that renaming our SHA1 implementation to a different
> set of symbols is the right solution. But this could cause trouble
> in any code that needs both SHA1 implementation and OpenSSL,
> especially if a SHA_CTX was passed to a function in another module.
Yes. You're never going to be able to get access to _both_
implementations if they have the same name. ;)
> I think its easy enough to just rename our SHA_CTX and SHA_*
> functions to something more git specific. Since its mostly a global
I think that is the cleanest and simplest solution. As for merging pain,
I think Junio would generally do a mechanical change like this as the
first thing after a release. However, in this case, I think we might
want it sooner if the conflict is causing breakage.
-Peff
^ permalink raw reply
* Re: [PATCH, resent] fix openssl headers conflicting with custom SHA1 implementations
From: Shawn O. Pearce @ 2008-10-01 15:54 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, git
In-Reply-To: <20081001034712.GE24513@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Tue, Sep 30, 2008 at 01:51:22PM -0700, Shawn O. Pearce wrote:
>
> > Yea, its a bit ugly due to the rats nest of system includes.
> > Right now I don't see how we can include your patch, it breaks a
> > major platform for us. But obviously my "fix" is also bogus and
> > won't get ARM working again.
> >
> > Any other ideas we can try? 'cause I don't have any right now. :-|
>
> I think you have an inherent conflict. Using openssl is going to end up
> including their SHA definition, and we clearly can't include both..
...
> So I think the right way is probably to use a level of indirection. Turn
> the ARM implementation into
>
> void ARM_SHA1_Init()
>
> and
>
> #define SHA1_Init ARM_SHA1_Init
Ick. I agree that renaming our SHA1 implementation to a different
set of symbols is the right solution. But this could cause trouble
in any code that needs both SHA1 implementation and OpenSSL,
especially if a SHA_CTX was passed to a function in another module.
> You can make it even simpler by just having all code call git_SHA1_Init,
> and that will expand to whichever implementation has been chosen.
$ git grep --cached SHA1_Init | wc -l
32
$ git grep --cached SHA1_Final | wc -l
26
$ git grep --cached SHA1_Update | wc -l
39
$ git grep --cached SHA_CTX | wc -l
48
I think its easy enough to just rename our SHA_CTX and SHA_*
functions to something more git specific. Since its mostly a global
s/// we should be able to run it through into master without too
much effort. It would however make merging certain changes from
maint fun, but I think we can handle it until the 1.6.1 release
goes final. We tend not to twiddle SHA1 related code in maint.
Of course this is me speaking... Junio is the one that would be faced
with the brunt of that pain. If it comes down to it I'd be willing
to handle the maint branch and its merges back into master for him.
A funny thing from the above stats... we have 6 SHA1_Init calls
which aren't balanced by a SHA1_Final call. Weird.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Shawn O. Pearce @ 2008-10-01 15:44 UTC (permalink / raw)
To: Jeff King
Cc: Andreas Ericsson, Wincent Colaiuta, Pieter de Bie, Junio C Hamano,
Git Mailinglist
In-Reply-To: <20081001154205.GD4962@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Wed, Oct 01, 2008 at 08:36:37AM -0700, Shawn O. Pearce wrote:
>
> > *sigh* And I just took up the #@*#@!&!*!@ paintbrush myself.
> > Dammit. I'm putting it down now. Really. :-)
>
> Heh. I don't want to stir up trouble or drag you into a discussion you
> don't want to be in. But it seems like you are saying "OK, this is
> silly, let's just go with what is in next." But I think Andreas raised a
> good point about "stuff the user should check should go on the left"
> which is not consistent with what is in next. So I just want to confirm
> that you either disagree with that, or simply think it is not important
> enough to keep the discussion going.
I agree with "important stuff on the left". So as much as I'd like
to just move on, I guess I'm willing to look at a 3rd patch that
moves the branch name onto the left side.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Jeff King @ 2008-10-01 15:42 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Andreas Ericsson, Wincent Colaiuta, Pieter de Bie, Junio C Hamano,
Git Mailinglist
In-Reply-To: <20081001153637.GC21310@spearce.org>
On Wed, Oct 01, 2008 at 08:36:37AM -0700, Shawn O. Pearce wrote:
> I briefly considered a format like this while replying above, but
> at prior day-job I used rather long branch names (sometimes with
> common prefixes) so it would truncate alot:
>
> normal case
> On i386 abc9056 (i386: Snib the sprock)
I don't like this purely for the reason that it wastes horizontal space,
which is one of the problems that started this discussion.
Also, there is no verb, which I think is worse. :)
> *sigh* And I just took up the #@*#@!&!*!@ paintbrush myself.
> Dammit. I'm putting it down now. Really. :-)
Heh. I don't want to stir up trouble or drag you into a discussion you
don't want to be in. But it seems like you are saying "OK, this is
silly, let's just go with what is in next." But I think Andreas raised a
good point about "stuff the user should check should go on the left"
which is not consistent with what is in next. So I just want to confirm
that you either disagree with that, or simply think it is not important
enough to keep the discussion going.
-Peff
^ permalink raw reply
* Re: obscure platform autobuilders
From: Jeff King @ 2008-10-01 15:37 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git
In-Reply-To: <e2b179460810010346j23617764i8134c1f24b2746f0@mail.gmail.com>
On Wed, Oct 01, 2008 at 11:46:43AM +0100, Mike Ralphson wrote:
> My googling led me to think that INTERNAL_QSORT would be a good idea
> on at least some versions of Solaris... it may depend on the fs
> though.
I thought it was purely a performance enhancement. Should it affect the
test results?
> How about this - let me know if ok, and I'll push it.
It mostly looks good, though I would have split it into several distinct
commits for readability. A few comments below.
> - - 'branches', a list of branches, one per line, to build and test
> + - 'branches', a list of branches, one per line, to build and test.
> + Lines starting with # are treated as comments
Makes sense.
> - 'config.mak'; if this file exists, it will be used as the config.mak
> - file for building git
> + file for building git. If it is not present, but there is a
> + config.mak file in your project directory, it is copied here to
> + prevent it being removed by 'git clean'
I'm not sure I agree with this. My goal was to treat the project
directory as nothing more than a cache, with the gitbuild repo as the
master source driving the tests. So this works backwards to that.
One of the things I was (and am) considering is rather than doing
checkout/clean, to simply export each branch to a new directory and
build from there. Then the "project" repo could actually be bare.
How is this feature intended to be used? It looks like it would
basically be invoked one time, when running this script on an existing
gitbuild setup. So it saves one manual step of copying your config.mak
to the platform directory. But you still have to manually inspect, add,
and commit that config.mak file.
> + - 'catch', a shell script sourced by the build script if an error
> + occurs. It is passed the failing command-line in its arguments
> +
> + - 'finally', a shell script sourced by the build script at the end
> + of the process. It is passed the exit code of build.sh as its
> + argument
These look like sensible hooks.
> + - project; the path to the directory to build in. If not set, defaults
> + to ./project relative to the starting directory
> +
I am accomplishing the same thing with a symlink, but I think this is
probably cleaner.
> +if ! test -d $project; then
> + try mkdir $project
> + try cd $project
Quotes around $project? I'm not sure how robust the rest of the script
is to paths with spaces (which I personally consider insane).
> - for i in `cat "$root/branches"`; do
> + for i in `cat "$root/branches" | grep -v '^#'`; do
Useless use of cat. :)
grep -v ^# < "$root/branches"
-Peff
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Shawn O. Pearce @ 2008-10-01 15:36 UTC (permalink / raw)
To: Jeff King
Cc: Andreas Ericsson, Wincent Colaiuta, Pieter de Bie, Junio C Hamano,
Git Mailinglist
In-Reply-To: <20081001152546.GB4962@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Wed, Oct 01, 2008 at 08:10:11AM -0700, Shawn O. Pearce wrote:
>
> > Actually I rather like the patch you submitted yesterday:
> >
> > normal case
> > Created abc9056 (i386: Snib the sprock) on i386
> >
> > detached head
> > Created DETACHED commit abc9056 (i386: Snib the sprock)
> >
> > initial commit
> > Created root-commit abc9056 (i386: Snib the sprock) on i386
> >
> > The detached HEAD and root-commit cases are clearly denoted at the
> > very start of the line, where your eyes are likely to start scanning
>
> I agree with your assumption that people scan the line from left to
> right, and that the most important stuff should come first. So that
> format covers _those_ cases, but not the case of "oops, I committed on
> a different branch than I intended." So I think it really makes sense
> to keep the branch name on the left side, and the commit subject last.
I briefly considered a format like this while replying above, but
at prior day-job I used rather long branch names (sometimes with
common prefixes) so it would truncate alot:
normal case
On i386 abc9056 (i386: Snib the sprock)
detached head
On DETACHED HEAD abc9056 (i386: Snib the sprock)
initial commit
On i386
Root commit abc9056 (i386: Snib the sprock)
With the branch name field set at about 15 characters and truncated.
The initial commit case is very infrequent so burning two lines
for it to help make it stand out *and* make the branch name clear
isn't really a problem.
> > Right now I'm happy with your patch in next. I don't like taking
> > the paint brush away from folks, but I also don't want to be applying
> > a ton of commit message reformatting patches over the next week. ;-)
>
> Welcome to maintainership. ;P
*sigh* And I just took up the #@*#@!&!*!@ paintbrush myself.
Dammit. I'm putting it down now. Really. :-)
--
Shawn.
^ permalink raw reply
* Re: interactive rebase not rebasing
From: Andreas Ericsson @ 2008-10-01 15:26 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <20081001095225.d28de16a.stephen@exigencecorp.com>
Stephen Haberman wrote:
>
> But given /this/ scenario (hehe), with the implementation's existing
> explicit usage of "--left-right --cherry-pick" to drop no-op commits,
> but then it's forgetting of this information later, leading to `git
> rebase` not performing a rebase at all, I think it is an obvious bug,
> and one that can be fixed without changing any of `git rebase`s
> existing semantics.
>
Agreed.
>> Merely that you should think hard about it and then make sure it
>> doesn't break anything people are already doing today with the current
>> toolset.
>
> I've attempted to do that. Now that I sent in the patch, if you could
> review it, I would appreciate your feedback.
I'm heading home from work now. I'll look it over tonight or tomorrow
morning. Thanks for the confidence :-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Jeff King @ 2008-10-01 15:25 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Andreas Ericsson, Wincent Colaiuta, Pieter de Bie, Junio C Hamano,
Git Mailinglist
In-Reply-To: <20081001151011.GA21310@spearce.org>
On Wed, Oct 01, 2008 at 08:10:11AM -0700, Shawn O. Pearce wrote:
> Actually I rather like the patch you submitted yesterday:
>
> normal case
> Created abc9056 (i386: Snib the sprock) on i386
>
> detached head
> Created DETACHED commit abc9056 (i386: Snib the sprock)
>
> initial commit
> Created root-commit abc9056 (i386: Snib the sprock) on i386
>
> The detached HEAD and root-commit cases are clearly denoted at the
> very start of the line, where your eyes are likely to start scanning
> from first before you say "Doh, its just line noise because Git wants
> a pat on the back for doing what I asked". Thus you are likely
> to notice something out of the ordinary (commit on detached HEAD)
> pretty quick.
I agree with your assumption that people scan the line from left to
right, and that the most important stuff should come first. So that
format covers _those_ cases, but not the case of "oops, I committed on
a different branch than I intended." So I think it really makes sense
to keep the branch name on the left side, and the commit subject last.
> Right now I'm happy with your patch in next. I don't like taking
> the paint brush away from folks, but I also don't want to be applying
> a ton of commit message reformatting patches over the next week. ;-)
Welcome to maintainership. ;P
-Peff
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Andreas Ericsson @ 2008-10-01 15:22 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Jeff King, Wincent Colaiuta, Pieter de Bie, Junio C Hamano,
Git Mailinglist
In-Reply-To: <20081001151011.GA21310@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Jeff King wrote:
>>> On Tue, Sep 30, 2008 at 11:59:25AM +0200, Andreas Ericsson wrote:
>>>> Another way would be to write
>>>> <branch>: Created <hash>: "subject line..."
>>> I think I like this even better.
>> Me too, but I thought it up after I sent out the first patch. The nicest
>> part is that the info that's always present will always end up in the
>> same place, while my patch moves the branch-name around depending on
>> the length of the subject line.
>>
>> Let's agree here and now that the subject should be last and that "commit "
>> should be dropped, at least for the normal cases.
>
> Actually I rather like the patch you submitted yesterday:
>
> normal case
> Created abc9056 (i386: Snib the sprock) on i386
>
> detached head
> Created DETACHED commit abc9056 (i386: Snib the sprock)
>
> initial commit
> Created root-commit abc9056 (i386: Snib the sprock) on i386
>
> The detached HEAD and root-commit cases are clearly denoted at the
> very start of the line, where your eyes are likely to start scanning
> from first before you say "Doh, its just line noise because Git wants
> a pat on the back for doing what I asked". Thus you are likely
> to notice something out of the ordinary (commit on detached HEAD)
> pretty quick.
>
> The "<branch>: Created <hash>: subject" format described above
> has the problem that a lot of errors look like "error: foo: bar"
> and the human eye is probably trained to glance over it. IMHO its
> formatted too much like an error message line.
>
>>> My only concern is that many programs
>>> say "program: some error", so you could potentially have a confusing
>>> branch name. But I personally have never used a branch name that would
>>> cause such confusion.
>> A valid concern, certainly. We needn't use colons for the branch-name
>> though, but could instead use some other delimiter, like this:
>> [<branch>] Created <hash>: "subject line..."
>> although I do believe we're close to nitpicking this issue to death
>> now. It's not *that* important after all.
>
> Yup, its a bikeshed.
>
> Right now I'm happy with your patch in next. I don't like taking
> the paint brush away from folks, but I also don't want to be applying
> a ton of commit message reformatting patches over the next week. ;-)
>
Thanks for putting your foot down. Having thought more about it, I
was quite disgusted to realize I spent brain-time on something so
unimportant.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Jeff King @ 2008-10-01 15:18 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Wincent Colaiuta, Pieter de Bie, Junio C Hamano, Git Mailinglist
In-Reply-To: <48E3312E.4090601@op5.se>
On Wed, Oct 01, 2008 at 10:13:34AM +0200, Andreas Ericsson wrote:
> Me too, but I thought it up after I sent out the first patch. The nicest
> part is that the info that's always present will always end up in the
> same place, while my patch moves the branch-name around depending on
> the length of the subject line.
>
> Let's agree here and now that the subject should be last and that "commit "
> should be dropped, at least for the normal cases.
Yes, I agree that those are the most important aspects, and the rest of
it is just minor formatting details.
> A valid concern, certainly. We needn't use colons for the branch-name
> though, but could instead use some other delimiter, like this:
> [<branch>] Created <hash>: "subject line..."
> although I do believe we're close to nitpicking this issue to death
> now. It's not *that* important after all.
Heh. Yes, I feel a little silly discussing this so much. But it probably
is _the_ most frequently seen informational message in git. So not only
does it affect new users' perception of git, but I have to see it every
day. ;)
> I don't quite like the fact that you're removing the "detached" thingie.
> I have coworkers that have been bitten by committing on detached head,
> so I'd like to have some mention of it. I'll rework it to take that
> into account. Otherwise, this looks good. Less code is always a good
> thing, imo.
I thought the all-caps "HEAD" instead of the branch name would make it
stand out. But given that it isn't the common case, I don't think it is
the end of the world to spend a little more screen real estate
mentioning it.
I am ready to bikeshed the next patch you produce. ;)
-Peff
^ permalink raw reply
* Re: [TG PATCH] README: Fix spelling and reflect recent depend support
From: Jonas Fonseca @ 2008-10-01 15:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <1222870059-22077-1-git-send-email-fonseca@diku.dk>
On Wed, Oct 1, 2008 at 16:07, Jonas Fonseca <fonseca@diku.dk> wrote:
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
> ---
I have been trying to get `tg mail` to work and have a few questions.
Would you mind if topgit didn't insert an empty line after the sob
line? Most emails to this list doesn't have it. The patch mail I just
sent had two 'To:' lines: one probably comes from topgit passing
git-send-email the --to option and the other comes from the patch file
(basically .topmsg) containing a 'To:' line. Should `tg mail` be fixed
to filter this somehow? Finally, tg-mail uses bash arrays, however,
perhaps topgit could get away with just passing one --from and one
--to option to git-send-email.
> diff --git a/README b/README
> index 35a9f98..903face 100644
> --- a/README
> +++ b/README
> @@ -252,6 +252,7 @@ tg delete
> depending on it.
>
> TODO: '-a' to delete all empty branches, depfix, revert
> + TODO: subcommand removing dependencies smoothly
>
> tg depend
> ~~~~~~~~~
Gah, this is obviously in the wrong subsection ...
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] git grep: Add "-Z/--null" option as in GNU's grep.
From: Raphael Zimmerer @ 2008-10-01 15:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <20081001145207.GW21310@spearce.org>
On Wed, Oct 01, 2008 at 07:52:07AM -0700, Shawn O. Pearce wrote:
> Its not like tools outside of Git are all that consistent. GNU
> grep uses --null/-Z. xargs and perl use -0. find uses -print0.
> The human at the keyboard already has to navigate this rats nest
> between different tools, but within a tool (git) we should be as
> consistent as we can.
... and git-config uses --null/-z.
I will send an updated patch with --null/-z.
- Raphael
^ 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