* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Piotr Findeisen @ 2008-11-10 10:14 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20081110100757.GA12868@diku.dk>
>
>> I noticed that all substitutions "--" -> "—", where "—" is a part of
>> sentence punctuation, match \w--\w pattern (e.g. no spaces on both
>> sides) and probably this is how it should be written in English. But
>> basing on this doesn't seem to me to be fool proof.
>
> So another option is to disable all substitution of "--" and just use
> the "—" character when it is explicitly needed. The documentation is
> using UTF-8 after all. This would also fix the usage of "--" in the
> manpages, e.g.
>
> You've now initialized the working directory--you may notice ...
>
> in gittutorial(7). On my setup, with "--" replaced with "—", I get the
> following nroff code:
On my machine, make gittutorial.7 produces manpage that displays "--"
in this place :)
>
> You've now initialized the working directory\(emyou may notice
Anyway, this may be a good idea to use unambiguous "—" (though people
writing docs may be used to using "--" as a punctuation). I can run
through the Documentation replacing "\w--\w" with m-dash, if you want.
Regards,
Piotr
^ permalink raw reply
* Re: StGit: stgit mail configuration options
From: Karl Hasselström @ 2008-11-10 10:19 UTC (permalink / raw)
To: David Kågedal; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <871vxptasf.fsf@krank.kagedal.org>
On 2008-11-06 11:21:20 +0100, David Kågedal wrote:
> The "stg mail" command uses a couple of configuration options that
> are completely undocumented, and don't fit well together.
I agree that they definitely need documenting.
As for renaming them and/or changing their types, that's probably a
good idea too. And once they are documented, we could e.g. rename and
only mention the new name in the docs, but keep the old name as well
for backward compatibility.
One interesting twist would be to fix StGit's config parser so that it
can automatically generate a man page listing all the config options
it recognizes. It needs updating anyway for other reasons (I believe
it still calls git-config several times instead of just once), and
this could be done at the same time.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Johannes Schindelin @ 2008-11-10 10:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Symonds, git
In-Reply-To: <200811081631.06229.jnareb@gmail.com>
Hi,
On Sat, 8 Nov 2008, Jakub Narebski wrote:
> On Sat, 8 Nov 2008, David Symonds wrote:
> > On Fri, Nov 7, 2008 at 5:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > > Mon, Oct 27, 2008
> > > -----------------
> > > * Dscho: Contributing with Git
> > > http://www.youtube.com/watch?v=j45cs5_nY2k
> >
> > It was a good intro, but I was expecting a few more non-GitTogether
> > people. We had quite a large room, but there was only about a dozen
> > other people who came along. I don't know whether that was the fault
> > of the timing, lack of advertising, or a lack of interest.
>
> By the way, it would be nice to have transcript for this talk, just
> like there is for Linus talk:
> http://git.or.cz/gitwiki/LinusTalk200705Transcript
> (but this would take some doing).
>
> It would be also nice to have slides for the talk available somewhere,
> just like slides for "Git Chronicle".
Voila:
http://repo.or.cz/w/git/dscho.git?a=blob_plain;f=all-your-rebase.pdf;hb=f23c1c9868256cae8591bddafd64422f95d67b02
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] Document "git log --simplify-by-decoration"
From: Santi Béjar @ 2008-11-10 10:47 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Junio C Hamano
In-Reply-To: <20081110185817.6117@nanako3.lavabit.com>
On Mon, Nov 10, 2008 at 10:58 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
> ---
> Documentation/rev-list-options.txt | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
> index 966276b..977290c 100644
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -456,6 +456,13 @@ Note the major differences in `N` and `P` over '\--full-history':
> removed completely, because it had one parent and is TREESAME.
> --
>
> +The '\--simplify-by-decoration' option can be used to treat commits that
> +are not referenced by tags as TREESAME, and treat commits that are tagged
> +as !TREESAME (even when they have exactly the same tree as their parents).
> +This can be used when you are only interested in the big picture of the
> +topology of the history.
> +
> +
I prefer the other way around, first what it does, and then how it
does it (but it is a general comment about the help in "History
Simplification", at least when viewing the help for "git log"). And
you should rewrite the line 416:
Finally, there is a fourth simplification mode available
as it is no longer "Finally".
Santi
^ permalink raw reply
* Install issues
From: H.Merijn Brand @ 2008-11-10 11:17 UTC (permalink / raw)
To: git
1. OpenSUSE 11.0's yast2 does not have "ignore dependency" anymore in
the gui, which makes installing git from the GIT RPMS to fail as it
seems to depend on openssh-clients, a package that has been
deprecated in SUSE, and is not available anymore
In 10.3 you could still go on after "ignore this dependency
locally", and all worked fine.
So now I have to build from source, or download the rpm and look up the
flags to rpm to make --no-deps work. That feels dirty, so I rather build
Builds fine. Now 'make test', which I often mistype as 'make check'
because the GNU folk refuse to add 'make test' as an alias for 'make
check' and switching between all the sourse distributions that do it
right (perl, git, ...) and those that do it wrong (GNU) I often type
the wrong one
git-1.6.0.4 112 > make check
for i in *.c; do sparse -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -D__BIG_ENDIAN__ -D__powerpc__ $i || exit; done
/bin/sh: sparse: command not found
make: *** [check] Error 127
Maybe the Makefile could be a little more user-friendly with a message
like
"Cannot run 'make check', as you do not have 'sparse' installed.
Did you mean to run 'make test' instead?"
FYI
'/bin/sh' ./aggregate-results.sh test-results/t*-*
fixed 1
success 3726
failed 0
broken 2
total 3729
rm -f -r 'trash directory' test-results
--
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: How it was at GitTogether'08 ?
From: Jakub Narebski @ 2008-11-10 11:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Symonds, git
In-Reply-To: <alpine.DEB.1.00.0811101125360.30769@pacific.mpi-cbg.de>
On Mon, 10 Nov 2008, Johannes Schindelin wrote:
> On Sat, 8 Nov 2008, Jakub Narebski wrote:
>> On Sat, 8 Nov 2008, David Symonds wrote:
>>> On Fri, Nov 7, 2008 at 5:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>>> Mon, Oct 27, 2008
>>>> -----------------
>>>> * Dscho: Contributing with Git
>>>> http://www.youtube.com/watch?v=j45cs5_nY2k
>>>
>>> It was a good intro, but I was expecting a few more non-GitTogether
>>> people. We had quite a large room, but there was only about a dozen
>>> other people who came along. I don't know whether that was the fault
>>> of the timing, lack of advertising, or a lack of interest.
[...]
>> It would be also nice to have slides for the talk available somewhere,
>> just like slides for "Git Chronicle".
>
> Voila:
>
> http://repo.or.cz/w/git/dscho.git?a=blob_plain;f=all-your-rebase.pdf;hb=f23c1c9868256cae8591bddafd64422f95d67b02
Thanks a lot. Added to http://git.or.cz/gitwiki/GitTogether
P.S. I guess GitTogether wiki page should be perhaps rewritten...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Install issues
From: Miklos Vajna @ 2008-11-10 11:39 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20081110121739.15f77a01@pc09.procura.nl>
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
On Mon, Nov 10, 2008 at 12:17:39PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
> git-1.6.0.4 112 > make check
> for i in *.c; do sparse -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -D__BIG_ENDIAN__ -D__powerpc__ $i || exit; done
> /bin/sh: sparse: command not found
> make: *** [check] Error 127
>
> Maybe the Makefile could be a little more user-friendly with a message
> like
>
> "Cannot run 'make check', as you do not have 'sparse' installed.
> Did you mean to run 'make test' instead?"
Care to send a patch?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH (GITK)] gitk: Fix commit encoding support.
From: Paul Mackerras @ 2008-11-10 11:46 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200811091806.07550.angavrilov@gmail.com>
Alexander Gavrilov writes:
> +proc do_readcommit {id} {
> + global tclencoding
> +
> + # Invoke git-log to handle automatic encoding conversion
> + set fd [open [concat | git log --no-color --pretty=raw -1 $id] r]
> + # Read the results using i18n.logoutputencoding
> + fconfigure $fd -translation lf -eofchar {}
> + if {$tclencoding != {}} {
> + fconfigure $fd -encoding $tclencoding
Does this mean there are two conversions going on, one inside git log
and another inside Tcl? Is there a reason why it's better to do two
conversions than one, or is it just more convenient that way?
Would an alternative approach have been to read the output of git
cat-file with -translation binary, look for an encoding header, and do
an encoding convertfrom based on the encoding header? What would be
the disadvantage of such an approach?
Paul.
^ permalink raw reply
* Re: [PATCH (GITK) v3 6/6] gitk: Explicitly position popup windows.
From: Paul Mackerras @ 2008-11-10 11:47 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200811091753.31198.angavrilov@gmail.com>
Alexander Gavrilov writes:
> I don't know about MacOS, but in Linux it does seem unnecessary, so:
OK. Do you mostly develop on windows or on linux?
> + if {$::tcl_platform(platform) ne {windows}} return
Any particular reason why you used $tcl_platform(platform) rather than
if {[tk windowingsystem] != "win32"} like we do elsewhere in gitk?
Paul.
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Johannes Schindelin @ 2008-11-10 12:09 UTC (permalink / raw)
To: Kai Blin; +Cc: Jakub Narebski, David Symonds, git, Tim Ansell
In-Reply-To: <200811101109.02885.kai@samba.org>
Hi,
On Mon, 10 Nov 2008, Kai Blin wrote:
> On Monday 10 November 2008 10:58:05 Johannes Schindelin wrote:
>
> > > Tim was talking about that media/ folder and managing that in git.
> > > If you want to work on the media, you might end up getting hundreds
> > > of gigabytes of data to get that folder, even if you only need to
> > > change one single file.
> > >
> > > That's the issue we're running into, and I don't thing submodules
> > > solve this at all.
> >
> > You'd have to have a single repository for each and every media file,
> > and you'd need to use shallow clones and shallow fetches.
> >
> > However, a push-conflict will probably be beyond any non-programmer
> > skillz.
>
> Ok, I agree. But you could work around that by teaching the artists to
> fetch/rebase/push instead of just pushing, or hiding this in the GUI. If
> there's a conflict on a binary data file you're screwed anyway. :)
A fetch in that case would make the artist download things she does not
need, right? So maybe that is not the way to go.
> > I'd rather propose to have a different interface, like through a web
> > server, where the user can say "I have some cool new graphics, in this
> > .zip file" together with a commit message.
> >
> > Kind of a git-gui via browser.
>
> Incidentally I'm currently working on something like this, just aimed at
> the "artist side", instead of the VCS side. This certainly is a useable
> solution for artists.
Seems like a nice starting point for a git-gui-in-a-browser.
> But at some point a developer will want to check out the repository to
> cut a release tarball, and we're back to wanting shallow and narrow
> clones. :)
Shallow clones are not an issue. They _should_ work.
And for releasing you do not want narrow clones.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH (GITK)] gitk: Fix commit encoding support.
From: Alexander Gavrilov @ 2008-11-10 12:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18712.7942.767651.569321@cargo.ozlabs.ibm.com>
On Mon, Nov 10, 2008 at 2:46 PM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>
>> +proc do_readcommit {id} {
>> + global tclencoding
>> +
>> + # Invoke git-log to handle automatic encoding conversion
>> + set fd [open [concat | git log --no-color --pretty=raw -1 $id] r]
>> + # Read the results using i18n.logoutputencoding
>> + fconfigure $fd -translation lf -eofchar {}
>> + if {$tclencoding != {}} {
>> + fconfigure $fd -encoding $tclencoding
>
> Does this mean there are two conversions going on, one inside git log
> and another inside Tcl? Is there a reason why it's better to do two
> conversions than one, or is it just more convenient that way?
That makes the processing flow uniform with the usual code path.
> Would an alternative approach have been to read the output of git
> cat-file with -translation binary, look for an encoding header, and do
> an encoding convertfrom based on the encoding header? What would be
> the disadvantage of such an approach?
If all commits were loaded through cat-file, that would be the way to
go. Otherwise, when one code path uses one method of conversion, and
another one, which is used rarely and semi-randomly, a different
method, it may lead to confusing results if something goes slightly
wrong.
Alexander
^ permalink raw reply
* Re: [PATCH (GITK) v3 6/6] gitk: Explicitly position popup windows.
From: Alexander Gavrilov @ 2008-11-10 12:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18712.8025.148318.526469@cargo.ozlabs.ibm.com>
On Mon, Nov 10, 2008 at 2:47 PM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>
>> I don't know about MacOS, but in Linux it does seem unnecessary, so:
>
> OK. Do you mostly develop on windows or on linux?
I use Linux at home (using a VirtualBox to compile msysgit when I need
to), and Windows at work.
Actually, since last Thursday I also have to use MacOS at work for
some things, but I haven't figured out anything beyond the bare
minimum yet.
>> + if {$::tcl_platform(platform) ne {windows}} return
>
> Any particular reason why you used $tcl_platform(platform) rather than
> if {[tk windowingsystem] != "win32"} like we do elsewhere in gitk?
No partucular reason, I simply copied that from git-gui.
Alexander.
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Johannes Schindelin @ 2008-11-10 12:25 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: sverre, git
In-Reply-To: <87hc6gjs7v.fsf@erwin.mina86.com>
Hi,
On Mon, 10 Nov 2008, Michal Nazarewicz wrote:
> I would like the "$Id$" sequences to be updated automatically after a
> commit (ie. without the need to check out). (Besides I would prefer
> $Date$ more but I can live with $Id$ I guess ;) ).
No, you don't.
At least most likely you do not want that behavior. Typically, you have
the $Id$ stuff in released versions to indicate what revision that version
came from even if the files are no longer in a Git repository.
And you can have that without ever committing anything in-between, by
using the export-subst attributes with git-archive. Have a look at
Documentation/gitattributes.txt (I agree it is underdocumented in
git-archive.txt).
If that is not your use case, then it may be wise to let us Git people
know what you _actually_ want (i.e. instead of asking for a specific
solution, you could tell us what your problem is).
Ciao,
Dscho
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: dhruva @ 2008-11-10 14:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michal Nazarewicz, sverre, git
In-Reply-To: <alpine.DEB.1.00.0811101319570.30769@pacific.mpi-cbg.de>
Hi,
On Mon, Nov 10, 2008 at 5:55 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> If that is not your use case, then it may be wise to let us Git people
> know what you _actually_ want (i.e. instead of asking for a specific
> solution, you could tell us what your problem is).
Since you have opened this topic to make a request with the problem, I
have a problem for which I need $Id$ expansion.
The git-p4 tool does not record contents in $Id$. When I try to submit
from git to p4 using git-p4, it does a 'p4 sync' which brings in
modified files with $Id$ changes. When git-p4 tries to apply patches,
it would not have recorded the change in $Id$. If there was a
mechanism to make $Id$ change and tracked in git, it would have
recorded a change as a hunk and the patch would have applied cleanly.
I have posted this problem earlier and also on the #git channel. Hope
to see some traction.
with best regards,
dhruva
--
Contents reflect my personal views only!
^ permalink raw reply
* JGIT: discuss: diff/patch implementation
From: Francis Galiegue @ 2008-11-10 14:22 UTC (permalink / raw)
To: Git Mailing List; +Cc: Shawn O. Pearce, Robin Rosenberg
Hello,
A very nice git feature, without even going as far as merges, is the cherry
pick feature.
For this to be doable from within the Eclipse Git plugin, a diff/patch
implementation needs to be found, in a license compatible with the current
JGit license (3-clause BSD, as far as I can tell). Or a new implementation
can be rewritten from scratch, of course.
I found this:
http://code.google.com/p/google-diff-match-patch
Its license is the Apache 2.0 license. It implements the same algorithm than
git's internal diff engine ("An O(ND) Difference Algorithm and its
Variations", by Eugene Myers), and as far as I can tell so far (IANAL, far
from it), it is compatible with JGit's current license.
Could this be a viable candidate?
--
fge
^ permalink raw reply
* git commit -v does not removes the patch
From: Santi Béjar @ 2008-11-10 15:20 UTC (permalink / raw)
To: Git Mailing List, Jeff King
Hi *,
$subject since:
4f672ad (wt-status: load diff ui config, 2008-10-26)
I tried to make a test case, but failed. I think because it is a bit
tricky the fake_editor/stdin/stdout stuff, so at the end I bisected it
by hand
Regards,
Santi
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Michal Nazarewicz @ 2008-11-10 15:48 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0811101319570.30769@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]
> On Mon, 10 Nov 2008, Michal Nazarewicz wrote:
>> I would like the "$Id$" sequences to be updated automatically after a
>> commit (ie. without the need to check out). (Besides I would prefer
>> $Date$ more but I can live with $Id$ I guess ;) ).
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> No, you don't.
>
> At least most likely you do not want that behavior. Typically, you have
> the $Id$ stuff in released versions to indicate what revision that version
> came from even if the files are no longer in a Git repository.
>
> And you can have that without ever committing anything in-between, by
> using the export-subst attributes with git-archive. Have a look at
> Documentation/gitattributes.txt (I agree it is underdocumented in
> git-archive.txt).
The thing is that for some repositories I don't distinguish anything
like a "release version" of files. For instance, I have a repository
with my configuration files, and I want to be able to do
scp emacs system-where-git-is-not-installed:.emacs
or attaching the file in an email without worrying about anything.
Instead, what you're describing would force me to do some voodoo magic
priory to sending the file.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Robin Rosenberg @ 2008-11-10 15:56 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <200811101522.13558.fg@one2team.net>
måndag 10 november 2008 15:22:13 skrev Francis Galiegue:
> Hello,
>
> A very nice git feature, without even going as far as merges, is the cherry
> pick feature.
>
> For this to be doable from within the Eclipse Git plugin, a diff/patch
> implementation needs to be found, in a license compatible with the current
> JGit license (3-clause BSD, as far as I can tell). Or a new implementation
> can be rewritten from scratch, of course.
>
> I found this:
>
> http://code.google.com/p/google-diff-match-patch
>
> Its license is the Apache 2.0 license. It implements the same algorithm than
> git's internal diff engine ("An O(ND) Difference Algorithm and its
> Variations", by Eugene Myers), and as far as I can tell so far (IANAL, far
> from it), it is compatible with JGit's current license.
>
> Could this be a viable candidate?
Our approach was to do just that, for the very reasons you mention.
I'll have a look. Thanks for doing some research for us. That project was
unknown to me..
-- robin
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Francis Galiegue @ 2008-11-10 15:58 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: git
In-Reply-To: <871vxjoa3j.fsf@erwin.mina86.com>
Le Monday 10 November 2008 16:48:48 Michal Nazarewicz, vous avez écrit :
[...]
>
> The thing is that for some repositories I don't distinguish anything
> like a "release version" of files.
"Git tracks contents, not files".
You have two problems here:
* first, unlike CVS, files don't have revisions;
* second, unline SVN (or even Mercurial), commits are not "ordered", at least
not in a natural way (can't tell what SHA1 is more recent).
Git will not track a single file, and I don't think it will ever do so. And
then, what about renames?
You have two options there:
1. (requires git modification, I guess) put a $last_modified_date$ magic that
expands to the last modification date;
2. (what I do) keep an internal ChangeLog for such files, that you (have to)
fill by hand each time.
The second approach has big advantages:
* you can date your changes;
* you _really_ know the file history;
* git's renaming handle allows you to track this ChangeLog over time!
It requires discipline, though...
--
fge
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Jakub Narebski @ 2008-11-10 15:59 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: git
In-Reply-To: <87ljvsjuq7.fsf@erwin.mina86.com>
Michal Nazarewicz <mina86@tlen.pl> writes:
> Hello,
>
> as probably many of you know CVS supported some magic tags which were
> replaced in committed files to a predefined value. For instance, if
> there was a "$Revision$" string in a file it would get replaced with
> "$Revision: x.y $" (or "$Revision: x.y.z.w $" and so on) where "x.y" is
> file's revision number.
>
> Now, what I need is such feature in GIT. Upon committing I would like
> some magic string (say "$Date$") to be replaced with some value
> identifying uniquely given version of a file (a date of the commit would
> be sufficient).
>
> I tried using some hooks for it but couldn't came up with anything that
> would actually work.
Well, there is `ident` attribute which you can set in .gitattributes
file which would make git do $Id$ keyword expansion. However the $Id$
git uses is not something you are familiar with: it is 40-character
hexadecimal blob object name. With it you can find (try to find)
relevant commit.
The reason why git doesn't support keywords like $Revision$ or $Date$
is performance: the $Revision$ and $Date$ are keywords related to
_commit_ data, not blob data. You can have the same contents of the
file in two different branches, thus two different commits, thus two
different $Revision$ or $Date$. If contents of file didn't change
between branches, git doesn't touch the file, which results in much
faster branch switching, for example (and also faster committing).
What you can do is one of the following things:
1. You can try to use either hooks (post-commit, post-update I think)
or smudge / clean filters (via gitattributes) to do keyword
expansion. This hits performance, and you probably would have the
problems CVS ad with keyword expansion.
2. You can use `export-subst` gitattribute and make git-archive do
keyword expansion, which can include things like '$Format:%aD$'
for commit date (equivalent of $Date:$?).
3. You can run some local equivalent of GIT-VERSION-GEN script git
and Linux kernel uses, and make your build system (Makefile)
replace '@@VERSION@@' or '++VERSION++' keywords / placeholders
as part of compiling process.
HTH
--
Jakub Narębski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Francis Galiegue @ 2008-11-10 16:16 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <200811101656.35887.robin.rosenberg@dewire.com>
Le Monday 10 November 2008 16:56:35 Robin Rosenberg, vous avez écrit :
[...]
> >
> > I found this:
> >
> > http://code.google.com/p/google-diff-match-patch
> >
> > Its license is the Apache 2.0 license. It implements the same algorithm
> > than git's internal diff engine ("An O(ND) Difference Algorithm and its
> > Variations", by Eugene Myers), and as far as I can tell so far (IANAL,
> > far from it), it is compatible with JGit's current license.
> >
> > Could this be a viable candidate?
>
> Our approach was to do just that, for the very reasons you mention.
> I'll have a look. Thanks for doing some research for us. That project was
> unknown to me..
>
> -- robin
Well, this API has a problem from the get go, since it does... Char by char
comparison. Ouch.
I'll try and hack it so that it does line by line, but given my Java skills,
uh...
--
fge
^ permalink raw reply
* Re: Install issues
From: H.Merijn Brand @ 2008-11-10 16:31 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20081110113924.GR24201@genesis.frugalware.org>
On Mon, 10 Nov 2008 12:39:24 +0100, Miklos Vajna
<vmiklos@frugalware.org> wrote:
> On Mon, Nov 10, 2008 at 12:17:39PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
> > git-1.6.0.4 112 > make check
> > for i in *.c; do sparse -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -D__BIG_ENDIAN__ -D__powerpc__ $i || exit; done
> > /bin/sh: sparse: command not found
> > make: *** [check] Error 127
> >
> > Maybe the Makefile could be a little more user-friendly with a message
> > like
> >
> > "Cannot run 'make check', as you do not have 'sparse' installed.
> > Did you mean to run 'make test' instead?"
>
> Care to send a patch?
--- Makefile.org 2008-11-10 17:29:53.000000000 +0100
+++ Makefile 2008-11-10 17:29:39.000000000 +0100
@@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
./test-sha1.sh
check: common-cmds.h
+ @`sparse </dev/null 2>/dev/null` || (\
+ echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
+ echo "Did you mean 'make test' instead?" ;\
+ exit 1 )
for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
remove-dashes:
--
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: JGIT: discuss: diff/patch implementation
From: Robin Rosenberg @ 2008-11-10 16:59 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <200811101716.29029.fg@one2team.net>
måndag 10 november 2008 17:16:28 skrev Francis Galiegue:
> Le Monday 10 November 2008 16:56:35 Robin Rosenberg, vous avez écrit :
> [...]
> > >
> > > I found this:
> > >
> > > http://code.google.com/p/google-diff-match-patch
> > >
> > > Its license is the Apache 2.0 license. It implements the same algorithm
> > > than git's internal diff engine ("An O(ND) Difference Algorithm and its
> > > Variations", by Eugene Myers), and as far as I can tell so far (IANAL,
> > > far from it), it is compatible with JGit's current license.
> > >
> > > Could this be a viable candidate?
> >
> > Our approach was to do just that, for the very reasons you mention.
> > I'll have a look. Thanks for doing some research for us. That project was
> > unknown to me..
> >
> > -- robin
>
> Well, this API has a problem from the get go, since it does... Char by char
> comparison. Ouch.
>
> I'll try and hack it so that it does line by line, but given my Java skills,
> uh...
>
We might want a byte-oriented version. Converting to char first is way
too slow.
-- robin
^ permalink raw reply
* Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Thomas Harning @ 2008-11-10 17:37 UTC (permalink / raw)
To: git; +Cc: Jeff King
Just wondering, has there been any looking into whether the git-notes
concept can track rebases?
Reading over what git-notes is leads me to think it could be a good
mechanism for the distributed bug-tracking idea I had some time ago.
The only gotcha I see is that there would have to be some reverse
mapping / fast lookup to track the commit objects that given notes are
attached to.... and to facilitate individual assignment... notes
applied to notes.
Example structure:
Commits A B C D
Notes BUG
Notes nA nC == bug notes
A <- nA
|\
B C <- nC
|/
D
nA <- BUG
nB <- BUG
Operations for bug-tracking:
1) List all 'BUG'-type items that would refer to individual notes
2) List 'BUG' items reachable from a point
Perhaps with criterion that a certain 'bug note' attribute is not
set...
or that a 'BUG_CLOSED' note is not attached to the given 'bug note'
... this seems to be somewhat of an extreme abuse of the notes
system... but I could imagine it may have uses outside...
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Michal Nazarewicz @ 2008-11-10 17:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3iqqvefmo.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]
Jakub Narebski <jnareb@gmail.com> writes:
> The reason why git doesn't support keywords like $Revision$ or $Date$
> is performance: the $Revision$ and $Date$ are keywords related to
> _commit_ data, not blob data.
In my case identifying content not commit would be even better.
> 1. You can try to use either hooks (post-commit, post-update I think)
> or smudge / clean filters (via gitattributes) to do keyword
> expansion. This hits performance, and you probably would have the
> problems CVS ad with keyword expansion.
Earlier in the thread there was following code for a pre-commit hook
mentioned:
#v+
files=$(git diff-index --name-only --diff-filter=AM HEAD)
perl -pi -e 's/\$Id.*?\$/\$Id: '$(TZ=UTC date +%s)' \$/g' $files
git add $files
#v-
Now, this meats all my needs except that (i) it adds all the files that
were modified (ie. makes `git commit` work like `git commit -a`) and
(ii) it modifies files even if the commit was aborted.
So, it seems that, what I need is: (i) a pre-commit-post-message-hook
and (ii) a way to get a list of files that are being committed.
> 2. You can use `export-subst` gitattribute and make git-archive do
> keyword expansion, which can include things like '$Format:%aD$'
> for commit date (equivalent of $Date:$?).
>
> 3. You can run some local equivalent of GIT-VERSION-GEN script git
> and Linux kernel uses, and make your build system (Makefile)
> replace '@@VERSION@@' or '++VERSION++' keywords / placeholders
> as part of compiling process.
That would work but the thing is I'd like to have visioning without the
need of creating releases or doing some other voodoo magic -- simply `scp
file remote:file` or attach to an email.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
[-- Attachment #2: Type: application/pgp-signature, Size: 196 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