Hi Everyone,
I'm seeing this issue on Windows: https://pastebin.com/YfB25E4T . It
seems the filename AUX is the culprit. Also see
https://blogs.msdn.microsoft.com/oldnewthing/20031022-00/?p=42073 .
(Thanks to Milleneumbug on Stack Overflow).
I did not name the file, someone else did. I doubt the
On Fri, Feb 09, 2018 at 03:19:57PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Feb 09 2018, Nguyễn Thái Ngọc Duy jotted:
>
> > By default, some option names (mostly --force, scripting related or for
> > internal use) are not completable for various reasons. When
> > GIT_COMPLETION_OPTIONS i
On Sat, Feb 10, 2018 at 03:55:58AM -0500, Jeffrey Walton wrote:
> Hi Everyone,
>
> I'm seeing this issue on Windows: https://pastebin.com/YfB25E4T . It
> seems the filename AUX is the culprit. Also see
> https://blogs.msdn.microsoft.com/oldnewthing/20031022-00/?p=42073 .
> (Thanks to Milleneumbug
On Sat, Feb 10, 2018 at 4:31 AM, Torsten Bögershausen wrote:
> On Sat, Feb 10, 2018 at 03:55:58AM -0500, Jeffrey Walton wrote:
>> Hi Everyone,
>>
>> I'm seeing this issue on Windows: https://pastebin.com/YfB25E4T . It
>> seems the filename AUX is the culprit. Also see
>> https://blogs.msdn.microso
On Fri, Feb 09, 2018 at 02:28:28PM +0100, lars.schnei...@autodesk.com wrote:
> From: Lars Schneider
>
> Git recognizes files encoded with ASCII or one of its supersets (e.g.
> UTF-8 or ISO-8859-1) as text files. All other encodings are usually
> interpreted as binary and consequently built-in Git
On Fri, Feb 09, 2018 at 03:13:30PM -0800, Elijah Newren wrote:
> This takes advantage of the fact that "worktrees/$WORKTREE/HEAD" will
> currently resolve as a ref, which may not be true in the future with
> different ref backends. I don't think it locks us in to supporting
> resolving other workt
On Sat, Feb 10, 2018 at 1:37 AM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Thu, Feb 01 2018, Junio C. Hamano jotted:
>
>> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits
>> - dir.c: stop ignoring opendir() error in open_cached_dir()
>> - update-index doc: note a fixed bug in the untrack
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S.
I know this may seem inappropriate so i ask for your forgiveness but i wish to
get to know you better, if I may be so bold. I consider myself an easy-going
man, adventurous, honest and fun loving person but I am curre
On Thu, Feb 8, 2018 at 3:45 AM, Jeff King wrote:
> On Mon, Feb 05, 2018 at 08:59:52PM +0700, Duy Nguyen wrote:
>
>> On Mon, Feb 5, 2018 at 8:48 PM, Andreas Kalz wrote:
>> > Hello,
>> >
>> > I am using git frequently and usually it is running great.
>> >
>> > I read to write to this eMail address
On Thu, Feb 8, 2018 at 2:00 AM, Stefan Beller wrote:
>> +
>> +deepen-relative
>> + Requests that the semantics of the "deepen" command be changed
>> + to indicate that the depth requested is relative to the clients
>> + current shallow boundary, instead of relative to the rem
On Thu, Feb 8, 2018 at 1:19 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> ...
>> Then we still need to decide the new keyword for this feature, I feel
>> compact is a bit too vague (I read --stat=compact as "it's compact
>> stat", not "stat with compact summary"), so perhaps
>> --stat=compa
From: "Jeffrey Walton"
Hi Everyone,
I'm seeing this issue on Windows: https://pastebin.com/YfB25E4T . It
seems the filename AUX is the culprit. Also see
https://blogs.msdn.microsoft.com/oldnewthing/20031022-00/?p=42073 .
(Thanks to Milleneumbug on Stack Overflow).
I did not name the file, some
On Thu, Feb 8, 2018 at 1:06 AM, Stefan Beller wrote:
>> Something else.. maybe "struct repository *" should not be a universal
>> function argument to avoid global states. Like sha1_file.c is mostly about
>> the
>> object store, and I see that you added object store struct (nice!).
>> These sha1
On Fri, Feb 9, 2018 at 7:08 PM, Duy Nguyen wrote:
> On Fri, Feb 9, 2018 at 6:27 PM, Thomas Gummerer wrote:
>> This would loose the information about the identifier of the worktree,
>> but from a coarse look at the man page it doesn't seem like we
>> advertise that widely
>>
>> ...
>>
>> So given
On Fri, Feb 09, 2018 at 02:30:39PM -0500, Jeff King wrote:
> Yes, I think so, but we may want to avoid this anti-pattern (since
> usually "! test_i18ngrep" is a sign of something wrong. It seems like
> these tests are doing more manual reporting work than is necessary, and
> could just be relying
On Sat, Feb 10, 2018 at 05:21:05PM +0700, Duy Nguyen wrote:
> > But it doesn't seem to work:
> >
> > $ yes | head -c $((1024*1024*1024 - 10*1024*1024)) >file
> > $ git add file
> > $ git commit -m one
> > $ yes | head -c $((1024*1024*1024)) >file
> > $ git commit -am two
> > fatal: una
On Sat, Feb 10, 2018 at 01:37:20AM +0100, Leo Gaspard wrote:
> > Yeah, tag-following may be a little tricky, because it usually wants to
> > write to refs/tags/. One workaround would be to have your config look
> > like this:
> >
> > [remote "origin"]
> > fetch = +refs/heads/*:refs/quarantine
On Sat, Feb 10, 2018 at 04:59:52PM +0700, Duy Nguyen wrote:
> On Fri, Feb 09, 2018 at 03:13:30PM -0800, Elijah Newren wrote:
> > This takes advantage of the fact that "worktrees/$WORKTREE/HEAD" will
> > currently resolve as a ref, which may not be true in the future with
> > different ref backends
In check_ignore(), the first pathspec item determines the dtype for any
subsequent ones. That means that a pathspec matching a regular file can
prevent following pathspecs from matching directories, which makes no
sense. Fix that by determining the dtype for each pathspec separately,
by passing t
From: "Philip Oakley"
From: "Jeffrey Walton"
Hi Everyone,
I'm seeing this issue on Windows: https://pastebin.com/YfB25E4T . It
seems the filename AUX is the culprit. Also see
https://blogs.msdn.microsoft.com/oldnewthing/20031022-00/?p=42073 .
(Thanks to Milleneumbug on Stack Overflow).
I did
On Thu, Feb 08, 2018 at 12:29:53PM -0800, Junio C Hamano wrote:
> Jonathan Tan writes:
>
> > On Thu, 8 Feb 2018 02:56:14 +
> > "brian m. carlson" wrote:
> >
> >> Existing trailers are extracted from the input message by looking for
> >> -a group of one or more lines that (i) are all traile
On 02/10/2018 02:33 AM, Leo Gaspard wrote:> I guess the very early part
of the discussion you're speaking of is what
> I was assuming after reading
> https://marc.info/?l=git&m=132478296309094&w=2
>
> [...]
>
> So the reason for a post-fetch in my opinion is the same as for a
> pre-push / pre
On 02/10/2018 01:21 PM, Jeff King wrote:
> On Sat, Feb 10, 2018 at 01:37:20AM +0100, Leo Gaspard wrote:
>
>>> Yeah, tag-following may be a little tricky, because it usually wants to
>>> write to refs/tags/. One workaround would be to have your config look
>>> like this:
>>>
>>> [remote "origin"]
Hi Junio,
On Tue, 23 Jan 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> > index 8a861c1e0d6..1d061373288 100644
> > --- a/Documentation/git-rebase.txt
> > +++ b/Documentation/git-rebase.txt
> > @@ -368,6
Duy Nguyen writes:
>> Yup, this is about giving summary in a compact way, not about giving
>> a compact stat information. I agree with all the above reasoning,
>> and that is why I said that your "compact-summary" was a good way to
>> refer to the feature.
>
> OK I'll wait for a few days. If the
Duy Nguyen writes:
> On Fri, Feb 09, 2018 at 03:13:30PM -0800, Elijah Newren wrote:
>> This takes advantage of the fact that "worktrees/$WORKTREE/HEAD" will
>> currently resolve as a ref, which may not be true in the future with
>> different ref backends. I don't think it locks us in to supporti
I need a good and honest person to claim the sum of seven million
British Pound which i inherited from my late husband. My name is Mrs.
Emile Kenold, presently i am in a very critical health condition in
which I sleep every night without knowing my fate day by day. I am a
widow suffering from long
Hi *,
I did some experimenting to understand rebasing better. I'm trying to
follow ProGit 2nd edition. I used the repository example from here:
https://git-scm.com/book/en/v2/Git-Branching-Rebasing#rbdiag_e
I did a short test setup and did a few rebases, expecting a certain
result from my limite
Hi Eric,
On Tue, 30 Jan 2018, Eric Sunshine wrote:
> On Mon, Jan 29, 2018 at 5:54 PM, Johannes Schindelin
> wrote:
> > [...]
> > This commit implements the commands to label, and to reset to, given
> > revisions. The syntax is:
> >
> > label
> > reset
> > [...]
> >
> > Signed-o
Hi Phillip,
On Wed, 31 Jan 2018, Phillip Wood wrote:
> On 31/01/18 13:21, Johannes Schindelin wrote:
> >
> > On Tue, 30 Jan 2018, Stefan Beller wrote:
> >
> >> On Mon, Jan 29, 2018 at 2:54 PM, Johannes Schindelin
> >> wrote:
> >>> @@ -116,6 +118,13 @@ static GIT_PATH_FUNC(rebase_path_stopped_s
Hi Sergey,
On Fri, 9 Feb 2018, Sergey Organov wrote:
> Johannes Schindelin writes:
>
> [...]
>
> > With this patch, the goodness of the Git garden shears comes to `git
> > rebase -i` itself. Passing the `--recreate-merges` option will generate
> > a todo list that can be understood readily, an
There are some commands that have to be skipped from rearranging by virtue
of not handling any commits.
However, the logic was not quite obvious: it skipped commands based on
their position in the enum todo_command.
Instead, let's make it explicit that we skip all commands that do not
handle any
In the upcoming commits, we will teach the sequencer to recreate merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo li
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The previous patch implemented the `label` and `
Once upon a time, I dreamt of an interactive rebase that would not
flatten branch structure, but instead recreate the commit topology
faithfully.
My original attempt was --preserve-merges, but that design was so
limited that I did not even enable it in interactive mode.
Subsequently, it *was* ena
As pointed out in a review of the `--recreate-merges` patch series,
`rollback_lock_file()` clobbers errno. Therefore, we have to report the
error message that uses errno before calling said function.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 13 -
1 file changed, 8 inserti
The sequencer just learned new commands intended to recreate branch
structure (similar in spirit to --preserve-merges, but with a
substantially less-broken design).
Let's allow the rebase--helper to generate todo lists making use of
these commands, triggered by the new --recreate-merges option. Fo
Similar to the `preserve` mode simply passing the `--preserve-merges`
option to the `rebase` command, the `recreate` mode simply passes the
`--recreate-merges` option.
This will allow users to conveniently rebase non-trivial commit
topologies when pulling new commits, without flattening them.
Sig
In the previous patches, we implemented the basic functionality of the
`git rebase -i --recreate-merges` command, in particular the `merge`
command to create merge commits in the sequencer.
The interactive rebase is a lot more these days, though, than a simple
cherry-pick in a loop. For example, i
From: Stefan Beller
Up to now each command took a commit as its first argument and ignored
the rest of the line (usually the subject of the commit)
Now that we are about to introduce commands that take different
arguments, clarify each command by giving the argument list.
Signed-off-by: Stefan
This one is a bit tricky to explain, so let's try with a diagram:
C
/ \
A - B - E - F
\ /
D
To illustrate what this new mode is all about, let's consider what
happens upon `git rebase -i --recreate-merges B`, in particular to
the commit `D`. So far, the new branch structur
Just like with regular `pick` commands, if we are trying to recreate a
merge commit, we now test whether the parents of said commit match HEAD
and the commits to be merged, and fast-forward if possible.
This is not only faster, but also avoids unnecessary proliferation of
new objects.
Signed-off-
Once upon a time, this here developer thought: wouldn't it be nice if,
say, Git for Windows' patches on top of core Git could be represented as
a thicket of branches, and be rebased on top of core Git in order to
maintain a cherry-pick'able set of patch series?
The original attempt to answer this
This allows for rebases to be run in parallel in separate worktrees
(think: interrupted in the middle of one rebase, being asked to perform
a different rebase, adding a separate worktree just for that job).
Signed-off-by: Johannes Schindelin
---
refs.c| 3 ++-
t/t343
On Fri, Feb 9, 2018 at 6:02 AM, Nguyễn Thái Ngọc Duy wrote:
> By default, some option names (mostly --force, scripting related or for
> internal use) are not completable for various reasons. When
> GIT_COMPLETION_OPTIONS is set to all, all options (except hidden ones)
> are completable.
>
> Signed
45 matches
Mail list logo
