* Re: retrieving a diff from git
From: Christian Jaeger @ 2008-10-15 10:12 UTC (permalink / raw)
To: Folkert van Heusden; +Cc: Alex Riesen, git
In-Reply-To: <20081014172048.GW22427@vanheusden.com>
Folkert van Heusden wrote:
>> Well, you can of course just click on "commitdiff" (and "raw" afterwords)
>> for every commit,
>>
>
> Hmmm the outcome does not apply cleanly to 2.6.27.
>
>
>> but ... Have you considered using Git for that?
>>
>
> and check out the whole tree using Git? I did consider but then I would
> not have all bells and whistles to generate a Debian kernel package.
>
I'm tempted to think that you should move (merge / cherry-pick or
rebase) the relevant changes onto 2.6.27 using Git, and then take the
diff from there (on the theory that Git could reduce the number of
conflicts that you would have to resolve manually, although I'm not sure
how much this is the case); the resulting diff will then apply cleanly
to a 2.6.27 tarball without using Git.
Christian.
^ permalink raw reply
* Re: git-scm.com (was Re: Git graph on GitHub)
From: Wincent Colaiuta @ 2008-10-15 10:34 UTC (permalink / raw)
To: PJ Hyett; +Cc: git
In-Reply-To: <bab6a2ab0810150318pb616a6dj867efa36623ac12e@mail.gmail.com>
El 15/10/2008, a las 12:18, PJ Hyett escribió:
>> One nitpick regarding your git.git mirror: I doubt that people here
>> ("the community") consider git-scm.com to be "the git homepage". I
>> don't
>> want to go into the reasons and start a pointless thread, but since
>> git-scm.com is a fork of git.or.cz pointing to the latter (the root)
>> should make everyone happy.
>
> Hi Michael,
> I'll go ahead and start a pointless thread along with the reasons
> provided via answers to the 2008 Git Survey[1]:
Coming up in news at 6...
GitHub announces new maintainer for Git
GitHub is proud to announce the replacement of the old Git maintainer
with the "Git Core Team", comprising PJ Hyett, Scott Chacon, Tom
Preston and some select personalities from the Ruby on Rails world.
You'll be able to track all the latest updates to "Git Edge" over at
GitHub. The former maintainer, Junio C Hamano, is being retired from
service because the Git community (see git-scm.com) decided he wasn't
as good-looking as David Heinemeier Hanson. For more information, see
the official Git book (book.git-scm.com).
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #03; Tue, 14)
From: Nguyen Thai Ngoc Duy @ 2008-10-15 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wsq7rt5.fsf@gitster.siamese.dyndns.org>
On 10/15/08, Junio C Hamano <gitster@pobox.com> wrote:
> [Stuck Topics]
>
> * nd/narrow (Wed Oct 1 11:04:09 2008 +0700) 9 commits
> - grep: skip files outside sparse checkout area
> - checkout_entry(): CE_NO_CHECKOUT on checked out entries.
> - Prevent diff machinery from examining worktree outside sparse
> checkout
> - ls-files: Add tests for --sparse and friends
> - update-index: add --checkout/--no-checkout to update
> CE_NO_CHECKOUT bit
> - update-index: refactor mark_valid() in preparation for new options
> - ls-files: add options to support sparse checkout
> - Introduce CE_NO_CHECKOUT bit
> - Extend index to save more flags
>
> Recently updated with a repost. Shawn says he's been too swamped at
> day-job to actively review the series. There has been some discussion on
> list about it so its not stalled, but it needs more eyeballs.
Just a bit of update. I'm still working on the second half. Code
change is even more than this, so I will wait until the first half
gets reviewed and accepted before sending the rest.
BTW, in the first half, unpack_trees()-related commands may refuse to
work if there is orphaned/stale entries in working directory
(verify_*() functions still look at working directory no matter
whether entries are no-checkout). Those entries are troublesome anyway
so encouraging people to clean them out is, IMHO, a good idea, rather
than fixing unpack_trees() to ignore them.
--
Duy
^ permalink raw reply
* [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-15 12:07 UTC (permalink / raw)
To: git
Greetings all,
two days ago I posted about an issue:
http://thread.gmane.org/gmane.comp.version-control.git/98171
After more testing I can confirm it is indeed a bug.
1.6.0.2 on OSX Leopard doesn't work. After adding a submodule
the folder of the submodule will always get listed under
"Untracked files" when calling git status.
1.5.6, however, works fine. I have not tested trunk yet.
So as a workaround I have to go back to 1.5.6 for now.
Yours,
Lars
^ permalink raw reply
* Re: Git graph on GitHub
From: Petr Baudis @ 2008-10-15 12:20 UTC (permalink / raw)
To: Tom Werner; +Cc: git
In-Reply-To: <530345950810150047v75bfbf9clebbb8a406b172c4c@mail.gmail.com>
Hi,
On Wed, Oct 15, 2008 at 12:47:52AM -0700, Tom Werner wrote:
> We've just pushed out an update to the Network Graph on GitHub this
> evening that finally allows us to draw very large repositories
> (including Git). We're mirroring the Git repo on the site and I
> thought it might be interesting for people to see this visualization.
> Enjoy!
>
> http://github.com/git/git/network
>
> Let me know if you have any ideas for improvements on the graph. I'm
> always looking for ways to enhance it.
it's generally nice, but I think it could be much more useful yet. :-)
Generally, I find its information density very low. I see only tiny
dots connected by lines at the top of the screen (rest grey) and if I
want to know _what_ commits are actually there, I need to carefully
hover over the scattered tiny dots. So my question is, exactly what kind
of information do you seek to present primarily? Based on what I see,
the answer seems to be just "how hairy the project history is", and I'm
wondering if maybe some other class of information would be more
interesting. IOW, what about using that blank grey area to show the
commit subjects? ;-)
Right now, your repository contains only the 'master' branch. I guess
you want to setup a --mirror repository instead of pulling?
Also, it would be pretty nifty if you could tag lines of past topic
branches based on the merge commit message. E.g. mark the blue line
short in the past as pb/gitweb-tagcloud based on the 3e3d4ee merge. On
the other hand, I'm not sure how well would it work visually if the
topic branches are very short and merged right away.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: [PATCH (GITK) v3 0/4] Enhance encoding support.
From: Paul Mackerras @ 2008-10-15 12:32 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <1223885554-27718-1-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> Currently GUI tools don't provide enough support for
> viewing files that contain non-ASCII characters. This set of
> patches addresses this issue. The git-gui part of the series
> is based on patches that were in the 'pu' branch of the
> git-gui repository.
Thanks. I applied 1/4 and 2/4 as one commit and 3/4 as another.
However, it seems invoking git check-attr is quite slow, or at least,
there is a large startup cost which is not really amortized by
batching up only 30 paths per call.
As a test I tried displaying the diff in the kernel tree from 2.6.27
to Linus' master as of a day or so ago (3fa8749e) which has 5277 files
different. With the 30-way batching this takes over 6 seconds to get
the file encodings (all of which are "unspecified" since I don't have
any .gitattributes files), which we need before we display the list of
changed files, which before only took 0.12 seconds -- so we're 50x
slower at showing the list of changed files as a result of adding the
per-file encoding support. Also, each call to cache_gitattr was
taking 1.2 seconds, which is too long since file handlers are supposed
to limit themselves to less than 100ms (preferably less than 50ms) of
processing on any one call, and the cache_gitattr call was making
gettreediffline take way too long.
So I have added another commit which makes the per-file encoding
support optional and default to off for now. It also increases the
amount of batching in cache_gitattr (except under windows) and reduces
the number of lines that gettreediffline does when per-file encoding
support is on. Along the way, it also converts the new code to the
gitk coding style, cleans up a few things and adds a simple cache to
tclencoding.
If git check-attr gets the --stdin-paths flag added, that will be
good, except then getblobdiffline will need to do something clever if
it needs the encoding for a file but the result hasn't come back from
git-check-attr yet. That could get quite tricky in fact...
Paul.
^ permalink raw reply
* Re: [PATCH (GITK) v3 0/4] Enhance encoding support.
From: Paul Mackerras @ 2008-10-15 12:38 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <1223885554-27718-1-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> Since git apparently cannot work with filenames in non-locale
> encodings anyway, I did not try to do anything about it apart
> from fixing some obvious bugs.
What we did before was read filenames and convert them from the system
encoding (done implicitly by gets) before unquoting filenames that
were quoted. What we do now with your patch 1/2 is that we read the
filenames in binary and unquote any quoted filenames before converting
from the system encoding. So I don't think your patch would have made
as much difference as it might appear. If there is a reason for
unquoting before converting from the system encoding rather than
after, it seems pretty subtle to me and wasn't explained in the patch
description. An explanation, preferably with examples, would be
useful.
Also, you didn't say whether you found the "obvious bugs" by
inspection or by encountering their effects in actual running (and if
so, what those effects were). That information is also good to have
in the patch description.
Paul.
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Jeff King @ 2008-10-15 12:49 UTC (permalink / raw)
To: Lars Hoss; +Cc: git
In-Reply-To: <c60a85c1297be6446ad92a3e7723ddc8.squirrel@webmail.highteq.net>
On Wed, Oct 15, 2008 at 02:07:17PM +0200, Lars Hoss wrote:
> two days ago I posted about an issue:
> http://thread.gmane.org/gmane.comp.version-control.git/98171
>
> After more testing I can confirm it is indeed a bug.
>
> 1.6.0.2 on OSX Leopard doesn't work. After adding a submodule
> the folder of the submodule will always get listed under
> "Untracked files" when calling git status.
>
> 1.5.6, however, works fine. I have not tested trunk yet.
I wasn't able to reproduce your bug on my Linux box. Can you bisect to
find the faulty commit?
-Peff
^ permalink raw reply
* Re: [PATCH v2] describe: Make --tags and --all match lightweight tags more often
From: Santi Béjar @ 2008-10-15 12:54 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, git, Pierre Habouzit, Erez Zilber,
Uwe Kleine-König
In-Reply-To: <20081013143946.GP4856@spearce.org>
> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
> index c4dbc2a..40e061f 100644
> --- a/Documentation/git-describe.txt
> +++ b/Documentation/git-describe.txt
[...]
> +annotated tags. For more information about creating annoated tags
s/annoated/annotated/
Santi
^ permalink raw reply
* Re: [PATCH (GITK) v3 0/4] Enhance encoding support.
From: Alexander Gavrilov @ 2008-10-15 13:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Johannes Sixt
In-Reply-To: <18677.58426.326371.788610@cargo.ozlabs.ibm.com>
On Wed, Oct 15, 2008 at 4:38 PM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>
>> Since git apparently cannot work with filenames in non-locale
>> encodings anyway, I did not try to do anything about it apart
>> from fixing some obvious bugs.
>
> What we did before was read filenames and convert them from the system
> encoding (done implicitly by gets) before unquoting filenames that
> were quoted. What we do now with your patch 1/2 is that we read the
> filenames in binary and unquote any quoted filenames before converting
> from the system encoding. So I don't think your patch would have made
> as much difference as it might appear. If there is a reason for
> unquoting before converting from the system encoding rather than
> after, it seems pretty subtle to me and wasn't explained in the patch
> description. An explanation, preferably with examples, would be
> useful.
The reason is that non-ASCII characters may be quoted too, so the
string that we read looks like
"\204\206\204y\204s\204\200\204r\204y\204~\204p.txt". There is no
point decoding it before unquoting.
> Also, you didn't say whether you found the "obvious bugs" by
> inspection or by encountering their effects in actual running (and if
> so, what those effects were). That information is also good to have
> in the patch description.
I actually created a test repository with non-ASCII filenames. If I
remember it correctly, the bugs manifested as strings in the tree view
appearing as if they were decoded using ISO-8859-1 (the result of
decoding before unquoting), or unstaged files being listed quoted as
above.
Now the remaining encoding issues are:
1) Commit messages that are loaded through readcommit are decoded
using the system encoding. It is rare, but it happens. This is a bug.
proc readcommit {id} {
if {[catch {set contents [exec git cat-file commit $id]}]} return
parsecommit $id $contents 0
}
2) Gitk cannot process commits stored in multiple different encodings:
they all are decoded using the current value of i18n.commitencoding.
This seems to be low priority, because most GUI users are better off
using utf-8 for their commits anyway.
Alexander
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-15 14:30 UTC (permalink / raw)
To: Jeff King; +Cc: Lars Hoss, git
In-Reply-To: <20081015124943.GA10816@sigill.intra.peff.net>
> I wasn't able to reproduce your bug on my Linux box. Can you bisect to
> find the faulty commit?
Yes, you are right. This bug does neither appear on Linux nor on Windows
(mysysgit). So far it seems to be a OSX only bug.
Never used bisect myself before since I am new to git. But will try to do
my best - hehehe :)
Yours,
Lars
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Matt McCutchen @ 2008-10-15 14:34 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <48F589EC.6050307@viscovery.net>
On Wed, 2008-10-15 at 08:13 +0200, Johannes Sixt wrote:
> Junio C Hamano schrieb:
> > Makes me wonder why this is _not_ inside test-lib.sh where it creates the
> > test (trash) directory. That way, you would cover future tests that wants
> > to see a saner/simpler POSIX permission behaviour, wouldn't you?
>
> But that would also paper over unanticipated bad interactions with strange
> ACLs that people might set, wouldn't it? By not placing this into
> test-lib.sh there is a higher chance that such an interaction is revealed,
> and we can react on it (educate users or fix the code).
A default ACL on the working tree does not interfere with git's
operation. If the repository is shared, git will explicitly set the
permissions of every file as configured; otherwise, new files will
simply take their permissions from the default ACL instead of the
creating process's umask. This is exactly the behavior that a user who
sets a default ACL would expect. There is no need to modify
adjust_shared_perm or to warn users not to use default ACLs.
The only problem here is that a default ACL prevents
t1301-shared-repo.sh from testing the interaction between the umask and
the sharedRepository setting, since the test case expects new files to
be created according to the umask it set but the default ACL is
overriding the umask. Removing the trash directory's default ACL is a
perfectly legitimate way for t1301-shared-repo.sh to test what it wants
to test. Another option would be to modify the trash directory's
default ACL instead of modifying the umask.
Other tests will not care whether test-lib.sh clears a default ACL for
them because they are not specifically testing file permissions.
Therefore, I thought it best to leave the default ACL alone so that the
trash directories get the permissions the user has specified in the
default ACL in case he/she cares about sharing the trash directories
with others.
Matt
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Pieter de Bie @ 2008-10-15 14:38 UTC (permalink / raw)
To: Lars Hoss, Jeff King, Git Mailinglist
In-Reply-To: <c60a85c1297be6446ad92a3e7723ddc8.squirrel@webmail.highteq.net>
On 15 okt 2008, at 14:07, Lars Hoss wrote:
> two days ago I posted about an issue:
> http://thread.gmane.org/gmane.comp.version-control.git/98171
>
> After more testing I can confirm it is indeed a bug.
>
> 1.6.0.2 on OSX Leopard doesn't work. After adding a submodule
> the folder of the submodule will always get listed under
> "Untracked files" when calling git status.
>
> 1.5.6, however, works fine. I have not tested trunk yet.
>
> So as a workaround I have to go back to 1.5.6 for now.
Works for me on Leopard
Vienna:a pieter$ git submodule add ~/projects/GitX/ gitx
Initialized empty Git repository in /Users/pieter/a/gitx/.git/
Vienna:a pieter$ git st
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: .gitmodules
# new file: gitx
#
Vienna:a pieter$ git --version
git version 1.6.0.2.415.gf9137
- Pieter
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-15 14:51 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Lars Hoss, Jeff King, Git Mailinglist
In-Reply-To: <5D0481A4-D173-4CF8-B855-5E58978210F8@ai.rug.nl>
> Works for me on Leopard
>
> Vienna:a pieter$ git submodule add ~/projects/GitX/ gitx
> Initialized empty Git repository in /Users/pieter/a/gitx/.git/
> Vienna:a pieter$ git st
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # new file: .gitmodules
> # new file: gitx
> #
> Vienna:a pieter$ git --version
> git version 1.6.0.2.415.gf9137
My git version "1.6.0.2" says:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: .gitmodules
# new file: lib
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# lib/
git --version
git version 1.6.0.2
Git was build from macports.
Yours,
Lars
^ permalink raw reply
* Re: Separating generated files? (Re: Mercurial -> git)
From: Nguyen Thai Ngoc Duy @ 2008-10-15 14:54 UTC (permalink / raw)
To: Christian Jaeger, Git Mailing List; +Cc: Gambit List
In-Reply-To: <48F5D86B.6040501@pflanze.mine.nu>
Hi Christian,
The idea of using two separate repositories for source and generated
source is interesting. I would like to bring this to git mailing list,
they may provide insightul comments for your idea or even other
approaches.
Background for Git people: gambit-c was previously stored in
mercurial. The main source is in gambit-c (a Scheme implementation or
a Lisp dialect). *.scm files generate *.c, which will be compiled by
gcc as usual. Both *.scm and generated *.c are now stored in
mercurial. Gambit-C maintainers have recently decided to move to Git.
On 10/15/08, Christian Jaeger <christian@pflanze.mine.nu> wrote:
> I wonder whether it would be a good idea, and good occasion to realize
> it, to move source files and generated files into separate repositories
> and 'link' those together using the git submodule feature.
>
> Expected advantages:
>
> - no clutter when looking through the history (can possibly be mitigated
> by constraining git log, git diff etc. to the non-generated paths only,
> although I don't think this is possible (cleanly) with the current
> directory structure); the same holds true for using "git format-patch"
> (one wouldn't usually want to include the generated files in diffs sent
> to the mailing list)
>
> - when merging branches, there will usually be no need to deal with
> merge conflicts in the generated files (one would just regenerate them
> instead)
>
> - [especially for files being generated not by Gambit itself (for
> example "configure"),] the files can be regenerated by differing
> [external] software versions without having to deal with those
> superfluous changes in the source repository.
>
> By still committing the generated files--to a different
> submodule--Gambit can still be updated through Git alone, and the
> possible advantage of tracking the generated files to see the effects of
> changes in compiler sources can still be had.
>
> Expected disadvantages:
>
> - all generated files need to reside in a separate directory structure;
> e.g. the file $BASEDIR/lib/_io.c would have to be at a place like
> $BASEDIR/build/lib/_io.c instead, where build/ is the submodule taking
> all generated files; since the "configure" file is expected to reside at
> the toplevel, I guess this would require that "make update" copies it
> from $BASEDIR/build/configure to $BASEDIR/configure (assuming that one
> cannot use a symlink because of portability reasons).
>
> - to commit the generated files, a separate step is necessary ("cd
> $otherrepo; git commit -a", or maybe easier create a "make
> commit_generated" make target?)
>
> - to make this work with the "source" repository residing at the
> toplevel, the Git superproject repository (of which the "source" and
> "build" repositories are submodules) would need to reside in a
> non-standard directory, like $BASEDIR/.gitsuperproject/ instead of the
> usual .git/, and using the GIT_DIR environment variable to access it,
> although this can probably be handled by make targets (i.e. "make
> update" would set GIT_DIR=$BASEDIR/.gitsuperproject when calling "git
> submodule update").
>
> - there may be some cases to flesh out; like, should "make update"
> really call "git submodule update" (which simply sets the submodules to
> the reference given by the superproject, throwing away changes done by
> the user in the submodules (they can be recovered from the git reflog,
> but may still be a surprise)) or should it run "git pull" in each
> submodule instead?
>
> I thought I'd bring this up now because if package maintainers need to
> adapt some things anyway, that may be a good time to do it now. (There's
> even the possibility to split the converted Mercurial repository into
> the source + build parts in retrospect now, which won't be possible
> anymore later on (without changing the sha1 sums of the whole Git
> history with the associated breakage of existing clones), although that
> may not be important.)
>
> I'm willing to help in the effort, although I don't know the build tools
> (autoconf and make) and their use in the setup well, so I would probably
> be quite a bit lost when doing it alone.
>
> Christian.
--
Duy
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Pieter de Bie @ 2008-10-15 14:59 UTC (permalink / raw)
To: Lars Hoss; +Cc: Jeff King, Git Mailinglist
In-Reply-To: <6ca24750ca8d7bd9e995d023e78e0d71.squirrel@webmail.highteq.net>
On 15 okt 2008, at 16:51, Lars Hoss wrote:
> My git version "1.6.0.2" says:
>
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # lib/
> git --version
> git version 1.6.0.2
I just tested 1.6.0.2, and had no problems. Perhaps macports is doing
something odd?
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Richard Bubel @ 2008-10-15 15:01 UTC (permalink / raw)
To: Lars Hoss; +Cc: Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <6ca24750ca8d7bd9e995d023e78e0d71.squirrel@webmail.highteq.net>
Hi,
On Oct 15, 2008, at 16:51 , Lars Hoss wrote:
>> Works for me on Leopard
>> [...]
>> Vienna:a pieter$ git --version
>> git version 1.6.0.2.415.gf9137
>
> My git version "1.6.0.2" says:
>
> # On branch master
> [...]
> git --version
> git version 1.6.0.2
>
> Git was build from macports.
works for me too on OS X 10.5.5 with git 1.6.0.2 from MacPorts. As it
deviates from the default, it might be worth mentioning that the
filesystem in use here is the case-sensitive version of HFS+.
Best Regards,
Richard
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-15 15:14 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Lars Hoss, Jeff King, Git Mailinglist
In-Reply-To: <A0A3837E-7F85-4172-A8BA-969BFD46CF48@ai.rug.nl>
> I just tested 1.6.0.2, and had no problems. Perhaps macports is doing
> something odd?
Actually this was my idea first. Thus I build git from the sources the
portfile links to myself. The bug, however, remains.
The link is: http://www.kernel.org/pub/software/scm/git/git-1.6.0.2.tar.bz2.
I've tested this on two machines, both using latest version of Leopard.
And there was another poster on this forum who had the very same issue.
Now the interesting question is what is different between Pieter's system
and mine? And why does 1.5.6 work fine?
As soon as I am at home I will try bisect. I am currently at work behind a
big bad firewall ;)
Yours,
Lars
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-15 15:21 UTC (permalink / raw)
To: Richard Bubel; +Cc: Lars Hoss, Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <DE453BEE-6749-4892-BFAA-3B37CFAADD3E@cs.chalmers.se>
Ok, this might be the difference. I am pretty sure my
filesystem is not case-sensitive (default?).
At least "mkdir Foo" fails when "foo" exists.
Yours,
Lars
> Hi,
>
> On Oct 15, 2008, at 16:51 , Lars Hoss wrote:
>
>>> Works for me on Leopard
>>> [...]
>>> Vienna:a pieter$ git --version
>>> git version 1.6.0.2.415.gf9137
>>
>> My git version "1.6.0.2" says:
>>
>> # On branch master
>> [...]
>> git --version
>> git version 1.6.0.2
>>
>> Git was build from macports.
>
>
> works for me too on OS X 10.5.5 with git 1.6.0.2 from MacPorts. As it
> deviates from the default, it might be worth mentioning that the
> filesystem in use here is the case-sensitive version of HFS+.
>
> Best Regards,
> Richard
>
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Brandon Casey @ 2008-10-15 15:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Arjen Laarhoven, Jeff King, Shawn O. Pearce, Mike Ralphson
In-Reply-To: <7vej2i7rt9.fsf@gitster.siamese.dyndns.org>
Two questions:
1) Should a5a5a048 be in maint?
"xdiff-interface.c: strip newline (and cr) from line before pattern matching"
2) Do we want to stick with compat/regex on
Darwin: Arjen
FreeBSD: Jeff
AIX: Mike
now that the builtin funcname patterns have been converted to Extended
Regular Expressions?
-brandon
^ permalink raw reply
* Re: [gambit-list] Separating generated files? (Re: Mercurial -> git)
From: Matthieu Moy @ 2008-10-15 15:30 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Christian Jaeger, Git Mailing List, Marc Feeley, Gambit List
In-Reply-To: <fcaeb9bf0810150754s613f2c44pd8341711d9d73f73@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> Hi Christian,
>
> The idea of using two separate repositories for source and generated
> source is interesting. I would like to bring this to git mailing list,
> they may provide insightul comments for your idea or even other
> approaches.
I think the first question is: do you (and why) need to use a version
control system for generated files?
--
Matthieu
^ permalink raw reply
* Re: git-scm.com (was Re: Git graph on GitHub)
From: Scott Chacon @ 2008-10-15 16:21 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <20C9ABEC-52E5-405E-A755-C58A6359D7A9@wincent.com>
Hi,
On Wed, Oct 15, 2008 at 3:34 AM, Wincent Colaiuta <win@wincent.com> wrote:
> El 15/10/2008, a las 12:18, PJ Hyett escribió:
>
>>> One nitpick regarding your git.git mirror: I doubt that people here
>>> ("the community") consider git-scm.com to be "the git homepage". I don't
>>> want to go into the reasons and start a pointless thread, but since
>>> git-scm.com is a fork of git.or.cz pointing to the latter (the root)
>>> should make everyone happy.
There is a slight misperception here. I setup the git mirror at
GitHub as part of my git-scm.com work, they did not do it as some sort
of semi-official mirror. The reason the git.git repo points to
git-scm is because I had plans to use github apis to do some fun stuff
on git-scm, and the mirror is being kept up to date by scripts on the
git-scm server. Also, I figured it was likely that people looking at
the git repo on GitHub rather than on kernel.org would probably be
more interested in the more user-friendly version, yes? That's all,
it's nothing sinister. Petr and I have previously discussed trying to
unify the sites somehow and will likely discuss this in more detail at
the GitTogether in a few weeks.
Also, trust me - none of us want Junio's job. I've talked way too
much with Shawn over the last few weeks to ever covet that position :)
I do wish that there wasn't this 'us vs them' mentality on this list,
though. I think GitHub is doing some good things for the community,
and I also think that 'the community' is bigger than this list. I
propose that we spend our cycles on git stuff, rather than mocking or
trying to exclude each other.
Also, I think we can all agree that Junio is strikingly handsome.
Scott
>>
>> Hi Michael,
>> I'll go ahead and start a pointless thread along with the reasons
>> provided via answers to the 2008 Git Survey[1]:
>
> Coming up in news at 6...
>
> GitHub announces new maintainer for Git
>
> GitHub is proud to announce the replacement of the old Git maintainer with
> the "Git Core Team", comprising PJ Hyett, Scott Chacon, Tom Preston and some
> select personalities from the Ruby on Rails world. You'll be able to track
> all the latest updates to "Git Edge" over at GitHub. The former maintainer,
> Junio C Hamano, is being retired from service because the Git community (see
> git-scm.com) decided he wasn't as good-looking as David Heinemeier Hanson.
> For more information, see the official Git book (book.git-scm.com).
>
> --
> 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: [gambit-list] Separating generated files? (Re: Mercurial -> git)
From: Michael J Gruber @ 2008-10-15 16:42 UTC (permalink / raw)
To: Matthieu Moy
Cc: Nguyen Thai Ngoc Duy, Christian Jaeger, Git Mailing List,
Marc Feeley, Gambit List
In-Reply-To: <vpqiqrt3mgs.fsf@bauges.imag.fr>
Matthieu Moy venit, vidit, dixit 15.10.2008 17:30:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
>> Hi Christian,
>>
>> The idea of using two separate repositories for source and generated
>> source is interesting. I would like to bring this to git mailing list,
>> they may provide insightul comments for your idea or even other
>> approaches.
>
> I think the first question is: do you (and why) need to use a version
> control system for generated files?
I guess we can take "yes" for granted for the first part ;)
As for the why: In cases like this one it's interesting to compare
(read: diff) the output generated by different versions of the input.
I wonder whether a clever use of "excludes" and GIT_DIR would allow
tracking the different filesets in the same dir, but using different
repos. I'm just afraid it's a fragile setup, in the sense that it relies
on config stuff which is not tracked (and thus not reproduced
automatically on clone).
Michael
^ permalink raw reply
* Re: Separating generated files?
From: Christian Jaeger @ 2008-10-15 16:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Gambit List, Git Mailing List
In-Reply-To: <vpqiqrt3mgs.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> I think the first question is: do you (and why) need to use a version
> control system for generated files?
The project in question is a self-hosting compiler which compiles to C
as an intermediary language. Providing the generated C files to users
makes installation easy (it avoids the bootstrapping issue). So it's
more 'severe' of an issue than just one of for example generating
documentation files using a 3rd-party tool.
What may make matters worse, is that there are interdependencies between
a number of hand-written C files and the generated files, so it's not
always possible to use an older compiler version to reproduce the
generated C files for a newer compiler; so if you want to merge newer
compiler sources, you may also need the generated files, at least if you
want that without fuss. So, there is always a need to somehow transmit
the generated files too. I guess that this is easier than code the
system in a way to always allow backwards compatibility (I haven't
worked on the compiler itself yet, so this is a guess and may need
confirmation).
Apart from that, I've found it useful (in another project, writing a
document translator) to keep generated files in a VCS (Git) as well (I
checked them into the *same* repository as the translator source, even
if it felt ugly (for the previously mentioned reasons)), as then when I
changed the translator, I could easily see where it had effect on the
generated output. It can even serve as a debugging help kind of like a
test suite does. This may be the case here, too (again, I'm guessing here).
How are other compiler projects which are bootstrapping via C dealing
with this?
Christian.
^ permalink raw reply
* StGIT 0.14.3: extra space is added before e-mail on export after "stg edit"
From: Andrey Borzenkov @ 2008-10-15 16:25 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
Hi,
Funny problem. I have following export template:
Subject: [PATCH] %(shortdescr)s
From: %(authname)s %(authemail)s
%(longdescr)s
Signed-off-by: %(authname)s %(authemail)s
---
%(diffstat)s
So after "stg new", edit, "stg refres" (and any number of "stg refresh"es)
it exports OK. But once I did "stg edit patch", all subsequent "stg export patch"
will give (assuming author is me@foo.net):
From: My Name < me@foo.net>
...
Signed-off-by: My Name < me@foo.net>
Notice extra space between "<" and e-mail.
TIA
-andrey
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox