* Re: RCS keyword expansion
From: Jan Hudec @ 2007-10-12 12:57 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0710121144001.3682@ds9.cixit.se>
[-- Attachment #1: Type: text/plain, Size: 3068 bytes --]
On Fri, Oct 12, 2007 at 11:50:51 +0100, Peter Karlsson wrote:
> > But don't you see? When switching branches, this totally breaks down.
>
> Why would it? If the file is the same on both branches, nothing would
> happen (it is still the same version), and if the file is different, it
> gets changed anyway, and a new keyword expansion would take place.
It does not -- the blob ID is the same. And you can indeed get $Id$ expanded
to that (see gitattributes(5)). However, that's the ONLY thing that is the
same. The date of last modification or ID of commit that last touched that
file might not.
Why? Because git tracks content, not history. The trees and blobs (files) are
identified by SHA1 hashes of their content. Only commit objects add the
notion of history. Thus if two commits contain file with the same text, it's
the same file. Even if the file is the same in those commit purely by
accident.
> > No, really, IMHO it is enough to show either the commit name or the
> > blob name of the file. After all, you are not interested in the date
> > that this file was last committed, but in the _contents_.
>
> Yes, but I want it on the lowest addressable unit size, i.e on the file
> level (I could possibly want to have the last commit for a set of files
> when I have something that get generated from several sources, but that
> is rare for a regular website, unless since javascripts and stylesheets
> etc. are delivered separately).
>
> Already today when you do "git log" on a file, you get the log filtered
> for only changes to that file. So the mechanisms seem already to be
> there, I just need to figure out how to apply them to what I want.
Yes. But you need the (current) commit for that. Now if a file foo is the
same on branches A and B, switching between them will not touch that file,
but git log foo may well give you completely different results. That's why
there's no date or commit that last touched a file.
> > So why not go for the contents? With CVS/SVN you only have the
> > chance to do that by date or version number. With git, we have a more
> > powerful way: we do it by a hash of the contents.
>
> Yes, but the hash if of "everything". I'm not interested in
> "everything" in this context, and I don't want to have a separate git
> repository for each file...
>
> > If it's not what you want, I suggest rethinking what you want ;-)
> > Otherwise it is scripting time for you. It's easy enough with git.
>
> That's what I'm trying to figure out. I assume it would be possible to
> do with some kind of hook that is run on checkout. But I can't figure
> out how to do that.
If you read the (already mentioned) gitattributes(5) manpage, you'll find
description of smudge and clean filters. They will be applied to each file
written out to the tree and read back respectively. But be sure to understand
why you can't -- for principial, not techical reasons -- have the date or
commit ID expanded correctly in all cases.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: Johannes Schindelin @ 2007-10-12 12:51 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Sixt, Jonathan del Strother, git, Junio C Hamano
In-Reply-To: <A7970E82-92E0-4267-AF79-D4ABDB21F0D0@wincent.com>
Hi,
On Fri, 12 Oct 2007, Wincent Colaiuta wrote:
> El 12/10/2007, a las 13:37, Johannes Schindelin escribi?:
>
> > On Fri, 12 Oct 2007, Wincent Colaiuta wrote:
> >
> > > El 11/10/2007, a las 22:53, David Kastrup escribi?:
> > >
> > > > Johannes Sixt <j.sixt@viscovery.net> writes:
> > > >
> > > > > Jonathan del Strother schrieb:
> > > > > > How are you going to test that git works on paths with spaces if
> > > > > > the
> > > > > > test suite doesn't run there?
> > > > >
> > > > > By writing a specific test?
> > > >
> > > > This is going to be much less thorough. And it does no harm if the
> > > > test scripts demonstrate defensive programming.
> > >
> > > +1: especially in this case, where it really is "defensive" and not
> > > "paranoiac".
> >
> > I am all for it, _iff_ the guilty parties (and by that, I mean _you_) do
> > it and keep maintaining it. See? Discussion closed already.
>
> How am *I* the guilty party? I'm merely endorsing David's comment that a
> modicum of defensive programming isn't a bad thing; an eminently
> reasonable position which is somewhat difficult to argue against.
All I'm saying: let patches speak. Talk is cheap.
Ciao,
Dscho
^ permalink raw reply
* Workflow: split repository?
From: Jan Wielemaker @ 2007-10-12 12:21 UTC (permalink / raw)
To: Git Mailing List
Hi,
I've got a big active project, until yesterday managed using CVS. As
with any distributed academic research project the repository has become
a nice mess where most files are in the wrong place and there are
several almost independent sub-projects living in directories.
The plan is/was to
* Convert everything to GIT (done, through cvs2svn)
* Everyone keeps hacking on their bits, while one is starting
to reorganise the structure by moving files and directories
and changing import headers, and other file references in
a GIT branch.
* Now we merge the continued work and the reorganisation to
end up with a nice clean hierarchy :-)
* Split the big project into multiple projects. One of the
reasons is that we want to make part of them public. Others
we cannot publish as they contain copyrighted data. I understand
we can reunite them using GIT sub modules.
Does this make sense?
While splitting we want to *loose* history information for some of the
projects. That is easy: simply create a new repository from the current
files. For some however we would like to *preserve* the history. This
means we would like to pick a hierarchy with its history. After quite
a bit of reading, I get the impression this cannot be done. Am I right?
Is the only way to create a GIT repositiory right away from a subset of
the CVS for which we want to preserve the history?
Thanks --- Jan
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: Wincent Colaiuta @ 2007-10-12 12:20 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Jonathan del Strother, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0710121235230.25221@racer.site>
El 12/10/2007, a las 13:37, Johannes Schindelin escribió:
> On Fri, 12 Oct 2007, Wincent Colaiuta wrote:
>
>> El 11/10/2007, a las 22:53, David Kastrup escribió:
>>
>>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>>
>>>> Jonathan del Strother schrieb:
>>>>> How are you going to test that git works on paths with spaces
>>>>> if the
>>>>> test suite doesn't run there?
>>>>
>>>> By writing a specific test?
>>>
>>> This is going to be much less thorough. And it does no harm if the
>>> test scripts demonstrate defensive programming.
>>
>> +1: especially in this case, where it really is "defensive" and not
>> "paranoiac".
>
> I am all for it, _iff_ the guilty parties (and by that, I mean
> _you_) do
> it and keep maintaining it. See? Discussion closed already.
How am *I* the guilty party? I'm merely endorsing David's comment
that a modicum of defensive programming isn't a bad thing; an
eminently reasonable position which is somewhat difficult to argue
against.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH amend] git-config: handle --file option with relative pathname properly
From: Johannes Schindelin @ 2007-10-12 12:08 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <20071012113251.29941.qmail@7584201f340355.315fe32.mid.smarden.org>
Hi,
On Fri, 12 Oct 2007, Gerrit Pape wrote:
> - setup_git_directory_gently(&nongit);
> + const char *file = setup_git_directory_gently(&nongit);
One last nit (because I did not see it earlier): please call the variable
"prefix", not "file".
Other than that, I think your patch is obviously correct.
Thanks,
Dscho
^ permalink raw reply
* Re: push fails with unexpected 'matches more than one'
From: Steffen Prohaska @ 2007-10-12 12:06 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <11921723791817-git-send-email-prohaska@zib.de>
On Oct 12, 2007, at 8:59 AM, Steffen Prohaska wrote:
> This adds a test case for unambigous local match but multiple remote
> matches. To me, it is unexpected that a ref that is perfectly defined
> on the local side fails with 'matches more than one'.
>
> The following rule could solve this:
> A ref shall first be unambigously resolved on the local side, and its
> full name should be used for matching on the remote side.
> For example 'frotz' resolves locally to 'heads/refs/frotz'.
> Therefore pretend the user had typed 'heads/refs/frotz'.
>
> But maybe there is some hidden secret about the current rules that
> I do not see.
Here is a related question:
I read carefully through the documentation of git-send-pack and
git-rev-parse. The current implementation of git-send-pack is in line
with the documented behaviour, as is the implementation of git-rev-
parse.
So formally everything is correct.
But it is completely against my expectation that git-push <remote>
<head>
can successfully resolve a <head> that git-rev-parse fails to parse. I
understand that refs are not revs ;). But nonetheless, I'd expect that a
local ref that cannot be parsed by git-rev-parse should also fail to be
pushed by git-send-pack. I didn't expect that git-send-pack would locate
<head> as someprefix/<head>.
Why is my expectation wrong?
Or is the current specification of git-send-pack's ref parsing wrong?
Steffen
^ permalink raw reply
* Re: [PATCH amend] git-config: print error message if the config file cannot be read
From: Johannes Sixt @ 2007-10-12 11:59 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20071012114057.30803.qmail@12f4c67b8560e2.315fe32.mid.smarden.org>
Gerrit Pape schrieb:
>> You probably want to see an error message *only* if you have supplied
>> a file name with --file.
>
> I changed the patch to die() only if --file was sepcified, and errno is
> not 0.
Thanks. I can live with that. ;)
-- Hannes
^ permalink raw reply
* [PATCH amend] git-config: print error message if the config file cannot be read
From: Gerrit Pape @ 2007-10-12 11:40 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <470B8286.5060006@viscovery.net>
Instead of simply exiting with 255, print an error message including
the reason why a config file specified through --file cannot be opened
or read.
The problem was noticed by Joey Hess, reported through
http://bugs.debian.org/445208
---
On Tue, Oct 09, 2007 at 02:16:41PM +0100, Johannes Schindelin wrote:
> On Tue, 9 Oct 2007, Gerrit Pape wrote:
> > + if (git_config(show_all_config) == -1)
> I'd rather check for < 0, just for future proofing.
Okay.
On Tue, Oct 09, 2007 at 03:30:46PM +0200, Johannes Sixt wrote:
> Gerrit Pape schrieb:
> >+ if (show_all) {
> >+ if (git_config(show_all_config) == -1)
> >+ die("unable to read config file %s: %s",
> >+ getenv(CONFIG_ENVIRONMENT), strerror(errno));
> I don't think that this works well: If there are no config files at
> all, then we don't want to see an error - just as if the config file
> were empty.
>
> Also, I don't think that errno is reliable at this point.
>
> You probably want to see an error message *only* if you have supplied
> a file name with --file.
I changed the patch to die() only if --file was sepcified, and errno is
not 0.
Thanks, Gerrit.
builtin-config.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index 4444d52..e5bf791 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -172,8 +172,12 @@ int cmd_config(int argc, const char **argv, const char *prefix)
type = T_INT;
else if (!strcmp(argv[1], "--bool"))
type = T_BOOL;
- else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
- return git_config(show_all_config);
+ else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l")) {
+ if (git_config(show_all_config) < 0 && file && errno)
+ die("unable to read config file %s: %s", file,
+ strerror(errno));
+ return 0;
+ }
else if (!strcmp(argv[1], "--global")) {
char *home = getenv("HOME");
if (home) {
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] Fixing path quoting issues
From: Johannes Schindelin @ 2007-10-12 11:37 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Sixt, Jonathan del Strother, git, Junio C Hamano
In-Reply-To: <E43846E3-4F42-4B3A-BA5F-1A21FE70C3FB@wincent.com>
Hi,
On Fri, 12 Oct 2007, Wincent Colaiuta wrote:
> El 11/10/2007, a las 22:53, David Kastrup escribi?:
>
> > Johannes Sixt <j.sixt@viscovery.net> writes:
> >
> > > Jonathan del Strother schrieb:
> > > > How are you going to test that git works on paths with spaces if the
> > > > test suite doesn't run there?
> > >
> > > By writing a specific test?
> >
> > This is going to be much less thorough. And it does no harm if the
> > test scripts demonstrate defensive programming.
>
> +1: especially in this case, where it really is "defensive" and not
> "paranoiac".
I am all for it, _iff_ the guilty parties (and by that, I mean _you_) do
it and keep maintaining it. See? Discussion closed already.
Ciao,
Dscho
^ permalink raw reply
* [PATCH drop] git-config: respect other options after -l, most notably --file
From: Gerrit Pape @ 2007-10-12 11:37 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Junio C Hamano, git
In-Reply-To: <20071009224943.GH31659@planck.djpig.de>
On Wed, Oct 10, 2007 at 12:49:43AM +0200, Frank Lichtenheld wrote:
> On Tue, Oct 09, 2007 at 12:50:24PM +0000, Gerrit Pape wrote:
> > When git-commit is seeing the -l|--list option, it stops reading the
> > following command line options. So although they should be the same,
> > the following commands act differently:
> >
> > git config --file ../repo2/.git/config -l
> > git config -l --file ../repo2/.git/config
> >
> > This patch delays the 'list all variables' to after the command line
> > options have been processed.
>
> Note that I have posted a conflicting patch for the same problem some
> days ago. I think my patch is more consistent with the behaviour for
> other options.
Fair enough. Regards, Gerrit.
^ permalink raw reply
* Re: RCS keyword expansion
From: Johannes Schindelin @ 2007-10-12 11:34 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710121144001.3682@ds9.cixit.se>
Hi,
On Fri, 12 Oct 2007, Peter Karlsson wrote:
> > But don't you see? When switching branches, this totally breaks down.
>
> Why would it? If the file is the same on both branches, nothing would
> happen (it is still the same version), and if the file is different, it
> gets changed anyway, and a new keyword expansion would take place.
Finding out which commit last changed that file is slow. That's why it
breaks down. It is possible, yes. But then I think that you really do
not want this. You are just to used to CVS/SVN to see that there is a
much better way in git.
> > No, really, IMHO it is enough to show either the commit name or the
> > blob name of the file. After all, you are not interested in the date
> > that this file was last committed, but in the _contents_.
>
> Yes, but I want it on the lowest addressable unit size, i.e on the file
> level (I could possibly want to have the last commit for a set of files
> when I have something that get generated from several sources, but that
> is rare for a regular website, unless since javascripts and stylesheets
> etc. are delivered separately).
The lowest addressable unit size is the file level, alright. And $Id$
contains the blob name. IOW it contains a key to retrieve the contents of
exactly this version of the file.
Ciao,
Dscho
^ permalink raw reply
* [PATCH amend] git-config: handle --file option with relative pathname properly
From: Gerrit Pape @ 2007-10-12 11:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <470B8024.2050106@viscovery.net>
When calling git-config not from the top level directory of a repository,
it changes directory before trying to open the config file specified
through the --file option, which then fails if the config file was
specified by a relative pathname. This patch adjusts the pathname to
the config file if applicable.
The problem was noticed by Joey Hess, reported through
http://bugs.debian.org/445208
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
On Tue, Oct 09, 2007 at 03:20:36PM +0200, Johannes Sixt wrote:
> Gerrit Pape schrieb:
> >- setenv(CONFIG_ENVIRONMENT, argv[2], 1);
> >+ if (argv[2][0] == '/')
>
> Please use is_absolute_path() here.
Okay.
> >+ name = argv[2];
> >+ else
> >+ name = name ? prefix_filename(name,
> >strlen(name), argv[2]) : argv[2];
>
> Can't you avoid this ternary here? There's already an 'if' with the same
> 'else' branch.
Sure, thanks, Gerrit.
builtin-config.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index 0a605e0..4444d52 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -165,7 +165,7 @@ int cmd_config(int argc, const char **argv, const char *prefix)
{
int nongit = 0;
char* value;
- setup_git_directory_gently(&nongit);
+ const char *file = setup_git_directory_gently(&nongit);
while (1 < argc) {
if (!strcmp(argv[1], "--int"))
@@ -189,7 +189,12 @@ int cmd_config(int argc, const char **argv, const char *prefix)
else if (!strcmp(argv[1], "--file") || !strcmp(argv[1], "-f")) {
if (argc < 3)
usage(git_config_set_usage);
- setenv(CONFIG_ENVIRONMENT, argv[2], 1);
+ if (!is_absolute_path(argv[2]) && file)
+ file = prefix_filename(file, strlen(file),
+ argv[2]);
+ else
+ file = argv[2];
+ setenv(CONFIG_ENVIRONMENT, file, 1);
argc--;
argv++;
}
--
1.5.3.4
^ permalink raw reply related
* Re: RCS keyword expansion
From: Lars Hjemli @ 2007-10-12 11:21 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0710121144001.3682@ds9.cixit.se>
On 10/12/07, Peter Karlsson <peter@softwolves.pp.se> wrote:
> Johannes said:
> > So why not go for the contents? With CVS/SVN you only have the
> > chance to do that by date or version number. With git, we have a more
> > powerful way: we do it by a hash of the contents.
>
> Yes, but the hash if of "everything". I'm not interested in
> "everything" in this context, and I don't want to have a separate git
> repository for each file...
Try this:
$ echo 'File revision $Id$' > index.html
$ echo "*.html ident" > .gitattributes
$ git add index.html .gitattributes
$ git commit
>From now on, the '$Id' in index.html gets expanded to the SHA1 of the
content of index.html (not the commit SHA1) each time you checkout
(and removed when you commit)
If you still want 'last modified date', the closest thing in git is
'commit date' which you can also get for free:
$ echo 'Last commit: $Format:%cd$' > index.html
$ echo "*.html export-subst" > .gitattributes
$ git add index.html .gitattributes
$ git commit
$ git archive --prefix=test/ HEAD | tar -x
$ cat test/index.html
For all supported keywords, take a look at the 'git-log --pretty=format' option
--
larsh
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: Wincent Colaiuta @ 2007-10-12 11:17 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Sixt, Jonathan del Strother, git, Junio C Hamano
In-Reply-To: <85k5pts796.fsf@lola.goethe.zz>
El 11/10/2007, a las 22:53, David Kastrup escribió:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Jonathan del Strother schrieb:
>>> How are you going to test that git works on paths with spaces if the
>>> test suite doesn't run there?
>>
>> By writing a specific test?
>
> This is going to be much less thorough. And it does no harm if the
> test scripts demonstrate defensive programming.
+1: especially in this case, where it really is "defensive" and not
"paranoiac".
Cheers,
Wincent
^ permalink raw reply
* Re: [RFC] git-gui window layout
From: Adam Piatyszek @ 2007-10-12 10:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <470F45D6.6050106@viscovery.net>
* Johannes Sixt [2007-10-12 12:00]:
> Adam Piatyszek schrieb:
>> I would like you to comment on my idea to change, or at least add a
>> possibility to change, the current layout of git-gui window.
>> [...]
>>
>> +-------------+----------------------------+---+
>> | | |###|
>> | | commit log |###|
>> | staged +----------------------------+---+
>> | | |
>> | | |
>> +----- 1 -----+ |
>> | | diff output |
>> | 2 |
>> | unstaged | |
>> | | |
>> | | |
>> +-------------+--------------------------------+
>
> May I point you to
> http://repo.or.cz/w/git-gui.git?a=commitdiff;h=a0592d3f5746b41c60fee71dd8d2d27b5c813907
>
> which was committed 5 hours ago.
>
> Except that it has Unstaged above Staged and Diff above Commit, which
> IMHO is much more natural.
Thanks for the info! It seems that I was a bit late with my proposal. ;-)
/Adam
--
.:. Adam Piatyszek - "ediap" .:. JID: ediap(at)jabber.org .:.
.:. ediap(at)users.sourceforge.net .:. PGP key ID: 0x1F115CCB .:.
^ permalink raw reply
* Re: RCS keyword expansion
From: Johannes Sixt @ 2007-10-12 11:05 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0710121144001.3682@ds9.cixit.se>
Peter Karlsson schrieb:
>> If it's not what you want, I suggest rethinking what you want ;-)
>> Otherwise it is scripting time for you. It's easy enough with git.
>
> That's what I'm trying to figure out. I assume it would be possible to
> do with some kind of hook that is run on checkout. But I can't figure
> out how to do that.
Read about the 'filter' attribute (clean and smudge filters), e.g. here:
http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
This is the place to tie a script to checkouts. How the scripts derive the
information that they put in the checked-out files, is a different matter.
-- Hannes
^ permalink raw reply
* Re: RCS keyword expansion
From: Peter Karlsson @ 2007-10-12 10:50 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0710121057540.25221@racer.site>
Hi!
> please do not play games with the To: header. We have a policy here
> (which is supposed to be good netiquette) that we keep people in the Cc:
> list that we respond to.
Sorry, didn't mean to do anything. I try to avoid Cc'ing people that
are on the mailing list, and apparently strange things happened that
kept the mailing list only as Cc. I'll try to remember setting To:
properly.
Back on-topic:
> But don't you see? When switching branches, this totally breaks down.
Why would it? If the file is the same on both branches, nothing would
happen (it is still the same version), and if the file is different, it
gets changed anyway, and a new keyword expansion would take place.
> No, really, IMHO it is enough to show either the commit name or the
> blob name of the file. After all, you are not interested in the date
> that this file was last committed, but in the _contents_.
Yes, but I want it on the lowest addressable unit size, i.e on the file
level (I could possibly want to have the last commit for a set of files
when I have something that get generated from several sources, but that
is rare for a regular website, unless since javascripts and stylesheets
etc. are delivered separately).
Already today when you do "git log" on a file, you get the log filtered
for only changes to that file. So the mechanisms seem already to be
there, I just need to figure out how to apply them to what I want.
> So why not go for the contents? With CVS/SVN you only have the
> chance to do that by date or version number. With git, we have a more
> powerful way: we do it by a hash of the contents.
Yes, but the hash if of "everything". I'm not interested in
"everything" in this context, and I don't want to have a separate git
repository for each file...
> If it's not what you want, I suggest rethinking what you want ;-)
> Otherwise it is scripting time for you. It's easy enough with git.
That's what I'm trying to figure out. I assume it would be possible to
do with some kind of hook that is run on checkout. But I can't figure
out how to do that.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Johannes Schindelin @ 2007-10-12 10:05 UTC (permalink / raw)
To: Simon Sasburg; +Cc: Thomas Harning Jr., git
In-Reply-To: <981e6de60710120027j5f390a9tbe2a4c76db9ed06d@mail.gmail.com>
Hi,
On Fri, 12 Oct 2007, Simon Sasburg wrote:
> On 10/11/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > We did not even find a way to post patches via gmail's web interface,
> > not without severely damaging the patches.
>
> Oh? Turning off Rich formatting and copy/pasting the patch from my
> editor worked for me.
Really? Even a single space on a single line is retained (last time I
checked that did not work)? If so, please amend
Documentation/SubmittingPatches.
Ciao,
Dscho
^ permalink raw reply
* Re: RCS keyword expansion
From: Johannes Schindelin @ 2007-10-12 10:02 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0710120723480.11771@perkele.intern.softwolves.pp.se>
Hi Peter,
please do not play games with the To: header. We have a policy here
(which is supposed to be good netiquette) that we keep people in the Cc:
list that we respond to.
On Fri, 12 Oct 2007, Peter Karlsson wrote:
> Johannes Schindelin:
>
> > The problem is this: for efficiency, git does not change files which
> > have not changes between the last version checked out (whatever that
> > is) and the current version.
> >
> > This seems counterintuitive to people coming from SVN/CVS: they expect
> > _every_ file to be touched when checking out.
>
> No? That would just be strange. Only the files that are actually changed
> should be updated, no others. A $Date$ or $Id$ will show the last
> time/commit that specific file was changed, not the latest global state
> (I guess the fact that most modern VCSs have global state makes this a
> bit more difficult to achieve, in RCS/CVS/PVCS and others the change
> history is local to a file and thus it is trivial to find the large
> change for that particular file).
But don't you see? When switching branches, this totally breaks down.
No, really, IMHO it is enough to show either the commit name or the blob
name of the file. After all, you are not interested in the date that this
file was last committed, but in the _contents_.
So why not go for the contents? With CVS/SVN you only have the chance to
do that by date or version number. With git, we have a more powerful way:
we do it by a hash of the contents.
> > As Randal already suggested: if you need something like this, you
> > better have a build procedure which replaced $Date$ _at a given time_
> > (make install) with the current date.
>
> But that's not what I want. Then my build procedure would need to do a
> "git status", or whatever you use to get the last commit information
> about a file, on each file that is changed and is to be installed. It
> would be a lot easier if that was done already on checkout through some
> kind of hook.
If it's not what you want, I suggest rethinking what you want ;-)
Otherwise it is scripting time for you. It's easy enough with git.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git-gui window layout
From: Johannes Sixt @ 2007-10-12 10:00 UTC (permalink / raw)
To: Adam Piatyszek; +Cc: git
In-Reply-To: <470F3516.7020606@users.sourceforge.net>
Adam Piatyszek schrieb:
> Dear Giters,
>
> I would like you to comment on my idea to change, or at least add a
> possibility to change, the current layout of git-gui window.
> [...]
>
> +-------------+----------------------------+---+
> | | |###|
> | | commit log |###|
> | staged +----------------------------+---+
> | | |
> | | |
> +----- 1 -----+ |
> | | diff output |
> | 2 |
> | unstaged | |
> | | |
> | | |
> +-------------+--------------------------------+
May I point you to
http://repo.or.cz/w/git-gui.git?a=commitdiff;h=a0592d3f5746b41c60fee71dd8d2d27b5c813907
which was committed 5 hours ago.
Except that it has Unstaged above Staged and Diff above Commit, which IMHO
is much more natural.
-- Hannes
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Simon Sasburg @ 2007-10-12 9:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Schindelin, Thomas Harning Jr., git
In-Reply-To: <8c5c35580710120126x51c300bfu4345b8c6315d953c@mail.gmail.com>
On 10/12/07, Lars Hjemli <lh@elementstorage.no> wrote:
> On 10/12/07, Simon Sasburg <simon.sasburg@gmail.com> wrote:
> > On 10/11/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > We did not even find a way to post patches via gmail's web interface, not
> > > without severely damaging the patches.
> >
> > Oh? Turning off Rich formatting and copy/pasting the patch from my
> > editor worked for me.
>
> The problem occurs when gmail decides to wrap the lines in the patch
> (max 72 chars per line, I guess).
>
> --
> larsh
>
Ah, good to know, then.
^ permalink raw reply
* git-fast-import crashes
From: Shun Kei Leung @ 2007-10-12 9:42 UTC (permalink / raw)
To: git
Hi all,
I am using git 1.5.3.4.206.g58ba4-dirty on Mac OS X 10.4. When I tried
to run `git-p4 rebase', it failed with a broken pipe to
`git-fast-import'. I gather the following from GDB. I am kind of
stuck. Does anyone have any idea what's going on?
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x64617469
in_window (win=0x5004d0, offset=3501) at sha1_file.c:701
701 off_t win_off = win->offset;
(gdb) bt
#0 in_window (win=0x5004d0, offset=3501) at sha1_file.c:701
#1 0x0000a7b0 in use_pack (p=0x500740, w_cursor=0xbfffd328,
offset=3501, left=0xbfffd2c8) at sha1_file.c:728
#2 0x0000aaa0 in unpack_object_header (p=0x64617461, w_curs=0x0,
curpos=0xbfffd330, sizep=0xbffff4ec) at sha1_file.c:1329
#3 0x0000e17c in unpack_entry (p=0x500740, obj_offset=3501,
type=0xbffff4e8, sizep=0xbffff4ec) at sha1_file.c:1591
#4 0x0000dc8c in read_packed_sha1 (sha1=0x64617461 <Address
0x64617461 out of bounds>, type=0xbffff4e8, size=0xbffff4ec) at
sha1_file.c:1811
#5 0x0000dd90 in read_sha1_file (sha1=0xbffff4f0
")S??=?P\r?6[?w?S[\021\004??", type=0xbffff4e8, size=0xbffff4ec) at
sha1_file.c:1877
#6 0x0000e020 in read_object_with_reference (sha1=0x100950b
")S??=?P\r?6[?w?S[\021\004??", required_type_name=0x0,
size=0xbffff578, actual_sha1_return=0x100950b
")S??=?P\r?6[?w?S[\021\004??") at sha1_file.c:1906
#7 0x0000450c in cmd_from_existing (b=0x10094c0) at fast-import.c:1922
#8 0x00004b3c in cmd_from (b=0x10094c0) at fast-import.c:1965
#9 0x000078a0 in cmd_new_commit () at fast-import.c:2044
#10 0x000088f0 in main (argc=213252, argv=0xbffff838) at fast-import.c:2329
(gdb) print win
$1 = (struct pack_window *) 0x5004d0
(gdb) print *win
$2 = {
next = 0x64617461,
base = 0x20333936 <Address 0x20333936 out of bounds>,
offset = 22523564414626158,
len = 1685026675,
last_used = 795894075,
inuse_cnt = 0
}
Regards,
Kevin Leung
^ permalink raw reply
* [RFC] git-gui window layout
From: Adam Piatyszek @ 2007-10-12 8:49 UTC (permalink / raw)
To: git
Dear Giters,
I would like you to comment on my idea to change, or at least add a
possibility to change, the current layout of git-gui window.
Nowadays there is a tendency to produce wide screens for laptops and
even standalone LCD monitors. One can safely assume that the minimum
reasonable horizontal resolution of a screen is at least 1024 pixels (I
do not expect anyone using git-gui with 800x600 resolution).
Moreover, most popular window managers decreases the vertical dimension
of a desktop by using horizontally-oriented panels (e.g. KDE, Gnome,
XFCE4, etc.)
The current layout of git-gui window covering the whole desktop area on
a typical WXGA (1280x800) laptop LCD display is thus:
+----------+-----------------------------------+
| | |
| staged | unstaged |
| | |
+----------+----------------+------------------+
|### commit log | EMPTY |
|### | |
+---------------------------+------------------+
| |
| diff output |
| |
+----------------------------------------------+
In my opinion, the staged, unstaged and diff areas are usually used for
displaying things that are taller than wider (e.g. a list of files,
patches of well structured code, which is usually < 80 columns). The
commit log window is also designed for text narrower than < 80 cols.
Therefore in my opinion it might be more useful to restructure this
layout to something like this:
+-------------+----------------------------+---+
| | |###|
| | commit log |###|
| staged +----------------------------+---+
| | |
| | |
+----- 1 -----+ |
| | diff output |
| 2 |
| unstaged | |
| | |
| | |
+-------------+--------------------------------+
Buttons (rescan, push, commit, etc.) are denoted here as ###. Besides
the walls denoted as 1 and 2 should be movable so one could adjust the
size of staged/unstaged and diff areas.
The minimum width of diff window would be limited by the commit log
window width (I propose 80 colums) plus the size of the buttons.
Unfortunately, I do not nothing about TCL/TK programming, so I even did
not tried to analyse the code of git-gui. Therefore I am not sure if
such a restructure is easy to implement.
Anyway I hope for your comments to this idea.
BR,
/Adam
--
.:. Adam Piatyszek - "ediap" .:. JID: ediap(at)jabber.org .:.
.:. ediap(at)users.sourceforge.net .:. PGP key ID: 0x1F115CCB .:.
^ permalink raw reply
* Re: Status of kha/experimental
From: Catalin Marinas @ 2007-10-12 8:56 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Yann Dirson, David Kågedal, Git Mailing List
In-Reply-To: <20071012074323.GB17403@diana.vm.bytemark.co.uk>
On 12/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-10-11 21:38:12 +0100, Catalin Marinas wrote:
>
> > I'll try - let's say we freeze it starting with the coming Monday
> > (what's currently in kha/safe will be merged anyway) and aim to
> > release 0.14 in about 3 weeks (or as soon as we fix the major bugs).
>
> Do you have a list of the bugs you'd like to see fixed before the
> release? (I don't, I'm not organized. :-) )
https://gna.org/bugs/?group=stgit. All of them, if possible :-). If
you happen to work on any of them, change the "assigned to" filed so
that we don't duplicate the effort.
--
Catalin
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Lars Hjemli @ 2007-10-12 8:26 UTC (permalink / raw)
To: Simon Sasburg; +Cc: Johannes Schindelin, Thomas Harning Jr., git
In-Reply-To: <981e6de60710120027j5f390a9tbe2a4c76db9ed06d@mail.gmail.com>
On 10/12/07, Simon Sasburg <simon.sasburg@gmail.com> wrote:
> On 10/11/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > We did not even find a way to post patches via gmail's web interface, not
> > without severely damaging the patches.
>
> Oh? Turning off Rich formatting and copy/pasting the patch from my
> editor worked for me.
The problem occurs when gmail decides to wrap the lines in the patch
(max 72 chars per line, I guess).
--
larsh
^ 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