* 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: 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: 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: 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: 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: [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: [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: 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
* [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: 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 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: [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 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 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
* 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: 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: [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
* 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: 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
* 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: David Kastrup @ 2007-10-12 13:14 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0710121351200.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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.
The patches spoke. That is what the [PATCH] in the subject line was about.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] add simple install replacement
From: Jan Hudec @ 2007-10-12 14:06 UTC (permalink / raw)
To: Robert Schiele; +Cc: git, gitster
In-Reply-To: <20071011215237.GI20753@schiele.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2881 bytes --]
On Thu, Oct 11, 2007 at 23:52:37 +0200, Robert Schiele wrote:
> This patch adds a very simple install replacement script to git.
> This allows more easy installation on systems that don't have a
> compatible install.
Do you have a particular case where you need it?
> Signed-off-by: Robert Schiele <rschiele@gmail.com>
> ---
> gitinstall | 35 +++++++++++++++++++++++++++++++++++
> 1 files changed, 35 insertions(+), 0 deletions(-)
> create mode 100755 gitinstall
>
> diff --git a/gitinstall b/gitinstall
> new file mode 100755
> index 0000000..8b346d6
> --- /dev/null
> +++ b/gitinstall
> @@ -0,0 +1,35 @@
> +#!/bin/sh
> +
> +MKDIRMODE=0
> +MODE=755
> +while getopts 'dm:' FLAG; do
No such thing here:
zsh$ /bin/sh
$ which getopts
$
Yes, bash and zsh do have that, but my (and I suspect many git users')
/bin/sh is neither of those. Git scripts should use just POSIX shell
features for portability.
Which is particularly important when you are trying to replace a common
utility, because the systems that won't have it are likely to not have bash
either.
You may want to have a look at /usr/share/automake-1.9/install-sh (or
/usr/share/automake<something>/install-sh). It shows how to portably process
options in shell and since it's in fact covered by the MIT/X license (and FSF
changes are public domain), git could just use it if necessary.
> + case "$FLAG" in
> + d) MKDIRMODE=1;;
> + m) MODE="$OPTARG";;
> + *) exit 1;;
> + esac
> +done
> +if test "$OPTIND" != 1; then
> + shift `expr $OPTIND - 1`
> +fi
> +if test $MKDIRMODE = 1; then
> + mkdir -p "$@"
> + chmod "$MODE" "$@"
> +else
> + if test $# = 2 && ! test -d "$2"; then
> + rm -rf "$2"
Are you sure reall install would do this? The maual (install(1)) states
following usage variants:
install [OPTION]... [-T] SOURCE DEST
install [OPTION]... SOURCE... DIRECTORY
install [OPTION]... -t DIRECTORY SOURCE...
install [OPTION]... -d DIRECTORY...
Now however there is nothing saying that SOURCE... is at least two, so is
install git /usr/bin
a case of the first or second usage? I would say the second, but your code
would:
rm -rf /usr/bin
cp git /usr/bin
> + cp "$1" "$2"
> + chmod "$MODE" "$2"
> + else
> + FILES=
> + while test $# != 1; do
> + FILES="$FILES $1"
> + shift
> + done
> + for i in $FILES; do
touch "foo*bar" "a b c"
./gitinstall "b*c" "a b c" /tmp
... will copy a lot of files to /tmp (presuming we are in git source
directory, where tons of files are called builtin-<something>.c) and complain
that there is no 'a', no 'b' and no 'c'.
> + rm -rf "$1/"`basename "$i"`
> + cp "$i" "$1"
> + chmod "$MODE" "$1/"`basename "$i"`
> + done
> + fi
> +fi
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Eivind LM @ 2007-10-12 14:14 UTC (permalink / raw)
To: Sam Vilain, Jonathan del Strother; +Cc: git
In-Reply-To: <470E9858.5050904@vilain.net>
On Thu, 11 Oct 2007 23:40:40 +0200, Sam Vilain <sam@vilain.net> wrote:
> Jonathan del Strother wrote:
>>> For example, I want to convert one subversion repository which
>>> contains the folders:
>>> trunk/projectA
>>> trunk/projectB
>>>
>>> into two git repositories:
>>> projectA.git
>>> projectB.git
>>
>> I have a slightly different layout to you -
>>
>> projectA/trunk
>> projectA/branches
>> projectA/tags
>> projectB/trunk
>> projectB/branches
>> projectB/tags
>> etc
>>
>> - but I've been creating separate git repos from that with (for
>> example) :
>>
>> git-svn init -t tags -b branches -T trunk http://svn.host.com/projectA
>> git-svn fetch
>>
>>
>> Or will git-svn not work with your sort of layout?
>
> It does work. Use:
>
> git-svn init -t projectA/tags -b projectA/branches \
> -T trunk/projectA http://svn.host.com/
> git fetch
With my paths this translates into
$ git-svn init -b eivindlm/branches \
-t eivindlm/tags \
-T eivindlm/trunk/src/probesimulator \
file:///svn-repo/
, which prints the happy message:
Initialized empty Git repository in .git/
The next command is unfortunately not as happy:
$ git fetch
fatal: 'origin': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
Cannot get the repository state from origin
I suppose this is due to my silly svn-repo layout... However, after some
trial and error it seems like the following command gives me what I want
(I don't need tags or other branches than main):
$ git-svn clone file:///svn-repo/ --follow-parent \
-T eivindlm/trunk/src/probesimulator
It seems to realize that the probesimulator directory has moved around in
my tree, and gives me history for files that belongs in this directory
only (and not history for other directories). So the problem appears to be
solved for my part, unless you see a reason for why I should not do it in
this way.
> [...]
Thanks a lot for the help to everyone who replied!
Eivind
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Eivind LM @ 2007-10-12 14:15 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <e2a1d0aa0710110624x2b50cfafo9bfdc176ba9063ce@mail.gmail.com>
Thanks,
I found svndumpfilter in the svn book, and gave it a try. Unfortunately it
seems to be confused about files that have moved around in the repository,
I was at least not able to make it dump the entire history for a directory
that over time has changed name, and that contains files that have moved
in from other directories.
Eivind
On Thu, 11 Oct 2007 15:24:59 +0200, Patrick Doyle <wpdster@gmail.com>
wrote:
> If you look through the Subversion FAQ or the book (I forget where
> I've seen it -- but I know I've seen it), you can export/filter out a
> tree from a subversion repository and load it into a new repository.
> Then you can import from that new repository.
>
> This presumes you have direct access to the subversion repository and
> can run commands like svnadmin --dump.
>
> --wpd
>
>
> On 10/11/07, Eivind LM <eivliste@online.no> wrote:
>> Hi,
>> I would like to convert a subversion repository to Git. The subversion
>> repository used to track development of several projects (only slightly
>> related), and I would like to divide the repository into several smaller
>> git repositories.
>>
>> For example, I want to convert one subversion repository which contains
>> the folders:
>> trunk/projectA
>> trunk/projectB
>>
>> into two git repositories:
>> projectA.git
>> projectB.git
>>
>> As far as I have understood, the way to do this is to
>> 1) Convert the entire subversion repository to git with git-svn.
>> 2) Make two copies of the whole new git-repository (projectA.git and
>> projectB.git).
>> 3) Use git-rm to remove projectB from projectA.git, and projectA from
>> projectB.git.
>>
>> This works fine, but both git-repositories now carries the history for
>> both projects. If possible, I would like to "clean" the history in the
>> repositories, so that I don't see history information for projectA when
>> I
>> am browsing logs in projectB.git. Has anyone been in the same situation?
>> Do you have suggestions on how it can be solved?
>>
>> Any help will be greatly appreciated.
>>
>> Thanks,
>> Eivind
>> -
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Jonathan del Strother @ 2007-10-12 14:23 UTC (permalink / raw)
To: Eivind LM; +Cc: Git Mailing List
In-Reply-To: <op.tz28hnd2jwclfx@ichi>
On 12 Oct 2007, at 15:14, Eivind LM wrote:
> On Thu, 11 Oct 2007 23:40:40 +0200, Sam Vilain <sam@vilain.net> wrote:
>
>> Jonathan del Strother wrote:
>>>> For example, I want to convert one subversion repository which
>>>> contains the folders:
>>>> trunk/projectA
>>>> trunk/projectB
>>>>
>>>> into two git repositories:
>>>> projectA.git
>>>> projectB.git
>>>
>>> I have a slightly different layout to you -
>>>
>>> projectA/trunk
>>> projectA/branches
>>> projectA/tags
>>> projectB/trunk
>>> projectB/branches
>>> projectB/tags
>>> etc
>>>
>>> - but I've been creating separate git repos from that with (for
>>> example) :
>>>
>>> git-svn init -t tags -b branches -T trunk http://svn.host.com/projectA
>>> git-svn fetch
>>>
>>>
>>> Or will git-svn not work with your sort of layout?
>>
>> It does work. Use:
>>
>> git-svn init -t projectA/tags -b projectA/branches \
>> -T trunk/projectA http://svn.host.com/
>> git fetch
>
> With my paths this translates into
>
> $ git-svn init -b eivindlm/branches \
> -t eivindlm/tags \
> -T eivindlm/trunk/src/probesimulator \
> file:///svn-repo/
> , which prints the happy message:
> Initialized empty Git repository in .git/
>
> The next command is unfortunately not as happy:
> $ git fetch
> fatal: 'origin': unable to chdir or not a git archive
> fatal: The remote end hung up unexpectedly
> Cannot get the repository state from origin
I believe you actually wanted "git-svn fetch" here
^ 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