* Re: Submodules: Publishing a locally created submodule.
From: Thomas Adam @ 2008-07-25 0:05 UTC (permalink / raw)
To: Mark Levedahl; +Cc: git mailing list
In-Reply-To: <48891088.40709@gmail.com>
Hello --
2008/7/25 Mark Levedahl <mlevedahl@gmail.com>:
> git submodule add <URL where this will exist> ./mysubmoduleB
>
> will recognize that mysubmoduleB is already a valid git repo and add it as
> is at the current location to the superproject.
Ah -- now that was missing from the documentation (the syntax; not the
intention.) Thanks.
It seems my brain has turned to mush so I need to go back to square
one and verify the steps for this are accurate. If I am doing this
arse-about-face, do say. ;)
I've mentioned I am using a bare repository which is shared amongst
developers. We've been using one fine for normal development and for
various reaons I am creating a new repository to be filled with
submodules. I shall call this "SM".
Our "superproject" is a directory hierarchy with interspersed files.
On the server I did this:
server% cd /usr/src/SM
server% git init
server% cd ./superproject
server% git init
server% git add .
server% git commit -m "Initial checkin"
server% cd ..
server% git submodule add /path/to/usr/src/SM
server% git commit -a -m "Submodules..."
Then cloned a bare repo from that which I was able to clone locally
and do stuff in. I could push stuff out too for that one project.
But how from this clone do I then publish any further submodules I
might create locally? I can't very well do so directly in my checkout
-- it has no concept of where the submodules are. I could go to the
server, add another directory as a submodule (as I've done with
"superproject" above --- but then any changes under /usr/src/SM on the
server are local -- the bare repo has no knowledge of any changes made
there.
Does this even make sense? ;)
Thanks in advance.
-- Thomas Adam
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-25 0:01 UTC (permalink / raw)
To: Eyvind Bernhardsen; +Cc: Avery Pennarun, Joshua Jensen, Junio C Hamano, git
In-Reply-To: <3B9933A6-9637-41AE-9133-9B6EA9204E6B@orakel.ntnu.no>
Hi,
On Thu, 24 Jul 2008, Eyvind Bernhardsen wrote:
> On 23. juli. 2008, at 21.44, Johannes Schindelin wrote:
>
> [...]
>
> >I deem it not, uhm, magical. By your reasoning there should be a way
> >for Git to convert a file to UTF-8 when some entertaining person
> >converted the working directory file to ISO-8859-15.
>
> Um, what? This discussion is about figuring out when Git should mess
> with the line endings a user is trying to commit.
This discusion is about when Git should mess with _content_ at all.
It is not limited to line endings.
Ciao,
Dscho "who personally could not care less about CR if it was not for M$'
stupidity"
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-24 23:58 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Steffen Prohaska, Dmitry Potapov, Junio C Hamano,
Git Mailing List
In-Reply-To: <200807242244.04799.robin.rosenberg.lists@dewire.com>
Hi,
On Thu, 24 Jul 2008, Robin Rosenberg wrote:
> torsdagen den 24 juli 2008 18.45.07 skrev Johannes Schindelin:
> > However, I see Junio's point: on sane platforms you have to work hard
> > to get CR-damaged files. And the regular sane platform user should
> > not be punished for the brain/CR damage a certain monopolist has
> > brought over this planet.
>
> That wasn't hard at all :) Eclipse did it all by itself for JEE
> MANIFEST.MF files. We got into some strange problems on windows with
> msysgit after that where git (status) detected the files as changed, but
> no actual content change and refused to change it's mind. I think we had
> actually fixed the files on Windows prior to that. Only after converting
> the checkout to autocrlf=input did msysgit enter a sane state again. I
> was not able to repeat the problem at the time.
>
> Maybe I'll try again in a few weeks time.
That would be rather useful, because without a way to reproduce, you leave
me with a rather frustrating situation.
Hth,
Dscho
^ permalink raw reply
* Re: Stitching together two split segments from svn
From: Jakub Narebski @ 2008-07-24 23:48 UTC (permalink / raw)
To: Liam Healy; +Cc: git
In-Reply-To: <654935030807241633g763e622br4feb8b4e23ee64e2@mail.gmail.com>
"Liam Healy" <lnp@healy.washington.dc.us> writes:
> I have a project whose history is stored in two separate svn
> repositories. The first repository I kept privately during initial
> development, the second started when I posted it publicly and does not
> have the history of the first. I am trying to reunite them under git.
> The development of the first was linear, so after using git svn, the
> history looks like:
>
> a - b - ... - c - d = HEAD (old repository)
>
> and the second has one branch "ffa":
>
> (new repository)
> T - d - e - ... - f - g - h - ... - j master
> \
> k - l - .... - m ffa
>
> Note that T is the "trunk" initial commit on the svn repo that has no
> files. The second commit d is identical to the HEAD of old, as
> verified by git diff.
> However, when I remote add these two into a single repository, they
> show up as two detached chains, with no connection between them. I
> thought git rebase would reconnect them. However, when I do that on
> each branch (master and ffa), I get the following:
>
> a - b - ... - c - d - e - ... - f - g - h - ... - j master
> \
> e - ... -f - g - k - l - .... - m ffa
>
> instead of what I would like
>
> a - b - ... - c - d - e - ... - f - g - h - ... - j master
> \
> k - l - .... - m ffa
>
> That is to say, those commits from the new repository that have a
> common history for the two branches are duplicated. The commits are
> listed separately and have different SHA IDs, but they are clearly the
> same commits (same comments, same svn version number). Is there any
> way to do what I want? Really, all I want to do is change the parent
> of "e" to be the HEAD of the old repository.
If this is initial import, and not published anywhere, the simplest (I
think) solution would be to use grafts file (.git/info/grafts) to
change parent of 'k' from 'g' in ffa to 'g' in master, by adding the
line with:
<sha1 of 'k'> <sha1 of 'g' on master>
to .git/info/grafts. Then examine history if everything is now all
right (for example using gitk), and if everything is O.K. run
git-filter-branch.
See documentation for details.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: James Pickens @ 2008-07-24 23:38 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0807241623m3fbd476dyc41990d8ef0888e6@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
> "git checkout B10" form has already been taken. How about "git
> checkout --add-path" and "git checkout --remove-path"?
That would be fine. The specific syntax is not that important to me, as long as
the capability exists.
James
^ permalink raw reply
* Stitching together two split segments from svn
From: Liam Healy @ 2008-07-24 23:33 UTC (permalink / raw)
To: git
Hi,
I have a project whose history is stored in two separate svn
repositories. The first repository I kept privately during initial
development, the second started when I posted it publicly and does not
have the history of the first. I am trying to reunite them under git.
The development of the first was linear, so after using git svn, the
history looks like:
a - b - ... - c - d = HEAD (old repository)
and the second has one branch "ffa":
(new repository)
T - d - e - ... - f - g - h - ... - j master
\
k - l - .... - m ffa
Note that T is the "trunk" initial commit on the svn repo that has no
files. The second commit d is identical to the HEAD of old, as
verified by git diff.
However, when I remote add these two into a single repository, they
show up as two detached chains, with no connection between them. I
thought git rebase would reconnect them. However, when I do that on
each branch (master and ffa), I get the following:
a - b - ... - c - d - e - ... - f - g - h - ... - j master
\
e - ... -f - g - k - l - .... - m ffa
instead of what I would like
a - b - ... - c - d - e - ... - f - g - h - ... - j master
\
k - l - .... - m ffa
That is to say, those commits from the new repository that have a
common history for the two branches are duplicated. The commits are
listed separately and have different SHA IDs, but they are clearly the
same commits (same comments, same svn version number). Is there any
way to do what I want? Really, all I want to do is change the parent
of "e" to be the HEAD of the old repository.
Thank you.
Liam
^ permalink raw reply
* Re: Submodules: Publishing a locally created submodule.
From: Mark Levedahl @ 2008-07-24 23:30 UTC (permalink / raw)
To: git; +Cc: git mailing list
In-Reply-To: <18071eea0807240840g79da962ci8fbc65546d496323@mail.gmail.com>
Thomas Adam wrote:
> Hello all,
>
>
> Now: I want to make mysubmoduleB a submodule which I can publish to
> the shared repository and when others pull, to see that submodule and
> be able to treat it as such.
>
> But I can't see how to do that. Can someone help?
>
> Many thanks in advance.
>
> -- Thomas Adam
git submodule add <URL where this will exist> ./mysubmoduleB
will recognize that mysubmoduleB is already a valid git repo and add it as is at
the current location to the superproject.
Mark
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 23:23 UTC (permalink / raw)
To: James Pickens; +Cc: git
In-Reply-To: <loom.20080724T171151-310@post.gmane.org>
On 7/25/08, James Pickens <jepicken@gmail.com> wrote:
> > You can do that with "git checkout --path" (non-recursive checkout aside):
> >
> > $ git checkout --path=A # checkout full A
> > $ git checkout --path=A/B1/C1 # no, limit to A/B1/C1 only
> > $ git checkout --path=A/B1/C1:A/B2 # extend to A/B2 too
>
>
> My point was not that incremental checkout is impossible, just that it
> would be easier if I didn't have to re-type the full path list again.
> Suppose I had 9 directories (A/B1 through A/B9) in my sparse checkout,
> and I wanted to add a 10th directory (A/B10). It would be much easier
> to type something like
>
> $ cd A
> $ git checkout B10
>
> instead of
>
> $ git checkout --path=A/B1:A/B2:A/B3:A/B4:A/B5:A/B6:A/B7:A/B8:A/B9:A/B10
"git checkout B10" form has already been taken. How about "git
checkout --add-path" and "git checkout --remove-path"?
--
Duy
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 23:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Johannes Schindelin
In-Reply-To: <200807242201.23991.jnareb@gmail.com>
On 7/25/08, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
>
> > On 7/24/08, Jakub Narebski <jnareb@gmail.com> wrote:
> > >
> > > Second, I think you can simply special case .git* files (.gitignore,
> > > .gitattributes, .gitmodules), and always check them out for all
> > > intermediate directories (unless configured otherwise, of course).
> > > So for example if you have the following directory structure:
> > >
> > > A/.gitignore
> > > A/a
> > > A/B1/.gitignore
> > > A/B1/b
> > > A/B2/.gitignore
> > > A/B2/c
> > >
> > > and you are checking out only subdirectory 'B1' (and all files in it;
> > > if subdirectories are checked out recursively it depends on
> > > configuration), and if for example there is .gitignore in every
> > > directory, then checked out tree would look like this:
> > >
> > > A/.gitignore
> > > A/B1/.gitignore
> > > A/B1/b
> > >
> > > The ability to do this is one of advantages of 'sparse' checkout over
> > > 'subtree' checkout.
> >
> > Or teach git to use index version of those files. Or collect all those
> > files, combine them and put the result to .git/info/exclude (and
> > similar places). Anyway well organized repos won't have this problem.
> >
> > Checking some files out as read-only (like this case) may be
> > interesting. Though I do not how much complicated it can be.
>
>
> I think teaching git to use index version of .git* files (.gitignore,
> .gitattributes, .gitmodules) would be much more work than adding
> default rule that .git* files in leading directories are by default
> checked out, just like leading directories are checked out. This
> would limit modifying git code, I think, and chances for errors.
>
> Having "leading" directories and files read-only would be a good idea,
> I think.
>
> I don't understand the sentence "well organized repos won't have this
> problem". I think well organized repos _would_ have this problem,
> because of maintained and distributed top-level .gitignore and
> .gitattributes.
I wrote that with svn repos in mind. If those repos are to be
partially checked out, .svnignore would be in subdirectories rather
than at toplevel. Anyway that may not be true.
> P.S. I hope that 'sparse checkout' feature would be ready for 1.7.0
>
> --
> Jakub Narebski
> Poland
>
--
Duy
^ permalink raw reply
* Re: [PATCH 02/12] git-grep: support --no-external-grep
From: Nguyen Thai Ngoc Duy @ 2008-07-24 23:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080724202634.GB3760@blimp.local>
On 7/25/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> Nguyen Thai Ngoc Duy, Wed, Jul 23, 2008 16:55:49 +0200:
>
> >
> > +static int no_external_grep;
> > +
>
>
> If you have used direct logic instead of negative, your patch would
> have been simplier and the code would be easier to understand. I.e.:
Point taken.
> + if (!strcmp("--no-external-grep", arg)) {
> + external_grep = 0;
> + continue;
> + }
>
> BTW, how about a config option for this? And maybe --external-grep={yes|no}
I don't need --external-grep=yes now, but that would be good for
testing external grep. About config option, is it really needed?
--
Duy
^ permalink raw reply
* Re: git newbie - cloning / check out help
From: Petr Baudis @ 2008-07-24 23:15 UTC (permalink / raw)
To: Donald Brady; +Cc: git
In-Reply-To: <loom.20080724T211609-298@post.gmane.org>
Hi,
On Thu, Jul 24, 2008 at 09:24:34PM +0000, Donald Brady wrote:
> I am just ramping up on git and have the following scenario / issue:
>
> I have a git repository on server A.
>
> I clone it onto my machine B.
>
> In my local copy/repository on machine B I clone a repository on some
> third party server C.
>
> I commit my changes into B and push them to A.
>
> Now if I clone my repository from Server A onto my local machine
> in a different location I see all the source as normal but only the top
> level directory of C. Any source under that is not present.
>
> What is the magic git incantation to make sure that I check out
> not only the code from my repository but any repositories that
> are cloned into it (recursive clone?)
we call this functionality "submodules" and the quickstart howto is:
You have git repository on A
You clone it onto your machine B
git submodule add url directoryC
You commit your changes into B and push them to A
You do another clone of A and then within the clone
git submodule update --init
For further details, see git-submodule(1).
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* [PATCH] Teach fsck and prune about the new location of temporary objects
From: Brandon Casey @ 2008-07-24 22:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Since 5723fe7e, temporary objects are now created in their final destination
directories, rather than in .git/objects/. Teach fsck to recognize and
ignore the temporary objects it encounters, and teach prune to remove them.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
builtin-fsck.c | 4 ++++
builtin-prune.c | 41 ++++++++++++++++++++++++-----------------
2 files changed, 28 insertions(+), 17 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 7326dc3..7a4a4f1 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -377,6 +377,10 @@ static void fsck_dir(int i, char *path)
if (de->d_name[0] != '.')
break;
continue;
+ case 14:
+ if (prefixcmp(de->d_name, "tmp_obj_"))
+ break;
+ continue;
case 38:
sprintf(name, "%02x", i);
memcpy(name+2, de->d_name, len+1);
diff --git a/builtin-prune.c b/builtin-prune.c
index 7de4cab..947de8c 100644
--- a/builtin-prune.c
+++ b/builtin-prune.c
@@ -13,6 +13,22 @@ static const char * const prune_usage[] = {
static int show_only;
static unsigned long expire;
+static int prune_tmp_object(char *path, const char *filename)
+{
+ const char *fullpath = mkpath("%s/%s", path, filename);
+ if (expire) {
+ struct stat st;
+ if (lstat(fullpath, &st))
+ return error("Could not stat '%s'", fullpath);
+ if (st.st_mtime > expire)
+ return 0;
+ }
+ printf("Removing stale temporary file %s\n", fullpath);
+ if (!show_only)
+ unlink(fullpath);
+ return 0;
+}
+
static int prune_object(char *path, const char *filename, const unsigned char *sha1)
{
const char *fullpath = mkpath("%s/%s", path, filename);
@@ -53,6 +69,11 @@ static int prune_dir(int i, char *path)
if (de->d_name[0] != '.')
break;
continue;
+ case 14:
+ if (prefixcmp(de->d_name, "tmp_obj_"))
+ break;
+ prune_tmp_object(path, de->d_name);
+ continue;
case 38:
sprintf(name, "%02x", i);
memcpy(name+2, de->d_name, len+1);
@@ -105,23 +126,9 @@ static void remove_temporary_files(void)
dirname);
return;
}
- while ((de = readdir(dir)) != NULL) {
- if (!prefixcmp(de->d_name, "tmp_")) {
- char name[PATH_MAX];
- int c = snprintf(name, PATH_MAX, "%s/%s",
- dirname, de->d_name);
- if (c < 0 || c >= PATH_MAX)
- continue;
- if (expire) {
- struct stat st;
- if (stat(name, &st) != 0 || st.st_mtime >= expire)
- continue;
- }
- printf("Removing stale temporary file %s\n", name);
- if (!show_only)
- unlink(name);
- }
- }
+ while ((de = readdir(dir)) != NULL)
+ if (!prefixcmp(de->d_name, "tmp_"))
+ prune_tmp_object(dirname, de->d_name);
closedir(dir);
}
--
1.6.0.rc0.55.g160ae.dirty
^ permalink raw reply related
* git newbie - cloning / check out help
From: Donald Brady @ 2008-07-24 21:24 UTC (permalink / raw)
To: git
I am just ramping up on git and have the following scenario / issue:
I have a git repository on server A.
I clone it onto my machine B.
In my local copy/repository on machine B I clone a repository on some
third party server C.
I commit my changes into B and push them to A.
Now if I clone my repository from Server A onto my local machine
in a different location I see all the source as normal but only the top
level directory of C. Any source under that is not present.
What is the magic git incantation to make sure that I check out
not only the code from my repository but any repositories that
are cloned into it (recursive clone?)
Thanks
Donald
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Stephan Beyer @ 2008-07-24 22:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <20080723141224.GA17648@leksak.fem-net>
> > How you use Git
I'd also like to see a question about what kind of content is tracked
using git.
[ ] Source code
[ ] Multimedia files
[ ] LaTeX documents
[ ] Office documents
[ ] Configuration files
[ ] Web content
[ ] the whole root filesystem ;-)
[ ] Other: _________________
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Eyvind Bernhardsen @ 2008-07-24 21:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Avery Pennarun, Joshua Jensen, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807232041570.8986@racer>
On 23. juli. 2008, at 21.44, Johannes Schindelin wrote:
[...]
> I deem it not, uhm, magical. By your reasoning there should be a
> way for
> Git to convert a file to UTF-8 when some entertaining person
> converted the
> working directory file to ISO-8859-15.
Um, what? This discussion is about figuring out when Git should mess
with the line endings a user is trying to commit. Why are you
bringing character encodings into it? Git does not (to my knowledge)
have any "utf8" setting that converts all files to UTF-8, and
certainly not one that is enabled by default on Windows.
Being able to mark a file with an "enforce crlf line endings on this
file" flag is useful _given that Git messes with line endings_, and a
"do not mess with line endings in this file" flag does not achieve the
same purpose. Okay?
If you want my personal opinion on autocrlf, I was happier when Git
left line endings alone so I didn't have to worry about the files I
commit being mangled (however reversibly).
I think "autocrlf=input" can make sense on a per-repository basis, but
I would have it somewhere versioned like .gitattributes, so that (a)
it is propagated when the repository is cloned, and (b) it is possible
to take an existing repository with checked-in CRLFs and do a one-time
conversion that also adds the "autocrlf=input" setting
to .gitattributes (or wherever the setting ends up going).
I don't use "autocrlf=true", even on Windows, so I don't have any
opinion on it other than thinking it should be a per-user setting
rather than per-repository (but with a per-platform default :). I
don't see how it could work unless the repository has normalised line
endings, though.
My background: I have a ton of repositories imported from CVS with a
sordid mix of CR and CRLF (occasionally in the same file!). Using
these repositories with "autocrlf=true" is a pain in the arse since
CRLFs in the repository cause spurious changes after a clean checkout,
merge troubles, etc. The code is supposed to build on Windows as well
as Unix, so I got bit by this when msysgit changed the default
autocrlf setting. [1]
My workaround is simply to set autocrlf=false; another solution might
be to filter-branch all CRLFs out of the repository, but then I'd be
messing with a lot of history, possibly breaking the files that
actually need CRLFs, and for no real upside. No thanks.
Okay, this turned into a longer rant than I intended; what I'm trying
to say is that I think autocrlf(=true) as it is currently implemented
is pretty useless, and that a setting that is versioned and cloneable
would be better. Phew!
--
Eyvind Bernhardsen
Footnote:
1. Your impression that people were rude when "autocrlf=true" was made
the default on msysgit might be related to the fact that nobody had
considered what would happen to existing repositories before making
the change? Steffen Prohaska wrote in response to one such complaint:
> Unfortunately, existing repositories that contain the wrong line
> endings
> suffer from the problems you described above. This can be handled
> either by switching off autocrlf, as you propose, or by cleaning up
> the
> line endings.
(http://groups.google.com/group/msysgit/browse_thread/thread/978a3435c1cb0c81/70bac514a8b438ef?lnk=gst#70bac514a8b438ef
)
Steffen went on to propose a patch to make autocrlf a sticky per-
repository setting, but I think you shot it down.
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 21:08 UTC (permalink / raw)
To: Lachele Foley (Lists); +Cc: Jon Loeliger, git
In-Reply-To: <d028d8030807241150j4ce755aal53158c5c88db7078@mail.gmail.com>
On Thu, 24 Jul 2008, Lachele Foley wrote:
> 01. USA
> 02. Probably best I stick to English, but I'm willing to negotiate.
> 06. Not sure yet.
> 09. Last month. I think.
Errr... this email is _not_ a survey. It is an RFC, Request For
Comments, meant to come up with a good list of questions, and good list
of possible answers for single choice/multiple choice questions.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 21:06 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <20080724180849.GA2925@dpotapov.dyndns.org>
On Thu, 24 July 2008, Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 11:49:41PM +0200, Jakub Narebski wrote:
>> On Wed, 23 Jul 2008, Dmitry Potapov wrote:
>>> On Wed, Jul 23, 2008 at 03:25:03AM +0200, Jakub Narebski wrote:
>>>>
>>>> 02. What is your preferred non-programming language?
>>>> (or) What is the language you want computer communicate with you?
>>>
>>> IMHO, the later wording of the question is much better.
>>
>> First just satisfies demographic curiosity. Second is more question
>> about internationalization (i18n).
>
> I think demographic is largely covered by the first question about
> country. As to i18n, I don't think it is fully covered just by the
> question about one's language preference to communicate with computer
> (which is probably is more correctly to call localization). Possible
> questions related to i18n are:
> - Do you use file names with non-ASCII characters?
> - Do you use text files with non-ASCII characters?
> - Do you (or members of your team) use computers with different
> character sets and have to deal with non-ASCII characters?
>
> But I guess we do not want to have so many questions. So, maybe
> something simple instead:
> - Are you satisfied with support for non-ASCII characters in Git?
But only if it is free-form question:
xx. Are you satisfied with support for non-ASCII characters in Git?
Yes or No? If no, please explain what you had problems with.
(free form, or rather Yes/No + explanation for No)
If we decide to add more questions about translating Git, I think
we should also add the following:
xx. Which parts of Git would you like/do you need translated?
(zero or more: multiple choice)
- git-gui, gitk, manpages, user's manual, commands messages
>> Should "What version do you use now?" be multiple choice (using git
>> on more than one machine / operating system)?
>
> I think we already have another question about what OS one uses.
> So I believe it should be only version number here.
One can use Git on many different machines (for example at work, and
at home), or on multi-boot machine (with more than one operating
system). Each of those machines, and/or each of those operating
systems can use different version of Git. So that is why I think
this should be multiple choice, even if I guess that most people
would select only one answer.
>> What should be possible
>> choices for "How long do you use git?"? Perhaps.
>>
>> 10. How long do you use git?
>> (single choice)
>> - never/few days/few weeks/month/few months/year/few years/
>> from beginning/I wrote it(*)
>> + (*) just kidding ;-)
>
> I would rather use numbers like that:
>
> never
> less than month
> 1-3 months
> 3-6 months
> 6-12 months
> 1-2 year
> more than 2 years
> from the beginning
I think it is even better; I'm not sure if we shouldn't split sub-month
region, for example to provide for people who has heard of git for
first time, but played with it a little bit.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Robin Rosenberg @ 2008-07-24 20:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Steffen Prohaska, Dmitry Potapov, Junio C Hamano,
Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807241742220.8986@racer>
torsdagen den 24 juli 2008 18.45.07 skrev Johannes Schindelin:
> However, I see Junio's point: on sane platforms you have to work hard to
> get CR-damaged files. And the regular sane platform user should not be
> punished for the brain/CR damage a certain monopolist has brought over
> this planet.
That wasn't hard at all :) Eclipse did it all by itself for JEE MANIFEST.MF files.
We got into some strange problems on windows with msysgit after that where git
(status) detected the files as changed, but no actual content change and refused
to change it's mind. I think we had actually fixed the files on Windows prior to that.
Only after converting the checkout to autocrlf=input did msysgit enter a sane state
again. I was not able to repeat the problem at the time.
Maybe I'll try again in a few weeks time.
-- robin
^ permalink raw reply
* Re: git rebase to move a batch of patches onto the current branch
From: Avery Pennarun @ 2008-07-24 20:42 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20080724203049.GC3760@blimp.local>
On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> Avery Pennarun, Thu, Jul 24, 2008 22:16:06 +0200:
> > On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
>
> > > gcp3 ()
> > > {
> > > git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
> > > }
> >
> > But that'll give up when there are conflicts, right? git-rebase lets
> > me fix them in a nice way.
>
> No, it same as in rebase. You'll fix them and do "git am --resolved".
> See manpage of git am.
Hmm, cool.
So that command isn't too easy to come upon by accident. If I wanted
to submit a patch to make this process a bit more obvious, would it
make sense to simply have git-cherry-pick call that sequence when you
give it more than one commit?
Hmm, I suppose not, since git-am is a shellscript and cherry-pick is
currently a builtin, so it would be kind of a step backwards.
Thanks,
Avery
^ permalink raw reply
* Re: [PATCH 7/9] builtin-checkout-index.c: use parse_options()
From: Sverre Rabbelier @ 2008-07-24 20:35 UTC (permalink / raw)
To: Michele Ballabio; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <200807242208.37192.barra_cuda@katamail.com>
On Thu, Jul 24, 2008 at 10:08 PM, Michele Ballabio
<barra_cuda@katamail.com> wrote:
> On Thursday 24 July 2008, Johannes Schindelin wrote:
>> On Wed, 23 Jul 2008, Michele Ballabio wrote:
>>
>> > + { OPTION_CALLBACK, 'f', "force", &state, NULL,
>> > + "force overwrite of existing files",
>> > + PARSE_OPT_NOARG, parse_state_force_cb, 0 },
>>
>> I wonder if this could not be written as
>>
>> OPT_BOOLEAN('f', "force", &state.force,
>> "force overwrite of existing files"),
>
> I did it that way because 'force' is a bitfield.
I thought there is an OPT_BIT?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git rebase to move a batch of patches onto the current branch
From: Alex Riesen @ 2008-07-24 20:30 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Git Mailing List
In-Reply-To: <32541b130807241316x4f85bcdfw12857be575fb3289@mail.gmail.com>
Avery Pennarun, Thu, Jul 24, 2008 22:16:06 +0200:
> On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> > gcp3 ()
> > {
> > git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
> > }
>
> But that'll give up when there are conflicts, right? git-rebase lets
> me fix them in a nice way.
>
No, it same as in rebase. You'll fix them and do "git am --resolved".
See manpage of git am.
^ permalink raw reply
* Re: [PATCH 02/12] git-grep: support --no-external-grep
From: Alex Riesen @ 2008-07-24 20:26 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20080723145549.GA29067@laptop>
Nguyễn Thái Ngọc Duy, Wed, Jul 23, 2008 16:55:49 +0200:
>
> +static int no_external_grep;
> +
If you have used direct logic instead of negative, your patch would
have been simplier and the code would be easier to understand. I.e.:
+static int external_grep = 1;
> @@ -386,7 +388,7 @@ static int grep_cache(struct grep_opt *opt, const char **paths, int cached)
> * we grep through the checked-out files. It tends to
> * be a lot more optimized
> */
> - if (!cached) {
> + if (!cached && !no_external_grep) {
+ if (!cached && external_grep) {
> @@ -544,6 +546,10 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> cached = 1;
> continue;
> }
> + if (!strcmp("--no-external-grep", arg)) {
> + no_external_grep = 1;
> + continue;
> + }
+ if (!strcmp("--no-external-grep", arg)) {
+ external_grep = 0;
+ continue;
+ }
BTW, how about a config option for this? And maybe --external-grep={yes|no}
^ permalink raw reply
* Re: git rebase to move a batch of patches onto the current branch
From: Avery Pennarun @ 2008-07-24 20:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20080724201333.GA3760@blimp.local>
On 7/24/08, Alex Riesen <raa.lkml@gmail.com> wrote:
> Avery Pennarun, Thu, Jul 24, 2008 21:57:03 +0200:
>
> > I often find myself being on a branch and wanting to do the equivalent
> > of a series of cherry-picks from another branch into the current one.
> > Unfortunately, "git cherry-pick" only does one patch at a time (which
> > is very tedious), and "git rebase", which is much less tedious to use,
> > seems to specializing in applying your current branch on top of
> > another branch, not the other way around.
>
> Try this:
>
> $ type gcp3
> gcp3 is a function
> gcp3 ()
> {
> git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
> }
But that'll give up when there are conflicts, right? git-rebase lets
me fix them in a nice way.
Avery
^ permalink raw reply
* [PATCH] Do not use ctime if file mode is not used
From: Alex Riesen @ 2008-07-24 19:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <7vr69lihkt.fsf@gitster.siamese.dyndns.org>
On some file systems, the only part of inode information we need
(executable) cannot be used, so ctime can be ignored as well. Change
time is updated when file attributes were changed (or it is written
to, but in this case, mtime is updated as well).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Junio C Hamano, Wed, Jul 23, 2008 02:12:50 +0200:
> > I had that at first (NO_DEPENDABLE_CTIME, than IGNORE_CTIME), than
> > deemed it excessive.
>
> Why is it excessive? My initial reaction was "what does trustable
> filemode nor trust_executable_bit has anything to do with ctime". Please
> explain.
You know, you have a good point... (and I'm sometimes really stupid)
Of course it depends on the underlying filesystem!
The updated patch is untested yet, but should be obviously correct.
BTW, any idea how to check if all callers of ce_match_stat_basic have
read the configuration? It is not that essential to have
trust_executable_bit set correctly, though. In worst case an index
entry will be marked not up-to-date.
read-cache.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index a50a851..f2fa0d9 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -181,7 +181,7 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
}
if (ce->ce_mtime != (unsigned int) st->st_mtime)
changed |= MTIME_CHANGED;
- if (ce->ce_ctime != (unsigned int) st->st_ctime)
+ if (trust_executable_bit && ce->ce_ctime != (unsigned int) st->st_ctime)
changed |= CTIME_CHANGED;
if (ce->ce_uid != (unsigned int) st->st_uid ||
--
1.6.0.rc0.70.g5aae9
^ permalink raw reply related
* Re: git rebase to move a batch of patches onto the current branch
From: Alex Riesen @ 2008-07-24 20:13 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Git Mailing List
In-Reply-To: <32541b130807241257j7820a591if8ca01c66bbcd6b2@mail.gmail.com>
Avery Pennarun, Thu, Jul 24, 2008 21:57:03 +0200:
> I often find myself being on a branch and wanting to do the equivalent
> of a series of cherry-picks from another branch into the current one.
> Unfortunately, "git cherry-pick" only does one patch at a time (which
> is very tedious), and "git rebase", which is much less tedious to use,
> seems to specializing in applying your current branch on top of
> another branch, not the other way around.
Try this:
$ type gcp3
gcp3 is a function
gcp3 ()
{
git format-patch -k --stdout --full-index "$@" | git am -k -3 --binary
}
^ 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