* Re: What's cooking in git.git (topics)
From: Bill Lear @ 2007-11-01 22:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Johan Herland, git, Geert Bosch
In-Reply-To: <alpine.LFD.0.999.0711011459490.3342@woody.linux-foundation.org>
On Thursday, November 1, 2007 at 15:05:44 (-0700) Linus Torvalds writes:
>...
>But yeah, I guess we could make the "clean.Imagirlyman" option (or however
>the "please-don't-hurt-me-by-default" option is spelled) the default. That
>way I'd just feel *extra* manly for immediately disabling it, and laughing
>at you wimps.
Precisely my sentiments.
Bill
^ permalink raw reply
* Re: [PATCH] Make git-mailinfo strip whitespace from the start of the mail file.
From: Junio C Hamano @ 2007-11-01 22:26 UTC (permalink / raw)
To: Simon Sasburg; +Cc: Junio C Hamano, git
In-Reply-To: <981e6de60711011441n5bef772cuda381c539c0a2603@mail.gmail.com>
"Simon Sasburg" <simon.sasburg@gmail.com> writes:
>> Just to help me understand why this change is needed...
>>
>> Are you using mailinfo directly without splitting with mailsplit
>> first?
>
> Well, when using gmail's web interface, when reading a mail, there is
> this option to show the raw mail text (headers+body) with the 'show
> original' option.
>
> If you do 'save as..' in your browser to save what you get with that,
> and try to do git-am on that file, it fails because it starts with
> some whitespace.
>
> With this patch git-am works on these files.
>
> So, i'm not using mailsplit or any other mail tools at all, just my
> browser and git.
Ah, I meant "git-mailsplit", which is the command internally run
by "git-am" to preprocess the file and to split it into
individual mail pieces to be fed to "git-mailinfo".
That may suggest the change is better done in git-mailsplit not
git-mailinfo.
Or perhaps both.
^ permalink raw reply
* Re: [PATCH] gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb test
From: Junio C Hamano @ 2007-11-01 22:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1193923396-17341-1-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> It does appear to do nothing; gitweb is run as standalone program
> and not as CGI script in this test. This call caused problems later.
Care to describe "later problems" a bit more?
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> t/t9500-gitweb-standalone-no-errors.sh | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
> index f7bad5b..1bf0988 100755
> --- a/t/t9500-gitweb-standalone-no-errors.sh
> +++ b/t/t9500-gitweb-standalone-no-errors.sh
> @@ -31,7 +31,6 @@ our \$projects_list = "";
> our \$export_ok = "";
> our \$strict_export = "";
>
> -CGI::Carp::set_programname("gitweb/gitweb.cgi");
> EOF
>
> cat >.git/description <<EOF
> --
> 1.5.3.5
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Linus Torvalds @ 2007-11-01 22:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, git, Geert Bosch
In-Reply-To: <7v8x5hab3d.fsf@gitster.siamese.dyndns.org>
On Thu, 1 Nov 2007, Junio C Hamano wrote:
>
> "git clean" is about things that git usually do not care about
> (i.e. things not in .gitignore, or even in .gitignore when -x is
> given). Everything else including "git stash" is all about what
> git cares about (i.e. tracked paths).
Right. I *love* "git clean". Real men have everything they care about
tracked by git, and thus by definition "git clean" is the safest operation
possible. I don't understand how anybody can call it "unsafe".
I just wish it was quiet by default - right now it takes a _loong_ time to
clean out your crud just because it scrolls forever talking about all
those girly files you don't want to keep - and that it had -x and -d on by
default, so that us *real* men wouldn't have to type so much.
But making it accept combined options, so that you can do "git clean -xdq"
would certainly already be a huge improvement.
But yeah, I guess we could make the "clean.Imagirlyman" option (or however
the "please-don't-hurt-me-by-default" option is spelled) the default. That
way I'd just feel *extra* manly for immediately disabling it, and laughing
at you wimps.
Linus
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Pierre Habouzit @ 2007-11-01 21:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999.0711011129460.3342@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]
On Thu, Nov 01, 2007 at 06:33:13PM +0000, Linus Torvalds wrote:
>
>
> On Wed, 31 Oct 2007, Junio C Hamano wrote:
> >
> > * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
> > + ...
> >
> > It appears 1.5.4 will be, to a certain extent, a "Let's clean up
> > the internal implementation" release. This series should become
> > part of it. Hopefully will merge to 'master' soon, but I
> > haven't looked this series very closely yet.
>
> I certainly think this should go in, but it does make one deficiency
> painfully clear: the remaining shell scripts end up having all the old
> flags behaviour.
Those are not the only commands with issues: not all builtins are
migrated on the new option parser, and those with recursive options (I
mean the ones that use diff options e.g.) are not migrated yet either,
because the option parser does not supports a mechanism to deal with
them.
The issue is not to let parse_option recurse into anoter option
structure, it's that if you do so, you want to express the address of
the "options" to patch in a relative and not absolute way, and I've not
decided myself mind about a way to do that yet.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-01 21:51 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Geert Bosch, Linus Torvalds
In-Reply-To: <200711012232.57286.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> What about making "git clean" _stash_ your changes instead of deleting them
> (so that you can undo the clean)? Preferably they should be stashed
> somewhere _other_ than where "git stash" does its thing. "git clean" could
> even delete the stash immediately, but keep the reflog around so that
> the "clean" at least could be undone within 30 days (or whatever is the
> current default).
>
> Thoughts?
Unthoughts. That does not mesh with the way how world works.
"git clean" is about things that git usually do not care about
(i.e. things not in .gitignore, or even in .gitignore when -x is
given). Everything else including "git stash" is all about what
git cares about (i.e. tracked paths).
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Pierre Habouzit @ 2007-11-01 21:46 UTC (permalink / raw)
To: Brian Downing; +Cc: Junio C Hamano, git
In-Reply-To: <20071101214131.GF4099@lavos.net>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
On Thu, Nov 01, 2007 at 09:41:31PM +0000, Brian Downing wrote:
> On Wed, Oct 31, 2007 at 10:41:06PM -0700, Junio C Hamano wrote:
> > * jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit
> > - git-diff: complain about >=8 consecutive spaces in initial indent
> >
> > This is a counterpart of an earlier patch from J. Bruce Fields
> > to change "git-apply --whitespace" to make SP{8,} at the
> > beginning of line a whitespace error.
> >
> > Personally, I am in favor of the stricter check, but I had to
> > reject the "git-apply" patch because there was no way to disable
> > the additional check without disabling the existing check for
> > trailing whitespaces. We probably would want to revisit that
> > one (perhaps with a new option and/or config to selectively
> > enable different kinds of whitespace check).
> I don't want to get into another stupid holy war about the superiority
> of indent styles (the last one was quite enough, thank you), but there
> are real projects out there that have a spaces-only-indent policy and
> use Git, and this change as is isn't good for them.
Seconded.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Pierre Habouzit @ 2007-11-01 21:44 UTC (permalink / raw)
To: Mike Hommey; +Cc: Junio C Hamano, Geert Bosch, Linus Torvalds, git
In-Reply-To: <20071101204755.GA15842@glandium.org>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Thu, Nov 01, 2007 at 08:47:55PM +0000, Mike Hommey wrote:
> On Thu, Nov 01, 2007 at 01:27:55PM -0700, Junio C Hamano wrote:
> > Geert Bosch <bosch@adacore.com> writes:
> >
> > > I often type "make clean" as well many "git xyz" commands
> > > during development, and so it happens that at times, I type
> > > "git clean" by accident.
> >
> > Happened to me once. I hate that command.
>
> Speaking of hateful commands, git stash clear is one of them.
> I tend to type git stash clean, which creates a "clean" stash...
I agree, the most itching issue is that usually, this action in git is
called `prune'. So it's inconsistant. I would have much prefered that
git stash would take its actions as options so that if you mistakenly
type a wrong command, the options parsers sees that and fails.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Pierre Habouzit @ 2007-11-01 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Geert Bosch, Linus Torvalds, git
In-Reply-To: <7v4pg5btis.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
On Thu, Nov 01, 2007 at 08:27:55PM +0000, Junio C Hamano wrote:
> Geert Bosch <bosch@adacore.com> writes:
>
> > I often type "make clean" as well many "git xyz" commands
> > during development, and so it happens that at times, I type
> > "git clean" by accident.
>
> Happened to me once. I hate that command.
>
> > So, I propose *not* converting git clean to a C builtin,
> > but instead adding --untracked and --ignored options to
> > git-rm.
>
> I think what you are trying to do is to deprecate or remove "git
> clean".
>
> I do not know where "git clean" came from. I am suspecting that
> it was to give counterparts to some other SCMs, but do not know
> which ones. Some people wanted to have it --- so you need to
> convince them that it is a bad idea first. Adding an equivalent
> options to "git rm" alone does not solve that issue.
FWIW I do use git clean a _lot_. I don't mind if it's doable from
another kind of command, but I do use git clean and even git clean -x a
lot, because it achives cleansing my repository faster (and sometimes
faster) than a `make distclean` would do.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Brian Downing @ 2007-11-01 21:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmytycykt.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 31, 2007 at 10:41:06PM -0700, Junio C Hamano wrote:
> * jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit
> - git-diff: complain about >=8 consecutive spaces in initial indent
>
> This is a counterpart of an earlier patch from J. Bruce Fields
> to change "git-apply --whitespace" to make SP{8,} at the
> beginning of line a whitespace error.
>
> Personally, I am in favor of the stricter check, but I had to
> reject the "git-apply" patch because there was no way to disable
> the additional check without disabling the existing check for
> trailing whitespaces. We probably would want to revisit that
> one (perhaps with a new option and/or config to selectively
> enable different kinds of whitespace check).
Just to throw in my two cents, I would be strongly opposed to this
going in without some form of configuration to make it work for
spaces-only-indent projects. I appreciate having whitespace checking,
and I think trailing whitespace and tabs-following-spaces are obviously
bad enough that they should always be flagged. But flagging leading
spaces makes a legitimate and common coding style yield incredibly
obnoxious-looking diffs.
I don't want to get into another stupid holy war about the superiority
of indent styles (the last one was quite enough, thank you), but there
are real projects out there that have a spaces-only-indent policy and
use Git, and this change as is isn't good for them.
-bcd
^ permalink raw reply
* Re: [PATCH] Make git-mailinfo strip whitespace from the start of the mail file.
From: Simon Sasburg @ 2007-11-01 21:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4utabx0.fsf@gitster.siamese.dyndns.org>
> Just to help me understand why this change is needed...
>
> Are you using mailinfo directly without splitting with mailsplit
> first?
Well, when using gmail's web interface, when reading a mail, there is
this option to show the raw mail text (headers+body) with the 'show
original' option.
If you do 'save as..' in your browser to save what you get with that,
and try to do git-am on that file, it fails because it starts with
some whitespace.
With this patch git-am works on these files.
So, i'm not using mailsplit or any other mail tools at all, just my
browser and git.
^ permalink raw reply
* Gitweb is preprocessing content when it shouldn't
From: Francesco Pretto @ 2007-11-01 21:36 UTC (permalink / raw)
To: git
I was trying to follow the gitweb/README [1] to obtain http URLs that
were valid both as cloneable GIT URL and as browseable gitweb
interfaces. Unfortunately, gitweb is preprocessing all the content
inside http://domain/repo.dir/ , so the command:
git clone http://git.vpsaruba.homeunix.org/bproofs.git
fails while trying to read XHTML generated pages.
I'm not yet sure if this is behaviour recently changed in gitweb but I
suppose this "hack" once worked (otherwise it wouldn't have been
documented).
My apache/vhost configuration follows:
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
<Directory "/var/www/cgi-bin">
Options Indexes FollowSymlinks ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory>
<VirtualHost 62.149.168.100:80>
ServerName git.vpsaruba.homeunix.org:80
DocumentRoot /var/git
RewriteEngine on
RewriteRule ^/(.*\.git/(?!/?(info|objects|refs)).*)?$
/cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
</VirtualHost>
Any consideration is appreciated.
Thanks,
Francesco
[1] http://git.kernel.org/?p=git/git.git;a=blob_plain;f=gitweb/README;hb=HEAD
^ permalink raw reply
* Re: [PATCH] Make git-mailinfo strip whitespace from the start of the mail file.
From: Junio C Hamano @ 2007-11-01 21:33 UTC (permalink / raw)
To: Simon Sasburg; +Cc: git, gitster
In-Reply-To: <1193951139-2312-1-git-send-email-Simon.Sasburg@gmail.com>
Just to help me understand why this change is needed...
Are you using mailinfo directly without splitting with mailsplit
first?
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johan Herland @ 2007-11-01 21:32 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Geert Bosch, Linus Torvalds
In-Reply-To: <7v4pg5btis.fsf@gitster.siamese.dyndns.org>
On Thursday 01 November 2007, Junio C Hamano wrote:
> Geert Bosch <bosch@adacore.com> writes:
>
> > I often type "make clean" as well many "git xyz" commands
> > during development, and so it happens that at times, I type
> > "git clean" by accident.
>
> Happened to me once. I hate that command.
>
> > So, I propose *not* converting git clean to a C builtin,
> > but instead adding --untracked and --ignored options to
> > git-rm.
>
> I think what you are trying to do is to deprecate or remove "git
> clean".
>
> I do not know where "git clean" came from. I am suspecting that
> it was to give counterparts to some other SCMs, but do not know
> which ones. Some people wanted to have it --- so you need to
> convince them that it is a bad idea first. Adding an equivalent
> options to "git rm" alone does not solve that issue.
What about making "git clean" _stash_ your changes instead of deleting them
(so that you can undo the clean)? Preferably they should be stashed
somewhere _other_ than where "git stash" does its thing. "git clean" could
even delete the stash immediately, but keep the reflog around so that
the "clean" at least could be undone within 30 days (or whatever is the
current default).
Thoughts?
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH 3/3] Make git-svn rebase --dirty pass along --dirty to git-rebase.
From: Simon Sasburg @ 2007-11-01 21:30 UTC (permalink / raw)
To: gitster; +Cc: git, Simon Sasburg
In-Reply-To: <1193952624-608-3-git-send-email-Simon.Sasburg@gmail.com>
Signed-off-by: Simon Sasburg <Simon.Sasburg@gmail.com>
---
git-svn.perl | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 22bb47b..5898a26 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -63,7 +63,7 @@ my ($_stdin, $_help, $_edit,
$_message, $_file,
$_template, $_shared,
$_version, $_fetch_all, $_no_rebase,
- $_merge, $_strategy, $_dry_run, $_local,
+ $_merge, $_strategy, $_dry_run, $_local, $_dirty,
$_prefix, $_no_checkout, $_verbose);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
@@ -169,6 +169,7 @@ my %cmd = (
'verbose|v' => \$_verbose,
'strategy|s=s' => \$_strategy,
'local|l' => \$_local,
+ 'dirty|d' => \$_dirty,
'fetch-all|all' => \$_fetch_all,
%fc_opts } ],
'commit-diff' => [ \&cmd_commit_diff,
@@ -482,16 +483,20 @@ sub cmd_find_rev {
}
sub cmd_rebase {
- command_noisy(qw/update-index --refresh/);
+ unless ($_dirty) {
+ command_noisy(qw/update-index --refresh/);
+ }
my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
unless ($gs) {
die "Unable to determine upstream SVN information from ",
"working tree history\n";
}
if (command(qw/diff-index HEAD --/)) {
- print STDERR "Cannot rebase with uncommited changes:\n";
- command_noisy('status');
- exit 1;
+ unless ($_dirty) {
+ print STDERR "Cannot rebase with uncommited changes:\n";
+ command_noisy('status');
+ exit 1;
+ }
}
unless ($_local) {
$_fetch_all ? $gs->fetch_all : $gs->fetch;
@@ -697,6 +702,7 @@ sub rebase_cmd {
push @cmd, '-v' if $_verbose;
push @cmd, qw/--merge/ if $_merge;
push @cmd, "--strategy=$_strategy" if $_strategy;
+ push @cmd, "--dirty" if $_dirty;
@cmd;
}
--
1.5.3.4.502.g37c97
^ permalink raw reply related
* [PATCH 2/3] Implement --dirty for git-rebase--interactive.
From: Simon Sasburg @ 2007-11-01 21:30 UTC (permalink / raw)
To: gitster; +Cc: git, Simon Sasburg
In-Reply-To: <1193952624-608-2-git-send-email-Simon.Sasburg@gmail.com>
Signed-off-by: Simon Sasburg <Simon.Sasburg@gmail.com>
---
git-rebase--interactive.sh | 42 ++++++++++++++++++++++++++++++++++++++++--
1 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 76dc679..326076b 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -25,6 +25,7 @@ REWRITTEN="$DOTEST"/rewritten
PRESERVE_MERGES=
STRATEGY=
VERBOSE=
+FIX_DIRTY=
test -d "$REWRITTEN" && PRESERVE_MERGES=t
test -f "$DOTEST"/strategy && STRATEGY="$(cat "$DOTEST"/strategy)"
test -f "$DOTEST"/verbose && VERBOSE=t
@@ -56,6 +57,35 @@ require_clean_work_tree () {
die "Working tree is dirty"
}
+store_dirty_state () {
+ echo "Storing dirty index/working tree"
+ diff=$(git diff --cached)
+ case "$diff" in
+ ?*) git commit -m "REBASE--dirty: store HEAD..index diff"
+ ;;
+ esac
+ diff=$(git diff)
+ case "$diff" in
+ ?*) git commit -a -m "REBASE--dirty: store index..workingtree diff"
+ ;;
+ esac
+}
+
+restore_dirty_state () {
+ lastmsg=$(git-rev-list HEAD^..HEAD --pretty=oneline | sed "s:[^ ]* ::")
+ if test "$lastmsg" = "REBASE--dirty: store index..workingtree diff"
+ then
+ echo "Restoring dirty index state"
+ git reset --mixed HEAD^
+ fi
+ lastmsg=$(git-rev-list HEAD^..HEAD --pretty=oneline | sed "s:[^ ]* ::")
+ if test "$lastmsg" = "REBASE--dirty: store HEAD..index diff"
+ then
+ echo "Restoring dirty working dir state"
+ git reset --soft HEAD^
+ fi
+}
+
ORIG_REFLOG_ACTION="$GIT_REFLOG_ACTION"
comment_for_reflog () {
@@ -329,6 +359,7 @@ do_next () {
test ! -f "$DOTEST"/verbose ||
git diff-tree --stat $(cat "$DOTEST"/head)..HEAD
} &&
+ restore_dirty_state &&
rm -rf "$DOTEST" &&
git gc --auto &&
warn "Successfully rebased and updated $HEADNAME."
@@ -378,6 +409,7 @@ do
;;
esac &&
output git reset --hard $HEAD &&
+ restore_dirty_state &&
rm -rf "$DOTEST"
exit
;;
@@ -417,6 +449,9 @@ do
''|-h)
usage
;;
+ --dirty)
+ FIX_DIRTY=t
+ ;;
*)
test -d "$DOTEST" &&
die "Interactive rebase already started"
@@ -435,7 +470,7 @@ do
;;
esac
- require_clean_work_tree
+ test "$FIX_DIRTY" = "t" || require_clean_work_tree
if test ! -z "$2"
then
@@ -445,9 +480,12 @@ do
die "Could not checkout $2"
fi
- HEAD=$(git rev-parse --verify HEAD) || die "No HEAD?"
UPSTREAM=$(git rev-parse --verify "$1") || die "Invalid base"
+ test "$FIX_DIRTY" = "t" && store_dirty_state
+
+ HEAD=$(git rev-parse --verify HEAD) || die "No HEAD?"
+
mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
test -z "$ONTO" && ONTO=$UPSTREAM
--
1.5.3.4.502.g37c97
^ permalink raw reply related
* [PATCH 1/3] Introduce --dirty option to git-rebase, allowing you to start from a dirty state.
From: Simon Sasburg @ 2007-11-01 21:30 UTC (permalink / raw)
To: gitster; +Cc: git, Simon Sasburg
In-Reply-To: <1193952624-608-1-git-send-email-Simon.Sasburg@gmail.com>
This will store the difference between HEAD and the index into a commit,
and the difference between the index and the working tree into a commit.
When the rebase is done, it restores the index and the working tree
by undoing these commits with git-reset.
Signed-off-by: Simon Sasburg <Simon.Sasburg@gmail.com>
---
git-rebase.sh | 63 ++++++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 224cca9..c923c3b 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -42,6 +42,7 @@ To restore the original branch and stop rebasing run \"git rebase --abort\".
unset newbase
strategy=recursive
do_merge=
+fix_dirty=
dotest=$GIT_DIR/.dotest-merge
prec=4
verbose=
@@ -117,9 +118,39 @@ call_merge () {
finish_rb_merge () {
rm -r "$dotest"
+ restore_dirty_state
echo "All done."
}
+store_dirty_state () {
+ echo "Storing dirty index/working tree"
+ diff=$(git diff --cached)
+ case "$diff" in
+ ?*) git commit -m "REBASE--dirty: store HEAD..index diff"
+ ;;
+ esac
+ diff=$(git diff)
+ case "$diff" in
+ ?*) git commit -a -m "REBASE--dirty: store index..workingtree diff"
+ ;;
+ esac
+}
+
+restore_dirty_state () {
+ lastmsg=$(git-rev-list HEAD^..HEAD --pretty=oneline | sed "s:[^ ]* ::")
+ if test "$lastmsg" = "REBASE--dirty: store index..workingtree diff"
+ then
+ echo "Restoring dirty index state"
+ git reset --mixed HEAD^
+ fi
+ lastmsg=$(git-rev-list HEAD^..HEAD --pretty=oneline | sed "s:[^ ]* ::")
+ if test "$lastmsg" = "REBASE--dirty: store HEAD..index diff"
+ then
+ echo "Restoring dirty working dir state"
+ git reset --soft HEAD^
+ fi
+}
+
is_interactive () {
test -f "$dotest"/interactive ||
while :; do case $#,"$1" in 0,|*,-i|*,--interactive) break ;; esac
@@ -156,6 +187,10 @@ do
git am --resolved --3way --resolvemsg="$RESOLVEMSG"
exit
;;
+ --dirty)
+ do_merge=t
+ fix_dirty=t
+ ;;
--skip)
if test -d "$dotest"
then
@@ -188,6 +223,7 @@ do
die "No rebase in progress?"
fi
git reset --hard ORIG_HEAD
+ restore_dirty_state
exit
;;
--onto)
@@ -253,15 +289,19 @@ else
fi
fi
-# The tree must be really really clean.
-git update-index --refresh || exit
-diff=$(git diff-index --cached --name-status -r HEAD)
-case "$diff" in
-?*) echo "cannot rebase: your index is not up-to-date"
- echo "$diff"
- exit 1
- ;;
-esac
+# The tree must be really really clean, unless --dirty is given.
+if test "$fix_dirty" = ""
+then
+ git update-index --refresh || exit
+ diff=$(git diff-index --cached --name-status -r HEAD)
+ case "$diff" in
+ ?*) echo "cannot rebase: your index is not up-to-date"
+ echo "$diff"
+ exit 1
+ ;;
+ esac
+
+fi
# The upstream head must be given. Make sure it is valid.
upstream_name="$1"
@@ -318,6 +358,11 @@ then
GIT_PAGER='' git diff --stat --summary "$mb" "$onto"
fi
+if test "$fix_dirty" = "t"
+then
+ store_dirty_state
+fi
+
# Rewind the head to "$onto"; this saves our current head in ORIG_HEAD.
echo "First, rewinding head to replay your work on top of it..."
git-reset --hard "$onto"
--
1.5.3.4.502.g37c97
^ permalink raw reply related
* [RFC PATCH 0/3] Starting rebase from dirty tree
From: Simon Sasburg @ 2007-11-01 21:30 UTC (permalink / raw)
To: gitster; +Cc: git
These patches allow a --dirty option for git-rebase, git-rebase--interactive, and git-svn rebase.
When --dirty is given, starting from a dirty tree state will be allowed.
The difference between HEAD and the index and between the index and the working tree will be committed,
these commits will be undone when the rebase is completed.
For me the most often used use case is git-svn rebase one, which i use often.
This prevents me form having to commit+reset or stash+unstash everytime i want
to do this in a dirty tree.
I recently saw some discussion about a stash-based patch to do the same thing, and decided to share this.
These patches are a bit rough in some places, and mostly meant to see what others think if this way of doing this.
One advantage above using stash is that merge conflicts will be presented to the user in the same way as when doing a normal rebase.
Also having to explicitly ask for this behaviour with --dirty will hopefully give the user some clue that this isn't a standard operation.
But, in the rebase--interactive case, it allows the user to shoot himself in the foot by re-ordering the commits such that the temporary ones aren't at the end anymore.
Well, comments are welcome :-)
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Melchior FRANZ @ 2007-11-01 21:26 UTC (permalink / raw)
To: git
In-Reply-To: <20071101211848.GG2387@thunk.org>
* Theodore Tso -- Thursday 01 November 2007:
> Looks like it came from Cogito's cg-clean. No one else has it as far
> as I know, [...]
Not built-in. But there are cvs-clean and svn-clean scripts
floating around (and part of KDE), which can be quite useful.
The svn-clean script prompts the user with the number of files
it is about to delete, and asks for confirmation.
m.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-01 21:20 UTC (permalink / raw)
To: Mike Hommey; +Cc: Geert Bosch, Linus Torvalds, git
In-Reply-To: <20071101204755.GA15842@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> On Thu, Nov 01, 2007 at 01:27:55PM -0700, Junio C Hamano wrote:
> ...
>> I do not know where "git clean" came from. I am suspecting that
>> it was to give counterparts to some other SCMs, but do not know
>> which ones. Some people wanted to have it --- so you need to
>> convince them that it is a bad idea first. Adding an equivalent
>> options to "git rm" alone does not solve that issue.
>
> Well, they could add an alias, then ;)
Why do people talk about forcing different behaviour on existing
users before proving that the new behaviour is good for
everybody, including existing ones?
I am personally very much in favor of removing "git clean", but
having many people on the list saying loudly that it is a bad
command is not good enough justification, as people who are
content with the status quo tend to be silent.
The steps I think is sensible to transition to that goal would
be:
- Change clean.requireForce to default to 'true' in the next
(or one after) version of git, to make 'clean' even safer.
See if anybody complains (I do not expect any).
- Implement the same functionarity as a new option to "git rm",
which is already in C.
- Do "git clean" in C, but sharing the code with "git rm"
implementation above.
- Discuss deprecation and removal of redundant commands. Ship
a version of git with deprecation and future removal notice.
Outline how to achieve the same thing as the deprecated
command used to do (or give convincing argument why what the
deprecated command used to do was a bad thing and do not
offer an alternative).
- Wait for a while (6 months to 1 year) and then remove them.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Theodore Tso @ 2007-11-01 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Geert Bosch, Linus Torvalds, git
In-Reply-To: <7v4pg5btis.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 01, 2007 at 01:27:55PM -0700, Junio C Hamano wrote:
> I think what you are trying to do is to deprecate or remove "git
> clean".
>
> I do not know where "git clean" came from. I am suspecting that
> it was to give counterparts to some other SCMs, but do not know
> which ones. Some people wanted to have it --- so you need to
> convince them that it is a bad idea first. Adding an equivalent
> options to "git rm" alone does not solve that issue.
There's this great SCM tool called git that we can use to investigate
the history of changes.... :-)
Looks like it came from Cogito's cg-clean. No one else has it as far
as I know, and I agree with others that it's a really not such a great
idea. Fortunately most of the damage can be mitigated with "git
config --global clean.requireForce true", but the newbies won't know
to do that.
- Ted
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Geert Bosch @ 2007-11-01 21:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v4pg5btis.fsf@gitster.siamese.dyndns.org>
On Nov 1, 2007, at 16:27, Junio C Hamano wrote:
> Geert Bosch <bosch@adacore.com> writes:
>> I often type "make clean" as well many "git xyz" commands
>> during development, and so it happens that at times, I type
>> "git clean" by accident.
>
> Happened to me once. I hate that command.
>
>> So, I propose *not* converting git clean to a C builtin,
>> but instead adding --untracked and --ignored options to
>> git-rm.
>
> I think what you are trying to do is to deprecate or remove "git
> clean".
Yes, and in the meantime I'd like to discourage people
from spending time and effort to upgrade it to first
class built-in status.
-Geert
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Junio C Hamano @ 2007-11-01 21:06 UTC (permalink / raw)
To: Mike Hommey; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20071101105318.GA4744@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> On Wed, Oct 31, 2007 at 06:15:27PM -0700, Junio C Hamano wrote:
>> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>>
>> > BTW, you have workaround for git-merge also? It uses cpio to save/restore state.
>>
>> Why do people want "workaround"? Is installing cpio such a
>> hassle?
>
> Note that to do what git-merge does with cpio, i wonder if it wouldn't
> be sensible to use git stash, now.
Like this? That's an excellent suggestion.
The patch uses the 'git stash create' which is in 'next'
(jc/stash-create topic).
Having said that, the savestate()/restorestate() codepaths are
only relevant to the "try multiple strategies and pick the best
one" feature of git-merge, and that is where cpio is used (and
the patch rewrites it to use stash). I am not sure if anybody
ever used it in practice. I admit I am guilty of inventing it,
but I certainly do not.
It might make sense to remove that try-multiple-strategies
feature from git-merge and be done with it. It would certainly
make the eventual rewrite to C much easier.
---
git-merge.sh | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index 3a01db0..e8916cc 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -28,20 +28,19 @@ allow_trivial_merge=t
dropsave() {
rm -f -- "$GIT_DIR/MERGE_HEAD" "$GIT_DIR/MERGE_MSG" \
- "$GIT_DIR/MERGE_SAVE" || exit 1
+ "$GIT_DIR/MERGE_STASH" || exit 1
}
savestate() {
# Stash away any local modifications.
- git diff-index -z --name-only $head |
- cpio -0 -o >"$GIT_DIR/MERGE_SAVE"
+ git stash create >"$GIT_DIR/MERGE_STASH"
}
restorestate() {
- if test -f "$GIT_DIR/MERGE_SAVE"
+ if test -f "$GIT_DIR/MERGE_STASH"
then
git reset --hard $head >/dev/null
- cpio -iuv <"$GIT_DIR/MERGE_SAVE"
+ git stash apply --index $(cat "$GIT_DIR/MERGE_STASH")
git update-index --refresh >/dev/null
fi
}
@@ -386,7 +385,7 @@ case "$use_strategies" in
single_strategy=no
;;
*)
- rm -f "$GIT_DIR/MERGE_SAVE"
+ rm -f "$GIT_DIR/MERGE_STASH"
single_strategy=yes
;;
esac
^ permalink raw reply related
* [PATCH] Make git-mailinfo strip whitespace from the start of the mail file.
From: Simon Sasburg @ 2007-11-01 21:05 UTC (permalink / raw)
To: git; +Cc: gitster, Simon Sasburg
This allows you to use files gotten through gmail's web interface via its 'Show original' option.
Signed-off-by: Simon Sasburg <Simon.Sasburg@gmail.com>
---
Note that this doesn't exactly follow RFC 2822 as far as i can see, but i don't know if git prefers to be strict or tolerant in these cases, so i'm sending the patch anyway.
It certaily helps me, even if just a little bit.
builtin-mailinfo.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index fb12248..5d4b6bf 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -915,6 +915,7 @@ static void handle_info(void)
static int mailinfo(FILE *in, FILE *out, int ks, const char *encoding,
const char *msg, const char *patch)
{
+ int peek;
keep_subject = ks;
metainfo_charset = encoding;
fin = in;
@@ -935,6 +936,11 @@ static int mailinfo(FILE *in, FILE *out, int ks, const char *encoding,
p_hdr_data = xcalloc(MAX_HDR_PARSED, sizeof(char *));
s_hdr_data = xcalloc(MAX_HDR_PARSED, sizeof(char *));
+ do {
+ peek = fgetc(in);
+ } while (peek == ' ' || peek == '\r' || peek == '\n');
+ ungetc(peek, in);
+
/* process the email header */
while (read_one_header_line(line, sizeof(line), fin))
check_header(line, sizeof(line), p_hdr_data, 1);
--
1.5.3.4.502.g37c97
^ permalink raw reply related
* [PATCH 2/3] make sure throughput display gets updated even if progress doesn't move
From: Nicolas Pitre @ 2007-11-01 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1193950797-29631-2-git-send-email-nico@cam.org>
Currently the progress/throughput display update happens only through
display_progress(). If the progress based on object count remains
unchanged because a large object is being received, the latest throughput
won't be displayed. The display update should occur through
display_throughput() as well.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
progress.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/progress.c b/progress.c
index 34a5961..39d5d2c 100644
--- a/progress.c
+++ b/progress.c
@@ -160,6 +160,9 @@ void display_throughput(struct progress *progress, unsigned long n)
tp->last_misecs[tp->idx] = misecs;
tp->idx = (tp->idx + 1) % TP_IDX_MAX;
tp->count = 0;
+
+ if (progress->last_value != -1 && progress_update)
+ display(progress, progress->last_value, 0);
}
}
--
1.5.3.4.279.gb2d9d-dirty
^ permalink raw reply related
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