* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Junio C Hamano @ 2008-07-19 22:18 UTC (permalink / raw)
To: Olivier Marin
Cc: Theodore Tso, Nanako Shiraishi, Johannes Schindelin,
René Scharfe, Stephan Beyer, Joe Fiorini, git, Jari Aalto
In-Reply-To: <4882350B.6020003@free.fr>
Olivier Marin <dkr+ml.git@free.fr> writes:
> Subject: [PATCH] git am --abort
>
> To squash.
>
> Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Thanks.
> @@ -203,9 +204,10 @@ then
>
> case "$abort" in
> t)
> - rm -fr "$dotest" &&
> + git rerere clear &&
> git read-tree -m -u ORIG_HEAD &&
> - git reset ORIG_HEAD && :
> + git reset ORIG_HEAD &&
> + rm -fr "$dotest"
> exit ;;
> esac
> else
Clearing the rerere information needs to be done, but I think we should
drop the last && to make sure we remove "$dotest" and exit with its exit
status.
I'm happy with the documentation and help-text parts of your patch, but
probably this, on top of 1a6f6bb (git am --abort, 2008-07-16), is more
appropriate?
---
git-am.sh | 6 +++---
t/t4151-am-abort.sh | 46 +++++++++++++++++++++++++++-------------------
2 files changed, 30 insertions(+), 22 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index a44bd7a..5cbf8f4 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -203,9 +203,9 @@ then
case "$abort" in
t)
- rm -fr "$dotest" &&
- git read-tree -m -u ORIG_HEAD &&
- git reset ORIG_HEAD && :
+ git rerere clear
+ git read-tree --reset -u HEAD ORIG_HEAD
+ rm -fr "$dotest"
exit ;;
esac
else
diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh
index 96b2cd5..dda7e2c 100755
--- a/t/t4151-am-abort.sh
+++ b/t/t4151-am-abort.sh
@@ -22,27 +22,35 @@ test_expect_success setup '
done &&
git format-patch initial &&
git checkout -b side initial &&
- echo local change >file-2 &&
- cp file-2 file-2-expect
+ echo local change >file-2-expect
'
-test_expect_success 'am stops at a patch that does not apply' '
- test_must_fail git am 000[124]-*.patch &&
- git log --pretty=tformat:%s >actual &&
- for i in 3 2 initial
- do
- echo $i
- done >expect &&
- test_cmp expect actual
-'
+for with3 in '' ' -3'
+do
+ test_expect_success "am$with3 stops at a patch that does not apply" '
-test_expect_success 'am --abort goes back' '
- git am --abort &&
- git rev-parse HEAD >actual &&
- git rev-parse initial >expect &&
- test_cmp expect actual &&
- test_cmp file-2-expect file-2 &&
- git diff-index --exit-code --cached HEAD
-'
+ git reset --hard initial &&
+ cp file-2-expect file-2 &&
+
+ test_must_fail git am$with3 000[124]-*.patch &&
+ git log --pretty=tformat:%s >actual &&
+ for i in 3 2 initial
+ do
+ echo $i
+ done >expect &&
+ test_cmp expect actual
+ '
+
+ test_expect_success "am --abort goes back after failed am$with3" '
+ git-am --abort &&
+ git rev-parse HEAD >actual &&
+ git rev-parse initial >expect &&
+ test_cmp expect actual &&
+ test_cmp file-2-expect file-2 &&
+ git diff-index --exit-code --cached HEAD &&
+ test ! -f .git/rr-cache/MERGE_RR
+ '
+
+done
test_done
^ permalink raw reply related
* Re: "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Junio C Hamano @ 2008-07-19 22:00 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: git
In-Reply-To: <20080719195909.GA5093@2ka.mipt.ru>
Evgeniy Polyakov <johnpol@2ka.mipt.ru> writes:
> I posted it so it would be stored in archive, that old enough git
> version does not work with recent trees, so one should upgrade if this
> error occures.
Thanks, but you are about 5 days too late ;-)
http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=88402
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Junio C Hamano @ 2008-07-19 21:52 UTC (permalink / raw)
To: Olivier Marin
Cc: Theodore Tso, Nanako Shiraishi, Johannes Schindelin,
René Scharfe, Stephan Beyer, Joe Fiorini, git, Jari Aalto
In-Reply-To: <4882454D.2080500@free.fr>
Olivier Marin <dkr+ml.git@free.fr> writes:
> It tries to apply patches even on a dirty tree which makes difficult
> to automatically do a "git reset --hard" with --skip or --abort and
> forces the user to clean the index by hand if last patch failed with
> unmerged files.
>
> So, do some people still use "git am" with a dirty tree or will a
> patch that make it work like "git rebase" be accepted?
Anything that changes "am" to require a clean working tree will NEVER be
accepted. I personally rely on the ability for it to run in a dirty tree,
so does Linus.
Side note. Anything that changes "merge" to require a clean
working tree is also unacceptable. Cf.
http://thread.gmane.org/gmane.comp.version-control.git/9073/focus=9089
Linus talks about "patch" in the paragraph second to the last one
in the message; back then he was talking about "git-applymbox" but
the same argument there applies to its newer incarnation "git-am".
Side note #2. It would have been nice if "rebase" were also
written in such a way that it can work in a dirty tree as long as
local changes did not interfere with the operation, but it is a
lot more involved.
When I looked at the "am --abort" patch briefly, I had an impression (by
reading its test case) that it correctly refrained from doing the
destructive "reset --hard".
^ permalink raw reply
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Petr Baudis @ 2008-07-19 21:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Lea Wiemann, git, John Hawley
In-Reply-To: <200807192254.24622.jnareb@gmail.com>
On Sat, Jul 19, 2008 at 10:54:24PM +0200, Jakub Narebski wrote:
> On Fri, 18 July 2008, Petr Baudis wrote:
>
> > But the experience shows that the pipe interface is actually
> > the _most_ used part of the Git Perl API.
Note that I referred both to scripts that are part of Git and
(actually more) to various third-party scripts I wrote externally.
> Here is some statistics on the usage of Git Perl API among built-in
> and contrib commands.
Thanks!
> The situation is worse for scripts in 'contrib/'. From those, only
> contrib/examples/git-remote.perl uses Git.pm; neither blameview,
> continuous, git-import and import-tars in fast-import, setgitperms
> and update-paranoid in hooks, stats, nor other Perl scripts in
> examples (git-rerere, git-svnimport) include "use Git".
I have actually once converted blameview to use Git locally, but in
the end never got around to submit it; I wonder if I have the source
still around somewhere. Not so important, I guess.
> Below there are stats on how different commands from Git.pm are
> used in mentioned Perl scripts:
>
> 2. git-cvsexportcommit.perl uses (besides ->repository() constructor)
> only once ->config; so I guess that current interface wrapping
> git-config should stay, because parsing whole config for such
> situation would be overkill.
I don't understand. Parsing whole config happen will either happen in
git-config or in Git::Config, and the performance difference is so tiny
that it is not really worth the API complexity, I believe.
> 3. git-send-email.perl uses 5 config, 2 config_bool, 2 ident_person
> (for author and for committer), 1 version, and of course once
> ->repository() constructor.
>
> Here we can see how to work around current API to: it uses
> Git::config(@repo, "sendemail.identity") form, where
> my $repo = eval { Git->repository() };
> my @repo = $repo ? ($repo) : ();
> to make it work both with git repository (using repo config), and
> outside/without git repository, using only user and system git
> config.
With the envisioned model, it could use $git which would be either
a reference to a Git::Standalone singleton or Git::Repo instance.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Jakub Narebski @ 2008-07-19 20:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: Lea Wiemann, git, John Hawley
In-Reply-To: <20080718164828.GT10151@machine.or.cz>
On Fri, 18 July 2008, Petr Baudis wrote:
> But the experience shows that the pipe interface is actually
> the _most_ used part of the Git Perl API.
This made me curious which parts of Git.pm, the current Git Perl API,
are used most.
Here is some statistics on the usage of Git Perl API among built-in
and contrib commands.
>From git commands in Perl the following include "use Git" in their
sources: git-cvsexportcommit, git-send-email, git-svn, and helper
script git-add--interactive. There are Perl scripts which do not
use Git.pm: git-archimport (which I think should be obsoleted or
moved to contrib), git-cvsimport, git-cvsserver, git-relink. This
means that half of Perl scripts use Git Perl API.
The situation is worse for scripts in 'contrib/'. From those, only
contrib/examples/git-remote.perl uses Git.pm; neither blameview,
continuous, git-import and import-tars in fast-import, setgitperms
and update-paranoid in hooks, stats, nor other Perl scripts in
examples (git-rerere, git-svnimport) include "use Git".
Below there are stats on how different commands from Git.pm are
used in mentioned Perl scripts:
1. git-add--interactive.perl uses Git.pm mainly to access color
configuration: 2 ->get_colorbool, 8 ->get_color, 1 ->config.
It also uses once ->repository() constuctor, and once
->repo_path().
This means that future Git::Config _has_ to have support for
color or colorbool valued configuration values.
2. git-cvsexportcommit.perl uses (besides ->repository() constructor)
only once ->config; so I guess that current interface wrapping
git-config should stay, because parsing whole config for such
situation would be overkill.
What is strange that git-cvsexportcommit.perl defines its own
safe_pipe_capture and xargs_safe_pipe_capture (!), and uses
them, open pipeline, backticks, and system() to call git commands.
3. git-send-email.perl uses 5 config, 2 config_bool, 2 ident_person
(for author and for committer), 1 version, and of course once
->repository() constructor.
Here we can see how to work around current API to: it uses
Git::config(@repo, "sendemail.identity") form, where
my $repo = eval { Git->repository() };
my @repo = $repo ? ($repo) : ();
to make it work both with git repository (using repo config), and
outside/without git repository, using only user and system git
config.
4. git-svn.perl (which is if I checked correctly third largest scripted
git command, after gitk-gui/gitk-wish and gitweb/gitweb.perl) uses:
3 x repository
28 x command_oneline
19 x command_noisy
18 x command
14 x command_output_pipe
1 x command_input_pipe
1 x git_try_cmd (and many "eval { command()/command_oneline() }")
2 x cat_blob
1 x hash_and_insert_object
1 x get_colorbool
(The above are all if I have not made mistake when counting commands)
Side note: git-svn is command which would get most out of
Git::Config, as it currently uses combination of "git config -l"
and "git config --get" (I guess that the code in question predates
machine-parseable "git config -l -z").
Note that all those statictics doesn't count how many times some
Git.pm method was called, only how many times it occurs in the code.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Olivier Marin @ 2008-07-19 20:25 UTC (permalink / raw)
To: Stephan Beyer
Cc: Junio C Hamano, Theodore Tso, Nanako Shiraishi,
Johannes Schindelin, René Scharfe, Joe Fiorini, git,
Jari Aalto
In-Reply-To: <20080719195944.GB5792@leksak.fem-net>
Stephan Beyer a écrit :
>
> If you mean with "work like I want" that it complains about an unclean
> work tree: the check is explicitly done by git-sequencer.
Yes, I mean: refuse to work if the tree is not clean _and_ --skip
and --abort clean the index/tree for me.
With current git version "git am --skip" refuse to continue with a
message: "Dirty index: cannot apply patches (dirty: ...)", if some
files stay unmerged.
As a user I find --skip and --abort useless^Wpainful to use in this
situation.
> I guess there are situations where you want to apply a patch on a dirty
> work tree, e.g. if you fixed some tiny issues so that patches can
> apply cleanly.
Maybe.
Olivier.
^ permalink raw reply
* Re: "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Evgeniy Polyakov @ 2008-07-19 20:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080719182014.GD32184@machine.or.cz>
Hi Petr.
On Sat, Jul 19, 2008 at 08:20:14PM +0200, Petr Baudis (pasky@suse.cz) wrote:
> On Sat, Jul 19, 2008 at 09:47:43PM +0400, Evgeniy Polyakov wrote:
> > $ git --version
> > git version 1.4.4.4
> >
> > Fresh 32bit Debian testing.
>
> Are you sure? http://packages.debian.org/testing/git-core says
>
> Package: git-core (1:1.5.6.2-1)
>
> Your sounds more like the Debian stable version.
It is that version indeed:
apt-cache show git-core
...
Version: 1:1.5.6.2-1
...
but it was imported there quite recently, so 'apt-get upgrade' will not
catch up with major version change. 1.5 works ok, I pointed to this
issue, so that resolution for the problem (i.e. upgrade to the more
recent version) could be found in archive.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Stephan Beyer @ 2008-07-19 19:59 UTC (permalink / raw)
To: Olivier Marin
Cc: Junio C Hamano, Theodore Tso, Nanako Shiraishi,
Johannes Schindelin, René Scharfe, Joe Fiorini, git,
Jari Aalto
In-Reply-To: <4882454D.2080500@free.fr>
Hi,
Olivier Marin wrote:
> Note: the version that use "git sequencer" seems to work like I want
> but I do not know if it is a side effect or not.
If you mean with "work like I want" that it complains about an unclean
work tree: the check is explicitly done by git-sequencer.
I guess there are situations where you want to apply a patch on a dirty
work tree, e.g. if you fixed some tiny issues so that patches can
apply cleanly.
But I think it does not hurt to commit such tiny changes and perhaps
squash later.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Evgeniy Polyakov @ 2008-07-19 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wvx211n.fsf@gitster.siamese.dyndns.org>
Hi Junio.
On Sat, Jul 19, 2008 at 11:15:16AM -0700, Junio C Hamano (gitster@pobox.com) wrote:
> > The repository you are cloning uses pack idx version #2; 1.4.4.4 predates it
> > by a wide margin.
>
> By the way, Debian folks are very aware of the issue and already has a
> backported material to cut a 1.4.4.5, but I do not know what the release
> schedule for their update is.
>
> Is it an option for you to update to a more modern version from say
> backports.org? Everybody using git for anything serious should be using
> 1.5.3 or newer these days.
It is very development test machine, there is no need to use git at all,
it is just a convenient way to get a needed version via 'git clone; git reset'.
I posted it so it would be stored in archive, that old enough git
version does not work with recent trees, so one should upgrade if this
error occures.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Olivier Marin @ 2008-07-19 19:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Nanako Shiraishi, Johannes Schindelin,
René Scharfe, Stephan Beyer, Joe Fiorini, git, Jari Aalto
In-Reply-To: <7viqv5r637.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
> Theodore Tso <tytso@mit.edu> writes:
>
>> While you have "git am" open, how about adding an "git am --abort"
>> which nukes the .dotest aka .git/rebase directory, and resets HEAD
>> back to the original position?
>
> This does not seem to have reached the list nor its archives. I cannot
> say I have really looked at it deeply but it may be a good starting
> point. It needs docs ;-)
Thinking about the way "git am" works:
It tries to apply patches even on a dirty tree which makes difficult
to automatically do a "git reset --hard" with --skip or --abort and
forces the user to clean the index by hand if last patch failed with
unmerged files.
So, do some people still use "git am" with a dirty tree or will a
patch that make it work like "git rebase" be accepted?
I think users can use "git stash" and "git stash pop" today. Did I
miss something?
Note: the version that use "git sequencer" seems to work like I want
but I do not know if it is a side effect or not.
Olivier.
^ permalink raw reply
* Re: [PATCH] Windows: set gitexecdir = $(bindir)
From: Johannes Sixt @ 2008-07-19 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Steffen Prohaska, Johannes Schindelin
In-Reply-To: <7vmykd238a.fsf@gitster.siamese.dyndns.org>
On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
> > Take as an example 'git pull'.
> >
> > - The first call to git will derive the exec-path
> > $prefix/bin/../libexec/git-core and prepend it to $PATH.
> >
> > - Calls to builtin git commands from inside 'git pull' will then derive
> > the exec-path $prefix/bin/../libexec/git-core/../libexec/git-core, that
> > is $prefix/libexec/libexec/git-core, and prepend it to $PATH as well.
> > That directory does not exist - usually - and it does not hurt. But it
> > feels dirty and potentially dangerous.
>
> You run "git" with an argument "pull". It needs to figure out where
> "git-pull" is, it checks where it came from and adds ../libexec/git-core/.
> Then it runs "git-pull" script.
>
> Then the script may have a call to "git ls-files -u" or "git-merge".
>
> - The former case, "git" again needs to find out where "git-ls-files"
> is.
>
> If "git" is found as bin/git and not as libexec/git-core/git, this
> should be perfectly fine, isn't it? Perhaps we install a duplicate
> copy there by mistake, which is what we need to fix?
Yes, there's libexec/git-core/git. There reason might be that the install
target is simpler to write (to create the hardlinks) just in case $(bindir)
and $(gitexecdir) are not on the same mount.
> - The latter case (our scripts source git-sh-setup so they have libexec
> one in the PATH when they are started) would find "git-merge" directly
> and runs it.
>
> In either case, the programs "git-ls-files" and "git-merge" do not need to
> do the same discovery -- are we giving them enough clues when we run them
> to let them avoid that?
Probably the only clue is the name itself, like Steffen proposed.
I'll see how I can improve my earlier exec-path patch series.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/3] add new Git::Repo API
From: Jakub Narebski @ 2008-07-19 19:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: Lea Wiemann, git, John Hawley
In-Reply-To: <20080718165407.GU10151@machine.or.cz>
On Fri, 18 July 2008, Petr Baudis wrote:
> On Tue, Jul 15, 2008 at 01:41:38AM +0200, Jakub Narebski wrote:
> > On Mon, 14 July 2008, Petr Baudis wrote:
> > > Here is an idea: Introduce Git::Command object that will have very
> > > general interface and look like
> > >
> > > my $c = Git::Command->new(['git', '--git-dir=.', 'cat-file', \
> > > '-p', 'bla'], {pipe_out=>1})
> > > ...
> > > $c->close();
> >
> > Errr... how do you read from such a pipe? <$c> I think wouldn't work,
> > unless you would use some trickery...
>
> That's good point; it might either be done using some trickery, or
> $c->pipe. The idea behind having a special object for it though is to
> have *unified* (no matter how simple) error handling. You might not
> detect the command erroring out at the open time.
>
> Is there a better approach for solving this?
I don't know if it is _better_ approach, but the _alternate_ approach
would be to use:
my $c = Git::Command->new(['git', '--git-dir=.', 'cat-file', \
'-p', 'bla'], {out=>my $fh, err=>undef})
...
while (my $line = <$fh>) {
...
$c->close();
And trickery would be to use blessed filehandle, or what? Or perhaps
extending IO::Handle (but not all like using object methods for I/O
handles)?
> > > and a Git::CommandFactory with a nicer interface that would look like
> > >
> > > my $cf = Git::CommandFactory->new('git', '--git-dir=.');
> > > my $c = $cf->output_pipe('cat-file', '-p', 'bla');
> > > $c->close();
> > >
> > > Then, Git::Repo would have a single Git::CommandFactory instance
> > > pre-initialized with the required calling convention, and returned by
> > > e.g. cmd() method. Then, from the user POV, you would just:
> > >
> > > my $repo = Git::Repo->new;
> > > $repo->cmd->output_pipe('cat-file', '-p', 'bla');
> > >
> > > Or am I overdoing it?
> >
> > You are probably overdoing it.
> >
> > I think it would be good to have the following interface
> >
> > Git->output_pipe('ls-remotes', $URL, '--heads');
>
> This is problematic; I think mixing the new and old interface within a
> single class is very bad idea, we should have Git::Standalone or
> something for this. Or, just, default Git::CommandFactory. ;-)
I forgot that we cannot obsolete / replace old interface. Nevertheless
it would be nice to be able to use for example
Git::Cmd->output_pipe('ls-remotes', $URL, '--heads');
but also
output_pipe('myscript.sh', <arg1>, <arg2>);
See also below for alternative interfaces to Git::Cmd->output_pipe();
> > [...]
> > $r = Git::Repo->new(<git_dir>);
> > $r->output_pipe('ls_tree', 'HEAD');
> > [...]
> > $nb = Git::Repo::NonBare->new(<git_dir>[, <working_area>]);
> > $nb->output_pipe('ls-files');
> >
> >
> > How can it be done with minimal effort, unfortunately I don't know...
>
> Well, this interface is almost identical to what I delineated, except
> that I have the extra ->cmd-> step there. But maybe, we could go with
> your API and instead have Git::CommandFactory as a base of Git::Repo?
> The hierarchy would be
>
> Git::CommandFactory - provides the cmd_pipe toolkit
> |
> Git::Repo - provides repository model
> |
> Git::Repo::NonBare - additional working-copy-related methods
>
> I think I will post a sample implementation sometime over the weekend.
Thanks.
I think this is a very good idea. Although... you mix somewhat here
relationships. Relationship between Git::CommandFactory (Git::Cmd?)
is a bit different than relationship between Git::Repo and
Git::Repo::NonBare. Git::Repo::NonBare is a case of Git::Repo which
additionally knows where its working copy (Git::WC?) is, and where
inside working copy we are (if we are inside working copy). Git::Repo
uses Git::CommandFactory to route calls to git commands, and to
provide default '--git-dir=<repo_path>' argument.
What I'd like to have is a way to easily set in _one_ place where git
binary can be found, even if we are using different repositories, call
git commands not related to git repository.
Should we use
Git::Cmd->output_pipe('ls-remotes', $URL, '--heads');
or
output_pipe(GIT, 'ls-remotes', $URL, '--heads');
or
output_pipe($GIT, 'ls-remotes', $URL, '--heads');
or
output_pipe($Git::GIT, 'ls-remotes', $URL, '--heads');
we would want to be able to set where git binary is once (and for all),
for example via
Git::Cmd->set_git('/usr/local/bin/git');
or something like that.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Fredrik Tolf @ 2008-07-19 18:18 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1216490252.10694.58.camel@koto.keithp.com>
On Sat, 2008-07-19 at 10:57 -0700, Keith Packard wrote:
> On Sat, 2008-07-19 at 19:06 +0200, Fredrik Tolf wrote:
> > By removing the DISPLAY env variable before forking, SSH
> > can thus be forced into non-interactive mode, without any obvious
> > ill effects.
>
> This will keep ssh-askpass from using any X-based password input
> program.
Ah, right. Would it be OK to add the `-x' flag to ssh instead? I imagine
that that might make git less portable to SSH implementations other than
OpenSSH, but I don't know if that is considered a problem.
Fredrik Tolf
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Olivier Marin @ 2008-07-19 18:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Nanako Shiraishi, Johannes Schindelin,
René Scharfe, Stephan Beyer, Joe Fiorini, git, Jari Aalto
In-Reply-To: <7viqv5r637.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
> Theodore Tso <tytso@mit.edu> writes:
>
>> While you have "git am" open, how about adding an "git am --abort"
>> which nukes the .dotest aka .git/rebase directory, and resets HEAD
>> back to the original position?
>
> This does not seem to have reached the list nor its archives. I cannot
> say I have really looked at it deeply but it may be a good starting
> point. It needs docs ;-)
This can be squashed to Nanako's path: it adds missing docs,
'git rerere clear' and move $dotest deletion at the end in case
'git read-tree' failed (because of a dirty index).
Olivier.
-- >8 --
Subject: [PATCH] git am --abort
To squash.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
Documentation/git-am.txt | 5 ++++-
git-am.sh | 8 +++++---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 2d7f162..e010a16 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--3way] [--interactive] [--binary]
[--whitespace=<option>] [-C<n>] [-p<n>]
[<mbox> | <Maildir>...]
-'git am' (--skip | --resolved)
+'git am' (--skip | --resolved | --abort)
DESCRIPTION
-----------
@@ -99,6 +99,9 @@ default. You could use `--no-utf8` to override this.
or `--skip` to handle the failure. This is solely
for internal use between 'git-rebase' and 'git-am'.
+--abort::
+ Restore the original branch and abort the patching operation.
+
DISCUSSION
----------
diff --git a/git-am.sh b/git-am.sh
index 5e645e4..04b2e96 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -22,7 +22,7 @@ p= pass it through git-apply
resolvemsg= override error message when patch failure occurs
r,resolved to be used after a patch failure
skip skip the current patch
-abort abandon patch application and clear .dotest directory
+abort restore the original branch and abort the patching operation.
rebasing (internal use for git-rebase)"
. git-sh-setup
@@ -55,6 +55,7 @@ stop_here_user_resolve () {
fi
echo "When you have resolved this problem run \"$cmdline --resolved\"."
echo "If you would prefer to skip this patch, instead run \"$cmdline --skip\"."
+ echo "To restore the original branch and stop patching run \"$cmdline --abort\"."
stop_here $1
}
@@ -203,9 +204,10 @@ then
case "$abort" in
t)
- rm -fr "$dotest" &&
+ git rerere clear &&
git read-tree -m -u ORIG_HEAD &&
- git reset ORIG_HEAD && :
+ git reset ORIG_HEAD &&
+ rm -fr "$dotest"
exit ;;
esac
else
--
1.5.6.3.441.g3087
^ permalink raw reply related
* Re: "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Petr Baudis @ 2008-07-19 18:20 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: git
In-Reply-To: <20080719174742.GA4253@2ka.mipt.ru>
On Sat, Jul 19, 2008 at 09:47:43PM +0400, Evgeniy Polyakov wrote:
> $ git --version
> git version 1.4.4.4
>
> Fresh 32bit Debian testing.
Are you sure? http://packages.debian.org/testing/git-core says
Package: git-core (1:1.5.6.2-1)
Your sounds more like the Debian stable version.
Petr "Pasky" Baudis
^ permalink raw reply
* [PATCH] Documentation/git-merge.txt: Partial rewrite of How Merge Works
From: Petr Baudis @ 2008-07-19 18:17 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7vprpa67e4.fsf@gitster.siamese.dyndns.org>
The git-merge documentation's "HOW MERGE WORKS" section is confusingly
composed and actually omits the most interesting part, the merging of
the arguments into HEAD itself, surprisingly not actually mentioning
the fast-forward merge anywhere.
This patch replaces the "[NOTE]" screenful of highly technical details
by a single sentence summing up the interesting information, and instead
explains how are the arguments compared with HEAD and the three possible
inclusion states that are named "Already up-to-date", "Fast-forward"
and "True merge". It also makes it clear that the rest of the section
talks only about the true merge situation, and slightly expands the
talk on solving conflicts.
Junio initiated the removal of the Note screenful altogether and
offered many stylistical fixes.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
> But what I was wondering was if we have given the users enough clues to
> tell if the above is the right action. If merge started and conflicted,
> then forgetting about it and keep going is _not_ the right thing, and the
> user needs to be able to tell these two very distinct cases apart.
I think that this is already obvious from both the documentation and
git-merge output; I'm not sure what to improve further on this.
I did make some minor tweaks in the conflict resolution part, though.
I hope this would be the final patch revision. :-)
Documentation/git-merge.txt | 76 ++++++++++++++++---------------------------
1 files changed, 29 insertions(+), 47 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 019e4ca..a7487d3 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -57,50 +57,31 @@ HOW MERGE WORKS
A merge is always between the current `HEAD` and one or more
commits (usually, branch head or tag), and the index file must
-exactly match the
-tree of `HEAD` commit (i.e. the contents of the last commit) when
-it happens. In other words, `git diff --cached HEAD` must
-report no changes.
-
-[NOTE]
-This is a bit of a lie. In certain special cases, your index is
-allowed to be different from the tree of the `HEAD` commit. The most
-notable case is when your `HEAD` commit is already ahead of what
-is being merged, in which case your index can have arbitrary
-differences from your `HEAD` commit. Also, your index entries
-may have differences from your `HEAD` commit that match
-the result of a trivial merge (e.g. you received the same patch
-from an external source to produce the same result as what you are
-merging). For example, if a path did not exist in the common
-ancestor and your head commit but exists in the tree you are
-merging into your repository, and if you already happen to have
-that path exactly in your index, the merge does not have to
-fail.
-
-Otherwise, merge will refuse to do any harm to your repository
-(that is, it may fetch the objects from remote, and it may even
-update the local branch used to keep track of the remote branch
-with `git pull remote rbranch:lbranch`, but your working tree,
-`.git/HEAD` pointer and index file are left intact). In addition,
-merge always sets `.git/ORIG_HEAD` to the original state of HEAD so
-a problematic merge can be removed by using `git reset ORIG_HEAD`.
-
-You may have local modifications in the working tree files. In
-other words, 'git-diff' is allowed to report changes.
-However, the merge uses your working tree as the working area,
-and in order to prevent the merge operation from losing such
-changes, it makes sure that they do not interfere with the
-merge. Those complex tables in read-tree documentation define
-what it means for a path to "interfere with the merge". And if
-your local modifications interfere with the merge, again, it
-stops before touching anything.
-
-So in the above two "failed merge" case, you do not have to
-worry about loss of data --- you simply were not ready to do
-a merge, so no merge happened at all. You may want to finish
-whatever you were in the middle of doing, and retry the same
-pull after you are done and ready.
-
+match the tree of `HEAD` commit (i.e. the contents of the last commit)
+when it starts out. In other words, `git diff --cached HEAD` must
+report no changes. (One exception is when the changed index
+entries are already in the same state that would result from
+the merge anyway.)
+
+Three kinds of merge can happen:
+
+* The merged commit is already contained in `HEAD`. This is the
+ simplest case, called "Already up-to-date."
+
+* `HEAD` is already contained in the merged commit. This is the
+ most common case especially when involved through 'git pull':
+ you are tracking an upstream repository, committed no local
+ changes and now you want to update to a newer upstream revision.
+ Your `HEAD` (and the index) is updated to at point the merged
+ commit, without creating an extra merge commit. This is
+ called "Fast-forward".
+
+* Both the merged commit and `HEAD` are independent and must be
+ tied together by a merge commit that has them both as its parents.
+ The rest of this section describes this "True merge" case.
+
+The chosen merge strategy merges the two commits into a single
+new source tree.
When things cleanly merge, these things happen:
1. The results are updated both in the index file and in your
@@ -142,12 +123,13 @@ After seeing a conflict, you can do two things:
* Decide not to merge. The only clean-up you need are to reset
the index file to the `HEAD` commit to reverse 2. and to clean
- up working tree changes made by 2. and 3.; 'git-reset' can
+ up working tree changes made by 2. and 3.; 'git-reset --hard' can
be used for this.
* Resolve the conflicts. `git diff` would report only the
- conflicting paths because of the above 2. and 3. Edit the
- working tree files into a desirable shape, 'git-add' or 'git-rm'
+ conflicting paths because of the above 2. and 3.
+ Edit the working tree files into a desirable shape
+ ('git mergetool' can ease this task), 'git-add' or 'git-rm'
them, to make the index file contain what the merge result
should be, and run 'git-commit' to commit the result.
^ permalink raw reply related
* Re: "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Junio C Hamano @ 2008-07-19 18:15 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: git
In-Reply-To: <7vfxq521ab.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Evgeniy Polyakov <johnpol@2ka.mipt.ru> writes:
>
>> $ git clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> Getting alternates list for http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>> Getting pack list for http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>> Getting index for pack 81cec7c6b26c755e466a79de8dbe1c7b827a48d6
>> error: non-monotonic index
>> /usr/bin/git-clone: line 33: 2025 Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
>>
>> $ git --version
>> git version 1.4.4.4
>>
>> Fresh 32bit Debian testing.
>
> The repository you are cloning uses pack idx version #2; 1.4.4.4 predates it
> by a wide margin.
By the way, Debian folks are very aware of the issue and already has a
backported material to cut a 1.4.4.5, but I do not know what the release
schedule for their update is.
Is it an option for you to update to a more modern version from say
backports.org? Everybody using git for anything serious should be using
1.5.3 or newer these days.
^ permalink raw reply
* Re: "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Junio C Hamano @ 2008-07-19 18:10 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: git
In-Reply-To: <20080719174742.GA4253@2ka.mipt.ru>
Evgeniy Polyakov <johnpol@2ka.mipt.ru> writes:
> $ git clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Getting alternates list for http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> Getting pack list for http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> Getting index for pack 81cec7c6b26c755e466a79de8dbe1c7b827a48d6
> error: non-monotonic index
> /usr/bin/git-clone: line 33: 2025 Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
>
> $ git --version
> git version 1.4.4.4
The repository you are cloning uses pack idx version #2; 1.4.4.4 predates it
by a wide margin.
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Keith Packard @ 2008-07-19 17:57 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: keithp, git
In-Reply-To: <1216487215-6927-1-git-send-email-fredrik@dolda2000.com>
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
On Sat, 2008-07-19 at 19:06 +0200, Fredrik Tolf wrote:
> By removing the DISPLAY env variable before forking, SSH
> can thus be forced into non-interactive mode, without any obvious
> ill effects.
This will keep ssh-askpass from using any X-based password input
program.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* "error: non-monotonic index" during fresh linux-2.6.git cloning.
From: Evgeniy Polyakov @ 2008-07-19 17:47 UTC (permalink / raw)
To: git
Hi.
I'm getting above error each time I'm tying to clone current 2.6 tree.
Archives tell that it happens when local index is currupted, but I do
not have local tree, it is a fresh clone in an empty dir.
$ git clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Getting alternates list for http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting pack list for http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting index for pack 81cec7c6b26c755e466a79de8dbe1c7b827a48d6
error: non-monotonic index
/usr/bin/git-clone: line 33: 2025 Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
$ git --version
git version 1.4.4.4
Fresh 32bit Debian testing.
It worked before (at least several months ago) and works with 1.5.2.5.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Mike Hommey @ 2008-07-19 17:52 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: git
In-Reply-To: <1216487215-6927-1-git-send-email-fredrik@dolda2000.com>
On Sat, Jul 19, 2008 at 07:06:55PM +0200, Fredrik Tolf wrote:
> OpenSSH has the nice feature that it sets the IP TOS value of its
> connection depending on usage. When used in interactive mode, it
> is set to Minimize-Delay, and other wise to Maximize-Throughput. Its
> usage by Git is best served by Maximize-Throughput, for obvious
> reasons.
>
> However, it seems to use a DWIM heuristic for detecting interactive
> mode. The current implementation enters interactive mode if either
> a PTY is allocated or X11 forwarding is enabled, and even though Git
> SSH:ing does not allocate a PTY, X11 forwarding is often turned on
> by default. By removing the DISPLAY env variable before forking, SSH
> can thus be forced into non-interactive mode, without any obvious
> ill effects.
Wouldn't adding the -x option be better ? Also adding -T could be a good
idea.
Mike
^ permalink raw reply
* Re: [PATCH] builtin-clone: Use is_dir_sep() instead of '/'
From: Daniel Barkalow @ 2008-07-19 17:44 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <200807191549.56402.johannes.sixt@telecom.at>
On Sat, 19 Jul 2008, Johannes Sixt wrote:
> On Samstag, 19. Juli 2008, Johannes Sixt wrote:
> > On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> > > Ok, but the surrounding code in this function look very suspicious.
> >
> > How about this then?
> >
> > -- snip --
> > builtin-clone: Rewrite guess_dir_name()
> >
> > The function has to do three small and independent tasks, but all of them
> > were crammed into a single loop. This rewrites the function entirely by
> > unrolling these tasks.
>
> Sigh. I knew it, I knew it. If it had been that trivial, then Daniel had done
> it this way in the first place. :-(
>
> This needs to be squashed in. It makes sure that we handle 'foo/.git';
> and .git was not stripped if we cloned from 'foo.git/'.
I actually got that from Johannes Schindelin, who added bundle support to
my clone patch. I remember looking at his change, thinking it looked
overly complicated, but finding that anything I tried to do to simplify it
failed tests. If this gets through the test suite (lots of the tests other
than the clone test try to do a wider variety of odd things than I expect
users do in practice most of the time), then it's probably a better
implementation.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Ensure that SSH runs in non-interactive mode
From: Fredrik Tolf @ 2008-07-19 17:06 UTC (permalink / raw)
To: git; +Cc: Fredrik Tolf
OpenSSH has the nice feature that it sets the IP TOS value of its
connection depending on usage. When used in interactive mode, it
is set to Minimize-Delay, and other wise to Maximize-Throughput. Its
usage by Git is best served by Maximize-Throughput, for obvious
reasons.
However, it seems to use a DWIM heuristic for detecting interactive
mode. The current implementation enters interactive mode if either
a PTY is allocated or X11 forwarding is enabled, and even though Git
SSH:ing does not allocate a PTY, X11 forwarding is often turned on
by default. By removing the DISPLAY env variable before forking, SSH
can thus be forced into non-interactive mode, without any obvious
ill effects.
Signed-off-by: Fredrik Tolf <fredrik@dolda2000.com>
---
connect.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/connect.c b/connect.c
index 574f42f..54888d3 100644
--- a/connect.c
+++ b/connect.c
@@ -607,6 +607,13 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
*arg++ = port;
}
*arg++ = host;
+ /* Remove the X11 DISPLAY from the environment, to
+ * make SSH run non-interactively */
+ const char *env[] = {
+ "DISPLAY",
+ NULL
+ };
+ conn->env = env;
}
else {
/* remove these from the environment */
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH] Windows: set gitexecdir = $(bindir)
From: Junio C Hamano @ 2008-07-19 17:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Steffen Prohaska, git, Johannes Schindelin
In-Reply-To: <200807191052.20057.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Samstag, 19. Juli 2008, Junio C Hamano wrote:
>> Sorry, I am not sure if I understand what you are trying to solve. If you
>> have ../libexec/git-core/ in GIT_EXEC_PATH (or have builtin_exec_path()
>> use it), then your installation would look like this:
>>
>> [[some random place]]
>> bin/git
>> libexec/git-core/git-add
>> libexec/git-core/git-del
>> libexec/git-core/git-dir
>> ...
>>
>> and if "git" can figure out it is "[[some random place]]/bin/git",
>> it can find its subcommands from neighbouring directory, that is still
>> inside the random place the user told the installer to use, can't it?
>
> Yes, but...
>
> Take as an example 'git pull'.
>
> - The first call to git will derive the exec-path
> $prefix/bin/../libexec/git-core and prepend it to $PATH.
>
> - Calls to builtin git commands from inside 'git pull' will then derive the
> exec-path $prefix/bin/../libexec/git-core/../libexec/git-core, that is
> $prefix/libexec/libexec/git-core, and prepend it to $PATH as well. That
> directory does not exist - usually - and it does not hurt. But it feels dirty
> and potentially dangerous.
You run "git" with an argument "pull". It needs to figure out where
"git-pull" is, it checks where it came from and adds ../libexec/git-core/.
Then it runs "git-pull" script.
Then the script may have a call to "git ls-files -u" or "git-merge".
- The former case, "git" again needs to find out where "git-ls-files"
is.
If "git" is found as bin/git and not as libexec/git-core/git, this
should be perfectly fine, isn't it? Perhaps we install a duplicate
copy there by mistake, which is what we need to fix?
- The latter case (our scripts source git-sh-setup so they have libexec
one in the PATH when they are started) would find "git-merge" directly
and runs it.
In either case, the programs "git-ls-files" and "git-merge" do not need to
do the same discovery -- are we giving them enough clues when we run them
to let them avoid that?
^ permalink raw reply
* Re: [PATCH] Windows: set gitexecdir = $(bindir)
From: Steffen Prohaska @ 2008-07-19 17:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <200807191052.20057.johannes.sixt@telecom.at>
On Jul 19, 2008, at 10:52 AM, Johannes Sixt wrote:
> On Samstag, 19. Juli 2008, Junio C Hamano wrote:
>> Sorry, I am not sure if I understand what you are trying to solve.
>> If you
>> have ../libexec/git-core/ in GIT_EXEC_PATH (or have
>> builtin_exec_path()
>> use it), then your installation would look like this:
>>
>> [[some random place]]
>> bin/git
>> libexec/git-core/git-add
>> libexec/git-core/git-del
>> libexec/git-core/git-dir
>> ...
>>
>> and if "git" can figure out it is "[[some random place]]/bin/git",
>> it can find its subcommands from neighbouring directory, that is
>> still
>> inside the random place the user told the installer to use, can't it?
>
> Yes, but...
>
> Take as an example 'git pull'.
>
> - The first call to git will derive the exec-path
> $prefix/bin/../libexec/git-core and prepend it to $PATH.
>
> - Calls to builtin git commands from inside 'git pull' will then
> derive the
> exec-path $prefix/bin/../libexec/git-core/../libexec/git-core, that is
> $prefix/libexec/libexec/git-core, and prepend it to $PATH as well.
> That
> directory does not exist - usually - and it does not hurt. But it
> feels dirty
> and potentially dangerous.
Maybe we can avoid this based on the name of the executable?
We would add libexec only if the executable is named "git",
but not if it is one of the dashed forms "git-*".
Steffen
^ 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