* Re: git status in clean working dir
From: Jeff King @ 2008-07-22 6:06 UTC (permalink / raw)
To: Mike Hommey; +Cc: Junio C Hamano, git, David Bremner
In-Reply-To: <20080722053921.GA4983@glandium.org>
On Tue, Jul 22, 2008 at 07:39:21AM +0200, Mike Hommey wrote:
> > This marks diff-files as FORBID_PAGER; I will leave it to others to
> > fight about which commands should have it. But it doesn't make sense to
> > mark "status" since some people obviously _want_ the paging there.
>
> Why not "simply" forbid the pager when output is not a terminal ?
We already do that (see pager.c:53). The original poster still had a
problem, but I don't know if it was for actual usage or simply a toy
$ git status
$ echo $?
$ echo "why don't exit codes work in status?" | mail git@vger
question.
-Peff
^ permalink raw reply
* Re: git status in clean working dir
From: Mike Hommey @ 2008-07-22 5:39 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, David Bremner
In-Reply-To: <20080722044157.GA20787@sigill.intra.peff.net>
On Tue, Jul 22, 2008 at 12:41:57AM -0400, Jeff King wrote:
> On Mon, Jul 21, 2008 at 07:40:28PM -0700, Junio C Hamano wrote:
>
> > Actually, the situation is now even worse than I originally thought
> > especially with Jeff's pager.<cmd> patch on 'master' recently. For
> > example, you can screw yourself quite badly by forcing diff-files used in
> > the scripts you run to page, defeating --exit-code option. Which means
>
> Actually, you could _always_ do that with "git -p diff-files". Which is
> obviously stupid, just as setting pager.diff-files is. In the reported
> case, though, "status" is broken, which we now do by default. So no
> stupidity required.
>
> > (2) Then why are we even allowing to configure the plumbing to page?
>
> 1. Laziness. We just never marked which shouldn't be allowed to page.
> But again, in this case, we have explicitly marked status as "this
> should page" so I don't think this is a plumbing / porcelain thing.
> Status fulfills both roles here (some people want it paged, because
> they use it as porcelain, and some people want the exit code).
>
> 2. We don't always know all git commands. We execute user scripts as
> "git foo", but we don't know what they do. Worse than that, we have
> to commit our pager choice early because we might be exec'ing (but
> this is somewhat of an artifact of the way the code is structured,
> and not necessarily an impossible obstacle).
>
> > Should we maintain a table of commands that we allow paging to be
> > customized, and ignore pager.<cmd> for commands that are not in the list?
>
> The patch below sets up the infrastructure, which is trivial. Note that
> this _doesn't_ handle the case of "git -p status", because we have to
> commit that choice at a different time (again, we might be able to
> overcome that with a little code restructuring).
>
> This marks diff-files as FORBID_PAGER; I will leave it to others to
> fight about which commands should have it. But it doesn't make sense to
> mark "status" since some people obviously _want_ the paging there.
Why not "simply" forbid the pager when output is not a terminal ?
Mike
^ permalink raw reply
* Re: [PATCH] builtin-merge: give a proper error message for invalid strategies in config
From: Junio C Hamano @ 2008-07-22 5:22 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <7vr69mpl5v.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
>> Till now 'git merge -s foobar' bailed out with an error message, but
>> foobar in pull.twohead or pull.octopus was just silently ignored. It's
>> better to inform the user then just silently doing nothing.
>>
>> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
>
> Doesn't this make "git merge -s 'recursive resolve'" to misbehave?
Perhaps this would be a better replacement. It makes get_strategy() to
validate and barf on unknown one. It is slightly smaller and more
contained. If/when we add user-defined ones, that logic will also be
contained in the function.
builtin-merge.c | 37 ++++++++++++-------------------------
t/t7601-merge-pull-config.sh | 12 ++++++++++++
2 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e97c79e..0fd7985 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -77,6 +77,7 @@ static int option_parse_message(const struct option *opt,
static struct strategy *get_strategy(const char *name)
{
int i;
+ struct strbuf err;
if (!name)
return NULL;
@@ -84,7 +85,13 @@ static struct strategy *get_strategy(const char *name)
for (i = 0; i < ARRAY_SIZE(all_strategy); i++)
if (!strcmp(name, all_strategy[i].name))
return &all_strategy[i];
- return NULL;
+
+ strbuf_init(&err, 0);
+ for (i = 0; i < ARRAY_SIZE(all_strategy); i++)
+ strbuf_addf(&err, " %s", all_strategy[i].name);
+ fprintf(stderr, "Could not find merge strategy '%s'.\n", name);
+ fprintf(stderr, "Available strategies are:%s.\n", err.buf);
+ exit(1);
}
static void append_strategy(struct strategy *s)
@@ -96,25 +103,10 @@ static void append_strategy(struct strategy *s)
static int option_parse_strategy(const struct option *opt,
const char *name, int unset)
{
- int i;
- struct strategy *s;
-
if (unset)
return 0;
- s = get_strategy(name);
-
- if (s)
- append_strategy(s);
- else {
- struct strbuf err;
- strbuf_init(&err, 0);
- for (i = 0; i < ARRAY_SIZE(all_strategy); i++)
- strbuf_addf(&err, " %s", all_strategy[i].name);
- fprintf(stderr, "Could not find merge strategy '%s'.\n", name);
- fprintf(stderr, "Available strategies are:%s.\n", err.buf);
- exit(1);
- }
+ append_strategy(get_strategy(name));
return 0;
}
@@ -643,14 +635,9 @@ static void add_strategies(const char *string, unsigned attr)
memset(&list, 0, sizeof(list));
split_merge_strategies(string, &list, &list_nr, &list_alloc);
- if (list != NULL) {
- for (i = 0; i < list_nr; i++) {
- struct strategy *s;
-
- s = get_strategy(list[i].name);
- if (s)
- append_strategy(s);
- }
+ if (list) {
+ for (i = 0; i < list_nr; i++)
+ append_strategy(get_strategy(list[i].name));
return;
}
for (i = 0; i < ARRAY_SIZE(all_strategy); i++)
diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
index 95b4d71..6b9f638 100755
--- a/t/t7601-merge-pull-config.sh
+++ b/t/t7601-merge-pull-config.sh
@@ -126,4 +126,16 @@ test_expect_success 'merge picks up the best result' '
test $auto_count != $resolve_count
'
+test_expect_success 'merge errors out on invalid strategy' '
+ git config pull.twohead "foobar" &&
+ git reset --hard c5 &&
+ test_must_fail git merge c6
+'
+
+test_expect_success 'merge errors out on invalid strategy' '
+ git config --unset-all pull.twohead &&
+ git reset --hard c5 &&
+ test_must_fail git merge -s "resolve recursive" c6
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] builtin-merge: give a proper error message for invalid strategies in config
From: Junio C Hamano @ 2008-07-22 5:01 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1216656647-16897-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> Till now 'git merge -s foobar' bailed out with an error message, but
> foobar in pull.twohead or pull.octopus was just silently ignored. It's
> better to inform the user then just silently doing nothing.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Doesn't this make "git merge -s 'recursive resolve'" to misbehave?
^ permalink raw reply
* Re: [PATCH] Allow pager of diff command be enabled/disabled
From: Jeff King @ 2008-07-22 4:58 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20080721212849.GB4748@blimp.local>
On Mon, Jul 21, 2008 at 11:28:49PM +0200, Alex Riesen wrote:
> See for example, status and show commands. Besides,
> Documentation/RelNotes-1.6.0.txt mentions that pager.<cmd>
> can be used to enable/disable paging behavior per command.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
>
> Also, really export check_pager_config, which just got another call
> site.
This patch looks correct to me. There are also a bunch of other commands
for which pager.* doesn't work. Basically, anything that doesn't ask for
RUN_SETUP is on its own to set up paging if it wants (because Bad Things
happen when we try to look in the config before setup has been run).
Most of them people probably don't care about (really, who wants paging
by default on git-apply?). But it is yet another hidden inconsistency
from the paging patch.
-Peff
^ permalink raw reply
* Re: [PATCH] Enable threaded delta search on *BSD and Linux.
From: Junio C Hamano @ 2008-07-22 4:54 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1216632223-14655-1-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
>
> Following the discussion we had 10 days ago, here is a proposal to enable
> threaded delta search on systems that are likely to behave properly wrt
> memory and CPU usage.
Hmmm.
I do not want to do this kind of thing very close to the release (like
now), but rather immediately after 1.6.0. Will queue for 'next'.
Distro people can decide for themselves and their users, but I am of
conservative kind.
^ permalink raw reply
* Re: git status in clean working dir
From: Jeff King @ 2008-07-22 4:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Bremner
In-Reply-To: <20080722044359.GB20787@sigill.intra.peff.net>
On Tue, Jul 22, 2008 at 12:44:00AM -0400, Jeff King wrote:
> We could also swap the parent/child relationship, and have the pager as
> child. But I assume that it is done the way we have it because otherwise
> the shell gets confused about when the command ends (i.e., we want it to
> run until pager completion). I didn't test, though.
Hmm, it looks like the MINGW32 codepath already _does_ spawn in that
order, but has a "wait_for_child" atexit handler. I wonder if there is a
reason all platforms can't use that trick (though the mingw approach
uses run_command, which makes it harder to do the "wait for input before
starting less" trick).
-Peff
^ permalink raw reply
* Re: git status in clean working dir
From: Jeff King @ 2008-07-22 4:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Bremner
In-Reply-To: <7vljzur5wd.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 21, 2008 at 07:48:02PM -0700, Junio C Hamano wrote:
> Another possibility is to set up an extra process whose sole purpose is to
> wait for the main process that feeds the pager pipe and relay its exit
> status to the outside world. But I do not think we would want to go
> there...
We could also swap the parent/child relationship, and have the pager as
child. But I assume that it is done the way we have it because otherwise
the shell gets confused about when the command ends (i.e., we want it to
run until pager completion). I didn't test, though.
-Peff
^ permalink raw reply
* Re: git status in clean working dir
From: Jeff King @ 2008-07-22 4:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Bremner
In-Reply-To: <7vtzeir68z.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 21, 2008 at 07:40:28PM -0700, Junio C Hamano wrote:
> Actually, the situation is now even worse than I originally thought
> especially with Jeff's pager.<cmd> patch on 'master' recently. For
> example, you can screw yourself quite badly by forcing diff-files used in
> the scripts you run to page, defeating --exit-code option. Which means
Actually, you could _always_ do that with "git -p diff-files". Which is
obviously stupid, just as setting pager.diff-files is. In the reported
case, though, "status" is broken, which we now do by default. So no
stupidity required.
> (2) Then why are we even allowing to configure the plumbing to page?
1. Laziness. We just never marked which shouldn't be allowed to page.
But again, in this case, we have explicitly marked status as "this
should page" so I don't think this is a plumbing / porcelain thing.
Status fulfills both roles here (some people want it paged, because
they use it as porcelain, and some people want the exit code).
2. We don't always know all git commands. We execute user scripts as
"git foo", but we don't know what they do. Worse than that, we have
to commit our pager choice early because we might be exec'ing (but
this is somewhat of an artifact of the way the code is structured,
and not necessarily an impossible obstacle).
> Should we maintain a table of commands that we allow paging to be
> customized, and ignore pager.<cmd> for commands that are not in the list?
The patch below sets up the infrastructure, which is trivial. Note that
this _doesn't_ handle the case of "git -p status", because we have to
commit that choice at a different time (again, we might be able to
overcome that with a little code restructuring).
This marks diff-files as FORBID_PAGER; I will leave it to others to
fight about which commands should have it. But it doesn't make sense to
mark "status" since some people obviously _want_ the paging there.
> Which codepath should issue error messages when the user tries to break
> the system by saying "pager.diff-files = true"?
No error, but it is silently ignored. :)
---
diff --git a/git.c b/git.c
index 74ea0e6..72cadb5 100644
--- a/git.c
+++ b/git.c
@@ -210,6 +210,7 @@ const char git_version_string[] = GIT_VERSION;
* RUN_SETUP for reading from the configuration file.
*/
#define NEED_WORK_TREE (1<<2)
+#define FORBID_PAGER (1<<3)
struct cmd_struct {
const char *cmd;
@@ -231,6 +232,8 @@ static int run_command(struct cmd_struct *p, int argc, const char **argv)
use_pager = check_pager_config(p->cmd);
if (use_pager == -1 && p->option & USE_PAGER)
use_pager = 1;
+ if (use_pager == 1 && p->option & FORBID_PAGER)
+ use_pager = 0;
commit_pager_choice();
if (p->option & NEED_WORK_TREE)
@@ -286,7 +289,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "count-objects", cmd_count_objects, RUN_SETUP },
{ "describe", cmd_describe, RUN_SETUP },
{ "diff", cmd_diff },
- { "diff-files", cmd_diff_files, RUN_SETUP },
+ { "diff-files", cmd_diff_files, RUN_SETUP | FORBID_PAGER },
{ "diff-index", cmd_diff_index, RUN_SETUP },
{ "diff-tree", cmd_diff_tree, RUN_SETUP },
{ "fast-export", cmd_fast_export, RUN_SETUP },
^ permalink raw reply related
* Git Documentation
From: Scott Chacon @ 2008-07-22 3:35 UTC (permalink / raw)
To: git
Hey all,
I'm starting a project to host a really nice, user-friendly, easy to
use Git learning materials website for Git newbies to get new users
started and make it as easy to learn as possible. I'll be redoing or
editing some of my screencasts from gitcasts.com and starting an open
book at github and putting it all in one place for new users to get
started easily. Anyone will be free to submit changes, additions,
etc.
If anyone has any tips on how they think git should be taught, issues
they are asked a lot, problems newbies tend to have, something they
wish there were a screencast for or was better documented, etc -
please do contact me so I can incorporate it. I would contribute to
git itself, but my C-foo is seriously wanting, so if by teaching
people properly I can free up some time for you guys, I would love to
do so.
Please let me know if you have any pointers or think anything should
really be better documented for end-users. I plan to do a lot of
graphics, screencasts and whatever else makes it as simple as
possible.
Thanks, and thanks again for git.
Scott Chacon
^ permalink raw reply
* Re: [PATCH] mailinfo: better parse email adresses containg parentheses
From: Junio C Hamano @ 2008-07-22 3:16 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: git
In-Reply-To: <1216647269-12287-1-git-send-email-book@cpan.org>
"Philippe Bruhat (BooK)" <book@cpan.org> writes:
> When using git-rebase, author fields containing a ')' at the last
> position had the close-parens character incorrectly removed
> because the From: parser incorrectly matched it as
>
> user@host (User Name)
>
> (removing parentheses), instead of
>
> User Name (me) <user@host>
>
> Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
Hmm, tests?
By the way, that second form parses like this:
mailbox =
name-addr =
display-name angle-addr = "User Name (me) <user@host>"
display-name =
phrase = "User Name"
angle-addr = CFWS "<" addr-spec ">" = "(me) <user@host>"
So strictly speaking, shouldn't we be stripping the whole (me) as garbage?
It is not even part of the display-name but is a whitespace equivalent
comment.
^ permalink raw reply
* Re: git status in clean working dir
From: Junio C Hamano @ 2008-07-22 2:48 UTC (permalink / raw)
To: Jeff King; +Cc: git, David Bremner
In-Reply-To: <7vtzeir68z.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Actually, the situation is now even worse than I originally thought
> especially with Jeff's pager.<cmd> patch on 'master' recently. For
> example, you can screw yourself quite badly by forcing diff-files used in
> the scripts you run to page, defeating --exit-code option. Which means
>
> (1) It hurts? Don't do it then; but
>
> (2) Then why are we even allowing to configure the plumbing to page?
>
> Should we maintain a table of commands that we allow paging to be
> customized, and ignore pager.<cmd> for commands that are not in the list?
>
> Which codepath should issue error messages when the user tries to break
> the system by saying "pager.diff-files = true"?
Another possibility is to set up an extra process whose sole purpose is to
wait for the main process that feeds the pager pipe and relay its exit
status to the outside world. But I do not think we would want to go
there...
^ permalink raw reply
* [PATCH] Revert "make git-status use a pager"
From: Junio C Hamano @ 2008-07-22 2:43 UTC (permalink / raw)
To: git
This reverts commit c8af1de9cfa0a5678ae766777e0f905e60b69fda.
The change was immensely unpopular, and poeple who would really want to
page can use pager.status configuration.
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index 74ea0e6..1bfd271 100644
--- a/git.c
+++ b/git.c
@@ -341,7 +341,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "shortlog", cmd_shortlog, USE_PAGER },
{ "show-branch", cmd_show_branch, RUN_SETUP },
{ "show", cmd_show, RUN_SETUP | USE_PAGER },
- { "status", cmd_status, RUN_SETUP | NEED_WORK_TREE | USE_PAGER },
+ { "status", cmd_status, RUN_SETUP | NEED_WORK_TREE },
{ "stripspace", cmd_stripspace },
{ "symbolic-ref", cmd_symbolic_ref, RUN_SETUP },
{ "tag", cmd_tag, RUN_SETUP },
--
1.6.0.rc0
^ permalink raw reply related
* Re: git status in clean working dir
From: Junio C Hamano @ 2008-07-22 2:40 UTC (permalink / raw)
To: Jeff King; +Cc: git, David Bremner
In-Reply-To: <7vy73ur6pz.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> git status -a
>>
>> exits with 0
>> ...
>
> Try "git status -a >/dev/null" or "git --no-pager status -a".
>
> I think this is an instance of the c8af1de (make git-status use a pager,
> 2008-04-23) stupidity raising its ugly head again.
>
> Do people mind reverting that patch?
Actually, the situation is now even worse than I originally thought
especially with Jeff's pager.<cmd> patch on 'master' recently. For
example, you can screw yourself quite badly by forcing diff-files used in
the scripts you run to page, defeating --exit-code option. Which means
(1) It hurts? Don't do it then; but
(2) Then why are we even allowing to configure the plumbing to page?
Should we maintain a table of commands that we allow paging to be
customized, and ignore pager.<cmd> for commands that are not in the list?
Which codepath should issue error messages when the user tries to break
the system by saying "pager.diff-files = true"?
^ permalink raw reply
* Re: git status in clean working dir
From: Abhijit Menon-Sen @ 2008-07-22 2:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Bremner, git
In-Reply-To: <7vy73ur6pz.fsf@gitster.siamese.dyndns.org>
At 2008-07-21 19:30:16 -0700, gitster@pobox.com wrote:
>
> I think this is an instance of the c8af1de (make git-status use a
> pager, 2008-04-23) stupidity raising its ugly head again.
>
> Do people mind reverting that patch?
I think that is an excellent idea. I've found myself annoyed time and
again by "git status" starting the pager for just a couple of lines of
output.
-- ams
^ permalink raw reply
* Re: git status in clean working dir
From: Junio C Hamano @ 2008-07-22 2:30 UTC (permalink / raw)
To: David Bremner; +Cc: git
In-Reply-To: <0ttzeirft8.wl%bremner@pivot.cs.unb.ca>
David Bremner <bremner@unb.ca> writes:
> According to the manual page for git-status (version 1.5.6.3)
>
> If there is no path that is different between the index file
> and the current HEAD commit (i.e., there is nothing to commit
> by running git-commit), the command exits with non-zero status.
>
> But it doesn't seem to work that way for me.
>
> git status -a
>
> exits with 0
> ...
Try "git status -a >/dev/null" or "git --no-pager status -a".
I think this is an instance of the c8af1de (make git-status use a pager,
2008-04-23) stupidity raising its ugly head again.
Do people mind reverting that patch?
^ permalink raw reply
* Re: [PATCH for master] Rename path_list to string_list
From: Junio C Hamano @ 2008-07-22 2:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0807211904090.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> @@ -64,9 +65,10 @@ Functions
>
> `string_list_clear`::
>
> - Free a string_list. The `path` pointer of the items will be freed in case
> - the `strdup_strings` member of the string_list is set. The second parameter
> - controls if the `util` pointer of the items should be freed or not.
> + Free a string_list. The `path` pointer of the items will be freed in
> + case the `strdup_strings` member of the string_list is set. The second
> + parameter controls if the `util` pointer of the items should be freed
> + or not.
Missed 's/path/string/' here?
Everything else looked fine, thanks.
^ permalink raw reply
* extracting the history of a single file as a new project [Was: Re: making a branch with just one file and keeping its whole]
From: ncrfgs @ 2008-07-22 2:14 UTC (permalink / raw)
To: git; +Cc: madewokherd
In-Reply-To: <alpine.DEB.1.00.0807211937390.8986@racer>
[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]
On Mon, 21 Jul 2008 20:39:45 +0200
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> However, I think that the OP was talking about something completely
> different: extracting the history of a single file as a new branch.
Exactly, but rather than a new branch I'd like to start a new project.
I've just realized the original subject name could have been a bit
misleading; I took it from the description a guy on #git@freenode has
given of what he thought I wanted to do, but probably I didn't explain
myself properly at that time.
> This will not start a new branch, which is what I presume you want to
> do. The "correct" (as in: probably the best) way to do it is to make a
> new directory, initialize a new git repository in it, and when you
> have something, push that branch into the other repository.
As far as I could understand, that screencast demonstrates how to create
empty branches in Git; in other words branches that are not derivatives
of your main branches, but entirely new projects.
In my case I don't want to start an entirely new project, but rather
start a new project from a file of an existing project and keeping his
history.
In the screencast, the author creates an empty branch to store the
website code in for my project, so he doesn't have to store it as a
subdirectory of his main project.
What I want to do, I think, is kinda different.
Let's say we are at commit #3000, I have this content I want to start a
new project from, which has been put in three different files:
path1/filename1 from commit 1 to commit 1000
path2/filename1 from commit 1001 to commit 2000
path2/filename2 from commit 2001 to commit 3000
In the meanwhile path1/filename1 has been created on commit 2500 with
path1/filename1 having nothing to do with the new project I'd like to
start.
My first idea to accomplish what I'd like to do, was to use the ouput of
`git-log -p --follow path2/filename2` with another git command; on
#git@freenode I've been suggested to use git-clone and
git-filter-branch.
Both from search results on the web and from the man pages, I've found
examples of git-filter-branch usage which aim to delete just one file
(or a small group of files) from the existing project's history.
What I'd like to do instead is to keep just one file which has been
renamed a couple of time.
On #git I've been also told to use also another combination of commands
which included git-commit-tree but I haven't managed to understand what
they meant. Another combination of commands included git-am instead.
Any suggestion is welcome. :)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] checkout without arguments does not make sense
From: Johannes Schindelin @ 2008-07-22 0:57 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Avery Pennarun, Johannes Sixt, Junio C Hamano, git
In-Reply-To: <20080721214459.GJ32057@genesis.frugalware.org>
Hi,
On Mon, 21 Jul 2008, Miklos Vajna wrote:
> On Mon, Jul 21, 2008 at 05:36:59PM -0400, Avery Pennarun <apenwarr@gmail.com> wrote:
>
> > I think "git status" reports this information in recent versions,
> > doesn't it?
>
> Right. But that shows other infos as well, for example the untracked
> files, etc. So there are cases when git checkout is just better.
>
> However, you are right about it may not be the best habit from my side
> to use git checkout to get that info. ;-)
I usually call "git status" for that information. But Junio suggested
checkout recently on #git, for exactly that information, so you are not
alone at all.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Junio C Hamano @ 2008-07-22 0:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080721210452.GP10151@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> commit. E.g.
>>
>> $ cd some/deep/path
>> $ git ls-tree --name-only -r HEAD~20
>>
>> will list the files in some/deep/path (i.e. where you are) 20
>> commits ago, just like running "/bin/ls" there will give you the
>> list of files you have right now.
>
> Frankly, I think this is overdoing it. I'm all for being positive, but
> it is obvious why this is good thing when you inspect a root tree and
> there's no need to be too wordy about it...
I mildly disagree.
If the person had truly understood that, why do we even have this thread
to begin with?
Description on *what* it does (i.e. "like what ls -a does in the current
working directory" we have in the Description section) obviously was not
good enough. It will be better understood if you describe *why* it does
it that way at the same time.
^ permalink raw reply
* git status in clean working dir
From: David Bremner @ 2008-07-21 23:13 UTC (permalink / raw)
To: git
According to the manual page for git-status (version 1.5.6.3)
If there is no path that is different between the index file
and the current HEAD commit (i.e., there is nothing to commit
by running git-commit), the command exits with non-zero status.
But it doesn't seem to work that way for me.
git status -a
exits with 0
but
git commit -a
exits with 1
Is the man page wrong, or is this a bug? Or, option #3 ?
David
P.S. Please CC me. I'm not on the list.
^ permalink raw reply
* Re: [PATCH 2/9] Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
From: Johannes Schindelin @ 2008-07-21 23:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1216667998-8879-3-git-send-email-johannes.sixt@telecom.at>
Hi,
On Mon, 21 Jul 2008, Johannes Sixt wrote:
> + bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
> + execdir=$$(cd '$(DESTDIR_SQ)$(gitexecdir_SQ)' && pwd) && \
These lack quotes, no?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/9] Make gitexecdir relative to $(bindir) on Windows
From: Johannes Schindelin @ 2008-07-21 23:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1216667998-8879-1-git-send-email-johannes.sixt@telecom.at>
Hi,
On Mon, 21 Jul 2008, Johannes Sixt wrote:
> The problem was that argv[0] does not have a path in certain cases.
Note that the same holds true for Linux when calling a program that is in
the PATH:
-- snip --
#include <stdio.h>
int main(int argc, char **argv)
{
printf("%s\n", argv[0]);
return 0;
}
-- snap --
compiled and put into the PATH will output just what the user said, not
the full path.
I imagine that the proper solution would be to rip out lookup_prog() and
use it for non-Windows Git, too. Unless you want to limit the usefulness
of your patch series to Windows, that is.
In which case you could use lookup_prog() after unstatifying it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH for master] Rename path_list to string_list
From: Johannes Schindelin @ 2008-07-21 23:33 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <alpine.DEB.1.00.0807211904090.8986@racer>
Hi,
On Mon, 21 Jul 2008, Johannes Schindelin wrote:
> my-prepare-patch.sh | 2 +-
As was pointed out to me privately, this should not have been part of the
interdiff. It is the script I used to prepare the interdiff, and it
needed fixing in order to run without "git-apply" in the PATH. That is
how this change slipped in.
Please just ignore that file,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0
From: Johannes Schindelin @ 2008-07-21 23:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20080721194322.GA4013@blimp.local>
Hi,
On Mon, 21 Jul 2008, Alex Riesen wrote:
> Johannes Schindelin, Mon, Jul 21, 2008 20:20:43 +0200:
>
> > Alex wrote:
> >
> > > Can MSys folks please try it? I noticed it when the test
> > > t2103-update-index-ignore-missing.sh (the 5th case) started failing.
> >
> > Since M$' documentation says "This member does not have a meaning for
> > directories." about the member nFileSizeLow of
> > WIN32_FILE_ATTRIBUTE_DATA which we use to implement a sane "lstat()",
> > I think this bug hits MinGW (not MSys) as well.
>
> Could you, just for completeness, try?
No, I cannot. I have no Windows machine.
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox