On Mon, Jan 14, 2013 at 11:28 AM, Ramsay Jones
wrote:
>
> In particular, sparse issues an "symbol not declared. Should it be
> static?" warning for the 'parse_args' function. Since this function
> does not require greater than file visibility, we suppress this
> warning by simply adding the static
On Sun, Jan 13, 2013 at 4:35 AM, Nguyễn Thái Ngọc Duy wrote:
> +static void parse_pathspec(struct pathspec *pathspec,
> + unsigned magic_mask, unsigned flags,
> + const char *prefix, const char **argv)
> +{
> + struct pathspec_item *item;
> +
On Fri, Jan 11, 2013 at 3:20 AM, Nguyễn Thái Ngọc Duy wrote:
>
> diff --git a/cache.h b/cache.h
> index e52365d..a3c316f 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -476,6 +476,9 @@ extern int ie_modified(const struct index_state *, struct
> cache_entry *, struct
> /* Pathspec magic */
> #defin
On Wed, Jan 9, 2013 at 11:53 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> ---
>> builtin/reset.c | 13 +++--
>> 1 file changed, 3 insertions(+), 10 deletions(-)
>>
>> diff --git a/builtin/reset.c b/builtin/reset.c
>> inde
On Sat, Jan 5, 2013 at 10:20 PM, Nguyễn Thái Ngọc Duy wrote:
> +
> + /* No arguments, no prefix -> no pathspec */
> + if (!entry && !prefix)
> + return;
>
> + /* No arguments with prefix -> prefix pathspec */
When working with the old get_pathspec(), I remember won
On Wed, Jan 9, 2013 at 11:48 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> Use a single condition to guard the call to die_if_unmerged_cache for
>> both --soft and --keep. This avoids the small distraction of the
>> precondition check from the logic
On Wed, Jan 9, 2013 at 11:39 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> Throughout most of parse_args(), the variable 'i' remains at 0. In the
>> remaining few cases, we can do pointer arithmentic on argv itself
>> instead.
>> ---
>
On Wed, Jan 9, 2013 at 11:32 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> ---
>> builtin/reset.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> With the patch that does not have any explicit check for bareness
> nor new err
On Wed, Jan 9, 2013 at 11:12 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
> And as a Porcelain, I would rather expect it to leave the resulting
> index refreshed.
Yeah, I guess you're right. Regular users (those using only porcelain)
shouldn't notice, but
On Wed, Jan 9, 2013 at 9:01 AM, Jeff King wrote:
> On Wed, Jan 09, 2013 at 12:16:13AM -0800, Martin von Zweigbergk wrote:
>
>> "git reset [--mixed]" without --quiet refreshes the index in order to
>> display the "Unstaged changes after reset". When --quiet
The final part of cmd_reset() essentially looks like:
if (pathspec) {
...
read_from_tree(...);
} else {
...
reset_index(...);
update_index_refresh(...);
...
}
where read_from_tree() internally also calls
update_index_refresh(). Move the call to update_index_refresh()
Some users seem to think, knowingly or not, that being on an unborn
branch is like having a commit with an empty tree checked out, but
when run on an unborn branch, "git reset" currently fails with:
fatal: Failed to resolve 'HEAD' as a valid ref.
Instead of making users figure out that they sho
We use the path arguments in two places in reset.c: in
interactive_reset() and read_from_tree(). Both of these call
get_pathspec(), so we pass the (prefix, arv) pair to both
functions. Move the call to get_pathspec() out of these methods, for
two reasons: 1) One argument is simpler than two. 2) It
If writing or committing the new index file fails, we print "Could not
write new index file." followed by "Could not reset index file to
revision $rev.". The first message seems to imply the second, so print
only the first message.
---
builtin/reset.c | 8 +++-
1 file changed, 3 insertions(+),
Throughout most of parse_args(), the variable 'i' remains at 0. In the
remaining few cases, we can do pointer arithmentic on argv itself
instead.
---
This is clearly mostly a matter of taste. The remainder of the series
does not depend on it in any way.
builtin/reset.c | 29 ++
By extracting the code for updating the HEAD and ORIG_HEAD symbolic
references to a separate function, we declutter cmd_reset() a bit and
we make it clear that e.g. the four variables {,sha1_}{,old_}orig are
only used by this code.
---
builtin/reset.c | 39 +++
"git reset [--mixed]" without --quiet refreshes the index in order to
display the "Unstaged changes after reset". When --quiet is given,
that output is suppressed, removing the need to refresh the index.
Other porcelain commands that care about a refreshed index should
already be refreshing it, so
Use a single condition to guard the call to die_if_unmerged_cache for
both --soft and --keep. This avoids the small distraction of the
precondition check from the logic following it.
Also change an instance of
if (e)
err = err || f();
to the almost as short, but clearer
if (e && !err)
--keep -q (cold) 7.377.21
[1] http://thread.gmane.org/gmane.comp.version-control.git/210568/focus=210855
Martin von Zweigbergk (19):
reset $pathspec: no need to discard index
reset $pathspec: exit with code 0 if successful
reset.c: pass pathspec around instead of (prefix, argv) pair
Resetting with paths does not update HEAD and there is nothing else
that a commit should be needed for. Relax the argument parsing so only
a tree is required.
The sha1 is only passed to read_from_tree(), which already only
requires a tree.
The "rev" variable we pass to run_add_interactive() will
---
builtin/reset.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 42d1563..05ccfd4 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -351,18 +351,11 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
Since 34110cd (Make 'unpack_trees()' have a separate source and
destination index, 2008-03-06), the index no longer gets clobbered by
do_diff_cache() and we can remove the code for discarding and
re-reading it.
There are two paths to update_index_refresh() from cmd_reset(), but on
both paths, eith
In preparation for the/a following patch, move the locking, writing
and committing of the index file out of update_index_refresh(). The
code duplication caused will soon be taken care of. What remains of
update_index_refresh() is just one line, but it is still called from
two places, so let's leave
"git reset --keep" calls reset_index_file() twice, first doing a
two-way merge to the target revision, updating the index and worktree,
and then resetting the index. After each call, we write the index
file.
In the unlikely event that the second call to reset_index_file()
fails, the index will hav
Thanks to b65982b (Optimize "diff-index --cached" using cache-tree,
2009-05-20), resetting with paths is much faster than resetting
without paths. Some timings for the linux-2.6 repo to illustrate this
(best of five, warm cache):
reset reset .
real0m0.219s0m0.080s
user0m0
By not returning from inside the "if (pathspec)" block, we can let the
pathspec-aware and pathspec-less code share a bit more, making it
easier to make future changes that should affect both cases. This also
highlights the similarity between read_from_tree() and reset_index().
---
Should error repo
Declutter cmd_reset() a bit by moving out the argument parsing to its
own function.
---
builtin/reset.c | 71 ++---
1 file changed, 38 insertions(+), 33 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 664fad9..9473725 100644
--
"git reset $pathspec" currently exits with a non-zero exit code if the
worktree is dirty after resetting, which is inconsistent with reset
without pathspec, and it makes it harder to know whether the command
really failed. Change it to exit with code 0 regardless of whether the
worktree is dirty so
When doing a mixed reset without paths, the index is locked, read,
reset, and written back as part of the actual reset operation (in
reset_index()). Then, when showing the list of worktree modifications,
we lock the index again, refresh it, and write it.
Change this so we only write the index once
---
builtin/reset.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 045c960..664fad9 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -295,8 +295,6 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
> diff --git a/Makefile b/Makefile
> index 26b697d..2f5e2ab 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2167,8 +2167,14 @@ configure: configure.ac GIT-VERSION-FILE
> $(RM) $<+
>
> ifdef AUTOCONFIGURED
> -config.status: configure
> - $(QUIET_GEN)if test -f config.status; then \
> +
On Tue, Jan 1, 2013 at 11:21 PM, Jonathan Nieder wrote:
>
> How about this patch (untested)?
Looks good. Thanks!
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -2267,12 +2267,9 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % :
>> unimplemented.sh
>> mv $@+ $@
>> endif # NO_PYTHON
>>
>> -configure
Hi,
I use autoconf with git.git. I have noticed lately, especially when
doing things like "git rebase -i --exec make", that ./configure is run
every time. If I understand correctly, this is because of 8242ff4
(build: reconfigure automatically if configure.ac changes,
2012-07-19). Just a few days b
On Thu, Dec 27, 2012 at 9:15 PM, Woody Wu wrote:
> On Mon, Dec 24, 2012 at 09:24:39AM -0800, Martin von Zweigbergk wrote:
>> On Sun, Dec 23, 2012 at 11:31 PM, Woody Wu wrote:
>> >
>> > This is not working to me since I have more than one local branch that
>> &
On Sun, Dec 23, 2012 at 11:31 PM, Woody Wu wrote:
> On Sun, Dec 23, 2012 at 11:09:58PM -0500, Seth Robertson wrote:
>>
>> In message <20121224035825.GA17203@zuhnb712>, Woody Wu writes:
>>
>> How can I find out what's the staring reference point (a commit number
>> or tag name) of a locally
On Sun, Dec 23, 2012 at 11:18 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>> On Sat, Dec 22, 2012 at 7:24 PM, Junio C Hamano wrote:
>
> I am not opposed to an "internal use" of the cherry-pick machinery to
> implement a corner case of "rebase -i&qu
On Sat, Dec 22, 2012 at 7:24 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>>>From the user's point of view, it seems natural to think that
>> cherry-picking into an unborn branch should work, so make it work,
>> with or without --ff.
>
> I ac
but will
result in conflicts unless the specified revision only deletes files.
Signed-off-by: Martin von Zweigbergk
---
The plan is to use this for fixing "git rebase --root" as discussed in
http://thread.gmane.org/gmane.comp.version-control.git/205796
Is there a better way of creating an
A function for checking that two given parameters refer to the same
revision was defined in several places, so move the definition to
test-lib-functions.sh instead.
Signed-off-by: Martin von Zweigbergk
---
t/t1505-rev-parse-last.sh | 18 +-
t/t3404-rebase
Oops, meant for all of you.
-- Forwarded message --
From: Martin von Zweigbergk
Date: Fri, Dec 21, 2012 at 8:45 AM
Subject: Re: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
To: Junio C Hamano
On Fri, Dec 21, 2012 at 7:58 AM, Junio C Ham
orktree, even though the worktree stat should not matter for that
operation.
This speeds up e.g. "git reset" a little on the linux-2.6 repo (best
of five, warm cache):
Before After
real0m0.288s0m0.233s
user0m0.190s0m0.150s
sys 0m0.090s0m0.080s
Signed
Although the subject line of 613f027 (read-tree -u one-way merge fix
to check out locally modified paths., 2006-05-15) mentions "read-tree
-u", it did not seem to check whether -u was in effect. Not checking
whether -u is in effect makes e.g. "read-tree --reset" lstat() the
worktree, even though th
On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano wrote:
>
> I am guilty of introducing "git reset --soft HEAD^" before I invented
> "commit --amend" during v1.3.0 timeframe to solve the issue "soft" reset
> originally wanted to.
I do use "commit --amend" a lot, but I still appreciate having "rese
On Wed, Nov 23, 2011 at 12:49 AM, Matthieu Moy
wrote:
> Philippe Vaucher writes:
>
>> Optional: a new mode would be introduced for consistency:
>> --worktree (or maybe --tree): only updates the worktree but not the index
>
> That would be an alias for "git checkout -- path", right?
Not quite, i
On Sun, Dec 9, 2012 at 3:04 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> "git reset" currently returns 0 (if successful) while "git reset
>> $pathspec" returns 0 iff the index matches HEAD after resetting (on
>> all paths, not jus
On Tue, Dec 4, 2012 at 9:46 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> More importantly, when is it desirable not to delete deleted entries?
>
> When I am trying to check out contents of Documentation/ directory
> as of an older edition because we made
On Sat, Dec 1, 2012 at 1:24 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> On Thu, Nov 29, 2012 at 2:00 PM, Martin von Zweigbergk
>> wrote:
>>> Slightly off topic, but another difference (or somehow another aspect
>>> of the same difference?
On Thu, Nov 29, 2012 at 2:00 PM, Martin von Zweigbergk
wrote:
> Slightly off topic, but another difference (or somehow another aspect
> of the same difference?) that has tripped me up a few times is that
> "git checkout $rev ." only affects added and modified files (in $rev
On Tue, Nov 27, 2012 at 11:12 PM, Junio C Hamano wrote:
>
> You have to special case the edges whichever way you go. [...]
If I understand you correctly, you're saying that revision walking
would need a different special case. This is the most obvious
difference, it seems. "git show" would also
On Thu, Nov 29, 2012 at 11:13 AM, Junio C Hamano wrote:
> [...]These
> two commands, "reset" and "checkout", share that the source we grab
> the blobs out of only need to be a tree and does not have to be a
> commit, and the only difference between them is where the blobs we
> grabbed out of that
On Thu, Nov 29, 2012 at 10:47 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> In cases where HEAD is not supposed to be updated, there is no reason
>> that "git reset" should require a commit, a tree should be enough. So
>> make "git reset
In cases where HEAD is not supposed to be updated, there is no reason
that "git reset" should require a commit, a tree should be enough. So
make "git reset $rev^{tree}" work just like "git reset $rev", except
that the former will not update HEAD (since there is no commit to
point it to).
Disallow
I decided to address this before "cherry-pick on unborn branch". RFC
mostly because I'm not sure about the user interface. When we have
agreed on that, I will add documentation.
Martin von Zweigbergk (2):
reset: learn to reset to tree
reset: learn to reset on unborn branch
When run on an unborn branch, "git reset" currently fails with:
fatal: Failed to resolve 'HEAD' as a valid ref.
Fix this by interpreting it as a reset to the empty tree.
If --patch is given, we currently pass the revision specifier, as
given on the command line, to interactive_reset(). On an u
On Tue, Nov 27, 2012 at 12:25 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> simplify a lot of things (maybe I'm biased because of the things I
>> have happened to work on?)
>
> Yes. Do not waste time on it.
Yes, no way I would waste time on th
On Tue, Oct 16, 2012 at 12:58 PM, Damien Robert
wrote:
> Now feature is rebased against master. How would you rebase the branches
> patch1, patch2 and build so that they keep the same layout?
>
> I tried to rebase patch1 and patch2, hoping that rebase -p build would use
> the rebased commits for t
On Thu, Sep 27, 2012 at 5:20 AM, Chris Webb wrote:
> You're right that rebase --root without --onto always creates a brand new
> root as a result of the implementation using a sentinel commit. Clearly this
> is what's wanted with --interactive
That's not as clear as one might first think. "git re
[+Chris Webb regarding "git rebase --root"]
First of all, thanks for a meticulous review!
On Tue, Sep 18, 2012 at 12:53 AM, Johannes Sixt wrote:
> Am 9/18/2012 8:31, schrieb Martin von Zweigbergk:
>
> Since here and in the following tests the test cases and test descriptions
On Tue, Sep 18, 2012 at 12:51 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> do you agree
>> that 'rebase --onto does not re-apply patches in onto' is desirable?
>
> This depends on how you look at --onto. Recall the most typical and
Add more test cases to check that the topology after a rebase is as
expected. Conflicts are not considered, but patch-equivalence is.
---
Tests pass and fail as indicated by the suffix
(_success/_failure). Your input especially appreciated on whether you
agree with the intent of the test cases. Fo
On Mon, Sep 17, 2012 at 10:23 PM, Andrew Wong wrote:
> On 09/18/12 00:58, Martin von Zweigbergk wrote:
>> On Mon, Sep 17, 2012 at 6:28 PM, Andrew Wong wrote:
>>> + test M = $(git cat-file commit HEAD^ | sed -ne \$p) &&
>>> + test L = $(git cat-f
On Mon, Sep 17, 2012 at 6:28 PM, Andrew Wong wrote:
> + test M = $(git cat-file commit HEAD^ | sed -ne \$p) &&
> + test L = $(git cat-file commit HEAD | sed -ne \$p)
I couldn't find "$" (match last line) in the POSIX man page for sed.
Besides, I think $(git show -s --format=%s HEAD) r
t; action=${1##--}
> ;;
> + --edit-todo)
> + test $total_argc -eq 2 || usage
> + action=${1##--}
> + ;;
It looks like this could be trivially combined with the previous case
arm, making the match "--continue|--skip|
On Fri, Aug 31, 2012 at 10:58 AM, Junio C Hamano wrote:
>
> And "git blame $path" probably should expect $path is something that
> appear in the tree of HEAD; apparently it does not.
That probably makes sense. For anyone deciding to implement that, note
that "git blame -C [-C [-C]] $path" should
On Fri, Aug 31, 2012 at 10:25 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>>> + if (argc != 2)
>>> + die("--is-ancestor takes exactly two commits");
>>
>> I think git merge-base shows the usage message regardless
(Resending as plain text, sorry about duplicate, Junio.)
On Thu, Aug 30, 2012 at 4:13 PM, Junio C Hamano wrote:
>
> In many scripted Porcelain commands, we find this idiom:
>
> if test "$(git rev-parse --verify A)" = "$(git merge-base A B)"
> then
> ... A is an ancestor of B ...
>
herry-picking and walking revisions (rev_info.no_walk = 0).
[1] http://thread.gmane.org/gmane.comp.version-control.git/164794
Signed-off-by: Martin von Zweigbergk
---
builtin/revert.c| 2 +-
sequencer.c | 4 +++-
t/t3508-cherry-pick-many-commits.sh | 2 +-
Cherry-picking commits out of order (w.r.t. commit time stamp) doesn't
currently work. Add a test case to demonstrate it.
Signed-off-by: Martin von Zweigbergk
---
t/t3508-cherry-pick-many-commits.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/t/t3508-cherry-pick
t to sort
up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting
to 'sorted' for backward-compatibility reasons.
Signed-off-by: Martin von Zweigbergk
---
Documentation/rev-list-options.txt | 12
builtin/log.c | 2 +-
builtin/revert
igrating my email to martinv...@gmail.com (not y...@google.com
;-) which saves a few keystrokes and matches some of my other
accounts, so these patches will be the first ones from the new
address.
Martin von Zweigbergk (3):
teach log --no-walk=unsorted, which avoids sorting
demonstrate broken '
On Wed, Aug 15, 2012 at 1:02 PM, Junio C Hamano wrote:
> diff --git a/Documentation/rev-list-options.txt
> b/Documentation/rev-list-options.txt
> index 6a4b635..9404d08 100644
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -578,16 +578,33 @@ Commit Orde
On Wed, Aug 15, 2012 at 11:39 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> Makes sense, I'll try to implement it that way. I was afraid that
>> we would need to call prepare_revision_walk() once first and then
>> if we afterwards find out that we s
On Wed, Aug 15, 2012 at 10:16 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> So all of the above case give the right result in the end as long
>> as the timestamps are chronological, and case 1) gives the right
>> result regardless. The other two cases
On Mon, Aug 13, 2012 at 2:05 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> To connect to the other mail I sent on this thread (in parallel with
>> yours), do you think "git cherrry-pick HEAD HEAD~1" should apply the
>> commits in the same orde
On Tue, Aug 14, 2012 at 3:25 PM, Junio C Hamano wrote:
> People answer 'y' to "Who should the emails appear to be from?" and
> 'n' to "Message-ID to be used as In-Reply-To for the first email?"
> for some unknown reason.
Yeah, I know :-(. I did feel stupid already. Thanks for improving.
--
To un
On Mon, Aug 13, 2012 at 4:53 PM, Junio C Hamano wrote:
> Stephen Boyd writes:
>
>> Can we throw up a big warning or just outright fail if someone types
>> 'n' or 'y' and hits enter for the in-reply-to question in
>> git-send-email? I saw a git-send-email sent patch with an In-Reply-To
>> header c
On Mon, Aug 13, 2012 at 4:05 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>>> diff --git a/Documentation/rev-list-options.txt
>>> b/Documentation/rev-list-options.txt
>>> index 6a4b635..dc501ee 100644
>>> --- a/Documentation/rev-list-op
On Mon, Aug 13, 2012 at 3:21 PM, Junio C Hamano wrote:
> * Let's do this before I forget...; came up in discussion $gmane/203370
Thanks! That definitely confused me (and I suppose I stupidly didn't
test with a proper range).
>
> Documentation/rev-list-options.txt | 29 +++--
On Mon, Aug 13, 2012 at 2:31 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> Makes sense. The shortlog example is a good example of sorting that
>> completely reorders the commit graph sometimes even making sense for
>> ranges. Thanks!
>
> By the way,
On Mon, Aug 13, 2012 at 1:05 PM, Junio C Hamano wrote:
> y...@google.com writes:
>
>> From: Martin von Zweigbergk
>>
>> 'git cherry-pick' internally sets the --reverse option while walking
>> revisions, so that 'git cherry-pick branch@{u}..branch
On Sun, Aug 12, 2012 at 11:27 PM, wrote:
> From: Martin von Zweigbergk
>
> 'git cherry-pick' internally sets the --reverse option while walking
> revisions, so that 'git cherry-pick branch@{u}..branch' will apply the
> revisions starting at the oldest one.
B
On Mon, Aug 13, 2012 at 10:05 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>>
>> ... so is a migration desired? Or just
>> change the default for --no-walk from "sorted" to "unsorted" in git
>> 2.0?
>
> I think the proper support
On Mon, Aug 13, 2012 at 12:17 AM, Junio C Hamano wrote:
> y...@google.com writes:
>
> [Administrivia: I somehow doubt y...@google.com would reach you, and
> futzed with the To: line above]
:-( Sorry, sendemail.from now set. (I apparently answered "y" instead
of just to accept the default.)
> I
On Fri, Aug 10, 2012 at 2:38 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> There is also cherry-pick/revert, which I _think_ does not really want
>> the revisions sorted.
>
> Yes, I think sequencer.c::prepare_revs() is wrong to unconditoinally
>
A while ago when I was looking at revision.c, I was surprised to see
that commits are sorted even when --no-walk is passed, but as 8e64006
(Teach revision machinery about --no-walk, 2007-07-24) points out,
this can be useful for doing
$ git log --abbrev-commit --pretty=oneline --decorate --all --
On Thu, Aug 9, 2012 at 9:05 AM, Michael J Gruber
wrote:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 0d2056f..dbc9de6 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -573,7 +573,7 @@ do_next () {
> newhead=$(git rev-parse
Add test cases for 'git rebase --keep-empty' with and without an
"empty" commit already in upstream. The empty commit that is about to
be rebased should be kept in both cases.
Signed-off-by: Martin von Zweigbergk
---
Added another test for when the upstream already has an em
Signed-off-by: Martin von Zweigbergk
---
While trying to use patch-id instead of
--ignore-if-in-upstream/--cherry-pick/cherry/etc, I noticed that
patch-id ignores empty patches and I was surprised that tests still
pass. This test case would be useful to protect --keep-empty.
t/t3401-rebase
While walking the revision list in get_patch_ids and cmd_cherry, we
check for each commit if there is more than one parent and ignore the
commit if that is the case. Instead, set rev_info.max_parents to 1 and
let the revision traversal code handle it for us.
Signed-off-by: Martin von Zweigbergk
Separated out the removal of the unused diff options into patch 2/3
and added the necessary max_parents=1 in patch 3/3.
Martin von Zweigbergk (3):
remove unnecessary parameter from get_patch_ids()
cherry: don't set ignored rev_info options
log: remove redundant check for merge c
.
Signed-off-by: Martin von Zweigbergk
---
builtin/log.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index ecc2793..7a92e3f 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -696,7 +696,7 @@ static int reopen_stdout(struct commit *commit
), these options are just distractions,
so remove them.
Signed-off-by: Martin von Zweigbergk
---
builtin/log.c | 4
1 file changed, 4 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 7a92e3f..8cea1e5 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1508,10 +1508,6 @@ int
Sorry, I meant to CC the list. See below.
On Sat, Jul 28, 2012 at 9:56 PM, Martin von Zweigbergk
wrote:
> On Fri, Jul 27, 2012 at 11:52 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>> It seems to have some interaction with your other topic, though.
>> T
On Fri, Jul 27, 2012 at 3:30 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>> Also re-initializing rev_info fields to the same values already set in
>> init_revisions().
Oops, that should have been " _avoid_ re-initializing".
> I suspect that
On Fri, Jul 27, 2012 at 3:44 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
> s/it seems the prefix doesn't change/the prefix never changes/;
:-) Thanks for confirming.
> In that sense it probably does not even matter if you did not pass
> rev->prefix
These are just some things I noticed while looking at the revision
walking code. I'm not very familiar with the code at all, so the
patches may very well be completely wrong; view them as newbie
questions in patch-form if you like.
Martin von Zweigbergk (2):
remove unnecessary parameter
econd rev_info.
Signed-off-by: Martin von Zweigbergk
---
builtin/log.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index ecc2793..7a92e3f 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -696,7 +696,7 @@ static int reopen_stdout(struct c
On Thu, Jul 26, 2012 at 11:09 PM, Junio C Hamano wrote:
> * mz/rebase-range (2012-07-18) 7 commits
> - rebase (without -p): correctly calculate patches to rebase
> - rebase -p: don't request --left-right only to ignore left side
> - rebase -p: use --cherry-mark for todo file
> - git-rebase--in
On Tue, Jul 24, 2012 at 11:27 AM, Jonathan Nieder wrote:
> Hi,
>
> Jiang Xin wrote:
>
>> Gettext message should not start with '-' nor '--'. Since the '-d' and
>> '--dotest' options do not exist in OPTIONS_SPEC variable, it's safe to
>> remove the block.
>
> The above justification is not a suffic
On Fri, Jul 20, 2012 at 1:18 AM, Johannes Sixt wrote:
> Am 7/18/2012 9:27, schrieb Martin von Zweigbergk:
>> diff --git a/git-rebase--am.sh b/git-rebase--am.sh
>> index 37c1b23..fe3fdd1 100644
>> --- a/git-rebase--am.sh
>> +++ b/git-rebase--am.sh
>> @@ -16,11 +1
101 - 200 of 212 matches
Mail list logo
