This is the 5th last patch series of my work to accelerate interactive
rebases in particular on Windows.
Basically, all it does is to make reusable some functions that were
ported over from git-pull.sh but made private to builtin/pull.c.
Changes since v1:
- skipped patch that tries to make requi
In cmd_pull(), when verifying that there are no changes preventing a
rebasing pull, we diligently pass the prefix parameter to the
die_on_unclean_work_tree() function which in turn diligently passes it
to the has_unstaged_changes() and has_uncommitted_changes() functions.
The casual reader might n
When converting the pull command to a builtin, the
require_clean_work_tree() function was renamed and the pull-specific
parts hard-coded.
This makes it impossible to reuse the code, so let's modify the code to
make it more similar to the original shell script again.
Signed-off-by: Johannes Schind
They will be used in the upcoming rebase helper.
Signed-off-by: Johannes Schindelin
---
wt-status.c | 4 ++--
wt-status.h | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 9ab9adc..f1120e6 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -2214,
It is remarkable that libgit.a did not sport this function yet... Let's
move it into a more prominent (and into an actually reusable) spot:
wt-status.[ch].
Signed-off-by: Johannes Schindelin
---
builtin/pull.c | 76 +-
wt-status.c| 75 +
Sometimes we are *actually* interested in those changes... For
example when an interactive rebase wants to continue with a staged
submodule update.
Signed-off-by: Johannes Schindelin
---
builtin/pull.c | 2 +-
wt-status.c| 16 +---
wt-status.h| 7 ---
3 files changed, 1
Hi Junio,
On Fri, 9 Sep 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Instead of dying there, let the caller high up in the callchain
> > notice the error and handle it (by dying, still).
> >
> > The only callers of checkout_fast_forward_to(), cmd_merge(),
> > pull_into_void()
Hi Kuba,
On Fri, 9 Sep 2016, Jakub Narębski wrote:
> W dniu 09.09.2016 o 16:40, Johannes Schindelin napisał:
> > On Fri, 2 Sep 2016, Jakub Narębski wrote:
> >> W dniu 01.09.2016 o 16:20, Johannes Schindelin pisze:
> >>> On Thu, 1 Sep 2016, Jakub Narębski wrote:
> W dniu 29.08.2016 o 10:06,
Hi Kuba,
On Fri, 9 Sep 2016, Jakub Narębski wrote:
> Hello Johannes,
>
> W dniu 09.09.2016 o 17:12, Johannes Schindelin napisał:
> > On Thu, 1 Sep 2016, Junio C Hamano wrote:
> >> Johannes Schindelin writes:
>
> >> I was sort of expecting that, when you do the preserve-merges mode
> >> of "re
Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-19.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub is
The git add --chmod option was introduced in 4e55ed3 ("add: add
--chmod=+x / --chmod=-x options", 2016-05-31), but was never
documented. Document the feature.
Signed-off-by: Thomas Gummerer
---
Documentation/git-add.txt | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/D
Changes since v1:
Added missing x in the documentation.
The changes since v1 are only minor, but as it's been a week, this is
as much a ping as a fixup of my error :)
Thomas Gummerer (4):
add: document the chmod option
update-index: use the same structure for chmod as add
read-cache: introd
While the chmod options for update-index and the add have the same
functionality, they are using different ways to parse and handle the
option internally. Unify these modes in order to make further
refactoring simpler.
Signed-off-by: Thomas Gummerer
---
builtin/update-index.c | 49 +
As there are chmod options for both add and update-index, introduce a
new chmod_index_entry function to do the work. Use it in update-index,
while it will be used in add in the next patch.
Signed-off-by: Thomas Gummerer
---
builtin/update-index.c | 8 +---
cache.h| 2 ++
r
When the chmod option was added to git add, it was hooked up to the diff
machinery, meaning that it only works when the version in the index
differs from the version on disk.
As the option was supposed to mirror the chmod option in update-index,
which always changes the mode in the index, regardle
This change is not completely faithful: instead of initializing all fields
to 0, we choose to initialize command and subcommand to -1 (instead of
defaulting to REPLAY_REVERT and REPLAY_NONE, respectively). Practically,
it makes no difference at all, but future-proofs the code to require
explicit as
Signed-off-by: Johannes Schindelin
---
builtin/commit.c | 2 +-
sequencer.c | 11 ++-
sequencer.h | 5 +
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index bb9f79b..e79af9d 100644
--- a/builtin/commit.c
+++ b/builtin/c
The sequencer reads options from disk and stores them in its struct
for use during sequencer's operations.
With this patch, the memory is released afterwards, plugging a
memory leak.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 13 ++---
1 file changed, 10 insertions(+), 3 delet
This patch series marks the '4' in the countdown to speed up rebase -i
by implementing large parts in C. It is based on the `libify-sequencer`
patch series that I submitted last week.
The patches in this series merely prepare the sequencer code for the
next patch series that actually teaches the
We really do not need the *pointer to a* pointer to the options in
the read_populate_opts() function.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index cb16cbd..c2fbf6f 100644
--- a/sequenc
In a couple of commits, we will teach the sequencer to handle the
nitty gritty of the interactive rebase, which keeps its state in a
different directory.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/
The sequencer is our attempt to lib-ify cherry-pick. Yet it behaves
like a one-shot command when it reads its configuration: memory is
allocated and released only when the command exits.
This is kind of okay for git-cherry-pick, which *is* a one-shot
command. All the work to make the sequencer its
Over the next commits, we will work on improving the sequencer to the
point where it can process the edit script of an interactive rebase. To
that end, we will need to teach the sequencer to read interactive
rebase's todo file. In preparation, we consolidate all places where
that todo file is neede
When we came up with the "sequencer" idea, we really wanted to have
kind of a plumbing equivalent of the interactive rebase. Hence the
choice of words: the "todo" script, a "pick", etc.
However, when it came time to implement the entire shebang, somehow this
idea got lost and the sequencer was use
The subcommands are used exactly once, at the very beginning of
sequencer_pick_revisions(), to determine what to do. This is an
unnecessary level of indirection: we can simply call the correct
function to begin with. So let's do that.
While at it, ensure that the subcommands return an error code s
Not only does this DRY up the code (providing a better documentation what
the code is about, as well as allowing to change the behavior in a single
place), it also makes it substantially shorter to use the same
functionality in functions to be introduced when we teach the sequencer to
process inter
As we are slowly teaching the sequencer to perform the hard work for
the interactive rebase, we need to read files that were written by
shell scripts.
These files typically contain a single line and are invariably ended
by a line feed (and possibly a carriage return before that). Let's use
a helpe
The rebase command sports a `--gpg-sign` option that is heeded by the
interactive rebase.
This patch teaches the sequencer that trick, as part of the bigger
effort to make the sequencer the work horse of the interactive rebase.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 42 +++
In interactive rebases, we commit a little bit differently than the
sequencer did so far: we heed the "author-script", the "message" and
the "amend" files in the .git/rebase-merge/ subdirectory.
Likewise, we may want to edit the commit message *even* when providing
a file containing the suggested
The `git-rebase-todo` file contains a list of commands. Most of those
commands have the form
The is displayed primarily for the user's convenience, as
rebase -i really interprets only the part. However, there
are *some* places in interactive rebase where the is used to
display mess
Signed-off-by: Johannes Schindelin
---
sequencer.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index b971ad0..7ba932b 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -232,11 +232,8 @@ static int error_dirty_index(struct replay_opts *opts)
In the upcoming commits, we will implement more and more of rebase
-i's functionality. One particular feature of the commands to come is
that some of them allow editing the commit message while others don't,
i.e. we cannot define in the replay_opts whether the commit message
should be edited or not
Interactive rebase's scripts may be indented; we need to handle this
case, too, now that we prepare the sequencer to process interactive
rebases.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sequencer.c b/sequencer.c
index 7953a05..5e5
The sequencer_commit() function already knows how to amend commits, and
with this new option, it can also clean up commit messages (i.e. strip
out commented lines). This is needed to implement rebase -i's 'fixup'
and 'squash' commands as sequencer commands.
Signed-off-by: Johannes Schindelin
---
This teaches the sequencer_commit() function to take an argument that
will allow us to implement "todo" commands that need to amend the commit
messages ("fixup", "squash" and "reword").
Signed-off-by: Johannes Schindelin
---
sequencer.c | 6 --
sequencer.h | 2 +-
2 files changed, 5 insertio
The return value of do_recursive_merge() may be positive (indicating merge
conflicts), so let's OR later error conditions so as not to overwrite them
with 0.
This is not yet a problem, but preparing for the patches to come: we will
teach the sequencer to do rebase -i's job.
Signed-off-by: Johanne
This makes the code consistent by fixing quite a couple of error messages.
Suggested by Jakub Narębski.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 1e7f29e..465e01
When translating error messages, we need to be careful *not* to translate
the todo commands such as "pick", "reword", etc because they are commands,
and Git would not understand translated versions of those commands.
Therefore, translating the commands in the error messages would simply be
mislead
The definition of this function goes back all the way to 043a449
(sequencer: factor code out of revert builtin, 2012-01-11), long before a
serious effort was made to translate all the error messages.
It is slightly out of the context of the current patch series (whose
purpose it is to re-implement
The sequencer was introduced to make the cherry-pick and revert
functionality available as library function, with the original idea
being to extend the sequencer to also implement the rebase -i
functionality.
The test to ensure that all of the commands in the script are identical
to the overall op
The write_message() function safely writes an strbuf to a file.
Sometimes it is inconvenient to require an strbuf, though: the text to
be written may not be stored in a strbuf, or the strbuf should not be
released after writing.
Let's refactor "safely writing string to a file" into
write_with_lock
> On 08 Sep 2016, at 23:18, Stefan Beller wrote:
>
> On Thu, Sep 8, 2016 at 11:21 AM, wrote:
>
>> +static int packet_write_fmt_1(int fd, int gently,
>> + const char *fmt, va_list args)
>> +{
>> + struct strbuf buf = STRBUF_INIT;
>> + size_t count;
>> +
> On 08 Sep 2016, at 23:24, Stefan Beller wrote:
>
> On Thu, Sep 8, 2016 at 11:21 AM, wrote:
>
>>
>> Add packet_write_gently() which writes arbitrary data and returns `0`
>> for success and `-1` for an error.
>
> I think documenting the return code is better done in either the header file
>
> On 08 Sep 2016, at 23:49, Stefan Beller wrote:
>
> On Thu, Sep 8, 2016 at 11:21 AM, wrote:
>> From: Lars Schneider
>>
>> write_packetized_from_fd() and write_packetized_from_buf() write a
>> stream of packets. All content packets use the maximal packet size
>> except for the last one. Afte
> On 09 Sep 2016, at 00:05, Stefan Beller wrote:
>
> On Thu, Sep 8, 2016 at 11:21 AM, wrote:
>> From: Lars Schneider
>>
>> Use `test_config` to set the config, check that files are empty with
>> `test_must_be_empty`, compare files with `test_cmp`, and remove spaces
>> after ">" and "<".
>>
Hi Junio,
There are some l10n updates for Git 2.10.0, please merge them to the
maint branch.
The following changes since commit e8e349249c86550d3505c4abfac28caf3d13df46:
Merge branch 'master' of https://github.com/vnwildman/git
(2016-09-02 21:29:48 +0800)
are available in the git repository a
On Sun, Sep 11, 2016 at 4:36 AM, Lars Schneider
wrote:
>>
>>call check_pipe from write_or_die here instead of
>>reproducing that function?
>
> Yes, might be better. I wasn't sure because the check_pipe is
> not public.
>
> Where would you declare check_pipe? In cache.h?
IIRC, once upon a
On Sun, Sep 11, 2016 at 5:33 AM, Lars Schneider
wrote:
> Does this convince you to keep the proposed error handling? If yes, then
> I would add a comment to the function to document that behavior explicitly!
oops. I should read the docs more carefully.
Thanks for pointing out.
Then I'd be happy
On Sat, Sep 10, 2016 at 1:15 AM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On Fri, 9 Sep 2016, Stefan Beller wrote:
>
>> On Fri, Sep 9, 2016 at 9:19 AM, Sergio Martín Turiel
>> wrote:
>>
>> > Can you tell me what I'm doing wrong?
>>
>> Not crying out loud when that commit was discussed on the
>
Hey everyone,
One of my friend was trying to add files using the command `git add
.*` and got an error that "fatal: ..: '..' is outside repository"
which did seem a little obvious to me. But then I tried to reproduce
it in my machine with `git add ".*"` and it didn't error out. I am
currently usin
On Sep 12 2016, Pranit Bauva wrote:
> One of my friend was trying to add files using the command `git add
> .*` and got an error that "fatal: ..: '..' is outside repository"
> which did seem a little obvious to me. But then I tried to reproduce
> it in my machine with `git add ".*"` and it didn't
Hi,
On 09/12, Pranit Bauva wrote:
> Hey everyone,
>
> One of my friend was trying to add files using the command `git add
> .*` and got an error that "fatal: ..: '..' is outside repository"
> which did seem a little obvious to me. But then I tried to reproduce
> it in my machine with `git add ".*
---
merge-recursive.c| 9 +---
t/t6042-merge-rename-corner-cases.sh | 42
2 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index e349126..25dc701 100644
--- a/merge-recursive.c
+++ b/
Stefan Beller writes:
> So as a caller the strbuf is in a different state in case of error
> depending whether
> the strbuf already had some data in it. I think it would be better if
> we only did
> `strbuf_setlen(sb_out, oldlen);` here, such that the caller can
> strbuf_release it
> unconditiona
Johannes Schindelin writes:
>> In other words, instead of trying to be consistent by erroring out
>> in non-regular blob case, I think the attached change on top would
>> make more sense, by consistently passing the object contents as-is
>> for all "not filtered" cases, whether it is run from the
Jakub Narębski writes:
> I wonder, if git-commit is to acquire such feature, what would be the
> best interface. "git commit :0:./"? "git commit -o -p "
> (that is, "git commit --only --patch ")?
Just do "git reset && git commit -p ", I would say.
Anything more elaborate would just confuse the
Johannes Schindelin writes:
> Thanks. There are a couple more git-gui patches waiting for quite a long
> time. So you prefer them still as patches to git-gui.git?
I prefer not to have to worry about them myself ;-) That means that
even if Pat steps down, the next maintainer for git-gui project
On Sun, Sep 11, 2016 at 2:50 PM, Junio C Hamano wrote:
> Jakub Narębski writes:
>
>> I wonder, if git-commit is to acquire such feature, what would be the
>> best interface. "git commit :0:./"? "git commit -o -p "
>> (that is, "git commit --only --patch ")?
>
> Just do "git reset && git commit
Stefan Beller writes:
> The plan is to hook the ls-files machinery into
> git-grep as the way of obtaining files to grep for a pattern.
That does not make much sense to me for exactly the same reason why
the "grab the list of paths and run 'git add' on them" example in
the message you are respon
Thomas Gummerer writes:
> @@ -955,10 +941,8 @@ int cmd_update_index(int argc, const char **argv, const
> char *prefix)
> PARSE_OPT_NOARG | /* disallow --cacheinfo= form */
> PARSE_OPT_NONEG | PARSE_OPT_LITERAL_ARGHELP,
> (parse_op
Mikhail Filippov writes:
> ---
You'd need a lot more explanation on why this is needed
(i.e. without it what behaviour you would get, and why that
behaviour is wrong).
> merge-recursive.c| 9 +---
> t/t6042-merge-rename-corner-cases.sh | 42
> +
Johannes Schindelin writes:
> When translating error messages, we need to be careful *not* to translate
> the todo commands such as "pick", "reword", etc because they are commands,
> and Git would not understand translated versions of those commands.
>
> Therefore, translating the commands in the
Johannes Schindelin writes:
> This makes the code consistent by fixing quite a couple of error messages.
Looks OK. While at it, we may want another one to downcase the
first word, perhaps?
These may not be messages added by your series and can be left
outside this series, but I have to point o
Johannes Schindelin writes:
> While at it, error out early if the "instruction sheet" (i.e. the todo
> script) could not be parsed.
Sounds good.
Johannes Schindelin writes:
> The write_message() function safely writes an strbuf to a file.
> Sometimes it is inconvenient to require an strbuf, though: the text to
> be written may not be stored in a strbuf, or the strbuf should not be
> released after writing.
>
> Let's refactor "safely writi
Johannes Schindelin writes:
> Interactive rebase's scripts may be indented; we need to handle this
> case, too, now that we prepare the sequencer to process interactive
> rebases.
Hmph, have we ever given the sequencer instructions indented to the
user to edit? I do not offhand see why we want
On Tue, Aug 23, 2016 at 11:02 AM, Junio C Hamano wrote:
> David Glasser writes:
>
> That might be something we want to fix up further in later patches;
> the change we see in this patch is good regardless.
Perhaps I am looking at the wrong branch, but I'm not sure that this
got merged? Is there
On Tue, Sep 06, 2016 at 12:42:04PM -0500, Jon Loeliger wrote:
> I have recently been enlisted by folks at the Linux Foundation to
> help run a Miniconference on Git at the Plumbers Conference [*]
> this fall.
I see the conference runs for 4 days; I assume the Git portion will just
be one day. Do
On Sun, Sep 11, 2016 at 03:10:13PM -0700, Junio C Hamano wrote:
> So a "ls-files" that is done internally in the end-user facing "git
> grep --recurse-submodules" needs to be run _without_ recursing
> itself at least once to learn "lib/" is a submodule. A flat "here
> are everything we have" does
On Sun, Sep 11, 2016 at 08:51:06PM -0400, Jeff King wrote:
> On Sun, Sep 11, 2016 at 03:10:13PM -0700, Junio C Hamano wrote:
>
> > So a "ls-files" that is done internally in the end-user facing "git
> > grep --recurse-submodules" needs to be run _without_ recursing
> > itself at least once to lea
Junio C Hamano writes:
> So a "ls-files" that is done internally in the end-user facing "git
> grep --recurse-submodules" needs to be run _without_ recursing
> itself at least once to learn "lib/" is a submodule. A flat "here
> are everything we have" does not sound like a good building block.
David Glasser writes:
> On Tue, Aug 23, 2016 at 11:02 AM, Junio C Hamano wrote:
>> David Glasser writes:
>>
>> That might be something we want to fix up further in later patches;
>> the change we see in this patch is good regardless.
>
>
> Perhaps I am looking at the wrong branch, but I'm not s
Jacob Keller writes:
> Yes, I'm actually confused by "git commit " *not* usinng what's
> in the index already, so I think that isn't intuitive as is.
You are excused ;-)
In ancient days, "git commit " was to add the contents
from working tree files that match to what is already in
the index an
On Sun, Sep 11, 2016 at 6:54 PM, Junio C Hamano wrote:
> The patch that was commented on in that exchange should be part of
> v2.10.0 already.
My mistake: I was accidentally searching for the paragraph I added in
config.txt instead of git-config.txt. Thanks and sorry for wasting
your time!
--dav
On Sun, Sep 11, 2016 at 6:57 PM, Junio C Hamano wrote:
>
> You are excused ;-)
>
> In ancient days, "git commit " was to add the contents
> from working tree files that match to what is already in
> the index and create a commit from that state. This ran against the
> intuition of many users who
Hey Thomas,
On Mon, Sep 12, 2016 at 1:09 AM, Thomas Gummerer wrote:
> Hi,
>
> On 09/12, Pranit Bauva wrote:
>> Hey everyone,
>>
>> One of my friend was trying to add files using the command `git add
>> .*` and got an error that "fatal: ..: '..' is outside repository"
>> which did seem a little ob
76 matches
Mail list logo