* [PATCH] Handle format.subjectprefix for every command which accepts --pretty
From: Alex Riesen @ 2007-07-04 10:42 UTC (permalink / raw)
To: Adam Roben; +Cc: git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 282 bytes --]
Because the --pretty can be given as --pretty=email which historically produced
mails with patches. IOW, exactly what git-format-patch does.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-log.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
[-- Attachment #2: 0002-Handle-format.subjectprefix-for-every-command-which.txt --]
[-- Type: text/plain, Size: 2286 bytes --]
From 3c8b524c775a96eb0e9b638e3c0b194d8743594a Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa@limbo.localdomain>
Date: Wed, 4 Jul 2007 12:37:27 +0200
Subject: [PATCH] Handle format.subjectprefix for every command which accepts --pretty
Because the --pretty can be given as --pretty=email which historically produced
mails with patches. IOW, exactly what git-format-patch does.
---
builtin-log.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 5dc2c1c..13bae31 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -16,6 +16,7 @@
#include "refs.h"
static int default_show_root = 1;
+static const char *fmt_patch_subject_prefix = "PATCH";
/* this is in builtin-diff.c */
void add_head(struct rev_info *revs);
@@ -55,6 +56,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
rev->commit_format = CMIT_FMT_DEFAULT;
rev->verbose_header = 1;
rev->show_root_diff = default_show_root;
+ rev->subject_prefix = fmt_patch_subject_prefix;
argc = setup_revisions(argc, argv, rev, "HEAD");
if (rev->diffopt.pickaxe || rev->diffopt.filter)
rev->always_show_header = 0;
@@ -94,6 +96,12 @@ static int cmd_log_walk(struct rev_info *rev)
static int git_log_config(const char *var, const char *value)
{
+ if (!strcmp(var, "format.subjectprefix")) {
+ if (!value)
+ die("format.subjectprefix without value");
+ fmt_patch_subject_prefix = xstrdup(value);
+ return 0;
+ }
if (!strcmp(var, "log.showroot")) {
default_show_root = git_config_bool(var, value);
return 0;
@@ -265,7 +273,6 @@ static int istitlechar(char c)
static char *extra_headers = NULL;
static int extra_headers_size = 0;
-static const char *fmt_patch_subject_prefix = "PATCH";
static const char *fmt_patch_suffix = ".patch";
static int git_format_config(const char *var, const char *value)
@@ -291,12 +298,6 @@ static int git_format_config(const char *var, const char *value)
if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
return 0;
}
- if (!strcmp(var, "format.subjectprefix")) {
- if (!value)
- die("format.subjectprefix without value");
- fmt_patch_subject_prefix = xstrdup(value);
- return 0;
- }
return git_log_config(var, value);
}
--
1.5.2.2.669.gad316
^ permalink raw reply related
* Re: [PATCH] gitk: fix for "gitk <ambiguous-name> --"
From: Paul Mackerras @ 2007-07-04 10:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Uwe Kleine-K?nig, git
In-Reply-To: <Pine.LNX.4.64.0707032353330.4071@racer.site>
Johannes Schindelin writes:
> If you have an ambiguous ref, i.e. a file in the working directory bears
> the same name, you have to use "--" at the end to disambiguate ref from
> file. This works with "git rev-list". Make it work with gitk, too.
This means that if you do "gitk rev -- file" we will end up with two
"--" in the git rev-list command that gitk does. I think we actually
want the patch below.
Junio: there seems to be an inconsistency between git rev-list and git
rev-parse here. If a name is both a filename and a ref, git rev-list
will give a fatal error but git rev-parse will take it as a ref.
Paul.
diff --git a/gitk b/gitk
index d509145..502a01a 100755
--- a/gitk
+++ b/gitk
@@ -87,10 +87,7 @@ proc start_rev_list {view} {
set startmsecs [clock clicks -milliseconds]
set commitidx($view) 0
- set args $viewargs($view)
- if {$viewfiles($view) ne {}} {
- set args [concat $args "--" $viewfiles($view)]
- }
+ set args [concat $viewargs($view) "--" $viewfiles($view)]
set order "--topo-order"
if {$datemode} {
set order "--date-order"
^ permalink raw reply related
* Re: [PATCH] filter-branch documentation: some more touch-ups.
From: Johannes Schindelin @ 2007-07-04 10:58 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster, Frank Lichtenheld, j.sixt
In-Reply-To: <1183534367401-git-send-email-johannes.sixt@telecom.at>
Hi,
On Wed, 4 Jul 2007, Johannes Sixt wrote:
> - The map function used to fail, but no longer does (since 3520e1e8687.)
> - Fix the "edge-graft" example.
> - Show the same using .git/info/grafts.
>
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
>
> I think that "edge-graft" makes more sense than "etch-graft".
> Native speakers, please?
I looked at dict.leo.org, and it does not know either version. Maybe it is
just "graft"?
Except for that,
Acked-by: Johannes E. Schindelin <johannes.schindelin@gmx.de>
> I tried the example, and its quoting was incorrect. The reason is that
> the shell removes the single quotes even if they are in the middle of
> a word; so they didn't end up in the eval'd script and made sed barf.
Thanks for sanity checking. It looked so obviously correct to me that I
did not bother checking, but your are correct, they were broken.
Unfortunately, I even would have missed it writing a test case, because
that need an extra level of quoting!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] filter-branch: Avoid an error message in the map function.
From: Johannes Schindelin @ 2007-07-04 11:08 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git, j.sixt
In-Reply-To: <11835356473029-git-send-email-johannes.sixt@telecom.at>
Hi,
On Wed, 4 Jul 2007, Johannes Sixt wrote:
> - test -r "$workdir/../map/$1" || echo "$1"
> - cat "$workdir/../map/$1"
> + test -r "$workdir/../map/$1" &&
> + cat "$workdir/../map/$1" ||
> + echo "$1"
I think this does not do what you want. If I read it correctly, it will
not do anything if $workdir/../map/$1 is not readable. I think you need
this:
(test -r "$workdir/../map/$1" &&
cat "$workdir/../map/$1") ||
echo "$1"
But that is a little too cute, so I personally would prefer an
if-then-else-fi, because that is the idea of that code snippet.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] filter-branch: added missing warn function
From: Johannes Schindelin @ 2007-07-04 11:21 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11835381843502-git-send-email-prohaska@zib.de>
Hi,
On Wed, 4 Jul 2007, Steffen Prohaska wrote:
> --tag-name-filter may have failed before because
> warn is used for reporting but was not available.
Ooops. Thanks.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Document git-filter-branch
From: Frank Lichtenheld @ 2007-07-04 11:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707040004200.4071@racer.site>
On Wed, Jul 04, 2007 at 12:17:05AM +0100, Johannes Schindelin wrote:
> Hi,
>
> [if you comment on just a small portion of the text, could you please
> quote only that? Thank you]
>
> On Wed, 4 Jul 2007, Frank Lichtenheld wrote:
>
> > General note: All the stuff in all uppercase should probably also
> > have some asciidoc emphasis.
>
> I do not understand. I grepped through all the docs for uppercase words
> emphasized in any way, and could not find one.
True. On the other hand it is used at least in the case of WARNING as
a means of emphasis and this should be reflected in the end result
as markup. So I still suggest changing it to *WARNING* or even
*Warning* if you don't want to double the emphasis.
> > On Tue, Jul 03, 2007 at 05:47:44PM +0100, Johannes Schindelin wrote:
> > > +the id of the commit being rewritten. The author/committer environment
> > > +variables are set before the first filter is run.
> >
> > Maybe give the actual names of the environment variables here?
>
> If you think so:
>
> Also, GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE,
> GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, and GIT_COMMITTER_DATE is
> set according to the current commit.
"are" set. And yeah, it doesn't look pretty. I still prefer having the
list somewhere in the text, though.
> > > + Only regard the history, as seen by the given subdirectory. The
> > ^^^
> > Does this comma belong there?
>
> This is my bad English. What I meant was this:
>
> Only ever look at the history, which touches the given
> subdirectory. The result will contain that directory as its
> project root.
I'm still not sure there should be a comma in this sentence, but my
English grammar is a bit rusty.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH 1/2] Remove obsolete commit-walkers
From: Johannes Schindelin @ 2007-07-04 11:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bill Lear, Daniel Barkalow, git
In-Reply-To: <7vsl84lpo3.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 3 Jul 2007, Junio C Hamano wrote:
> Bill Lear <rael@zopyra.com> writes:
>
> > On Monday, July 2, 2007 at 23:22:05 (-0700) Junio C Hamano writes:
> >>I'll apply this after 1.5.3. In the meantime, I'll do this for 1.5.3.
> >>
> >>diff --git a/Documentation/git-local-fetch.txt b/Documentation/git-local-fetch.txt
> >>index 19b5f88..141b767 100644
> >>--- a/Documentation/git-local-fetch.txt
> >>+++ b/Documentation/git-local-fetch.txt
> >>@@ -14,6 +14,8 @@ SYNOPSIS
> >>
> >> DESCRIPTION
> >> -----------
> >>+THIS COMMAND IS DEPRECATED.
> >>...
> >
> > If a deprecated command has a replacement, the deprecation notice
> > should point the user to that.
>
> Actually these fetch backend shouldn't even be needed by the end
> users. "git fetch" simply does not drive them these days.
You forget that this backend is a plumbing component, which might well be
used by other porcelains. IIRC cogito uses it, optionally.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] filter-branch: Avoid an error message in the map function.
From: Johannes Sixt @ 2007-07-04 11:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, gitster, git
In-Reply-To: <Pine.LNX.4.64.0707041205250.4071@racer.site>
Johannes Schindelin wrote:
>
> Hi,
>
> On Wed, 4 Jul 2007, Johannes Sixt wrote:
>
> > - test -r "$workdir/../map/$1" || echo "$1"
> > - cat "$workdir/../map/$1"
> > + test -r "$workdir/../map/$1" &&
> > + cat "$workdir/../map/$1" ||
> > + echo "$1"
>
> I think this does not do what you want. If I read it correctly, it will
> not do anything if $workdir/../map/$1 is not readable. I think you need
> this:
>
> (test -r "$workdir/../map/$1" &&
> cat "$workdir/../map/$1") ||
> echo "$1"
>
> But that is a little too cute, so I personally would prefer an
> if-then-else-fi, because that is the idea of that code snippet.
It does do what I think it should do. I tested it. Your elaborate
version is not required. The reason is that in the shell && and || have
equal precedence; if there is ... && cmd ... then cmd is run if the most
recent result is success, and if there is ... || cmd ... then cmd is run
if the most recent result is failure; in both cases cmd is otherwise
skipped and does not count as "most recent result".
-- Hannes
^ permalink raw reply
* Re: [PATCH] filter-branch: Avoid an error message in the map function.
From: Johannes Schindelin @ 2007-07-04 11:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Sixt, gitster, git
In-Reply-To: <468B8852.CB36968@eudaptics.com>
Hi,
On Wed, 4 Jul 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
> >
> > On Wed, 4 Jul 2007, Johannes Sixt wrote:
> >
> > > - test -r "$workdir/../map/$1" || echo "$1"
> > > - cat "$workdir/../map/$1"
> > > + test -r "$workdir/../map/$1" &&
> > > + cat "$workdir/../map/$1" ||
> > > + echo "$1"
> >
> > I think this does not do what you want. If I read it correctly, it will
> > not do anything if $workdir/../map/$1 is not readable. I think you need
> > this:
> >
> > (test -r "$workdir/../map/$1" &&
> > cat "$workdir/../map/$1") ||
> > echo "$1"
> >
> > But that is a little too cute, so I personally would prefer an
> > if-then-else-fi, because that is the idea of that code snippet.
>
> It does do what I think it should do. I tested it.
Okay. But take me as an example of an average programmer. I got confused.
Therefore I would greatly appreciate it, if it were written with
if-then-else-fi, because I get less confused then.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] git-init: set core.worktree if GIT_WORK_TREE is specified
From: Johannes Schindelin @ 2007-07-04 11:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Matthias Lederhofer, Linus Torvalds, git
In-Reply-To: <468B793D.53661D60@eudaptics.com>
Hi,
On Wed, 4 Jul 2007, Johannes Sixt wrote:
> Matthias Lederhofer wrote:
> >
> > > + if (!getcwd(cwd, sizeof(cwd)) || cwd[0] != '/')
> > > + die("Unable to read current working directory");
> >
> > Dscho just pointed out that this causes problems on windows. The same
> > is also in setup_git_directory_gently and was there before I touched
> > it, introduced by Linus in d288a700. What was the original reason to
> > do this? Are there implementations of getcwd which return a relative
> > path?
> >
> > Additionally there are other places which need to check if some user
> > supplied path is absolute. Should we have a macro/function for that
> > which depends on the os and checks for path[0] = '/' on unix and
> > perhaps path[1] = ':' on windows?
>
> I've modified some places (that check for an absolute path) in the MinGW
> port to read (path[0] == '/' || path[1] == ':'). I don't think that it's
> necessary that you cater for this case in your code - I'll take care of
> it in the MinGW port. Of course, a hint that there is another place to
> watch out for, or even better a test case in t/, is most appreciated.
>
> I still hope to find some time to rework the MinGW port. Then such
> details will be hidden behind a is_path_absolute() function. Or maybe
> getcwd_or_die() ;)
Yes, but why not start early? is_path_absolute() makes perfect sense.
However, I was asking (out of lack of knowledge): is there any way
getcwd() does not return an absolute path?
Ciao,
Dscho
^ permalink raw reply
* Re: gitk - fails to highlight commits
From: Paul Mackerras @ 2007-07-04 12:02 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Git Mailing List
In-Reply-To: <468AED7C.5040507@verizon.net>
Mark Levedahl writes:
> Using gitk on master (281404ca1db4c921ac162f3c0 in the gitk) gitk's
> highlighting is sporadic. Running gitk from a gitk sandbox and typing
> 'gitk' into the 'Highlight Commits' box shows nothing highlighted, but
> all commits should be highlighted. After doing this, many of the commits
> revealed by scrolling down the list are highlighted, just not the ones
> visisble at the top nor the first few below.
This is fixed by a commit I just pushed out ("gitk: Fix the find and
highlight functions").
Paul.
^ permalink raw reply
* [PATCH take 2] filter-branch: Avoid an error message in the map function.
From: Johannes Sixt @ 2007-07-04 12:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, gitster, git
In-Reply-To: <Pine.LNX.4.64.0707041247520.4071@racer.site>
When the map function didn't find the rewritten commit of the passed in
original id, it printed the original id, but it still fell through to
the 'cat', which failed with an error message.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-filter-branch.sh | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 22fb5bf..5fa9b61 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -16,8 +16,12 @@
map()
{
# if it was not rewritten, take the original
- test -r "$workdir/../map/$1" || echo "$1"
- cat "$workdir/../map/$1"
+ if test -r "$workdir/../map/$1"
+ then
+ cat "$workdir/../map/$1"
+ else
+ echo "$1"
+ fi
}
# When piped a commit, output a script to set the ident of either
--
1.5.3.rc0.5.g7cd9
^ permalink raw reply related
* Re: [Qgit RFC] commit --amend
From: Marco Costalba @ 2007-07-04 12:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan Hudec, git
In-Reply-To: <7vy7hwlpo4.fsf@assigned-by-dhcp.cox.net>
On 7/4/07, Junio C Hamano <gitster@pobox.com> wrote:
> Jan Hudec <bulb@ucw.cz> writes:
>
> >> P.S: Why 'git-commit --amend -F' it's explicitely forbidden?
>
> The reasoning goes like this (here, I am not particularly trying
> to justify it, but am merely explaining the original reasoning
> and intended use case as a historical background):
>
Thanks for your explanation, of course ;-) I think you will agree that...
>
> There is no room for -F, -c, nor -m to make sense for these use
> cases, and giving them to "commit --amend" is most likely a user
> error, and diagnozed as such, because "commit --amend" is an
> end-user level Porcelain program.
>
Why an 'end-user' should _erroneusly_ write '-F' option to 'git commit
--amend' ?
An error IMHO could occur if user *forgets* to write something, not if
he intentionally writes a very specific '-F' option, in that case I
would say user knows what it writes.
And speaking about errors one can always write 'git reset HEAD^' with
worst results.
Probably you agree it's very _artificial_ try to guess what is in the
head of the user and what is not, especially if this guess is made by
a tool.
So I would dare to say this could be a good occasion to remove that
illusory and obscure check.
> But if a Porcelain like StGIT or Qgit would want to do that kind
> of operation for different use case than "amending", it can and
> should use plumbing commands, just like the implementation of
> "commit --amend" does, with different constraints and error
> checks.
>
I always prefer qgit to use the highest level commands as possible because:
1- Less error prone
2- Easier to implement
3- More robust to API change
4- Less easy to break by changes in git.
Having said that, from '-F' option documentation:
-F <file>::
Take the commit message from the given file. Use '-' to
read the message from the standard input.
Jan, what about to use '-' and feed message from stdin?
Indeed the full signature of run() is:
bool Git::run(SCRef runCmd, QString* runOutput, QObject* receiver, SCRef buf)
Where the last parameter 'buf' it's a string that, if not empty, is
passed to the launched program stdin.
I don't know if it is already too late, but I would suggest to stick
to git-commit if possible, I see only downsides in not doing so. But
of course who writes the code decides.
Marco
^ permalink raw reply
* [PATCH] filter-branch: make output nicer
From: Johannes Schindelin @ 2007-07-04 12:45 UTC (permalink / raw)
To: git, gitster
Instead of filling the screen with progress lines, use \r so that
the progress can be seen, but warning messages are more visible.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-filter-branch.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
mode change 100644 => 100755 git-filter-branch.sh
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
old mode 100644
new mode 100755
index 22fb5bf..e320379
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -160,7 +160,7 @@ test $commits -eq 0 && die "Found nothing to rewrite"
i=0
while read commit parents; do
i=$(($i+1))
- printf "$commit ($i/$commits) "
+ printf "\rRewrite $commit ($i/$commits)"
case "$filter_subdir" in
"")
@@ -203,8 +203,8 @@ while read commit parents; do
sed -e '1,/^$/d' <../commit | \
eval "$filter_msg" | \
- sh -c "$filter_commit" "git commit-tree" $(git write-tree) $parentstr | \
- tee ../map/$commit
+ (sh -c "$filter_commit" "git commit-tree" $(git write-tree)
+ $parentstr) 2> /dev/null > ../map/$commit
done <../revs
src_head=$(tail -n 1 ../revs | sed -e 's/ .*//')
--
1.5.3.rc0.2646.g88600-dirty
^ permalink raw reply related
* [PATCH] filter-branch: make output nicer
From: Johannes Schindelin @ 2007-07-04 12:50 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707041345230.4071@racer.site>
Instead of filling the screen with progress lines, use \r so that
the progress can be seen, but warning messages are more visible.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Oops. Forgot the last output line.
git-filter-branch.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
mode change 100644 => 100755 git-filter-branch.sh
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 22fb5bf..c9a64b0
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -160,7 +160,7 @@ test $commits -eq 0 && die "Found nothing to rewrite"
i=0
while read commit parents; do
i=$(($i+1))
- printf "$commit ($i/$commits) "
+ printf "\rRewrite $commit ($i/$commits)"
case "$filter_subdir" in
"")
@@ -203,8 +203,8 @@ while read commit parents; do
sed -e '1,/^$/d' <../commit | \
eval "$filter_msg" | \
- sh -c "$filter_commit" "git commit-tree" $(git write-tree) $parentstr | \
- tee ../map/$commit
+ (sh -c "$filter_commit" "git commit-tree" $(git write-tree)
+ $parentstr) 2> /dev/null > ../map/$commit
done <../revs
src_head=$(tail -n 1 ../revs | sed -e 's/ .*//')
@@ -256,6 +256,6 @@ fi
cd ../..
rm -rf "$tempdir"
-echo "Rewritten history saved to the $dstbranch branch"
+printf "\nRewritten history saved to the $dstbranch branch\n"
exit $ret
--
1.5.3.rc0.2646.g88600-dirty
^ permalink raw reply related
* Re: [PATCH take 2] filter-branch: Avoid an error message in the map function.
From: Johannes Schindelin @ 2007-07-04 12:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Sixt, gitster, git
In-Reply-To: <468B8DB1.9A4CF1E6@eudaptics.com>
Hi,
On Wed, 4 Jul 2007, Johannes Sixt wrote:
> When the map function didn't find the rewritten commit of the passed in
> original id, it printed the original id, but it still fell through to
> the 'cat', which failed with an error message.
>
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Thanked-for-and-Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Ciao,
Dscho
^ permalink raw reply
* How to rebase after upstream was merged?
From: Johannes Sixt @ 2007-07-04 12:24 UTC (permalink / raw)
To: git
I have this history:
o--o--o--o--o <- origin
\ \
x--x--x--M--x--x <- master (HEAD)
At this point I would like to rebase to straighten the history, but it
won't let me:
$ git rebase origin
Current branch master is up to date.
However, if there were additional commits on origin, it would work as
expected, i.e. all the 'x', but not 'M', would be moved on top of
origin. The reason is that rebase checks whether the merge base of
origin and HEAD is origin, and exits early if it is.
I would like to extend the check to also check for linear history. How
can I do this most efficiently? My first try is along these lines:
test $(git rev-list origin..HEAD | wc -l) = \
$(git rev-list --no-merges origin..HEAD | wc -l)
Is there a better approach?
-- Hannes
^ permalink raw reply
* [PATCH] Fix t5516 to create test repo without hooks
From: Alex Riesen @ 2007-07-04 13:11 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]
Otherwise the hooks will be executed on cygwin and the test will fail
because of the contributed hooks.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t5516-fetch-push.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
Before someone tries to say something about Cygwin supporting
permissions on NTFS and not on FAT: it is NTFS.
The relevant output was:
* expecting success:
mk_test heads/frotz tags/frotz &&
if git push testrepo master:frotz
then
echo "Oops, should have failed"
false
else
check_push_result $the_first_commit heads/frotz tags/frotz
fi
Initialized empty Git repository in .git/
updating 'refs/heads/frotz' using 'b9c09d6cc74d3857142fb7c082dca65b88254c6d'
from 0000000000000000000000000000000000000000
to b9c09d6cc74d3857142fb7c082dca65b88254c6d
Generating pack...
Done counting 3 objects.
Deltifying 3 objects...
100% (3/3) done
Writing 3 objects...
100% (3/3) done
Total 3 (delta 0), reused 0 (delta 0)
Unpacking 3 objects...
100% (3/3) done
refs/heads/frotz: 0000000000000000000000000000000000000000 ->
b9c09d6cc74d3857142fb7c082dca65b88254c6d
updating 'refs/tags/frotz' using 'b9c09d6cc74d3857142fb7c082dca65b88254c6d'
from 0000000000000000000000000000000000000000
to b9c09d6cc74d3857142fb7c082dca65b88254c6d
Generating pack...
Done counting 0 objects.
Writing 0 objects...
Total 0 (delta 0), reused 0 (delta 0)
Unpacking 0 objects...
*** The un-annotated tag, frotz, is not allowed in this repository
*** Use 'git tag [ -a | -s ]' for tags you want to propagate.
error: hooks/update exited with error code 1
error: hook declined to update refs/tags/frotz
ng refs/tags/frotz hook declined
error: failed to push to 'testrepo'
Oops, push refs/tags/frotz failure
* FAIL 12: push with ambiguity (2)
mk_test heads/frotz tags/frotz &&
if git push testrepo master:frotz
then
echo "Oops, should have failed"
false
else
check_push_result $the_first_commit
heads/frotz tags/frotz
[-- Attachment #2: 0001-Fix-t5516-to-create-test-repo-without-hooks.txt --]
[-- Type: text/plain, Size: 769 bytes --]
From bf9370303bc6752ea2e5f815d207aca151d360d4 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed, 4 Jul 2007 14:06:04 +0200
Subject: [PATCH] Fix t5516 to create test repo without hooks
Otherwise the hooks will be executed on cygwin and the test will fail
because of the contributed hooks.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t5516-fetch-push.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index c0fa2ba..ca46aaf 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -11,7 +11,8 @@ mk_empty () {
mkdir testrepo &&
(
cd testrepo &&
- git init
+ git init &&
+ mv .git/hooks .git/hooks-disabled
)
}
--
1.5.3.rc0.759.g6c112
^ permalink raw reply related
* Re: Finally implement "git log --follow"
From: Marco Costalba @ 2007-07-04 13:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706191425240.3593@woody.linux-foundation.org>
On 6/19/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> - the commit simplification isn't done. So you cannot do "--follow"
> together with somethign that wants a contiguous history (like gitk) and
> uses "--parents".
>
> This is pretty fundamental. The commit simplification is a separate
> phase over the (non-linear!) commit space, and the "git log --follow"
> logic is really a *different* logic over the _linear_ space (namely the
> streaming "log output" space).
>
> Two totally different things, in other words. And not compatible.
>
Of course I need exactly that!
Really don't want to thrash away the nice qgit graph, also in file
histories, and at the same time I really like that '--follow' feature,
so....
I've just started to hit the wall against the scary revision.c and
friends, my goal is to find a solution (trick/hack) to get the renames
also with --parents.
First of all I have commented out:
/* Can't prune commits with rename following: the paths change.. */
// if (!revs->diffopt.follow_renames)
revs->prune_fn = try_to_simplify_commit;
So I've see that with --parents set try_to_simplify_commit() does his
job and when the processing arrives in diff_tree_sha1() it is already
pruned, so also if the check
if (opt->follow_renames && diff_might_be_rename())
is true and the following try_to_follow_renames() is called, no
alternative tree is found.
My idea, after have understood a little bit better how it works, is to
'resurrect' the pruned info before calling try_to_follow_renames().
To do this I was thinking of saving a pointer to some pruned tree
information in try_to_simplify_commit() and in case use that pointer
after in diff_tree_sha1() when needed.
Nightmares??? Perhaps, I'm just starting with this difficult piece of
code and probably (90%) I will give up before the end and very
probably (99%) all said before is just brain dead, but...anyway I have
to start from somewhere.
Marco
^ permalink raw reply
* Re: [PATCH] filter-branch: make output nicer
From: Johannes Schindelin @ 2007-07-04 13:25 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707041349330.4071@racer.site>
Hi,
On Wed, 4 Jul 2007, Johannes Schindelin wrote:
> - sh -c "$filter_commit" "git commit-tree" $(git write-tree) $parentstr | \
> - tee ../map/$commit
> + (sh -c "$filter_commit" "git commit-tree" $(git write-tree)
> + $parentstr) 2> /dev/null > ../map/$commit
Aargh! I seem to be unable to get anything right today. This should be
+ sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
+ $parentstr > ../map/$commit
Ah well. I think I play a little more with it, and resubmit the patch.
Please ignore.
Ciao,
Dscho
^ permalink raw reply
* Re: efficient way to filter several branches with common history?
From: Steffen Prohaska @ 2007-07-04 13:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <468B5C4B.26F5E90B@eudaptics.com>
On Jul 4, 2007, at 10:37 AM, Johannes Sixt wrote:
> Steffen Prohaska wrote:
>>
>> Is there an efficient way to filter several branches at once
>> through git-filter-branch? Often several branches have a lot
>> of common history. Therefore, I suspect it would be much more
>> efficient to filter them with one call to git-filter-branch.
>> For example how can I efficiently filter all origin/* branches
>> to filtered/* branches?
>
> That feature is not yet implemented.
>
> In the meantime do it this way:
>
> Make an octopus merge of the branches onto a new branch. (If you have
> more than a dozen or so, you better make a hierarchy of
> octopusses.) You
> don't need to resolve conflicts (you are not interested in the merge
> result), or use -s ours to avoid them in the first place.
> Then filter that new branch.
> Then create new refs at the rewritten commits:
>
> $ git update-ref refs/filtered/b1 $id-of-rewritten-origin/b1
> $ ...
>
> Use gitk to find the $ids-of-rewritten-origin/*
Thanks for your explanation. The following is the template I used
to build my fully automated version of what you proposed:
--- SNIP ---
echo "merging branches to be filtered ..."
git-checkout -b tmp/all origin/master
for b in origin/branchX origin/branchY [ ... more branches here ...]
do
git merge -s ours -m "merge-for-preparing-filter-branch $b" $b
done
echo "... filtering ..."
git-filter-branch \
[... your git-filter-branch filters here ...] \
filtered/all >filter-branch.log
echo "... setting heads of filtered branches."
lastp1=
git-log --pretty="format:%s %P" filtered/all |
while read t b p1 p2
do
[[ "$t" == "merge-for-preparing-filter-branch" ]] || { git
update-ref refs/heads/filtered/master $lastp1 ; break ; }
b=filtered/$(basename $b)
git update-ref refs/heads/$b $p2
lastp1=$p1
done
echo "delete tmp/all and filtered/all after checking the result"
--- SNIP ---
Steffen
^ permalink raw reply
* Re: How to rebase after upstream was merged?
From: Johannes Schindelin @ 2007-07-04 13:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <468B918E.FBCADCB9@eudaptics.com>
Hi,
On Wed, 4 Jul 2007, Johannes Sixt wrote:
> I have this history:
>
> o--o--o--o--o <- origin
> \ \
> x--x--x--M--x--x <- master (HEAD)
>
> At this point I would like to rebase to straighten the history, but it
> won't let me:
>
> $ git rebase origin
> Current branch master is up to date.
I'd do something like
$ git checkout -b tmp HEAD~3
$ git rebase origin
$ git checkout master
$ git rebase --onto tmp HEAD~2
$ git branch -d tmp
> I would like to extend the check to also check for linear history. How
> can I do this most efficiently? My first try is along these lines:
>
> test $(git rev-list origin..HEAD | wc -l) = \
> $(git rev-list --no-merges origin..HEAD | wc -l)
>
> Is there a better approach?
I usually to
test -z "$(git rev-list --parents origin..HEAD | grep " .* ")"
Hth,
Dscho
^ permalink raw reply
* gitk - error in git repo on cygwin
From: Mark Levedahl @ 2007-07-04 13:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
Beginning with commit "[66e46f37de3ed3211a8ae0e8fc09c063bc3a1e08] gitk:
Store ids in rowrangelist and idrowranges rather than row numbers", gitk
run on Cygwin encounters an error looking at the git repository. The
error occurs during startup (just run gitk on master), with error:
can't read "commitrow(0,8572)": no such element in array
can't read "commitrow(0,8572)": no such element in array
while executing
"lappend linenos $commitrow($curview,$rid)"
(procedure "rowranges" line 14)
invoked from within
"rowranges $id"
(procedure "optimize_rows" line 21)
invoked from within
"optimize_rows $rowoptim 0 [expr {$rowoptim + $nr}]"
(procedure "layoutmore" line 16)
invoked from within
"layoutmore $tlimit $allread"
(procedure "chewcommits" line 9)
invoked from within
"chewcommits 0"
("eval" body line 1)
invoked from within
"eval $script"
(procedure "dorunq" line 9)
invoked from within
"dorunq"
("after" script)
This doesn't happen on my Linux box, so this is most likely due to a tcl
feature introduced more recently than the tcl used in Cygwin (8.4.1). My
guess would be that the more recent tcl is more forgiving of an
attempted access to a non-existent element.
Mark
^ permalink raw reply
* Re: gitk - fails to highlight commits
From: Mark Levedahl @ 2007-07-04 13:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <18059.35942.150086.936853@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> This is fixed by a commit I just pushed out ("gitk: Fix the find and
> highlight functions").
>
> Paul.
>
Thanks - that fixed the problem.
Mark
^ permalink raw reply
* Re: How to rebase after upstream was merged?
From: Johannes Sixt @ 2007-07-04 13:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707041426570.4071@racer.site>
Johannes Schindelin wrote:
> [...how to check for linear history...]
> I usually to
>
> test -z "$(git rev-list --parents origin..HEAD | grep " .* ")"
Ah, that's much better.
Thanks,
-- 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