* Re: [FAQ?] Rationale for git's way to manage the index
From: Julian Phillips @ 2007-05-06 22:53 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqbqgxak1i.fsf@bauges.imag.fr>
On Sun, 6 May 2007, Matthieu Moy wrote:
> The reason why I'm posting this is that I was wondering whether
> "commit -a" not being the default was supposed to be a message like
> "you shouln't use it too often".
Well, personally I practically never use it, I find that having a
separation between what the current state of my tree is and what will be
comitted to be one of the really "oh wow, why doens't everything else do
this?" features. However, i tend to be working on more than one thing at
once, and switch between them - so I commit work on A while work on B is
still unfinished, then start C, finish B some point later and commit it,
and then I can finish C. Git is the first VCS that supports a butterfly
mind :P.
> It seems it isn't. I'll just get used to "commit -a" (and probably
> alias it), and discover the actual benefits of the index little by
> little.
"git add -i" - this is a feature I have wanted since I started using
version control ...
--
Julian
---
Your good nature will bring you unbounded happiness.
^ permalink raw reply
* Re: [PATCH] connect: display connection progress
From: Alex Riesen @ 2007-05-06 22:21 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git
In-Reply-To: <20070506195230.GA30339@mellanox.co.il>
Michael S. Tsirkin, Sun, May 06, 2007 21:52:30 +0200:
> Make git notify the user about host resolution/connection attempts. This
> is useful both as a progress indicator on slow links, and helps reassure the
> user there are no DNS/firewall problems.
If there DNS problems, it is usually useful to show which address was
used. And what errors were, exactly (not just errno, but h_errno too).
And which one of many, BTW. Maybe this below could be of help:
diff --git a/connect.c b/connect.c
index da89c9c..34c26bb 100644
--- a/connect.c
+++ b/connect.c
@@ -391,6 +391,23 @@ static enum protocol get_protocol(const char *name)
#ifndef NO_IPV6
+static const char *ai_name(const struct addrinfo *ai)
+{
+ static char addr[INET_ADDRSTRLEN];
+ if ( AF_INET == ai->ai_family ) {
+ struct sockaddr_in *in;
+ in = (struct sockaddr_in *)ai->ai_addr;
+ inet_ntop(ai->ai_family, &in->sin_addr, addr, sizeof(addr));
+ } else if ( AF_INET6 == ai->ai_family ) {
+ struct sockaddr_in6 *in;
+ in = (struct sockaddr_in6 *)ai->ai_addr;
+ inet_ntop(ai->ai_family, &in->sin6_addr, addr, sizeof(addr));
+ } else {
+ strcpy(addr, "(unknown)");
+ }
+ return addr;
+}
+
/*
* Returns a connected socket() fd, or else die()s.
*/
@@ -401,6 +418,7 @@ static int git_tcp_connect_sock(char *host)
const char *port = STR(DEFAULT_GIT_PORT);
struct addrinfo hints, *ai0, *ai;
int gai;
+ int cnt = 0;
if (host[0] == '[') {
end = strchr(host + 1, ']');
@@ -438,10 +456,17 @@ static int git_tcp_connect_sock(char *host)
}
if (connect(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
saved_errno = errno;
+ fprintf(stderr, "%s[%d: %s]: net=%s, errno=%s\n",
+ host,
+ cnt,
+ ai_name(ai),
+ hstrerror(h_errno),
+ strerror(saved_errno));
close(sockfd);
sockfd = -1;
continue;
}
+ fprintf(stderr, "using %s[%s]\n", host, ai_name(ai));
break;
}
@@ -467,6 +492,7 @@ static int git_tcp_connect_sock(char *host)
struct sockaddr_in sa;
char **ap;
unsigned int nport;
+ int cnt;
if (host[0] == '[') {
end = strchr(host + 1, ']');
@@ -497,7 +523,7 @@ static int git_tcp_connect_sock(char *host)
nport = se->s_port;
}
- for (ap = he->h_addr_list; *ap; ap++) {
+ for (cnt = 0, ap = he->h_addr_list; *ap; ap++, cnt++) {
sockfd = socket(he->h_addrtype, SOCK_STREAM, 0);
if (sockfd < 0) {
saved_errno = errno;
@@ -511,10 +537,19 @@ static int git_tcp_connect_sock(char *host)
if (connect(sockfd, (struct sockaddr *)&sa, sizeof sa) < 0) {
saved_errno = errno;
+ fprintf(stderr, "%s[%d: %s]: net=%s, errno=%s\n",
+ host,
+ cnt,
+ inet_ntoa(*(struct in_addr *)&sa.sin_addr),
+ hstrerror(h_errno),
+ strerror(saved_errno));
close(sockfd);
sockfd = -1;
continue;
}
+ fprintf(stderr, "using %s[%s]\n",
+ host,
+ inet_ntoa(*(struct in_addr *)&sa.sin_addr));
break;
}
^ permalink raw reply related
* Re: [PATCH] submodule merge support
From: Linus Torvalds @ 2007-05-06 22:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: Martin Waitz, Junio C Hamano, git
In-Reply-To: <20070506220745.GA2439@steel.home>
On Mon, 7 May 2007, Alex Riesen wrote:
> Martin Waitz, Sun, May 06, 2007 21:02:24 +0200:
> > When merge-recursive gets to a dirlink, it starts an automatic
> > submodule merge and then uses the resulting merge commit for the
> > top-level tree.
>
> merge-recursive is a mess already, you just made even more so.
> Besides, you completely forgot all other merge strategies.
>
> How about making all existing strategies just ignore submodules, and
> move recursive merge in the merge driver (git-merge.sh)?
Yes, I think that's the right thing to do.
I think it's the right thing for another reason: in a true "recursive"
merge, the submodules shouldn't be recursively merged anyway. *THEIR*
merge will have its own history, and doing it based on some random history
of the superproject is actually wrong anyway!
Linus
^ permalink raw reply
* Re: [PATCH] submodule merge support
From: Martin Waitz @ 2007-05-06 22:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20070506220745.GA2439@steel.home>
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
hoi :)
On Mon, May 07, 2007 at 12:07:45AM +0200, Alex Riesen wrote:
> Martin Waitz, Sun, May 06, 2007 21:02:24 +0200:
> > When merge-recursive gets to a dirlink, it starts an automatic
> > submodule merge and then uses the resulting merge commit for the
> > top-level tree.
>
> merge-recursive is a mess already, you just made even more so.
> Besides, you completely forgot all other merge strategies.
>
> How about making all existing strategies just ignore submodules, and
> move recursive merge in the merge driver (git-merge.sh)?
Well, I don't think it can be done in the merge driver but it does make
sense to consolidate all the low-level file-based merging (and the new
submodule merge is exactly that) between merge strategies.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] submodule merge support
From: Alex Riesen @ 2007-05-06 22:07 UTC (permalink / raw)
To: Martin Waitz; +Cc: Junio C Hamano, git
In-Reply-To: <20070506190224.GG30511@admingilde.org>
Martin Waitz, Sun, May 06, 2007 21:02:24 +0200:
> When merge-recursive gets to a dirlink, it starts an automatic
> submodule merge and then uses the resulting merge commit for the
> top-level tree.
merge-recursive is a mess already, you just made even more so.
Besides, you completely forgot all other merge strategies.
How about making all existing strategies just ignore submodules, and
move recursive merge in the merge driver (git-merge.sh)?
^ permalink raw reply
* Re: [PATCH] diff: release blobs after generating textual diff.
From: Robin Rosenberg @ 2007-05-06 21:36 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.99.0705061301190.24220@xanadu.home>
söndag 06 maj 2007 skrev Nicolas Pitre:
> On Sun, 6 May 2007, Junio C Hamano wrote:
>
> > This reduces the memory pressure when dealing with many paths.
> >
> > An unscientific test of running "diff-tree --stat --summary -M"
> > between v2.6.19 and v2.6.20-rc1 in the linux kernel repository
> > indicates that the number of minor faults are reduced by 2/3
> > (153k vs 49k).
> >
> > Signed-off-by: Junio C Hamano <junkio@cox.net>
> > ---
> >
> > * This is still a WIP, not in the sense that it breaks anything
> > (it doesn't seem to), but in the sense that it is not known
> > if it is useful in general and would make that much of a
> > difference with a project much larger than the kernel.
>
> This can only be good. People are really starting to use Git with
> gigantic repos on limited memory hardware.
This did wonders on the usually unreasonable diffs on huge repos. The openoffice
diff mentioned in the openoffice thread went from 6 to ~3 minutes, and most importantly
the computer was perfectly usable meanwhile. Git memory usage dropped from 1,7GB to
400MB.
A more reasonable test diffing against a recent branch , master vs v33M4-patches, in
the eclipse repo some of you have didn't gain much in performance, but memory usage
dropped from 700MB to a peak just under 400MB, which makes a huge difference in
responsiveness for the other applications that I have, since they were not swapped out
during the diff.
-- robin
^ permalink raw reply
* [PATCH] Added a reference to git-add in the documentation for git-update-index
From: Matthieu Moy @ 2007-05-06 21:11 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <11784859173725-git-send-email-Matthieu.Moy@imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-update-index.txt | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index cd5e014..6cfbd9a 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -27,6 +27,9 @@ Modifies the index or directory cache. Each file mentioned is updated
into the index and any 'unmerged' or 'needs updating' state is
cleared.
+See also gitlink:git-add[1] for a more user-friendly way to do some of
+the most common operations on the index.
+
The way "git-update-index" handles files it is told about can be modified
using the various options:
@@ -306,7 +309,8 @@ The command looks at `core.ignorestat` configuration variable. See
See Also
--------
-gitlink:git-config[1]
+gitlink:git-config[1],
+gitlink:git-add[1]
Author
--
1.5.1.3
^ permalink raw reply related
* [PATCH] Document "commit --only".
From: Matthieu Moy @ 2007-05-06 21:11 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <11784859182473-git-send-email-Matthieu.Moy@imag.fr>
The documentation was there earlier, but removed by
4170a19587280eeb3663a47a6fd993910de78076.
That option being the default now, it could perhaps be actually
removed, but since it is there, and mentionned in the SYNOPSIS, it
should be actually documented.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-commit.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index d024c03..0bdf794 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -116,6 +116,11 @@ but can be used to amend a merge commit.
as well. This is usually not what you want unless you
are concluding a conflicted merge.
+-o|--only::
+ Commit only the files specified on the command line.
+ This format cannot be used during a merge. This is the
+ default.
+
-q|--quiet::
Suppress commit summary message.
--
1.5.1.3
^ permalink raw reply related
* [PATCH] Document the fact that commit -a is the way to go for simple operations
From: Matthieu Moy @ 2007-05-06 21:11 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-commit.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 2895225..d024c03 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -54,7 +54,8 @@ OPTIONS
-a|--all::
Tell the command to automatically stage files that have
been modified and deleted, but new files you have not
- told git about are not affected.
+ told git about are not affected. You should use it for most
+ trivial operations.
-c or -C <commit>::
Take existing commit object, and reuse the log message
--
1.5.1.3
^ permalink raw reply related
* [PATCH] Document git add -u introduced earlier.
From: Matthieu Moy @ 2007-05-06 21:11 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <11784859173386-git-send-email-Matthieu.Moy@imag.fr>
This command was implemented, but not documented in
dfdac5d9b877641d3aad8ec49f64c2730a3487e3.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-add.txt | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 755d718..ea27018 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -7,7 +7,7 @@ git-add - Add file contents to the changeset to be committed next
SYNOPSIS
--------
-'git-add' [-n] [-v] [-f] [--interactive | -i] [--] <file>...
+'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] <file>...
DESCRIPTION
-----------
@@ -56,6 +56,10 @@ OPTIONS
Add modified contents in the working tree interactively to
the index.
+-u::
+ Update all files that git already knows about. This is what
+ "git commit -a" does in preparation for making a commit.
+
\--::
This option can be used to separate command-line options from
the list of files, (useful when filenames might be mistaken
--
1.5.1.3
^ permalink raw reply related
* Re: [PATCH] Make --color available to git-status
From: Jeff King @ 2007-05-06 20:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, git
In-Reply-To: <Pine.LNX.4.64.0705051956200.4015@racer.site>
On Sat, May 05, 2007 at 07:58:45PM +0200, Johannes Schindelin wrote:
> AFAIR there have been attempts to enable this by default, when git-status
> is run interactively (i.e. its output is not piped). However, this proved
> to be remarkably complex, given that the output of runstatus _is_ piped.
I have been running with "status.color" set to "auto" for months, and it
works fine. git-status sends the output of runstatus to stdout; only
git-commit saves it in a file. However, that is irrelevant here since
git-commit explicitly turns off color anyway. The reason for this is
that the result ends up in the user's editor and in the commit object.
In the editor, it is more elegant to do syntax highlighting at that
level (otherwise you have to edit around the escape codes). For the
commit object, we would have to put in code to strip the colorization.
My biggest complaint is that git-commit shows the runstatus output to
the user if there is nothing to commit, but it isn't colorized (because
we created it with the intent of running the editor on it). This could
be fixed at the expense of slightly more CPU by simply re-running
runstatus instead of using the saved copy.
> IMHO the proper solution would be to go the full nine yards, and teach
> runstatus about the remaining parts of git-status. Then, automatic color
> works automatically.
When I rewrote runstatus in C, it was always my intent that it just be a
first step in turning git-status into a C builtin (with the ultimate
goal of improving the output by parallel walking the HEAD, index, and
working tree). Unfortunately, I don't seem to have gotten around to
it...
-Peff
^ permalink raw reply
* Re: [PATCH] connect: display connection progress
From: Junio C Hamano @ 2007-05-06 20:41 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20070506195230.GA30339@mellanox.co.il>
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> Make git notify the user about host resolution/connection attempts. This
> is useful both as a progress indicator on slow links, and helps reassure the
> user there are no DNS/firewall problems.
>
> Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
>
> ---
>
> I find the following useful.
> This currently only covers native git protocol. I expect it would
> be easy to extend this to other protocols, if there's interest.
> Opinions?
I think giving this kind of feedback makes a lot of sense, from
both the "assurance" point of view and also debuggability.
But please do this only under verbose, or squelch it if "quiet"
is asked.
^ permalink raw reply
* Re: [PATCH 2/3] dir.c: Omit non-excluded directories with dir->show_ignored
From: Michael Spang @ 2007-05-06 20:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0705061239460.25245@woody.linux-foundation.org>
Linus Torvalds wrote:
>
> On Sun, 6 May 2007, Michael Spang wrote:
>> @@ -461,7 +462,7 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
>> memcpy(fullname + baselen, de->d_name, len+1);
>> if (simplify_away(fullname, baselen + len, simplify))
>> continue;
>> - if (excluded(dir, fullname) != dir->show_ignored) {
>> + if ((exclude = excluded(dir, fullname)) != dir->show_ignored) {
>
> Style issue: please write this as
>
> exclude = excluded(dir, fullname);
> if (exclude != dir->show_ignored) {
>
> instead.
Okay. Will fixup after waiting a bit for more comments.
Thanks,
Michael Spang
^ permalink raw reply
* Re: Git benchmarks at OpenOffice.org wiki
From: Robin Rosenberg @ 2007-05-06 20:05 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Johannes Schindelin, Florian Weimer, git
In-Reply-To: <46a038f90705030348o260fbe6cwc92d07778269c937@mail.gmail.com>
torsdag 03 maj 2007 skrev Martin Langhoff:
> [resend - correcting a couple of typos and addressing git@vger
> correctly - apologies]
>
> On 5/3/07, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> > The reason is simple. I have a lousy one gigabyte RAM only, while
> > git wants 1.7GB virtual to do the diff-stat. and 800 MB resident. The swap is having a party,
>
> That is true, unfortunately. git will fly if it can fit its working
> set plus the kernel stat cache for your working tree in memory. And
> the underlying assumption is that for large trees you'll have gobs of
> RAM. If things don't fit, it does get rather slow...
>
> But... just to put things in perspective, how long does it take to
> *compile* that checkout on that same laptop. I remember reading
> instructions to the tune of "don't even try to compile this with less
> than 4GB RAM, a couple of CPUs and 12hs". Those were for the OSX build
> IIRC.
No idea. I wouldn't try it without distcc and ccache anyway which makes the
capabilities of this particular machine less relevant.
> Ah - it's moved to the general instructions: "Building OOo takes some
> time (approx 10-12 hours on standard desktop PC) ":
> http://wiki.services.openoffice.org/wiki/Building_OpenOffice.org#Starting_the_real_build
>
> So I don't think anyone working on projects the size of the kernel or
> OO.org is going to be happy with 1GB RAM.
The kernel 2.6 repo isn't in the same ball park wrt to size. Hacking the kernel is quite fine
on this machine and even smaller though the first compile takes some time. Having more
is always fun though.
Consider another huge project like Eclipse. Similar operations take a loong time (not anywhere
near the eons that CVS need, but...) and building Eclipse with 1GB i very reasonable so sheer
project size does not per se demand powerful computers. KDE is another huge project that
is reasonable to build with 1GB. The first time is somewhat painful, but rebuilding is not.
-- robin
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Linus Torvalds @ 2007-05-06 19:54 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqbqgxak1i.fsf@bauges.imag.fr>
On Sun, 6 May 2007, Matthieu Moy wrote:
>
> Well, git's index still tells more than "the content FOOBAR exists,
> somewhere". It also "contains", if not "points to", the file name.
Indeed.
Git's index is basically very much defined as
- sufficient to contain the total "content" of the tree (and this
includes all metadata: the filename, the mode, and the file contents
are all *parts* of the "content", and they are all meaningless on their
own!)
- additional "stat" information to allow the obvious and trivial (but
hugely important!) filesystem comparison optimizations.
So you really should see it as *being* the content. The content is not the
"file name" or the "file content" as separate parts. You really cannot
separate the two. Filenames on their own make no sense (they have to have
file content too), and file content on its own is similarly senseless (you
have to know how to reach it).
What I'm trying to say is that git fundmaentally doesn't _allow_ you to
see a filename without its content. The whole notion is insane and not
valid. It has no relevance for "reality".
Also, you should realize that when you do
git add X
you are *not* adding the filename X. No, "X" is literally a "content path
pattern", the same way it is when you do something like
gitk X
and it's worth always keeping in mind that in neither case is "X"
necessarily a single file, but literally a pathname pattern that is used
as a "filter" on all the possible patterns.
(Of course, the filtering rules are different for "git add" and "gitk": in
the "git add" example, you filter the working tree files, while in "gitk"
you filter the files that git already knows about, so they are different,
but in both cases you really should think of them as filters, not as
"filenames", even though one _trivial_ filter is to give a filter that
matches exactly one pathname).
> The reason why I'm posting this is that I was wondering whether
> "commit -a" not being the default was supposed to be a message like
> "you shouln't use it too often".
No, "git commit -a" is undoubtedly _convenient_. You can use it as often
as you like.
So as long as you see it as a convenience feature, and realize that "git
commit" is actually a lot more powerful than just being able to always do
the convenient, go on and use "git commit -a" all the time.
When you hit a situation where you want to do something slightly subtler,
you'll suddenly be really happy that you always had the convenience
feature, but that git didn't make you think that it was how you _had_ to
work.
> > [...] it basically could be used ass a definition of CVS: [...]
> ^^^
> Not sure this was intentional, but your spelling of "as" when used to
> talk about CVS seems to reveal something about your state of mind ;-).
Indeed ;)
Freudian slip. But yes, I'm really down on CVS. The only thing I like less
than CVS is SVN, and that's just because I think it's such a sad waste,
not because it's actually _worse_ than CVS. (Ie I dislike SVN from a "it
could have been so much better" perspective).
Linus
^ permalink raw reply
* [PATCH] connect: display connection progress
From: Michael S. Tsirkin @ 2007-05-06 19:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Make git notify the user about host resolution/connection attempts. This
is useful both as a progress indicator on slow links, and helps reassure the
user there are no DNS/firewall problems.
Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
---
I find the following useful.
This currently only covers native git protocol. I expect it would
be easy to extend this to other protocols, if there's interest.
Opinions?
diff --git a/connect.c b/connect.c
index da89c9c..f026713 100644
--- a/connect.c
+++ b/connect.c
@@ -425,9 +425,11 @@ static int git_tcp_connect_sock(char *host)
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
+ fprintf(stderr, "Looking up %s ... ", host);
gai = getaddrinfo(host, port, &hints, &ai);
if (gai)
die("Unable to look up %s (port %s) (%s)", host, port, gai_strerror(gai));
+ fprintf(stderr, "done.\nConnecting to %s (port %s) ... ", host, port);
for (ai0 = ai; ai; ai = ai->ai_next) {
sockfd = socket(ai->ai_family,
@@ -450,6 +452,8 @@ static int git_tcp_connect_sock(char *host)
if (sockfd < 0)
die("unable to connect a socket (%s)", strerror(saved_errno));
+ fprintf(stderr, "done.\n");
+
return sockfd;
}
--
MST
^ permalink raw reply related
* Re: How to set git commit timestamp
From: Robin Rosenberg @ 2007-05-06 19:51 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705061759210.8165@bianca.dialin.t-online.de>
söndag 06 maj 2007 skrev Guido Ostkamp:
> Hello,
>
> does somebody know a method to specify a timestamp for a 'git commit'?
>
> I am writing a tool to convert from another SCM to git and need to replay
> all checkins. I know how to set the log message and the author, but there
> appears to be no command option for the timestamp (Mercurial for example,
> has a 'hg commit -d date <file>' syntax for this).
If you are writing a converter then you should really use the plumbing
commands rather than porcelains like git-commit and in particular you should
look at git-fast-import for a really fast methord of importing (and packing)
objects.
-- robin
^ permalink raw reply
* [PATCH] t7300: Basic tests for git-clean
From: Michael Spang @ 2007-05-06 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vlkg1bw17.fsf@assigned-by-dhcp.cox.net>
This tests the -d, -n, -f, -x, and -X options to git-clean.
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
---
This replaces 1/3 and the "amend".
I guess this is the desired format? The email you sent seemed to have
spaces on one of the lines, the others had tabs so I am using tabs.
t/t7300-clean.sh | 180 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 180 insertions(+), 0 deletions(-)
create mode 100755 t/t7300-clean.sh
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
new file mode 100755
index 0000000..5c31e94
--- /dev/null
+++ b/t/t7300-clean.sh
@@ -0,0 +1,180 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Michael Spang
+#
+
+test_description='git-clean basic tests'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ mkdir -p src &&
+ touch src/part1.c Makefile &&
+ echo build >> .gitignore &&
+ echo *.o >> .gitignore &&
+ git-add . &&
+ git-commit -m setup &&
+ touch src/part2.c README &&
+ git-add .
+
+'
+
+test_expect_success 'git-clean' '
+
+ mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test ! -e a.out &&
+ test ! -e src/part3.c &&
+ test -f docs/manual.txt &&
+ test -f obj.o &&
+ test -f build/lib.so
+
+'
+
+test_expect_success 'git-clean -n' '
+
+ mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -n &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test -f a.out &&
+ test -f src/part3.c &&
+ test -f docs/manual.txt &&
+ test -f obj.o &&
+ test -f build/lib.so
+
+'
+
+test_expect_success 'git-clean -d' '
+
+ mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -d &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test ! -e a.out &&
+ test ! -e src/part3.c &&
+ test ! -e docs &&
+ test -f obj.o &&
+ test -f build/lib.so
+
+'
+
+test_expect_success 'git-clean -x' '
+
+ mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -x &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test ! -e a.out &&
+ test ! -e src/part3.c &&
+ test -f docs/manual.txt &&
+ test ! -e obj.o &&
+ test -f build/lib.so
+
+'
+
+test_expect_success 'git-clean -d -x' '
+
+ mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -d -x &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test ! -e a.out &&
+ test ! -e src/part3.c &&
+ test ! -e docs &&
+ test ! -e obj.o &&
+ test ! -e build
+
+'
+
+test_expect_success 'git-clean -X' '
+
+ mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -X &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test -f a.out &&
+ test -f src/part3.c &&
+ test -f docs/manual.txt &&
+ test ! -e obj.o &&
+ test -f build/lib.so
+
+'
+
+test_expect_success 'git-clean -d -X' '
+
+ mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -d -X &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test -f a.out &&
+ test -f src/part3.c &&
+ test -f docs/manual.txt &&
+ test ! -e obj.o &&
+ test ! -e build
+
+'
+
+test_expect_success 'clean.requireForce' '
+
+ git-config clean.requireForce true &&
+ ! git-clean
+
+'
+
+test_expect_success 'clean.requireForce and -n' '
+
+ mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -n &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test -f a.out &&
+ test -f src/part3.c &&
+ test -f docs/manual.txt &&
+ test -f obj.o &&
+ test -f build/lib.so
+
+'
+
+test_expect_success 'clean.requireForce and -f' '
+
+ git-clean -f &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test ! -e a.out &&
+ test ! -e src/part3.c &&
+ test -f docs/manual.txt &&
+ test -f obj.o &&
+ test -f build/lib.so
+
+'
+
+test_done
--
1.5.2.rc1.4.g47e1
^ permalink raw reply related
* Re: [PATCH 2/3] dir.c: Omit non-excluded directories with dir->show_ignored
From: Linus Torvalds @ 2007-05-06 19:42 UTC (permalink / raw)
To: Michael Spang; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <463E19D4.4030400@uwaterloo.ca>
On Sun, 6 May 2007, Michael Spang wrote:
> @@ -461,7 +462,7 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
> memcpy(fullname + baselen, de->d_name, len+1);
> if (simplify_away(fullname, baselen + len, simplify))
> continue;
> - if (excluded(dir, fullname) != dir->show_ignored) {
> + if ((exclude = excluded(dir, fullname)) != dir->show_ignored) {
Style issue: please write this as
exclude = excluded(dir, fullname);
if (exclude != dir->show_ignored) {
instead.
Yes, both are valid C, and mean the same thing, but one is much more
readable than the other.
Combining multiple things inside an if-statement is convenient if:
- the things inside are _really_ trivial.
- it's done as part of macro expansion etc (ie it's not visible as such,
and the code is readable in its pre-preprocessor format)
but it's not good form otherwise.
Linus
^ permalink raw reply
* Re: [PATCH(amend)] Really run "git-clean -n" in test
From: Junio C Hamano @ 2007-05-06 19:18 UTC (permalink / raw)
To: Michael Spang; +Cc: Git Mailing List
In-Reply-To: <463E27BC.5060604@uwaterloo.ca>
Michael Spang <mspang@uwaterloo.ca> writes:
> Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
> ---
>
> Whoops.
>
> t/t7300-clean.sh | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
Oops indeed.
* This is not an "amend"; you are following up an earlier patch of
your own. Marking such a patch as "amend" is only confusing.
Please do not do it.
> test_expect_failure \
> 'clean.requireForce' \
> - "mkdir -p build docs &&
> - touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
> - git-config clean.requireForce true &&
> + "git-config clean.requireForce true &&
> git-clean"
* Please do not do this. test_expect_failure, unless used for a
very simple single test, is almost always a bug. You would
not know which step of && chain failed, even though you may be
expecting the failure from the last one.
* I do not think a "this reformats every existing tests" patch
is needed nor wanted, but at least I'd like to see new scripts
and updates to the existing ones to be consistently formatted
like this:
test_expect_success 'name of the test' '
test body goes here &&
like this &&
and this
'
^ permalink raw reply
* Re: [PATCH/RFD 4/3] t7300: Tests for git-clean using filenames with spaces/punctuation
From: Michael Spang @ 2007-05-06 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vr6ptbx5g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Michael Spang <mspang@uwaterloo.ca> writes:
>
>> Is this even properly solvable without making clean a builtin or
>> writing git-unescape?
>
> If you know how to use "xargs -0" and are willing to depend on
> the -0 GNU extension, then the answer is yes.
Right. But I do not think xargs can call a shell function. git-clean
does not just call git-rm directly. I guess git-clean could call
itself through xargs, but that might become confusing.
> I do not use git-clean myself, as I do not see what (I think) it
> tries to solve as a problem to begin with, so obviously I do not
> care too deeply about the command's implementation --- I just
> let it be there because there seem to be others who want it ---
> but if I were asked an advice on the right direction to proceed,
> I would probably suggest rewriting it in C.
That seems like the cleanest solution to me as well.
Cheers,
Michael Spang
^ permalink raw reply
* [PATCH(amend)] Really run "git-clean -n" in test
From: Michael Spang @ 2007-05-06 19:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <463E19C4.8010601@uwaterloo.ca>
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
---
Whoops.
t/t7300-clean.sh | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 1fb3850..1ada8da 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -125,14 +125,15 @@ test_expect_success \
test_expect_failure \
'clean.requireForce' \
- "mkdir -p build docs &&
- touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
- git-config clean.requireForce true &&
+ "git-config clean.requireForce true &&
git-clean"
test_expect_success \
'clean.requireForce and -n' \
- "test -f Makefile &&
+ "mkdir -p build docs &&
+ touch a.out src/part3.c docs/manual.txt obj.o build/lib.so &&
+ git-clean -n &&
+ test -f Makefile &&
test -f README &&
test -f src/part1.c &&
test -f src/part2.c &&
^ permalink raw reply related
* [PATCH] submodule merge support
From: Martin Waitz @ 2007-05-06 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When merge-recursive gets to a dirlink, it starts an automatic submodule merge
and then uses the resulting merge commit for the top-level tree.
The submodule merge is done in another process to decouple object databases.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
.gitignore | 1 +
Makefile | 2 +-
git-dirlink-merge.sh | 28 ++++++++++++++++++++++++++++
merge-recursive.c | 36 ++++++++++++++++++++++++++++++++++++
4 files changed, 66 insertions(+), 1 deletions(-)
create mode 100644 git-dirlink-merge.sh
diff --git a/.gitignore b/.gitignore
index 8436a83..b076e2f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -38,6 +38,7 @@ git-diff-files
git-diff-index
git-diff-tree
git-dirlink-checkout
+git-dirlink-merge
git-describe
git-fast-import
git-fetch
diff --git a/Makefile b/Makefile
index fcd0125..ff24477 100644
--- a/Makefile
+++ b/Makefile
@@ -196,7 +196,7 @@ SCRIPT_SH = \
git-merge-one-file.sh git-mergetool.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh \
git-repack.sh git-request-pull.sh git-reset.sh \
- git-sh-setup.sh git-dirlink-checkout.sh \
+ git-sh-setup.sh git-dirlink-checkout.sh git-dirlink-merge.sh \
git-tag.sh git-verify-tag.sh \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
diff --git a/git-dirlink-merge.sh b/git-dirlink-merge.sh
new file mode 100644
index 0000000..e719b1a
--- /dev/null
+++ b/git-dirlink-merge.sh
@@ -0,0 +1,28 @@
+#!/bin/sh -e
+# Merge a submodule
+# (c) 2006 Martin Waitz
+
+USAGE="submodule orig-sha1 a-sha1 b-sha1"
+
+unset GIT_DIR
+cd "$1"
+
+. git-sh-setup
+
+test $# -eq 4 || usage
+
+orig="$2"
+ours="$3"
+theirs="$4"
+
+base=`git-merge-base "$ours" "$theirs"`
+
+if test `git-merge-base "$orig" "$base"` != "$orig"; then
+ die "$1 cannot be merged: other side switched branches"
+fi
+
+if test `git-rev-parse --verify HEAD` != "$ours"; then
+ die "$1: HEAD != ours"
+fi
+
+exec git-merge $theirs
diff --git a/merge-recursive.c b/merge-recursive.c
index 8f72b2c..4b67cd0 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -11,6 +11,7 @@
#include "diff.h"
#include "diffcore.h"
#include "run-command.h"
+#include "refs.h"
#include "tag.h"
#include "unpack-trees.h"
#include "path-list.h"
@@ -574,6 +575,21 @@ static void update_file_flags(const unsigned char *sha,
void *buf;
unsigned long size;
+ if (S_ISDIRLNK(mode)) {
+ /* defer dirlinks to another process, don't try to */
+ /* read the object "sha" here */
+ const char *dirlink_checkout[] = {
+ "dirlink-checkout", path, sha1_to_hex(sha), NULL
+ };
+ struct child_process cmd = {
+ .argv = dirlink_checkout,
+ .git_cmd = 1,
+ };
+
+ run_command(&cmd);
+ goto update_index;
+ }
+
buf = read_sha1_file(sha, &type, &size);
if (!buf)
die("cannot read object %s '%s'", sha1_to_hex(sha), path);
@@ -1069,6 +1085,26 @@ static struct merge_file_info merge_file(struct diff_filespec *o,
free(result_buf.ptr);
result.clean = (merge_status == 0);
+ } else if (S_ISDIRLNK(a->mode)) {
+ const char *dirlink_merge[] = {
+ "dirlink-merge", a->path,
+ sha1_to_hex(o->sha1),
+ sha1_to_hex(a->sha1),
+ sha1_to_hex(b->sha1),
+ NULL
+ };
+ struct child_process cmd = {
+ .argv = dirlink_merge,
+ .git_cmd = 1,
+ };
+ /* recurse into the submodule in a different process */
+ result.clean = !run_command(&cmd);
+ if (result.clean) {
+ /* get the new merged version */
+ if (resolve_gitlink_ref(a->path, "HEAD",
+ result.sha) < 0)
+ result.clean = 0;
+ }
} else {
if (!(S_ISLNK(a->mode) || S_ISLNK(b->mode)))
die("cannot merge modes?");
--
1.5.1.2.247.gaef5a
--
Martin Waitz
^ permalink raw reply related
* importing multi-project svn repositories
From: David Hanson @ 2007-05-06 18:56 UTC (permalink / raw)
To: git
What's the recommended way to import the full history from an svn
repository organized as a group of projects? E.g., as described at
http://svnbook.red-bean.com/nightly/en/
svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout:
/
calc/
trunk/
tags/
branches/
calendar/
trunk/
tags/
branches/
spreadsheet/
trunk/
tags/
branches/
…
I'd like to import calc at the top level, put calc/tags/foo in git's
tags/calc/foo and calc/branches/baz in git's heads/calc/baz. Ditto
for calendar, spreadsheet, etc.
I suspect there's a way to use git-svnimport repeatedly with
appropriate editing of .git/svn2git.
thanks,
dave h
^ permalink raw reply
* Re: [PATCH/RFD 4/3] t7300: Tests for git-clean using filenames with spaces/punctuation
From: Junio C Hamano @ 2007-05-06 18:54 UTC (permalink / raw)
To: Michael Spang; +Cc: Git Mailing List
In-Reply-To: <463E19F6.9000906@uwaterloo.ca>
Michael Spang <mspang@uwaterloo.ca> writes:
> Is this even properly solvable without making clean a builtin or
> writing git-unescape?
If you know how to use "xargs -0" and are willing to depend on
the -0 GNU extension, then the answer is yes.
I do not use git-clean myself, as I do not see what (I think) it
tries to solve as a problem to begin with, so obviously I do not
care too deeply about the command's implementation --- I just
let it be there because there seem to be others who want it ---
but if I were asked an advice on the right direction to proceed,
I would probably suggest rewriting it in C.
^ 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