* StGit hooks
From: Karl Hasselström @ 2007-11-28 10:17 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <20071128093403.GB12977@diana.vm.bytemark.co.uk>
On 2007-11-28 10:34:03 +0100, Karl Hasselström wrote:
> It would also be convenient with a post-commit hook that turns new
> commits into patches automatically. And gives "git commit --amend"
> the semantics of "stg refresh".
Hmm, so what I'd want for this is a hook that gets called every time a
branch ref is updated (after the update), preferably with the ref name
and its old and new values as arguments (but as long as I get the ref
name, I guess I could just ask git for the sha1s?). Is there such a
hook? I poked around a bit, but couldn't find any.
For extra points, I'd like to know what operation caused the ref
update. I'd want to do different things depending on whether the user
did a "commit" or "commit --amend", for example. I could use a
heuristic, but I'd rather not if there's a way to know for sure. (Hmm.
It looks like the reflog messages could be used here. Are they stable
enough?)
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?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Wincent Colaiuta @ 2007-11-28 10:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <7v1waa7lcv.fsf@gitster.siamese.dyndns.org>
El 28/11/2007, a las 10:47, Junio C Hamano escribió:
> I think _GIT_FOO vs GIT_FOO is an important detail, not at all a
> bikeshed color, to make things consistent. "export VAR=VAL" also is a
> valid concern (you said in a separate message you only know about
> bash,
> and I later asked people if they use shells that get affected with it
> but we happily run otherwise. I personally do not think the latter
> is a
> problem, but since somebody already raised it as a potential issue, it
> gave us a good chance to hear from people on minority platforms, if
> only
> to build confidence in us to use that POSIX form.
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?
> If these details (I do not think the overridability is a minor detail,
> though) look like bikeshedding to you, that is somewhat sad. You seem
> to be very capable of producing usable code, but these details
> (consistency and flexibility) matter for longer term stability, and I
> would really want to see capable people pay attention to such details,
> especially I sometimes fail to do so myself.
I think the *key* difference between our patches was the refactoring
that you did (extracting into a separate function and at the same time
making the entire message customizable rather than just the end). I
think that's easily explained by the fact that as a new contributor I
am pretty much always going to err on the side of the most minimal
change possible (minimum number of lines, and changes kept as local as
possible), even if it isn't the best or most well-engineered one. Your
patch is more invasive, but it's better too, and I think it's more
invasive precisely because your knowledge of the codebase and your
track record gives you the confidence to make non-minimal changes when
you think they're better. With time I imagine I'll evolve away from
such defensive, minimal patches as the one I sent.
Cheers,
Wincent
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Junio C Hamano @ 2007-11-28 9:47 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <50645A3B-C5F0-4A99-A2B8-AD9251024244@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> The problem in this case was that my patch didn't receive any
> meaningful feedback (ie. suggestions for improvement), only a lot of
> bikeshed stuff about whether the environment variable should have an
> underscore prefix or not, whether or not I should use "export FOO=..."
> or not etc. So I didn't know what was necessary in order to get it
> accepted.
I do not think that is the case.
I think _GIT_FOO vs GIT_FOO is an important detail, not at all a
bikeshed color, to make things consistent. "export VAR=VAL" also is a
valid concern (you said in a separate message you only know about bash,
and I later asked people if they use shells that get affected with it
but we happily run otherwise. I personally do not think the latter is a
problem, but since somebody already raised it as a potential issue, it
gave us a good chance to hear from people on minority platforms, if only
to build confidence in us to use that POSIX form.
Maybe it is just me, but I think my suggestion to replace not just "git
commit" part but also "git add" part is also an important design issue.
In any case, after a discussion, sending out a readily applyable patch
would help to make sure we reached a reasonable consensus; it makes it
easier for other people to try out your proposed draft of the consensus
without waiting for me or anybody else and give positive feedback.
The difference between the variant I posted and your revised one I see
are:
* As discussed, we have precedence like GITHEAD_* and GIT_REFLOG_ACTION
that are used purely for inter-tool communication without the leading
underscore, so I followed them for consistency.
* The part of the message that is overridable is made wider; that way,
we can later choose to have "git rebase --continue" do the final "git
add -u" step, just like we made "git rebase --skip" to run "git reset
--hard", without changing revert/cherry-pick,as I explained in the
comment to my patch.
* I made the help-message creation into a separate function. This is
just a minor detail, but I think it is good for readability.
* I am setting and exporting the help environment near the beginning of
rebase--interactive just once; again I think this is more readable.
But other than that, the basic idea is the same and is all yours.
If these details (I do not think the overridability is a minor detail,
though) look like bikeshedding to you, that is somewhat sad. You seem
to be very capable of producing usable code, but these details
(consistency and flexibility) matter for longer term stability, and I
would really want to see capable people pay attention to such details,
especially I sometimes fail to do so myself.
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Karl Hasselström @ 2007-11-28 9:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711271512g790364e0ka4839b2be9fd4935@mail.gmail.com>
On 2007-11-27 18:12:49 -0500, Jon Smirl wrote:
> As Jakub pointed out to me "git reset --hard $(cat
> .git/patches/<branch>/orig-base)" would have recovered from the
> rebase command. But I had already typed 'stg repair' which
> compounded the mess.
Unless it has a bug, the only thing "stg repair" will do is
* create some new applied patches out of commits reachable from HEAD
* mark some applied patches as unapplied
* mark some unapplied patches as applied
in order to make sure that the applied patches are precisely those
that are reachable from HEAD, and that the sequence of applied patches
doesn't have "holes" in it (that is, commits that aren't patches).
In particular, it should not ever modify your existing patches, and it
will never move the branch head. Just resetting the branch head to
wherever you want it to be (and then running repair again) should fix
literally all problems.
> This is way too easy to do. One simple mistype of 'git' for 'stg'
> and you're in a mess.
You're right, this is not user friendly. A pre-rebase hook sounds like
a reasonable idea.
It would also be convenient with a post-commit hook that turns new
commits into patches automatically. And gives "git commit --amend" the
semantics of "stg refresh".
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Rollback of git commands
From: Karl Hasselström @ 2007-11-28 9:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711271733r6f280618pbb14095aebba3309@mail.gmail.com>
On 2007-11-27 20:33:27 -0500, Jon Smirl wrote:
> Let's take my recent problem as an example. I typed 'git rebase
> linus/master' instead of 'stg rebase linus/master'. Then I typed
> 'stg repair'. The repair failed and left me in a mess. Both of these
> are easy to rollback except for the fact that stg has stored a bunch
> of state in .git/*.
>
> After doing the commands I located my last commit before the rebase
> and edited master back to it. But my system was still messed up
> since moving master got me out of sync with the state stg stored in
> .git/*. The 'stg repair' command had changed the stored state.
How exactly did repair mess up? Did it crash, produce a broken result,
an unreasonable but technically valid result, or just not the result
you wanted?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Use --no-color option on git log commands.
From: Junio C Hamano @ 2007-11-28 4:45 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <474C60FA.4040302@wanadoo.fr>
Pascal Obry <pascal.obry@wanadoo.fr> writes:
> Junio C Hamano a écrit :
>> The patch is good as belt-and-suspender, thanks.
>
> Ok.
>
>> But I suspect that we should make 'true' to mean 'auto' someday in
>> git_config_colorbool(). Crazy people can set 'always' if they really
>> wanted to, but most normal people would not want color unless the output
>> goes to the terminal, I would think.
>
> I definitely agree. I add it set to true, using auto instead I do not
> have the problem. Anyway I still think that it is good to apply my patch
> to completely avoid such issues.
Yes, that is what I said.
Except that the patch is severely whitespace damaged, and the message
lack a sign-off.
I fixed them up by hand, so no need to resend.
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Wincent Colaiuta @ 2007-11-28 8:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <7vir3m94ku.fsf@gitster.siamese.dyndns.org>
El 28/11/2007, a las 9:06, Junio C Hamano escribió:
>> Once I get a clear idea of what kind of change is likely to actually
>> get accepted I'll submit a proper patch.
>
> Too often, people disappear with a patch that is basically good but
> has
> room for improvements this way. I really do not have time nor
> bandwidth
> to keep bugging them for updates, and often end up cleaning up on my
> own
> instead.
The problem in this case was that my patch didn't receive any
meaningful feedback (ie. suggestions for improvement), only a lot of
bikeshed stuff about whether the environment variable should have an
underscore prefix or not, whether or not I should use "export FOO=..."
or not etc. So I didn't know what was necessary in order to get it
accepted.
> This is such a patch, and without acks or comments, it is also very
> likely to be lost.
Ok, please disregard the resend that I just posted a few minutes ago
(hadn't seen your new patch yet).
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Junio C Hamano @ 2007-11-28 8:43 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1196205847-22968-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> This patch makes it possible to drag files and directories from
> a graphical browser and drop them onto a shell and feed them
> to common git operations without editing away the path to the
> root of the work tree.
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> ---
> setup.c | 19 +++++++++++++++++
> t/t3904-abspatharg.sh | 55 +++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 74 insertions(+), 0 deletions(-)
> create mode 100755 t/t3904-abspatharg.sh
>
> diff --git a/setup.c b/setup.c
> index f512ea0..ffc30bf 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -7,6 +7,25 @@ static int inside_work_tree = -1;
> const char *prefix_path(const char *prefix, int len, const char *path)
> {
> const char *orig = path;
> + const char *work_tree = get_git_work_tree();
> + if (is_absolute_path(path) && work_tree) {
> + int n = strlen(work_tree);
> + if (!strncmp(path, work_tree, n) && (path[n] == '/' || !path[n])) {
> + if (path[n])
> + path += n + 1;
> + else
> + path += n;
> +
> + if (prefix && !strncmp(path, prefix, len - 1)) {
> + if (path[len - 1] == '/')
> + path += len;
> + else
> + if (!path[len - 1])
> + path += len - 1;
> + }
> + }
> + }
> +
This looks somewhat tighter than the previous one, but still made me
worried if the caller of prefix_path() has run the setup sequence enough
so that calling get_git_work_tree() is safe, so I ended up auditing the
callpath. At least, I do not want to see that unconditional call to
get_git_work_tree() when we do not need to do this "ah prefix got an
unusual absolute path" stuff.
* builtin-init-db.c uses prefix_path() to find where the template is
(this is mingw fallout change); in general, I do not think we would
want to trigger repository nor worktree discovery inside init-db,
although I suspect this particular callpath could be made Ok (because
it is taken only when template_dir is not absolute) if you do not
unconditionally call get_git_work_tree() in prefix_path().
* config.c uses prefix_path() to find the ETC_GITCONFIG that is not
absolute (again, mingw fallout). When git_config() is called, we
already should have discovered repository but worktree may not have
been found yet (config.worktree can be used to specify where it is,
so you have a chicken and egg problem). Again, this particular
callpath happens to be Ok because this is used only for non-absolute
path, but that is a bit subtle.
* get_pathspec() uses prefix_path() for obvious reasons, and the prefix
it gets must have been discovered by finding out where the worktree
is, so by definition that one is safe.
Everybody else you would get from "git grep prefix_path" are after the
proper setup, so they should all be safe.
> diff --git a/t/t3904-abspatharg.sh b/t/t3904-abspatharg.sh
> new file mode 100755
> index 0000000..cd4a52e
> --- /dev/null
> +++ b/t/t3904-abspatharg.sh
> @@ -0,0 +1,55 @@
> +#!/bin/sh
> +#
> +# Copyright (C) 2007 Robin Rosenberg
> +#
> +
> +test_description='Test absolute filename arguments to various git
> +commands. Absolute arguments pointing to a location within the git
> +work tree should behave the same as relative arguments. '
> +
> +. ./test-lib.sh
> +
> +test_expect_success 'add files using absolute path names' '
> +echo a >afile &&
> +echo b >bfile &&
> +git-add afile &&
> +git-add "$(pwd)/bfile" &&
This looks quite dense. With indent like other existing tests this
would become a bit easier to read.
> +test "afile bfile" = "$(echo $(git ls-files))"
Hmmm. Looks a bit ugly but Ok.
> +mkdir x &&
> +cd x &&
> +echo c >cfile &&
> +echo d >dfile &&
> +git-add cfile &&
> +git-add "$(pwd)" &&
> +cd .. &&
If this sequence fails in the middle, the next test will execute in a
wrong directory. Instead of "cd there && ... && cd .. &&", it is safer
to do "( cd there && ... ) &&".
> +test "afile bfile x/cfile x/dfile" = "$(echo $(git ls-files))" &&
> +git ls-files x >f1 &&
> +git ls-files "$(pwd)/x" >f2 &&
> +diff f1 f2
"diff -u" is much easier for people who ends up reading the output when
something goes wrong.
Cases that are still not covered:
try to add a file in the parent directory from a subdirectory,
using absolute path;
try to add a file in a directory that is too high (i.e. outside
the work tree), using absolute path;
The latter I think should fail. People tend to forget writing negative
tests when they are too excited with their shiny new features.
Perhaps adding something like:
try to add a sub-subdirectory using an absolute path, and make
sure paths in subdirectory are not added;
would also be prudent to catch future possible breakages (off by one
cutting the common directory prefix one level too deep or something),
but that is probably just me who tends to be paranoid.
Exactly the same comments apply to tests for other commands. Also I
think mv, rm, reset and checkout take pathnames.
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Nguyen Thai Ngoc Duy @ 2007-11-28 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan Hudec, Johannes Schindelin, git
In-Reply-To: <7v8x4jb295.fsf@gitster.siamese.dyndns.org>
On Nov 28, 2007 8:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
> In case somebody is thinking about 36e5e70e0f40 (Start deprecating
> "git-command" in favor of "git command"), that is a somewhat different
> issue. What Linus suggested is not installing git-foo link for built-in
> commands _anywhere_ on the filesystem. Not just "out of user's PATH".
> That is not deprecating dash form but removing the support for it. We
> need to give ample time for users to adjust to such a change.
A little note on this one. I've been using git without builtin links
for a while with my git-box port. There are still some builtin fixups
needed. And because execv_git_cmd() always uses dash form, so it's
impossible to use vanilla git without builtin links.
--
Duy
^ permalink raw reply
* Re: [PATCH] Replace misleading message during interactive rebasing
From: Wincent Colaiuta @ 2007-11-28 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, tsuna, Johannes.Schindelin, mcostalba
In-Reply-To: <7vve7n9eaa.fsf@gitster.siamese.dyndns.org>
El 28/11/2007, a las 5:37, Junio C Hamano escribió:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Wincent Colaiuta schrieb:
>>> + export _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
>>
>> Isn't this a bashism?
>
> Being an old-fashioned shell programmer myself, "export VAR=VAL" does
> raise my eyebrows. It is in POSIX but are there shells that we do
> support (dash, bash, ksh -- /bin/sh on Solaris does not count) that
> want their exports old-fashioned way?
As I noted earlier in thread, the idiom is used elsewhere in Git
already. Below is a list of the instances I found where shell scripts
use the idiom. There are also other instances (documentation, test
scripts, even a tcl file) where the idiom is used. As far as its
suitability I only have directory experience with Bash, and it's
always worked in all versions that I've tried in the 2.x and 3.x
range. The other shells, I don't know.
In any case, below I'll paste in a revised patch that doesn't use the
export FOO=... idiom. I can also submit another patch changing the
other usages of the idiom elsewhere in the tree, but I'd need guidance
on how far you'd want to go (only the Git commands? also the tests?
don't worry about the docs? etc).
El 27/11/2007, a las 9:49, Wincent Colaiuta escribió:
> I wondered that myself before submitting the patch, but then saw
> that the same pattern was used at other places as well:
>
> git-clone.sh:
>
> W=$(cd "$GIT_WORK_TREE" && pwd) && export GIT_WORK_TREE="$W"
>
> git-filter-branch.sh:
>
> export GIT_INDEX_FILE="$(pwd)/../index"
> export GIT_COMMIT=$commit
> export GIT_COMMIT="$sha1"
>
> git-quiltimport.sh:
>
> export GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
> export GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
> export GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' "$tmp_info")
> export SUBJECT=$(sed -ne 's/Subject: //p' "$tmp_info")
>
> So if this is a problem, those sites will need to be changed as well.
>
> Cheers,
> Wincent
Here's the revised patch:
--------8<---------
From cd11e1355011796fe16d0eb7116fae4070f2a30d Mon Sep 17 00:00:00 2001
From: Wincent Colaiuta <win@wincent.com>
Date: Mon, 26 Nov 2007 13:35:46 +0100
Subject: [PATCH] Replace misleading message during interactive rebasing
git-rebase--interactive uses git-cherry-pick under the covers to reorder
commits, which in turn means that in the event of a conflict a message
will be shown advising the user to commit the results and use the -c
switch to retain authorship after fixing the conflict.
The message is misleading because what the user really needs to do is
run "git rebase --continue"; the committing is handled by git-rebase
and the authorship of the commit message is retained automatically.
We solve this problem by using an environment variable to communicate
to git-cherry-pick that rebasing is underway and replace the misleading
error message with a more helpful one.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
builtin-revert.c | 8 +++++---
git-rebase--interactive.sh | 4 ++++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index a0586f9..5a57574 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -229,7 +229,7 @@ static int revert_or_cherry_pick(int argc, const
char **argv)
unsigned char head[20];
struct commit *base, *next, *parent;
int i;
- char *oneline, *reencoded_message = NULL;
+ char *oneline, *reencoded_message = NULL, *help_message;
const char *message, *encoding;
const char *defmsg = xstrdup(git_path("MERGE_MSG"));
@@ -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,
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index bf44b6a..3552c89 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -117,6 +117,8 @@ pick_one () {
sha1=$(git rev-parse --short $sha1)
output warn Fast forward to $sha1
else
+ _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
+ export _GIT_CHERRY_PICK_HELP &&
output git cherry-pick "$@"
fi
}
@@ -187,6 +189,8 @@ pick_one_preserving_merges () {
fi
;;
*)
+ _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
+ export _GIT_CHERRY_PICK_HELP &&
output git cherry-pick "$@" ||
die_with_patch $sha1 "Could not pick $sha1"
;;
--
1.5.3.6.953.gdffc
^ permalink raw reply related
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jan Hudec @ 2007-11-28 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Nguyễn Thái Ngoc Duy, git
In-Reply-To: <7v8x4jb295.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 27, 2007 at 17:13:58 -0800, Junio C Hamano wrote:
> Jan Hudec <bulb@ucw.cz> writes:
> > On Tue, Nov 27, 2007 at 16:18:01 +0000, Johannes Schindelin wrote:
> >> On Tue, 27 Nov 2007, Nguyễn Thái Ngoc Duy wrote:
> >>
> >> > Both configure and make-only ways should work now
> >>
> >> I thought your plan was to put the non-porcelain into the libexecdir only?
> >
> > I had the impression that deprecating the dash notation for /all/ use was
> > approved some time ago. Though I don't want to search through the list
> > archives this late in the night to check it.
>
> [...]
>
> In case somebody is thinking about 36e5e70e0f40 (Start deprecating
> "git-command" in favor of "git command"), that is a somewhat different
> issue. What Linus suggested is not installing git-foo link for built-in
> commands _anywhere_ on the filesystem. Not just "out of user's PATH".
> That is not deprecating dash form but removing the support for it. We
> need to give ample time for users to adjust to such a change.
Yes, that is what I said I recall seeing. Installing out of user's PATH is
a step towards not installing at all and the change suggests it has been
already accepted as a general direction for future. Or not?
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Andreas Ericsson @ 2007-11-28 8:12 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Schindelin, Nicolas Pitre,
らいしななこ, Jakub Narebski,
git
In-Reply-To: <20071127170749.GA19136@fieldses.org>
J. Bruce Fields wrote:
> On Tue, Nov 27, 2007 at 04:54:18PM +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Tue, 27 Nov 2007, J. Bruce Fields wrote:
>>
>>> If we really want a fetch+rebase script, OK, but call it something other
>>> than pull.
>> Why? pull = fetch + merge only because that was the originally envisioned
>> way to pull remote changes into your local working tree. However, I do
>> not see why we should be married to pull being a fetch and a merge for
>> eternity.
>
> Two responses:
>
> First, OK, if you want to say "pull" means "fetch something and then
> incorporate it somehow into your current branch", that doesn't bother me
> quite as much as saying that "pull" always means "fetch + merge", and
> that "rebase" is really just a special kind of merge. It's clearly not
> a merge.
>
I beg to differ. The end result is identical to a merge (assuming one
never does "git rebase skip", which otoh could be thought of as one way
of resolving a merge conflict). It's just history that doesn't turn out
the same. git has always been about content, so from that pov, a rebase
is exactly the same as a merge.
> Second: "fetch+rebase" will really have very different properties from
> "fetch+pull".
"fetch+merge", no?
> It may be possible to make the former behave a little
> like the latter in some common cases, but it's going to complicated.
True. I don't think octopus rebase needs to be supported, for example.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Junio C Hamano @ 2007-11-28 8:06 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <97F6E8DE-4022-4458-B6A9-C644A6EDC1E3@wincent.com>
> Once I get a clear idea of what kind of change is likely to actually
> get accepted I'll submit a proper patch.
Too often, people disappear with a patch that is basically good but has
room for improvements this way. I really do not have time nor bandwidth
to keep bugging them for updates, and often end up cleaning up on my own
instead.
This is such a patch, and without acks or comments, it is also very
likely to be lost.
-- >8 --
revert/cherry-pick: Allow overriding the help text by the calling Porcelain
A Porcelain command that uses cherry-pick or revert may make a commit
out of resolved index itself, in which case telling the user to commit
the result is not appropriate at all. This allows GIT_CHERRY_PICK_HELP
environment variable to be set by the calling Porcelain in order to
override the built-in help text.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I suspect that "git rebase --continue" can do "git add -u" itself,
just like recent "git rebase --skip" would do "git reset --hard".
The overriding help text in this patch can lose its second line that
tells the user to use "git add <paths>" if we decide to do so.
builtin-revert.c | 33 +++++++++++++++++++++++----------
git-rebase--interactive.sh | 5 +++++
2 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index a0586f9..4f86178 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -224,6 +224,27 @@ static int merge_recursive(const char *base_sha1,
return run_command_v_opt(argv, RUN_COMMAND_NO_STDIN | RUN_GIT_CMD);
}
+static char *help_msg(const unsigned char *sha1)
+{
+ static char helpbuf[1024];
+ char *msg = getenv("GIT_CHERRY_PICK_HELP");
+
+ if (msg)
+ return msg;
+
+ strcpy(helpbuf, " After resolving the conflicts,\n"
+ "mark the corrected paths with 'git add <paths>' "
+ "and commit the result.");
+
+ if (action == CHERRY_PICK) {
+ sprintf(helpbuf + strlen(helpbuf),
+ "\nWhen commiting, use the option "
+ "'-c %s' to retain authorship and message.",
+ find_unique_abbrev(sha1, DEFAULT_ABBREV));
+ }
+ return helpbuf;
+}
+
static int revert_or_cherry_pick(int argc, const char **argv)
{
unsigned char head[20];
@@ -352,16 +373,8 @@ 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);
- 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) {
- fprintf(stderr, "When commiting, use the option "
- "'-c %s' to retain authorship and message.\n",
- find_unique_abbrev(commit->object.sha1,
- DEFAULT_ABBREV));
- }
+ fprintf(stderr, "Automatic %s failed.%s\n",
+ me, help_msg(commit->object.sha1));
exit(1);
}
if (close(msg_fd) || commit_lock_file(&msg_file) < 0)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index bf44b6a..33a5d4b 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -30,6 +30,11 @@ test -d "$REWRITTEN" && PRESERVE_MERGES=t
test -f "$DOTEST"/strategy && STRATEGY="$(cat "$DOTEST"/strategy)"
test -f "$DOTEST"/verbose && VERBOSE=t
+GIT_CHERRY_PICK_HELP=" After resolving the conflicts,
+mark the corrected paths with 'git add <paths>', and
+run 'git rebase --continue'"
+export GIT_CHERRY_PICK_HELP
+
warn () {
echo "$*" >&2
}
^ permalink raw reply related
* Re: [PATCH] git-config --get-color: get configured color
From: Dan Zwell @ 2007-11-28 7:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <7vir3mal9u.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> +--get-color name default::
> +
> + Find the color configured for `name` (e.g. `color.diff.new`) and
> + output it as the ANSI color escape sequence to the standard
> + output. The optional `default` parameter is used if the
> + configuration for `name` is missing.
Perhaps you could mention here that the second parameter is a normal
string, not an ansi code? Just adding 'for example, "blue"' would
probably help.
> +RESET==$(git config --get-color "" "reset")
This is a typo, no?
+RESET=$(git config --get-color "" "reset")
Dan
^ permalink raw reply
* ok for git to delete temporary packs on write error?
From: David Tweed @ 2007-11-28 7:42 UTC (permalink / raw)
To: Git Mailing List
Hi, I'd like to check if there's any reason in the overall design of
git which would make deleting tmp_pack's that have suffered
write errors a bad idea? (Before I look further into this I may be missing
a good reason why they shouldn't be auto-deleted.)
My encounter with this comes from using an almost full
usbstick which I discovered when I was poking around
for other reasons several partial packs from occasions
(separated by weeks) where gc failed. On each failure
I'd removed stuff from the drive to clear space and done
a successful gc but hadn't thought to
check below .git for removable stuff so they'd just accumulated.
Below is a output of a test session:
$ git version
git version 1.5.3.6
$ git gc --aggressive --prune
Generating pack...
Done counting 22216 objects.
Deltifying 22216 objects...
100% (22216/22216) done
Writing 22216 objects...
fatal: sha1 file '/media/usbdiskc/v.git/objects/tmp_pack_QCYYAi' write
error (No space left on device)
error: failed to run repack
$ ls -l /media/usbdiskc/v.git/objects/
total 3944
drwxr-xr-x 2 sis05dst sis05dst 2048 2007-11-28 07:25 info
drwxr-xr-x 2 sis05dst sis05dst 2048 2007-11-28 07:25 pack
-rwxr-xr-x 1 sis05dst sis05dst 4034560 2007-11-28 07:25 tmp_pack_QCYYAi
-rw------- 1 sis05dst sis05dst 0 2007-04-18 23:02 tmp_pack_RYLguI
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* [PATCH/RFC] "color.diff = true" is not "always" anymore.
From: Junio C Hamano @ 2007-11-28 7:26 UTC (permalink / raw)
To: git list
In-Reply-To: <7vr6icej23.fsf@gitster.siamese.dyndns.org>
Too many people got burned by setting color.diff and color.status to
true when they really should have set it to "auto".
This makes only "always" to do the unconditional colorization, and
change the meaning of "true" to the same as "auto": colorize only when
we are talking to a terminal.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is definitely a backward incompatible change, but I think it is
only in a good way. Are there people who have "color.* = true" and
do mean it? If we do this, they need to change their configuration
and use "always", but I suspect there is no sane workflow that wants
the color escape code in files (e.g. "git log >file") or pipes
(e.g. "git diff | grep foo") by default, in which case this won't
hurt anybody and would help countless normal people who were bitten
by the mistaken meaning originally chosen for "true".
color.c | 32 +++++++++++++++++++-------------
1 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/color.c b/color.c
index 124ba33..97cfbda 100644
--- a/color.c
+++ b/color.c
@@ -118,21 +118,27 @@ bad:
int git_config_colorbool(const char *var, const char *value)
{
- if (!value)
- return 1;
- if (!strcasecmp(value, "auto")) {
- if (isatty(1) || (pager_in_use && pager_use_color)) {
- char *term = getenv("TERM");
- if (term && strcmp(term, "dumb"))
- return 1;
- }
- return 0;
+ if (value) {
+ if (!strcasecmp(value, "never"))
+ return 0;
+ if (!strcasecmp(value, "always"))
+ return 1;
+ if (!strcasecmp(value, "auto"))
+ goto auto_color;
}
- if (!strcasecmp(value, "never"))
+
+ /* Missing or explicit false to turn off colorization */
+ if (!git_config_bool(var, value))
return 0;
- if (!strcasecmp(value, "always"))
- return 1;
- return git_config_bool(var, value);
+
+ /* any normal truth value defaults to 'auto' */
+ auto_color:
+ if (isatty(1) || (pager_in_use && pager_use_color)) {
+ char *term = getenv("TERM");
+ if (term && strcmp(term, "dumb"))
+ return 1;
+ }
+ return 0;
}
static int color_vfprintf(FILE *fp, const char *color, const char *fmt,
--
1.5.3.6.2039.g0495
^ permalink raw reply related
* [PATCH] git-config --get-color: get configured color
From: Junio C Hamano @ 2007-11-28 7:20 UTC (permalink / raw)
To: Jeff King, Dan Zwell; +Cc: git, Jakub Narebski
In-Reply-To: <7vabp4u40y.fsf@gitster.siamese.dyndns.org>
This new option allows scripts to grab color setting from the user
configuration, translated to ANSI color escape sequence.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Integer variables can have optional 'k', 'm' or 'g' suffix.
>> config_int() method will return simple decimal number, taking
>> care of those suffixes.
>
> Good. I forgot about --int option to "git config" already.
>
> Maybe in a similar way, we might want to add --color to "git
> config" to return ANSI sequence, so that Git::config_color() can
> work without even loading Term::ANSIColor?
Documentation/git-config.txt | 16 ++++++++++++
builtin-config.c | 55 +++++++++++++++++++++++++++++++++++++++--
2 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index a592b61..ed3076f 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -20,6 +20,7 @@ SYNOPSIS
'git-config' [<file-option>] --rename-section old_name new_name
'git-config' [<file-option>] --remove-section name
'git-config' [<file-option>] [-z|--null] -l | --list
+'git-config' [<file-option>] --get-color name [default]
DESCRIPTION
-----------
@@ -134,6 +135,12 @@ See also <<FILES>>.
output without getting confused e.g. by values that
contain line breaks.
+--get-color name default::
+
+ Find the color configured for `name` (e.g. `color.diff.new`) and
+ output it as the ANSI color escape sequence to the standard
+ output. The optional `default` parameter is used if the
+ configuration for `name` is missing.
[[FILES]]
FILES
@@ -292,6 +299,15 @@ To add a new proxy, without altering any of the existing ones, use
% git config core.gitproxy '"proxy-command" for example.com'
------------
+An example to use customized color from the configuration in your
+script:
+
+------------
+#!/bin/sh
+WS=$(git config --get-color color.diff.whitespace "blue reverse")
+RESET==$(git config --get-color "" "reset")
+echo "${WS}your whitespace color or blue reverse${RESET}"
+------------
include::config.txt[]
diff --git a/builtin-config.c b/builtin-config.c
index f672c9c..4c9ded3 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -1,8 +1,9 @@
#include "builtin.h"
#include "cache.h"
+#include "color.h"
static const char git_config_set_usage[] =
-"git-config [ --global | --system | [ -f | --file ] config-file ] [ --bool | --int ] [ -z | --null ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list";
+"git-config [ --global | --system | [ -f | --file ] config-file ] [ --bool | --int ] [ -z | --null ] [--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list | --get-color var [default]";
static char *key;
static regex_t *key_regexp;
@@ -161,6 +162,53 @@ char *normalize_value(const char *key, const char *value)
return normalized;
}
+static int get_color_found;
+static const char *get_color_slot;
+static char parsed_color[COLOR_MAXLEN];
+
+static int git_get_color_config(const char *var, const char *value)
+{
+ if (!strcmp(var, get_color_slot)) {
+ color_parse(value, var, parsed_color);
+ get_color_found = 1;
+ }
+ return 0;
+}
+
+static int get_color(int argc, const char **argv)
+{
+ /*
+ * grab the color setting for the given slot from the configuration,
+ * or parse the default value if missing, and return ANSI color
+ * escape sequence.
+ *
+ * e.g.
+ * git config --get-color color.diff.whitespace "blue reverse"
+ */
+ const char *def_color = NULL;
+
+ switch (argc) {
+ default:
+ usage(git_config_set_usage);
+ case 2:
+ def_color = argv[1];
+ /* fallthru */
+ case 1:
+ get_color_slot = argv[0];
+ break;
+ }
+
+ get_color_found = 0;
+ parsed_color[0] = '\0';
+ git_config(git_get_color_config);
+
+ if (!get_color_found && def_color)
+ color_parse(def_color, "command line", parsed_color);
+
+ fputs(parsed_color, stdout);
+ return 0;
+}
+
int cmd_config(int argc, const char **argv, const char *prefix)
{
int nongit = 0;
@@ -234,8 +282,9 @@ int cmd_config(int argc, const char **argv, const char *prefix)
return 1;
}
return 0;
- }
- else
+ } else if (!strcmp(argv[1], "--get-color")) {
+ return get_color(argc-2, argv+2);
+ } else
break;
argc--;
argv++;
--
1.5.3.6.2039.g0495
^ permalink raw reply related
* Re: stgit: lost all my patches again
From: Karl Hasselström @ 2007-11-28 6:32 UTC (permalink / raw)
To: Jon Smirl; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <9e4733910711271859w7b7dc141q93e3c9f67693a54@mail.gmail.com>
On 2007-11-27 21:59:00 -0500, Jon Smirl wrote:
> 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.
Mmmm. We'd have to define "damage"; "stg repair" can take care of
quite a lot of things nowadays. Committing new stuff on top of a patch
series is no problem, for example, and "git reset --hard HEAD^ && stg
repair" is equivalent to "stg pop". I can see how "git rebase" would
still be a nuisance, though.
Patch? :-)
Presumably, we'd want the hook to be a Python script, so as to
* not make it more difficult to port StGit to Windows someday;
* make it possible for the hook to call StGit functions; and
* not force the project's contributors to learn more shell scripting
than they have to. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Allow update hooks to update refs on their own
From: Steven Grimm @ 2007-11-28 5:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vzlwz9ghg.fsf@gitster.siamese.dyndns.org>
On Nov 27, 2007, at 7:49 PM, Junio C Hamano wrote:
> Yeah, and I am wondering why update hook needs to be changed for this.
> Didn't we introduce post-receive exactly for this sort of thing?
I didn't think the post-receive hook could reject a revision. I need
to be able to do that here, e.g., if the user's change fails to commit
because it's rejected by an svn commit hook. (Hooks upon hooks upon
hooks...) If I do the svn commit in post-receive it's not clear how
the user would repush the change after fixing it -- their fix would
show up as a delta on top of a revision that I can't commit on its own
to svn, so I would somehow have to know to do a squash merge and there
would no longer be a one-to-one correspondence between git and svn
revisions. That's not a total showstopper (I'm rewriting history
anyway) but it sure seems like it'll be confusing and error-prone.
Also, running in post-receive will subject me to race conditions that
aren't present in the update hook case; if I make my update hook
script do its own locking and update the refs on its own, I'm
guaranteed no other push will come along and update my ref out from
under me. In post-receive there is no such guarantee and I may end up
sending two pushes' worth of commits to svn when I think I'm only
sending one.
If I'm misunderstanding the flow of control, please feel free to
correct me. It just seemed like update was the only good place to do
what I needed to do.
-Steve
^ permalink raw reply
* Re: Rollback of git commands
From: Junio C Hamano @ 2007-11-28 4:57 UTC (permalink / raw)
To: Sean; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <BAYC1-PASMTP02DBA3FB25E09FE45F0BF2AE770@CEZ.ICE>
"Sean" <seanlkml@sympatico.ca> writes:
>> After doing the commands I located my last commit before the rebase
>> and edited master back to it. But my system was still messed up since
>> moving master got me out of sync with the state stg stored in .git/*.
>> The 'stg repair' command had changed the stored state.
>
> From your description is seems that Git proper was able to handle the
> situation just fine. It sounds instead like you're describing a problem
> with Stg where it became confused without a way to restore _its_ meta
> data. There's not much Git itself can do to help in this situation
> unless Stg stores all of its meta-data as standard Git objects, rather
> than just using the .git directory.
Essentially, he does not want to use "git rebase" and have a way to
disable the command on a branch that stg is actively munging. And that
is something git proper can help with the user, which is why I earlier
referred him to pre-rebase hook.
As you suggested, however, git proper should not know the internals of
Porcelains, so I'd rather not to have that logic deep in git-rebase
itself. But the pre-rebase hook shoud be the appropriate place for the
user to actually populate with stg specific logic ("is stg set to
actively munge this branch") and activate it for his repository.
^ permalink raw reply
* Re: [PATCH] Allow update hooks to update refs on their own
From: Steven Grimm @ 2007-11-28 2:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pf7b20b.fsf@gitster.siamese.dyndns.org>
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.
-Steve
^ permalink raw reply
* Re: Rollback of git commands
From: Jon Smirl @ 2007-11-28 4:53 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <BAYC1-PASMTP101A96ADE42981D2708652AE770@CEZ.ICE>
On 11/27/07, Sean <seanlkml@sympatico.ca> wrote:
> On Tue, November 27, 2007 11:37 pm, Jon Smirl said:
>
> > Patch management is an important part of the work flow. I would hope
> > that git implements patch management as a core feature in future
> > versions. stgit/guilt/quilt are valuable since they blazed the trail
> > and figured out what commands are useful. As time passes these
> > features can become more highly integrated into core git.
>
> Think this is a separate topic from where we started though.
>
> > Of course you've never screwed up a repository using git commands,
> > right? I've messed up plenty. A good way to mess up a repo is to get
> > the data in .git/* out of sync with what is in the repo. I'm getting
> > good enough with git that I can fix most mess up with a few edits, but
> > it took me two years to get to that point. Rolling back to a check
> > point is way easier. User error and a command failing are both equally
> > valid ways to mess up a repo.
>
> What are you looking for that reflogs don't already handle?
A UI that doesn't need a year of using git before you know what to do with it.
Delta tracking of changes made in .git/* that aren't currently being tracked.
reflogs is a piece of the complete solution.
A higher level of integration for stgit would probably make it more
bullet proof.
>
> Cheers,
> Sean
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Rollback of git commands
From: Sean @ 2007-11-28 4:40 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711272037r2ce3ed01y31ec8531f5803efe@mail.gmail.com>
On Tue, November 27, 2007 11:37 pm, Jon Smirl said:
> Patch management is an important part of the work flow. I would hope
> that git implements patch management as a core feature in future
> versions. stgit/guilt/quilt are valuable since they blazed the trail
> and figured out what commands are useful. As time passes these
> features can become more highly integrated into core git.
Think this is a separate topic from where we started though.
> Of course you've never screwed up a repository using git commands,
> right? I've messed up plenty. A good way to mess up a repo is to get
> the data in .git/* out of sync with what is in the repo. I'm getting
> good enough with git that I can fix most mess up with a few edits, but
> it took me two years to get to that point. Rolling back to a check
> point is way easier. User error and a command failing are both equally
> valid ways to mess up a repo.
What are you looking for that reflogs don't already handle?
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] Replace misleading message during interactive rebasing
From: Junio C Hamano @ 2007-11-28 4:37 UTC (permalink / raw)
To: Johannes Sixt
Cc: Wincent Colaiuta, git, tsuna, Johannes.Schindelin, mcostalba
In-Reply-To: <474BD5CA.7050407@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Wincent Colaiuta schrieb:
>> + export _GIT_CHERRY_PICK_HELP="run 'git rebase --continue'"
>
> Isn't this a bashism?
Being an old-fashioned shell programmer myself, "export VAR=VAL" does
raise my eyebrows. It is in POSIX but are there shells that we do
support (dash, bash, ksh -- /bin/sh on Solaris does not count) that
want their exports old-fashioned way?
^ permalink raw reply
* Re: Rollback of git commands
From: Jon Smirl @ 2007-11-28 4:37 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <BAYC1-PASMTP02DBA3FB25E09FE45F0BF2AE770@CEZ.ICE>
On 11/27/07, Sean <seanlkml@sympatico.ca> wrote:
> On Tue, November 27, 2007 8:33 pm, Jon Smirl said:
>
> Hi Jon,
>
> > I'm only looking for a command that would rollback the effect of
> > changes to the object store (you don't have to remove the objects).
> > Losing complex staging would be ok since it can be recreated.
> >
> > Let's take my recent problem as an example. I typed 'git rebase
> > linus/master' instead of 'stg rebase linus/master'. Then I typed 'stg
> > repair'. The repair failed and left me in a mess. Both of these are
> > easy to rollback except for the fact that stg has stored a bunch of
> > state in .git/*.
> >
> > After doing the commands I located my last commit before the rebase
> > and edited master back to it. But my system was still messed up since
> > moving master got me out of sync with the state stg stored in .git/*.
> > The 'stg repair' command had changed the stored state.
>
> From your description is seems that Git proper was able to handle the
> situation just fine. It sounds instead like you're describing a problem
> with Stg where it became confused without a way to restore _its_ meta
> data. There's not much Git itself can do to help in this situation
> unless Stg stores all of its meta-data as standard Git objects, rather
> than just using the .git directory.
Patch management is an important part of the work flow. I would hope
that git implements patch management as a core feature in future
versions. stgit/guilt/quilt are valuable since they blazed the trail
and figured out what commands are useful. As time passes these
features can become more highly integrated into core git.
Of course you've never screwed up a repository using git commands,
right? I've messed up plenty. A good way to mess up a repo is to get
the data in .git/* out of sync with what is in the repo. I'm getting
good enough with git that I can fix most mess up with a few edits, but
it took me two years to get to that point. Rolling back to a check
point is way easier. User error and a command failing are both equally
valid ways to mess up a repo.
--
Jon Smirl
jonsmirl@gmail.com
^ 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