* Re: gitk error: expected integer but got "Hamano"
From: Steffen Prohaska @ 2007-12-02 16:41 UTC (permalink / raw)
To: Jing Xue; +Cc: git
In-Reply-To: <20071202160204.GA13141@fawkes>
On Dec 2, 2007, at 5:02 PM, Jing Xue wrote:
>
> I'd try to debug myself but my knowledge on tcl/tk is rather limited
> (read: zero).
See my mail "Corrupted (?) commit 6e6db85e confusing gitk", which
describes the reason in detail.
Steffen
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-12-02 16:39 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Jeff King, Junio C Hamano, Andreas Ericsson, Nicolas Pitre,
Linus Torvalds, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <FFEBE8BB-E764-4DD0-A7DC-8CC01659D9BC@wincent.com>
Hi,
On Sun, 2 Dec 2007, Wincent Colaiuta wrote:
> El 1/12/2007, a las 0:10, Johannes Schindelin escribi?:
>
> > To me, it is mighty annoying anybody brings up that "144 commands"
> > argument Linus was referring to, and if there is _any_ way to shut up
> > those bikeshedders, I am all for it.
>
> This is not a bikeshed argument and it is not an "idiotic complaint" (to
> use Linus' phrase). It is a legitimate concern and a *real* UI problem.
>
> You and Linus don't care that there are 140+ Git commands and I imagine
> that you know exactly what each of them does.
Okay, how many executables are there in your /usr/bin/? Here there are
2973.
Guess what. I am not intimidated by that number.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 6/6] builtin-commit: Add newline when showing which commit was created
From: Jeff King @ 2007-12-02 16:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0712021212490.27959@racer.site>
On Sun, Dec 02, 2007 at 12:13:07PM +0000, Johannes Schindelin wrote:
> > It would be helpful if you could remember the test case, but perhaps
> > that is not an option at this point.
>
> IIRC it was "git commit -m bla".
I have made several attempts to reproduce the problem, looked a bit
through the log-tree code, and checked the results of the t750* series
of tests; but I have found nothing. I think we are better off reverting,
which fixes every case I have seen; if the problem behavior comes back,
we will have figured out what causes it. And if it doesn't come back,
then the revert is the right thing. :)
-- >8 --
Revert "builtin-commit: Add newline when showing which commit was created"
This reverts commit 129fa606365c172d07a5d98bea9345277f221363.
We end up in most cases with an undesired extra newline. It
is possible that there is some corner case that requires the
newline, but there is no published test case. So let's fix
the known problem, and we can deal with the corner case if
and when there is a bug report.
---
builtin-commit.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index f6e8e44..118853d 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -660,7 +660,6 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
printf("Created %scommit ", initial_commit ? "initial " : "");
log_tree_commit(&rev, commit);
- printf("\n");
}
int git_commit_config(const char *k, const char *v)
--
1.5.3.6.2094.g3713
^ permalink raw reply related
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Pascal Obry @ 2007-12-02 16:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, Jeff King, Junio C Hamano, Andreas Ericsson,
Nicolas Pitre, Linus Torvalds, Nguyen Thai Ngoc Duy, Jan Hudec,
git
In-Reply-To: <Pine.LNX.4.64.0712021637250.27959@racer.site>
Johannes Schindelin a écrit :
> Okay, how many executables are there in your /usr/bin/? Here there are
> 2973.
> Guess what. I am not intimidated by that number.
Good, and look in /usr/bin, all those 2973 binary are all disconnected.
Here we are speaking about a tool as a whole : Git.
And I agree that hiding some of them will probably help new comers. We
can also argue that a new comers should read some documentation :)
After all I'm not sure what's the right move !
At least let me say something constructive :) I'm a new comer to Git.
I've read many documentations before grabbing the system and I've not
been impressed by the number of binaries in /usr/bin... Because I've
almost never looked there. Most of the time I'm using "git <tab>" and
the bash completion feature is just right for me.
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
* git-merge --no-commit commits
From: Vegard Nossum @ 2007-12-02 16:57 UTC (permalink / raw)
To: git
Hi,
I am using git 1.5.3.4 and just did the following (v1 and v2 are
branches; v1 is a parent of v2):
git checkout v1
git merge --no-commit v2
It simply fast-forwarded AND committed even though I explicitly told
it not to. What gives?
Kind regards,
Vegard Nossum
^ permalink raw reply
* Re: problems with importing from cvs archive
From: Jeff King @ 2007-12-02 17:07 UTC (permalink / raw)
To: Jean-François Veillette; +Cc: Ed S. Peschko, git
In-Reply-To: <C4B8CB94-3B39-4C14-9134-DE43684A3AB7@yahoo.ca>
On Sun, Dec 02, 2007 at 10:14:07AM -0500, Jean-François Veillette wrote:
> Le 07-12-02 à 01:46, Ed S. Peschko a écrit :
>
>> All,
>>
>> I'm trying to use git-cvsimport to import from a CVS archive, using:
>>
>> git-cvsimport -d $CVSROOT
>
> I was able to go further just by adding the verbose mode ( -v ) :
> git cvsimport -v -d ...
There were some serious problems with the argument parsing of
git-cvsimport with respect to finding the correct module from the git
config or from your CVS working directory. This should all be fixed in
v1.5.3.7; please let me know if you still have a problem with that
version.
-Peff
^ permalink raw reply
* Re: git-merge --no-commit commits
From: Jakub Narebski @ 2007-12-02 17:10 UTC (permalink / raw)
To: Vegard Nossum; +Cc: git
In-Reply-To: <19f34abd0712020857m757c57cfr358a81e47f38fac8@mail.gmail.com>
"Vegard Nossum" <vegard.nossum@gmail.com> writes:
> I am using git 1.5.3.4 and just did the following (v1 and v2 are
> branches; v1 is a parent of v2):
>
> git checkout v1
> git merge --no-commit v2
>
> It simply fast-forwarded AND committed even though I explicitly told
> it not to. What gives?
The --no-commit option doesn't prevent fast-forward because
fast-forward doesn't really _create_ a commit (and -no-commit is
really about commit creation). It just advanced ref (branch head).
You probably wanted to use
$ git merge --no-commit --no-ff v2
HTH
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: git-merge --no-commit commits
From: Vegard Nossum @ 2007-12-02 17:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3bq99vx7t.fsf@roke.D-201>
On Dec 2, 2007 6:10 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Vegard Nossum" <vegard.nossum@gmail.com> writes:
>
> > I am using git 1.5.3.4 and just did the following (v1 and v2 are
> > branches; v1 is a parent of v2):
> >
> > git checkout v1
> > git merge --no-commit v2
> >
> > It simply fast-forwarded AND committed even though I explicitly told
> > it not to. What gives?
>
> The --no-commit option doesn't prevent fast-forward because
> fast-forward doesn't really _create_ a commit (and -no-commit is
> really about commit creation). It just advanced ref (branch head).
>
> You probably wanted to use
>
> $ git merge --no-commit --no-ff v2
>
Yes. Thanks. Isn't that counter-intuitive, though? The manpage says
that it lets you review the changes first. I assumed this would
include fast-forwarding as well. There is no --no-ff in my git-merge
manpage. Maybe I need a newer version?
> HTH
> --
> Jakub Narebski
> ShadeHawk on #git
> Poland
>
Vegard
^ permalink raw reply
* Re: [PATCH 6/6] builtin-commit: Add newline when showing which commit was created
From: Johannes Schindelin @ 2007-12-02 17:18 UTC (permalink / raw)
To: Jeff King; +Cc: git, krh, gitster
In-Reply-To: <20071202165409.GA30998@coredump.intra.peff.net>
Hi,
On Sun, 2 Dec 2007, Jeff King wrote:
> On Sun, Dec 02, 2007 at 12:13:07PM +0000, Johannes Schindelin wrote:
>
> > > It would be helpful if you could remember the test case, but perhaps
> > > that is not an option at this point.
> >
> > IIRC it was "git commit -m bla".
>
> I have made several attempts to reproduce the problem, looked a bit
> through the log-tree code, and checked the results of the t750* series
> of tests; but I have found nothing.
I remember again. When I did "commit -s -m bla" the empty line between
the oneline and the signoff would be missing. But in the meantime, the
signoff was dragged into the strbuf and all is well.
ACK.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] t9600: test cvsimport from CVS working tree
From: Jeff King @ 2007-12-02 17:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This test passes with v1.5.3.7, but not with v1.5.3.6.
Signed-off-by: Jeff King <peff@peff.net>
---
I wrote this to investigate a reported bug (which turned out
to be fixed by the recent cvsimport patches). No bug to fix,
but I think it's a good test to have in general.
t/t9600-cvsimport.sh | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 29fee2d..08f0f2a 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -119,4 +119,16 @@ test_expect_success 'cvsimport.module config works' '
'
+test_expect_success 'import from a CVS working tree' '
+
+ cvs co -d import-from-wt module &&
+ cd import-from-wt &&
+ git cvsimport -a -z0 &&
+ echo 1 >expect &&
+ git log -1 --pretty=format:%s%n >actual &&
+ git diff actual expect &&
+ cd ..
+
+'
+
test_done
--
1.5.3.6.2094.g0ce9a-dirty
^ permalink raw reply related
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Johannes Schindelin @ 2007-12-02 17:23 UTC (permalink / raw)
To: Pascal Obry
Cc: Wincent Colaiuta, Jeff King, Junio C Hamano, Andreas Ericsson,
Nicolas Pitre, Linus Torvalds, Nguyen Thai Ngoc Duy, Jan Hudec,
git
In-Reply-To: <4752E3D0.6030802@obry.net>
Hi,
On Sun, 2 Dec 2007, Pascal Obry wrote:
> Johannes Schindelin a ?crit :
> > Okay, how many executables are there in your /usr/bin/? Here there
> > are 2973. Guess what. I am not intimidated by that number.
>
> Good, and look in /usr/bin, all those 2973 binary are all disconnected.
>
> Here we are speaking about a tool as a whole : Git.
No, we are speaking about different commands, such as commit, fetch, push,
etc.
I refuse to believe that you cannot see the equivalence.
> I've read many documentations before grabbing the system and I've not
> been impressed by the number of binaries in /usr/bin... Because I've
> almost never looked there.
Exactly my point.
> Most of the time I'm using "git <tab>" and the bash completion feature
> is just right for me.
Bash completion is really something fine.
But even without, I do not see a problem: many cvs users used only three
out of 32 commands (most CVS users I personally know/knew only called add,
commit and update). You could even see all 32 commands when calling the
clunky command line "cvs --help-commands". I am convinced we're already
more user-friendly than that.
Ciao,
Dscho
^ permalink raw reply
* git + unison
From: Matthieu Moy @ 2007-12-02 17:59 UTC (permalink / raw)
To: git
Hi,
I'm wondering how dangerous the interaction of git with the unison
file synchronizer[1] can be.
Another way of asking the question can be: what's the best way to
keep two machines with many git repositories in sync?
Unison is a userland application that does bi-directional
synchronization of two directories. Typically, to keep a laptop and a
desktop synchronized (modify a file on the desktop and another on the
laptop, unison will copy the files). I find it very usefull to keep
large directories containing unrelated projects (typically,
~/teaching/, ~/research, ..., my colleagues even synchronize $HOME on
their laptops) in sync between two machines.
Actually, git achives something similar (and lot more, of course):
modify a file here, commit, modify another there, commit, and then
push & pull can do the sync. I find git excellent to manage somehow
self-contained projects (~/teaching/2007-2008/whatever-course/), but
inappropriate for $HOME or such big containers (need to run more
commands, disk-space overhead, ...).
So, at the moment, I have both unison and git. My fear is that unison
touches the content of the .git/ directories. So, for example, if I
commit on one side, and commit something else on the other side, I'll
get unison conflicts at least on .git/refs/heads/master and
.git/index, and resolving the conflict in favor of either side leads
to dangling objects whith important content.
What I'm doing right now is that I try to make sure I don't run unison
when trees have diverged, which is not really satisfactory since 1) I
can be wrong, and a miss-synchronization could lead to data-loss, and
2) that means not really taking advantage of unison.
What about you? What do you use to synchronize your laptop and
desktop, or home and office? Anybody using unison and git on the same
filesystem?
Thanks for your hints,
--
Matthieu
[1] : http://www.cis.upenn.edu/~bcpierce/unison/
^ permalink raw reply
* Re: git-merge --no-commit commits
From: Jakub Narebski @ 2007-12-02 18:00 UTC (permalink / raw)
To: Vegard Nossum; +Cc: git
In-Reply-To: <19f34abd0712020918w1640389kb0ca006b2051a678@mail.gmail.com>
On Sun, 2 Dec 2007, Vegard Nossum wrote:
> On Dec 2, 2007 6:10 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Vegard Nossum" <vegard.nossum@gmail.com> writes:
>>
>>> I am using git 1.5.3.4 and just did the following (v1 and v2 are
>>> branches; v1 is a parent of v2):
>>>
>>> git checkout v1
>>> git merge --no-commit v2
>>>
>>> It simply fast-forwarded AND committed even though I explicitly told
>>> it not to. What gives?
>>
>> The --no-commit option doesn't prevent fast-forward because
>> fast-forward doesn't really _create_ a commit (and -no-commit is
>> really about commit creation). It just advanced ref (branch head).
>>
>> You probably wanted to use
>>
>> $ git merge --no-commit --no-ff v2
>
> Yes. Thanks. Isn't that counter-intuitive, though? The manpage says
> that it lets you review the changes first. I assumed this would
> include fast-forwarding as well.
But for fast-forward there are no "changes" to review. Just updating
branch head. Fast-forward means no new commit.
> There is no --no-ff in my git-merge
> manpage. Maybe I need a newer version?
It looks like it is not in any released version. I've found description
in 'master' version of Documentation/merge-options.txt
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git + unison
From: Remi Vanicat @ 2007-12-02 18:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqd4tpgepj.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Hi,
>
[...]
Note that I do use I do use both unison and git, but I don't use
unison on git repository (I use git to synchronize git repository).
> So, at the moment, I have both unison and git. My fear is that unison
> touches the content of the .git/ directories. So, for example, if I
> commit on one side, and commit something else on the other side, I'll
> get unison conflicts at least on .git/refs/heads/master and
> .git/index, and resolving the conflict in favor of either side leads
> to dangling objects whith important content.
Well, at least with my configuration, when a file have been change on
both side, unison offer the possibility to transfer one way or the
other or to do nothing. I believe that if this happen, the correct
procure is to use git tool to merge (as git is better for merging
than unison, even more when we are speaking about git repository)
>
> What I'm doing right now is that I try to make sure I don't run unison
> when trees have diverged, which is not really satisfactory since 1) I
> can be wrong, and a miss-synchronization could lead to data-loss, and
> 2) that means not really taking advantage of unison.
Well, as I've already said, I use unison in an interactive way, so if
a file have been changed in both side, unison say it, ask me what to
do. So I can choose to do nothing, and to stop unison right away to
use a better tool for this task.
--
Rémi Vanicat
^ permalink raw reply
* Re: [PATCH 6/6] builtin-commit: Add newline when showing which commit was created
From: Junio C Hamano @ 2007-12-02 18:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0712021716220.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I have made several attempts to reproduce the problem, looked a bit
>> through the log-tree code, and checked the results of the t750* series
>> of tests; but I have found nothing.
>
> I remember again. When I did "commit -s -m bla" the empty line between
> the oneline and the signoff would be missing. But in the meantime, the
> signoff was dragged into the strbuf and all is well.
Sorry, now I am confused. Building the version before that change and
doing "./git-commit -a -s -m bla", I do not see the extra blank line in
the "Created commit" response, and I see a blank line before and after
the sign-off in the "git show" output for the resulting commit.
Was this unnecessary change from the beginning? I am inclined to think
so...
^ permalink raw reply
* Re: [PATCH] Adding menu for Emacs git.el
From: Alexandre Julliard @ 2007-12-02 18:42 UTC (permalink / raw)
To: =?utf-8?q?R=C3=A9mi=20Vanicat?=; +Cc: git
In-Reply-To: <87mysvfr7e.dlv@vanicat.homelinux.org>
"=?utf-8?q?R=C3=A9mi=20Vanicat?=" <vanicat@debian.org>, Remi Vanicat
<vanicat@debian.org> writes:
> Adding three menu to the git-status-mode of git.el : One for marking
> and unmarking, one for every thing you need when you have a conflict,
> and a last one for all the rest.
>
> Signed-off-by: Rémi Vanicat <vanicat@debian.org>
It looks good to me. A couple of minor details:
> + ["Interctive Diff File" git-diff-file-idiff t]
There's a typo here.
> + ["Show Uptodate" git-toggle-show-uptodate :style toggle :selected git-show-uptodate]
> + ["Toggle Show Ignored" git-toggle-show-ignored :style toggle :selected git-show-ignored]
> + ["Toggle Show Unknown" git-toggle-show-unknown :style toggle :selected git-show-unknown]))
I'd get rid of 'Toggle' on the last two for consistency.
BTW do you have a copyright assignment for Emacs?
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: Difference in how "git status" and "git diff --name-only" lists filenames
From: Junio C Hamano @ 2007-12-02 18:44 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git
In-Reply-To: <bf7b2dda0712020604x209d6665i9ab58b32834b2cee@mail.gmail.com>
"Gustaf Hendeby" <hendeby@gmail.com> writes:
> A while ago 'git status' was patched to report relative pathnames. (I
> like that change it makes cut'n'paste easier.) However, 'git diff
> --name-only' and 'git diff --name-status' (other commands as well),
> which gives in a sense similar output has not been changed the same
> way. Is this intentionally, or just because no one has stepped up and
> provided a patch? If the difference is to stay, maybe this should be
> reflected in the help texts to avoid any confusion.
The commands output from diff always talks about paths relative to the
tree root, and scripts rely on it. The recent change made exceptions to
the status command. I agree an additional documentation to git-status
would be beneficial.
Having said that, a switch --relative-name might be an option. It could
be argued that doing it the other way around (like --full-name option to
ls-files does), defaulting to relative to cwd, would have been a getter
approach if we were doing git from scratch, though. We may still want
to do so in the longer run, but that would be a huge interface change
that would impact a lot of peoples' scripts.
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 8fd0fc6..b0cb6bc 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -40,6 +40,10 @@ OUTPUT
The output from this command is designed to be used as a commit
template comments, and all the output lines are prefixed with '#'.
+The paths mentioned in the output, unlike many other git commands, are
+made relative to the current directory, if you are working in a
+subdirectory (this is on purpose, to help cutting and pasting).
+
CONFIGURATION
-------------
^ permalink raw reply related
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Junio C Hamano @ 2007-12-02 18:53 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <5F1A20CC-7427-4E7A-AB95-E89C9FA17951@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> I'd like to conclude with some questions:
> - Is this commit corrupted?
> - How was the commit created?
> - Should "git fsck" detect such corruption?
> - Should gitk more gracefully handle corrupted commits?
Yeah, I was wondering what that commit that records the change older
than git or myself come to life ;-)
I did rewrite the commit a few times, and it was some interaction
between the built-in commit series, git-rebase -i and git-am, but I do
not have the details, sorry.
^ permalink raw reply
* Re: git + unison
From: J. Bruce Fields @ 2007-12-02 19:05 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqd4tpgepj.fsf@bauges.imag.fr>
On Sun, Dec 02, 2007 at 06:59:36PM +0100, Matthieu Moy wrote:
> What about you? What do you use to synchronize your laptop and
> desktop, or home and office? Anybody using unison and git on the same
> filesystem?
I just have a subdirectory of my home directory "local" that I tell
unison not to synchronize:
ignore = Path local
and keep all my git repos there, relying on git itself when I need to
distribute stuff--generally all my repos are associated with public
repos on a single (regularly backed-up) server, and I try not to let any
work accumulate in any particular repository for long without being
pushed to a branch in its public repo.
--b.
^ permalink raw reply
* Re: [PATCH] Highlight keyboard shortcuts in git-add--interactive
From: Junio C Hamano @ 2007-12-02 19:06 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, dzwell, peff, Matthieu.Moy
In-Reply-To: <5B4BC281-10BD-437F-A956-EEB73F40A76C@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> Unless by "documentation" you meant to somehow expose these in the
> interface at runtime... something like this? (applied on top of the
> patch I just sent to the list):
I did not recall (and was too lazy to check) if they were documented
already, but as you suggest, I think letting people type ? at the prompt
to get a help is always a good idea. So, instead of doing this part:
> @@ -308,7 +309,7 @@ sub list_and_choose {
> print "> ";
> }
> else {
> - print ">> ";
> + print " (?)>> ";
I'd prefer accepting '?' as a valid "help me" input and showing
appropriate help for _both_ singleton select and multiple select,
without mentioning " (?)". For this, your prompt_help_cmd needs to be
enhanced to limit the help to singleton case, though.
^ permalink raw reply
* Re: [RFC] use typechange as rename source
From: Junio C Hamano @ 2007-12-02 19:15 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071201064916.GA7431@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> And maybe something like this on top for git-status?
>
> diff --git a/wt-status.c b/wt-status.c
> index 0e0439f..e77120d 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -250,6 +250,7 @@ static void wt_status_print_updated(struct wt_status *s)
> rev.diffopt.format_callback_data = s;
> rev.diffopt.detect_rename = 1;
> rev.diffopt.rename_limit = 100;
> + rev.diffopt.break_opt = 0;
> wt_read_cache(s);
> run_diff_index(&rev, 1);
> }
I have to wonder how much this is going to make things worse in the real
world, although I agree in the "as we already spend cycles for
detect_rename why not" sense.
With the recent change from Alex not to run status when not interactive,
it probably does not matter. If we are going to spawn an editor, we are
dealing with human interaction and even -B -M should not be too bad.
^ permalink raw reply
* Re: [PATCH 1/3] git-help: add -i|--info option to display info page.
From: Pascal Obry @ 2007-12-02 8:54 UTC (permalink / raw)
To: Christian Couder
Cc: Junio Hamano, git, Theodore Tso, Jakub Narebski, Alex Riesen,
Andreas Ericsson, Matthieu Moy, Eric Wong
In-Reply-To: <20071202060740.269e54ad.chriscool@tuxfamily.org>
Christian Couder a écrit :
> "git help --info XXX" will now call "info git-XXX".
If would be nice if this could be more generic. For example I'd like to
use Emacs woman mode instead of info. Can't we have something like
$ git help --ext XXX
"ext" standing for external and calling whatever command recorded into
.gitconfig for example ?
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: Corrupted (?) commit 6e6db85e confusing gitk
From: Brian Downing @ 2007-12-02 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <7vir3hx70y.fsf@gitster.siamese.dyndns.org>
On Sun, Dec 02, 2007 at 10:53:33AM -0800, Junio C Hamano wrote:
> Yeah, I was wondering what that commit that records the change older
> than git or myself come to life ;-)
>
> I did rewrite the commit a few times, and it was some interaction
> between the built-in commit series, git-rebase -i and git-am, but I do
> not have the details, sorry.
It looks like the "guilty" commit that allowed this behavior was:
commit 13208572fbe8838fd8835548d7502202d1f7b21d
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Sun Nov 11 17:35:58 2007 +0000
builtin-commit: fix --signoff
The Signed-off-by: line contained a spurious timestamp. The reason was
a call to git_committer_info(1), which automatically added the
timestamp.
Instead, fmt_ident() was taught to interpret an empty string for the
date (as opposed to NULL, which still triggers the default behavior)
as "do not bother with the timestamp", and builtin-commit.c uses it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the above, something like:
echo msg | GIT_AUTHOR_DATE='' git commit-tree sha1
will produce a broken commit without a timestamp, since fmt_ident is
also used for the committer and author lines.
Personally, I think if the date_str is not NULL, it should die() on
anything that can't successfully be parsed as a date, rather than simply
falling back to the current time. But maybe that's a bit extreme.
-bcd
^ permalink raw reply
* [PATCH] contrib: Make remotes2config.sh script more robust
From: Jakub Narebski @ 2007-12-02 19:40 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Jakub Narebski
The remotes2config.sh script replaced all 'unsafe' characters in repo
name with '.'; include '-' in the 'safe' characters set (the set is
probably even larger).
Script required also space after "URL:", "Push:" and "Pull:" in
remotes file. This for example made the following remote
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/heads/origin
Pull:+refs/heads/pu:refs/heads/pu
miss 'pu' branch (forced branch) in config file after conversion.
Allow for any number of whitespace after "URL:", "Push:", "Pull:".
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
contrib/remotes2config.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
mode change 100644 => 100755 contrib/remotes2config.sh
diff --git a/contrib/remotes2config.sh b/contrib/remotes2config.sh
old mode 100644
new mode 100755
index 5838b3a..1cda19f
--- a/contrib/remotes2config.sh
+++ b/contrib/remotes2config.sh
@@ -11,11 +11,11 @@ if [ -d "$GIT_DIR"/remotes ]; then
{
cd "$GIT_DIR"/remotes
ls | while read f; do
- name=$(printf "$f" | tr -c "A-Za-z0-9" ".")
+ name=$(printf "$f" | tr -c "A-Za-z0-9-" ".")
sed -n \
- -e "s/^URL: \(.*\)$/remote.$name.url \1 ./p" \
- -e "s/^Pull: \(.*\)$/remote.$name.fetch \1 ^$ /p" \
- -e "s/^Push: \(.*\)$/remote.$name.push \1 ^$ /p" \
+ -e "s/^URL:[ ]*\(.*\)$/remote.$name.url \1 ./p" \
+ -e "s/^Pull:[ ]*\(.*\)$/remote.$name.fetch \1 ^$ /p" \
+ -e "s/^Push:[ ]*\(.*\)$/remote.$name.push \1 ^$ /p" \
< "$f"
done
echo done
--
1.5.3.6
^ permalink raw reply related
* Re: Corrupted (?) commit 6e6db85e confusing gitk
From: Linus Torvalds @ 2007-12-02 20:34 UTC (permalink / raw)
To: Brian Downing; +Cc: Junio C Hamano, Steffen Prohaska, Git Mailing List
In-Reply-To: <20071202193918.GQ6212@lavos.net>
On Sun, 2 Dec 2007, Brian Downing wrote:
>
> With the above, something like:
>
> echo msg | GIT_AUTHOR_DATE='' git commit-tree sha1
>
> will produce a broken commit without a timestamp, since fmt_ident is
> also used for the committer and author lines.
Ouch. And I notice that fsck doesn't even warn about the resulting broken
commit. Partly because I was lazy, but partly because originally I was
thinking that maybe we'll have more header lines, so fsck basically just
checks the ones that git *really* cares about (parenthood and tree), and
the rest is not really even looked at (well, it does check that the next
line starts with "author", but that's it).
I guess the breakage is pretty benign, but this is still very wrong.
Junio: that broken commit seems to be in "pu" only - we should make sure
that it never makes it into next or master, so that it will eventually get
pruned out of history.
Linus
^ 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