* Re: [PATCH] Allow update hooks to update refs on their own
From: Daniel Barkalow @ 2007-11-28 3:25 UTC (permalink / raw)
To: Steven Grimm; +Cc: Junio C Hamano, git
In-Reply-To: <49EB8C6F-8100-48C1-BB2D-A8F6023BACAD@midwinter.com>
On Tue, 27 Nov 2007, Steven Grimm wrote:
> On Nov 27, 2007, at 5:19 PM, Junio C Hamano wrote:
>
> >How does this interact with the "pretend to have fetched back
> >immediately" supported by modern git-push?
>
>
> That continues to fire, but it updates the local tracking ref to point to the
> SHA1 that was pushed, which isn't the actual remote ref. So you have to do a
> real fetch to get the local tracking ref pointed to the right place. In other
> words, that feature doesn't do any good in this context, but it doesn't really
> hurt anything either.
>
> It would of course be better if git-push could notice that it needs to do an
> actual fetch. I think it'd be sufficient to transmit the final remote ref SHA1
> back to git-push, and if it doesn't match what was pushed, that's a sign that
> a fetch is needed. But that change wouldn't be mutually exclusive with this
> patch, I believe.
Couldn't you do this with a status message? ("ok <refname> changed by
hook" or something.)
I disagree that the feature doesn't do any good; it records that the state
of the remote is at least as new as the local state, so you can tell
without a network connection that you don't have any local changes you
haven't sent off.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Jon Smirl @ 2007-11-28 2:59 UTC (permalink / raw)
To: Karl Hasselström, Catalin Marinas; +Cc: Git Mailing List
In-Reply-To: <7vr6ibb3x7.fsf@gitster.siamese.dyndns.org>
On 11/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
> > Can we add a check in "git rebase" so that it will refuse to run if
> > stg is active?
>
> The pre-rebase hook has been there since early Feb 2006.
Karl, Catalin, can stgit install a pre-rebase hook and disable 'git
rebase' when stg is active on the branch? This would keep me from
destroying my patch stack when my fingers get ahead of me. Might be
good to disable anything else that can cause damage too.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Rollback of git commands
From: David Symonds @ 2007-11-28 1:57 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711271749q1b96bfe9i60e43619c89234b9@mail.gmail.com>
On Nov 28, 2007 12:49 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> Rollback is too strong of name for this. Checkpoints would be better.
> The idea is to record the total system state at convenient moments and
> then allow moving back to the checkpointed state. The object store
> supports this, but the rest of the state in .git/* isn't being
> recorded.
rsync -a .git /somewhere/safe
I fear that what you ask becomes a chicken-and-egg scenario: where/how
is this checkpointing information going to be stored? If it's tightly
integrated with Git, what happens when you want to roll-back a
checkpoint-restore?
Dave.
^ permalink raw reply
* Re: Rollback of git commands
From: Jon Smirl @ 2007-11-28 1:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <9e4733910711271733r6f280618pbb14095aebba3309@mail.gmail.com>
Rollback is too strong of name for this. Checkpoints would be better.
The idea is to record the total system state at convenient moments and
then allow moving back to the checkpointed state. The object store
supports this, but the rest of the state in .git/* isn't being
recorded.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: StGit hooks
From: Andreas Ericsson @ 2007-11-28 11:44 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20071128101718.GA13940@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
>
> Also, if StGit is to set up hooks automatically (commit hooks,
> pre-rebase hooks, whatever), it'd be nice to not have to worry about
> overwriting any existing hooks the user might have. But git currently
> allows only one hook script per hook, right?
>
Yes, but you can obviously call any number of scripts and programs
from within the hook that git executes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: QGit: Shrink used memory with custom git log format
From: Johannes Schindelin @ 2007-11-28 12:01 UTC (permalink / raw)
To: Jan Hudec; +Cc: Shawn O. Pearce, Marco Costalba, Git Mailing List
In-Reply-To: <20071127191915.GB9174@efreet.light.src>
Hi,
On Tue, 27 Nov 2007, Jan Hudec wrote:
> On Tue, Nov 27, 2007 at 10:48:00 +0000, Johannes Schindelin wrote:
> > On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> > > [...]
> > > Otherwise I think what you really want here is a libgit that you can
> > > link into your process and that can efficiently inflate an object
> > > on demand for you. Like the work Luiz was working on this past
> > > summer for GSOC. Lots of downsides to that current tree though...
> > > like die() kills the GUI...
> >
> > But then, die() calls die_routine, which you can override. And C++ has
> > this funny exception mechanism which just begs to be used here. The only
> > thing you need to add is a way to flush all singletons like the object
> > array.
>
> Unfortunately, exceptions won't really work. Why? Because to use
> exceptions, you need to have an exception-safe code. That is the code
> needs to free any allocated resources when it's aborted by exception.
> And git code is not exceptions safe. Given the lack of destructors in C,
> it means registering all resource allocation in some kind of pool, so
> they can be freed en masse in case of failure. Than you can also use
> longjmp for die (for C they really behave the same).
Sorry, I just assumed that you can read my mind (or alternatively remember
what I suggested a few months ago, namely to "override" xmalloc(),
xcalloc(), xrealloc() and xfree() (probably you need to create the
latter)).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-gui: Improve the application icon on Windows.
From: Johannes Schindelin @ 2007-11-28 12:08 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Shawn O. Pearce
In-Reply-To: <200711272147.22511.johannes.sixt@telecom.at>
Hi,
On Tue, 27 Nov 2007, Johannes Sixt wrote:
> On Tuesday 27 November 2007 16:40, Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 27 Nov 2007, Johannes Sixt wrote:
> > > Previusly, there was only a 16x16 image, which looked very distorted.
> > > Here we add a 32x32 version, and also make the image sharper.
> > >
> > > Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> > > ---
> > > I'm by far not an artist, but improving the previous version
> > > was not difficult at all. ;)
> >
> > Why did you not just use the svg contained in msysGit?
>
> Because I cannot find one?
>
> $ GIT_PAGER=cat git grep -i svg 4msysgit/devel
> 4msysgit/devel:attr.c: * attributes, e.g. "*.svg merge=special-...
Sorry, it is in msysgit.git, not 4msysgit.git's
master:share/resources/gitlogo.svg.
Or in the Downloads, as Steffen already said.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Do not generate full commit log message if it not going to be used
From: Johannes Schindelin @ 2007-11-28 12:18 UTC (permalink / raw)
To: Alex Riesen
Cc: Git Mailing List, Johannes Sixt, Junio C Hamano,
Kristian Høgsberg
In-Reply-To: <20071127214425.GA3156@steel.home>
Hi,
On Tue, 27 Nov 2007, Alex Riesen wrote:
> Could not stop myself. Hopefully didn't beat anyone to it :)
> Almost all code shamelessly stolen from builtin-diff-index.c.
Then I have to wonder if it would not be a better idea to refactor the
code, so that other people do not have to steal the code again, but are
able to reuse it ;-)
> Preprocessor trickery in DIFF_OPT_* macros is disgusting, it breaks Vim
> word completion and trying to use many flags in one expression looks
> just ugly.
How does it break Vim word completion? And why should something like
DIFF_OPT_SET(&rev.diffopt, QUIET | EXIT_WITH_STATUS);
look ugly? I find it highly readable.
> + if (no_edit) {
> + static const char *argv[] = { NULL, "HEAD", NULL };
> + struct rev_info rev;
> + unsigned char sha1[40];
> + int is_initial;
> +
> + fclose(fp);
> +
> + if (!active_nr && read_cache() < 0)
> + die("Cannot read index");
> +
> + if (get_sha1("HEAD", sha1) != 0)
> + return !!active_nr;
Don't want to be anal here, but are there possibly reasons (read "possible
errors") other than an empty repo where this triggers?
> +
> + init_revisions(&rev, "");
> + rev.abbrev = 0;
> + (void)setup_revisions(2, argv, &rev, NULL);
(void)?
Besides, would this not be more elegant as
setup_revisions(0, NULL, &rev, "HEAD");
Hmm?
> + (void)run_diff_index(&rev, 1 /* cached */);
(void)?
Other than that (including my remark about refactoring that piece of
code), I like it.
Thanks,
Dscho
^ permalink raw reply
* Re: StGit hooks
From: Karl Hasselström @ 2007-11-28 12:19 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <474D5482.5020609@op5.se>
On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:
> Karl Hasselström wrote:
>
> > Also, if StGit is to set up hooks automatically (commit hooks,
> > pre-rebase hooks, whatever), it'd be nice to not have to worry
> > about overwriting any existing hooks the user might have. But git
> > currently allows only one hook script per hook, right?
>
> Yes, but you can obviously call any number of scripts and programs
> from within the hook that git executes.
That doesn't help here, however, since the user and not StGit "owns"
the "top-level" hook. StGit would have to rely on the user having
installed a specific kind of multiplexer as a hook script (e.g. one
that executes everything under .git/hooks/$hook.d/). Or it would have
to install it itself, and hope that moving any existing hook to the
subdirectory where the multiplexer looks for hooks doesn't break
anything. Both solutions are problematic.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-28 12:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shawn O. Pearce, git
In-Reply-To: <fii9ta$b2j$1@ger.gmane.org>
Hi,
On Wed, 28 Nov 2007, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
>
> >> I think this should be prefixed by fast-import patch to teach it
> >> something like "encoding N" as a subcommand of commit, so that you
> >> can feed data in a non UTF-8 encoding and get it to include the
> >> proper encoding header in the commit object it creates. That way a
> >> pipeline like the above really does create a duplicate repository,
> >> with the same commit SHA-1s, even if the commits weren't in UTF-8.
> >
> > IMHO it's not worth that hassle. People who want to use fast-import
> > usually want something fast which works, and not bother with
> > specifying encodings.
>
> Well, when I am converting some repository which uses legacy encoding
> (not utf-8), I'd like to use this git feature of specifying encoding;
> actually, to be generic, it could be any header which would be added to
> all created commit objects.
>
> Yes, I could reencode commit messages...
Right.
> P.S. One nice use of proposed (at one time) 'note' header would be to
> save revision identifier from the version control system you import (CVS
> revision number, Subversion sequential revision number, etc.).
Why not put it into the commit message? It is not information that git
uses, so it does not belong into the commit header IMO. (IIRC I made the
same point already at the time 'note' was discussed.)
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Johannes Schindelin @ 2007-11-28 12:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shawn O. Pearce, git
In-Reply-To: <fiib19$dj6$1@ger.gmane.org>
Hi,
On Wed, 28 Nov 2007, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
> >
> >> Actually I might revisit this XUL concept using an HTTP server and
> >> AJAX. I could actually link the damn HTTP server against libgit.a
> >> (Junio will hate me). If the server dies XUL can notice it and
> >> simply restart it.
> >
> > But if you can restart the HTTP server via XUL, you can start other
> > git programs directly.
> >
> > What you'd have to do is (urgh) write a wrapper via start_command()
> > which would recognize that the second process die()d.
> >
> > All in all, I think if you want to switch from Tcl/Tk to another
> > language for git-gui, for the sake of attracting more developers, it
> > might be wiser to go Java than XUL.
>
> Wont we get with the same problems as egit/jgit?
My idea was not to get the same problems, but to use jgit. After all,
Shawn made a point of separating the both.
> ----
> This is proposed set of questions for git-gui mini survey...
>
> 1. What language and what toolkit should git-gui be written in?
> (single choice)
>
> a. Tcl/Tk (current implementation)
> b. C++/Qt
> c. C/GTK+
> d. Python (native)
> e. Python/PyQt
> f. Python/PyGTK
> g. Ruby
> h. Java/Swing
> i. Java/SWT
> j. XUL+JavaScript+CSS/XULRunner
> k. other
> l. no opinion
I am pretty comfortable with a), but rather than go [b-gi-l] I would
prefer h).
> 3. Do you contribute to git-gui?
> Yes/No
Yes (sort of; not half as much as I'd like to.)
> 4. If git-gui would use other language/toolkit, would you contribute?
> Yes/No
Yes, as long as it is a language/toolkit that is available on all
platforms that I (have to) work. That pretty much excludes C# and Python
as a language.
> 5. What languages and what toolkits you are proficient with (to send
> patches)?
> (multiple choice)
>
> a. Tcl/Tk (current implementation)
> b. C++/Qt
> c. C/GTK+
> d. Python (native)
> e. Python/PyQt
> f. Python/PyGTK
> g. Ruby
> h. Java/Swing
> i. Java/SWT
> j. XUL+JavaScript+CSS/XULRunner
> k. other
> l. N/A
[abchk]
> 6. What other?
Personally, I am quite comfortable with the existing implementation, and
IMHO people dismiss contributing to git-gui too easily; Tcl is not all
that complicated, and it is not hard at all to change/imitate existing
code.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Replace misleading message during interactive rebasing
From: Johannes Schindelin @ 2007-11-28 12:41 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, Johannes Sixt, git, tsuna, mcostalba
In-Reply-To: <47D3817B-AA0D-4949-99ED-C36611604D5E@wincent.com>
Hi,
On Wed, 28 Nov 2007, Wincent Colaiuta wrote:
> @@ -352,11 +352,13 @@ static int revert_or_cherry_pick(int argc, const char
> **argv)
> }
> if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
> die ("Error wrapping up %s", defmsg);
> + help_message = getenv("_GIT_CHERRY_PICK_HELP");
> fprintf(stderr, "Automatic %s failed. "
> "After resolving the conflicts,\n"
> "mark the corrected paths with 'git add <paths>' "
> - "and commit the result.\n", me);
> - if (action == CHERRY_PICK) {
> + "and %s.\n", me,
> + help_message ? help_message : "commit the result");
> + if (action == CHERRY_PICK && !help_message) {
> fprintf(stderr, "When commiting, use the option "
> "'-c %s' to retain authorship and message.\n",
> find_unique_abbrev(commit->object.sha1,
What about Junio's remark that _GIT_CHERRY_PICK_HELP should rather replace
the _complete_ message?
You could still provide the "me" and unique_abbrev parameters, so that the
first %s in _GIT_CHERRY_PICK_HELP would be replaced by the operation, and
the second by the sha1. Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: git guidance
From: Al Boldi @ 2007-11-28 12:49 UTC (permalink / raw)
To: linux-kernel; +Cc: git
In-Reply-To: <20071127235237.GF15227@1wt.eu>
Willy Tarreau wrote:
> It should not turn into an endless thread led by people who want to
> redefine GIT's roadmap, but experience sharing helps a lot with GIT.
Well, now that you mentioned it, if there is one thing I dislike, it's for
version control to start mutilating your sources. Version Control should be
completely transparent. GIT isn't.
Thanks!
--
Al
^ permalink raw reply
* Re: [PATCH] Replace misleading message during interactive rebasing
From: Johannes Sixt @ 2007-11-28 12:53 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, Junio C Hamano, git, tsuna, mcostalba
In-Reply-To: <Pine.LNX.4.64.0711281237250.27959@racer.site>
Johannes Schindelin schrieb:
> You could still provide the "me" and unique_abbrev parameters, so that the
> first %s in _GIT_CHERRY_PICK_HELP would be replaced by the operation, and
> the second by the sha1. Hmm?
Gaah! First rule to safe programming: Don't use user input as format
strings. getenv(_GIT_CHERRY_PICK_HELP) *is* user input. In this case, the
caller knows exactly what the put into the help string, so it should do so.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Jakub Narebski @ 2007-11-28 12:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0711281221090.27959@racer.site>
Johannes Schindelin wrote:
> On Wed, 28 Nov 2007, Jakub Narebski wrote:
>> Yes, I could reencode commit messages...
>
> Right.
>
>> P.S. One nice use of proposed (at one time) 'note' header would be to
>> save revision identifier from the version control system you import (CVS
>> revision number, Subversion sequential revision number, etc.).
>
> Why not put it into the commit message? It is not information that git
> uses, so it does not belong into the commit header IMO. (IIRC I made the
> same point already at the time 'note' was discussed.)
There are no problems if communication is only in one direction,
i.e. if it is only import to git repository. If communication is
two-directional, for example importing CVS repository into git
and using git-cvsserver, or using Subversion repository with the
help of git-svn, you would want commit messages preserved exactly.
This includes not adding information about original revision id
to commit message, and not recoding commit message to other encoding.
Just a thought...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH v2] Teach 'git pull' about --rebase
From: Johannes Schindelin @ 2007-11-28 13:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v3aurcjpq.fsf@gitster.siamese.dyndns.org>
When calling 'git pull' with the '--rebase' option, it performs a
fetch + rebase instead of a fetch + pull.
This behavior is more desirable than fetch + pull when a topic branch
is ready to be submitted and needs to be update.
fetch + rebase might also be considered a better workflow with shared
repositories in any case, or for contributors to a centrally managed
repository, such as WINE's.
As a convenience, you can set the default behavior for a branch by
defining the config variable branch.<name>.rebase, which is
interpreted as a bool. This setting can be overridden on the command
line by --rebase and --no-rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 27 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > ...
> > I do not want to go into _that_ many details here, since the
> > place to look for it is git-rebase.txt. Probably I should
> > have done that in the first place.
> >
> > So how about this instead:
> >
> > \--rebase::
> > Instead of a merge, perform a rebase after fetching.
> > *NOTE:* This is a potentially _dangerous_ mode of operation.
> > It rewrites history, which does not bode well when you
> > published that history already. Do _not_ use this option
> > unless you have read gitlink:git-rebase[1] carefully.
> >
> > Hmm?
>
> Okay.
I also added documentation for the branch.<name>.rebase variable.
Documentation/config.txt | 7 +++++++
Documentation/git-pull.txt | 10 ++++++++++
git-pull.sh | 11 ++++++++++-
t/t5520-pull.sh | 22 ++++++++++++++++++++++
4 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 645514d..7bebc9a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -360,6 +360,13 @@ branch.<name>.mergeoptions::
option values containing whitespace characters are currently not
supported.
+branch.<name>.rebase::
+ When true, rebase the branch <name> on top of the fetched branch,
+ instead of merging the default branch from the default remote.
+ *NOTE*: this is a possibly dangerous operation; do *not* use
+ it unless you understand the implications (see gitlink:git-rebase[1]
+ for details).
+
clean.requireForce::
A boolean to make git-clean do nothing unless given -f
or -n. Defaults to true.
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index e1eb2c1..d4d26af 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -33,6 +33,16 @@ include::urls-remotes.txt[]
include::merge-strategies.txt[]
+\--rebase::
+ Instead of a merge, perform a rebase after fetching.
+ *NOTE:* This is a potentially _dangerous_ mode of operation.
+ It rewrites history, which does not bode well when you
+ published that history already. Do *not* use this option
+ unless you have read gitlink:git-rebase[1] carefully.
+
+\--no-rebase::
+ Override earlier \--rebase.
+
DEFAULT BEHAVIOUR
-----------------
diff --git a/git-pull.sh b/git-pull.sh
index 30fdc57..698e82b 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -17,6 +17,9 @@ test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
strategy_args= no_summary= no_commit= squash= no_ff=
+curr_branch=$(git symbolic-ref -q HEAD)
+curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
+rebase=$(git config --bool branch.$curr_branch_short.rebase)
while :
do
case "$1" in
@@ -52,6 +55,12 @@ do
esac
strategy_args="${strategy_args}-s $strategy "
;;
+ -r|--r|--re|--reb|--reba|--rebas|--rebase)
+ rebase=true
+ ;;
+ --no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
+ rebase=false
+ ;;
-h|--h|--he|--hel|--help)
usage
;;
@@ -95,7 +104,6 @@ merge_head=$(sed -e '/ not-for-merge /d' \
case "$merge_head" in
'')
- curr_branch=$(git symbolic-ref -q HEAD)
case $? in
0) ;;
1) echo >&2 "You are not currently on a branch; you must explicitly"
@@ -142,5 +150,6 @@ then
fi
merge_name=$(git fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
+test true = "$rebase" && exec git-rebase $merge_head
exec git-merge $no_summary $no_commit $squash $no_ff $strategy_args \
"$merge_name" HEAD $merge_head
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 93eaf2c..52b3a0c 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -53,4 +53,26 @@ test_expect_success 'the default remote . should not break explicit pull' '
test `cat file` = modified
'
+test_expect_success '--rebase' '
+ git branch to-rebase &&
+ echo modified again > file &&
+ git commit -m file file &&
+ git checkout to-rebase &&
+ echo new > file2 &&
+ git add file2 &&
+ git commit -m "new file" &&
+ git tag before-rebase &&
+ git pull --rebase . copy &&
+ test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
+ test new = $(git show HEAD:file2)
+'
+
+test_expect_success 'branch.to-rebase.rebase' '
+ git reset --hard before-rebase &&
+ git config branch.to-rebase.rebase 1 &&
+ git pull . copy &&
+ test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
+ test new = $(git show HEAD:file2)
+'
+
test_done
--
1.5.3.6.2064.g4e322
^ permalink raw reply related
* Re: [PATCH/RFC] "color.diff = true" is not "always" anymore.
From: Johannes Schindelin @ 2007-11-28 13:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vd4tuakzj.fsf_-_@gitster.siamese.dyndns.org>
Hi,
On Tue, 27 Nov 2007, Junio C Hamano wrote:
> * This is definitely a backward incompatible change, but I think it is
> only in a good way.
I think so, too.
Thanks,
Dscho
^ permalink raw reply
* Re: StGit hooks
From: Andreas Ericsson @ 2007-11-28 13:14 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20071128121905.GA15953@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:
>
>> Karl Hasselström wrote:
>>
>>> Also, if StGit is to set up hooks automatically (commit hooks,
>>> pre-rebase hooks, whatever), it'd be nice to not have to worry
>>> about overwriting any existing hooks the user might have. But git
>>> currently allows only one hook script per hook, right?
>> Yes, but you can obviously call any number of scripts and programs
>> from within the hook that git executes.
>
> That doesn't help here, however, since the user and not StGit "owns"
> the "top-level" hook. StGit would have to rely on the user having
> installed a specific kind of multiplexer as a hook script (e.g. one
> that executes everything under .git/hooks/$hook.d/). Or it would have
> to install it itself, and hope that moving any existing hook to the
> subdirectory where the multiplexer looks for hooks doesn't break
> anything. Both solutions are problematic.
>
The user-defined hook can be kept in the hooks directory too. It just
needs to be named in such a way that git will never have a hook named
like that. For that reason, I think it would be easiest to just agree
for the git core to never call any hooks prefixed with "stgit" or
some such. I think the odds for it happening by chance are remote, to
say the least.
---%<---%<---
#!/bin/sh
do_stgit_things
sh -c '"$GIT_DIR/hooks/pre-stgit-$action-hook" "$@"'
exit $?
---%<---%<---
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH v2] Teach 'git pull' about --rebase
From: Jonathan del Strother @ 2007-11-28 13:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711281307420.27959@racer.site>
On 28 Nov 2007, at 13:11, Johannes Schindelin wrote:
> When calling 'git pull' with the '--rebase' option, it performs a
> fetch + rebase instead of a fetch + pull.
>
> This behavior is more desirable than fetch + pull when a topic branch
> is ready to be submitted and needs to be update.
Don't you mean fetch + merge ?
^ permalink raw reply
* Re: [RFC] git-gui USer's Survey 2007
From: Sergei Organov @ 2007-11-28 13:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fiib19$dj6$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
[...]
> This is proposed set of questions for git-gui mini survey...
>
> 1. What language and what toolkit should git-gui be written in?
> (single choice)
>
> a. Tcl/Tk (current implementation)
> b. C++/Qt
> c. C/GTK+
> d. Python (native)
What's this? Tkinter? If so, it's better to be spelled "Python/Tk" here,
and probably should be removed anyway as there is no apparent reason to
re-implement current Tcl/Tk in Python/Tk.
Anyway, for Python as a language, a realistic choice of GUI seems to be
between PyGtk, PyQt, and WxPython.
--
Sergei.
^ permalink raw reply
* Re: [PATCH v2] Teach 'git pull' about --rebase
From: Jakub Narebski @ 2007-11-28 13:19 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711281307420.27959@racer.site>
Johannes Schindelin wrote:
> @@ -52,6 +55,12 @@ do
> esac
> strategy_args="${strategy_args}-s $strategy "
> ;;
> + -r|--r|--re|--reb|--reba|--rebas|--rebase)
> + rebase=true
> + ;;
> + --no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
> + rebase=false
> + ;;
> -h|--h|--he|--hel|--help)
> usage
> ;;
Hmmm... rebase doesn't use git-rev-parse --parseopt?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: StGit hooks
From: Karl Hasselström @ 2007-11-28 13:26 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <474D69A7.6020404@op5.se>
On 2007-11-28 14:14:15 +0100, Andreas Ericsson wrote:
> Karl Hasselström wrote:
>
> > On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:
> >
> > > Karl Hasselström wrote:
> > >
> > > > Also, if StGit is to set up hooks automatically (commit hooks,
> > > > pre-rebase hooks, whatever), it'd be nice to not have to worry
> > > > about overwriting any existing hooks the user might have. But
> > > > git currently allows only one hook script per hook, right?
> > >
> > > Yes, but you can obviously call any number of scripts and
> > > programs from within the hook that git executes.
> >
> > That doesn't help here, however, since the user and not StGit
> > "owns" the "top-level" hook. StGit would have to rely on the user
> > having installed a specific kind of multiplexer as a hook script
> > (e.g. one that executes everything under .git/hooks/$hook.d/). Or
> > it would have to install it itself, and hope that moving any
> > existing hook to the subdirectory where the multiplexer looks for
> > hooks doesn't break anything. Both solutions are problematic.
>
> The user-defined hook can be kept in the hooks directory too. It
> just needs to be named in such a way that git will never have a hook
> named like that. For that reason, I think it would be easiest to
> just agree for the git core to never call any hooks prefixed with
> "stgit" or some such. I think the odds for it happening by chance
> are remote, to say the least.
You've lost me. :-/
Take the pre-commit hook as an example. git will call
".git/hooks/pre-commit" when interesting stuff happens. Now StGit
wants to install its pre-commit hook in an existing repository, and
finds that there already is a file called ".git/hooks/pre-commit".
What should it do?
It could move ".git/hooks/pre-commit" to
".git/hooks/pre-commit.d/user_hook", install its own hook in
".git/hooks/pre-commit.d/stgit_hook", and install a multiplexer at
".git/hooks/pre-commit". But that makes some assumptions, e.g. that
the user's hook can handle being moved, and that the user is fine with
this.
I don't see a good way around this other than having git mandate the
multiplexing scheme.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git bug/feature request
From: Peter Karlsson @ 2007-11-28 13:30 UTC (permalink / raw)
Cc: git
In-Reply-To: <85prxvda7z.fsf@lola.goethe.zz>
David Kastrup:
> > I have learned to work around this problem by always pulling between
> > my repositories, not pulling.
> Uhm...
"...not *pushing*", obviously. Sorry :-)
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: git guidance
From: Rogan Dawes @ 2007-11-28 13:45 UTC (permalink / raw)
To: Al Boldi; +Cc: linux-kernel, git
In-Reply-To: <200711281549.02663.a1426z@gawab.com>
Al Boldi wrote:
> Willy Tarreau wrote:
>> It should not turn into an endless thread led by people who want to
>> redefine GIT's roadmap, but experience sharing helps a lot with GIT.
>
> Well, now that you mentioned it, if there is one thing I dislike, it's for
> version control to start mutilating your sources. Version Control should be
> completely transparent. GIT isn't.
>
> Thanks!
>
> --
> Al
>
Care to explain? Git is quite happy handling arbitrary binary content,
so I find it difficult to believe that it is changing your source code
in strange ways.
Rogan
^ permalink raw reply
* [PATCH] Replace instances of export VAR=VAL with VAR=VAL; export VAR
From: Johannes Schindelin @ 2007-11-28 13:57 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Junio C Hamano, Johannes Sixt, Benoit Sigoure, Git Mailing List
In-Reply-To: <1570EAD5-9F47-4105-B3DA-49CA6FA57369@wincent.com>
It might be POSIX, but there are shells that do not like the
expression 'export VAR=VAL'. To be on the safe side, rewrite them
into 'VAR=VAL' and 'export VAR'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 28 Nov 2007, Wincent Colaiuta wrote:
> I'm still a little concerned that nobody commented when I
> pointed out that export VAR=VAL is used elsewhere in Git,
> especially in git-clone.sh, which is very commonly-used
> porcelain. Is it a problem?
How's that for a comment?
git-clone.sh | 2 +-
git-filter-branch.sh | 20 ++++++++++++--------
git-quiltimport.sh | 10 ++++++----
3 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 24ad179..ecf9d89 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -229,7 +229,7 @@ cleanup() {
trap cleanup 0
mkdir -p "$dir" && D=$(cd "$dir" && pwd) || usage
test -n "$GIT_WORK_TREE" && mkdir -p "$GIT_WORK_TREE" &&
-W=$(cd "$GIT_WORK_TREE" && pwd) && export GIT_WORK_TREE="$W"
+W=$(cd "$GIT_WORK_TREE" && pwd) && GIT_WORK_TREE="$W" && export GIT_WORK_TREE
if test yes = "$bare" || test -n "$GIT_WORK_TREE"; then
GIT_DIR="$D"
else
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 19cab5a..3afc945 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -66,17 +66,17 @@ set_ident () {
h
s/^'$lid' \([^<]*\) <[^>]*> .*$/\1/
s/'\''/'\''\'\'\''/g
- s/.*/export GIT_'$uid'_NAME='\''&'\''/p
+ s/.*/GIT_'$uid'_NAME='\''&'\''\nexport GIT_'$uid'_NAME/p
g
s/^'$lid' [^<]* <\([^>]*\)> .*$/\1/
s/'\''/'\''\'\'\''/g
- s/.*/export GIT_'$uid'_EMAIL='\''&'\''/p
+ s/.*/GIT_'$uid'_EMAIL='\''&'\''\nexport GIT_'$uid'_EMAIL/p
g
s/^'$lid' [^<]* <[^>]*> \(.*\)$/\1/
s/'\''/'\''\'\'\''/g
- s/.*/export GIT_'$uid'_DATE='\''&'\''/p
+ s/.*/GIT_'$uid'_DATE='\''&'\''\nexport GIT_'$uid'_DATE/p
q
}
@@ -84,7 +84,7 @@ set_ident () {
LANG=C LC_ALL=C sed -ne "$pick_id_script"
# Ensure non-empty id name.
- echo "[ -n \"\$GIT_${uid}_NAME\" ] || export GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\""
+ echo "case \"\$GIT_${uid}_NAME\" in \"\") GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\" && export GIT_${uid}_NAME;; esac"
}
USAGE="[--env-filter <command>] [--tree-filter <command>] \
@@ -206,7 +206,8 @@ done < "$tempdir"/backup-refs
ORIG_GIT_DIR="$GIT_DIR"
ORIG_GIT_WORK_TREE="$GIT_WORK_TREE"
ORIG_GIT_INDEX_FILE="$GIT_INDEX_FILE"
-export GIT_DIR GIT_WORK_TREE=.
+GIT_WORK_TREE=.
+export GIT_DIR GIT_WORK_TREE
# These refs should be updated if their heads were rewritten
@@ -231,7 +232,8 @@ done > "$tempdir"/heads
test -s "$tempdir"/heads ||
die "Which ref do you want to rewrite?"
-export GIT_INDEX_FILE="$(pwd)/../index"
+GIT_INDEX_FILE="$(pwd)/../index"
+export GIT_INDEX_FILE
git read-tree || die "Could not seed the index"
ret=0
@@ -267,7 +269,8 @@ while read commit parents; do
git read-tree -i -m $commit:"$filter_subdir"
esac || die "Could not initialize the index"
- export GIT_COMMIT=$commit
+ GIT_COMMIT=$commit
+ export GIT_COMMIT
git cat-file commit "$commit" >../commit ||
die "Cannot read commit $commit"
@@ -401,7 +404,8 @@ if [ "$filter_tag_name" ]; then
[ -f "../map/$sha1" ] || continue
new_sha1="$(cat "../map/$sha1")"
- export GIT_COMMIT="$sha1"
+ GIT_COMMIT="$sha1"
+ export GIT_COMMIT
new_ref="$(echo "$ref" | eval "$filter_tag_name")" ||
die "tag name filter failed: $filter_tag_name"
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 6b0c4d2..233e5ea 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -77,8 +77,9 @@ for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
}
# Parse the author information
- export GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
- export GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
+ GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
+ GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
+ export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
while test -z "$GIT_AUTHOR_EMAIL" && test -z "$GIT_AUTHOR_NAME" ; do
if [ -n "$quilt_author" ] ; then
GIT_AUTHOR_NAME="$quilt_author_name";
@@ -104,8 +105,9 @@ for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
GIT_AUTHOR_EMAIL="$patch_author_email"
fi
done
- export GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' "$tmp_info")
- export SUBJECT=$(sed -ne 's/Subject: //p' "$tmp_info")
+ GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' "$tmp_info")
+ SUBJECT=$(sed -ne 's/Subject: //p' "$tmp_info")
+ export GIT_AUTHOR_DATE SUBJECT
if [ -z "$SUBJECT" ] ; then
SUBJECT=$(echo $patch_name | sed -e 's/.patch$//')
fi
--
1.5.3.6.2064.g4e322
^ permalink raw reply related
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