* Re: Closing the merge window for 1.6.0
From: Nick Andrew @ 2008-07-20 2:23 UTC (permalink / raw)
To: git
In-Reply-To: <20080714124327.GL10151@machine.or.cz>
Petr Baudis <pasky <at> suse.cz> writes:
> Upgrading to newer version, *especially* if it's over then 1.4 - 1.5
> boundary, is not something you could seriously expect Debian to do.
> At least I actually _hope_ so, as a sysadmin of a network of 40 etch
> workstations.
Perhaps Debian could add a "git1.5" package to the etch repository. That
will guarantee that no current etch users of git 1.4.4.4 will be affected,
and they can choose if they want, to install git1.5.
Nick.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2008-07-20 1:59 UTC (permalink / raw)
To: git
In-Reply-To: <7vabgiwlj5.fsf@gitster.siamese.dyndns.org>
* The 'maint' branch is at 1.5.6.4.
* The 'master' branch has these since the last announcement
in addition to what is already in 1.5.6.4.
Alexander Gavrilov (3):
Avoid rescanning unchanged entries in search for copies.
Do not try to detect move/copy for entries below threshold.
Support gitlinks in fast-import.
Eric Raible (1):
Teach lookup_prog not to select directories
Eric Wong (1):
t/lib-git-svn: fix SVN_HTTPD tests to work with "trash directory"
Fabian Emmes (2):
Testsuite: Unset CVS_SERVER
testsuite for cvs co -c
Johannes Sixt (1):
builtin-clone: rewrite guess_dir_name()
Junio C Hamano (9):
git-rebase: report checkout failure
t/aggregate-results: whitespace fix
Update draft release notes for 1.6.0
read-cache.c: typofix
mailinfo: off-by-one fix for [PATCH (foobar)] removal from Subject: line
builtin-remote.c: fix earlier "skip_prefix()" conversion
t9001 (send-email): Do not use hardcoded /bin/sh in test
.mailmap update
Getting closer to 1.6.0-rc0
Lars Noschinski (2):
cvsserver: Add support for packed refs
cvsserver: Add cvs co -c support
Lukas Sandström (3):
Make some strbuf_*() struct strbuf arguments const.
Add some useful functions for strbuf manipulation.
git-mailinfo: use strbuf's instead of fixed buffers
Miklos Vajna (4):
t0001-init.sh: change confusing directory name
t1007-hash-object.sh: use quotes for the test description
git-bisect: use dash-less form on git bisect log
make remove-dashes: apply to scripts and programs as well, not just to
builtins
Nanako Shiraishi (3):
cache-tree.c: make cache_tree_find() static
builtin-describe.c: make a global variable "pattern" static
parse-options.c: make check_typos() static
Peter Harris (1):
Add ANSI control code emulation for the Windows console
Petr Baudis (5):
Documentation/git-submodule.txt: Add Description section
Documentation/RelNotes-1.6.0.txt: Expand on the incompatible packfiles
Documentation/git-submodule.txt: Further clarify the description
Documentation: How to ignore local changes in tracked files
Documentation/git-merge.txt: Partial rewrite of How Merge Works
René Scharfe (8):
archive: remove args member from struct archiver
add context pointer to read_tree_recursive()
archive: add baselen member to struct archiver_args
archive: centralize archive entry writing
archive: unify file attribute handling
archive: remove extra arguments parsing code
archive: make zip compression level independent from core git
archive: remove unused headers
Stephan Beyer (4):
t/test-lib.sh: exit with small negagive int is ok with test_must_fail
t/: Use "test_must_fail git" instead of "! git"
Make usage strings dash-less
Link git-shell only to a subset of libgit.a
SungHyun Nam (1):
t/Makefile: use specified shell when running aggregation script
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-20 1:58 UTC (permalink / raw)
To: git
In-Reply-To: <7vlk01hqzz.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
Due to increased activity level from people including GSoC students, I
expect 'next' to stay somewhat more active than previous rounds during the
1.6.0-rc cycle. The request for people who usually follow 'next' is the
same as usual, though. After -rc1 is tagged, please run 'master' for your
daily git use instead, in order to make sure 'master' does what it claims
to do without regression.
Tentative schedule, my wishful thinking:
- 1.6.0-rc0 (Jul 20)
- 1.6.0-rc1 (Jul 23)
- 1.6.0-rc2 (Jul 30)
- 1.6.0-rc3 (Aug 6)
- 1.6.0 (Aug 10)
No real activity on 'next', as I was busy tending bugfixes and pushing out
v1.5.6.4 today.
----------------------------------------------------------------
[Will merge to "master" soon]
* ns/am-abort (Wed Jul 16 19:39:10 2008 +0900) 1 commit
+ git am --abort
This one is for Ted; builds on top of the recent "am and rebase leaves
ORIG_HEAD just like reset, merge and pull does" rather nicely.
* jc/rerere-auto-more (Wed Jul 16 20:25:18 2008 -0700) 1 commit
+ rerere.autoupdate: change the message when autoupdate is in effect
This one is for Ingo.
This changes the message rerere issues after reusing previous conflict
resolution from "Resolved" to "Staged" when autoupdate option is in
effect.
It is envisioned that in practice, some auto resolutions are trickier and
iffier than others, and we would want to add a feature to mark individual
resolutions as "this is ok to autoupdate" or "do not autoupdate the result
using this resolution even when rerere.autoupdate is in effect" in the
future. When that happens, these messages will make the distinction
clearer.
* ap/trackinfo (Wed Jul 16 15:19:27 2008 -0400) 1 commit
+ Reword "your branch has diverged..." lines to reduce line length
----------------------------------------------------------------
[Stalled/Needs more work]
* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
- Documentation: Improve documentation for git-imap-send(1)
- imap-send.c: more style fixes
- imap-send.c: style fixes
- git-imap-send: Support SSL
- git-imap-send: Allow the program to be run from subdirectories of
a git tree
I said: "Some people seem to prefer having this feature available also
with gnutls. If such a patch materializes soon, that would be good, but
otherwise I'll merge this as-is to 'next'. Such an enhancement can be
done in-tree on top of this series." Anybody?
* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
. cherry: cache patch-ids to avoid repeating work
The discussion suggested that the value of having the cache itself is
iffy, but I should pick up the updated one and look at it.
* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
. gitweb: use new Git::Repo API, and add optional caching
. Add new Git::Repo API
. gitweb: add test suite with Test::WWW::Mechanize::CGI
* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
. Migrate git-am to use git-sequencer
. Add git-sequencer test suite (t3350)
. Add git-sequencer prototype documentation
. Add git-sequencer shell prototype
I haven't looked at the updated series yet. I should, but nobody else
seems to be looking at these patches, which is somewhat depressing but
understandable. Summer is slower ;-)
* pb/submodule (Wed Jul 16 21:11:40 2008 +0200) 7 commits
. t7403: Submodule git mv, git rm testsuite
. git rm: Support for removing submodules
. git mv: Support moving submodules
. submodule.*: Introduce simple C interface for submodule lookup by
path
. git submodule add: Fix naming clash handling
. t7400: Add short "git submodule add" testsuite
. git-mv: Remove dead code branch
Long overdue usability improvement series for submodule. Very much
welcomed. It would be nice to have some submodule improvements in 1.6.0,
but it would take us a few more rounds to hit 'next' with this, and it
will not be in 'master' when 1.6.0 ships.
* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
- [BROKEN wrt shallow clones] Ignore graft during object transfer
Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck. This fixes object transfer to ignore grafts.
Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
This is for peeling the line from the blamed version to see what's behind
it, which may or may not help applications like gitweb.
----------------------------------------------------------------
[Will drop]
* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
+ Teach git-merge -X<option> again.
+ Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
+ builtin-merge.c: use parse_options_step() "incremental parsing"
machinery
+ Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
* jc/merge-theirs (Fri Jul 18 02:43:00 2008 -0700) 6 commits
- Document that merge strategies can now take their own options
+ Make "subtree" part more orthogonal to the rest of merge-
recursive.
+ Teach git-pull to pass -X<option> to git-merge
+ Teach git-merge to pass -X<option> to the backend strategy module
+ git-merge-recursive-{ours,theirs}
+ git-merge-file --ours, --theirs
It appears nobody wants "theirs" nor "ours", so I'll soon apply a
wholesale revert for these series to 'next', and then these will be
dropped when we rewind 'next' after 1.6.0 final.
Please make sure next time somebody asks "ours/theirs" merge on the list
and #git s/he is quickly told that it was unanimously rejected so that
people do not have to waste time rehashing the topic ever again.
----------------------------------------------------------------
[On Hold]
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet. Perhaps
in 1.7.0.
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
+ Revert "Make clients ask for "git program" over ssh and local
transport"
+ Make clients ask for "git program" over ssh and local transport
This is the "botched" one. Will be resurrected during 1.7.0 or 1.8.0
timeframe.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
^ permalink raw reply
* Re: [PATCH/rfc] git-svn.perl: workaround assertions in svn library 1.5.0
From: Junio C Hamano @ 2008-07-20 1:27 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Gerrit Pape, git, Eric Wong
In-Reply-To: <37fcd2780807171137m1c5a8197vc94b2a42ac53a297@mail.gmail.com>
"Dmitry Potapov" <dpotapov@gmail.com> writes:
> On Thu, Jul 17, 2008 at 6:08 PM, Gerrit Pape <pape@smarden.org> wrote:
>>
>> Hi, while this commit fixed the selftests, it unfortunately is a
>> regression
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/87822/
>> http://bugs.debian.org/490400
>
> This particular breakage is easy to fix:
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 3750e47..a5a5b1b 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1226,7 +1226,7 @@ sub linearize_history {
>
> sub find_file_type_and_diff_status {
> my ($path) = @_;
> - return ('dir', '') if $path eq '.';
> + return ('dir', '') if $path eq '';
>
> my $diff_output =
> command_oneline(qw(diff --cached --name-status --), $path) || "";
>
> but it could be some other places in git-svn that may need correction too.
>
>>
>> I'm still not sure whether this is a git-svn problem, or actually a
>> problem in subversion 1.5.0
>
> Accordingly to SVN developers you do not use SVN API correctly,
> therefore you got assert. So, the problem in git-svn.
> http://svn.haxx.se/dev/archive-2008-01/0425.shtml
So what's the conclusion of this issue?
I'll just revert 2fe403e (git-svn.perl: workaround assertions in svn
library 1.5.0, 2008-07-06) for 1.6.0-rc0 unless I hear better
suggestions.
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.6.4
From: Junio C Hamano @ 2008-07-20 0:56 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.5.6.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.6.4.tar.{gz,bz2} (source tarball)
git-htmldocs-1.5.6.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.6.4.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also provided
as courtesy.
RPMS/$arch/git-*-1.5.6.4-1.fc9.$arch.rpm (RPM)
GIT v1.5.6.4 Release Notes
==========================
Fixes since v1.5.6.3
--------------------
* Various commands could overflow its internal buffer on a platform
with small PATH_MAX value in a repository that has contents with
long pathnames.
* There wasn't a way to make --pretty=format:%<> specifiers to honor
.mailmap name rewriting for authors and committers. Now you can with
%aN and %cN.
* Bash completion wasted too many cycles; this has been optimized to be
usable again.
* Bash completion lost ref part when completing something like "git show
pu:Makefile".
* "git-cvsserver" did not clean up its temporary working area after annotate
request.
* "git-daemon" called syslog() from its signal handler, which was a
no-no.
* "git-fetch" into an empty repository used to remind that the fetch will
be huge by saying "no common commits", but this was an unnecessary
noise; it is already known by the user anyway.
* "git-http-fetch" would have segfaulted when pack idx file retrieved
from the other side was corrupt.
* "git-index-pack" used too much memory when dealing with a deep delta chain.
* "git-mailinfo" (hence "git-am") did not correctly handle in-body [PATCH]
line to override the commit title taken from the mail Subject header.
* "git-rebase -i -p" lost parents that are not involved in the history
being rewritten.
* "git-rm" lost track of where the index file was when GIT_DIR was
specified as a relative path.
* "git-rev-list --quiet" was not quiet as advertised.
Contains other various documentation fixes.
^ permalink raw reply
* [PATCH] index: be careful when handling long names
From: Junio C Hamano @ 2008-07-20 0:51 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
This is a follow-up to 7fec10b (index: be careful when handling long
names, 2008-01-18) where we fixed handling of index entries with long
names. There still remained a few remaining unsafe codepaths.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-apply.c | 2 +-
builtin-update-index.c | 2 +-
read-cache.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index e15471b..f2377fe 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2758,7 +2758,7 @@ static void add_index_file(const char *path, unsigned mode, void *buf, unsigned
ce = xcalloc(1, ce_size);
memcpy(ce->name, path, namelen);
ce->ce_mode = create_ce_mode(mode);
- ce->ce_flags = namelen;
+ ce->ce_flags = create_ce_flags(namelen, 0);
if (S_ISGITLINK(mode)) {
const char *s = buf;
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 38eb53c..003cb98 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -95,7 +95,7 @@ static int add_one_path(struct cache_entry *old, const char *path, int len, stru
size = cache_entry_size(len);
ce = xcalloc(1, size);
memcpy(ce->name, path, len);
- ce->ce_flags = len;
+ ce->ce_flags = create_ce_flags(len, 0);
fill_stat_cache_info(ce, st);
ce->ce_mode = ce_mode_from_stat(old, st->st_mode);
diff --git a/read-cache.c b/read-cache.c
index 1648428..2dd8131 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -498,7 +498,7 @@ int add_to_index(struct index_state *istate, const char *path, struct stat *st,
size = cache_entry_size(namelen);
ce = xcalloc(1, size);
memcpy(ce->name, path, namelen);
- ce->ce_flags = namelen;
+ ce->ce_flags = create_ce_flags(namelen, 0);
fill_stat_cache_info(ce, st);
if (trust_executable_bit && has_symlinks)
^ permalink raw reply related
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Jakub Narebski @ 2008-07-20 0:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080719211403.GA10151@machine.or.cz>
On Sat, 19 July 2008, Petr Baudis wrote:
> On Sat, Jul 19, 2008 at 10:54:24PM +0200, Jakub Narebski wrote:
> > 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.
So that the code would look like the following, instead:
my $git = new Git::Cmd; # or Git::Standalone, or Git::CommandFactory
my $repo = eval { Git->repository() };
$git = $repo if $repo;
and later use
$git->config('sendemail.identity');
By the way, git-svn can use command(...) instead of $repo->command(...)
because it sets $ENV{'GIT_DIR'} if it is unset... but I don't see
where Git.pm inserts 'git' to commands list...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-mv: Keep moved index entries inact
From: Junio C Hamano @ 2008-07-19 23:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080717223036.20680.9672.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> A new test has been added to the testsuite to reflect this change.
> Also, based on suggestion by Junio about desired symlink behaviour
> of git mv, I have added two tests for that; however, I do not have
> need or desire to spend time fixing this, so they are expected
> to fail for now until someone gets around to fixing that.
Well, somebody would eventually come to help, then ;-).
> builtin-mv.c | 62 ++++++++-------------------------------------------------
> cache.h | 2 ++
> read-cache.c | 15 ++++++++++++++
> t/t7001-mv.sh | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 83 insertions(+), 53 deletions(-)
Very nice code reduction, isn't it?
> diff --git a/read-cache.c b/read-cache.c
> index 1648428..70e5f57 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -38,6 +38,21 @@ static void replace_index_entry(struct index_state *istate, int nr, struct cache
> istate->cache_changed = 1;
> }
>
> +void rename_index_entry_at(struct index_state *istate, int nr, const char *new_name)
> +{
> + struct cache_entry *old = istate->cache[nr], *new;
> + int namelen = strlen(new_name);
> +
> + new = xmalloc(cache_entry_size(namelen));
> + copy_cache_entry(new, old);
> + new->ce_flags = (new->ce_flags & ~CE_NAMEMASK) | namelen;
> + memcpy(new->name, new_name, namelen);
> +
> + cache_tree_invalidate_path(istate->cache_tree, old->name);
> + remove_index_entry_at(istate, nr);
> + add_index_entry(istate, new, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
> +}
Hmm, would this use of copy_cache_entry() kosher, I have to wonder. This
new copy of cache entry begins its life unhashed, doesn't it? Shouldn't
we be not copying its hashed/unhashed bits from the old one?
Also setting of that ce_flags looks wrong when namelen does not fit within
the width of CE_NAMEMASK. Shouldn't it be doing the same thing as
create_ce_flags()?
> diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
> index 336cfaa..6b615f8 100755
> --- a/t/t7001-mv.sh
> +++ b/t/t7001-mv.sh
> @@ -156,4 +156,61 @@ test_expect_success 'absolute pathname outside should fail' '(
>
> )'
>
> +# git mv meets angry Git maintainer
What's this comment about?
> +test_expect_success 'git mv should not change sha1 of moved cache entry' '
> +
> + rm -fr .git &&
> + git init &&
> + echo 1 >dirty &&
> + git add dirty &&
> + entry="$(git ls-files --stage dirty | cut -f 1)"
"rev-parse :dirty"?
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-19 23:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7v4p6l3jbm.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 19 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Yes, I agree, if all strategies fail, it is dubitable that we find a
> > metric that will always find the "best" one. But if one fails and the
> > next one does not, it is obvious what is correct.
>
> Not at all. Imagine the case where one of them is either ours or
> theirs.
But then it is not the _default_ at all!
It is what the _user_ _asked_ for.
So this is what the user gets.
With Git, the user is not ignored (like GNOME does, to "help" the user).
With Git, the user _gets_ what she asked for, even if the question does
not make sense.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git submodule documentation: typo fix
From: Miklos Vajna @ 2008-07-19 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vfxq5xzqy.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 277 bytes --]
On Sat, Jul 19, 2008 at 03:42:13PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Thanks, but I think Pasky already covered this typo in his latest round.
Ah, possible. I was just reading 'git log -p junio/master' to catch up
with the recent changes and noticed this one.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git submodule documentation: typo fix
From: Junio C Hamano @ 2008-07-19 22:42 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Petr Baudis, git
In-Reply-To: <1216506534-27649-1-git-send-email-vmiklos@frugalware.org>
Thanks, but I think Pasky already covered this typo in his latest round.
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Jakub Narebski @ 2008-07-19 22:39 UTC (permalink / raw)
To: git
In-Reply-To: <7vd4l9zgmp.fsf@gitster.siamese.dyndns.org>
[This is git@vger.kernel.org only copy]
Junio C Hamano wrote:
> 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".
I guess instead of "git reset --hard" we can use here "git stash save
&& git stash apply --index" to save state (perhaps as "git stash save
--no-reset"), and either "git stash drop" at the the end, or
"git reset --hard && git stash pop --index" at '--abort'.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] git submodule documentation: typo fix
From: Miklos Vajna @ 2008-07-19 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
The current status of submodules can be queried using the 'status' (and
not the 'submodule') subcommand.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-submodule.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index bb4e6fb..e849858 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -34,7 +34,7 @@ When adding a new submodule to the tree, the 'add' subcommand is to be used.
However, when pulling a tree containing submodules, these will not be checked
out by default; the 'init' and 'update' subcommands will maintain submodules
checked out and at appropriate revision in your working tree. You can inspect
-the current status of your submodules using the 'submodule' subcommand and get
+the current status of your submodules using the 'status' subcommand and get
an overview of changes 'update' would perform using the 'summary' subcommand.
--
1.5.6.2.450.g8d367.dirty
^ permalink raw reply related
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Junio C Hamano @ 2008-07-19 22:27 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: <7v3am5zfea.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> 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"
We still need "git reset ORIG_HEAD" after the read-tree. Sorry about the
noise.
> exit ;;
> esac
> else
^ permalink raw reply
* 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
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