* 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
* Re: cvs diff -l equivalent?
From: Stephen R. van den Berg @ 2008-07-30 15:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.LSU.1.00.0807301553030.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>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?
Usage: cvs diff [-lR] [-k kopt] [format_options]
[[-r rev1 | -D date1] [-r rev2 | -D date2]] [files...]
-l Local directory only, not recursive
It shows the diff for all files in the current directory, nothing
deeper, nothing higher.
>> How many weeks are there in a lightyear?
>That is easy. 52 light ones.
I presume you mean "lightweeks", and yes, that would probably fit the bill :-).
--
Sincerely,
Stephen R. van den Berg.
^ permalink raw reply
* Re: Feature suggestion: git-hist
From: Avery Pennarun @ 2008-07-30 15:58 UTC (permalink / raw)
To: Santi Béjar; +Cc: H.Merijn Brand, Miklos Vajna, Lars Noschinski, git
In-Reply-To: <8aa486160807300823w3dfbdff2m4b9821d71779231d@mail.gmail.com>
On Wed, Jul 30, 2008 at 11:23 AM, Santi Béjar <sbejar@gmail.com> wrote:
> It cannot be described because there is no annotated tag before this
> commit. Add --always to show the abbreviated commit as fallback.
Or --tags to include non-annotated tags.
Avery
^ permalink raw reply
* Re: German translation of git man pages
From: Petr Baudis @ 2008-07-30 16:03 UTC (permalink / raw)
To: Fabio Scotoni; +Cc: git
In-Reply-To: <alpine.LNX.1.10.0807301604010.4094@hydra.esse.ch>
Hi!
On Wed, Jul 30, 2008 at 04:05:03PM +0200, Fabio Scotoni wrote:
> 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
(Your favorite public link-correcting service "pasky" offers
git://repo.or.cz/gitman-de.git
http://repo.or.cz/w/gitman-de.git
instead. ;-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Gitweb: Provide Git links in project list?
From: Robert Richter @ 2008-07-30 16:11 UTC (permalink / raw)
To: J.H.; +Cc: git
In-Reply-To: <1217432970.2884.8.camel@localhost.localdomain>
On 30.07.08 08:49:30, J.H. wrote:
> 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, I would like the patch.
Yes, I have seen the commit as well and it is not the only change in
this commit. Also, if I got it right, the repository is not taken from
.git/cloneurl. So, with the current implementation the git url in the
summary page may be different to cloneurl. But this is not a major
issue.
It would be great if you could provide a patch with your changes for
gitweb.
Thanks,
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com
^ permalink raw reply
* Re: [PATCH] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Steve Haslam @ 2008-07-30 16:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Johannes Sixt
In-Reply-To: <alpine.LSU.1.00.0807301650060.3486@wbgn129.biozentrum.uni-wuerzburg.de>
[sorry, was intended to cc Johannes Sixt when I mailed the patch to the
list... not doing well with the recipient etiquette]
[and then Icedove decided it was going to send mail as HTML. This is so embarassing.]
Johannes Schindelin wrote:
>> 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.
>
Fair enough.
> 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.
git.c will always need to do the calculation, to determine which command
it is being invoked as, so is there much value in delaying until necessary?
If the code in git.c is left alone, then it needs to be eventually
duplicated in upload-pack.c and receive-pack.c, or in exec_cmd.c. [I
botched when sending out the patch originally and only sent it to
Johannes and not the list, so it's my fault that the history of how this
has evolved is unclear I'm afraid]
> 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.
Hmm, system_path and setup_path both use argv0_path; git.c would need to
call an additional function in exec_cmd.c to get the "leafname" result
of the calculation, though.
> And your change to set argv0_path from receive-pack and upload-pack would
> be a second patch.
OK.
> 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.
I think that once git-upload-pack.c et al get the argv[0] path over to
setup_path() then there's nothing more to do; setup_path() already uses
argv0_path in its list of paths to try. I'm confused to the reference to
PATH, though: we're avoiding the PATH environment variable completely.
SRH
^ permalink raw reply
* Re: cvs diff -l equivalent?
From: Stephen R. van den Berg @ 2008-07-30 16:17 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200807301600.44205.trast@student.ethz.ch>
Thomas Rast wrote:
>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 /)
git diff $(git ls-files --exclude-standard . | fgrep -v /)
comes the closest, so it seems.
>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)
This doesn't seem to do the right thing, it messes up with which commit we
diff.
--
Sincerely,
Stephen R. van den Berg.
How many weeks are there in a lightyear?
^ permalink raw reply
* Re: Merging submodules (was Re: Feature suggestion: git-hist)
From: H.Merijn Brand @ 2008-07-30 16:26 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Lars Noschinski, git
In-Reply-To: <FA2D570A-B2B1-4994-AA6A-9C0C55E69900@silverinsanity.com>
On Wed, 30 Jul 2008 11:15:55 -0400, Brian Gernhardt
<benji@silverinsanity.com> wrote:
>
> On Jul 30, 2008, at 9:58 AM, H.Merijn Brand wrote:
>
> > 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.
>
> Following the example of Linus, the following is completely untested.
>
> First you fetch all of the heads/tags/etc into the superproject with
> commands like
>
> git fetch module_a refs/heads/*:refs/remotes/module_a/*
> git fetch module_b refs/heads/*:refs/remotes/module_b/*
> git fetch module_c refs/heads/*:refs/remotes/module_c/*
All went well
> Then you do something like:
>
> rm -rf module_{a,b,c}/.git # Do this in a test repository, obviously...
> git add module_a module_b module_c
> git commit # Needed because '-s ours' uses current HEAD, not index
So far so good.
> git merge --no-commit -s ours module_a/master module_b/master module_c/master
$ git merge --no-commit -s ours fnc/master i00f000/master
i99f000/master include/master l00m000/master l01f000/master l02f000/master l03f000/master l06f000/master l90z000/master leerpl/master mutbev/master prtabel/master rpt/master tabellen/master zoomen/master Automatic merge went well; stopped before committing as requested
> git commit --amend
$ git commit --amend
fatal: You are in the middle of a merge -- cannot amend.
$ git status
# On branch master
nothing to commit (working directory clean)
When I start git-gui, it still shows a long commit message:
Merge commit 'fnc/master'; commit 'i00f000/master'; commit 'i99f000/master'; commit 'include/master'; commit 'l00m000/master'; commit 'l01f000/master'; commit 'l02f000/master'; commit 'l03f000/master'; commit 'l06f000/master'; commit 'l90z000/master'; commit 'leerpl/master'; commit 'mutbev/master'; commit 'prtabel/master'; commit 'rpt/master'; commit 'tabellen/master'; commit 'zoomen/master'
All other areas are clear
> From this point on, the project repository has a merged history of
> the sub-projects, and if anyone doesn't catch up and still makes a
> commit on a subproject you can use "git merge -s subtree" to merge it
> in anyway.
>
> You may need to "git rm --cached" some files after the "git add" step
> if your .gitignore files aren't perfect.
--
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: Lars Noschinski @ 2008-07-30 16:34 UTC (permalink / raw)
To: Avery Pennarun
Cc: Santi Béjar, H.Merijn Brand, Miklos Vajna, Lars Noschinski,
git
In-Reply-To: <32541b130807300858r152d7428j404eaefc04f606@mail.gmail.com>
* Avery Pennarun <apenwarr@gmail.com> [08-07-30 18:26]:
>On Wed, Jul 30, 2008 at 11:23 AM, Santi Béjar <sbejar@gmail.com> wrote:
>> It cannot be described because there is no annotated tag before this
>> commit. Add --always to show the abbreviated commit as fallback.
>
>Or --tags to include non-annotated tags.
For the intended use case, --contains; as the OP wants to know the
oldest version, which contains this commit.
^ permalink raw reply
* Re: Gitweb: Provide Git links in project list?
From: Boyd Lynn Gerber @ 2008-07-30 16:41 UTC (permalink / raw)
To: J.H.; +Cc: Robert Richter, git
In-Reply-To: <1217432970.2884.8.camel@localhost.localdomain>
On Wed, 30 Jul 2008, J.H. wrote:
> 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.
I would like to see the patch. I think it would be good to get it
included.
Thanks,
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ 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