* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Ian Hilt @ 2008-11-10 18:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Francis Galiegue, Git Mailing List, Pierre Habouzit
In-Reply-To: <7vbpwo88gh.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1517 bytes --]
On Mon, 10 Nov 2008, Junio C Hamano wrote:
> Ian Hilt <ian.hilt@gmx.com> writes:
>
> > On Sun, 9 Nov 2008, Junio C Hamano wrote:
> >> Ian Hilt <ian.hilt@gmx.com> writes:
> >>
> >> > On Sun, 9 Nov 2008, Francis Galiegue wrote:
> >> >> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
> >> >> > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
> >> >>
> >> >> Greedy operators are only supported with perl 5.10 or more... I think it's a
> >> >> bad idea to use them...
> >> ...
> >> You expect something non-blank there anyway, so why not do:
> >>
> >> To:\s*(\S.*?)\s*\n....
> >
> > That works. Although, I seem to be missing Francis' point. According
> > to perlre, a quantified subpattern is "greedy". So a "greedy operator"
> > is any one of the standard quantified subpatterns. The "+" and "?"
> > modify its matching behavior. And it seems to me that it _has_ to use a
> > q.s. to work ...
>
> The "perlre" documentation you are reading is from Perl 5.10.0; check
> "perldelta" documentation next to it.
>
> I think you are wrong in saying that "it _has_ to use". Yes, you _can_
> use possessive quantifiers to write that pattern (provided if you can
> limit your users to Perl 5.10.0 or later), but you do _not_ have to (and I
> just showed you how). By not using the new feature, you can make it work
> for people with older version of Perl.
Right. I was saying it has to use quantifiers, in general, not that it
has to use possessive quantifiers.
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Francis Galiegue @ 2008-11-10 18:11 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <200811101759.03864.robin.rosenberg@dewire.com>
Le Monday 10 November 2008 17:59:03 Robin Rosenberg, vous avez écrit :
[Sorry if this is offtopic for the git mailing list...]
> >
> > 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.
>
Well, AFAICT, here is how the current git code detects whether a file is
binary or not:
----
#define FIRST_FEW_BYTES 8000
int buffer_is_binary(const char *ptr, unsigned long size)
{
if (FIRST_FEW_BYTES < size)
size = FIRST_FEW_BYTES;
return !!memchr(ptr, 0, size);
}
----
Easy enough to be coded in Java, hey, even I could do it :p
So, provided binary files are dealt with already, what penalty is left for
Java to deal with?
--
fge
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Jeff King @ 2008-11-10 18:10 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0811100720n52ac1d47id9b7f402412aa0d3@mail.gmail.com>
On Mon, Nov 10, 2008 at 04:20:51PM +0100, Santi Béjar wrote:
> 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
Sorry, I don't quite understand what the problem is. From reading your
subject line, I expected that "git commit -v" would show the diff in
your editor, but then accidentally also include it in the final commit
message. But I can't seem to reproduce that.
Can you describe the problem in more detail?
-Peff
^ permalink raw reply
* Re: [PATCH (GITK) v3 6/6] gitk: Explicitly position popup windows.
From: Alex Riesen @ 2008-11-09 10:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Paul Mackerras, Alexander Gavrilov, git
In-Reply-To: <49146EC0.4050006@viscovery.net>
Johannes Sixt, Fri, Nov 07, 2008 17:37:20 +0100:
> Alex Riesen schrieb:
> > 2008/11/7 Paul Mackerras <paulus@samba.org>:
> >> Is there any reason to call tk::PlaceWindow under Linux or MacOS?
> >> If not I'd rather add an if statement so we only call it on Windows.
> >>
> >
> > Yes, please. I rather like the smart placement in compiz.
>
> Just out of curiosity because I don't use compiz: Did you mean
> "Yes, please call tk::PlaceWindow on Linux"
> or
> "Yes, please add the if statement"
That one. So PlaceWindow is NOT called.
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Alex Riesen @ 2008-11-09 10:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Miles Bader, git
In-Reply-To: <alpine.LFD.2.00.0811071004170.3468@nehalem.linux-foundation.org>
Linus Torvalds, Fri, Nov 07, 2008 19:08:36 +0100:
> On Fri, 7 Nov 2008, Alex Riesen wrote:
> >
> > Does not work if there are ranges given :-/
> > It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6
>
> Yeah, we've very fundamentally never supported that. Not for show, but
> also not for anything else (ie "gitk a..b c..d" does _not_ give you two
> ranges).
>
> It's easy to see why once you understand what 'a..b' really means (ie it
> just expands to '^a' and 'b'), and how it's not really a "range" operation
> as much as a set operation that interacts with all the other arguments
> too. But unless you're very aware of that, it can be surprising.
>
Oh, I am. But it is just so convenient to have range support for
commands which just show commits. Besides, git-show just errors out,
instead of producing the commits like git-log does.
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Jakub Narebski @ 2008-11-10 18:03 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: git
In-Reply-To: <8763mvlbwb.fsf@erwin.mina86.com>
Dnia poniedziałek 10. listopada 2008 18:38, Michal Nazarewicz napisał:
> 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.
Well, in that case using `ident` attribute would be enough
(but cryptic).
# set `ident` attribute for all files
$ echo '* ident' > .gitattributes
# check that it is set for file 'foo'
$ git check-attr ident -- foo
foo: ident: set
# edit file to contain '$Id$' keyword
$ cat foo
...
... $Id$ ...
...
# make a commit
$ git commit -a
# $Id$ keyword is replaced on checkout
$ git add foo
$ git checkout foo
# and check that it got replaced
$ cat foo
...
... $Id: 0ca1524d4460ba6bc91bf3adc9dab13212599243 $ ...
...
But you need git to make use of this SHA-1 _blob_ (contents) identifier
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Install issues
From: Miklos Vajna @ 2008-11-10 17:51 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20081110173101.3d76613b@pc09.procura.nl>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Mon, Nov 10, 2008 at 05:31:01PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
> --- 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
Please read Documentation/SubmittingPatches, your patch lacks a signoff
and a commit message.
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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
* 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: 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
* 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: 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: 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: 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: 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: 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
* 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
* 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
* 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
* 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: [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: [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: 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) 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: [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
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