Trying again from plain old gmail which I think does not send a
multipart content.
On Fri, Nov 7, 2014 at 11:06 PM, Martin von Zweigbergk
wrote:
> Is this also related to "git checkout $rev ." not removing removed files?
> What you say about the difference in implementation betw
pathspec" was a deliberate design choice, not an implementation glitch.
>
> Pardon HTML, misspellings and grammos, typed on a tablet.
>
> On Nov 7, 2014 11:10 PM, "Martin von Zweigbergk"
> wrote:
>>
>> Trying again from plain old gmail which I think does not send a
&g
First of all, thanks again for spending time on this.
On Sat, Nov 8, 2014 at 12:30 AM, Jeff King wrote:
> On Fri, Nov 07, 2014 at 11:35:59PM -0800, Junio C Hamano wrote:
>
> So just to be clear, the behavior we want is that:
>
> echo foo >some-new-path
> git add some-new-path
> git checkout
On Sun, Dec 8, 2013 at 12:06 PM, John Keeping wrote:
> Commit 15a147e (rebase: use @{upstream} if no upstream specified,
> 2011-02-09) says:
>
> Make it default to 'git rebase @{upstream}'. That is also what
> 'git pull [--rebase]' defaults to, so it only makes sense that
>
On Wed, Oct 16, 2013 at 11:53 AM, John Keeping wrote:
> Commit 15a147e (rebase: use @{upstream} if no upstream specified,
> 2011-02-09) says:
>
> Make it default to 'git rebase @{upstream}'. That is also what
> 'git pull [--rebase]' defaults to, so it only makes sense that
>
On Wed, Oct 16, 2013 at 11:53 AM, John Keeping wrote:
> Commit 15a147e (rebase: use @{upstream} if no upstream specified,
> 2011-02-09) says:
>
> Make it default to 'git rebase @{upstream}'. That is also what
> 'git pull [--rebase]' defaults to, so it only makes sense that
>
On Mon, Oct 21, 2013 at 4:24 AM, John Keeping wrote:
> On Sun, Oct 20, 2013 at 10:03:29PM -0700, Martin von Zweigbergk wrote:
>> On Wed, Oct 16, 2013 at 11:53 AM, John Keeping wrote:
>> > Commit 15a147e (rebase: use @{upstream} if no upstream specified,
>
Sorry about the regression and thanks for report and fixes.
On Thu, Oct 24, 2013 at 9:24 PM, Jeff King wrote:
> On Thu, Oct 24, 2013 at 08:40:13PM -0700, Junio C Hamano wrote:
>
>> Maarten de Vries writes:
>>
>> > Some more info: It used to work as intended. Using a bisect shows it
>> > has been
Thanks for taking care of this! Maybe John or I can finally get the
changes to rebase done after this.
A few comments below. Sorry I didn't find time to review the earlier revisions.
On Fri, Oct 25, 2013 at 2:38 PM, Junio C Hamano wrote:
> +
> +where `origin/master` used to point at commits B3,
I was recently confused by the yoda condition in this block of code from [1]
+ for (i = 0; i < revs.nr; i++)
+ if (&bases->item->object == &revs.commit[i]->object)
+ break; /* found */
+ if (revs.nr <= i)
I think I was particularly surprised because it came so soon after the
"i < revs.nr". I didn
On Sun, Jun 23, 2013 at 4:54 PM, Jonathan Nieder wrote:
>
> In other words, HEAD always either points to an unborn or existing
> branch or an existing commit. It's not clear to me what it would
> mean to detach from an unborn branch.
I think it should mean that the next commit would be a root co
On Sat, Aug 24, 2013 at 9:19 PM, Jonathan Nieder wrote:
> Thomas Ackermann wrote:
>> --- a/Documentation/user-manual.txt
>> +++ b/Documentation/user-manual.txt
>> @@ -1784,17 +1784,6 @@ repository that you pulled from.
>> <>; instead, your branch will just be
>> updated to point to the latest co
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
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
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
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
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
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 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 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 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 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 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 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 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
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
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
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
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
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
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
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 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 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
>> &
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 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
> 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 \
> +
---
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)
"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
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
--
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
"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
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
---
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
--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
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)
"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
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 +++
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 ++
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(+),
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
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()
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
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 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: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: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 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: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 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 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 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
) It lets us use
the (arguably clearer) "if (pathspec)" in place of "if (i < argc)".
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
Unstaged changes after reset:
D .gitattributes
D .gitignore
D .mailmap
...
This happens because the check for is_bare_repository() happens after
we branch off into read_from_tree() to reset with paths. Fix by moving
the branching point after the check.
Signed-off-by:
0m0.093s0m0.080s
user0m0.040s0m0.020s
sys 0m0.050s0m0.050s
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 915cc9f..8cc7c72 100644
--- a/builtin/r
e is dirty so that non-zero indicates an error.
This makes the 4 "disambiguation" test cases in t7102 clearer since
they all used to "fail", 3 of which "failed" due to changes in the
work tree. Now only the ambiguous one fails.
Signed-off-by: Martin von Zweigbergk
ive() will resolve to a
tree. This is fine since interactive_reset only needs the parameter to
be a treeish and doesn't use it for display purposes.
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 48 +++-
t/t7102-reset.sh | 8 ++
reset $rev" would also be faster).
Timing "git reset" shows that it indeed becomes as fast as
"git reset ." after this patch.
Signed-off-by: Martin von Zweigbergk
---
It seems like a better solution would be for unpack_trees() learn the
same tricks as do_diff_cache(). I&#x
tly referring to HEAD in "git reset HEAD".
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c| 16 -
t/t7106-reset-unborn-branch.sh | 52 ++
2 files changed, 62 insertions(+), 6 deletions(-)
create mode 100755 t/
ned-off-by: Martin von Zweigbergk
---
builtin/reset.c | 42 ++
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index e8a3e41..c316d9b 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -309,19 +309,6 @@ int cmd
x27;s leave it for now.
In the process, we expose and fix the minor UI bug that makes us print
"Could not refresh index" when we fail to write the index file when
invoked with a pathspec. Copy the error message from the pathspec-less
codepath ("Could not write new index file.").
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.
Signed-off-by: Martin von Zweigbergk
---
0m0.130s
sys 0m0.070s0m0.080s
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index c1d6ef2..e8a3e41 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -336,6
Declutter cmd_reset() a bit by moving out the argument parsing to its
own function.
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 70 +++--
1 file changed, 38 insertions(+), 32 deletions(-)
diff --git a/builtin/reset.c b/builtin
left-overs.
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 97fa9f7..c3eb2eb 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -349,18 +349,11 @@ int cmd_rese
Now that there is only one caller left to the single-line method
update_index_refresh(), inline it.
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index c316d9b
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.
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 39
half-way reset
state. As a bonus, we speed up "git reset --keep" a little on the
linux-2.6 repo (best of five, warm cache):
Before After
real0m0.315s0m0.296s
user0m0.290s0m0.280s
sys 0m0.020s0m0.010s
Signed-off-by: Martin von Zweigbergk
t; patch by one that just
inlines update_index_refresh()
- Incorporated fixes from Junio's repo
- Provided some motivation for "replace switch by if-else" amd moved
the patch later in the series.
Thanks for reviewing!
Martin von Zweigbergk (19):
reset $pathspec: no need to di
() out of
read_from_tree for symmetry with the 'else' block, making
read_from_tree() and reset_index() closer in functionality.
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/builtin/reset.c
mp; !err)
err = f();
(which is equivalent since we only care whether exit code is 0)
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 2187d64..4e34195 100644
--- a
part of a loop. To avoid such confusion, remove the
variable and also the 'argc' parameter and check for NULL trailing
argv instead.
Signed-off-by: Martin von Zweigbergk
---
I explained a bit more why I was confused by the current style, but
I'm also perfectly happy if you just dr
I suppose this was meant for everyone. Adding back the others.
On Tue, Jan 15, 2013 at 10:27 AM, Holding, Lawrence (NZ)
wrote:
> Maybe use *argv instead of argv[0]?
Sure. Everywhere? Also in the lines added in patch 17/19 that refer to
both argv[0] and argv[1], such as "argv[1] &&
!get_sha1_tree
---
Sorry, I forgot the documentation updates. I hope this looks ok. Can
you squash this in, Junio? Thanks.
I don't think any documentation update is necessary for the "reset on
unborn branch" patch. Let me know if you think differently.
Documentation/git-reset.txt | 18 +-
bui
On Wed, Jan 16, 2013 at 10:00 AM, Martin von Zweigbergk
wrote:
> ---
>
> Sorry, I forgot the documentation updates. I hope this looks ok. Can
> you squash this in, Junio? Thanks.
I see the series just entered 'next', so I guess it would have to go
on top then. Perhaps with
Hi,
I think I have some patches at home that instead teach 'git am' the
--keep-empty flag. Does that make sense? It's been a while since I
looked at it, but I'll try to take a look tonight (PST).
Martin
On Tue, May 28, 2013 at 6:29 AM, Felipe Contreras
wrote:
> Hi,
>
> I've been analyzing 'git
As Junio asked in the previous iteration, shouldn't this have been in
the first patch?
On Tue, May 28, 2013 at 9:16 PM, Felipe Contreras
wrote:
> We are not in am mode.
>
> Signed-off-by: Felipe Contreras
> ---
> git-rebase--cherrypick.sh | 10 ++
> 1 file changed, 6 insertions(+), 4 d
Same here: should this have been in the first patch? If not, do you
know for how long it has been broken (since which commit)?
On Tue, May 28, 2013 at 9:16 PM, Felipe Contreras
wrote:
> Signed-off-by: Felipe Contreras
> ---
> git-rebase.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
Actually, are all of 2/8 - 7/8 fixes for things that broke in patch 1/8?
On Tue, May 28, 2013 at 9:16 PM, Felipe Contreras
wrote:
> We don't use the 'rebase-apply'.
>
> Signed-off-by: Felipe Contreras
> ---
> git-rebase--cherrypick.sh | 4
> git-rebase.sh | 5 -
> 2 files c
On Tue, May 28, 2013 at 10:41 PM, Felipe Contreras
wrote:
> On Wed, May 29, 2013 at 12:33 AM, Martin von Zweigbergk
> wrote:
>> As Junio asked in the previous iteration, shouldn't this have been in
>> the first patch?
>
> No, the first patch is splitting the
:-)
On Tue, May 28, 2013 at 11:05 PM, Felipe Contreras
wrote:
> On Wed, May 29, 2013 at 12:51 AM, Martin von Zweigbergk
> wrote:
>> On Tue, May 28, 2013 at 10:41 PM, Felipe Contreras
>> wrote:
>
>>> One change splits, the other change fixes, what's wrong with
---
t/t3401-rebase-partial.sh | 24
t/t3420-rebase-topology-linear.sh | 58 +++
2 files changed, 58 insertions(+), 24 deletions(-)
diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh
index 58f4823..7ba1797 100755
--- a/t/
Update the following:
- Quote 'setup'
- Remove blank lines within test case body
- Use test_commit instead of custom quick_one
- Create branch "topic" from tag created by test_commit
---
t/t3406-rebase-message.sh | 30 +-
1 file changed, 9 insertions(+), 21 deletio
Helped-by: Johannes Sixt
---
t/lib-rebase.sh | 15
t/t3420-rebase-topology-linear.sh | 78 +++
2 files changed, 93 insertions(+)
create mode 100755 t/t3420-rebase-topology-linear.sh
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
ind
---
t/t3420-rebase-topology-linear.sh | 129 ++
1 file changed, 129 insertions(+)
diff --git a/t/t3420-rebase-topology-linear.sh
b/t/t3420-rebase-topology-linear.sh
index 40fe264..2429aa8 100755
--- a/t/t3420-rebase-topology-linear.sh
+++ b/t/t3420-rebase-topo
1 - 100 of 212 matches
Mail list logo
