* Re: CVS-$Id:$ replacement in git?
From: Johannes Schindelin @ 2007-08-31 16:33 UTC (permalink / raw)
To: Andreas Hildebrandt; +Cc: git
In-Reply-To: <46D82DC3.2030203@bioinf.uni-sb.de>
Hi,
On Fri, 31 Aug 2007, Andreas Hildebrandt wrote:
> But unfortunately, we internally rely heavily on the $Id:$ - expansion
> of CVS, that is the ability to have a line like
>
> $Id:$
>
> in the source file expanded to something like
>
> $Id: HINFile.C,v 1.64 2005/02/09 13:02:41 oliver Exp $
>
> The information we want to store in the file would be something like the
> SHA1 of the last commit that touched that file, the date when it
> happened and the person who commited it.
Please see Documentation/gitattributes.txt, look for 'ident'.
Hth,
Dscho
^ permalink raw reply
* Re: CVS-$Id:$ replacement in git?
From: Junio C Hamano @ 2007-08-31 16:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Hildebrandt, git
In-Reply-To: <Pine.LNX.4.64.0708311732580.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 31 Aug 2007, Andreas Hildebrandt wrote:
>
>> But unfortunately, we internally rely heavily on the $Id:$ - expansion
>> of CVS, that is the ability to have a line like
>>
>> $Id:$
>>
>> in the source file expanded to something like
>>
>> $Id: HINFile.C,v 1.64 2005/02/09 13:02:41 oliver Exp $
>>
>> The information we want to store in the file would be something like the
>> SHA1 of the last commit that touched that file, the date when it
>> happened and the person who commited it.
>
> Please see Documentation/gitattributes.txt, look for 'ident'.
Please do _not_ see that. ident is about blob object name and
does not have anything to do with the commit, pathname,
committer, nor date, and this is deliberately so.
^ permalink raw reply
* [PATCH] filter-branch: fix remnants of old syntax in documentation
From: Johannes Schindelin @ 2007-08-31 16:42 UTC (permalink / raw)
To: git, gitster
Some time ago, filter-branch's syntax changed so that more than one
ref can be rewritten at the same time. This involved the removal of
the ref name for the result; instead, the refs are rewritten in-place.
This updates the last leftovers in the documentation to reflect the
new behavior.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/git-filter-branch.txt | 32 ++++++++++++++++++--------------
1 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index ae03514..4f89c04 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -17,19 +17,19 @@ SYNOPSIS
DESCRIPTION
-----------
-Lets you rewrite git revision history by creating a new branch from
-your current branch, applying custom filters on each revision.
+Lets you rewrite git revision history by rewriting the branches mentioned
+in the <rev-list options>, applying custom filters on each revision.
Those filters can modify each tree (e.g. removing a file or running
a perl rewrite on all files) or information about each commit.
Otherwise, all information (including original commit times or merge
information) will be preserved.
-The command takes the new branch name as a mandatory argument and
-the filters as optional arguments. If you specify no filters, the
-commits will be recommitted without any changes, which would normally
-have no effect. Nevertheless, this may be useful in the future for
-compensating for some git bugs or such, therefore such a usage is
-permitted.
+The command will only rewrite the _positive_ refs mentioned in the
+command line (i.e. if you pass 'a..b', only 'b' will be rewritten).
+If you specify no filters, the commits will be recommitted without any
+changes, which would normally have no effect. Nevertheless, this may be
+useful in the future for compensating for some git bugs or such,
+therefore such a usage is permitted.
*WARNING*! The rewritten history will have different object names for all
the objects and will not converge with the original branch. You will not
@@ -43,8 +43,8 @@ if different from the rewritten ones, will be stored in the namespace
'refs/original/'.
Note that since this operation is extensively I/O expensive, it might
-be a good idea to redirect the temporary directory off-disk, e.g. on
-tmpfs. Reportedly the speedup is very noticeable.
+be a good idea to redirect the temporary directory off-disk with the
+'-d' option, e.g. on tmpfs. Reportedly the speedup is very noticeable.
Filters
@@ -112,6 +112,9 @@ OPTIONS
As a special extension, the commit filter may emit multiple
commit ids; in that case, ancestors of the original commit will
have all of them as parents.
++
+Note that the 'map' function is not available in the commit filter yet.
+This will be changed in a future version.
--tag-name-filter <command>::
This is the filter for rewriting tag names. When passed,
@@ -186,8 +189,8 @@ order to paste the other history behind the current history:
git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD
-------------------------------------------------------------------
-(if the parent string is empty - therefore we are dealing with the
-initial commit - add graftcommit as a parent). Note that this assumes
+(if the parent string is empty - which happens when we are dealing with
+the initial commit - add graftcommit as a parent). Note that this assumes
history with a single root (that is, no merge without common ancestors
happened). If this is not the case, use:
@@ -232,11 +235,12 @@ range in addition to the new branch name. The new branch name will
point to the top-most revision that a 'git rev-list' of this range
will print.
-Note that the changes introduced by the commits, and not reverted by
-subsequent commits, will still be in the rewritten branch. If you want
+*NOTE* the changes introduced by the commits, and which are not reverted
+by subsequent commits, will still be in the rewritten branch. If you want
to throw out _changes_ together with the commits, you should use the
interactive mode of gitlink:git-rebase[1].
+
Consider this history:
------------------
--
1.5.3.rc7.18.gc9b59
^ permalink raw reply related
* Re: [PATCH 1/2] Introduces xmkstemp()
From: Luiz Fernando N. Capitulino @ 2007-08-31 16:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Marius Storm-Olsen, git
In-Reply-To: <46D7D60C.8090608@telecom.at>
Em Fri, 31 Aug 2007 10:49:16 +0200
Johannes Sixt <j.sixt@telecom.at> escreveu:
| Marius Storm-Olsen schrieb:
| > Just wanted to let the original author know, so he would be aware of it,
| > and we wouldn't have to go the extra round-trips with patches to fix
| > patches. (And for MinGW awareness when adding code to git-compat-util.h)
|
| You can't expect a lot of MinGW awareness from non-MinGW users when they
| make changes to git-compat-util.h since upstream does not have _any_
| references to MinGW there, yet.
Droping people from the CC doesn't help either.
Please, do not do that.
--
Luiz Fernando N. Capitulino
^ permalink raw reply
* Re: CVS-$Id:$ replacement in git?
From: Rogan Dawes @ 2007-08-31 16:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Andreas Hildebrandt, git
In-Reply-To: <7v8x7r1wyy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Fri, 31 Aug 2007, Andreas Hildebrandt wrote:
>>
>>> But unfortunately, we internally rely heavily on the $Id:$ - expansion
>>> of CVS, that is the ability to have a line like
>>>
>>> $Id:$
>>>
>>> in the source file expanded to something like
>>>
>>> $Id: HINFile.C,v 1.64 2005/02/09 13:02:41 oliver Exp $
>>>
>>> The information we want to store in the file would be something like the
>>> SHA1 of the last commit that touched that file, the date when it
>>> happened and the person who commited it.
>> Please see Documentation/gitattributes.txt, look for 'ident'.
>
> Please do _not_ see that. ident is about blob object name and
> does not have anything to do with the commit, pathname,
> committer, nor date, and this is deliberately so.
>
For more details see this thread:
<http://thread.gmane.org/gmane.comp.version-control.git/44750>
Rogan
^ permalink raw reply
* [PATCH] rebase -i: mention the option to split commits in the man page
From: Johannes Schindelin @ 2007-08-31 17:10 UTC (permalink / raw)
To: git, gitster
The interactive mode of rebase can be used to split commits. Tell the
interested parties about it, with a dedicated section in the man page.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I hope I got the asciidoc markup right...
Documentation/git-rebase.txt | 39 ++++++++++++++++++++++++++++++++++++++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index a1b6dce..640ea3b 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -211,7 +211,8 @@ OPTIONS
-i, \--interactive::
Make a list of the commits which are about to be rebased. Let the
- user edit that list before rebasing.
+ user edit that list before rebasing. This mode can also be used to
+ split commits (see SPLITTING COMMITS below).
-p, \--preserve-merges::
Instead of ignoring merges, try to recreate them. This option
@@ -325,6 +326,42 @@ sure that the current HEAD is "B", and call
$ git rebase -i -p --onto Q O
-----------------------------
+
+SPLITTING COMMITS
+-----------------
+
+In interactive mode, you can mark commits with the action "edit". However,
+this does not necessarily mean that 'git rebase' expects the result of this
+edit to be exactly one commit. Indeed, you can undo the commit, or you can
+add other commits. This can be used to split a commit into two:
+
+- Start an interactive rebase with 'git rebase -i <commit>^', where
+ <commit> is the commit you want to split. In fact, any commit range
+ will do, as long as it contains that commit.
+
+- Mark the commit you want to split with the action "edit".
+
+- When it comes to editing that commit, execute 'git reset HEAD^'. The
+ effect is that the HEAD is rewound by one, and the index follows suit.
+ However, the working tree stays the same.
+
+- Now add the changes to the index that you want to have in the first
+ commit. You can use gitlink:git-add[1] (possibly interactively) and/or
+ gitlink:git-gui[1] to do that.
+
+- Commit the now-current index with whatever commit message is appropriate
+ now.
+
+- Repeat the last two steps until your working tree is clean.
+
+- Continue the rebase with 'git rebase --continue'.
+
+If you are not absolutely sure that the intermediate revisions are
+consistent (they compile, pass the testsuite, etc.) you should use
+gitlink:git-stash[1] to stash away the not-yet-committed changes
+after each commit, test, and amend the commit if fixes are necessary.
+
+
Authors
------
Written by Junio C Hamano <junkio@cox.net> and
--
1.5.3.rc7.18.gc9b59
^ permalink raw reply related
* Re: CVS-$Id:$ replacement in git?
From: Johannes Schindelin @ 2007-08-31 17:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Hildebrandt, git
In-Reply-To: <7v8x7r1wyy.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 31 Aug 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 31 Aug 2007, Andreas Hildebrandt wrote:
> >
> >> But unfortunately, we internally rely heavily on the $Id:$ - expansion
> >> of CVS, that is the ability to have a line like
> >>
> >> $Id:$
> >>
> >> in the source file expanded to something like
> >>
> >> $Id: HINFile.C,v 1.64 2005/02/09 13:02:41 oliver Exp $
> >>
> >> The information we want to store in the file would be something like the
> >> SHA1 of the last commit that touched that file, the date when it
> >> happened and the person who commited it.
> >
> > Please see Documentation/gitattributes.txt, look for 'ident'.
>
> Please do _not_ see that. ident is about blob object name and
> does not have anything to do with the commit, pathname,
> committer, nor date, and this is deliberately so.
But this is what I was suggesting... To change the ways for the better.
I admit that I was really sneaky about it.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-reset.txt: Use uniform HEAD~N notation in all examples
From: Jari Aalto @ 2007-08-31 17:47 UTC (permalink / raw)
To: git
The manual mixed both caret(HEAD^) and tilde (HEAD~N) notation in
examples. This may be xconfusing to new users. The "counting" notation
HEAD~N likely to be grasped more easily because it allow successive
numbering 1, 2, 3 etc.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/git-reset.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 15e3aca..c42cd26 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -55,7 +55,7 @@ Undo a commit and redo::
+
------------
$ git commit ...
-$ git reset --soft HEAD^ <1>
+$ git reset --soft HEAD~1 <1>
$ edit <2>
$ git commit -a -c ORIG_HEAD <3>
------------
@@ -77,7 +77,7 @@ $ git commit ...
$ git reset --hard HEAD~3 <1>
------------
+
-<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
+<1> The last three commits (HEAD, HEAD~1, and HEAD~2) were bad
and you do not want to ever see them again. Do *not* do this if
you have already given these commits to somebody else.
@@ -162,7 +162,7 @@ $ git checkout master
$ fix fix fix
$ git commit ;# commit with real log
$ git checkout feature
-$ git reset --soft HEAD^ ;# go back to WIP state <2>
+$ git reset --soft HEAD~1 ;# go back to WIP state <2>
$ git reset <3>
------------
+
--
1.5.3.rc5
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply related
* Re: CVS-$Id:$ replacement in git?
From: Junio C Hamano @ 2007-08-31 18:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Hildebrandt, git
In-Reply-To: <Pine.LNX.4.64.0708311812000.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 31 Aug 2007, Junio C Hamano wrote:
> ...
>> Please do _not_ see that. ident is about blob object name and
>> does not have anything to do with the commit, pathname,
>> committer, nor date, and this is deliberately so.
>
> But this is what I was suggesting... To change the ways for the better.
The thing is that it is not "for the better". See earlier
discussion and please do not beat the dead horse.
^ permalink raw reply
* Re: [PATCH] git-reset.txt: Use uniform HEAD~N notation in all examples
From: Junio C Hamano @ 2007-08-31 19:00 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <tzqfsijk.fsf@cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> The manual mixed both caret(HEAD^) and tilde (HEAD~N) notation in
> examples. This may be xconfusing to new users. The "counting" notation
> HEAD~N likely to be grasped more easily because it allow successive
> numbering 1, 2, 3 etc.
I am mildly negative on this change.
Referring to (rather, "having to refer to" to fix mistakes) the
previous commit happens far more often than referring to an
ancestor of an arbitrary generation away (i.e. HEAD~$n). I
think it is a better idea to expose users early on that HEAD^
notation which is shorter to type.
^ permalink raw reply
* [PATCH 1/2] filter-branch: provide the convenience functions also for commit filters
From: Johannes Schindelin @ 2007-08-31 19:05 UTC (permalink / raw)
To: git, gitster
Move the convenience functions to the top of git-filter-branch.sh, and
return from the script when the environment variable SOURCE_FUNCTIONS is
set.
By sourcing git-filter-branch with that variable set automatically, all
commit filters may access the convenience functions like "map".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Evidently, this is on top of my documentation cleanup...
Obviously, I think that these two changes are simple enough to be
included even this late in the game for 1.5.3. But I understand
completely when people shout at me: "What exactly does deep
feature freeze mean to you *knocks on Dscho's head*?"
Documentation/git-filter-branch.txt | 3 ---
git-filter-branch.sh | 25 +++++++++++++++----------
t/t7003-filter-branch.sh | 10 ++++++++++
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 4f89c04..456d52b 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -112,9 +112,6 @@ OPTIONS
As a special extension, the commit filter may emit multiple
commit ids; in that case, ancestors of the original commit will
have all of them as parents.
-+
-Note that the 'map' function is not available in the commit filter yet.
-This will be changed in a future version.
--tag-name-filter <command>::
This is the filter for rewriting tag names. When passed,
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index c166c97..3b041d8 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -8,15 +8,6 @@
# a new branch. You can specify a number of filters to modify the commits,
# files and trees.
-USAGE="[--env-filter <command>] [--tree-filter <command>] \
-[--index-filter <command>] [--parent-filter <command>] \
-[--msg-filter <command>] [--commit-filter <command>] \
-[--tag-name-filter <command>] [--subdirectory-filter <directory>] \
-[--original <namespace>] [-d <directory>] [-f | --force] \
-[<rev-list options>...]"
-
-. git-sh-setup
-
warn () {
echo "$*" >&2
}
@@ -75,6 +66,20 @@ set_ident () {
echo "[ -n \"\$GIT_${uid}_NAME\" ] || export GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\""
}
+# This script can be sourced by the commit filter to get the functions
+test "a$SOURCE_FUNCTIONS" = a1 && return
+this_script="$(cd "$(dirname "$0")"; pwd)"/$(basename "$0")
+export this_script
+
+USAGE="[--env-filter <command>] [--tree-filter <command>] \
+[--index-filter <command>] [--parent-filter <command>] \
+[--msg-filter <command>] [--commit-filter <command>] \
+[--tag-name-filter <command>] [--subdirectory-filter <directory>] \
+[--original <namespace>] [-d <directory>] [-f | --force] \
+[<rev-list options>...]"
+
+. git-sh-setup
+
tempdir=.git-rewrite
filter_env=
filter_tree=
@@ -131,7 +136,7 @@ do
filter_msg="$OPTARG"
;;
--commit-filter)
- filter_commit="$OPTARG"
+ filter_commit='SOURCE_FUNCTIONS=1 . "$this_script";'" $OPTARG"
;;
--tag-name-filter)
filter_tag_name="$OPTARG"
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index bc6e2dd..c79853d 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -159,4 +159,14 @@ test_expect_success 'barf on invalid name' '
! git filter-branch -f HEAD^
'
+test_expect_success '"map" works in commit filter' '
+ git filter-branch -f --commit-filter "\
+ parent=\$(git rev-parse \$GIT_COMMIT^) &&
+ mapped=\$(map \$parent) &&
+ actual=\$(echo \"\$@\" | sed \"s/^.*-p //\") &&
+ test \$mapped = \$actual &&
+ git commit-tree \"\$@\";" master~2..master &&
+ git rev-parse --verify master
+'
+
test_done
--
1.5.3.rc7.18.gc9b59
^ permalink raw reply related
* [PATCH 2/2] filter-branch: introduce convenience function "skip_commit"
From: Johannes Schindelin @ 2007-08-31 19:06 UTC (permalink / raw)
To: git, gitster
With this function, a commit filter can leave out unwanted commits
(such as temporary commits). It does _not_ undo the changeset
corresponding to that commit, but it _skips_ the revision. IOW
its ancestors' tree objects remain the same.
If you like to commit early and often, but want to filter out all
intermediate commits, marked by "@@@" in the commit message, you can
now do this with
git filter-branch --commit-filter '
if git cat-file commit $GIT_COMMIT | grep '@@@' > /dev/null;
then
skip_commit "$@";
else
git commit-tree "$@";
fi' newbranch
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Same comment as for 1/2 applies here, too...
Documentation/git-filter-branch.txt | 34 +++++++++++++++++++++++++++-------
git-filter-branch.sh | 14 ++++++++++++++
t/t7003-filter-branch.sh | 8 +-------
3 files changed, 42 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 456d52b..29bb8ce 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -112,6 +112,11 @@ OPTIONS
As a special extension, the commit filter may emit multiple
commit ids; in that case, ancestors of the original commit will
have all of them as parents.
++
+You can use the 'map' convenience function in this filter, and other
+convenience functions, too. For example, calling 'skip_commit "$@"'
+will leave out the current commit (but not its changes! If you want
+that, use gitlink:git-rebase[1] instead).
--tag-name-filter <command>::
This is the filter for rewriting tag names. When passed,
@@ -209,24 +214,39 @@ To remove commits authored by "Darl McBribe" from the history:
git filter-branch --commit-filter '
if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
then
- shift;
- while [ -n "$1" ];
- do
- shift;
- echo "$1";
- shift;
- done;
+ skip_commit "$@";
else
git commit-tree "$@";
fi' HEAD
------------------------------------------------------------------------------
+Note that the changes introduced by the commits, and not reverted by
+subsequent commits, will still be in the rewritten branch. If you want
+to throw out _changes_ together with the commits, you should use the
+interactive mode of gitlink:git-rebase[1].
+
+The function 'skip_commits' is defined as follows:
+
+--------------------------
+skip_commit()
+{
+ shift;
+ while [ -n "$1" ];
+ do
+ shift;
+ map "$1";
+ shift;
+ done;
+}
+--------------------------
+
The shift magic first throws away the tree id and then the -p
parameters. Note that this handles merges properly! In case Darl
committed a merge between P1 and P2, it will be propagated properly
and all children of the merge will become merge commits with P1,P2
as their parents instead of the merge commit.
+
To restrict rewriting to only part of the history, specify a revision
range in addition to the new branch name. The new branch name will
point to the top-most revision that a 'git rev-list' of this range
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 3b041d8..a4b6577 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -23,6 +23,20 @@ map()
fi
}
+# if you run 'skip_commit "$@"' in a commit filter, it will print
+# the (mapped) parents, effectively skipping the commit.
+
+skip_commit()
+{
+ shift;
+ while [ -n "$1" ];
+ do
+ shift;
+ map "$1";
+ shift;
+ done;
+}
+
# override die(): this version puts in an extra line break, so that
# the progress is still visible
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index c79853d..e935b20 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -138,13 +138,7 @@ test_expect_success "remove a certain author's commits" '
git-filter-branch -f --commit-filter "\
if [ \"\$GIT_AUTHOR_NAME\" = \"B V Uips\" ];\
then\
- shift;\
- while [ -n \"\$1\" ];\
- do\
- shift;\
- echo \"\$1\";\
- shift;\
- done;\
+ skip_commit \"\$@\";
else\
git commit-tree \"\$@\";\
fi" removed-author &&
--
1.5.3.rc7.18.gc9b59
^ permalink raw reply related
* StGit fixes and experimental branches updated
From: Karl Hasselström @ 2007-08-31 19:12 UTC (permalink / raw)
To: git, David Kågedal, Pavel Roskin, Catalin Marinas
The "master" (experimental) branch is for test driving by interested
parties; the "fixes" branch is stuff that Catalin might want to pull.
-+-
The following changes since commit 18669b744dbc40df9ce025f3db44a28f7aba29ff:
Catalin Marinas (1):
Add the '--exclusive' option to 'uncommit'
are available in the git repository at:
git://repo.or.cz/stgit/kha.git fixes
David Kågedal (2):
Add basic test for stg status
Cleanup tree_status and use -z
Karl Hasselström (2):
Write warnings and errors to stderr if not on a terminal
Don't fail just because a subprocess wrote stuff to stderr
Pavel Roskin (2):
Use --force to overwrite python files
Fix refresh -es
Makefile | 2 +-
stgit/commands/patches.py | 2 +-
stgit/commands/refresh.py | 2 +-
stgit/git.py | 22 +++++++++++-----------
stgit/out.py | 11 +++++++++--
stgit/run.py | 5 ++++-
stgit/stack.py | 3 ++-
t/t0002-status.sh | 15 +++++++++++++++
8 files changed, 44 insertions(+), 18 deletions(-)
create mode 100755 t/t0002-status.sh
-+-
The following changes since commit f1c5519a186e6ed20a4206be093cc1b14e755984:
Pavel Roskin (1):
Fix refresh -es
are available in the git repository at:
git://repo.or.cz/stgit/kha.git master
David Kågedal (6):
Split git.merge into two functions
Leave working dir and index alone after failed (conflicting) push
Added a test case to check what happens when push finds a conflict
Simplify merge_recursive
Use the output from merge-recursive to list conflicts
Ask git about unmerged files
Karl Hasselström (11):
Compute patch appliedness from commit DAG
Test the new DAG appliedness machinery
Fix bash completion after the DAG appliedness patch
Speed up the appliedness test
Speed up the discovery of uninteresting commits
Speed up appliedness check during patch creation
Don't traverse the whole DAG when looking for uninteresting commits
Find uninteresting commits faster for special cases
Optimize uninterestingness checks for rebase
Better error message if merge fails
Merge branch 'conflict'
contrib/stgit-completion.bash | 15 +-
stgit/commands/commit.py | 8 +-
stgit/commands/common.py | 8 +-
stgit/commands/float.py | 2 +-
stgit/commands/imprt.py | 2 +-
stgit/commands/pick.py | 2 +-
stgit/commands/refresh.py | 2 +-
stgit/commands/sync.py | 2 +-
stgit/git.py | 74 ++++--
stgit/stack.py | 574 +++++++++++++++++++++++++++++++++--------
t/t1203-push-conflict.sh | 70 +++++
t/t3000-git-interop.sh | 60 +++++
t/t4000-upgrade.sh | 6 +
13 files changed, 668 insertions(+), 157 deletions(-)
create mode 100755 t/t1203-push-conflict.sh
create mode 100755 t/t3000-git-interop.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: introduce convenience function "skip_commit"
From: Karl Hasselström @ 2007-08-31 19:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0708312005420.28586@racer.site>
On 2007-08-31 20:06:27 +0100, Johannes Schindelin wrote:
> It does _not_ undo the changeset corresponding to that commit, but
> it _skips_ the revision. IOW its ancestors' tree objects remain the
> same.
While this is true too, I'm guessing you intended to say that its
_descendants'_ tree objects remain the same. Right?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Add commands that git-gc runs underneath
From: David Kastrup @ 2007-08-31 19:25 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Johannes Schindelin, Jari Aalto, git
In-Reply-To: <46D7E058.9050001@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>> Andreas Ericsson <ae@op5.se> writes:
>>
>>> When gc was a shell-script, it was fairly easy to find out the command-
>>> sequence...
>>
>> Maybe referring more advanced/curious users to contrib/examples/
>> directory is a good idea, but not necessarily from manpages of
>> the commands that have been rewritten in C.
>>
>> I think contrib/examples/ needs a README file that effectively
>> say "these are the last versions of shell script implementation
>> of the commands before they were rewritten in C. New features
>> may have been added to the built-in ones but these example
>> scripts are not kept up to date. They are here to serve as
>> examples to show you how you would pipeline the plumbing level
>> commands."
>>
>
> Sensible, and also avoids the possible bitrot problem with the
> man-page should there be additional actions added to standard
> git-gc operations.
Let's just make all manual pages empty, and then we have solved all
manual page bitrot problems in one fell swoop.
Really: I don't see how this helps at all. If I am interested in
seeing what operations git-gc performs, I am not interested in some
historical script's behavior.
Hiding that information into contrib/examples and telling people that
it may be wrong, anyway, is not really helpful as a way of documenting
git-gc's behavior.
Of _course_, _any_ useful documentation will have a "possible bitrot
problem with the man-page" whenever code is changed. The solution is
not to make the manual pages as useless as possible so that nothing
can be subject to bitrot. The solution is to update the information.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [StGit PATCH] Let "stg status" ignore empty directories
From: Karl Hasselström @ 2007-08-31 19:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
This was a really simple fix: just pass the right flag to
git-ls-files. Since the output has a trailing \0, split() gives us an
empty string at the end of the list that we have to throw away.
(Curiously, there was an empty string at the end before this change
too, but it disappeared somehow.)
This fixes bug 9891.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/git.py | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/stgit/git.py b/stgit/git.py
index f315b05..8857209 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -181,7 +181,8 @@ def tree_status(files = None, tree_id = 'HEAD', unknown = False,
# unknown files
if unknown:
- cmd = ['git-ls-files', '-z', '--others', '--directory']
+ cmd = ['git-ls-files', '-z', '--others', '--directory',
+ '--no-empty-directory']
if not noexclude:
cmd += ['--exclude=%s' % s for s in
['*.[ao]', '*.pyc', '.*', '*~', '#*', 'TAGS', 'tags']]
@@ -191,7 +192,7 @@ def tree_status(files = None, tree_id = 'HEAD', unknown = False,
if os.path.exists(fn)]
lines = GRun(*cmd).raw_output().split('\0')
- cache_files += [('?', line) for line in lines]
+ cache_files += [('?', line) for line in lines if line]
# conflicted files
conflicts = get_conflicts()
^ permalink raw reply related
* [PATCH] diff: resurrect the traditional empty "diff --git" behaviour
From: Junio C Hamano @ 2007-08-31 20:13 UTC (permalink / raw)
To: git; +Cc: Michael S. Tsirkin, Jeff King
In-Reply-To: <20070831160335.GA17761@coredump.intra.peff.net>
The "Consier running git-status" warning message we experimented
during the 1.5.3 cycle turns out to be a bad idea. It robbed
cache-dirty information from people who valued it, while still
asking users to run "update-index --refresh". It was hoped that
the new behaviour would at least have some educational value,
but not showing the cache-dirty paths like before means the user
would not even know easily which paths are cache-dirty.
This commit reinstates the traditional behaviour as the default,
but with a twist.
If you set diff.autorefreshindex configuration variable, it
squelches the empty "diff --git" output, and at the end of the
command, it automatically runs "update-index --refresh" without
even bothering the user. In other words, with the configuration
variable set, people who do not care about the cache-dirtyness
do not even have to see the warning.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Jeff King <peff@peff.net> writes:
> FWIW, I find the new message terribly ugly compared to the old behavior.
> There have been many output changes that I didn't like at first, but for
> which I held my tongue and eventually grew to like when they became more
> familiar (e.g., the 'subject' line after git-commit).
>
> But I just can't seem to find this one anything but ugly; everytime I
> see it, I involuntarily cringe. Perhaps because it really looks like an
> error message that accidentally got stuck in the diff output through
> incompetent redirection of stdout/stderr.
>
> I say this not to start a flame war (which is perhaps inevitable), but I
> just wonder if others feel the same, now that they have had a chance to
> get used to it.
Same here. This patch saw only very light testing, but I
personally think is a sane thing to do before 1.5.3 final.
builtin-diff.c | 31 ++++++++++++++++++++++++++-----
cache.h | 3 +++
diff.c | 5 +++++
3 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index 6ed7b68..4ffbbad 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -188,6 +188,30 @@ void add_head(struct rev_info *revs)
add_pending_object(revs, obj, "HEAD");
}
+static void refresh_index_quietly(void)
+{
+ struct lock_file *lock_file;
+ int fd;
+
+ lock_file = xcalloc(1, sizeof(struct lock_file));
+ fd = hold_locked_index(lock_file, 0);
+ if (fd < 0)
+ return;
+ discard_cache();
+ read_cache();
+ refresh_cache(REFRESH_QUIET|REFRESH_UNMERGED);
+ if (active_cache_changed) {
+ if (write_cache(fd, active_cache, active_nr) ||
+ close(fd) ||
+ commit_locked_index(lock_file))
+ ; /*
+ * silently ignore it -- we haven't mucked
+ * with the real index.
+ */
+ }
+ rollback_lock_file(lock_file);
+}
+
int cmd_diff(int argc, const char **argv, const char *prefix)
{
int i;
@@ -222,7 +246,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
prefix = setup_git_directory_gently(&nongit);
git_config(git_diff_ui_config);
init_revisions(&rev, prefix);
- rev.diffopt.skip_stat_unmatch = 1;
+ rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
if (!setup_diff_no_index(&rev, argc, argv, nongit, prefix))
argc = 0;
@@ -348,9 +372,6 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
if ((rev.diffopt.output_format & DIFF_FORMAT_PATCH)
&& (1 < rev.diffopt.skip_stat_unmatch))
- printf("Warning: %d path%s touched but unmodified. "
- "Consider running git-status.\n",
- rev.diffopt.skip_stat_unmatch - 1,
- rev.diffopt.skip_stat_unmatch == 2 ? "" : "s");
+ refresh_index_quietly();
return result;
}
diff --git a/cache.h b/cache.h
index c7e00e7..70abbd5 100644
--- a/cache.h
+++ b/cache.h
@@ -594,6 +594,9 @@ extern char *convert_to_git(const char *path, const char *src, unsigned long *si
extern char *convert_to_working_tree(const char *path, const char *src, unsigned long *sizep);
extern void *convert_sha1_file(const char *path, const unsigned char *sha1, unsigned int mode, enum object_type *type, unsigned long *size);
+/* diff.c */
+extern int diff_auto_refresh_index;
+
/* match-trees.c */
void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, int);
diff --git a/diff.c b/diff.c
index a7e7671..75d95da 100644
--- a/diff.c
+++ b/diff.c
@@ -19,6 +19,7 @@
static int diff_detect_rename_default;
static int diff_rename_limit_default = -1;
static int diff_use_color_default;
+int diff_auto_refresh_index;
static char diff_colors[][COLOR_MAXLEN] = {
"\033[m", /* reset */
@@ -166,6 +167,10 @@ int git_diff_ui_config(const char *var, const char *value)
diff_detect_rename_default = DIFF_DETECT_RENAME;
return 0;
}
+ if (!strcmp(var, "diff.autorefreshindex")) {
+ diff_auto_refresh_index = git_config_bool(var, value);
+ return 0;
+ }
if (!prefixcmp(var, "diff.")) {
const char *ep = strrchr(var, '.');
^ permalink raw reply related
* Re: [RFC] Change handling of RelNotes
From: Junio C Hamano @ 2007-08-31 20:25 UTC (permalink / raw)
To: Stephen Cuppett; +Cc: git
In-Reply-To: <316a20a40708310552r3d445d03h2ab44508a0608f0c@mail.gmail.com>
"Stephen Cuppett" <cuppett@gmail.com> writes:
> Sorry, I didn't mean to imply a demand on anybody, or mandate anybody
> change their workflow...
I have to admit that your "I propose" phrase did raise my
eyebrow, but it's not a big deal. I've grown thicker skins ;-)
As a general principle, I agree it is a good idea to keep
git.git easily accessible by people on different platforms and
environments. After all, you would need to get git.git in order
to obtain newer repository features, so there is a chicken and
egg problem involved that is more severe than other projects.
That is exactly the reason why I do not use subprojects to bind
gitk and git-gui into git.git. It needs to wait until everybody
has 1.5.2 or newer --- otherwise peole cannot clone or fetch
from git.git to get the feature that allows such a fetch to
begin with.
It would have been a different issue if the build procedure
depended on having a tracked symlink foo.h pointing at cache.h
and some source file included foo.h. You cannot build such a
thing on a filesystem without symbolic links. But the RelNotes
symlink is there for people to easily find the notes for the
latest to be released, and that symlink appears as a text file
that records the name of the Documentation file in a checkout
with "core.symlinks = false"; I do not think it is such a big
show stopper, even for people on a filesystem without symbolic
links.
^ permalink raw reply
* Re: [PATCH] diff: resurrect the traditional empty "diff --git" behaviour
From: Jeff King @ 2007-08-31 20:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael S. Tsirkin
In-Reply-To: <7vtzqfzcll.fsf_-_@gitster.siamese.dyndns.org>
On Fri, Aug 31, 2007 at 01:13:42PM -0700, Junio C Hamano wrote:
> If you set diff.autorefreshindex configuration variable, it
> squelches the empty "diff --git" output, and at the end of the
> command, it automatically runs "update-index --refresh" without
> even bothering the user. In other words, with the configuration
> variable set, people who do not care about the cache-dirtyness
> do not even have to see the warning.
Nice. This is much more sane behavior, IMHO, and I think it should make
everyone happy.
> Same here. This patch saw only very light testing, but I
> personally think is a sane thing to do before 1.5.3 final.
Passes my light testing as well, but I have a feeling we just tested the
same things...;)
One question on the implementation (and remember that I am somewhat
ignorant of the structure of this part of the code, so the answer may be
"it's too ugly"): is there a good reason to refresh _after_ the diff? It
seems like when we are looking through the working tree and index the
first time, we notice that the stat information doesn't match; why can't
we update it then? That would save an extra working tree traversal.
-Peff
^ permalink raw reply
* Re: Perl warning in git-svn (git v1.5.3-rc7-16-ge340d7d)
From: Junio C Hamano @ 2007-08-31 20:50 UTC (permalink / raw)
To: Eric Wong; +Cc: Robert Newson, git
In-Reply-To: <20070831152153.GA30745@muzzle>
Eric Wong <normalperson@yhbt.net> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Curious. I wonder how can it trigger.
>>
>> Presimably, that while (<$fh>) loop is reading from git-log, and
>> the first line would look like "commit [0-9a-f]{40}" and will
>> set $hash, do "next". Which means the variable should have been
>> initialized by the time the part that complains about string eq
>> (which I think is "if ($c && $c eq $hash)" comparison) is
>> reached.
>
> This could be a sign of a bigger problem.
>
> Does git-log read .git/config and that could potentially change
> its default output format? A quick scan of the docs say "no".
>
> I remember using git-rev-list in the original code because git-log was
> (is still?) considered porcelain and less suitable for automated
> parsing...
Yes, git-log is Porcelain, and it is subject to this kind of
breakage.
I was almost going to suggest us to change "*.color = true" to
mean 'auto'. Because git can internally use pager and has a way
for the user to control enabling/disabling colors when the pager
is used, there is no _logical_ reason to enable pager when the
output is not going to a tty.
However, people from CVS/SVN background are used to type:
$ scm log | less
because they are not used to our "by default we page" setup, and
it is very understandable that they would want "*.color = true"
in their configuration honored in such a usage.
We probably should do two things to resolve this.
* Protect our scripts. When parsing from "git log" and any
other Porcelain, explicitly give --no-color.
* Educate users. Tool output, even from Porcelain, are not to
be colored or molested in any other way, when going to
anywhere other than a tty.
Say in the FAQ "if you are tempted to say *.color = true,
stop. Learn not to type the extra '| less' and let the
internal pager take care of paging for you and you will be
much happier".
Additionally we could do the following, but if we do the above
two properly, there should be no need to:
* Declare "*.color = true" will mean "*.color = auto" in the
next version, now.
* Actually switch "*.color = true" to mean "*.color = auto"
in the next version (not 1.5.3 but the one after that).
* Perhaps introduce "*.color = always" at the same time we do
the above switch, but I think that has the same issue as the
current "true" has, so I doubt this step is needed.
^ permalink raw reply
* Re: [PATCH] diff: resurrect the traditional empty "diff --git" behaviour
From: Johannes Schindelin @ 2007-08-31 20:57 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Michael S. Tsirkin
In-Reply-To: <20070831203250.GA19340@coredump.intra.peff.net>
Hi,
On Fri, 31 Aug 2007, Jeff King wrote:
> On Fri, Aug 31, 2007 at 01:13:42PM -0700, Junio C Hamano wrote:
>
> > If you set diff.autorefreshindex configuration variable, it
> > squelches the empty "diff --git" output, and at the end of the
> > command, it automatically runs "update-index --refresh" without
> > even bothering the user. In other words, with the configuration
> > variable set, people who do not care about the cache-dirtyness
> > do not even have to see the warning.
>
> Nice. This is much more sane behavior, IMHO, and I think it should make
> everyone happy.
I could even imagine that this will eventually become the standard
behaviour.
> > Same here. This patch saw only very light testing, but I
> > personally think is a sane thing to do before 1.5.3 final.
>
> Passes my light testing as well, but I have a feeling we just tested the
> same things...;)
>
> One question on the implementation (and remember that I am somewhat
> ignorant of the structure of this part of the code, so the answer may be
> "it's too ugly"): is there a good reason to refresh _after_ the diff?
We do not need to do it always. After the diff, we know if the index
needs refreshing. Before, we don't.
> It seems like when we are looking through the working tree and index the
> first time, we notice that the stat information doesn't match; why can't
> we update it then? That would save an extra working tree traversal.
But that would be intrusive in the diff machinery IMHO. It should stay as
read-only as possible.
BTW I was a little concerned that the locking would fail in a read-only
setup, and that git would die(), but that has been taken care of, so I
have no objections left.
Thanks, Junio.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] filter-branch: provide the convenience functions also for commit filters
From: Junio C Hamano @ 2007-08-31 20:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0708312005070.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Obviously, I think that these two changes are simple enough to be
> included even this late in the game for 1.5.3. But I understand
> completely when people shout at me: "What exactly does deep
> feature freeze mean to you *knocks on Dscho's head*?"
My response to those people who might shout is that this is
merely a step to complete a _new_ program that was not in _any_
released version to make it feature complete. You do not have
to even pretend that filter-branch did not exist before -- it
actually didn't. The new part might be buggier than other
parts, but that's the same way as any other software development
process. If the new 'map' does not work as advertised there is
always 1.5.3.1.
Thanks.
^ permalink raw reply
* git svn dcommit not checking if up-to-date?
From: Johannes Schindelin @ 2007-08-31 21:04 UTC (permalink / raw)
To: Eric Wong; +Cc: git
Hi Eric,
harningt just asked about known issues of git-svn on IRC, and I remembered
that I had an issue: Accidentally, I forgot to "git svn fetch" before "git
svn dcommit"ing, and unfortunately, a colleague had just checked in a
change, which got undone by my dcommit.
Is this a known issue, has it been fixed, am I a bad pilot?
Ciao,
Dscho
P.S.: harningt promised to get his hands dirty, but I just realised that
the issue could be fixed since long ago...
^ permalink raw reply
* Re: [PATCH] Test for windows format absolute paths on cygwin too
From: Robin Rosenberg @ 2007-08-31 21:07 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <46D7DFE0.6040606@eudaptics.com>
fredag 31 augusti 2007 skrev Johannes Sixt:
> Robin Rosenberg schrieb:
> > ---
> >
> > Requires cherry-picking 6397c3119ecaa258b5185315c64062bec29bcd86
>
> ... which you find in mingw.git.
>
> However, that commit is not signed-off for a reason: It is going to be
> rewritten mostly because it doesn't yet use the is_absolute_path() from
> git-compat-util.h.
Ah, yes. It can probably wait. I needed this for the Eclipse Git plugin to work
nicely wth shared cloned repos under cygwin. With full clones there is no such
problem. Before the patch I created two references, one for cygwin and one
for EGIT, but cygwin was very noisy with that workaround and git-gui/gitk didn't
work reliably when they did work at all.
-- robin
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: introduce convenience function "skip_commit"
From: Johannes Schindelin @ 2007-08-31 21:05 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, gitster
In-Reply-To: <20070831191921.GB2151@diana.vm.bytemark.co.uk>
Hi,
On Fri, 31 Aug 2007, Karl Hasselstr?m wrote:
> On 2007-08-31 20:06:27 +0100, Johannes Schindelin wrote:
>
> > It does _not_ undo the changeset corresponding to that commit, but
> > it _skips_ the revision. IOW its ancestors' tree objects remain the
> > same.
>
> While this is true too, I'm guessing you intended to say that its
> _descendants'_ tree objects remain the same. Right?
Right. So how about:
IOW no tree objects are changed by this.
Hmm?
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox