Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > > wrote:
> > > > >
> > > > >
> > > > > from "man git-reset":
> > > > >
> > > > > SYNOPSIS
> > > > > git reset [-q] [] [--] ...
> >
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
> >
> > On Sat, 8 Dec 2018, Duy Nguyen wrote:
> >
> > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > wrote:
> > > >
> > >
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
> >
> > On Sat, 8 Dec 2018, Duy Nguyen wrote:
> >
> > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > wrote:
> > > >
> > >
On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
>
> On Sat, 8 Dec 2018, Duy Nguyen wrote:
>
> > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > wrote:
> > >
> > >
> > > from "man git-reset":
> > >
> > >
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote:
> >
> >
> > from "man git-reset":
> >
> > SYNOPSIS
> > git reset [-q] [] [--] ...
> > git reset (--patch | -p) [] [--] [...]
> >
On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote:
>
>
> from "man git-reset":
>
> SYNOPSIS
> git reset [-q] [] [--] ...
> git reset (--patch | -p) [] [--] [...]
> git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q]
> []
>
&g
inherited the "drive letter" concept from DOS,
> and everybody (tm) familar with the code and the path handling
> in Git is used to that wording.
> Even if there was a better name, it needed to be addressed
> in a patch series different from this one.
> Here I
1/-0 contrib/README
> > > 3:unchanged+1/-0 t/README
> > > Patch update>>
> > >
> > > Here I hit enter. Did you?
> >
> > perhaps i'm just not seeing it, but from "man git-add", it
> > doesn't seem obvious that you
from "man git-reset":
SYNOPSIS
git reset [-q] [] [--] ...
git reset (--patch | -p) [] [--] [...]
git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] []
oddly, the third form says nothing about possible "", even
though i'm pretty sure they're vali
hread-safe as chdir() affects a
process as a whole...
The old (and non-thread-save) OS calls chdir()/pwd() had been
replaced by a string operation.
The cygwin layer "knows" that "C:\cygwin" is an absolute path,
but the new string operation does not.
"git clone C
Current "man git-add" emphasizes single letter interactive
shortcut commands with "[]".
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 45652fe4a6..ad9bd7c7a6 100644
--- a/Documentation/git-add.txt
+++ b/Docum
On Fri, Dec 07, 2018 at 01:50:57PM -0800, biswaranjan panda wrote:
> Thanks Jeff and Bryan! However, I am curious that if there were a way
> to tell git blame to skip a commit (the one which added the file again
> and maybe the one which deleted it originally) while it walks back
Matthew DeVore writes:
> $ git -C pc1 fetch-pack --stdin "file://$(pwd)/srv.bare"
> Where observed.oids contains all the blobs that were missing. It tells
> the remote that it already has the "refs/heads/master" commit, which
> means it is excluded. Before, t
Jonathan Nieder writes:
>> So it seems most sensible to me if this is going to be supported that we
>> go a bit beyond the call of duty and fake up the start of it, namely:
>>
>> --- a/arch/x86/kernel/process.c
>> +++ b/arch/x86/kernel/process.c
>>
&
On Fri, 07 Dec 2018, Yaroslav Halchenko wrote:
> On Fri, 07 Dec 2018, Stefan Beller wrote:
> > > the initial "git submodule update --reset-hard" is pretty much a
> > > crude workaround for some of those cases, so I would just go earlier in
> > > the h
On Fri, Dec 7, 2018 at 6:14 PM Josh Wolfe wrote:
>
> git version 2.19.1
> steps to reproduce:
>
> # start in a brand new repo
> git init
>
> # create lots of unreachable loose objects
> for i in {1..1}; do git commit-tree -m "$(head -c 12 /dev/ur
On Fri, 07 Dec 2018, Stefan Beller wrote:
> > the initial "git submodule update --reset-hard" is pretty much a
> > crude workaround for some of those cases, so I would just go earlier in
> > the history, and redo some things, whenever I could just drop or revert
>
git version 2.19.1
steps to reproduce:
# start in a brand new repo
git init
# create lots of unreachable loose objects
for i in {1..1}; do git commit-tree -m "$(head -c 12 /dev/urandom
| base64)" "$(git mktree <&-)" <&-; done
# this prints a lot of outp
On Fri, Dec 7, 2018 at 11:04 AM wrote:
> The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
> is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
> in the same way as it is done in 'Git for Windows' in compat/mingw.[ch]
>
> Instead
o fail. In the test labeled "manual
prefetch of missing objects", we create a clone of srv.bare without
blobs called "pc1", then push some new commits to srv.bare (via a
separate "local" repo), and try to fetch missing blobs with this
command:
$ git -C pc1 fetch-pack --stdin "file://$(pwd)/srv.bare"
information before you can
>> start.
>
> Which branch should I work off of in the repo?
"master".
Also, please make sure the documentation (e.g. in
Documentation/config/user.txt) describes when a user would want to set
this option.
See also:
- Documentation/SubmittingPatches
-
t; No, the patch-id doesn't just care about the diff, it cares about the
> context before the diff too.
Sorry, I did a bad job of communicating. When I said "diff text", I was
including context.
[...]
> Observe that the diff --git line matters, we hash it:
>
&
rg/lkml/20181125185004.151077...@linutronix.de/
>>
>> I am guessing quilt does not bother including the leading "diff a/foo
>> b/foo" because it's redundant with the next two lines, however this
>> remains a valid patch recognized by git-am.
>>
>> If you
Hi Johannes,
On Thu, Dec 06, 2018 at 11:20:07PM +0100, Johannes Schindelin wrote:
> Hi William,
>
>[...]
>
> There *is* a way to get what you want that is super easy and will
> definitely work: if you sit down and do it ;-)
>
> Please let us know if you need any additional information before
lt does not bother including the leading "diff a/foo
> b/foo" because it's redundant with the next two lines, however this
> remains a valid patch recognized by git-am.
>
> If you pipe that patch via git-patch-id, it produces nothing, but if I
> put in the leading "diff",
he worktree set to it as well.
> NB "gitlink" -- just now discovered the thing for me. Thought it would be
> called a subproject echoing what git diff/log -p shows for submodule
> commits.
The terminology is messy:
The internal representation in Gits object model
Hi Torsten,
On Fri, 7 Dec 2018, tbo...@web.de wrote:
> compat/mingw-cygwin.c | 28
> compat/mingw-cygwin.h | 20
Please use compat/win32/path.c (or .../path-utils.c) instead. This is not
so much about MINGW or Cygwin or MSys or MSYS2 or Visual
On Thu, Dec 6, 2018 at 11:26 PM Jeff King wrote:
>>
>> On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
>>
> >> Thanks! Strangely git log --follow does work.
>>
>> I suspect it would work even without --follow. When you limit a log
>>
>
> I am guessing quilt does not bother including the leading "diff a/foo
> b/foo" because it's redundant with the next two lines, however this
> remains a valid patch recognized by git-am.
>
> If you pipe that patch via git-patch-id, it produces nothing, but if I
&
On Fri, Dec 7, 2018 at 9:51 AM Johannes Sixt wrote:
>
> From: Elijah Newren
>
> In commit 6aba117d5cf7 ("am: avoid directory rename detection when
> calling recursive merge machinery", 2018-08-29), the git-rebase manpage
> probably should have also been
o" because it's redundant with the next two lines, however this
remains a valid patch recognized by git-am.
If you pipe that patch via git-patch-id, it produces nothing, but if I
put in the leading "diff", like so:
diff a/arch/x86/kernel/process.c b/arch/x86/kernel/proce
From: Elijah Newren
In commit 6aba117d5cf7 ("am: avoid directory rename detection when
calling recursive merge machinery", 2018-08-29), the git-rebase manpage
probably should have also been updated to note the stronger
incompatibility between git-am and directory rename detectio
hread-safe as chdir() affects a
process as a whole...
The old (and non-thread-save) OS calls chdir()/pwd() had been
replaced by a string operation.
The cygwin layer "knows" that "C:\cygwin" is an absolute path,
but the new string operation does not.
"git clone C
On Thu, Dec 6, 2018 at 11:26 PM Jeff King wrote:
>
> On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
>
> > Thanks! Strangely git log --follow does work.
>
> I suspect it would work even without --follow. When you limit a log
> traversal with a pathspec,
On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
> Thanks! Strangely git log --follow does work.
I suspect it would work even without --follow. When you limit a log
traversal with a pathspec, like:
git log foo
that is not about following some continuous stream of cont
Thanks! Strangely git log --follow does work.
On Thu, Dec 6, 2018 at 10:55 PM Bryan Turner wrote:
>
> On Thu, Dec 6, 2018 at 10:49 PM biswaranjan panda
> wrote:
> >
> > I have the following scenario:
> >
> > On a branch A, I deleted a file foo.txt and committed t
branch B where the file is present.
> Then checkout A. Then do
> git checkout B -- path_to_file
It doesn't change anything, but note that you don't need to checkout B
first, to restore the file. If you know a commit SHA where the file is
present, "git checkout SHA -- path_to_file&quo
I have the following scenario:
On a branch A, I deleted a file foo.txt and committed the change. Then
I did a bunch of other changes.
Now I want to undelete foo.txt.
One way is to checkout a separate branch B where the file is present.
Then checkout A. Then do
git checkout B -- path_to_file
Hi,
I have set my UI font in the git-gui preferences, but it only affects
the menus and certain widgets. It does not apply the font to labels
and buttons. This creates a problem for my HiDPI display because the
fonts are quite small. I've never programmed in TCL/TK before so I
don't know
Hi Stefan,
Thanks for the dialogue! Replies are embedded below.
On Thu, 06 Dec 2018, Stefan Beller wrote:
> ...
> > > What if the branch differs from the sha1 recorded in the superproject?
> > git reset --hard itself is an operation which should be done with some
>
a subsequent rebase command.
>
> I mean, use one's own short memory instead of copying and pasting.
As everybody pointed out, a single integer number will fundamentally
unworkable with distributed nature of Git that inherently makes the
history with forks and merges. Besides, there is no way
On Thu, Dec 6, 2018 at 6:30 PM Lukáš Krejčí wrote:
>
> I am talking about `git bisect replay`. The shell script, as far as I
> can see, only updates the references (ref/bisect/*) and never checks if
> the revisions marked as 'good' are ancestors of the 'bad' one.
> Ther
at a former employer, versus continuous delivery. That's due to lack of
personal familiarity with CD -- not any real objections.
Thanks,
John
On 12/06/2018 03:08 PM, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 5 Dec 2018, Jeff King wrote:
>
>> The model that fits more natu
hi everybody,
I am the maintainer of cregit. We are trying to improve blame
traceability at the token level (see
https://github.com/dmgerman/papers/blob/master/editorials/cregit/cregit.org)
We use git-blame heavilty in cregit. One of the features that I
would like to add to cregit
Hi William,
On Thu, 6 Dec 2018, William Hubbs wrote:
> On Thu, Dec 06, 2018 at 07:38:08PM +0100, Martin Ågren wrote:
> > Hi William,
> >
> > [...]
> >
> > This idea was floated a couple of months ago [1]. Junio seemed to find
> > the request sensible and outlined a design. No patches
On Thu, Dec 6, 2018 at 12:09 PM Johannes Schindelin
wrote:
>
> Hi,
>
> On Wed, 5 Dec 2018, Jeff King wrote:
>
> > The model that fits more naturally with how Git is implemented would be
> > to use submodules. There you leak the hash of the commit from the
> &
On Thu, Dec 6, 2018 at 1:25 PM Yaroslav Halchenko wrote:
>
>
> On Thu, 06 Dec 2018, Stefan Beller wrote:
>
> > On Thu, Dec 6, 2018 at 10:02 AM Yaroslav Halchenko
> > wrote:
>
> > > Dear Git Gurus,
>
> > > I wondered what would be your take on my w
On Thu, 06 Dec 2018, Stefan Beller wrote:
> On Thu, Dec 6, 2018 at 10:02 AM Yaroslav Halchenko
> wrote:
> > Dear Git Gurus,
> > I wondered what would be your take on my wishlist request to add
> > --reset-hard option, which would be very similar to regular "
Hi,
On Wed, 5 Dec 2018, Jeff King wrote:
> The model that fits more naturally with how Git is implemented would be
> to use submodules. There you leak the hash of the commit from the
> private submodule, but that's probably obscure enough (and if you're
> really worried, you can
ecause Eric suggested a tool called
> direnv. Maybe that would work for you.
Yes, this design would solve the issue.
I'll take a look at direnv, but it would be nice to have native git
support for this. :-)
Thanks,
William
> [1]
> https://public-inbox.org/git/0f66ad7a-2289-2cce-6533-a
author.email and
> author.name settings to the git-config system.
>
> Additionally you could add committer.name and committer.email, but the
> only reason I bring the committer variations up is consistency since I
> see you also have GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL environm
On Thu, Dec 6, 2018 at 10:02 AM Yaroslav Halchenko wrote:
>
> Dear Git Gurus,
>
> I wondered what would be your take on my wishlist request to add
> --reset-hard option, which would be very similar to regular "update" which
> checks out necessary commit, but I wan
.
There are the GIT_AUTHOR_EMAIL and GIT_AUTHOR_NAME environment
variables, but these would have to be set globally. Also, there is the
--author command line switch for the "git commit" command, but this is
easy to forget to use.
Is there something I'm missing?
If not, I would like to propose the addition of au
Dear Git Gurus,
I wondered what would be your take on my wishlist request to add
--reset-hard option, which would be very similar to regular "update" which
checks out necessary commit, but I want it to remain in the branch.
Rationale: In DataLad we heavily rely on submodules, a
On Thu, 2018-12-06 at 17:31 +0100, Christian Couder wrote:
> > When Git replays the bisect log, it only updates refs/bisect/bad,
> > refs/bisect/good-*, refs/bisect/skip-* and reconstructs the log in
> > .git/BISECT_LOG. After that check_good_are_ancestors_of_bad() verifies
Hi,
On Thu, Dec 6, 2018 at 3:43 PM Lukáš Krejčí wrote:
>
> Hello again,
>
> after looking into this today, I'm not sure if this can be considered a
> bug - it's just that I expected Git to check out the exact commit to
> test that was there before resetting the bisect. That
Hello again,
after looking into this today, I'm not sure if this can be considered a
bug - it's just that I expected Git to check out the exact commit to
test that was there before resetting the bisect. That made me uncertain
whether Git restored the correct state.
When I looked at what Git
On Thu, Dec 06, 2018 at 09:31:36AM +0900, Junio C Hamano wrote:
> >> It would be great if git-log has a formatting option to insert an
> >> index of the current commit since HEAD.
> >>
> >> It would allow after quitting the git-log to immediately fire up &qu
Hi,
When running "git add -p" on git version 2.19.2 and "diff.noprefix" set
to true, it still shows the "a/" and "b/" prefixes.
This issue has been reported in 2016 already[1], but is still there in
2.19.2.
[1]
https://public-inbox.org/git/e1d7329a
Registration is now open for the Contributor Summit at Git Merge. To
recap from my earlier announcement[1]:
When: Thursday, January 31, 2019. 10am-5pm.
Where: The Egg[2], Brussels, Belgium
What: Round-table discussion about Git
Who: All contributors to Git or related projects in the Git
On Thu, Dec 06, 2018 at 10:17:24AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > The other major user of that feature I can think of is LFS. There Git
> > ends up diffing the LFS pointers, not the big files. Which arguably is
> > the wrong thing (you'd prefer to see the actual fi
information leaks of the supposedly
>> > protected data.
>> > ...
>>
>> Yup, with s/implemented/designed/, I agree all you said here
>> (snipped).
>
> Heh, yeah, I actually scratched my head over what word to use. I think
> Git _could_ be written in a way that
Hi,
When running `git fetch` it returns every time the same 100+ branches
that didn't change at all but still specifies them as new branches in
the server. It also prints the branches that did change.
I don't see this behavior in other repositories I contribute. how do I fix it?
The same output
On Wed, Dec 05, 2018 at 11:42:09PM +, Coiner, John wrote:
> > For instance, Git is very eager to try to find delta-compression
> > opportunities between objects, even if they don't have any relationship
> > within the tree structure. So imagine I want to know the content
.
>
> Yup, with s/implemented/designed/, I agree all you said here
> (snipped).
Heh, yeah, I actually scratched my head over what word to use. I think
Git _could_ be written in a way that is both compatible with existing
repositories (i.e., is still recognizably Git) and is careful abou
n't have a more positive response. What you want to do is
> perfectly reasonable, but I just think it's a mismatch with how Git
> works (and because of the security impact, one missed corner case
> renders the whole thing useless).
Yup, again.
Storing source files encrypted and decrypting
Konstantin Khomoutov writes:
> On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote:
>
>> It would be great if git-log has a formatting option to insert an
>> index of the current commit since HEAD.
>>
>> It would allow after quitting the git-l
leaks
>
> - you're fighting an uphill battle against the way Git is implemented;
> there's no single point to enforce this kind of segmentation
>
> The model that fits more naturally with how Git is implemented would be
> to use submodules. There you leak the hash of
etical AMD monorepo should be able to
> securely deny read access in certain subtrees to users without required
> permissions".
>
> I.e. in this case there will be a
> secret-stuff-here/ryzen-microcode.code.encrypted or whatever,
> unauthorized users can't see the content, but t
On Wed, Dec 05 2018, Coiner, John wrote:
I forgot to mention this in my initial reply in
<878t13zp8y@evledraar.gmail.com>, but on a re-reading I re-spotted
this:
> - hashes are secret. If the hashes from a protected tree leak, the
> data also leaks. No check on the server prevents it
On Wed, Dec 05 2018, Duy Nguyen wrote:
> On Wed, Dec 5, 2018 at 9:46 PM Derrick Stolee wrote:
>> This directory-level security is not a goal for VFS for Git, and I don't
>> see itbecoming a priority as it breaks a number of design decisions we
>> made in our object stor
On Wed, Dec 05, 2018 at 08:13:16PM +, Coiner, John wrote:
> One obstacle to moving AMD to git/VFSForGit is the lack of access
> control support in git. AMD has a lot of data whose distribution must be
> limited. Sometimes it's a legal requirement, eg. CPU core designs are
> c
On Wed, Dec 5, 2018 at 9:46 PM Derrick Stolee wrote:
> This directory-level security is not a goal for VFS for Git, and I don't
> see itbecoming a priority as it breaks a number of design decisions we
> made in our object storage and communication models.
>
> The best I can t
On 12/5/2018 3:34 PM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Dec 05 2018, Coiner, John wrote:
I'm an engineer with AMD. I'm looking at whether we could switch our
internal version control to a monorepo, possibly one based on git and
VFSForGit.
Has anyone looked at adding access control to git
On Wed, Dec 05 2018, Coiner, John wrote:
> I'm an engineer with AMD. I'm looking at whether we could switch our
> internal version control to a monorepo, possibly one based on git and
> VFSForGit.
>
> One obstacle to moving AMD to git/VFSForGit is the lack of access
> cont
Hi,
I'm an engineer with AMD. I'm looking at whether we could switch our
internal version control to a monorepo, possibly one based on git and
VFSForGit.
One obstacle to moving AMD to git/VFSForGit is the lack of access
control support in git. AMD has a lot of data whose distribution must
On Dez 05 2018, Elijah Newren wrote:
> Or, just use name-rev so it works with non-linear histories too:
>
> git log | git name-rev --refs=$(git symbolic-ref HEAD) --stdin | less
That wouldn't work for a detached HEAD, though, and you need to use
--no-abbrev.
Andreas.
--
Andreas Sc
On Wed, Dec 5, 2018 at 6:56 AM Konstantin Khomoutov wrote:
>
> On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote:
>
> > It would be great if git-log has a formatting option to insert an
> > index of the current commit since HEAD.
> >
> > It w
On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote:
> It would be great if git-log has a formatting option to insert an
> index of the current commit since HEAD.
>
> It would allow after quitting the git-log to immediately fire up "git
> rebase -i HEAD~in
It would be great if git-log has a formatting option to insert an index of the
current commit since HEAD.
It would allow after quitting the git-log to immediately fire up "git rebase -i
HEAD~index" instead of "git rebase -i go-copy-paste-this-long-number-id".
On Tue, Dec 04, 2018 at 06:48:22PM -0800, Stefan Beller wrote:
> > Perhaps we should note this more prominently, and since Brandon isn't at
> > Google anymore can some of you working there edit this post? It's the
> > first Google result for "git protocol v2"
-cc linux list
> Perhaps we should note this more prominently, and since Brandon isn't at
> Google anymore can some of you working there edit this post? It's the
> first Google result for "git protocol v2", so it's going to be quite
> confusing for people if after
> Keep the properties introduced in 10f5c52656 (submodule: avoid
> auto-discovery in prepare_submodule_repo_env(), 2016-09-01), by fixating
> the git directory of the submodule.
This is to avoid the autodetection of the Git repository, making it less
error-prone; looks good to me.
On Thu, 29 Nov 2018 at 16:39, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 29 2018, Mateusz Loskot wrote:
> > On Thu, 29 Nov 2018 at 16:03, Ævar Arnfjörð Bjarmason
> > wrote:
> >> On Wed, Nov 28 2018, Mateusz Loskot wrote:
> >> >
> >> > (using
On Tue, 2018-12-04 at 13:01 +0100, Christian Couder wrote:
> To debug I think it would be interesting to see the output of the
> following commands just before we get different results:
>
> git for-each-ref 'refs/bisect/*'
>
> and
>
> git log -1 --format=oneline
&g
This adds a warning for the issue discussed upthread. As noted in
these patches we've been emitting an "error" while not impacting the
exit code, should we die() instead? Maybe, but until there's consensus
on that let's change this to warning() while we're at it.
Ævar Arnfjörð Bjarmason (3):
On Tue, Dec 4, 2018 at 12:20 PM Lukáš Krejčí wrote:
>
> On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote:
> >
> > Could you try to check that? And first could you give us the output of:
> >
> > git merge-base 5b394b2ddf
(I'm sorry about the formatting, here's the message again.)
Executing git bisect replay reaches a different commit than
the one that is obtained by running the commands from the bisect log manually.
Distribution: Arch Linux
git: 2.19.2-1
perl: 5.28.1-1
pcre2: 10.32-1
expat: 2.2.6-1
perl-error
On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote:
>
> Could you try to check that? And first could you give us the output of:
>
> git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
> 94710cac0ef4ee177a63b5227664b38c95bbf703
$ git merge-base 5b394b2ddf0347bef56e50c69
On Tue, Dec 4, 2018 at 10:53 AM Lukáš Krejčí wrote:
>
> Executing git bisect replay reaches a different commit than
> the one that is obtained by running the commands from the bisect log manually.
> $ git bisect replay /var/tmp/git-bisect.log
> We are not bisecting.
> Bisec
Executing git bisect replay reaches a different commit than
the one that is obtained by running the commands from the bisect log manually.
Distribution: Arch Linux
git: 2.19.2-1
perl: 5.28.1-1
pcre2: 10.32-1
expat: 2.2.6-1
perl-error: 0.17027-1
grep: 3.1-2
bash: 4.4.023-1
no system /etc
>From 9a7edd7f94b82335177917463cb334541b4d2cb0 Mon Sep 17 00:00:00 2001
From: Petter Reinholdtsen
Date: Mon, 3 Dec 2018 12:24:22 +0100
Subject: [PATCH] i18n: Update the nb translation of git-gui and start on
glossary list.
Signed-off-by: Petter Reinholdtsen
---
po/glossary/nb.po |
On Mon, Nov 26, 2018 at 09:03:37PM +0100, SZEDER Gábor wrote:
> Test scripts checking 'git daemon' stop the daemon with a TERM signal,
> and the 'stop_git_daemon' helper checks the daemon's exit status to
> make sure that it indeed died because of that signal.
>
> This check
Junio C Hamano writes:
> If "git clean" takes a pathspec, perhaps you can give a negative
> pathspec to exclude whatever you do not want to get cleaned,
> something like
>
> git clean '*.o' ':!precious.o'
>
> to say "presious.o is ignored (hence norma
Team,
Git for Windows v2.20.0-rc2 is available here:
https://github.com/git-for-windows/git/releases/tag/v2.20.0-rc2.windows.1
There is already one known issue: the size of the installer increased (see
https://github.com/git-for-windows/git/issues/1963). This is in the
process of being
Hi Junio,
> A release candidate Git v2.20.0-rc2 is now available for testing
> at the usual places. It is comprised of 934 non-merge commits
> since v2.19.0, contributed by 76 people, 25 of which are new faces.
Here are a few suggested tweaks after reading the draft release notes
> > Would something like git clean --exclude=file-pattern work as a
> > compromise notion? Files matching the pattern would not be cleaned
> > regardless of .gitignore or their potential preciousness status
> > long-term. Multiple repetitions of the --exclude option mig
Jiang Xin writes:
> Git v2.20.0-rc2 has been released, and there are 5 new messages need to
> be translated. So let's start new round of l10n for Git 2.20.0.
A huge thanks, as always, to the translation team. Jiang, sorry to
see that -rc2 slipped just after you sent out the round 2 m
"Randall S. Becker" writes:
> Would something like git clean --exclude=file-pattern work as a
> compromise notion? Files matching the pattern would not be cleaned
> regardless of .gitignore or their potential preciousness status
> long-term. Multiple repetitions of the
On December 2, 2018 8:26, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Dec 01 2018, Cameron Boehmer wrote:
>
> > 1) add a new flag
> > -l, --local
> > Do not consult git config --global core.excludesFile in
> > determining what files git ignores. This is use
1 - 100 of 30258 matches
Mail list logo
