* [PATCH 2/3] fix push --quiet: add 'quiet' capability to receive-pack
From: Clemens Buchacher @ 2012-01-08 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Todd Zullinger
In-Reply-To: <1326056781-17456-1-git-send-email-drizzd@aon.at>
Currently, git push --quiet produces some non-error output, e.g.:
$ git push --quiet
Unpacking objects: 100% (3/3), done.
This fixes a bug reported for the fedora git package:
https://bugzilla.redhat.com/show_bug.cgi?id=725593
Reported-by: Jesse Keating <jkeating@redhat.com>
Cc: Todd Zullinger <tmz@pobox.com>
Commit 90a6c7d4 (propagate --quiet to send-pack/receive-pack)
introduced the --quiet option to receive-pack and made send-pack
pass that option. Older versions of receive-pack do not recognize
the option, however, and terminate immediately. The commit was
therefore reverted.
This change instead adds a 'quiet' capability to receive-pack,
which is a backwards compatible.
In addition, this fixes push --quiet via http: A verbosity of 0
means quiet for remote helpers.
Reported-by: Tobias Ulmer <tobiasu@tmux.org>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
builtin/receive-pack.c | 14 ++++++++++++--
builtin/send-pack.c | 13 ++++++++++---
remote-curl.c | 4 +++-
t/t5523-push-upstream.sh | 7 +++++++
t/t5541-http-push.sh | 8 ++++++++
5 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index d8ddcaa..31d17cf 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -33,6 +33,7 @@ static int transfer_unpack_limit = -1;
static int unpack_limit = 100;
static int report_status;
static int use_sideband;
+static int quiet;
static int prefer_ofs_delta = 1;
static int auto_update_server_info;
static int auto_gc = 1;
@@ -122,7 +123,7 @@ static int show_ref(const char *path, const unsigned char *sha1, int flag, void
else
packet_write(1, "%s %s%c%s%s\n",
sha1_to_hex(sha1), path, 0,
- " report-status delete-refs side-band-64k",
+ " report-status delete-refs side-band-64k quiet",
prefer_ofs_delta ? " ofs-delta" : "");
sent_capabilities = 1;
return 0;
@@ -736,6 +737,8 @@ static struct command *read_head_info(void)
report_status = 1;
if (parse_feature_request(feature_list, "side-band-64k"))
use_sideband = LARGE_PACKET_MAX;
+ if (parse_feature_request(feature_list, "quiet"))
+ quiet = 1;
}
cmd = xcalloc(1, sizeof(struct command) + len - 80);
hashcpy(cmd->old_sha1, old_sha1);
@@ -789,8 +792,10 @@ static const char *unpack(void)
if (ntohl(hdr.hdr_entries) < unpack_limit) {
int code, i = 0;
- const char *unpacker[4];
+ const char *unpacker[5];
unpacker[i++] = "unpack-objects";
+ if (quiet)
+ unpacker[i++] = "-q";
if (fsck_objects)
unpacker[i++] = "--strict";
unpacker[i++] = hdr_arg;
@@ -904,6 +909,11 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
const char *arg = *argv++;
if (*arg == '-') {
+ if (!strcmp(arg, "--quiet")) {
+ quiet = 1;
+ continue;
+ }
+
if (!strcmp(arg, "--advertise-refs")) {
advertise_refs = 1;
continue;
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index cd1115f..71f258e 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -263,6 +263,8 @@ int send_pack(struct send_pack_args *args,
args->use_ofs_delta = 1;
if (server_supports("side-band-64k"))
use_sideband = 1;
+ if (!server_supports("quiet"))
+ args->quiet = 0;
if (!remote_refs) {
fprintf(stderr, "No refs in common and none specified; doing nothing.\n"
@@ -301,11 +303,12 @@ int send_pack(struct send_pack_args *args,
char *old_hex = sha1_to_hex(ref->old_sha1);
char *new_hex = sha1_to_hex(ref->new_sha1);
- if (!cmds_sent && (status_report || use_sideband)) {
- packet_buf_write(&req_buf, "%s %s %s%c%s%s",
+ if (!cmds_sent && (status_report || use_sideband || args->quiet)) {
+ packet_buf_write(&req_buf, "%s %s %s%c%s%s%s",
old_hex, new_hex, ref->name, 0,
status_report ? " report-status" : "",
- use_sideband ? " side-band-64k" : "");
+ use_sideband ? " side-band-64k" : "",
+ args->quiet ? " quiet" : "");
}
else
packet_buf_write(&req_buf, "%s %s %s",
@@ -439,6 +442,10 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
args.force_update = 1;
continue;
}
+ if (!strcmp(arg, "--quiet")) {
+ args.quiet = 1;
+ continue;
+ }
if (!strcmp(arg, "--verbose")) {
args.verbose = 1;
continue;
diff --git a/remote-curl.c b/remote-curl.c
index 48c20b8..bcbc7fb 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -770,7 +770,9 @@ static int push_git(struct discovery *heads, int nr_spec, char **specs)
argv[argc++] = "--thin";
if (options.dry_run)
argv[argc++] = "--dry-run";
- if (options.verbosity > 1)
+ if (options.verbosity == 0)
+ argv[argc++] = "--quiet";
+ else if (options.verbosity > 1)
argv[argc++] = "--verbose";
argv[argc++] = url;
for (i = 0; i < nr_spec; i++)
diff --git a/t/t5523-push-upstream.sh b/t/t5523-push-upstream.sh
index c229fe6..9ee52cf 100755
--- a/t/t5523-push-upstream.sh
+++ b/t/t5523-push-upstream.sh
@@ -108,4 +108,11 @@ test_expect_failure TTY 'push --no-progress suppresses progress' '
! grep "Writing objects" err
'
+test_expect_success TTY 'quiet push' '
+ ensure_fresh_upstream &&
+
+ test_terminal git push --quiet --no-progress upstream master 2>&1 | tee output &&
+ test_cmp /dev/null output
+'
+
test_done
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index 9b85d42..0c3cd3b 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -5,6 +5,7 @@
test_description='test smart pushing over http via http-backend'
. ./test-lib.sh
+. "$TEST_DIRECTORY"/lib-terminal.sh
if test -n "$NO_CURL"; then
skip_all='skipping test, git built without http support'
@@ -186,5 +187,12 @@ test_expect_success 'push --mirror to repo with alternates' '
git push --mirror "$HTTPD_URL"/smart/alternates-mirror.git
'
+test_expect_success TTY 'quiet push' '
+ cd "$ROOT_PATH"/test_repo_clone &&
+ test_commit quiet &&
+ test_terminal git push --quiet --no-progress 2>&1 | tee output &&
+ test_cmp /dev/null output
+'
+
stop_httpd
test_done
--
1.7.8
^ permalink raw reply related
* Re: [PATCH 5/6] revert: report fine-grained error messages from insn parser
From: Jonathan Nieder @ 2012-01-08 21:33 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Junio C Hamano
In-Reply-To: <CALkWK0mStgcb4EBB+ni9fisDJY=13cJZWCTEcgfyOUyAXbc=tA@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Jonathan Nieder wrote:
>> Ramkumar Ramachandra wrote:
>>> /* Eat up extra spaces/ tabs before object name */
>>> - padding = strspn(bol, " \t");
>>> - if (!padding)
>>> - return -1;
>>> - bol += padding;
>>> + bol += strspn(bol, " \t");
[...]
> Not a bugfix: since I have to report sensible error messages now, I
> changed the "pick" and "revert" checks to "pick " || "pick\t" and
> "revert " || "revert\t" -- then, I can report "invalid action" if it
> doesn't match instead of a useless "missing space after action".
Ah, I forgot that the "if (!padding)" check noticed errors like
picking foo
before. So this is just a code cleanup, with no functional effect.
However, you can still report "invalid action" with the old code
structure --- it would just mean duplicating an error message in the
code, since you reach the same conclusion by two code paths. So it's
a relevant cleanup, but I'd still suggest lifting it into a patch that
comes before so future readers can assure themselves that it introduces
no functional change instead of being confused.
[...]
>>> + return error(_("%s:%d: Not a valid commit: %.*s"),
>>> + todo_file, lineno, (int)error_len, bol);
>>> + }
>>
>> Hmm, this one can be emitted even when there was no corruption or
>> internal error, because the user removed a commit she was
>> cherry-picking and the gc-ed before a "git cherry-pick --continue".
>> Alternatively, it can happen because the repository has grown very
>> crowded and what used to be an unambiguous commit name no longer is
>> one (not enough digits). Will the error message be intuitive in these
>> situations?
>
> Something like "Unable to look up commit: %s" perhaps?
My "alternatively" was bogus --- lookup_commit_reference takes a (raw)
full commit name as its argument.
I dunno. The question was not actually rhetorical --- I just meant
that it's worth thinking about these cases. There are a few cases:
- missing object
- object is present but corrupt
- object is a blob, not a commit
In the second case, there's an error message printed describing the
problem, but in the other two there isn't. The other callers tend to
say "not a valid <foo>" or "could not lookup commit <foo>, so I guess
error: .git/sequencer/todo:5: not a valid commit: 78a89f493
would be fine.
Except that this focusses on the .git/sequencer/todo filename which
would leave the person debugging astray. It is not that
.git/sequencer/todo contains a typo (that would have been caught by
get_sha1), but that it referred to a bad object or non-commit. Maybe
something in the direction of
error: cannot pick 78a89f493 because it is not a valid commit
would be more helpful.
Is this the right moment to report that error? Will the operator be
happy that we errored out right away before cherry-picking anything
and wasting the human's time in assisting with that process, or will
she be unhappy that inability to do something later that she might
have been planning on skipping anyway prevented making progress right
away? (I'm not sure what the best thing to do is --- I guess some
advice like
hint: to abort, use cherry-pick --abort
hint: to skip or replace that commit, use cherry-pick --edit
would help.)
Thanks for some food for thought.
Jonathan
^ permalink raw reply
* Re: [PATCH 4/6] revert: allow mixing "pick" and "revert" actions
From: Jonathan Nieder @ 2012-01-08 21:40 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Junio C Hamano
In-Reply-To: <CALkWK0mYbBsZN1UX9YM0VWQezZsBpJCcEgKirCggtNXs0HZ-8g@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Jonathan Nieder wrote:
>> Yes, I've always liked this one.
>>
>> Haven't re-read the patch to avoid wasted effort if there are changes
>> when the previous patches in the series change. Maybe it would be
>> possible to send as a standalone?
>
> If I don't get manage to get the series right in a couple of re-rolls,
> I'll do that.
Splitting out unrelated changes (or at least putting the uncontroversial
ones near the front) is part of getting a series right. I'll pick up
this patch, play around with it and send separately.
^ permalink raw reply
* [PATCH] rebase --fix: interactive fixup mode
From: Clemens Buchacher @ 2012-01-08 21:31 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Interactive rebase is frequently used not to rebase history, but to
manipulate recent commits. This is typically done using the following
command:
git rebase -i HEAD~N
Where N has to be large enough such that the the range HEAD~N..HEAD
contains the desired commits. At the same time, it should be small
enough such that the range HEAD~N..HEAD does not include published
commits or a merge commit. Otherwise, the user may accidentally change
published history. Rebasing a merge commit can also have the generally
undesirable effect of linearizing the merge history.
In order to determine a suitable range automatically, it is a reasonable
heuristic to rebase onto the most recent merge commit. It does not
guarantee that published commits are not included -- indeed there is no
way to do that. But, the range is usually large enough to contain the
desired commits. Also, this mechanism works regardless of whether or not
branch tracking has been configured.
So instead of the above command, one can instead use the following:
git rebase --fix
By default, the range is limited to a maximum of 20 commits. This can be
changed by passing a different number to --fix, e.g.:
git rebase --fix=50
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
Also on branch cb/rebase-fix at https://github.com/drizzd/git .
Documentation/git-rebase.txt | 9 +++++++++
git-rebase.sh | 37 ++++++++++++++++++++++++++++++++++++-
2 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 504945c..b1eac16 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -332,6 +332,15 @@ link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
user edit that list before rebasing. This mode can also be used to
split commits (see SPLITTING COMMITS below).
+--fix=<n>::
+ Searches commit history backwards from the current commit until the
+ most recent merge commit, or until a maximum of <n> preceding commits
+ (default: 20), and runs rebase -i <commit>^. The resulting range is
+ typically large enough to contain recent commits which the user might
+ want to edit, while avoiding the usually undesirable effects of
+ rebasing a merge commit, which obviates the need to find a suitable
+ base commit manually.
+
-p::
--preserve-merges::
Instead of ignoring merges, try to recreate them.
diff --git a/git-rebase.sh b/git-rebase.sh
index 00ca7b9..e95b57f 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -38,6 +38,7 @@ git-rebase [-i] --continue | --abort | --skip
v,verbose! display a diffstat of what changed upstream
q,quiet! be quiet. implies --no-stat
onto=! rebase onto given branch instead of upstream
+fix?! interactive rebase onto last merge commit
p,preserve-merges! try to recreate merges instead of ignoring them
s,strategy=! use the given merge strategy
no-ff! cherry-pick all commits, even if unchanged
@@ -95,6 +96,7 @@ type=
state_dir=
# One of {'', continue, skip, abort}, as parsed from command line
action=
+rebase_fix=
preserve_merges=
autosquash=
test "$(git config --bool rebase.autosquash)" = "true" && autosquash=t
@@ -178,6 +180,22 @@ run_pre_rebase_hook () {
fi
}
+latest_merge_commit()
+{
+ max_nr_commits=$1
+
+ latest_merge=$(git rev-list -1 --merges HEAD)
+ if test -z "$latest_merge"
+ then
+ range=HEAD
+ else
+ range=$latest_merge..HEAD
+ fi
+
+ range_start=$(git rev-list -"$max_nr_commits" "$range" | tail -1)
+ echo $(git rev-parse $range_start^)
+}
+
test -f "$apply_dir"/applying &&
die 'It looks like git-am is in progress. Cannot rebase.'
@@ -220,6 +238,20 @@ do
-i)
interactive_rebase=explicit
;;
+ --fix)
+ interactive_rebase=explicit
+ rebase_fix=20
+ # Parse optional argument.
+ if test "${2#-}" = "$2"
+ then
+ if ! expr "$2" : "^[0-9]\+$" >/dev/null
+ then
+ die "Invalid argument to rebase --fix: $2"
+ fi
+ rebase_fix=$2
+ shift
+ fi
+ ;;
-p)
preserve_merges=t
test -z "$interactive_rebase" && interactive_rebase=implied
@@ -375,7 +407,10 @@ if test -z "$rebase_root"
then
case "$#" in
0)
- if ! upstream_name=$(git rev-parse --symbolic-full-name \
+ if test -n "$rebase_fix"
+ then
+ upstream_name=$(latest_merge_commit $rebase_fix)
+ elif ! upstream_name=$(git rev-parse --symbolic-full-name \
--verify -q @{upstream} 2>/dev/null)
then
. git-parse-remote
--
1.7.8
^ permalink raw reply related
* Re: [PATCH 4/6] revert: allow mixing "pick" and "revert" actions
From: Jonathan Nieder @ 2012-01-08 21:55 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Junio C Hamano
In-Reply-To: <20120108214042.GR1942@burratino>
Jonathan Nieder wrote:
> I'll pick up
> this patch, play around with it and send separately.
On second thought, do you have a link to the last submitted version,
and do you remember if there were any important changes since then?
The base for that one should be closer to "master", I think.
^ permalink raw reply
* Re: [PATCH] rebase --fix: interactive fixup mode
From: Jonathan Nieder @ 2012-01-08 22:01 UTC (permalink / raw)
To: Clemens Buchacher
Cc: git, Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <20120108213134.GA18671@ecki.lan>
Clemens Buchacher wrote:
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -332,6 +332,15 @@ link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
> user edit that list before rebasing. This mode can also be used to
> split commits (see SPLITTING COMMITS below).
>
> +--fix=<n>::
> + Searches commit history backwards from the current commit until the
> + most recent merge commit, or until a maximum of <n> preceding commits
> + (default: 20), and runs rebase -i <commit>^. The resulting range is
> + typically large enough to contain recent commits which the user might
> + want to edit, while avoiding the usually undesirable effects of
> + rebasing a merge commit, which obviates the need to find a suitable
> + base commit manually.
Funny. :) I wonder if this is possible to generalize, to something like
git rebase -i foo^{last-merge}
or even something like
git rebase -i foo^{first:--merges}
(where "<commit>^{first:<rev-list args>}" would mean something like
"the first commit listed by "git rev-list <rev-list args> <commit>").
What do you think?
^ permalink raw reply
* Re: [PATCH] rebase --fix: interactive fixup mode
From: Jakub Narebski @ 2012-01-08 21:57 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano
In-Reply-To: <20120108213134.GA18671@ecki.lan>
Clemens Buchacher <drizzd@aon.at> writes:
[...]
> In order to determine a suitable range automatically, it is a reasonable
> heuristic to rebase onto the most recent merge commit.
Why not additionally / instead take into account remote-tracking
branches for "push" remotes?
> It does not
> guarantee that published commits are not included -- indeed there is no
> way to do that. But, the range is usually large enough to contain the
> desired commits. Also, this mechanism works regardless of whether or not
> branch tracking has been configured.
>
> So instead of the above command, one can instead use the following:
>
> git rebase --fix
>
> By default, the range is limited to a maximum of 20 commits. This can be
> changed by passing a different number to --fix, e.g.:
>
> git rebase --fix=50
>
> Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Nice idea!
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] rebase --fix: interactive fixup mode
From: Clemens Buchacher @ 2012-01-08 22:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <m3r4z9eu36.fsf@localhost.localdomain>
On Sun, Jan 08, 2012 at 01:57:03PM -0800, Jakub Narebski wrote:
>
> > In order to determine a suitable range automatically, it is a reasonable
> > heuristic to rebase onto the most recent merge commit.
>
> Why not additionally / instead take into account remote-tracking
> branches for "push" remotes?
For me personally, remote-tracking does not work. I frequently branch
locally, and even if I do branch from a remote branch, it's often not
from a public branch, but rather my own private branch that I
synchronize between repos and machines. So my remote-tracking
configuration is usually an awful mess, and it does not feel like fixing
it up manually would be worth the trouble.
As a result, I don't trust remote-tracking and I do not use any of the
features associated with it. For my uses of rebase --fix it would
therefore be counter-productive to consider remote-tracking information.
What I did consider was adding a comment to the list of "pick <commit>"
that interactive rebase offers saying:
# older commits are already contained in the current upstream branch
Also, I often rewrite commits that are also contained in other branches.
That typically happens when I am reworking a topic that has already been
tested extensively. In that case I like to keep the original branch
around for reference, even if I end up not using it eventually.
^ permalink raw reply
* Re: SVN -> Git *but* with special changes
From: Abscissa @ 2012-01-08 22:28 UTC (permalink / raw)
To: git
In-Reply-To: <20120108120807.GA7360@angband.pl>
I see. That's strange, I've been using "apt-get upgrade xxx" for at least a
couple years, I can't believe I never knew that! Thanks for the detailed
info, everyone (and for the patience!)
In answer to someone's question, yea, it's Ubuntu (Kubuntu 10.04, and yea, I
know that's old, but it's not my primary system and I haven't had a chance
yet to upgrade it and get everything set back up again). I also tried it on
a Debian 6 Live/Persistent system and got the same results...apparently for
the same reason.
I did manage to get 1.7.8 installed (on both systems) by downloading and
installing the source (it was kind of a pain figuring out the names of some
of the dependent packages, but I managed to get it.)
So hopefully this should all work now...
--
View this message in context: http://git.661346.n2.nabble.com/SVN-Git-but-with-special-changes-tp6840904p7165979.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] rebase --fix: interactive fixup mode
From: Clemens Buchacher @ 2012-01-08 22:25 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <20120108220127.GA4050@burratino>
On Sun, Jan 08, 2012 at 04:01:27PM -0600, Jonathan Nieder wrote:
>
> Funny. :) I wonder if this is possible to generalize, to something like
>
> git rebase -i foo^{last-merge}
>
> What do you think?
I suppose if the history has no merges, I would return the root commit?
Uh, and now I realize I have a bug. In a repo with only linear history:
$ git rebase --fix
fatal: ambiguous argument '4ccf67b9fa2ae247e55b86648d650cb368f286c2^': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
fatal: Needed a single revision
invalid upstream 4ccf67b9fa2ae247e55b86648d650cb368f286c2^
^ permalink raw reply
* Re: [PATCH] rebase --fix: interactive fixup mode
From: Junio C Hamano @ 2012-01-08 22:58 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <20120108213134.GA18671@ecki.lan>
Clemens Buchacher <drizzd@aon.at> writes:
> Interactive rebase is frequently used not to rebase history, but to
> manipulate recent commits. This is typically done using the following
> command:
>
> git rebase -i HEAD~N
>
> Where N has to be large enough such that the the range HEAD~N..HEAD
> contains the desired commits. At the same time, it should be small
> enough such that the range HEAD~N..HEAD does not include published
> commits or a merge commit. Otherwise, the user may accidentally change
> published history. Rebasing a merge commit can also have the generally
> undesirable effect of linearizing the merge history.
>
> In order to determine a suitable range automatically, it is a reasonable
> heuristic to rebase onto the most recent merge commit.
I understand the problem you are trying to solve, but I am not sure if
this is a good idea from the UI point of view for two reasons.
- "We want to limit the extent of the operation to commits since the last
merge" is by itself a reasonable thing to ask, and I do not think it
should be limited to "rebase". If we had an extended SHA-1 syntax to
express it, for example, you may want to say "I want to see what I did
since the last merge" and run "git log $last_merge_before_HEAD..".
Perhaps HEAD~{merge} or something?
- If your "rebase --fix" is to "fix" things, what is "rebase -i" about?
Isn't it also about fixing? I imagine that ordinary people expect a
"fix" option that takes a parameter would take a commit to be fixed,
and drive the rebase machinery to quickly fix it; in other words,
$ git rebase --fix=':/^reword the greeting message'
may internally run "rebase -i $(git rev-parse ':/^rewor...')^", with
the insn sheet already prepared to "edit" the first commit in it, and
may even return the control back to the user without showing the insn
sheet in the editor.
Hmm?
^ permalink raw reply
* Re: SVN -> Git *but* with special changes
From: Abscissa @ 2012-01-08 23:38 UTC (permalink / raw)
To: git
In-Reply-To: <1326061722334-7165979.post@n2.nabble.com>
Damn. That 'git-svn-migrate' tool is just giving me errors now. It just gets
through little over 10% of the revisions, and gives:
-----------------------------
Failed to strip path 'bin/lang/.gitignore' ((?-xism:^trunk(/|$)))
- Converting svn:ignore properties into a .gitignore file...
fatal: ambiguous argument 'HEAD': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
log --no-color --no-decorate --first-parent --pretty=medium HEAD: command
returned error: 128
-----------------------------
And then it keeps going and gives:
-----------------------------
To /var/git/Goldie.git
! [rejected] master -> trunk (non-fast-forward)
error: failed to push some refs to '/var/git/Goldie.git'
To prevent you from losing history, non-fast-forward updates were rejected
-----------------------------
I guess I'll have to try some other approach. :/
--
View this message in context: http://git.661346.n2.nabble.com/SVN-Git-but-with-special-changes-tp6840904p7166084.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Aborting "git commit --interactive" discards updates to index
From: Junio C Hamano @ 2012-01-09 0:41 UTC (permalink / raw)
To: demerphq; +Cc: git, Ævar Arnfjörð
In-Reply-To: <CANgJU+WGEBMMQzsGyQSnMBK3Q8Z2XZdbDx4nr-tB-s0uYEU9CQ@mail.gmail.com>
demerphq <demerphq@gmail.com> writes:
> On 7 January 2012 06:08, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> You are welcome to rehash the age old discussion, though. Personally I do
>> not care very deeply either way. I would never use "commit --interactive"
>> myself, and I would not encourage others to use it, either, even if we do
>> not worry about the behaviour when a commit is aborted.
>
> If I were to provide a patch to make this behavior configurable would
> you have any objections?
You are welcome to rehash the discussion.
I am not a dictator and will listen to other people on the list for their
opinions, and I cannot say if such a patch will be accepted or not without
seeing how well it is done.
>> ... off to run "git add -i" to prepare the index, "git stash save -k" to check
>> out what is to be committed (and stash away what are to be left out) so
>> that you can make sure what you are committing is what you thought are
>> committing (by asking "git diff" and "make test" for example), and after
>
> Isnt this what the diff option in commit interactive is for?
Not at all.
That is to help the user incrementally in the process and not a
replacement for the final eyeballing of the result.
Neither the patch shown in "commit -v", whose primary purpose is to aid
the user to write a better log message.
^ permalink raw reply
* Re: [PATCH] rebase --fix: interactive fixup mode
From: Nguyen Thai Ngoc Duy @ 2012-01-09 1:44 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Clemens Buchacher, git, Junio C Hamano
In-Reply-To: <20120108220127.GA4050@burratino>
2012/1/9 Jonathan Nieder <jrnieder@gmail.com>:
> Funny. :) I wonder if this is possible to generalize, to something like
>
> git rebase -i foo^{last-merge}
>
> or even something like
>
> git rebase -i foo^{first:--merges}
>
> (where "<commit>^{first:<rev-list args>}" would mean something like
> "the first commit listed by "git rev-list <rev-list args> <commit>").
> What do you think?
Is something like this over-generalized?
http://kerneltrap.org/mailarchive/git/2010/12/24/47502
A good thing I see from having a specific option for "-i HEAD~n" is
that it's potentially shorter to type. For someone who does rebase a
lot and has CapsLock turned to Ctrl, it helps. Maybe "rebase -I" ==
"rebase -i HEAD^{last-merge}" (or "rebase -i
<the-revision-used-last-time>") and "rebase -I <n>" == "rebase -i
HEAD~<n>"?
--
Duy
^ permalink raw reply
* Re: [PATCH] Work around sed portability issue in t8006-blame-textconv
From: Ben Walton @ 2012-01-09 3:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vehvcigsy.fsf@alter.siamese.dyndns.org>
Excerpts from Junio C Hamano's message of Fri Jan 06 17:53:33 -0500 2012:
> Ping?
Sorry, I was out of email contact since last Sunday. I'll look at
this tomorrow. I think I tested the exit status from
/usr/xpg4/bin/sed on this file by hand and found that it was exiting
cleanly, but I'll verify and let you know. If you're correct, I'll
adjust the commit message accordingly.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply
* [PATCH v2 0/3] nd/index-pack-no-recurse
From: Nguyễn Thái Ngọc Duy @ 2012-01-09 3:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1324901080-23215-1-git-send-email-pclouds@gmail.com>
Resend to incorporate the fixup commit from pu, no other changes.
Nguyễn Thái Ngọc Duy (3):
Eliminate recursion in setting/clearing marks in commit list
index-pack: eliminate recursion in find_unresolved_deltas
index-pack: eliminate unlimited recursion in get_delta_base()
builtin/index-pack.c | 141 ++++++++++++++++++++++++++++++++------------------
commit.c | 13 ++++-
revision.c | 45 ++++++++++------
3 files changed, 131 insertions(+), 68 deletions(-)
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply
* [PATCH v2 2/3] index-pack: eliminate recursion in find_unresolved_deltas
From: Nguyễn Thái Ngọc Duy @ 2012-01-09 3:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1324901080-23215-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/index-pack.c | 111 +++++++++++++++++++++++++++++++------------------
1 files changed, 70 insertions(+), 41 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index af7dc37..38ff03a 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -34,6 +34,8 @@ struct base_data {
struct object_entry *obj;
void *data;
unsigned long size;
+ int ref_first, ref_last;
+ int ofs_first, ofs_last;
};
/*
@@ -221,6 +223,15 @@ static NORETURN void bad_object(unsigned long offset, const char *format, ...)
die("pack has bad object at offset %lu: %s", offset, buf);
}
+static struct base_data *alloc_base_data(void)
+{
+ struct base_data *base = xmalloc(sizeof(struct base_data));
+ memset(base, 0, sizeof(*base));
+ base->ref_last = -1;
+ base->ofs_last = -1;
+ return base;
+}
+
static void free_base_data(struct base_data *c)
{
if (c->data) {
@@ -553,58 +564,76 @@ static void resolve_delta(struct object_entry *delta_obj,
nr_resolved_deltas++;
}
-static void find_unresolved_deltas(struct base_data *base,
- struct base_data *prev_base)
+static struct base_data *find_unresolved_deltas_1(struct base_data *base,
+ struct base_data *prev_base)
{
- int i, ref_first, ref_last, ofs_first, ofs_last;
-
- /*
- * This is a recursive function. Those brackets should help reducing
- * stack usage by limiting the scope of the delta_base union.
- */
- {
+ if (base->ref_last == -1 && base->ofs_last == -1) {
union delta_base base_spec;
hashcpy(base_spec.sha1, base->obj->idx.sha1);
find_delta_children(&base_spec,
- &ref_first, &ref_last, OBJ_REF_DELTA);
+ &base->ref_first, &base->ref_last, OBJ_REF_DELTA);
memset(&base_spec, 0, sizeof(base_spec));
base_spec.offset = base->obj->idx.offset;
find_delta_children(&base_spec,
- &ofs_first, &ofs_last, OBJ_OFS_DELTA);
- }
+ &base->ofs_first, &base->ofs_last, OBJ_OFS_DELTA);
- if (ref_last == -1 && ofs_last == -1) {
- free(base->data);
- return;
- }
+ if (base->ref_last == -1 && base->ofs_last == -1) {
+ free(base->data);
+ return NULL;
+ }
- link_base_data(prev_base, base);
+ link_base_data(prev_base, base);
+ }
- for (i = ref_first; i <= ref_last; i++) {
- struct object_entry *child = objects + deltas[i].obj_no;
- struct base_data result;
+ if (base->ref_first <= base->ref_last) {
+ struct object_entry *child = objects + deltas[base->ref_first].obj_no;
+ struct base_data *result = alloc_base_data();
assert(child->real_type == OBJ_REF_DELTA);
- resolve_delta(child, base, &result);
- if (i == ref_last && ofs_last == -1)
+ resolve_delta(child, base, result);
+ if (base->ref_first == base->ref_last && base->ofs_last == -1)
free_base_data(base);
- find_unresolved_deltas(&result, base);
+
+ base->ref_first++;
+ return result;
}
- for (i = ofs_first; i <= ofs_last; i++) {
- struct object_entry *child = objects + deltas[i].obj_no;
- struct base_data result;
+ if (base->ofs_first <= base->ofs_last) {
+ struct object_entry *child = objects + deltas[base->ofs_first].obj_no;
+ struct base_data *result = alloc_base_data();
assert(child->real_type == OBJ_OFS_DELTA);
- resolve_delta(child, base, &result);
- if (i == ofs_last)
+ resolve_delta(child, base, result);
+ if (base->ofs_first == base->ofs_last)
free_base_data(base);
- find_unresolved_deltas(&result, base);
+
+ base->ofs_first++;
+ return result;
}
unlink_base_data(base);
+ return NULL;
+}
+
+static void find_unresolved_deltas(struct base_data *base)
+{
+ struct base_data *new_base, *prev_base = NULL;
+ for (;;) {
+ new_base = find_unresolved_deltas_1(base, prev_base);
+
+ if (new_base) {
+ prev_base = base;
+ base = new_base;
+ } else {
+ free(base);
+ base = prev_base;
+ if (!base)
+ return;
+ prev_base = base->base;
+ }
+ }
}
static int compare_delta_entry(const void *a, const void *b)
@@ -684,13 +713,13 @@ static void parse_pack_objects(unsigned char *sha1)
progress = start_progress("Resolving deltas", nr_deltas);
for (i = 0; i < nr_objects; i++) {
struct object_entry *obj = &objects[i];
- struct base_data base_obj;
+ struct base_data *base_obj = alloc_base_data();
if (is_delta_type(obj->type))
continue;
- base_obj.obj = obj;
- base_obj.data = NULL;
- find_unresolved_deltas(&base_obj, NULL);
+ base_obj->obj = obj;
+ base_obj->data = NULL;
+ find_unresolved_deltas(base_obj);
display_progress(progress, nr_resolved_deltas);
}
}
@@ -783,20 +812,20 @@ static void fix_unresolved_deltas(struct sha1file *f, int nr_unresolved)
for (i = 0; i < n; i++) {
struct delta_entry *d = sorted_by_pos[i];
enum object_type type;
- struct base_data base_obj;
+ struct base_data *base_obj = alloc_base_data();
if (objects[d->obj_no].real_type != OBJ_REF_DELTA)
continue;
- base_obj.data = read_sha1_file(d->base.sha1, &type, &base_obj.size);
- if (!base_obj.data)
+ base_obj->data = read_sha1_file(d->base.sha1, &type, &base_obj->size);
+ if (!base_obj->data)
continue;
- if (check_sha1_signature(d->base.sha1, base_obj.data,
- base_obj.size, typename(type)))
+ if (check_sha1_signature(d->base.sha1, base_obj->data,
+ base_obj->size, typename(type)))
die("local object %s is corrupt", sha1_to_hex(d->base.sha1));
- base_obj.obj = append_obj_to_pack(f, d->base.sha1,
- base_obj.data, base_obj.size, type);
- find_unresolved_deltas(&base_obj, NULL);
+ base_obj->obj = append_obj_to_pack(f, d->base.sha1,
+ base_obj->data, base_obj->size, type);
+ find_unresolved_deltas(base_obj);
display_progress(progress, nr_resolved_deltas);
}
free(sorted_by_pos);
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* [PATCH v2 1/3] Eliminate recursion in setting/clearing marks in commit list
From: Nguyễn Thái Ngọc Duy @ 2012-01-09 3:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1324901080-23215-1-git-send-email-pclouds@gmail.com>
Recursion in a DAG is generally a bad idea because it could be very
deep. Be defensive and avoid recursion in mark_parents_uninteresting()
and clear_commit_marks().
mark_parents_uninteresting() learns a trick from clear_commit_marks()
to avoid malloc() in (dorminant) single-parent case.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
commit.c | 13 +++++++++++--
revision.c | 45 +++++++++++++++++++++++++++++----------------
2 files changed, 40 insertions(+), 18 deletions(-)
diff --git a/commit.c b/commit.c
index 44bc96d..c7aefbf 100644
--- a/commit.c
+++ b/commit.c
@@ -421,7 +421,8 @@ struct commit *pop_most_recent_commit(struct commit_list **list,
return ret;
}
-void clear_commit_marks(struct commit *commit, unsigned int mark)
+static void clear_commit_marks_1(struct commit_list **plist,
+ struct commit *commit, unsigned int mark)
{
while (commit) {
struct commit_list *parents;
@@ -436,12 +437,20 @@ void clear_commit_marks(struct commit *commit, unsigned int mark)
return;
while ((parents = parents->next))
- clear_commit_marks(parents->item, mark);
+ commit_list_insert(parents->item, plist);
commit = commit->parents->item;
}
}
+void clear_commit_marks(struct commit *commit, unsigned int mark)
+{
+ struct commit_list *list = NULL;
+ commit_list_insert(commit, &list);
+ while (list)
+ clear_commit_marks_1(&list, pop_commit(&list), mark);
+}
+
void clear_commit_marks_for_object_array(struct object_array *a, unsigned mark)
{
struct object *object;
diff --git a/revision.c b/revision.c
index 8764dde..7cc72fc 100644
--- a/revision.c
+++ b/revision.c
@@ -139,11 +139,32 @@ void mark_tree_uninteresting(struct tree *tree)
void mark_parents_uninteresting(struct commit *commit)
{
- struct commit_list *parents = commit->parents;
+ struct commit_list *parents = NULL, *l;
+
+ for (l = commit->parents; l; l = l->next)
+ commit_list_insert(l->item, &parents);
while (parents) {
struct commit *commit = parents->item;
- if (!(commit->object.flags & UNINTERESTING)) {
+ l = parents;
+ parents = parents->next;
+ free(l);
+
+ while (commit) {
+ /*
+ * A missing commit is ok iff its parent is marked
+ * uninteresting.
+ *
+ * We just mark such a thing parsed, so that when
+ * it is popped next time around, we won't be trying
+ * to parse it and get an error.
+ */
+ if (!has_sha1_file(commit->object.sha1))
+ commit->object.parsed = 1;
+
+ if (commit->object.flags & UNINTERESTING)
+ break;
+
commit->object.flags |= UNINTERESTING;
/*
@@ -154,21 +175,13 @@ void mark_parents_uninteresting(struct commit *commit)
* wasn't uninteresting), in which case we need
* to mark its parents recursively too..
*/
- if (commit->parents)
- mark_parents_uninteresting(commit);
- }
+ if (!commit->parents)
+ break;
- /*
- * A missing commit is ok iff its parent is marked
- * uninteresting.
- *
- * We just mark such a thing parsed, so that when
- * it is popped next time around, we won't be trying
- * to parse it and get an error.
- */
- if (!has_sha1_file(commit->object.sha1))
- commit->object.parsed = 1;
- parents = parents->next;
+ for (l = commit->parents->next; l; l = l->next)
+ commit_list_insert(l->item, &parents);
+ commit = commit->parents->item;
+ }
}
}
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* [PATCH v2 3/3] index-pack: eliminate unlimited recursion in get_delta_base()
From: Nguyễn Thái Ngọc Duy @ 2012-01-09 3:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1324901080-23215-1-git-send-email-pclouds@gmail.com>
Revert the order of delta applying so that by the time a delta is
applied, its base is either non-delta or already inflated.
get_delta_base() is still recursive, but because base's data is always
ready, the inner get_delta_base() call never has any chance to call
itself again.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/index-pack.c | 30 +++++++++++++++++++++---------
1 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 38ff03a..8c1f5d9 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -519,10 +519,25 @@ static void *get_base_data(struct base_data *c)
{
if (!c->data) {
struct object_entry *obj = c->obj;
+ struct base_data **delta = NULL;
+ int delta_nr = 0, delta_alloc = 0;
- if (is_delta_type(obj->type)) {
- void *base = get_base_data(c->base);
- void *raw = get_data_from_pack(obj);
+ for (; is_delta_type(c->obj->type); c = c->base) {
+ ALLOC_GROW(delta, delta_nr + 1, delta_alloc);
+ delta[delta_nr++] = c;
+ }
+ if (!delta_nr) {
+ c->data = get_data_from_pack(obj);
+ c->size = obj->size;
+ base_cache_used += c->size;
+ prune_base_data(c);
+ }
+ for (; delta_nr > 0; delta_nr--) {
+ void *base, *raw;
+ c = delta[delta_nr - 1];
+ obj = c->obj;
+ base = get_base_data(c->base);
+ raw = get_data_from_pack(obj);
c->data = patch_delta(
base, c->base->size,
raw, obj->size,
@@ -530,13 +545,10 @@ static void *get_base_data(struct base_data *c)
free(raw);
if (!c->data)
bad_object(obj->idx.offset, "failed to apply delta");
- } else {
- c->data = get_data_from_pack(obj);
- c->size = obj->size;
+ base_cache_used += c->size;
+ prune_base_data(c);
}
-
- base_cache_used += c->size;
- prune_base_data(c);
+ free(delta);
}
return c->data;
}
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* Re: SVN -> Git *but* with special changes
From: Michael Haggerty @ 2012-01-09 8:26 UTC (permalink / raw)
To: Abscissa; +Cc: git
In-Reply-To: <1326061722334-7165979.post@n2.nabble.com>
On 01/08/2012 11:28 PM, Abscissa wrote:
> In answer to someone's question, yea, it's Ubuntu (Kubuntu 10.04, and yea, I
> know that's old, but it's not my primary system and I haven't had a chance
> yet to upgrade it and get everything set back up again). I also tried it on
> a Debian 6 Live/Persistent system and got the same results...apparently for
> the same reason.
For Ubuntu users: there is a git PPA [1] which usually has quite
up-to-date git packages for recent Ubuntu releases. If you configure
your system to use this PPA (instructions are on the page) then you can
stay up-to-date with minimal effort. Currently they have version
1.7.8.2 available for hardy, lucid, maverick, natty, and oneiric and
older versions for some other Ubuntu releases.
Caveat: I am not affiliated with the PPA and cannot vouch for its integrity.
Michael
[1] https://launchpad.net/~git-core/+archive/ppa
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Mark and protect local commits?
From: norbert.nemec @ 2012-01-09 8:29 UTC (permalink / raw)
To: git
Hi there,
I have often wished that there were ways to
a) protect certain commits from leaving the local repository
b) mark commits that have already left the local repository
To be more specific:
a) Sometimes, I try out certain experimental features and want to make
sure they don't accidentally end up out in the wild. If there were a
flag to explicitly mark them "private", any non-local operation (push,
pull, etc) on these commits could create an error message.
b) For history-rewriting operations, it is important to know which
commits are out in the wild and which are not. In a "push"-setup working
copy, git should be able to keep track of this. Any newly created commit
would be marked as "unpublished" and the mark would be removed when the
commit is pushed. Any history-rewriting would be prevented on published
commits.
Has anyone else thought along these lines?
Greetings,
Norbert
^ permalink raw reply
* Re: [PATCH] rebase --fix: interactive fixup mode
From: Jonathan Nieder @ 2012-01-09 8:43 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Clemens Buchacher, git, Junio C Hamano
In-Reply-To: <CACsJy8CKK0EAy79Fahi64bUw2kfr=eunegbeA7oX_XaXEBFr2g@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> Is something like this over-generalized?
>
> http://kerneltrap.org/mailarchive/git/2010/12/24/47502
Yes, I suspect that at the moment (i.e., in the absence of a large
collection of examples to show their utility), both your ^{~custom}
and my ^{first:rev-list args} are overengineered, and that they do
something that is more clearly expressed using the shell's command
substitution feature:
git rebase -i $(git rev-list --merges HEAD | head -1)
So why did I suggest it?
I guess I was reacting to the implementation of the
rebase-recent-commits command. I understand that it was a sketch, but
it felt a little ad hoc. If it could be expressed as a clean
two-liner, I would be more comfortable since the burden of maintaining
it would be less.
Thanks for clarifying.
Sincerely,
Jonathan
^ permalink raw reply
* Re: [PATCH] rebase --fix: interactive fixup mode
From: Michael Haggerty @ 2012-01-09 8:40 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano
In-Reply-To: <20120108213134.GA18671@ecki.lan>
On 01/08/2012 10:31 PM, Clemens Buchacher wrote:
> Interactive rebase is frequently used not to rebase history, but to
> manipulate recent commits. This is typically done using the following
> command:
>
> git rebase -i HEAD~N
>
> Where N has to be large enough such that the the range HEAD~N..HEAD
> contains the desired commits. At the same time, it should be small
> enough such that the range HEAD~N..HEAD does not include published
> commits or a merge commit. Otherwise, the user may accidentally change
> published history. Rebasing a merge commit can also have the generally
> undesirable effect of linearizing the merge history.
>
> In order to determine a suitable range automatically, it is a reasonable
> heuristic to rebase onto the most recent merge commit. It does not
> guarantee that published commits are not included -- indeed there is no
> way to do that. But, the range is usually large enough to contain the
> desired commits. Also, this mechanism works regardless of whether or not
> branch tracking has been configured.
>
> So instead of the above command, one can instead use the following:
>
> git rebase --fix
Two comments:
* The name "--fix" might be confusing because of its similarity to the
"fixup" command that can be specified in the interactive instructions file.
* I agree with you that "interactive rebase is frequently used not to
rebase history, but to manipulate recent commits". In fact, I use
interactive rebase *only* for manipulating recent commits and
non-interactive rebase *only* for changing commits' ancestry. I think
it is a good idea to make these two uses more distinct. For example, it
makes me nervous that I might mis-type the <upstream> parameter when I
am trying to touch up commits and end up inadvertently rebasing the
commits onto a new parent.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] rebase --fix: interactive fixup mode
From: Thomas Rast @ 2012-01-09 9:13 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano
In-Reply-To: <20120108213134.GA18671@ecki.lan>
Clemens Buchacher <drizzd@aon.at> writes:
> Interactive rebase is frequently used not to rebase history, but to
> manipulate recent commits. This is typically done using the following
> command:
>
> git rebase -i HEAD~N
>
> Where N has to be large enough such that the the range HEAD~N..HEAD
> contains the desired commits. At the same time, it should be small
> enough such that the range HEAD~N..HEAD does not include published
> commits or a merge commit.
[...]
> git rebase --fix
>
> By default, the range is limited to a maximum of 20 commits.
Given the name I would expect --fix to rebase far enough to make recent
fixup!/squash! commits take effect. Perhaps name it --recent?
(And I also think that the 20 is rather arbitrary...)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] git-gui: fix selection regression introduced in a8ca786991
From: Bert Wesarg @ 2012-01-09 9:28 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, Bert Wesarg, Shawn O. Pearce
In-Reply-To: <14628854a651ab0202e3f82be9b245331cf9029a.1325965254.git.bert.wesarg@googlemail.com>
Hi,
On Sat, Jan 7, 2012 at 20:43, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> While fixing the problem from a8ca786991, it introduces a regression
> regarding what happen after the multi selected file operation (ie.
> one of Ctrl-{T,U,J}) because the next selected file could not be handled
> by such a subsequent file operation.
>
> The right way is to move the fix from this commit down into the show_diff
> function. So that all code path add the current diff path to the list of
> selections.
>
> This also simplifies helper functions for these operatione which needed
> to handle the case whether there is only the current diff path or also
> a selction.
I think we need to think this more through, especially with input from
Shawn, please.
I have now find out, that git-gui has two selections in the file
lists. The first is that for the current path for what we show the
diff (the tag for this is called 'in_diff') and the the second is that
for the current list of paths which are selected ('in_sel'). The file
list operations 'staging', 'reverting', 'unstaging', work either on
'in_sel'; if that is not empty, or on 'in_diff'. The problem I've now
realized is, that these two selections share the same visual hints,
ie. a lightgray background.
The problem I tried to solve in a8ca786991 was, that adding paths to
the selection with Ctrl-Button-1 or Shift-cutton-1, didn't included
the current diff path in the subsequent file list operation. But I
would have expected it, because it was visual in the 'selection'.
My current 'workaround' is to make the two selections visually
distinguishable (and reverting a8ca786991), by using a different
background color for the 'in_sel' tag and also the italic font, so
that it is still possible to see whether the current diff path is in
the selection or not:
@@ -717,11 +717,11 @@ proc tk_optionMenu {w varName args} {
proc rmsel_tag {text} {
$text tag conf sel \
-background [$text cget -background] \
-foreground [$text cget -foreground] \
-borderwidth 0
- $text tag conf in_sel -background lightgray
+ $text tag conf in_sel -background SlateGray1 -font font_diffitalic
bind $text <Motion> break
return $text
}
wm withdraw .
@@ -3557,11 +3557,11 @@ if {$use_ttk} {
.vpane.files add .vpane.files.index -sticky news
}
foreach i [list $ui_index $ui_workdir] {
rmsel_tag $i
- $i tag conf in_diff -background [$i tag cget in_sel -background]
+ $i tag conf in_diff -background lightgray
}
unset i
set files_ctxm .vpane.files.ctxm
menu $files_ctxm -tearoff 0
I'm not very pleased with this, but at least it is now possible to
visual recognize what files will be handled by a subsequent file list
operation.
Any input is more than welcome.
Regards,
Bert
^ 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