On Mon, Jul 15, 2019 at 1:16 AM Matthew DeVore wrote:
>
> On Fri, Jul 12, 2019 at 02:02:52PM -0700, Junio C Hamano wrote:
> > * md/list-objects-filter-combo (2019-06-28) 10 commits
> > - list-objects-filter-options: make parser void
> > - list-objects-filter-options: clean up use of ALLOC_GROW
>
Hi!
I just had "an interesting case" for a merge with conflicts:
The merge re-introduced a file that had been renamed (say old one is "bla", and
the new one is "foo").
After merging the changes from bla into foo, I added foo, trying to remove bla:
> git add foo
> git rm bla
bla: needs merge
rm 'b
Still failing:
On Fri, 2019-07-12 at 22:39 -0400, Andrey wrote:
> Could you, please, try the patch below?
>
> diff --git a/git-p4.py b/git-p4.py
> index 5b79920f46..f5be048348 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -4137,13 +4137,13 @@ def main():
> if cmd.needsGit:
> if cm
Hi!
I have two remotes with different tags, so when I use "git fetch" it
removes the tag from the other remote and add tag from the origin remote.
So I tried to use "git fetch --no-tags" to prevent this behavior and I
have no use for those tags locally.
The problem is it works for the origin rem
To prevent mistakes when editing a branch, rebase features a knob,
rebase.missingCommitsCheck, to warn the user if a commit was dropped.
Unfortunately, this check is only effective for the initial edit, which
means that if you edit the todo list at a later point of the rebase and
dropped a commit,
When set to "warn" or "error", `rebase.missingCommitCheck' would make
rebase -i warn if the user removed commits from the todo list to prevent
mistakes. Unfortunately, rebase --edit-todo and rebase --continue don't
take it into account.
This adds three tests to t3404 to demonstrate this. The fir
After executing a command, rebase reloads the todo list from the disk,
in case the script has modified it, but does not honour
rebase.missingCommitsCheck.
This adds three tests to t3429 to demonstrate this. The first one is
not broken, as when `rebase.missingCommitsCheck' is not set, nothing
shou
`total_nr' is the total amount of items, done and toto, that are in a
todo list. But unlike `nr', it was not updated when an item was
appended to the list.
Signed-off-by: Alban Gruin
---
sequencer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sequencer.c b/sequencer.c
index cf262701e8..
In a todo list, `done_nr' is the amount of commands that were executed
or skipped, but skip_unnecessary_picks() did not update it.
Signed-off-by: Alban Gruin
---
sequencer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sequencer.c b/sequencer.c
index e61ae75451..ec9c3d4dc5 100644
--- a/se
As it is called by sequencer_continue() or after an exec command,
read_populate_todo() is a great place to check for dropped commits in
the todo list, but complete_action() (a caller of sequencer_continue())
already does. Double-checking would show the message twice.
This adds a parameter to sequ
The total amount of commands can be used to show the progression of the
rebasing in a shell. This number is written to the disk by
read_populate_todo() when the todo list is loaded from
sequencer_continue() or pick_commits(), but not by complete_action(),
which releases its todo list before callin
This adds the ability to check if commits were dropped when resuming a
rebase (with `--continue') or when reloading the todo list after an
`exec' command.
Tests added previously should work now.
Signed-off-by: Alban Gruin
---
sequencer.c | 5 -
t/t3404-rebase-interactive.s
todo_list_check() works by checking if every commit in old_todo (the
backup list) is also present in new_todo (the todo list to check).
This works only when no commits have been picked (ie. right after the
initial edit). In other cases, the backup list will contain one or
several commits that hav
This adds the ability for --edit-todo to check if commits were dropped
by the user using todo_list_check_against_backup().
Signed-off-by: Alban Gruin
---
rebase-interactive.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/rebase-interactive.c b/rebase-interactive.
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> Even though we have been sticking to C89, there are a few handy
>> features we borrow from more recent C language in our codebase after
>> trying them in weather balloons and saw that nobody screamed.
>>
>> Spell them out.
>
> Thanks for this.
Bryan Turner writes:
> On Tue, Jul 16, 2019 at 10:21 AM Junio C Hamano wrote:
>>
>> Even though we have been sticking to C89, there are a few handy
>> features we borrow from more recent C language in our codebase after
>> trying them in weather balloons and saw that nobody screamed.
>>
>> Spell
"Thurston via GitGitGadget" writes:
> Instead of managing paths and relative paths such as echo
> "path/to/the/file.txt" >../../../../../../.gitignore git ignore
> path/to/the/file.txt No matter what directory that is in, the correct
> relative path will be added to the gitignore.
Hmph, do you m
Christian Couder writes:
> On Mon, Jul 15, 2019 at 1:16 AM Matthew DeVore wrote:
>>
>> On Fri, Jul 12, 2019 at 02:02:52PM -0700, Junio C Hamano wrote:
>> > * md/list-objects-filter-combo (2019-06-28) 10 commits
>> > - list-objects-filter-options: make parser void
>> > - list-objects-filter-opt
"Ulrich Windl" writes:
> I just had "an interesting case" for a merge with conflicts:
> The merge re-introduced a file that had been renamed (say old one is "bla",
> and the new one is "foo").
> After merging the changes from bla into foo, I added foo, trying to remove
> bla:
>> git add foo
>>
> Wouldn't this simpler to type and less error prone, as you do
> have to
> $ cd path/to/the
> ... work in that deep
> ... realize that file.txt in that directory needs ignoring ...
> $ echo file.txt > .gitignore
that would have "path/to/the/.gitignore" which contains "file.
my mistake, my last email should have read:
$ cd path/to/the
... work in that deep directory ...
... realize that file.txt in that directory needs ignoring ...
... know relative path of both desired ignore file and cwd ...
$ echo path/to/the/file.txt > ../../../.gitignore
... or with this
Am 16.07.19 um 21:01 schrieb Junio C Hamano:
> but as long as we declare that we take "{ 0 }" as a mere convention
> [...], I am perfectly fine with it, and if it is hidden
> behind a macro, that would be even better ;-)
And I thought that "Avoid macros!" would be a welcome guideline...
I think w
Edmundo Carmona Antoranz writes:
> On Fri, Jul 12, 2019 at 11:18 PM Edmundo Carmona Antoranz
> wrote:
>>
>> Option -m can be used to defined the message for the revision instead
>> of the default message that contains all squashed revisions info.
>>
>
> I have noticed that just adding the suppor
Jeff King writes:
> ... My big question is if we use "{}" for gcc (and
> compatible friends), does that squelch all of the complaints from other
> compilers and tools that might see the "{0}" version? In particular,
> does it work for sparse?
Yeah, I agree that it is the most important question.
Junio C Hamano writes:
>> The other warnings in that function are issued using warning_errno()
>> (shorter code, consistency is enforced) and messages are marked for
>> translation. That would be nice to have here as well, no?
>
> Absolutely. Also, downcase "Could" and perhaps use _() around.
On Wed, Jul 17, 2019 at 11:13:04AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... My big question is if we use "{}" for gcc (and
> > compatible friends), does that squelch all of the complaints from other
> > compilers and tools that might see the "{0}" version? In particular,
> > do
Jeff King writes:
> Other than that, our options seem to be:
>
> 1. Live with it. IIRC we're already not sparse-clean, and Ramsay
> mostly looks at the diff to find new problems.
OK.
> 2. Pass -Wno-non-pointer-null to sparse. Unfortunately that also
> disables more useful warnings
When resolving a conflict on a path in favor of removing it, using
"git rm" on it is the standard way to do so. The user however is
greeted with a "needs merge" message during that operation:
$ git merge side-branch
$ edit conflicted-path-1
$ git add conflicted-path-1
On Wed, Jul 17, 2019 at 12:07 PM Junio C Hamano wrote:
>
> Sure. I started skimming and then gave up after seeing that quite a
> lot of code has been shuffled around without much explanation (e.g.
> printing of "Squash commit -- not updating HEAD" is gone from the
> callee and now it is a respons
On Wed, Jul 17, 2019 at 6:41 PM Edmundo Carmona Antoranz
wrote:
>
>
> Does it make sense to keep this file in those two situations?
yes it does. disregard the question.
30 matches
Mail list logo
