* Re: [PATCH 2/2] filter-branch: fail gracefully when a filter fails
From: Junio C Hamano @ 2007-07-05 16:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <Pine.LNX.4.64.0707051636240.9789@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 5 Jul 2007, Jeff King wrote:
>
>> status=`((cmd1; echo $? >&3) | cmd2) 3>&1`
>
> Cute.
>
> This is the replacement patch, then (I guess there are still some nits to
> be had, so I did not redo the proper patch yet):
> ...
> + (sed -e '1,/^$/d' <../commit |
> + (eval "$filter_msg" ||
> + die "msg filter failed: $filter_msg" 2>&3) |
> + (sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
> + $parentstr > ../map/$commit ||
> + die "commit filter failed: $filter_commit" 2>&3)) 3>&1 |
> + grep . && die
You certainly meant "grep >&2 ." at the end of that pipeline;
while I welcome people to be aware that it is possible with
esoteric shell redirection games, I personally feel this is not
worth it.
^ permalink raw reply
* Re: [PATCH] stash: end commit log with a newline
From: Junio C Hamano @ 2007-07-05 16:47 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: しらいしななこ,
Git Mailing List
In-Reply-To: <20070705115825.GA13654@informatik.uni-freiburg.de>
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> writes:
> I didn't test it yet, but it sounds good. I will apply your patch and
> work a while with it. But I think if someone adds documentation, I will
> give my Ack. :-)
>
> BTW: I prefer help over usage, but if it nanako prefers usage, why not
> both?
We could do that, I guess. Nana?
^ permalink raw reply
* Re: [PATCH] git init: activate rerere by default
From: Junio C Hamano @ 2007-07-05 16:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <81b0412b0707050610mddaf5c0w724b747fe10ed6f9@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> On 7/5/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>> We have a working implementation of rerere since long ago, and we even
>> make sure that it works as expected in a test case. It is also a very
>> useful feature, so why not turn it on for the benefit of users who are
>> not even aware of it? This patch does that.
>
> Maybe just create in template directory?
Sounds saner.
^ permalink raw reply
* Re: [PATCH 2/2] WIP per-path attribute based hunk header selection.
From: Junio C Hamano @ 2007-07-05 16:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0707051223520.9789@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 4 Jul 2007, Junio C Hamano wrote:
>
>> diff --git a/diff.c b/diff.c
>> index 552f7c0..0c7d2c6 100644
>> --- a/diff.c
>> +++ b/diff.c
>> @@ -3011,21 +3079,6 @@ void diffcore_std(struct diff_options *options)
>> if (options->quiet)
>> return;
>>
>> - /*
>> - * break/rename count similarity differently depending on
>> - * the binary-ness.
>> - */
>> - if ((options->break_opt != -1) || (options->detect_rename)) {
>> - struct diff_queue_struct *q = &diff_queued_diff;
>> - int i;
>> -
>> - for (i = 0; i < q->nr; i++) {
>> - struct diff_filepair *p = q->queue[i];
>> - p->one->is_binary = file_is_binary(p->one);
>> - p->two->is_binary = file_is_binary(p->two);
>> - }
>> - }
>> -
>> if (options->break_opt != -1)
>> diffcore_break(options->break_opt);
>> if (options->detect_rename)
>> diff --git a/diffcore-delta.c b/diffcore-delta.c
>> index a038b16..d9729e5 100644
>> --- a/diffcore-delta.c
>> +++ b/diffcore-delta.c
>> @@ -129,7 +129,7 @@ static struct spanhash_top *hash_chars(struct diff_filespec *one)
>> struct spanhash_top *hash;
>> unsigned char *buf = one->data;
>> unsigned int sz = one->size;
>> - int is_text = !one->is_binary;
>> + int is_text = !diff_filespec_is_binary(one);
>>
>> i = INITIAL_HASH_SIZE;
>> hash = xmalloc(sizeof(*hash) + sizeof(struct spanhash) * (1<<i));
>
> It is quite cute to hide this in the funcname patch...
That is why it is marked as WIP.
^ permalink raw reply
* [PATCH] fix remote.origin.url in tutorial.txt
From: Alecs King @ 2007-07-05 16:21 UTC (permalink / raw)
To: git
Bob cloned from Alice.
The origin url is actually Alice's repo.
Signed-off-by: Alecs King <alecsk@gmail.com>
---
Documentation/tutorial.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 118ff72..53403c6 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -354,7 +354,7 @@ used for pulls:
-------------------------------------
$ git config --get remote.origin.url
-/home/bob/myrepo
+/home/alice/project
-------------------------------------
(The complete configuration created by git-clone is visible using
--
1.5.3.rc0.107.g93d7e
--
Alecs King
^ permalink raw reply related
* Re: Fwd: git-svn dcommit fail
From: Steven Grimm @ 2007-07-05 16:18 UTC (permalink / raw)
To: Kees-Jan Dijkzeul; +Cc: git
In-Reply-To: <fa0b6e200707050406i831816co80ff1500dae6bf54@mail.gmail.com>
Kees-Jan Dijkzeul wrote:
> Basically, the problem is as follows: My head commit is a merge:
> $ git show HEAD
> commit e135f26dbae66f539b486646a12aa51e71c196a1
> Merge: bb8ac98... f453e1e...
>
> Both parents are svn-commits.
That seems to be a case that the current merge support in git-svn can't
handle. I'll refer you to the test I did when the merge support first
landed on the mailing list:
http://www.spinics.net/lists/git/msg33628.html
The current code seems to be aimed at using branches for local
development on the git side rather than dealing with relationships
between multiple svn branches.
I'll also point out this utility, which may be of use to you. It is not
perfect but it works.
http://www.spinics.net/lists/git/msg29119.html
-Steve
^ permalink raw reply
* [PATCH] filter-branch documentation: clarify which filters are eval'ed
From: Johannes Schindelin @ 2007-07-05 16:07 UTC (permalink / raw)
To: git, gitster
All filters, except the commit filter, are evaluated.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I tried to extract the magic of the "remove commit" example into a
function "skip_commit", since I guess it will be a common
operation. Alas, since the commit filter has to be "sh -c"ed to
get arguments, I do not see any way to use a convenience function
in there, short of sourcing a helper file. Does anybody see a
better way?
Documentation/git-filter-branch.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 219a81d..eaea82d 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -50,7 +50,8 @@ Filters
~~~~~~~
The filters are applied in the order as listed below. The <command>
-argument is always evaluated in shell using the 'eval' command.
+argument is always evaluated in shell using the 'eval' command (with the
+notable exception of the commit filter, for technical reasons).
Prior to that, the $GIT_COMMIT environment variable will be set to contain
the id of the commit being rewritten. Also, GIT_AUTHOR_NAME,
GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL,
--
1.5.3.rc0.2689.g99ca2-dirty
^ permalink raw reply related
* Re: [PATCH 2/2] filter-branch: fail gracefully when a filter fails
From: Johannes Schindelin @ 2007-07-05 15:38 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070705135824.GB5493@sigill.intra.peff.net>
Hi,
On Thu, 5 Jul 2007, Jeff King wrote:
> status=`((cmd1; echo $? >&3) | cmd2) 3>&1`
Cute.
This is the replacement patch, then (I guess there are still some nits to
be had, so I did not redo the proper patch yet):
git-filter-branch.sh | 43 ++++++++++++++++++++++++++++++++-----------
1 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
old mode 100644
new mode 100755
index 6cf67df..f08288d
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -28,6 +28,16 @@ map()
fi
}
+# override die(): this version puts in an extra line break, so that
+# the progress is still visible
+
+die()
+{
+ echo \ >&2
+ echo "$*" >&2
+ exit 1
+}
+
# When piped a commit, output a script to set the ident of either
# "author" or "committer
@@ -181,23 +191,29 @@ while read commit parents; do
export GIT_COMMIT=$commit
git cat-file commit "$commit" >../commit
- eval "$(set_ident AUTHOR <../commit)"
- eval "$(set_ident COMMITTER <../commit)"
- eval "$filter_env" < /dev/null
+ eval "$(set_ident AUTHOR <../commit)" ||
+ die "setting author failed for commit $commit"
+ eval "$(set_ident COMMITTER <../commit)" ||
+ die "setting committer failed for commit $commit"
+ eval "$filter_env" < /dev/null ||
+ die "env filter failed: $filter_env"
if [ "$filter_tree" ]; then
git checkout-index -f -u -a
# files that $commit removed are now still in the working tree;
# remove them, else they would be added again
git ls-files -z --others | xargs -0 rm -f
- eval "$filter_tree" < /dev/null
+ eval "$filter_tree" < /dev/null ||
+ die "tree filter failed: $filter_tree"
+
git diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
xargs -0 git update-index --add --replace --remove
git ls-files -z --others | \
xargs -0 git update-index --add --replace --remove
fi
- eval "$filter_index" < /dev/null
+ eval "$filter_index" < /dev/null ||
+ die "index filter failed: $filter_index"
parentstr=
for parent in $parents; do
@@ -206,13 +222,17 @@ while read commit parents; do
done
done
if [ "$filter_parent" ]; then
- parentstr="$(echo "$parentstr" | eval "$filter_parent")"
+ parentstr="$(echo "$parentstr" | eval "$filter_parent")" ||
+ die "parent filter failed: $filter_parent"
fi
- sed -e '1,/^$/d' <../commit | \
- eval "$filter_msg" | \
- sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
- $parentstr > ../map/$commit
+ (sed -e '1,/^$/d' <../commit |
+ (eval "$filter_msg" ||
+ die "msg filter failed: $filter_msg" 2>&3) |
+ (sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
+ $parentstr > ../map/$commit ||
+ die "commit filter failed: $filter_commit" 2>&3)) 3>&1 |
+ grep . && die
done <../revs
src_head=$(tail -n 1 ../revs | sed -e 's/ .*//')
@@ -249,7 +269,8 @@ if [ "$filter_tag_name" ]; then
[ -f "../map/$sha1" ] || continue
new_sha1="$(cat "../map/$sha1")"
export GIT_COMMIT="$sha1"
- new_ref="$(echo "$ref" | eval "$filter_tag_name")"
+ new_ref="$(echo "$ref" | eval "$filter_tag_name")" ||
+ die "tag name filter failed: $filter_tag_name"
echo "$ref -> $new_ref ($sha1 -> $new_sha1)"
^ permalink raw reply related
* Re: git-rm isn't the inverse action of git-add
From: David Kastrup @ 2007-07-05 14:00 UTC (permalink / raw)
To: git
In-Reply-To: <vpqd4z7q820.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> One benefit is: you don't have to use "-f" for a non-dangerous
> senario. That seems stupid, but for the plain "rm" command, the
> "-rf" is hardcoded in the fingers of many unix users, and I know
> several people having lost data by typing it a bit too mechanically
> (with a typo behind, like forgetting the "*" in "*~" ;-).
Just a few days ago, I used rm -rf * in a temporary directory. I
would now advise people against doing that without an absolute path.
The problem was that at some later point of time, some history
search/key fsckup popped that line back into the shell and executed
it.
At that time, in my home directory. This was definitely annoying,
even though the files and directories .* (and thus most configuration
data) were spared.
> I'll try writting patch for that if people agree that this is saner
> that the current behavior.
Sounds like it.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: fail gracefully when a filter fails
From: Jeff King @ 2007-07-05 13:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707041535420.4071@racer.site>
On Wed, Jul 04, 2007 at 03:36:01PM +0100, Johannes Schindelin wrote:
> It is slightly ugly that the output of msg-filter is written
> to a temporary file. But I do not know a better method to
> catch a failing msg-filter. Help?
If you mean, in general, to catch the exit code of the first part of a
pipe, you have to do something like this:
status=`((cmd1; echo $? >&3) | cmd2) 3>&1`
which is pretty ugly in itself, and if you want the stdout of cmd2, then
you have to add even more redirection. I'm not sure it's worth it.
-Peff
^ permalink raw reply
* Re: git-svnexport
From: Patrick Doyle @ 2007-07-05 13:50 UTC (permalink / raw)
To: Steve French; +Cc: git
In-Reply-To: <524f69650707031231y2ab7b9a3o7769f64b9876326@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]
On 7/3/07, Steve French <smfrench@gmail.com> wrote:
> I noticed a git-svnexport, but don't see an easy way to do the more
> common task ... export a replica (via svn) of a kernel directory whose
> master copy is in git (no changes come through svn, all changes come
> through git).
>
> The Samba team (jra and others) use svn and would like me to keep more
> uptodate the svn branch (which I sync manually now by applying the
> patches from the kernel git tree by hand) for the two cifs git trees.
> Basically I need to do something like:
>
> git log fs/cifs
> save off each of the commits which hit fs/cifs which are not in the svn tree yet
> patch and "svn checkin" each of the commits to the svn tree
>
>
> Has anyone done any scripts to --- export -- to an svn tree from part
> of a git tree?
> I don't want to go to having my svn tree as the master and import into
> git from svn.
>
If you're interested I (may) have attached a script I was using to
learn how to import a git maintained project into a subversion
maintained project. It is obviously a "play with this and try this
out" script, not a production script in any sense of the word, but it
might help point you in the direction you want to go.
The gist of the script is that I used .git/info/grafts to graft the
chain of git commits from my other project onto the most recent commit
from the svn maintained project (fetched via "git-svn clone") and then
I committed the result back to SVN. All of the cruft around that is
simply, "blow away what I tried before and start from scratch all over
again" cruft I used when I was testing the concept.
hth
--wpd
[-- Attachment #2: git-graft-test2 --]
[-- Type: application/octet-stream, Size: 1068 bytes --]
#!/bin/sh
set -e
set -x
# Blow away the test directories
rm -rf sdrgen wpd sdrgen.orig.git mypack
# Now make fresh working directories, "wpd" is the subversion repo,
# ../vid_proj/sdrgen is where I've been doing all of my work to date.
cp -a wpd.orig wpd
cp -a ../vid_proj/sdrgen sdrgen.orig.git
# Fetch the SVN repository as a GIT repository
git-svn clone file:///home/wpd/git-svn-tests/wpd/sdrgen
# Start working in the new repo
cd sdrgen
# Pull in the original git repo as a branch
git-fetch ../sdrgen.orig.git master:original
FIRST_COMMIT=`git-rev-list original | tail -1`
TOPDIR=`git-rev-parse master`
# Now, graft the first commit from the other repository onto the last
# commit of this repo
echo $FIRST_COMMIT $TOPDIR > .git/info/grafts
# Change the "master" branch to point to the head of our newly imported
# chain of commits.
git-reset --hard original
# We're done with the original branch now
git-branch -d original
# Commit all of the changes back to the SVN repository
git-svn dcommit
# We're done with the grafts file now
rm .git/info/grafts
^ permalink raw reply
* Re: git-rm isn't the inverse action of git-add
From: Matthieu Moy @ 2007-07-05 13:44 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, Yann Dirson, Christian Jaeger, git
In-Reply-To: <20070704200806.GA3991@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
>> What's wrong with the behavior of "hg rm"?
>> What's wrong with the behavior of "svn rm"?
>> What's wrong with the behavior of "bzr rm"?
>> (no, I won't do it with CVS ;-) )
>>
>> None of these commands have the problem that git-rm has.
>
> Hm. They all behave roughly the same: They unversion the file and unlink it,
> unless it is modified, in which case they unversion it and leave it
> alone.
Yes. Roughly, they'll ask you a --force flag whenever you'd risk
data-loss. bzr gives you the choice between --force and --keep (that
would be --cached in git) if the file doesn't match HEAD.
> Now git has the extra complexity that index contains also content of the
> file. But the behaviour can be easily adapted like this (HEAD = version in
> HEAD, index = version in index, tree = version in tree):
^^^^- I suppose you meant "version"
here since you don't use
"tree" after.
> - if (HEAD == index && index == version) unversion and unlink
Just to be more precise:
- if (HEAD == index && index == version) unversion and
* if (--cached is not given) unlink
* else do nothing
> - else if (HEAD == index || index == version) unversion
> - else print message and do nothing
>
> Would you consider that a sane behaviour?
To me, that's a sane behavior.
It makes a few senarios easy and safe, like this:
$ git add <whatever>
# Ooops, no, I didn't want to version this one :-(
$ git rm some-file
# Cool, I just cancelled my mistake without loosing anything ;-)
One benefit is: you don't have to use "-f" for a non-dangerous
senario. That seems stupid, but for the plain "rm" command, the "-rf"
is hardcoded in the fingers of many unix users, and I know several
people having lost data by typing it a bit too mechanically (with a
typo behind, like forgetting the "*" in "*~" ;-).
I'll try writting patch for that if people agree that this is saner
that the current behavior.
--
Matthieu
^ permalink raw reply
* Re: Embedded Linux development with GIT
From: linux @ 2007-07-05 12:31 UTC (permalink / raw)
To: svk.sweng; +Cc: git
> Is it possible then to see our 400 odd commits then in the Local
> branch on top of 2.6.17 so that we can see not only our history but
> also the history that came before? Then as Master advances we can see
> about backporting and bringing our code close enough to mainline
> kernel to actually be able to contribute back to the community and
> submit patches. Is this realistic approach. I am unsure of the GIT
> commands that I need to do this?
Yes. There are two ways to do this:
1) Use the grafts feature. You can put a line in your repository's
.git/info/grafts which lists your initial commit and the ancestors you
want it to have.
E.g. note that Linus's v2.6.17 is 427abfa28afedffadfca9dd8b067eb6d36bac53f, with
parent ce221982e0bef039d7047b0f667bb414efece5af. So you can just include
<your initial checkin> ce221982e0bef039d7047b0f667bb414efece5af
in git/info/grafts, and boom.
The advantage is that you don't have to change anything.
The disadvantge here is that this is NOT automatically propagated
by pull operations (it would be a security breach if it were), so
everyone pulling from you has to do the same thing manually.
(If you're only sending out patches, it doesn't matter as much.)
2) Rebase your changes.
Import a standard Linux kernel into the repository, and rebase your
changes from your original root import onto Linus' 2.6.17.
The advantage here is that the commit IDs will be preserved when you
share your changes, so if you have your changes pulled into the kernel
mainline, it'll be easier to merge them and for you to merge back.
The disadvantage is that everyone who has cloned from you has to manually
re-fetch once.
Basically, option 1 has less immediate pain, but has an ongoing cost.
Option 2 gets it out of the way all at once.
^ permalink raw reply
* Re: [PATCH] git init: activate rerere by default
From: Alex Riesen @ 2007-07-05 13:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707051312260.9789@racer.site>
On 7/5/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> We have a working implementation of rerere since long ago, and we even
> make sure that it works as expected in a test case. It is also a very
> useful feature, so why not turn it on for the benefit of users who are
> not even aware of it? This patch does that.
Maybe just create in template directory?
^ permalink raw reply
* [PATCH] git init: activate rerere by default
From: Johannes Schindelin @ 2007-07-05 12:16 UTC (permalink / raw)
To: git, gitster
We have a working implementation of rerere since long ago, and we even
make sure that it works as expected in a test case. It is also a very
useful feature, so why not turn it on for the benefit of users who are
not even aware of it? This patch does that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Maybe it is too late for 1.5.3? But maybe this is nice enough to
have in 1.5.3?
BTW I shamelessly put in a comment to boost my comment ration on
ohloh.net...
builtin-init-db.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 66ddaeb..aa3a01e 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -293,6 +293,9 @@ static int create_default_files(const char *git_dir, const char *git_work_tree,
if (git_work_tree)
git_config_set("core.worktree", git_work_tree);
}
+ /* activate rerere */
+ strcpy(path + len, "rr-cache");
+ safe_create_dir(path, 1);
return reinit;
}
--
1.5.3.rc0.2689.g99ca2-dirty
^ permalink raw reply related
* Re: Embedded Linux development with GIT
From: Johannes Schindelin @ 2007-07-05 12:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <468C996B.7FEFEB29@eudaptics.com>
Hi,
On Thu, 5 Jul 2007, Johannes Sixt wrote:
> Sean Kelley wrote:
> >
> > I have a situation where we have a local GIT repository that is based
> > on v2.6.17. We initially added the source tarball to an empty
> > repository and then started applying changes to it. Looking back,
> > that might not have been the best idea 400 commits later.
>
> That is possible using a graft:
>
> $ echo "$x $(git rev-parse v2.6.17^0)" >> .git/info/grafts
>
> where $x is the SHA1 of the first commit you made on top of the imported
> tarball.
Yes, this is also how I would do it.
> This way you have spliced your history with Linus's history. (This is a
> strictly _local_ matter! Every clone of your history must repeat the
> game!)
Now, here I disagree slightly. If you merge just once, subsequent merges
will be possible even without that graft.
So if you merge with some newer Linux version, all your cloners get the
benefit.
> Now, Linus will not be able to pull from your faked history because he
> doesn't know about the graft.
Except if you merge with a more recent version of Linux.
However, I doubt that such a distant (in terms of time!) merge would
appeal to Linus. I guess you have to rebase on top of Linus' version
_anyway_.
> In order to fix that, you can run git-filter-branch from current git's
> master branch to rewrite your history:
>
> $ git filter-branch new-master v2.6.17..master
>
> Read the man page of git-filter-branch, and understand the implications
> before you publish the result.
This is a way to fix your history, yes. Note that filter-branch is not
yet in an official release of Git, and so you either have to wait for
1.5.3, or you get filter-branch from git.git's "next" branch (just picking
this one script should work fine, if you have at least 1.5.1 installed).
Note that this rewrites the history, so all the disadvantages of
rebasing with pulling apply here, too.
But as stated above, I think you have to rebase eventually anyway, if you
go for inclusion in Linus' tree. In that case, the filter-branch is
unnecessary.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] stash: end commit log with a newline
From: Uwe Kleine-König @ 2007-07-05 11:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ,
Git Mailing List
In-Reply-To: <7vbqere732.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> しらいしななこ <nanako3@bluebottle.com> writes:
>
> > I am sorry to join the discussion late, but I think it is much better to let
> > the user give a short reminder message from the command line. For example,
> >
> > $ git stash add customized message to stash
> >
> > When I say "git stash list", I want to see which branch I was on when I was
> > in the middle of doing something, and what that something was. It is not
> > interesting which commit on that branch I started that change from. After
> > creating a stash without a message, and then another stash with a message, I
> > want to see:
> >
> > $ git stash list
> > stash@{0}: On master: add customized message to stash
> > stash@{1}: WIP on master: 36e5e70... Start deprecating "git-command" in favor of "git command"
>
> Hmph. I only recently got interested in "stash", so have not
> enough real-life experience to base my judgement on, but I think
> I'd agree with your reasoning.
>
> Perhaps something like this?
I didn't test it yet, but it sounds good. I will apply your patch and
work a while with it. But I think if someone adds documentation, I will
give my Ack. :-)
BTW: I prefer help over usage, but if it nanako prefers usage, why not
both?
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=1+stone%3D
^ permalink raw reply
* Re: [PATCH 2/2] diff: add custom regular expressions for function names
From: Johannes Schindelin @ 2007-07-05 11:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vwsxfe96i.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 4 Jul 2007, Junio C Hamano wrote:
> *NOTE IN BIG RED LETTERS*
>
> I do not particularly like the way multiple regexps are used in
> Johannes's patch, but I left it as-is, as that part of the
> change is orthogonal from the support to use the gitattribute
> mechanism, and the primary reason I got involved in this topic
> is to give help around the latter area.
I do not like it particularly, either. Until two days ago, that POSIX
regexps suck so much, in that they do not even have a look-ahead, let
alone a negative look-ahead. _That_ is what I wanted.
Alas, that is the first valid argument I encounter that would speak _for_
pcre. It speaks volumes that _nobody_ pointed this out before, but all
pcre fans put out bogus arguments.
> I think using multiple regexp is cute, but if we do that, it
> should allow people to pick from:
>
> public class Beer
> {
> int special;
> public static void main(String args[])
> {
> ... modified part is here ...
>
> with two regexp matches, say:
>
> /^(public|private|protectd) class (.*)/ then
> /^ +.* (\w*\(.*)$/
>
> and define the hunk_header format as something like:
>
> "\[1,2]::\[2,1]"
>
> meaning, "pick the second capture group from the match data of
> the first regexp, followed by double-colon, and pick the first
> capture group from the match data of the second regexp", to
> result in "Beer::main(String args[])". You should be able
> to pick "/package (\w+);/ then /^sub (\w+)/" in Perl code using
> the same idea.
>
> I am not married to the syntax I used in the above examples,
> though.
Is that really necessary?
But yeah, it is possible. You'd have to have some state in the struct, and
introduce yet another escape (probably in place of the first line of the
regexp), similar to
*[2,2]::[1,1]
*keep-searching-after-match 1
^ +.* (\w*\(.*)$
^(public|private|protected) class (.*)
Of course, there _has_ to be a way to handle exceptions, such as in Perl,
where you do not necessarily have a package, and thus do not want that
silly "::" in front of the rest.
But frankly, I think this is too complicated. Maybe somebody more
intelligent than me can actually come up with a sane syntax and
implementation of this, but at some point I think it is Good Enough(tm).
And IMHO it is already good enough matching just one line.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] WIP per-path attribute based hunk header selection.
From: Johannes Schindelin @ 2007-07-05 11:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vlkdve93o.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Wed, 4 Jul 2007, Junio C Hamano wrote:
> diff --git a/diff.c b/diff.c
> index 552f7c0..0c7d2c6 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -3011,21 +3079,6 @@ void diffcore_std(struct diff_options *options)
> if (options->quiet)
> return;
>
> - /*
> - * break/rename count similarity differently depending on
> - * the binary-ness.
> - */
> - if ((options->break_opt != -1) || (options->detect_rename)) {
> - struct diff_queue_struct *q = &diff_queued_diff;
> - int i;
> -
> - for (i = 0; i < q->nr; i++) {
> - struct diff_filepair *p = q->queue[i];
> - p->one->is_binary = file_is_binary(p->one);
> - p->two->is_binary = file_is_binary(p->two);
> - }
> - }
> -
> if (options->break_opt != -1)
> diffcore_break(options->break_opt);
> if (options->detect_rename)
> diff --git a/diffcore-delta.c b/diffcore-delta.c
> index a038b16..d9729e5 100644
> --- a/diffcore-delta.c
> +++ b/diffcore-delta.c
> @@ -129,7 +129,7 @@ static struct spanhash_top *hash_chars(struct diff_filespec *one)
> struct spanhash_top *hash;
> unsigned char *buf = one->data;
> unsigned int sz = one->size;
> - int is_text = !one->is_binary;
> + int is_text = !diff_filespec_is_binary(one);
>
> i = INITIAL_HASH_SIZE;
> hash = xmalloc(sizeof(*hash) + sizeof(struct spanhash) * (1<<i));
It is quite cute to hide this in the funcname patch...
Ciao,
Dscho
^ permalink raw reply
* Re: Fwd: git-svn dcommit fail
From: Kees-Jan Dijkzeul @ 2007-07-05 11:06 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wfndyow.fsf@assigned-by-dhcp.cox.net>
On 7/5/07, Junio C Hamano <gitster@pobox.com> wrote:
> Could you double check?
*Blush*. I should have caught that one myself. I'm now at commit
114fd812f78ea375ee6782d4ff0203f3ae20b076, which still exhibits the
same problem.
Basically, the problem is as follows: My head commit is a merge:
$ git show HEAD
commit e135f26dbae66f539b486646a12aa51e71c196a1
Merge: bb8ac98... f453e1e...
Both parents are svn-commits.
When I do a dry-run, I get
$ git-svn dcommit -n
diff-tree e135f26dbae66f539b486646a12aa51e71c196a1~1
e135f26dbae66f539b486646a12aa51e71c196a1
As far as I'm concerned, this is correct. This is the delta that
should be committed to the svn branch who's head is
e135f26dbae66f539b486646a12aa51e71c196a1~1 (obviously).
However, function "working_head_info" of git-svn returns the other
parent as the working head. As a result, committing the diff to svn
fails.
I've observed that the call to cmt_metadata("$d~1") (line 382 of
git-svn) does return the correct svn branch, so it would seem to me
that it makes much more sense to commit to that.
Any thoughts, tips, tricks?
Thanks!
Kees-Jan
^ permalink raw reply
* Re: [PATCH 1/2] Future-proof source for changes in xdemitconf_t
From: Johannes Schindelin @ 2007-07-05 11:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6nne949.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Wed, 4 Jul 2007, Junio C Hamano wrote:
> [jc: minimally fixed by getting rid of a new global]
Funny. This is identical to my first version of that patch ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Fwd: git-svn dcommit fail
From: Junio C Hamano @ 2007-07-05 8:47 UTC (permalink / raw)
To: Kees-Jan Dijkzeul; +Cc: git
In-Reply-To: <fa0b6e200707050128h6bc3caa4rd661c64128ac7367@mail.gmail.com>
"Kees-Jan Dijkzeul" <k.j.dijkzeul@gmail.com> writes:
> I just fetched the master branch. For me it is at commit
> d44c782bbd6b0e806e056f9e8ff8cd8e426e67a3.
You must be kiding. That was made on Jun 6, 2007, which is
ancient if not prehistoric in git timescale.
Could you double check?
^ permalink raw reply
* Fwd: git-svn dcommit fail
From: Kees-Jan Dijkzeul @ 2007-07-05 8:28 UTC (permalink / raw)
To: git
In-Reply-To: <fa0b6e200707050126m17a23de6uad4909533306eb06@mail.gmail.com>
This one should have gone to the list. Sorry, Steven, for mailing privately.
---------- Forwarded message ----------
From: Kees-Jan Dijkzeul <k.j.dijkzeul@gmail.com>
Date: Jul 5, 2007 10:26 AM
Subject: Re: git-svn dcommit fail
To: Steven Grimm <koreth@midwinter.com>
On 7/5/07, Steven Grimm <koreth@midwinter.com> wrote:
> git-svn doesn't support nonlinear history in any of the official
> releases, though there will be some support in the next release (you can
> try it out by grabbing the latest version from git.git's master branch).
I just fetched the master branch. For me it is at commit
d44c782bbd6b0e806e056f9e8ff8cd8e426e67a3.
At this point, git-svn is identical to the one in 1.5.2.3.
I've attempted to use git to merge two subversion branches, but when
dcommitting attempts to commit the correct delta to the wrong branch,
and subsequently claims that "Your file or directory is probably out
of date" (which, in a weird way, makes sense).
I'd be happy to test this support for nonlinear history, but so far,
I've been unable to locate the correct commit.
Groetjes,
Kees-Jan
^ permalink raw reply
* Re: [PATCH 2/2] diff: add custom regular expressions for function names
From: Florian Weimer @ 2007-07-05 8:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vwsxfe96i.fsf@assigned-by-dhcp.cox.net>
* Junio C. Hamano:
> I think using multiple regexp is cute, but if we do that, it
> should allow people to pick from:
>
> public class Beer
> {
> int special;
> public static void main(String args[])
> {
> ... modified part is here ...
>
> with two regexp matches, say:
>
> /^(public|private|protectd) class (.*)/ then
> /^ +.* (\w*\(.*)$/
>
> and define the hunk_header format as something like:
>
> "\[1,2]::\[2,1]"
Even that doesn't work for C++ namespaces, or nested Java classes. 8-(
If you want to do it right, you need to spawn some helper program.
^ permalink raw reply
* Re: git-svn dcommit fail
From: Steven Grimm @ 2007-07-05 7:11 UTC (permalink / raw)
To: Dongsheng Song; +Cc: Git Mailing List
In-Reply-To: <4b3406f0707040256x31f0909cie126d950c60374f1@mail.gmail.com>
Dongsheng Song wrote:
> After some merge operation,
git-svn doesn't support nonlinear history in any of the official
releases, though there will be some support in the next release (you can
try it out by grabbing the latest version from git.git's master branch).
If you don't want to run a prerelease version of git, you need to avoid
doing non-squash merges into branches that you are going to check into
an svn repository.
Squash merges (git merge --squash) work fine, though. They will be
recorded in your history as a regular commit, not a merge, so git-svn
won't be confused by them.
-Steve
^ 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