Hello, i use Git Bash and check in very frequently.
it appears there is a range from "extreme often" to "extreme very seldom".
Examples:
{me, extreme often, Windows} very granular, with a brief yet appropriate
comment [like narrating a story] per commit-i change a few
lines of code,
Alt+Tab
PREAMBLE [START] - please feel free to skip this first section
Forgive me for asking this question on a mailing list.
stackoverflow would probably kill such a question before the bits were fully
saved to a server drive.
Let me explain why i am asking and why i am not being a troll.
[a] i'm
Help, please and thank you.
i have spent > one hour searching via Google and by visiting git-scm,
BitBucket, github, et cetera, for an excellent tutorial for
beginners and refresher for one who has not touched git for quite a while.
if you've done the same tutorial, you will recognize its
On Thu, Jul 19, 2018 at 09:08:08PM -0400, Jeff King wrote:
> Ditto for sprintf, where you should _always_ be using at least xsnprintf
> (or some better tool, depending on the situation). And for strncpy,
> strlcpy (or again, some better tool) is strictly an improvement.
Nitpick: this may be true
On Fri, Jul 06, 2018 at 04:21:47PM -0700, frede...@ofb.net wrote:
> I don't think that it's really important to find a "best" ordering for
> commands or glossary terms; it's more a matter of finding someone who
> is willing to take responsibility for choosing a reasonable ordering.
> Presumably
On Tue, Jun 12, 2018 at 09:12:19PM +0200, Peter Backes wrote:
> This incorrect claim is completely inverting the logic of Art. 17.
>
> The logic is clarly that if ANY of lit (a) to (f) is satisfied, the
> data must be deleted.
>
> It is not necessary for ALL of them to be satisfied.
>
> In
On Sat, Jun 09, 2018 at 11:50:32PM +0100, Philip Oakley wrote:
> I just want to remind folks that Gmane disappeared as a regular list because
> of a legal challenge, the SCO v IBM Unix court case keeps rumbling on, so
> clarifying the legal case for:
> a) holding the 'personal git meta data', and
On Fri, Jun 08, 2018 at 08:26:57AM +0200, Peter Backes wrote:
>
> If you run a website where the world can access a repository, you are
> responsible for obeying the GDPR with respect to that repository. If
> you receive a request to be forgotten, you have to make sure you stop
> publishing
On Fri, Jun 08, 2018 at 01:21:29AM +0200, Peter Backes wrote:
> On Thu, Jun 07, 2018 at 03:38:49PM -0700, David Lang wrote:
> > > Again: The GDPR certainly allows you to keep a proof of copyright
> > > privately if you have it. However, it does not allow you to keep
> > > publishing it if someone
On Mon, Jun 04, 2018 at 12:16:16AM +0200, Peter Backes wrote:
>
> Verifying the commit ID by itself wouldn't be any less efficient than
> before. Admitteldly, it wouldn't verify the author and authordate
> integrity anymore without additional work. That would be some overhead,
> sure, and
On Sun, Jun 03, 2018 at 10:52:33PM +02h00, hPeter Backes wrote:
> But I will take your message as saying you at least don't see any
> obvious criticism leading to complete rejection of the approach.
If you don't think a potential 2x -- 10x performance hit isn't a
blocking factor --- sure, go
On Sun, Jun 03, 2018 at 09:24:17PM +0200, Peter Backes wrote:
>
> He said: It would be a tyranny of lawyers.
>
> Let's not have a tyranny of lawyers. Let us, the engineers and hackers,
> exercise the necessary control over those pesky lawyers by defining and
> redefining the state of the art
On Sun, Jun 03, 2018 at 07:46:17PM +0200, Peter Backes wrote:
>
> Let's be honest: We do not know what legitimization exactly in each
> specific case the git metadata is being distributed under.
It seems like you are engaging in something even more dangerous than a
hardware engineering
Currently, `commit.gpgsign` allows you to give either 'true' or 'false' as a
value. If the key is not present, commits will fail:
```sh
$ git commit -m "example"
error: gpg failed to sign the data
fatal: failed to write commit object
```
I like to reuse my config file across several machines,
From: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
When 'git log' is passed the --no-walk option, no revision walk takes
place, naturally. Perhaps somewhat surprisingly, however, the provided
revisions still get sorted by commit date. So e.g 'git log --no-walk
HEAD HEAD~1' and 'git log
From: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
'git cherry-pick' internally sets the --reverse option while walking
revisions, so that 'git cherry-pick branch@{u}..branch' will apply the
revisions starting at the oldest one. If no uninteresing revisions are
given, --no-walk is
From: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
'git cherry-pick A B' implicitly sends --no-walk=sorted to the
revision walker, which means that the older of A and B will be applied
first, which is most likely surprising to most. Fix this by instead
sending --no-walk=unsorted to the
From: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
When 'git cherry-pick' and 'git revert' are used with ranges such as
'git cherry-pick A..B', the order of the commits to pick are
determined by the default date-based sorting. If a commit has a commit
date before the commit date of its
From: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
This series adds supports for 'git log --no-walk=unsorted', which
should be useful for the re-roll of my mz/rebase-range series. It also
addresses the bug in cherry-pick/revert, which makes it sort revisions
by date.
On Fri, Aug 10,
On Saturday 25 June 2005 02:20, Linus Torvalds wrote:
On Wed, 22 Jun 2005, Alexander Y. Fomichev wrote:
I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8
GHz [ MoBo: Intel E7520, intel 82801 ]
but kernel hangs on boot right after records:
Booting processor 2/1 rip
On Saturday 25 June 2005 02:20, Linus Torvalds wrote:
On Wed, 22 Jun 2005, Alexander Y. Fomichev wrote:
I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8
GHz [ MoBo: Intel E7520, intel 82801 ]
but kernel hangs on boot right after records:
Booting processor 2/1 rip
21 matches
Mail list logo
