* Re: Gitweb: Provide Git links in project list?
From: Fredrik Skolmli @ 2008-07-30 13:02 UTC (permalink / raw)
To: Robert Richter; +Cc: git
In-Reply-To: <20080730125743.GY15356@erda.amd.com>
On Wed, Jul 30, 2008 at 02:57:43PM +0200, Robert Richter wrote:
> The Gitweb on git.kernel.org povides links to the Git repository for
> each project (git <git://...>). However, I did not find this feature
> in the current implementation of git_project_list_body(). Does
> somebody know if there is a patch available for this and if this could
> be added to gitweb?
Is putting the address in .git/cloneurl giving the behaviour you're looking for?
- F
--
Regards,
Fredrik Skolmli
^ permalink raw reply
* Re: [RFC/PATCH v3] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Johannes Schindelin @ 2008-07-30 13:51 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Junio C Hamano, Miklos Vajna, Jakub Narebski
In-Reply-To: <200807300652.41404.chriscool@tuxfamily.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2107 bytes --]
Hi,
On Wed, 30 Jul 2008, Christian Couder wrote:
> Le lundi 28 juillet 2008, Johannes Schindelin a écrit :
>
> > On Mon, 28 Jul 2008, Christian Couder wrote:
> > > + rev = xmalloc((argc - 1) * sizeof(*rev));
> > > +
> > > + do {
> > > + struct commit *r = get_commit_reference(argv[1]);
> > > + if (!r)
> > > + return 1;
> > > + rev[rev_nr++] = r;
> > > + argc--; argv++;
> > > + } while (argc > 1);
> > > +
> > > + return show_merge_base(rev, rev_nr, show_all);
> >
> > rev = xmalloc((argc - 1) * sizeof(*rev));
> >
> > for (rev_nr = 0; rev_nr + 1 < argc; rev_nr++) {
> > rev[rev_nr] = get_commit_reference(argv[rev_nr + 1]);
> > if (!rev[rev_nr])
> > return !!error("Does not refer to a commit: '%s'",
> > argv[rev_nr + 1]);
> > }
> >
> > return show_merge_base(rev, rev_nr, show_all);
> >
> > I do not know about you, but I think this is not only shorter (in spite
> > of adding a helpful error message), but also simpler to understand (not
> > using convoluted do { } while logic), and therefore superior.
>
> In my last version the loop is reduced to:
>
> + do {
> + rev[rev_nr++] = get_commit_reference(argv[1]);
> + argc--; argv++;
> + } while (argc > 1);
>
> so it's very simple.
>
> And the stop condition is simpler in my version.
Does not matter. The logic is convoluted, i.e. not how (most) humans
think. And you cheat by putting the argc and argv statements in one line.
And you do not use argc and argv after the loop, so those statements are
pointless.
And you cheat by not needing that die() anymore because you posted a
(good!) patch _after_ I sent my version.
So it could e as short as this:
while (++rev_nr < argc)
rev[rev_nr - 1] = get_commit_reference(argv[rev_nr]);
I would contend that the for() version is more readable.
> > Your performance argument is weak IMHO, as this is not a big
> > performance hit, and command line parameter parsing is definitely not
> > performance critical.
>
> It feels a bit sloppy though.
Sure.
If you think that obviousness in a command line parsing is less important
than performance.
Ciao,
Dscho
^ permalink raw reply
* [StGit] stg import documentation incorrect.
From: Jurko Gospodnetić @ 2008-07-30 13:52 UTC (permalink / raw)
To: git; +Cc: catalin.marinas
Hi.
StGIT 'stg import' documentation at
http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT_Tutorial states that this
command is equivalent to:
> "stg new" followed by "patch -i <file>", then "stg refresh -e"
However, 'stg refresh' does not accept the -e option (which most
likely has something to do with calling an external editor to edit the a
log message).
Hope this helps.
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* Re: cvs diff -l equivalent?
From: Johannes Schindelin @ 2008-07-30 13:53 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080730082030.GA12555@cuci.nl>
Hi,
On Wed, 30 Jul 2008, Stephen R. van den Berg wrote:
> Someone popped this question on me.
I do not know cvs that well anymore. So I do not know what -l does. Care
to explain?
> How many weeks are there in a lightyear?
That is easy. 52 light ones.
Ciao,
Dscho
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: H.Merijn Brand @ 2008-07-30 13:58 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git
In-Reply-To: <20080730133334.GB31192@lars.home.noschinski.de>
On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski
<lars-2008-1@usenet.noschinski.de> wrote:
> * H.Merijn Brand <h.m.brand@xs4all.nl> [08-07-30 13:38]:
>
> > I can ask them what version they have, and I can then check if
> > the complaint was already addressed in an update that was
> > already released. In SCCS this was easy: they tell me the output
> > of the what command, I check if the bug was fixed in a newer
> > version and the answer is present. No such luck in git, as the
> > stamps are (non-sequitive) SHA id's. As we moved to git, we now
> > have to update those id's by hand, as the customers are used to
> > it. (At least we can now use readable date formats)
>
> Hm, what about "git-describe --contains $SHA_OF_BUGFIX"?
If you come from a SCCS environment, the developers are used to see the
version of a single file, not of the id of a fix. One of the reasons we
moved from SCCS to git, is that we now can commit a group of files as a
single commit, and later look at the complete picture.
We are not used to working with $SHA's, and IMHO from the end-user pov,
a $SHA is less user friendly than a release number or a file version. I
can remember a version, but I cannot remember a SHA.
The end user only has the application, which is (or at least should be)
able to spit out its release version. That is all we can go by when we
dig back into the history to see where we changed things.
One (very) big disadvantage of SCCS is that commits are on a per-file
basis, and only in a single directory. This drawback still haunts me in
git, as my first attempts to convert were successful in a single folder
and git cannot merge folders into a single project.
Say I now have
/work/src/project/.git
/work/src/project/module_a/.git
/work/src/project/module_b/.git
/work/src/project/module_c/.git
Which are all converted repos from SCCS, I'd like to merge the three
module_# repos into the top level repo.
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: cvs diff -l equivalent?
From: Thomas Rast @ 2008-07-30 14:00 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080730082030.GA12555@cuci.nl>
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
Stephen R. van den Berg wrote:
> Someone popped this question on me. The closest I got was:
>
> git diff .
>
> But that still recurses. Any solutions without patching?
Maybe a scripted version? For just 'git diff .', this should work:
git diff $(git ls-files . | grep -v /)
That will still do the wrong thing if you diff against an older commit
with a different list of files. In that case you need the list of
files in the other side of the diff too:
git diff HEAD^.. -- $(git ls-files . | grep -v /; git ls-tree HEAD^ | cut -f2)
- Thomas
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: German translation of git man pages
From: Fabio Scotoni @ 2008-07-30 14:05 UTC (permalink / raw)
To: git
Hello,
On Wed, 2008-07-30 at 14:25 +0200, Stephan Beyer wrote:
> The glossary may also be a good help:
> http://git.kernel.org/?p=git/git.git;a=blob;f=git-gui/po/glossary/de.po
I think we should follow this Glossary. Git-gui users should not be
forced to learn again. Learning git is already enough work.
On Wed, 2008-07-30 at 13:18 +0200, David Soria Parra wrote:
> You might want to provide a public repository, which we can pull from
> and send you patches.
Of course. Here it is: git://repo.or.cz/srv/git/gitman-de.git
(You may blame me now for using a public repository.)
I did create the mob user ( http://repo.or.cz/mob.html ) and it's
branch. Pushing only over ssh.
I used the repository of git from yesterday.
The only translated file at the moment is gittutorial-de.txt.
Every file without -de at its end is the original English file.
DO NOT MODIFY them.
If files with -de at their end have English passages or are completely
English means, they haven't been translated.
Note: You should fix any Eszett errors, I'm Swiss, so i was unable to
insert any Eszetts.
On Wed, 2008-07-30 at 13:06 +0200, Stephen R. van den Berg wrote:
> A good translation will translate those words. However, since the
> commandline interface uses the English words, you'll be forced to
> re-explain that relationship a lot of times (using parenthesis, most
> likely).
I think we should avoid this. It just makes the text more unclear and
harder to understand. Instead, we should provide something like
"gitglossary-de.1", so interested users can look up our translations of
English words.
On Wed, 2008-07-30 at 11:21 +0000, Mark Struberg wrote:
> (Reminds me of some old Siemens BS2000 mainfraims back in the 80s.
> They translated really ALL terms to german, which was frankly
> completely unreadable)
Yes, I exactly know what you mean and I would like to keep some terms,
but they were translated to German and so I feel forced to copy the
glossary of git-gui.
With best regards,
Fabio Scotoni
^ permalink raw reply
* Re: [PATCH] 64bit issue in test-parse-options.c
From: Pierre Habouzit @ 2008-07-30 14:05 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20080730144452.797d8686@pc09.procura.nl>
[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]
On Wed, Jul 30, 2008 at 12:44:52PM +0000, H.Merijn Brand wrote:
> On Wed, 30 Jul 2008 14:37:13 +0200, Pierre Habouzit
> <madcoder@debian.org> wrote:
>
> > On Wed, Jul 30, 2008 at 12:16:56PM +0000, H.Merijn Brand wrote:
> > > git-1.5.6.4 - HP-UX 11.23 64bit compile
> > >
> > > * expecting success:
> > > test-parse-options -s123 -b -i 1729 -b -vv -n > output 2> output.err &&
> > > test_cmp expect output &&
> > > test ! -s output.err
> > >
> > > --- expect 2008-07-30 11:52:05 +0000
> > > +++ output 2008-07-30 11:52:05 +0000
> > > @@ -1,5 +1,5 @@
> > > boolean: 2
> > > -integer: 1729
> > > +integer: 7425998454784
> > > string: 123
> > > abbrev: 7
> > > verbose: 2
> > > * FAIL 2: short options
> > >
> > > I'm sure you can come up with a more sensible change, but the current
> > > code is definitely wrong
> > >
> > >
> > > --8<---
> > > --- test-parse-options.c.org 2008-07-30 11:57:16 +0000
> > > +++ test-parse-options.c 2008-07-30 12:08:56 +0000
> > > @@ -2,6 +2,7 @@
> > > #include "parse-options.h"
> > >
> > > static int boolean = 0;
> > > +static unsigned int int_integer = 0;
> > > static unsigned long integer = 0;
> >
> > long is wrong in the first place, parse-opt only uses ints.
>
> If I change it to int, the date parsing goes bogus.
That is because OPT_DATE indeed expect a long (why not a time_t I don't
know btw... but time_t is a long on linux so it doesn't change things a
lot).
The proper fix is to let integer be an *INT* (long integer is bogus
anyways) and to put the date in a long using static unsigned long date,
and make OPT_DATE use this long.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] Add git-sequencer documentation
From: Johannes Schindelin @ 2008-07-30 14:06 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <20080730121454.GA8767@leksak.fem-net>
Hi,
On Wed, 30 Jul 2008, Stephan Beyer wrote:
> Johannes Schindelin wrote:
> > > +-B::
> > > +--batch::
> > > + Run in batch mode. If unexpected user intervention is needed
> > > + (e.g. a conflict or the need to run an editor), 'git-sequencer' fails.
> >
> > Does it abort, or leave a dirty tree?
>
> It aborts.
> Perhaps I should make this clear in the docs.
No, just leave it as is. The users can always ask you on the mailing
list. So my comment was totally unfounded.
> > > +--onto=<base>::
> > > + Checkout given commit or branch before sequencing.
> > > + If you provide a branch, sequencer will make the provided
> > > + changes on the branch, i.e. the branch will be changed.
> >
> > Whoa, does that mean that
> >
> > $ git checkout my-private-branch
> > $ git sequencer --onto=master
> >
> > will change _master_?
>
> Exactly.
/me does not like that. I could see a new porcelain doing that, but not
the thing that will be called by rebase.
> > > + --include-merges;;
> > > + Sanity check does not fail if you have merges
> > > + between HEAD and <mark>.
> >
> > It may be a commit, too, right? And why does it make sense to check that
> > there are no merges? I mean, it is just as if I did two cherry-picks, the
> > second with -n, and then commit --amend it. Can make tons of sense...
>
> I think I mean something different. With "merges" I am talking about
> commits having more than one parent.
Yes, I read "merges" the same way. My comment still stands.
> Thanks for your reply and your other notes. (The ones I didn't comment
> are just ACKed.)
The ones that _I_ did not comment on I do not necessarily agree with, but
then, I do not have the time to argue about them.
Ciao,
Dscho
^ permalink raw reply
* Re: git sequencer prototype
From: Johannes Schindelin @ 2008-07-30 14:07 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <20080730121458.GB8767@leksak.fem-net>
Hi,
On Wed, 30 Jul 2008, Stephan Beyer wrote:
> Johannes Schindelin wrote:
> >
> > > In the last patchset I mentioned the issue, that the prototype is
> > > slow as hell. I know some bottlenecks, but I have not even tried to
> > > change that, because this is no issue for the builtin.
> >
> > Why is it no issue for the builtin? Is it so much different from the
> > prototype?
>
> As Sverre pointed out and as my "experiments" tried to show: the builtin
> is just fast ;-)
So why is it just so fast? Does it do things completely different than
the shell prototype you presented?
Still puzzled,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] GitStats development finished (WRT GSoC)
From: Johannes Schindelin @ 2008-07-30 14:22 UTC (permalink / raw)
To: sverre
Cc: Junio C Hamano, Git Mailinglist, Jakub Narebski, David Symonds,
Shawn O. Pearce, Sam Vilain
In-Reply-To: <bd6139dc0807300212r67ccb849i542e490c8cd00953@mail.gmail.com>
Hi,
On Wed, 30 Jul 2008, Sverre Rabbelier wrote:
> On Wed, Jul 30, 2008 at 09:07, Junio C Hamano <gitster@pobox.com> wrote:
> > Can't wait running this, especially in conjunction with the "author"
> > stuff ;-)
>
> Hehe, don't expect too much of it yet though (the 'bug' module that is),
> there won't be any "99% of the bugs come from Dscho" yet :P.
So what should I expect? What does it show?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] format-patch: Produce better output with --inline or --attach
From: Johannes Schindelin @ 2008-07-30 14:29 UTC (permalink / raw)
To: Kevin Ballard; +Cc: git, peff, Junio C Hamano
In-Reply-To: <1217396973-82246-1-git-send-email-kevin@sb.org>
Hi,
On Tue, 29 Jul 2008, Kevin Ballard wrote:
> MIME defines the encapsulation boundary as including the preceding CRLF (or in
This line will still be too long in git log's output, as well as in git
shortlog's output. I thought we had a suggestion to use at most 76
characters per line in SubmittingPatches, but apparently we don't.
> The second change is to always write the line termination character
> (default: newline) even when using --inline or --attach. This is simply
> to improve the aesthetics of the resulting message. When using --inline
> an email client should render the resulting message identically to the
> non-inline version. And when using --attach this adds a blank line
> preceding the attachment in the email, which is visually attractive.
It appears that your patch has one uncontroversial and one controversial
part, then.
Ciao,
Dscho
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: Miklos Vajna @ 2008-07-30 14:55 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Lars Noschinski, git
In-Reply-To: <20080730155835.71289eee@pc09.procura.nl>
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
On Wed, Jul 30, 2008 at 03:58:35PM +0200, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
> We are not used to working with $SHA's, and IMHO from the end-user pov,
> a $SHA is less user friendly than a release number or a file version. I
> can remember a version, but I cannot remember a SHA.
But a version is never unique in a distributed environment. So a version
is useless without at least an abbreviated hash.
If pure hashes are not friendly enough, you can use something like:
git describe $(git rev-list -1 HEAD -- <file>)
to get the _hash_ of the _commit_ (ie. not the version of a file) that
touched the file last time.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Gitweb: Provide Git links in project list?
From: Bert Wesarg @ 2008-07-30 14:55 UTC (permalink / raw)
To: Robert Richter; +Cc: Fredrik Skolmli, git
In-Reply-To: <20080730131357.GZ15356@erda.amd.com>
On Wed, Jul 30, 2008 at 15:13, Robert Richter <robert.richter@amd.com> wrote:
> On 30.07.08 15:02:57, Fredrik Skolmli wrote:
>> On Wed, Jul 30, 2008 at 02:57:43PM +0200, Robert Richter wrote:
>>
>> > The Gitweb on git.kernel.org povides links to the Git repository for
>> > each project (git <git://...>). However, I did not find this feature
>> > in the current implementation of git_project_list_body(). Does
>> > somebody know if there is a patch available for this and if this could
>> > be added to gitweb?
>>
>> Is putting the address in .git/cloneurl giving the behaviour you're looking for?
>
> Yes, I did change this and in the project summary I get "URL git://...".
>
> That I mean is the main page, that lists the projects. I only have:
>
> ... summary | shortlog | log | tree
>
> At git.kernel.org there is additional '... | git' with a link to the
> Git repository.
>
> The current source of gitweb seems not to provide this.
Look here for all notible forks of gitweb:
http://git.or.cz/gitwiki/Gitweb
Bert
>
> -Robert
>
> --
> Advanced Micro Devices, Inc.
> Operating System Research Center
> email: robert.richter@amd.com
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Johannes Schindelin @ 2008-07-30 14:56 UTC (permalink / raw)
To: Steve Haslam; +Cc: git
In-Reply-To: <1217417238-26731-1-git-send-email-shaslam@lastminute.com>
Hi,
> diff --git a/upload-pack.c b/upload-pack.c
> index c911e70..086eff6 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -616,6 +616,9 @@ int main(int argc, char **argv)
> int i;
> int strict = 0;
>
> + if (argv[0] && *argv[0])
> + git_extract_argv0_path(argv[0]);
> +
This is ugly. The called function should already do it itself.
Further, why not go the full nine yards and avoid the calculation
altogether, until it is necessary? Then the change to add
lookup_program_in_path() would be nice and non-intrusive.
IOW why not leave the function name as-is, and just enhance system_path()
to have a static variable "initialized", which does the whole calculation?
I.e. move the calculation from git.c to exec_cmd.c, but at the same time
do it only when needed.
And your change to set argv0_path from receive-pack and upload-pack would
be a second patch.
And then the patch to add support to "glean" (did not know that word) the
path from the PATH (lookup_program_in_path()) could come as a third patch.
Ciao,
Dscho
^ permalink raw reply
* Re: git blame not respecting --find-copies-harder ?
From: Björn Steinbrink @ 2008-07-30 15:01 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Git Mailinglist
In-Reply-To: <20080730093903.GA14330@cuci.nl>
On 2008.07.30 11:39:03 +0200, Stephen R. van den Berg wrote:
> git clone git://git.cuci.nl/pike
>
> Both of this "git blame" commands return the same (erroneous) results
> at the end of the files (the last lines are older, and are from the old
> README file next to it).
>
> git blame README-CVS
> git blame --find-copies-harder README-CVS
git blame doesn't know --find-copies-harder, it's -C -C for blame.
Björn
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: H.Merijn Brand @ 2008-07-30 15:03 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Lars Noschinski, git
In-Reply-To: <20080730145534.GD32057@genesis.frugalware.org>
On Wed, 30 Jul 2008 16:55:34 +0200, Miklos Vajna
<vmiklos@frugalware.org> wrote:
> On Wed, Jul 30, 2008 at 03:58:35PM +0200, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
> > We are not used to working with $SHA's, and IMHO from the end-user pov,
> > a $SHA is less user friendly than a release number or a file version. I
> > can remember a version, but I cannot remember a SHA.
>
> But a version is never unique in a distributed environment. So a version
> is useless without at least an abbreviated hash.
Which is exactly what my git-hist does:
# git-hist *pm | perl -ne'63..83 and print'
09d4472 2007-12-06 13:25:58 63: allow_loose_quotes => 0,
09d4472 2007-12-06 13:25:58 64: allow_loose_escapes => 0,
09d4472 2007-12-06 13:25:58 65: allow_whitespace => 0,
caf4798 2008-02-19 17:56:36 0.34 + 004 66: blank_is_undef => 0,
09d4472 2007-12-06 13:25:58 67: verbatim => 0,
09d4472 2007-12-06 13:25:58 68: types => undef,
09d4472 2007-12-06 13:25:58 69:
8648db0 2008-03-27 18:37:54 0.37 + 002 70:
09d4472 2007-12-06 13:25:58 71: _EOF => 0,
09d4472 2007-12-06 13:25:58 72: _STATUS => undef,
09d4472 2007-12-06 13:25:58 73: _FIELDS => undef,
09d4472 2007-12-06 13:25:58 74: _FFLAGS => undef,
09d4472 2007-12-06 13:25:58 75: _STRING => undef,
09d4472 2007-12-06 13:25:58 76: _ERROR_INPUT => undef,
2b95026 2008-04-04 11:10:09 0.37 + 006 77: _COLUMN_NAMES => undef,
ce53d02 2008-04-06 00:40:26 0.37 + 016 78: _BOUND_COLUMNS => undef,
09d4472 2007-12-06 13:25:58 79: );
caf4798 2008-02-19 17:56:36 0.34 + 004 80: my $last_new_err = "";
09d4472 2007-12-06 13:25:58 81:
09d4472 2007-12-06 13:25:58 82: sub new
09d4472 2007-12-06 13:25:58 83: {
> If pure hashes are not friendly enough, you can use something like:
>
> git describe $(git rev-list -1 HEAD -- <file>)
What do I miss here?
> git describe $(git rev-list -1 HEAD -- *pm)
fatal: cannot describe 'c2220c8a544af5cd5419e238eb5f43b1f079ad85'
> to get the _hash_ of the _commit_ (ie. not the version of a file) that
> touched the file last time.
My git-hist is just a perl script that collects the combined
information of
git-log --pretty=format:'%h %ct %s'
git-show-ref --tags
and git-blame file
I could also make it a reformatting wrapper over several calls to
git blame -l file | git name-rev --stdin --tags
Which is probably faster for a single file, but slower on multiple files
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: Santi Béjar @ 2008-07-30 15:18 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Lars Noschinski, git
In-Reply-To: <20080730155835.71289eee@pc09.procura.nl>
On Wed, Jul 30, 2008 at 15:58, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski
> <lars-2008-1@usenet.noschinski.de> wrote:
>
>> * H.Merijn Brand <h.m.brand@xs4all.nl> [08-07-30 13:38]:
>>
>> > I can ask them what version they have, and I can then check if
>> > the complaint was already addressed in an update that was
>> > already released. In SCCS this was easy: they tell me the output
>> > of the what command, I check if the bug was fixed in a newer
>> > version and the answer is present. No such luck in git, as the
>> > stamps are (non-sequitive) SHA id's. As we moved to git, we now
>> > have to update those id's by hand, as the customers are used to
>> > it. (At least we can now use readable date formats)
>>
>> Hm, what about "git-describe --contains $SHA_OF_BUGFIX"?
>
> If you come from a SCCS environment, the developers are used to see the
> version of a single file, not of the id of a fix. One of the reasons we
> moved from SCCS to git, is that we now can commit a group of files as a
> single commit, and later look at the complete picture.
>
> We are not used to working with $SHA's, and IMHO from the end-user pov,
> a $SHA is less user friendly than a release number or a file version. I
> can remember a version, but I cannot remember a SHA.
>
> The end user only has the application, which is (or at least should be)
> able to spit out its release version.
As git itself does:
$ git version
git version 1.6.0.rc1.11.g1ce47
I think it is far better to know the version of the entire project,
than the version of a single file.
> That is all we can go by when we
> dig back into the history to see where we changed things.
>
> One (very) big disadvantage of SCCS is that commits are on a per-file
> basis, and only in a single directory. This drawback still haunts me in
> git, as my first attempts to convert were successful in a single folder
> and git cannot merge folders into a single project.
>
> Say I now have
>
> /work/src/project/.git
> /work/src/project/module_a/.git
> /work/src/project/module_b/.git
> /work/src/project/module_c/.git
>
> Which are all converted repos from SCCS, I'd like to merge the three
> module_# repos into the top level repo.
You have, basically, two possibilities:
1) Add the module_# as submodules:
http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
http://git.or.cz/gitwiki/GitSubmoduleTutorial
2) Add the submodules as subtrees (as gitk and git-gui in git.git)
http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
Santi
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: Santi Béjar @ 2008-07-30 15:23 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Miklos Vajna, Lars Noschinski, git
In-Reply-To: <20080730170326.6f4f1772@pc09.procura.nl>
On Wed, Jul 30, 2008 at 17:03, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> On Wed, 30 Jul 2008 16:55:34 +0200, Miklos Vajna
> <vmiklos@frugalware.org> wrote:
>
>> If pure hashes are not friendly enough, you can use something like:
>>
>> git describe $(git rev-list -1 HEAD -- <file>)
>
> What do I miss here?
>
>> git describe $(git rev-list -1 HEAD -- *pm)
> fatal: cannot describe 'c2220c8a544af5cd5419e238eb5f43b1f079ad85'
>
It cannot be described because there is no annotated tag before this
commit. Add --always to show the abbreviated commit as fallback.
Santi
^ permalink raw reply
* Re: Gitweb: Provide Git links in project list?
From: Robert Richter @ 2008-07-30 15:27 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Fredrik Skolmli, git
In-Reply-To: <36ca99e90807300755r1b1bc53bmdbaa1811370cd1f@mail.gmail.com>
On 30.07.08 16:55:40, Bert Wesarg wrote:
> > The current source of gitweb seems not to provide this.
>
> Look here for all notible forks of gitweb:
>
> http://git.or.cz/gitwiki/Gitweb
>
> Bert
Thanks Bert, it is in the kernel.org repository.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: H.Merijn Brand @ 2008-07-30 15:29 UTC (permalink / raw)
To: Santi Béjar; +Cc: Lars Noschinski, git
In-Reply-To: <8aa486160807300818m108920a0pe4a5de47de8d838c@mail.gmail.com>
On Wed, 30 Jul 2008 17:18:59 +0200, "Santi Béjar" <sbejar@gmail.com>
wrote:
> On Wed, Jul 30, 2008 at 15:58, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> > On Wed, 30 Jul 2008 15:33:34 +0200, Lars Noschinski
> > <lars-2008-1@usenet.noschinski.de> wrote:
> >
> >> * H.Merijn Brand <h.m.brand@xs4all.nl> [08-07-30 13:38]:
> >>
> >> > I can ask them what version they have, and I can then check if
> >> > the complaint was already addressed in an update that was
> >> > already released. In SCCS this was easy: they tell me the output
> >> > of the what command, I check if the bug was fixed in a newer
> >> > version and the answer is present. No such luck in git, as the
> >> > stamps are (non-sequitive) SHA id's. As we moved to git, we now
> >> > have to update those id's by hand, as the customers are used to
> >> > it. (At least we can now use readable date formats)
> >>
> >> Hm, what about "git-describe --contains $SHA_OF_BUGFIX"?
> >
> > If you come from a SCCS environment, the developers are used to see the
> > version of a single file, not of the id of a fix. One of the reasons we
> > moved from SCCS to git, is that we now can commit a group of files as a
> > single commit, and later look at the complete picture.
> >
> > We are not used to working with $SHA's, and IMHO from the end-user pov,
> > a $SHA is less user friendly than a release number or a file version. I
> > can remember a version, but I cannot remember a SHA.
>
> >
> > The end user only has the application, which is (or at least should be)
> > able to spit out its release version.
>
> As git itself does:
>
> $ git version
> git version 1.6.0.rc1.11.g1ce47
>
> I think it is far better to know the version of the entire project,
> than the version of a single file.
Yes. I agree.
We us tags to `mark' the release, but with the repo's of a project
(still) scattered around, it is far from ideal.
And as to a single file: I mostly know (when I fixed something) in what
file I fixed it, so the first thing I do is to check that file against
the revision that the customer runs.
> > That is all we can go by when we dig back into the history to see where
> > we changed things.
> >
> > One (very) big disadvantage of SCCS is that commits are on a per-file
> > basis, and only in a single directory. This drawback still haunts me in
> > git, as my first attempts to convert were successful in a single folder
> > and git cannot merge folders into a single project.
> >
> > Say I now have
> >
> > /work/src/project/.git
> > /work/src/project/module_a/.git
> > /work/src/project/module_b/.git
> > /work/src/project/module_c/.git
> >
> > Which are all converted repos from SCCS, I'd like to merge the three
> > module_# repos into the top level repo.
>
> You have, basically, two possibilities:
>
> 1) Add the module_# as submodules:
> http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
> http://git.or.cz/gitwiki/GitSubmoduleTutorial
> 2) Add the submodules as subtrees (as gitk and git-gui in git.git)
> http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
Thanks, I'll start reading ...
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH 2/5] Add git-sequencer documentation
From: Daniel Barkalow @ 2008-07-30 15:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephan Beyer, git, Christian Couder
In-Reply-To: <alpine.LSU.1.00.0807301556140.3486@wbgn129.biozentrum.uni-wuerzburg.de>
On Wed, 30 Jul 2008, Johannes Schindelin wrote:
> On Wed, 30 Jul 2008, Stephan Beyer wrote:
>
> > Johannes Schindelin wrote:
> >
> > > Whoa, does that mean that
> > >
> > > $ git checkout my-private-branch
> > > $ git sequencer --onto=master
> > >
> > > will change _master_?
> >
> > Exactly.
>
> /me does not like that. I could see a new porcelain doing that, but not
> the thing that will be called by rebase.
Yeah, an option to change which branch is current should be called
something different. --onto is an initial reset --hard, not an initial
checkout; it specifies the branch (or commit) that the sequence of changes
are done on top of, not the branch that will contain them. "Onto" (as an
english preposition) specifies a destination, not a location, so it
doesn't make sense as the location that stuff is done.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [ANNOUNCE] GitStats development finished (WRT GSoC)
From: Sverre Rabbelier @ 2008-07-30 15:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Git Mailinglist, Jakub Narebski, David Symonds,
Shawn O. Pearce, Sam Vilain
In-Reply-To: <alpine.LSU.1.00.0807301621570.3486@wbgn129.biozentrum.uni-wuerzburg.de>
On Wed, Jul 30, 2008 at 16:22, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Wed, 30 Jul 2008, Sverre Rabbelier wrote:
>> Hehe, don't expect too much of it yet though (the 'bug' module that is),
>> there won't be any "99% of the bugs come from Dscho" yet :P.
>
> So what should I expect? What does it show?
Atm I have 4 'metrics' (4 out of the 5 suggested ones), namely:
* Does a commit belong to a specific branch. This can be used, for
example, to mark commits on 'maint' as bugfixes with 99% reliability
(you need to make sure your regexp catches all branches you are
interested in, when Junio splits of '1.5.6.4' of maint, it might list
'1.5.6.4' instead of 'maint', as they both point at the same ref).
* Does a commit fully revert another one (e.g., make commit A, do 'git
revert A', it will detect that commit as reverting A).
* Does the commit message match a certain regexp (e.g., if it contains
the word "fixes", it is likely a fix).
* Does the commit diff match a regexp (e.g., a change from
"test_expect_failure" -> "test_expect_success")
- (not tweaked yet) Does a commit partially revert another one, this
needs some tweaking, otherwise small changes are quickly seen as
similar. (If you have two unrelated one-lines, and you set it to
ignore one difference...)
You have to configure a few things to get it running (for example, you
need to tell it what branch is your maintenance branch, if any). You
can also configure how valued each metric is (you can say "if it's in
'maint', add 5 points, but if it's a revert, add 10, and add only 1
point if it matches this regexp). Configuration is trivially done with
'git config GitStats.key value".
(Will add the above to the bug module's documentation)
If anyone comes up with any more metrics to determine whether
something is a bug it can be easily hooked in.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git blame not respecting --find-copies-harder ?
From: Sverre Rabbelier @ 2008-07-30 15:43 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Stephen R. van den Berg, Git Mailinglist
In-Reply-To: <20080730150123.GB9758@atjola.homenet>
On Wed, Jul 30, 2008 at 17:01, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> git blame doesn't know --find-copies-harder, it's -C -C for blame.
Shouldn't it have died with "don't know option --find-copies-harder" then?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Gitweb: Provide Git links in project list?
From: J.H. @ 2008-07-30 15:49 UTC (permalink / raw)
To: Robert Richter; +Cc: git
In-Reply-To: <20080730125743.GY15356@erda.amd.com>
Robert,
That is a kernel.org specific change - if the community at large wants
it I can dig the patch out (I likely didn't do it as it's own patch when
I did it, being young, naive and stupid at the time - I'm now slightly
older and slightly less naive now ;-)
But yeah - if people feel that's interesting I'm happy to rip it out
later today and submit it to the mailing list.
- John 'Warthog9' Hawley
On Wed, 2008-07-30 at 14:57 +0200, Robert Richter wrote:
> The Gitweb on git.kernel.org povides links to the Git repository for
> each project (git <git://...>). However, I did not find this feature
> in the current implementation of git_project_list_body(). Does
> somebody know if there is a patch available for this and if this could
> be added to gitweb?
>
> Thanks,
>
> -Robert
>
^ 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