* [PATCH] Do not generate full commit log message if it not going to be used
From: Alex Riesen @ 2007-11-27 21:44 UTC (permalink / raw)
To: Git Mailing List
Cc: Johannes Sixt, Junio C Hamano, Johannes Schindelin,
Kristian Høgsberg
In-Reply-To: <81b0412b0711271018m6419b076n269a0175494fac84@mail.gmail.com>
Like when it is already specified through -C, -F or -m to git-commit.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Alex Riesen, Tue, Nov 27, 2007 19:18:56 +0100:
> On 27/11/2007, Junio C Hamano <gitster@pobox.com> wrote:
> > ... When no_edit is in effect, I think these two places can
> > be replaced with an equivalent of "diff-index --cached HEAD --" (which
> > should not hit the work tree at all) to see if there is anything to be
> > committed. For initial commit the check would obviously be "is the
> > index empty?" instead.
>
> This is of course very useful optimization, and will speed up things
> everywhere (and especially here).
Could not stop myself. Hopefully didn't beat anyone to it :)
Almost all code shamelessly stolen from builtin-diff-index.c.
Builds, runs, passes all the tests. That !active_nr is
micro-optimization, but a nice one: clearly don't reread.
Preprocessor trickery in DIFF_OPT_* macros is disgusting, it breaks
Vim word completion and trying to use many flags in one expression
looks just ugly. What was wrong is inline functions?
builtin-commit.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index a35881e..8167ce4 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -367,6 +367,30 @@ static int prepare_log_message(const char *index_file, const char *prefix)
strbuf_release(&sb);
+ if (no_edit) {
+ static const char *argv[] = { NULL, "HEAD", NULL };
+ struct rev_info rev;
+ unsigned char sha1[40];
+ int is_initial;
+
+ fclose(fp);
+
+ if (!active_nr && read_cache() < 0)
+ die("Cannot read index");
+
+ if (get_sha1("HEAD", sha1) != 0)
+ return !!active_nr;
+
+ init_revisions(&rev, "");
+ rev.abbrev = 0;
+ (void)setup_revisions(2, argv, &rev, NULL);
+ DIFF_OPT_SET(&rev.diffopt, QUIET);
+ DIFF_OPT_SET(&rev.diffopt, EXIT_WITH_STATUS);
+ (void)run_diff_index(&rev, 1 /* cached */);
+
+ return !!DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES);
+ }
+
if (in_merge && !no_edit)
fprintf(fp,
"#\n"
--
1.5.3.6.1006.g08f2
^ permalink raw reply related
* Re: [PATCH] Allow update hooks to update refs on their own
From: Steven Grimm @ 2007-11-27 21:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fii1od$d38$1@ger.gmane.org>
On Nov 27, 2007, at 1:21 PM, Jakub Narebski wrote:
>> +The hook may optionally choose to update the ref on its own, e.g.,
>> +if it needs to modify incoming revisions in some way. If it updates
>> +the ref, it should exit with a status of 100.
>
> Why 100, and not for example 127, 128 or -1?
Because those seemed much more likely to be used by existing hook
scripts to denote an error condition, and I wanted to reduce the
chance that this would break existing scripts.
-Steve
^ permalink raw reply
* Re: [PATCH] Allow update hooks to update refs on their own
From: Jakub Narebski @ 2007-11-27 21:21 UTC (permalink / raw)
To: git
In-Reply-To: <20071127211730.GA11861@midwinter.com>
Steven Grimm wrote:
> +The hook may optionally choose to update the ref on its own, e.g.,
> +if it needs to modify incoming revisions in some way. If it updates
> +the ref, it should exit with a status of 100.
Why 100, and not for example 127, 128 or -1?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Allow update hooks to update refs on their own
From: Steven Grimm @ 2007-11-27 21:17 UTC (permalink / raw)
To: git
This is useful in cases where a hook needs to modify an incoming commit
in some way, e.g., adding an annotation to the commit message, noting
the location of output from a profiling tool, or committing to an svn
repository using git-svn.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
I did this to support a bridge between svn and git. The idea is
that the people who use git can do "git push" to publish their
changes, and if they've pushed to certain branches, the changes
will get transparently committed to svn using git-svn.
The git users therefore can operate in a totally git-centric
environment. (This is a step toward transitioning my company
away from svn entirely: get people used to a native git environment
with no direct svn interactions.)
One problem is that git-svn wants to rewrite history to add its
git-svn-id: lines, which means that when the update hook returns
after doing the git-svn dcommit, HEAD is already pointed at the
updated commit. Without this change or something like it,
receive-pack bombs out because HEAD has moved, and the push
appears to fail. This patch addresses that particular problem.
There are other issues with the history rewriting, but this
change is hopefully useful on its own for cases like the ones
listed in the commit message.
Documentation/git-receive-pack.txt | 8 +++-
receive-pack.c | 68 +++++++++++++++++++++++-------------
2 files changed, 50 insertions(+), 26 deletions(-)
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index 2633d94..115ae97 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -74,8 +74,12 @@ Note that the hook is called before the refname is updated,
so either sha1-old is 0\{40} (meaning there is no such ref yet),
or it should match what is recorded in refname.
-The hook should exit with non-zero status if it wants to disallow
-updating the named ref. Otherwise it should exit with zero.
+The hook may optionally choose to update the ref on its own, e.g.,
+if it needs to modify incoming revisions in some way. If it updates
+the ref, it should exit with a status of 100. The hook should exit
+with a status between 1 and 99 if it wants to disallow updating the
+named ref. Otherwise it should exit with zero, and the ref will be
+updated automatically.
Successful execution (a zero exit status) of this hook does not
ensure the ref will actually be updated, it is only a prerequisite.
diff --git a/receive-pack.c b/receive-pack.c
index 38e35c0..19162ec 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -18,6 +18,9 @@ static int report_status;
static char capabilities[] = " report-status delete-refs ";
static int capabilities_sent;
+/* Update hook exit code: hook has updated ref on its own */
+#define EXIT_CODE_REF_UPDATED 100
+
static int receive_pack_config(const char *var, const char *value)
{
if (strcmp(var, "receive.denynonfastforwards") == 0) {
@@ -70,8 +73,11 @@ static struct command *commands;
static const char pre_receive_hook[] = "hooks/pre-receive";
static const char post_receive_hook[] = "hooks/post-receive";
-static int hook_status(int code, const char *hook_name)
+static int hook_status(int code, const char *hook_name, int ok_start)
{
+ if (ok_start && -code >= ok_start)
+ return -code;
+
switch (code) {
case 0:
return 0;
@@ -121,7 +127,7 @@ static int run_hook(const char *hook_name)
code = start_command(&proc);
if (code)
- return hook_status(code, hook_name);
+ return hook_status(code, hook_name, 0);
for (cmd = commands; cmd; cmd = cmd->next) {
if (!cmd->error_string) {
size_t n = snprintf(buf, sizeof(buf), "%s %s %s\n",
@@ -132,7 +138,7 @@ static int run_hook(const char *hook_name)
break;
}
}
- return hook_status(finish_command(&proc), hook_name);
+ return hook_status(finish_command(&proc), hook_name, 0);
}
static int run_update_hook(struct command *cmd)
@@ -155,7 +161,8 @@ static int run_update_hook(struct command *cmd)
proc.no_stdin = 1;
proc.stdout_to_stderr = 1;
- return hook_status(run_command(&proc), update_hook);
+ return hook_status(run_command(&proc), update_hook,
+ EXIT_CODE_REF_UPDATED);
}
static const char *update(struct command *cmd)
@@ -194,32 +201,45 @@ static const char *update(struct command *cmd)
return "non-fast forward";
}
}
- if (run_update_hook(cmd)) {
- error("hook declined to update %s", name);
- return "hook declined";
- }
-
- if (is_null_sha1(new_sha1)) {
- if (delete_ref(name, old_sha1)) {
- error("failed to delete %s", name);
- return "failed to delete";
+ switch (run_update_hook(cmd)) {
+ case 0:
+ if (is_null_sha1(new_sha1)) {
+ if (delete_ref(name, old_sha1)) {
+ error("failed to delete %s", name);
+ return "failed to delete";
+ }
+ fprintf(stderr, "%s: %s -> deleted\n", name,
+ sha1_to_hex(old_sha1));
}
- fprintf(stderr, "%s: %s -> deleted\n", name,
- sha1_to_hex(old_sha1));
- return NULL; /* good */
- }
- else {
- lock = lock_any_ref_for_update(name, old_sha1, 0);
- if (!lock) {
- error("failed to lock %s", name);
- return "failed to lock";
+ else {
+ lock = lock_any_ref_for_update(name, old_sha1, 0);
+ if (!lock) {
+ error("failed to lock %s", name);
+ return "failed to lock";
+ }
+ if (write_ref_sha1(lock, new_sha1, "push")) {
+ return "failed to write"; /* error() already called */
+ }
+ fprintf(stderr, "%s: %s -> %s\n", name,
+ sha1_to_hex(old_sha1), sha1_to_hex(new_sha1));
}
- if (write_ref_sha1(lock, new_sha1, "push")) {
- return "failed to write"; /* error() already called */
+ return NULL; /* good */
+
+ case EXIT_CODE_REF_UPDATED:
+ /* hook has taken care of updating ref, which means it
+ might be a different revision than we think. */
+ if (! resolve_ref(name, new_sha1, 1, NULL)) {
+ error("can't resolve ref %s after hook updated it",
+ name);
+ return "ref not resolvable";
}
fprintf(stderr, "%s: %s -> %s\n", name,
sha1_to_hex(old_sha1), sha1_to_hex(new_sha1));
return NULL; /* good */
+
+ default:
+ error("hook declined to update %s", name);
+ return "hook declined";
}
}
--
1.5.3.6.862.g7acd00-dirty
^ permalink raw reply related
* Re: Removing old data without disturbing tree?
From: David Brown @ 2007-11-27 21:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git
In-Reply-To: <alpine.LFD.0.99999.0711271459520.9605@xanadu.home>
On Tue, Nov 27, 2007 at 03:06:45PM -0500, Nicolas Pitre wrote:
>On Tue, 27 Nov 2007, David Brown wrote:
>
>> An upstream tree I'm mirroring with git-p4 has decided to start checking
>> in large tarballs (150MB) periodically. It's basically a prebuild version
>> of some firmware needed to run the rest of the software.
>>
>> Git doesn't seem to have any problem with these tarballs (and is using a
>> lot less space than P4), but I have a feeling we might start running into
>> problems when things get real big. Does anyone have experience with packs
>> growing beyong several GB?
>
>It should just work. It was tested with artificial data sets but that's
>about it.
>
>Now if those tarballs are actually multiple revisions of the same
>package, you might consider storing them uncompressed and let Git delta
>compress them against each other which will produce an even more
>significant space saving.
I did manage to talk them into leaving them uncompressed. But, they are
large, and don't seem to delta compress all that well. Maybe as more come,
the compression will be better.
I guess this will be a good test case... It will probably take months or
even a year or so for the repo to get up to several GB.
David
^ permalink raw reply
* Re: [PATCH] git-gui: Improve the application icon on Windows.
From: Johannes Sixt @ 2007-11-27 20:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0711271539310.27959@racer.site>
On Tuesday 27 November 2007 16:40, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 27 Nov 2007, Johannes Sixt wrote:
> > Previusly, there was only a 16x16 image, which looked very distorted.
> > Here we add a 32x32 version, and also make the image sharper.
> >
> > Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> > ---
> > I'm by far not an artist, but improving the previous version
> > was not difficult at all. ;)
>
> Why did you not just use the svg contained in msysGit?
Because I cannot find one?
$ GIT_PAGER=cat git grep -i svg 4msysgit/devel
4msysgit/devel:attr.c: * attributes, e.g. "*.svg merge=special-...
-- Hannes
^ permalink raw reply
* Re: Removing old data without disturbing tree?
From: Nicolas Pitre @ 2007-11-27 20:06 UTC (permalink / raw)
To: David Brown; +Cc: Git
In-Reply-To: <20071127193955.GA16585@old.davidb.org>
On Tue, 27 Nov 2007, David Brown wrote:
> An upstream tree I'm mirroring with git-p4 has decided to start checking
> in large tarballs (150MB) periodically. It's basically a prebuild version
> of some firmware needed to run the rest of the software.
>
> Git doesn't seem to have any problem with these tarballs (and is using a
> lot less space than P4), but I have a feeling we might start running into
> problems when things get real big. Does anyone have experience with packs
> growing beyong several GB?
It should just work. It was tested with artificial data sets but that's
about it.
Now if those tarballs are actually multiple revisions of the same
package, you might consider storing them uncompressed and let Git delta
compress them against each other which will produce an even more
significant space saving.
Nicolas
^ permalink raw reply
* Re: git bug/feature request
From: Daniel Barkalow @ 2007-11-27 20:34 UTC (permalink / raw)
To: gapon; +Cc: git
In-Reply-To: <200711271127.41161.gapon007@gmail.com>
On Tue, 27 Nov 2007, gapon wrote:
> hi all,
> first of all i don't know if there's a bugzilla or something similar for git -
> i have found just this email (on http://git.or.cz/ webpage).
>
> i have discovered "weird" behaviour of git in this scenario*:
> - user A is working in repo A
> - user B clones repo A
> - user B makes some changes, commits, pushes
> - user A makes some changes, git status (no info about new commit in his repo
> from user B but it's probably ok i'd say - but some of my files are marked as
> changed and already added to index but i haven't changed them - that's
> confusing, isn't it?)
> - user A can commit his changes => shouldn't be there any info/message/warning
> displayed? it would be helpful to have here some info about "foreign commit"
> in the repo or something like this
This is kind of a fundamentally crazy thing to do; it's like a CVS user
committing to somebody else's working directory instead of to the central
repository. As you might expect, the system is confused because the info
of what version is checked out is changed without the checked-out files
getting changed. This should probably be kept from happening in some
fashion, not reported to the user after the fact.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git bug/feature request
From: Daniel Barkalow @ 2007-11-27 20:19 UTC (permalink / raw)
To: Steven Grimm; +Cc: Jakub Narebski, git
In-Reply-To: <FA6B0BE9-FC43-4298-932F-627826ADE18F@midwinter.com>
On Tue, 27 Nov 2007, Steven Grimm wrote:
> On Nov 27, 2007, at 7:13 AM, Jakub Narebski wrote:
> >I thought that modern git refuses to push into checked out branch
> >(in HEAD) in non-bare repositories.
>
> It doesn't -- otherwise the "update the working copy when a push to the
> current branch comes in" update hook scripts that some of us use wouldn't
> work, and they do work at the moment. (Before anyone warns me of the dangers
> of that: the hook only runs in a shared repo that no human is allowed to
> modify, so the working copy is always a clean version of HEAD and thus is safe
> to update.)
It could require the working copy to be a clean version of HEAD, and, in
this case, update it. Then it would always be kept consistent one way or
the other, without consistency depending on the use of a hook. (This is
like how a pre-refs/remotes/ pull into a checked-out origin was handled,
and it seemed reliable there)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git bug/feature request
From: Steven Grimm @ 2007-11-27 19:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fihc5u$mbs$1@ger.gmane.org>
On Nov 27, 2007, at 7:13 AM, Jakub Narebski wrote:
> I thought that modern git refuses to push into checked out branch
> (in HEAD) in non-bare repositories.
It doesn't -- otherwise the "update the working copy when a push to
the current branch comes in" update hook scripts that some of us use
wouldn't work, and they do work at the moment. (Before anyone warns me
of the dangers of that: the hook only runs in a shared repo that no
human is allowed to modify, so the working copy is always a clean
version of HEAD and thus is safe to update.)
-Steve
^ permalink raw reply
* Removing old data without disturbing tree?
From: David Brown @ 2007-11-27 19:39 UTC (permalink / raw)
To: Git
An upstream tree I'm mirroring with git-p4 has decided to start checking
in large tarballs (150MB) periodically. It's basically a prebuild version
of some firmware needed to run the rest of the software.
Git doesn't seem to have any problem with these tarballs (and is using a
lot less space than P4), but I have a feeling we might start running into
problems when things get real big. Does anyone have experience with packs
growing beyong several GB?
Aside from that, is there an easy way to prune out the old history from a
working tree? I'd like something like what 'git clone --depth n' would
produce, and I suppose I could do the clone and then pivot the trees. I
mainly don't want to be rewriting history, just making parts inaccessible.
Thanks,
David Brown
^ permalink raw reply
* Re: QGit: Shrink used memory with custom git log format
From: Jan Hudec @ 2007-11-27 19:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Marco Costalba, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711271045430.27959@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]
On Tue, Nov 27, 2007 at 10:48:00 +0000, Johannes Schindelin wrote:
> On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> > [...]
> > Otherwise I think what you really want here is a libgit that you can
> > link into your process and that can efficiently inflate an object
> > on demand for you. Like the work Luiz was working on this past
> > summer for GSOC. Lots of downsides to that current tree though...
> > like die() kills the GUI...
>
> But then, die() calls die_routine, which you can override. And C++ has
> this funny exception mechanism which just begs to be used here. The only
> thing you need to add is a way to flush all singletons like the object
> array.
Unfortunately, exceptions won't really work. Why? Because to use exceptions,
you need to have an exception-safe code. That is the code needs to free any
allocated resources when it's aborted by exception. And git code is not
exceptions safe. Given the lack of destructors in C, it means registering all
resource allocation in some kind of pool, so they can be freed en masse in
case of failure. Than you can also use longjmp for die (for C they really
behave the same).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Use --no-color option on git log commands.
From: Pascal Obry @ 2007-11-27 18:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vr6icej23.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
> The patch is good as belt-and-suspender, thanks.
Ok.
> But I suspect that we should make 'true' to mean 'auto' someday in
> git_config_colorbool(). Crazy people can set 'always' if they really
> wanted to, but most normal people would not want color unless the output
> goes to the terminal, I would think.
I definitely agree. I add it set to true, using auto instead I do not
have the problem. Anyway I still think that it is good to apply my patch
to completely avoid such issues.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] builtin-commit: add --cached to operate only on index
From: Alex Riesen @ 2007-11-27 18:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, Git Mailing List, Johannes Schindelin,
Kristian Høgsberg
In-Reply-To: <7vfxyrd2x2.fsf@gitster.siamese.dyndns.org>
On 27/11/2007, Junio C Hamano <gitster@pobox.com> wrote:
> On the other hand, when we know we do not have to _show_ the list of
> staged/modified/untracked files (i.e. we already have the commit log
> message via -m, -F, or -C and we were told not to invoke editor), we do
> not have to call run_status(), only to discard its output. In such a
> case, we are calling it only to see if we have something committable,
> and we should be able to optimize THAT without being told by the user
> with this new option. Incidentally I just checked the scripted version;
> it does not do this optimization (git-commit.sh, ll. 514-517). The C
> rewrite in 'next' does not have it in either (builtin-commit.c,
> ll. 387-390). When no_edit is in effect, I think these two places can
> be replaced with an equivalent of "diff-index --cached HEAD --" (which
> should not hit the work tree at all) to see if there is anything to be
> committed. For initial commit the check would obviously be "is the
> index empty?" instead.
This is of course very useful optimization, and will speed up things
everywhere (and especially here).
But still: I didn't mean it. I really meant the interactive case, with
editor and prepared commit message which has status list.
Sometimes this list is the reason why a commit is aborted:
I notice that I'm committing something I didn't really intend to.
^ permalink raw reply
* Re: [PATCH] builtin-commit: add --cached to operate only on index
From: Alex Riesen @ 2007-11-27 18:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, Git Mailing List, Johannes Schindelin,
Kristian Høgsberg
In-Reply-To: <7vfxyrd2x2.fsf@gitster.siamese.dyndns.org>
On 27/11/2007, Junio C Hamano <gitster@pobox.com> wrote:
> I am sympathetic to the _cause_, but I do not think the option --cached
> is a good match for this change. As Hannes points out, as-is commit is
> the default, and --cached to other commands mean "work only with index
> not work tree", not "short-circuit for systems with slow lstat(3)".
I don't just mean to avoid lstat. I'm trying to avoid _any_
interaction with the thing unless absolutely needed.
> * The option "--cached" is a wrong thing to have the user say and is
> not what you want anyway. You want "no status list in the commit log
> template";
That is not what I meant to say. I do want status list in commit message.
I don't want anything except git-diff-index --name-status --cached HEAD in it.
No untracked files whatsoever.
And, as I said, I also just want to commit the index _exactly_ as it is.
No checking for files changed after they were updated in the index
intended. I think that whatever the index holds is perfect (except it's
no different from HEAD) and I want commit it now.
> * Skip run_status() and replace with "diff-index --cached HEAD" (or "is
> the index empty?") when the user instructs so;
Right. Is it not what happens with the patch?
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Johannes Schindelin @ 2007-11-27 17:48 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <figlf6$d48$1@ger.gmane.org>
Hi,
On Tue, 27 Nov 2007, Andy Parkins wrote:
> Actually although I like C++, that's not the reason, the reason is that Qt
> is a significantly (IMHO) better toolkit than Tk. It's more cross platform
> and looks a lot nicer.
Tcl/Tk was easier to install on a lot more platforms in my life than Qt.
Ciao,
Dscho
^ permalink raw reply
* RE: [PATCH] Remove git-status from list of scripts as it is builtin
From: Medve Emilian @ 2007-11-27 17:00 UTC (permalink / raw)
To: Shawn O. Pearce, Junio C Hamano; +Cc: git
In-Reply-To: <20071123203508.GA6797@spearce.org>
Hi Shawn,
That does the trick. Thanks.
Cheers,
Emil.
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Shawn O. Pearce
> Sent: Friday, November 23, 2007 2:35 PM
> To: Junio C Hamano
> Cc: git@vger.kernel.org
> Subject: [PATCH] Remove git-status from list of scripts as it
> is builtin
>
> Now that git-status is builtin on Cygwin this compiles as
> git-status.exe. We cannot continue to include git-status
> as a Makefile target as it will never be built.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
>
> I apologize if this is a dupe; I haven't had a chance to read
> the list traffic to see what has been posted and what hasn't.
> I'll be offline for the next few days so I figured I should get
> this out there now, just in case anyone else might run into the
> same problem I did.
>
> Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 313f9a2..a5a40ce 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -233,7 +233,7 @@ SCRIPT_PERL = \
>
> SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
> $(patsubst %.perl,%,$(SCRIPT_PERL)) \
> - git-status git-instaweb
> + git-instaweb
>
> # ... and all the rest that could be moved out of bindir to
> gitexecdir
> PROGRAMS = \
> --
> 1.5.3.6.1936.gc44a9
> -
> 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: If you would write git from scratch now, what would you change?
From: Jing Xue @ 2007-11-27 17:33 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <fiet88$68n$1@ger.gmane.org>
Quoting Andy Parkins <andyparkins@gmail.com>:
> - "index", "cached" and "stage" are a definite source of confusion
Hear, hear.
> - "git add" and "git rm" would be nicer as "git stage" and "git unstage"
> (or something similar)
Not sure it would be that easy. (As I have just learned recently) "git
rm" is the opposite of "git add" _only_ in the case of
files-not-previously-tracked. And the opposite of "git add <file>" for
files-already-being-tracked is "git reset HEAD -- <file>", which is
probably where you were going with "git unstage" 8-) .
> - libgit would have come first
> - "git revert" should be called "git invert"
> - "git revert" would (maybe) be "git reset"
> - "git clone" wouldn't exist
Why? AFAIC, git clone works out quite well - both functionality and
naming wise.
Cheers.
--
Jing Xue
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-27 17:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ,
Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <7vbq9fd2mp.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1821 bytes --]
Hi,
On Tue, 27 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Tue, 27 Nov 2007, しらいしななこ wrote:
> >
> >> Quoting Andreas Ericsson <ae@op5.se>:
> >>
> >> > "git pull --rebase" already has an implementation. Dscho cooked one up
> >> > which I've been using since then. It works nicely.
> >>
> >> What is the reason that the option was not added to the official git?
> >> Was it coded poorly, buggy or were there some other issues?
> >
> > It is very well possible that it was coded poorly ;-)
> >
> > The main reason, I believe, was that some old-timers who know the
> > implications said that it would encourage a wrong workflow. One thing
> > that could go possibly wrong, for example, is to rebase commits that you
> > already published.
> >
> > So AFAICT it was deemed not only giving people rope, but making that rope
> > look like a necklace to them.
>
> Hmph, that is different from how I remember, and the "workflow" argument
> would not be something I would make if we were having that discussion
> today.
>
> I think what happened was that we took a misguided detour to make this
> an option to "git merge" (which was _my_ mistake IIRC, sorry), which did
> not pan out well (because rebase is not "a different form of merge").
> After that for some reason we failed to follow-up on the topic. We
> could have gone back to the original "a pull is integrating following a
> fetch, and the integration does not have to be merge" approach to see if
> it was workable, but we didn't.
>
> If people find it useful, I do not think of a huge reason to object to
> the inclusion. "Give them rope" is good ;-)
FWIW the my last reply in that thread was
http://thread.gmane.org/gmane.comp.version-control.git/62382/focus=62405
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Nicolas Pitre @ 2007-11-27 17:23 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Schindelin,
らいしななこ,
Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <20071127164243.GE11731@fieldses.org>
On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> On Tue, Nov 27, 2007 at 11:14:47AM -0500, Nicolas Pitre wrote:
> > On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> > > No, their work isn't always based on origin/master@{1}. Often they've
> > > got more than one project going. If they try
> > >
> > > git checkout project-1
> > > git pull -s rebase
> > > git checkout project-2
> > > git pull -s rebase
> > >
> > > what's going to happen? What if project-2 has been on the back burner
> > > for a few months and they're just getting around to rebasing it now?
> >
> > I don't see the problem. They'll just have a possibly harder rebase due
> > to increased chances for conflicts than if they rebased more often, but
> > that's to be expected even with a merge.
>
> Well, fair enough. It can be much worse than a merge, though--consider
> what happens when upstream drops a commit, or replaces a patch by
> another patch (or patches) that solves the problem in a different way.
That's the whole point for the need to rebase. To others I'm currently
upstream and I do the above all the time. So I don't see the issue.
> > > What if their various projects are based on different upstream branches,
> > > but the fetch done by git-pull updates them all at once?
> > > What if they
> > > did a git fetch earlier just to peek at current development and are only
> > > now getting around to updating their own branches?
> >
> > You are not _forced_ to use origin/master@{1} in that case -- I used
> > that notation only to illustrate the concept in Git terms. What I tell
> > people to do is to tag their new base after the rebase is done, and to
> > use that tag after the next fetch to rebase again.
>
> That's fine, but it's not an automated process any more.
Indeed. I never claimed it was automated, but I'm rather deploring it.
> > I honnestly don't use such a tag myself because I think I know what I'm
> > doing when using Git, and therefore I know when origin/master@{1} refers
> > to what I really want. But the point is that either that usage of
> > origin/master@{1}, or a dedicated tag, or whatever other means to
> > retrieve the previous base, could be handled implicitly by the porcelain
> > and the user wouldn't have to care as much.
>
> OK, so you're imagining a version of "git pull -s rebase" that also
> allows specifying the previous base of your series? What would the
> syntax be? You could do something like stg does and keep extra
> information under .git that records the base of each "patch series".
> Then you have to figure out how to manage that information and how it
> should interact with the varoius branch management commands.
... which is IMHO the best reason to find a solution that doesn't need
extra information to be kept.
> > Thinking about it, there should be a way to find the proper base even
> > without explicitly recording it with a tag. If it isn't
> > origin/master@{1}, it has to be the first of origin/master@{n} for
> > n = [1, ...] reachable from the local work branch before rebasing.
>
> That'll work in some cases. You're almost using the reflog as another
> piece of history to find the "real" merge-base.
Sure. Since it is there, why not use it?
> That's a little fragile, since reflogs aren't quite "real" history. It
> doesn't work reliably in the "project that was put on the back burner"
> case (because the reflog entries may have expired).
Tough.
Maybe reflogs should always preserve a minimum of x entries by default
even if they are older than the expiration threshold.
But practically speaking, if you've been sitting on your work for so
long and you've pruned your reflog then you should always be able to
look up your branch history and find the first commit which isn't yours,
then use its ID explicitly. And if you forgot enough about that work of
yours so not to be able to determine that base commit then I probably
don't want to trust you anyway. :-)
> It doesn't work if
> work is done in multiple repositories.
Hmmm... would have to think a bit more about that, but it never was a
real issue to me so far.
> > > And I don't think any of those are crazy corner cases; I know at least
> > > that I do all of those things.
> >
> > Sure. In which case you certainly fall into the "know what you're
> > doing" category too and certainly can find your way towards the proper
> > base ref to use.
>
> Beginners are will try those things too, so we'd have to explain the
> limitations up front.
Sure. Yet a bunch of Git beginners are doing just well so far with the
rather terse instructions I provided for manually rebasing their work
when using my repo. So that must not be that bad.
> > But again I think that can be automated.
>
> I'd want to see the algorithm spelled out, and a very convincing
> description of exactly which cases it handles.
>
> My other objection is that "rebase" just isn't a merge strategy. I
> think of a merge strategy takes some HEADs in a produces a single merge
> commit that connects them.
>
> If we really want a fetch+rebase script, OK, but call it something other
> than pull.
I absolutely agree. Anyway, the Git "pull" is my own most hated command.
I always considered it has strange semantics hiding too much of what is
actually going on, using an artificial concept probably borrowed from BK
to justify its existence. In all the tutorials for $job I've done so
far, I simply never talk about pull nor clone, but rather about init,
"git remote", fetch and merge, with explicit and meaningful branch
names. I think that basic commands, even if there is a bit more of
them, make Git easier to learn and understand than talking about those
magic meta commands hiding the truth away. But hey, this is only my own
opinion, and after all I'm the one having to deal with those $job people
in the end.
Nicolas
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-27 17:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: しらいしななこ,
Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0711271109130.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 27 Nov 2007, しらいしななこ wrote:
>
>> Quoting Andreas Ericsson <ae@op5.se>:
>>
>> > "git pull --rebase" already has an implementation. Dscho cooked one up
>> > which I've been using since then. It works nicely.
>>
>> What is the reason that the option was not added to the official git?
>> Was it coded poorly, buggy or were there some other issues?
>
> It is very well possible that it was coded poorly ;-)
>
> The main reason, I believe, was that some old-timers who know the
> implications said that it would encourage a wrong workflow. One thing
> that could go possibly wrong, for example, is to rebase commits that you
> already published.
>
> So AFAICT it was deemed not only giving people rope, but making that rope
> look like a necklace to them.
Hmph, that is different from how I remember, and the "workflow" argument
would not be something I would make if we were having that discussion
today.
I think what happened was that we took a misguided detour to make this
an option to "git merge" (which was _my_ mistake IIRC, sorry), which did
not pan out well (because rebase is not "a different form of merge").
After that for some reason we failed to follow-up on the topic. We
could have gone back to the original "a pull is integrating following a
fetch, and the integration does not have to be merge" approach to see if
it was workable, but we didn't.
If people find it useful, I do not think of a huge reason to object to
the inclusion. "Give them rope" is good ;-)
^ permalink raw reply
* Re: [PATCH] builtin-commit: add --cached to operate only on index
From: Junio C Hamano @ 2007-11-27 17:16 UTC (permalink / raw)
To: Alex Riesen
Cc: Johannes Sixt, Git Mailing List, Johannes Schindelin,
Kristian Høgsberg
In-Reply-To: <81b0412b0711270448s6534a849u86bcb161d4d7b3fe@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
>> Doesn't git-commit operate only on the index, unless you pass it extra
>> arguments?
>
> It doesn't
>
>> What am I missing?
>
> run_status and check for changed files
I am sympathetic to the _cause_, but I do not think the option --cached
is a good match for this change. As Hannes points out, as-is commit is
the default, and --cached to other commands mean "work only with index
not work tree", not "short-circuit for systems with slow lstat(3)".
Obviously we cannot short-circuit checking for modified or removed paths
when "git-commit -a" is run, but it is plausible that people may still
want to trade run_status output with interactive speed even when doing
"git-commit -a".
On the other hand, when we know we do not have to _show_ the list of
staged/modified/untracked files (i.e. we already have the commit log
message via -m, -F, or -C and we were told not to invoke editor), we do
not have to call run_status(), only to discard its output. In such a
case, we are calling it only to see if we have something committable,
and we should be able to optimize THAT without being told by the user
with this new option. Incidentally I just checked the scripted version;
it does not do this optimization (git-commit.sh, ll. 514-517). The C
rewrite in 'next' does not have it in either (builtin-commit.c,
ll. 387-390). When no_edit is in effect, I think these two places can
be replaced with an equivalent of "diff-index --cached HEAD --" (which
should not hit the work tree at all) to see if there is anything to be
committed. For initial commit the check would obviously be "is the
index empty?" instead.
So in short:
* The option "--cached" is a wrong thing to have the user say and is
not what you want anyway. You want "no status list in the commit log
template";
* Skip run_status() and replace with "diff-index --cached HEAD" (or "is
the index empty?") when the user instructs so;
* In addition, the same optimization should apply when we know we do
not use the exact run_status() output.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: J. Bruce Fields @ 2007-11-27 17:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nicolas Pitre, らいしななこ,
Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0711271652070.27959@racer.site>
On Tue, Nov 27, 2007 at 04:54:18PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 27 Nov 2007, J. Bruce Fields wrote:
>
> > If we really want a fetch+rebase script, OK, but call it something other
> > than pull.
>
> Why? pull = fetch + merge only because that was the originally envisioned
> way to pull remote changes into your local working tree. However, I do
> not see why we should be married to pull being a fetch and a merge for
> eternity.
Two responses:
First, OK, if you want to say "pull" means "fetch something and then
incorporate it somehow into your current branch", that doesn't bother me
quite as much as saying that "pull" always means "fetch + merge", and
that "rebase" is really just a special kind of merge. It's clearly not
a merge.
Second: "fetch+rebase" will really have very different properties from
"fetch+pull". It may be possible to make the former behave a little
like the latter in some common cases, but it's going to complicated.
And a lot of git-pull documentation is going to end up with clauses like
"...except if you're running pull in 'rebase' mode, in which case...".
Better to keep the two cases as separate operations with separate syntax
and man pages. (But share where it makes sense--e.g. any syntax and
documentation of fetch part should be shared.)
--b.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-27 16:54 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Nicolas Pitre, らいしななこ,
Andreas Ericsson, Jakub Narebski, git
In-Reply-To: <20071127164243.GE11731@fieldses.org>
Hi,
On Tue, 27 Nov 2007, J. Bruce Fields wrote:
> If we really want a fetch+rebase script, OK, but call it something other
> than pull.
Why? pull = fetch + merge only because that was the originally envisioned
way to pull remote changes into your local working tree. However, I do
not see why we should be married to pull being a fetch and a merge for
eternity.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Tweak git-quiltimport to allow more flexible series format
From: Alexey Dobriyan @ 2007-11-27 16:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, adobriyan
In-Reply-To: <7vsl2x26di.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 22, 2007 at 03:43:53PM -0800, Junio C Hamano wrote:
> Alexey Dobriyan <adobriyan@sw.ru> writes:
>
> > Make quiltimport also understand comments following patch name.
> >
> > Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
> > ---
> >
> > git-quiltimport.sh | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- a/git-quiltimport.sh
> > +++ b/git-quiltimport.sh
> > @@ -63,7 +63,7 @@ tmp_info="$tmp_dir/info"
> > commit=$(git rev-parse HEAD)
> >
> > mkdir $tmp_dir || exit 2
> > -for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
> > +for patch_name in $(sed -e 's/#.*//' < "$QUILT_PATCHES/series" ); do
> > if ! [ -f "$QUILT_PATCHES/$patch_name" ] ; then
> > echo "$patch_name doesn't exist. Skipping."
> > continue
>
> Is this consistent with the way quilt groks the series file?
>
> IOW, does quilt forbid patchfile whose name contains a hash, and
> anything after a hash on the line is taken as comment?
It looks like hash inside a patch name is legal.
> Can a line in a quilt series file name more than one patchfile?
No. Which means we can probably do sed -e 's/^#//' -e 's/[ \t]#.*//'
... let me experiment bit more.
> If so, are they whitespace separated?
^ 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