* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Martin Langhoff @ 2007-10-12 4:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Harning Jr., git
In-Reply-To: <Pine.LNX.4.64.0710111704570.4174@racer.site>
On 10/12/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I, for one, am totally opposed to this split. All too often valuable
> _user_ discussions turn into _technical_ discussions, and thence into a
> throwing back and forth patches.
<aol>mee too! - I think it's the kind of development culture that
Linus tries to foster, and I suspect Junio likes too: "talk in
patches" which is a lot more productive than "talk like a pirate",
bikeshedding and other maladies that can fester in mailing lists.
So no split for me ;-) We have the additional alibi that git users are
supposed to be programmers.
m
^ permalink raw reply
* Re: RCS keyword expansion
From: Peter Karlsson @ 2007-10-12 5:26 UTC (permalink / raw)
Cc: git
In-Reply-To: <Pine.LNX.4.64.0710112144380.4174@racer.site>
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).
> 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.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: RCS keyword expansion
From: Peter Karlsson @ 2007-10-12 5:27 UTC (permalink / raw)
Cc: git
In-Reply-To: <20071011192103.GD2804@steel.home>
Alex Riesen:
> That's confusing. If your web site is just a checkout, what is the "make
> install" for?
Exactly. That's what I wondering.
> If it is a repo, you have the version information anyway, and at all
> times.
Yes, but not embedded in the page in a format that is visible to the
visitor. For CVS I use something like this:
<p class="date">$Date$</p>
to embed the last update time into the page.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: Johannes Sixt @ 2007-10-12 6:43 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: David Kastrup, git, Junio C Hamano
In-Reply-To: <63D5CE5B-51DD-4017-B2E2-2ADC5DCBE849@steelskies.com>
Jonathan del Strother schrieb:
>
> On 11 Oct 2007, at 21:53, David Kastrup wrote:
>
>> 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.
>
> I would also point out that most tests have already been written to
> handle this case - ones that don't quote their paths are in the minority.
Actually, reconsidering your proposed patch, there are only a handful of
problematic cases, namely those where the test script is quoted with
double-quotes, like this:
test_expect_success 'load repository with strange names' "
- svnadmin load -q $rawsvnrepo < ../t9115/funky-names.dump &&
+ svnadmin load -q '$rawsvnrepo' < ../t9115/funky-names.dump &&
start_httpd
"
The problem is that here $rawsvnrepo will be expanded before the entire test
script is passed as argument to test_expect_success. Consider the case where
$rawsvnrepo contains a single-quote (say, a directory named "Joe's git"):
then the 'eval' inside test_expect_success sees a syntax error. The proper
change is:
test_expect_success 'load repository with strange names' "
- svnadmin load -q $rawsvnrepo < ../t9115/funky-names.dump &&
+ svnadmin load -q \"\$rawsvnrepo\" < ../t9115/funky-names.dump &&
start_httpd
"
So, what I think you should do is:
1. Submit the change to git-rebase.sh in a separate patch.
2. Fix the patch for the double-quoted test scriptlets.
That should remove all my concerns.
-- Hannes
^ permalink raw reply
* push fails with unexpected 'matches more than one'
From: Steffen Prohaska @ 2007-10-12 6:59 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
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.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
t/t5516-fetch-push.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index ca46aaf..f249216 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -244,4 +244,12 @@ test_expect_success 'push with colon-less refspec (4)' '
'
+test_expect_success 'push with colon-less refspec (locally unambigous)' '
+
+ mk_test heads/frotz heads/t/frotz &&
+ git branch -f frotz master &&
+ git push testrepo frotz
+
+'
+
test_done
--
1.5.3.4.219.gd0b2
^ permalink raw reply related
* Re: yet another workflow question...
From: Andy Parkins @ 2007-10-12 7:25 UTC (permalink / raw)
To: git; +Cc: Jing Xue, Patrick Doyle
In-Reply-To: <20071011164019.3n4l3rayckck8c4w@intranet.digizenstudio.com>
On Thursday 2007 October 11, Jing Xue wrote:
> Quoting Andy Parkins <andyparkins@gmail.com>:
> > - Mobility. This one is a bit distributed, but I hope you'll let
> > me have it.
> > I often do work on my desktop at home, my desktop at work and my
> > laptop. By setting my remotes up correctly in git it's really easy to
> > walk to another system and pick up exactly where I left off from the
> > other computer. More importantly though, when you accidentally make
> > changes in two places, there is no danger of data loss.
>
> To extend on this point, after picking up the randomly checked-in save
> point on another computer, the save point itself can be easily
> git-reset'ed. So there won't be commits like "it's utter broken but i
> got to go home" polluting the history. I find that extremely handy.
Absolutely; in fact I've had times when I've done things like this:
git merge laptop-branch
git merge home-branch
git reset HEAD^^
That is to say, I'm not interested in documenting the merges, I just want to
bring a set of changes from different places together ready for some proper
commits, which of course can be done really easily with git add -i.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Simon Sasburg @ 2007-10-12 7:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Harning Jr., git
In-Reply-To: <Pine.LNX.4.64.0710111704570.4174@racer.site>
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.
^ permalink raw reply
* Re: Status of kha/experimental
From: Karl Hasselström @ 2007-10-12 7:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Yann Dirson, David Kågedal, Git Mailing List
In-Reply-To: <b0943d9e0710111338u109aa304o6ba9c886a42c2e24@mail.gmail.com>
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. :-) )
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ 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
* 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
* [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
* 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
* 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
* 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
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