* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-25 9:35 UTC (permalink / raw)
To: Matthew D. Fuller
Cc: Carl Worth, Aaron Bentley, Linus Torvalds, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <20061021130111.GL75501@over-yonder.net>
Matthew D. Fuller wrote:
> On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of
> Carl Worth, and lo! it spake thus:
>
>> (since pull seems the only way to synch up without infinite new
>> merge commits being added back and forth).
>
> The infinite-merge-commits case doesn't happen in bzr-land because we
> generally don't merge other branches except when the branch owner says
> "Hey, I've got something for you to merge". If you were to setup a
> script to merge two branches back and forth until they were 'equal',
> yes, it'd churn away until you filled up your disk with the N bytes of
> metadata every new revision uses up.
>
This is new to me. At work, we merge our toy repositories back and forth
between devs only. There is no central repo at all. Does this mean that
each merge would add one extra commit per time the one I'm merging with
has merged with me?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-25 9:46 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Matthew D. Fuller, Carl Worth, Aaron Bentley, Linus Torvalds,
bazaar-ng, git
In-Reply-To: <453F2FF8.2080903@op5.se>
Andreas Ericsson wrote:
> Matthew D. Fuller wrote:
>> On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of
>> Carl Worth, and lo! it spake thus:
>>
>>> (since pull seems the only way to synch up without infinite new
>>> merge commits being added back and forth).
>>
>> The infinite-merge-commits case doesn't happen in bzr-land because we
>> generally don't merge other branches except when the branch owner says
>> "Hey, I've got something for you to merge". If you were to setup a
>> script to merge two branches back and forth until they were 'equal',
>> yes, it'd churn away until you filled up your disk with the N bytes of
>> metadata every new revision uses up.
>
> This is new to me. At work, we merge our toy repositories back and forth
> between devs only. There is no central repo at all. Does this mean that
> each merge would add one extra commit per time the one I'm merging with
> has merged with me?
From what I understand, "bzr merge" will create one extra commit to
preserve the "first parent is my branch" feature. "bzr pull" will do
fast-forward if your DAG is proper subset of pulled branch/repository
DAG, but at the cost that it would change your revno to revision mapping
to those of the pulled repository.
That's a consequence of preserving branch as "my work" i.e. as path
through "branch DAG" in the DAG using first parent as special, instead
of saving it outside DAG.
--
Jakub Narebski
^ permalink raw reply
* Re: VCS comparison table
From: Jeff King @ 2006-10-25 9:49 UTC (permalink / raw)
To: David Rientjes; +Cc: Linus Torvalds, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64N.0610250157470.3467@attu1.cs.washington.edu>
On Wed, Oct 25, 2006 at 02:19:15AM -0700, David Rientjes wrote:
> No, my criticism is against the added complexity which makes the
> modification of git increasingly difficult with every new release. It's a
OK, you seemed to imply problems for end users in your first paragraph,
which is what I was responding to.
> _current_ needs. For any experienced shell programmer it is so much
> easier to go in and change an option or pipe to a different command or
> comment out a simple shell command in a .sh file than editing the C code.
Yes, it's true that some operations might be easier to play with in the
shell. However, does it actually come up that you want to modify
existing git programs? The more common usage seems to be gluing the
plumbing together in interesting ways, and that is still very much
supported.
> And sometimes it's necessary to have several different variations of that
> command which is very easy with slightly renamed .sh files instead of
> adding on more and more flags to commands that have become so complex at
> this point that it's difficult to know the basics of how to manage a
> project.
You can do the same thing in C. In fact, look at how similar
git-whatchanged, git-log, and git-diff are.
I don't understand how a C->shell conversion has anything to do with
options being added. If you look at all of the conversions, they
replicate the interface _exactly_.
> This all became very obvious when the tutorials came out on "how to use
> git in 20 commands or less" effectively. These tutorials shouldn't need
> to exist with an information manager that started as a quick, efficient,
> and _simple_ project. You're treating git development in the same light
Sorry, I don't see how this is related to the programming language _at
all_. Are you arguing that the interface of git should be simplified so
that such tutorials aren't necessary? If so, then please elaborate, as
I'm sure many here would like to hear proposals for improvements. If
you're arguing that git now has too many features, then which features
do you consider extraneous?
> as you treat Linux development; let's be honest and say that 99% of the
> necessary git functionality was there almost a year ago and ever since
> nothing of absolute necessity has been added that serious developers care
> about in a revision control system. Look at LKML, nobody is waiting on
I don't agree with this. There are tons of enhancements that I find
useful (e.g., '...' rev syntax, rebasing with 3-way merge, etc) that I
think other developers ARE using. There are scalability and performance
improvements. And there are new things on the way (Junio's pickaxe work)
that will hopefully make git even more useful than it already is.
If you don't think recent git versions are worthwhile, then why don't
you run an old version? You can even use git to cherry-pick patches onto
your personal branch.
> Absolutely. I think I've actually documented that fairly well. Back in
Where?
> the day git was a very concise, well-written package. Today, a tour
> through the source code for the latest release leaves a lot to be desired
> for any serious C programmer.
I don't agree, but since you haven't provided anything specific enough
to discuss, there's not much to say.
> Functionality wise, no. But in terms of being able to _customize_ my
> version of git depending on how I want to use it, I've lost hope on the
> whole idea. It's a shame too because it appears as though the original
Can you name one customization that you would like to perform now that
you feel can't be easily done (and presumably that would have been
easier in the past)?
-Peff
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-25 9:52 UTC (permalink / raw)
To: Carl Worth; +Cc: Jeff Licquia, Jakub Narebski, bazaar-ng, git
In-Reply-To: <8764ed1b7z.wl%cworth@cworth.org>
Carl Worth wrote:
> On Sat, 21 Oct 2006 19:42:47 -0400, Jeff Licquia wrote:
>> I don't think so. Recently, I've been trying to track a particular
>> patch in the kernel. It was done as a series of commits, and probably
>> would have been its own branch in bzr, but when I was trying to group
>> the commits together to analyze them as a group, the easiest way to do
>> that was by the original committer's name.
>
> As far as "its own branch in bzr" would such a branch remain available
> indefinitely even after being merged in to the main tree?
>
>> Now, there's probably a better way to hunt that stuff down, but in this
>> case hunting the user down worked for me. (It may have made a
>> difference that I was using gitweb instead of a local clone.)
>
> Vast, huge, gaping, cosmic difference.
>
> Almost none of the power of git is exposed by gitweb. It's really not
> worth comparing. (Now a gitweb-alike that provided all the kinds of
> very easy browsing and filtering of the history like gitk and git
> might be nice to have.)
>
There was one, but it got discontinued due to performance issues. Shame
that, because it would have been nice to have to show "foreign" visitors
how gitk/qgit works. It would especially show the way git thinks about
branches and stuff like that.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: VCS comparison table
From: Matthieu Moy @ 2006-10-25 9:57 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Matthew D. Fuller, Carl Worth, Aaron Bentley, Linus Torvalds,
bazaar-ng, git, Jakub Narebski
In-Reply-To: <453F2FF8.2080903@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> This is new to me. At work, we merge our toy repositories back and
> forth between devs only. There is no central repo at all. Does this
> mean that each merge would add one extra commit per time the one I'm
> merging with has merged with me?
Two things differ in bzr and git, here:
* bzr doesn't do "autocommit" after a merge. So, new revisions are
created only if you use"commit".
* bzr has two commands, "pull" and "merge". "pull" just does what the
git people call "fast-forward", and only this (it refuses to do
anything if the branches diverged). In particular, you never have to
commit after a pull (well, except if you had some local, uncommited
changes). "merge" changes your working directory, and you have to
commit after. "merge" will never do fast-forward, it will never
change the revision to which your working tree revfers to, and it's
your option to commit or not after (if you see that it introduces no
changes, you might not want to commit).
The final rule in bzr would be "you create an extra commit each time
you commit" ;-).
As a side-note, it could be interesting to have a git-like merge
command (chosing automatically between merge and pull), probably not
in the core, but as a plugin.
--
^ permalink raw reply
* [PATCH] git-fetch.sh printed protocol fix
From: Tuncer Ayaz @ 2006-10-25 10:03 UTC (permalink / raw)
To: git
As a feature I wished for (ftp:// support in git-fetch) was added in 1.4.3
I tested that feature and found a minor logging issue. The mini-patch
below fixes that. AFAIK the pattern expansion feature I've used should
be available in any current /bin/sh. If not we will have to find another
way to print the protocol part of the used fetch URL.
--- git-core-1.4.3.2/git-fetch.sh 2006-10-24 07:29:47.000000000 +0200
+++ git-core-1.4.3.2.tma/git-fetch.sh 2006-10-25 11:44:34.000000000 +0200
@@ -310,7 +310,7 @@
done
expr "z$head" : "z$_x40\$" >/dev/null ||
die "Failed to fetch $remote_name from $remote"
- echo >&2 Fetching "$remote_name from $remote" using http
+ echo >&2 Fetching "$remote_name from $remote" using ${remote%%:*}
git-http-fetch -v -a "$head" "$remote/" || exit
;;
^ permalink raw reply
* Re: VCS comparison table
From: James Henstridge @ 2006-10-25 10:08 UTC (permalink / raw)
To: Jakub Narebski
Cc: bazaar-ng, Matthew D. Fuller, Linus Torvalds, Carl Worth,
Andreas Ericsson, git
In-Reply-To: <200610251146.06116.jnareb@gmail.com>
On 25/10/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Andreas Ericsson wrote:
> > This is new to me. At work, we merge our toy repositories back and forth
> > between devs only. There is no central repo at all. Does this mean that
> > each merge would add one extra commit per time the one I'm merging with
> > has merged with me?
>
> From what I understand, "bzr merge" will create one extra commit to
> preserve the "first parent is my branch" feature. "bzr pull" will do
> fast-forward if your DAG is proper subset of pulled branch/repository
> DAG, but at the cost that it would change your revno to revision mapping
> to those of the pulled repository.
Actually, "bzr merge" does not create any commits on the branch -- you
need to run "bzr commit" afterwards (possibly after resolving
conflicts). The control files for the working tree record a pending
merge, which gets recorded when you get round to the commit.
So you can easily check if there were any tree changes resulting from the merge.
If there aren't, or you made the merge by mistake, you can make a call
to "bzr revert" to clean things up without ever having created a new
revision.
James.
^ permalink raw reply
* [PATCH] document the <tree ish> <file> blob reference syntax
From: Andy Whitcroft @ 2006-10-25 10:42 UTC (permalink / raw)
To: git
It is possible to specify a specific file within a tree-ish
symbolically. For example you can find the contents of
a specific file in a specific commit as below:
git cat-file -p v1.2.4:git-prune.sh
Document this syntax in the Symbolic Identifiers section
of the main git documentation and reference it from
git-cat-file's documentation.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index 5e9cbf8..9f2138d 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-file.txt
@@ -19,7 +19,9 @@ or '-s' is used to find the object size.
OPTIONS
-------
<object>::
- The sha1 identifier of the object.
+ The sha1 identifier of the object or a symbolic object
+ reference. See the Symbolic Identifiers section of the
+ main git manual page.
-t::
Instead of the content, show the object type identified by
@@ -58,6 +60,18 @@ Otherwise the raw (though uncompressed)
be returned.
+EXAMPLES
+--------
+git cat-file -p c5a5d29aaacf753b70e715169cbb7f74f0193e4a::
+ Pretty print the object directly using an sha1, perhaps
+ from a git ls-tree output.
+
+git cat-file -p v1.2.4:git-prune.sh::
+ Output the file git-prune.sh from the branch or tag v1.2.4.
+ Note that where the name is ambigious a heads/ or tags/
+ prefix may be used to disambiguate the name.
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 7074e32..e9f99e2 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -565,6 +565,13 @@ HEAD::
a valid head 'name'
(i.e. the contents of `$GIT_DIR/refs/heads/<head>`).
+Some commands will also accept the following extended syntax:
+
+<tree-ish>:<file>::
+ indicating a specific blob for that file within the tree
+ object specified, which may also be symbolic. For example
+ 'v1.2.4:git-prune.sh'.
+
File/Directory Structure
^ permalink raw reply related
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-25 10:52 UTC (permalink / raw)
To: Matthew D. Fuller; +Cc: Linus Torvalds, bazaar-ng, git
In-Reply-To: <20061023222131.GB17019@over-yonder.net>
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
Matthew D. Fuller wrote:
> On Mon, Oct 23, 2006 at 10:29:53AM -0700 I heard the voice of
> Linus Torvalds, and lo! it spake thus:
>> I already briought this up once, and I suspect that the bzr people
>> simply DID NOT UNDERSTAND the question:
>>
>> - how do you do the git equivalent of "gitk --all"
>
> I for one simply DO NOT UNDERSTAND the question, because I don't know
> what that is or what I'd be trying to accomplish by doing it. The
> documentation helpfully tells me that it's something undocumented.
>
See the attached screenshot. This is from qgit --all on the git
repository, but the DAG output is identical to that of gitk. Note in
particular the 'pu' and 'next' branches. By scrolling down, I can easily
see the branch-point of any of them.
To those that do not appreciate or allow email-attachments, I apologize.
I think however that it was necessary to provide a view for the bazaar
people of what Linus is talking about without having to download and
install git and a git repository.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
[-- Attachment #2: Screenshot.png --]
[-- Type: image/png, Size: 148451 bytes --]
^ permalink raw reply
* Re: git-fetch not working?
From: Petr Baudis @ 2006-10-25 11:11 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Andy Parkins, git, ftpadmin
In-Reply-To: <453E8133.8020707@zytor.com>
Dear diary, on Tue, Oct 24, 2006 at 11:10:11PM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> said that...
> Petr Baudis wrote:
> > nope, I'm getting it as well (hey I know about broken git.kernel.org
> >in an hour at most now because of the repo.or.cz cronjobs ;) -
> >git-daemon at the kernel.org machines seems to be broken.
> >
>
> Nope, just tripping the load limit. git1.kernel.org has had loads over
> 400 today. Oddly enough, the load on git2.kernel.org is in the low teens.
Hmm, interesting. Just to make sure, is that because of git-daemon or
something else? :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: git-*arch* in git-arch rpm
From: Gerrit Pape @ 2006-10-25 11:23 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <7viri9dkk5.fsf@assigned-by-dhcp.cox.net>
On Tue, Oct 24, 2006 at 10:35:38PM -0700, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
> > Hi, there're two programs in the git-arch rpm that shouldn't be there:
> So we need at least this?
And this I think, but can't test it.
diff --git a/git.spec.in b/git.spec.in
index 9b1217a..0dbee39 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -96,10 +96,10 @@ find $RPM_BUILD_ROOT -type f -name .pack
find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
-(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
+(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "git-archimport|svn|cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
(find $RPM_BUILD_ROOT%{perl_vendorlib} -type f | sed -e s@^$RPM_BUILD_ROOT@@) >> perl-files
%if %{!?_without_docs:1}0
-(find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "arch|svn|git-cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
+(find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "git-archimport|svn|git-cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
%else
rm -rf $RPM_BUILD_ROOT%{_mandir}
%endif
> diff --git a/git.spec.in b/git.spec.in
> index 9b1217a..b61a338 100644
> --- a/git.spec.in
> +++ b/git.spec.in
> @@ -126,10 +126,10 @@ # These are no files in the root package
>
> %files arch
> %defattr(-,root,root)
> -%doc Documentation/*arch*.txt
> -%{_bindir}/*arch*
> -%{!?_without_docs: %{_mandir}/man1/*arch*.1*}
> -%{!?_without_docs: %doc Documentation/*arch*.html }
> +%doc Documentation/git-archimport.txt
> +%{_bindir}/git-archimport
> +%{!?_without_docs: %{_mandir}/man1/git-archimport.1*}
> +%{!?_without_docs: %doc Documentation/git-archimport.html }
>
> %files email
^ permalink raw reply related
* Re: git-fetch not working?
From: Jakub Narebski @ 2006-10-25 11:37 UTC (permalink / raw)
To: git
In-Reply-To: <20061025111150.GK20017@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Tue, Oct 24, 2006 at 11:10:11PM CEST, I got a letter
> where "H. Peter Anvin" <hpa@zytor.com> said that...
>> Petr Baudis wrote:
>> > nope, I'm getting it as well (hey I know about broken git.kernel.org
>> >in an hour at most now because of the repo.or.cz cronjobs ;) -
>> >git-daemon at the kernel.org machines seems to be broken.
>> >
>>
>> Nope, just tripping the load limit. git1.kernel.org has had loads over
>> 400 today. Oddly enough, the load on git2.kernel.org is in the low
>> teens.
Shouldn't git.kernel.org distribute load?
> Hmm, interesting. Just to make sure, is that because of git-daemon or
> something else? :-)
Today (with git version 1.4.2.1):
998:jnareb@roke:~/git> git pull origin
fatal: read error (Connection reset by peer)
Fetch failure: git://git.kernel.org/pub/scm/git/git.git
1000:jnareb@roke:~/git> time git pull origin-http
Fetching refs/heads/master from http://git.kernel.org/pub/scm/git/git.git using http
Fetching refs/heads/pu from http://git.kernel.org/pub/scm/git/git.git using http
Fetching refs/heads/man from http://git.kernel.org/pub/scm/git/git.git using http
Fetching refs/heads/html from http://git.kernel.org/pub/scm/git/git.git using http
Fetching refs/heads/next from http://git.kernel.org/pub/scm/git/git.git using http
Fetching refs/heads/todo from http://git.kernel.org/pub/scm/git/git.git using http
Fetching refs/heads/maint from http://git.kernel.org/pub/scm/git/git.git using http
Already up-to-date.
real 8m0.369s
user 0m0.984s
sys 0m0.800s
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: updating only changed files source directory?
From: Han-Wen Nienhuys @ 2006-10-25 11:58 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610241435420.9789@iabervon.org>
Daniel Barkalow escreveu:
>> I'm just starting out with GIT. Initially, I want to use experiment with
>> integrating it into our binary builder structure for LilyPond.
>>
>> The binary builder roughly does this:
>>
>> 1. get source code updates from a server to a single, local
>> repository. This is currently a git repository that is that
>> tracks our CVS server.
>>
>> 2. copy latest commit from a branch to separate source directory.
>> This copy should only update files that changed.
>>
>> 3. Incrementally compile from that source directory
>
> The terminology in the git world is, I think, a little different from what
> you expect. We call the thing that contains all of the tracked information
> (what you're calling the repository) the "object database"; what we call
yes, you hit the nail on the head.
> referencing an external one. So you need a repository for each source
> directory (because it keeps track of what commit is currently in the
> source directory), but it doesn't need to have its own complete object
> database, which is what you're trying to share between all of them.
OK. This makes sense; thanks for this pointer.
How can I set the object database? I found GIT_OBJECT_DIRECTORY, but
can I write a config file entry for that?
> built it in that directory. You fetch into the single bare repository
> from upstream, and then pull into each source directory from the bare
> repository; this will do the minimal update to the contents of the source
> directory automatically.
yes, this works. Thanks!
--
^ permalink raw reply
* [PATCH 2/3 (amend)] gitweb: Use --no-commit-id in git_commit and git_commitdiff
From: Jakub Narebski @ 2006-10-25 12:23 UTC (permalink / raw)
To: git
In-Reply-To: <200610241354.49396.jnareb@gmail.com>
Use --no-commit-id option to git diff-tree command in git_commit and
git_commitdiff to filter out commit ID output that git-diff-tree adds
when called with only one <tree-ish> (not only for --stdin).
This option is in git since at least v1.0.0, so make use of it.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is "amend" patch. It adds --no-commit-id option to git-diff-tree
invocation instead of removing commit IDs (tree-ish IDs to be more exact)
from git-diff-tree output.
Still, I'm not sure why git-diff-tree outputs tree-ish before diff
when called with only one tree-ish. Bugwards compatibility?
gitweb/gitweb.perl | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8ac60be..345e336 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3004,7 +3004,8 @@ sub git_commit {
if (!defined $parent) {
$parent = "--root";
}
- open my $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts, $parent, $hash
+ open my $fd, "-|", git_cmd(), "diff-tree", '-r', "--no-commit-id",
+ @diff_opts, $parent, $hash
or die_error(undef, "Open git-diff-tree failed");
my @difftree = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading git-diff-tree failed");
@@ -3321,6 +3322,7 @@ sub git_commitdiff {
my @difftree;
if ($format eq 'html') {
open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
+ "--no-commit-id",
"--patch-with-raw", "--full-index", $hash_parent, $hash
or die_error(undef, "Open git-diff-tree failed");
--
1.4.2.1
^ permalink raw reply related
* [PATCH 4/3] gitweb: Use --no-commit-id in git_commit and git_commitdiff
From: Jakub Narebski @ 2006-10-25 12:17 UTC (permalink / raw)
To: git
In-Reply-To: <200610241354.49396.jnareb@gmail.com>
Use --no-commit-id option to git diff-tree command in git_commit and
git_commitdiff to filter out commit ID output that git-diff-tree adds
when called with only one <tree-ish> (not only for --stdin).
This option is in git since at least v1.0.0, so make use of it.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Gaaah, --no-commit-id is at least since v1.0.0, and we do require
--full-history and --git-dir options which are much later additions.
This is "correction" patch.
gitweb/gitweb.perl | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e35ecb4..345e336 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3004,14 +3004,12 @@ sub git_commit {
if (!defined $parent) {
$parent = "--root";
}
- open my $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts, $parent, $hash
+ open my $fd, "-|", git_cmd(), "diff-tree", '-r', "--no-commit-id",
+ @diff_opts, $parent, $hash
or die_error(undef, "Open git-diff-tree failed");
my @difftree = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading git-diff-tree failed");
- # filter out commit ID output
- @difftree = grep(!/^[0-9a-fA-F]{40}$/, @difftree);
-
# non-textual hash id's can be cached
my $expires;
if ($hash =~ m/^[0-9a-fA-F]{40}$/) {
@@ -3324,15 +3322,14 @@ sub git_commitdiff {
my @difftree;
if ($format eq 'html') {
open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
+ "--no-commit-id",
"--patch-with-raw", "--full-index", $hash_parent, $hash
or die_error(undef, "Open git-diff-tree failed");
while (chomp(my $line = <$fd>)) {
# empty line ends raw part of diff-tree output
last unless $line;
- # filter out commit ID output
- push @difftree, $line
- unless $line =~ m/^[0-9a-fA-F]{40}$/;
+ push @difftree, $line;
}
} elsif ($format eq 'plain') {
--
1.4.2.1
^ permalink raw reply related
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-25 12:41 UTC (permalink / raw)
To: Erik Bågfors
Cc: Carl Worth, Matthew D. Fuller, Linus Torvalds, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <845b6e870610241451x578efe9n77017f3a9404e81c@mail.gmail.com>
Erik Bågfors wrote:
>
> Creates the picture you can see at
> http://erik.bagfors.nu/bzr-plugins/dotrepo.png
>
Looking at this picture, I found a very annoying thing with bzr's
revids: For commits from the same author on the same day, they don't
differ in the beginning, making all of them, at a glance, look the same.
I got a headache just trying to figure out how to read them. It might be
worth looking into in the future, especially if you decide to show them
to the users.
Perhaps it's just my git eyes being used to seeing the first 4 chars
(which is all I normally look at) being different for each different
commit, but having to look up the near-end of the string to find the
actual difference in bzr's revids was actually a quite painful experience.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-25 13:15 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Carl Worth, Matthew D. Fuller, Linus Torvalds, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <453F5B73.2050504@op5.se>
On 10/25/06, Andreas Ericsson <ae@op5.se> wrote:
> Erik Bågfors wrote:
> >
> > Creates the picture you can see at
> > http://erik.bagfors.nu/bzr-plugins/dotrepo.png
> >
>
> Looking at this picture, I found a very annoying thing with bzr's
> revids: For commits from the same author on the same day, they don't
> differ in the beginning, making all of them, at a glance, look the same.
> I got a headache just trying to figure out how to read them. It might be
> worth looking into in the future, especially if you decide to show them
> to the users.
>
> Perhaps it's just my git eyes being used to seeing the first 4 chars
> (which is all I normally look at) being different for each different
> commit, but having to look up the near-end of the string to find the
> actual difference in bzr's revids was actually a quite painful experience.
I agree, and new formats for how the revisions should look are being
discussed on the mailinglist right now. It's not set in stone.
/Erik
--
google talk/jabber. zindar@gmail.com
SIP-phones: sip:erik_bagfors@gizmoproject.com
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-25 13:49 UTC (permalink / raw)
To: Jeff King; +Cc: git, Linus Torvalds, bazaar-ng, David Rientjes
In-Reply-To: <20061025094900.GA26989@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Oct 25, 2006 at 02:19:15AM -0700, David Rientjes wrote:
>
>> No, my criticism is against the added complexity which makes the
>> modification of git increasingly difficult with every new release. It's a
>
> OK, you seemed to imply problems for end users in your first paragraph,
> which is what I was responding to.
>
>> _current_ needs. For any experienced shell programmer it is so much
>> easier to go in and change an option or pipe to a different command or
>> comment out a simple shell command in a .sh file than editing the C code.
>
> Yes, it's true that some operations might be easier to play with in the
> shell. However, does it actually come up that you want to modify
> existing git programs? The more common usage seems to be gluing the
> plumbing together in interesting ways, and that is still very much
> supported.
>
Indeed. I still use my old git-send-patch script whenever I want to send
patches, simply because I don't like git-send-email and its defaults
much. The interface hasn't changed one bit since I wrote it. That's
pretty stable, since send-patch was created couple of hours before git.c
was submitted to the list, as I wrote the "send-patch" script to send
the patch that did the rewriting.
I'm personally all for a rewrite of the necessary commands in C
("commit" comes to mind), but as many others, I have no personal
interest in doing the actual work. I'm fairly certain that once we get
it working natively on windows with some decent performance, windows
hackers will pick up the ball and write "wingit", which will be a log
viewer and GUI thing for
fetching/merging/committing/reverting/rebasing/sending patches and
whatnot. Possibly it will have hooks to Visual C++ or some other IDE. I
don't know how that sort of thing works, but I'm sure someone clever and
bored enough will want to investigate the possibilities.
^ permalink raw reply
* (unknown)
From: andyparkins @ 2006-10-25 14:47 UTC (permalink / raw)
From cd4366ed4e3f765c00310c35c0eabeccf433acdb Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Wed, 25 Oct 2006 15:47:19 +0100
Subject: [PATCH] Use "up/" prefix for all the upstream branches
To: git@vger.kernel.org
X-TUID: aba1ff8a0c61615e
X-UID: 126
X-Length: 1359
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610251547.19208.andyparkins@gmail.com>
To easily differentiate the read-only upstream branches, from normal branches,
default to cloning them with the prefix "up/" added to their branch names.
This also abandons the idea of an "origin" branch which is now simply
"up/master" and hence removes the special treatment that master was getting.
(cherry picked from 33d89375652222c41fbf225f1e1c3bfb38b755b2 commit)
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
I'm sure this will be an unwanted patch. However, I really do think it's
important to highlight these upstream branches in some way. I realise
renaming "origin" is probably not going to fly, but perhaps it would be okay
to have at least the non-origin branches prefixed?
git-clone.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 3f006d1..ebd93da 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -185,7 +185,7 @@ fi
if test -z "$origin"
then
- origin=origin
+ origin=up/master
fi
# Turn the source into an absolute path if
@@ -389,7 +389,7 @@ Pull: refs/heads/$head_points_at:$origin
then
continue
fi
- echo "Pull: refs/heads/${name}:$remote_top/${name}"
+ echo "Pull: refs/heads/${name}:$remote_top/up/${name}"
done >>"$GIT_DIR/remotes/$origin" &&
case "$use_separate_remote" in
t)
--
1.4.2.3
^ permalink raw reply related
* (unknown)
From: andyparkins @ 2006-10-25 14:49 UTC (permalink / raw)
From cf13955d13b8b6a86dd1f6340565e16500b3cf38 Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Wed, 25 Oct 2006 15:49:34 +0100
Subject: [PATCH] Minor grammar fixes for git-diff-index.txt
To: git@vger.kernel.org
X-TUID: c63a7eaedc72a5ce
X-UID: 129
X-Length: 2247
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610251549.34193.andyparkins@gmail.com>
"what you are going to commit is" doesn't need the "is" and does need a comma.
"can trivially see" is an unecessary split infinitive and "easily" is a more
appropriate adverb.
"case where you" should be "case were you" as it's the past tense form of the
verb "to be", rather than a location (I think :-) ).
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-diff-index.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-diff-index.txt
b/Documentation/git-diff-index.txt
index 9cd43f1..ad1e903 100644
--- a/Documentation/git-diff-index.txt
+++ b/Documentation/git-diff-index.txt
@@ -54,7 +54,7 @@ If '--cached' is specified, it allows yo
For example, let's say that you have worked on your working directory,
updated
some files in the index and are ready to commit. You want to see exactly
-*what* you are going to commit is without having to write a new tree
+*what* you are going to commit, without having to write a new tree
object and compare it that way, and to do that, you just do
git-diff-index --cached HEAD
@@ -68,11 +68,11 @@ matches my working directory. But doing
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74
git-commit.c
-You can trivially see that the above is a rename.
+You can see easily that the above is a rename.
In fact, "git-diff-index --cached" *should* always be entirely equivalent to
actually doing a "git-write-tree" and comparing that. Except this one is much
-nicer for the case where you just want to check where you are.
+nicer for the case were you just want to check where you are.
So doing a "git-diff-index --cached" is basically very useful when you are
asking yourself "what have I already marked for being committed, and
--
1.4.2.3
^ permalink raw reply related
* (unknown)
From: andyparkins @ 2006-10-25 14:49 UTC (permalink / raw)
From b149c0fca7399030225750958bf5c962c3796b44 Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Wed, 25 Oct 2006 15:49:50 +0100
Subject: [PATCH] Make new builtin cherry match documentation for "+" and "-"
To: git@vger.kernel.org
X-TUID: 218b478df3f8d847
X-UID: 128
X-Length: 1090
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610251549.51121.andyparkins@gmail.com>
"+" and "-" don't match the documentation, where "+" means the patch /is/ in
upstream, "-" means it isn't
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-log.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 840c742..8ded627 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -519,12 +519,12 @@ int cmd_cherry(int argc, const char **ar
while (list) {
unsigned char sha1[20];
- char sign = '+';
+ char sign = '-';
commit = list->item;
if (!get_patch_id(commit, &patch_id_opts, sha1) &&
lookup_object(sha1))
- sign = '-';
+ sign = '+';
if (verbose) {
static char buf[16384];
--
1.4.2.3
^ permalink raw reply related
* (unknown)
From: andyparkins @ 2006-10-25 14:50 UTC (permalink / raw)
From f52af4e576cb1ad688c72f6cc1443443b7d12b69 Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Wed, 25 Oct 2006 15:50:03 +0100
Subject: [PATCH] git-clone documentation didn't mention --origin as equivalent of -o
To: git@vger.kernel.org
X-Length: 979
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610251550.04024.andyparkins@gmail.com>
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-clone.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
X-TUID: 4aebd5773bc8eef9
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index f973c64..e22a036 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -75,6 +75,7 @@ OPTIONS
this option is used, neither the `origin` branch nor the
default `remotes/origin` file is created.
+--origin::
-o <name>::
Instead of using the branch name 'origin' to keep track
of the upstream repository, use <name> instead. Note
--
1.4.2.3
^ permalink raw reply related
* Re: (unknown)
From: Jakub Narebski @ 2006-10-25 14:53 UTC (permalink / raw)
To: git
In-Reply-To: <E1Gck2K-0003H4-00@dvr.360vision.com>
andyparkins@gmail.com wrote:
> To easily differentiate the read-only upstream branches, from normal branches,
> default to cloning them with the prefix "up/" added to their branch names.
> This also abandons the idea of an "origin" branch which is now simply
> "up/master" and hence removes the special treatment that master was getting.
> (cherry picked from 33d89375652222c41fbf225f1e1c3bfb38b755b2 commit)
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> ---
> I'm sure this will be an unwanted patch. However, I really do think it's
> important to highlight these upstream branches in some way. I realise
> renaming "origin" is probably not going to fly, but perhaps it would be okay
> to have at least the non-origin branches prefixed?
Check if "git clone --use-separate-remote" isn't what you want.
And please correct mail sending.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Minor grammar fixes for git-diff-index.txt
From: Andy Parkins @ 2006-10-25 15:02 UTC (permalink / raw)
To: git
In-Reply-To: <200610251549.34193.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]
From 9f5b5b3d4925ac5f22a64fd075c50417cff7b496 Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Wed, 25 Oct 2006 15:59:53 +0100
Subject: [PATCH] Minor grammar fixes for git-diff-index.txt
To: git@vger.kernel.org
"what you are going to commit is" doesn't need the "is" and does need a comma.
"can trivially see" is an unecessary split infinitive and "easily" is a more
appropriate adverb.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
This corrects the previous grammar patch - the original use of "where" was
correct. You know when you say a word enough and it loses all meaning...
Documentation/git-diff-index.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-diff-index.txt
b/Documentation/git-diff-index.txt
index 9cd43f1..2df581c 100644
--- a/Documentation/git-diff-index.txt
+++ b/Documentation/git-diff-index.txt
@@ -54,7 +54,7 @@ If '--cached' is specified, it allows yo
For example, let's say that you have worked on your working directory,
updated
some files in the index and are ready to commit. You want to see exactly
-*what* you are going to commit is without having to write a new tree
+*what* you are going to commit, without having to write a new tree
object and compare it that way, and to do that, you just do
git-diff-index --cached HEAD
@@ -68,7 +68,7 @@ matches my working directory. But doing
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74
git-commit.c
-You can trivially see that the above is a rename.
+You can see easily that the above is a rename.
In fact, "git-diff-index --cached" *should* always be entirely equivalent to
actually doing a "git-write-tree" and comparing that. Except this one is much
--
1.4.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: (unknown)
From: Andy Parkins @ 2006-10-25 15:10 UTC (permalink / raw)
To: git
In-Reply-To: <ehntnv$b1k$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
On Wednesday 2006 October 25 15:53, Jakub Narebski wrote:
> Check if "git clone --use-separate-remote" isn't what you want.
I did try that, but then the branches don't appear in git branch. I still
like that they exist.
> And please correct mail sending.
AHHHH!!! I thought I had. Dagnamit; I think an upgrade in Debian overwrote my
manual git-imap-send compile. The git-imap-send bug was fixed in
e0b0830726286287744cc9e1a629a534bbe75452, but doesn't seem to have made it
into debian yet.
I'm getting so sick of looking like an idiot.
My apologies to everyone for the constant noise I keep dumping on the list. I
promise I'm trying really hard to be good.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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