On Mon, Feb 19, 2018 at 11:08:19PM +0100, Peter Backes wrote:
> Is thetre some existing code that could be used? I think I read
> somewhere that git once did preserve mtimes, but that this code was
> removed because of the build tool issues. Perhaps that code could
> simply be put back in, and
On Sun, Jan 28, 2018 at 03:56:57PM -, Philip Oakley wrote:
> Michal, you may want to hack up an option that can automatically create
> that format if it is of use. I sometimes find the sort order an issue in
> some of my mail clients.
If there is a From: header in the beginning of the mail
On Mon, Jan 22, 2018 at 07:47:10PM -0500, Jeff King wrote:
>
> I think Ævar is talking about the case of:
>
> 1. You make 100 objects that aren't referenced. They're loose.
>
> 2. You run git-gc. They're still too recent to be deleted.
>
> Right now those recent loose objects sit loose,
On Mon, Jan 22, 2018 at 04:09:23PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > What's tricky is to devise a way to allow us to salvage objects that
> > are placed in a cruft pack because they are accessed recently,
> > proving themselves to be no longer crufts. It could be that a good
> > way to
On Fri, Jan 19, 2018 at 11:08:46AM -0800, Junio C Hamano wrote:
> So..., is it fair to say that the one you sent in
>
> https://public-inbox.org/git/20180117193510.ga30...@lst.de/
>
> is the best variant we have seen in this thread so far? I'll keep
> that in my inbox so that I do not forget,
On Fri, Jan 19, 2018 at 12:51:52PM -0500, Robert P. J. Day wrote:
> that's all the info i was given, but it *seems* clear that the build
> process itself was making changes to one or more tracked files.
>
> technically, i guess one can design a build system to do pretty
> much anything, but is
On Wed, Jan 17, 2018 at 02:07:22PM -0800, Linus Torvalds wrote:
>
> Now re-do the test while another process writes to a totally unrelated
> a huge file (say, do a ISO file copy or something).
>
> That was the thing that several filesystems get completely and
> horribly wrong. Generally
On Sat, Jan 06, 2018 at 10:29:21AM -0700, Carl Baldwin wrote:
> > When n==m==1, "amended" pointer from X1 to A1 may allow you to
> > answer "Is this the first attempt? If this is refined, what did the
> > earlier one look like?" when given X1, but you would also want to
> > answer a related
On Mon, Dec 25, 2017 at 06:16:40PM -0700, Carl Baldwin wrote:
> At this point, you might wonder why I'm not proposing to simply add a
> "change-id" to the commit object. The short answer is that the
> "change-id" Gerrit uses in the commit messages cannot stand on its own.
> It depends on data
On Fri, Dec 22, 2017 at 11:10:19PM -0700, Carl Baldwin wrote:
> I've been calling this proposal `git replay` or `git replace` but I'd
> like to hear other suggestions for what to name it. It works like
> rebase except with one very important difference. Instead of orphaning
> the original commit,
On Sun, Nov 12, 2017 at 03:21:57PM +0100, Christian Couder wrote:
>
> Yeah I agree that it might be something interesting for the user to do.
> But in this case the sequence in which you give the good and the bad
> commits is not important.
> Only the last bad commit and the set of good commits
On Sat, Nov 11, 2017 at 11:38:23PM +0900, Junio C Hamano wrote:
>
> Thanks for saving me time to explain why 'next' is still a very
> important command but the end users do not actually need to be
> strongly aware of it, because most commands automatically invokes it
> as their final step due to
On Sun, Oct 08, 2017 at 03:44:14PM -0400, Robert P. J. Day wrote:
> >
> > find | xargs git rm
> >
> > myself.
>
> that's what i would have normally used until i learned about git's
> magical globbing capabilities, and i'm going to go back to using it,
> because git's magical globbing
On Sun, Oct 08, 2017 at 10:32:40AM -0400, Paul Smith wrote:
> Personally I don't use Git's magical globbing capabilities, and use "git
> rm" as if it were UNIX rm. So in your request above I'd use:
>
>git rm $(find . -name Makefile)
>
> which I find simpler.
I have to agree that git's
On Sat, Oct 07, 2017 at 03:43:43PM -0400, Robert P. J. Day wrote:
> > -r
> > Recursively remove the contents of any directories that match
> > ``.
> >
> > or something.
>
> it's been a long week, so take this in the spirit in which it is
> intended ... i think the "git rm" command and
On Mon, Jun 05, 2017 at 07:36:58PM -0400, Hector Santos wrote:
> Do you see any technical issues with using programmable hooks or something
> like this would have to be patched in? I am giving it a serious thought to
> exploring a fix to the Git Daemon over the wire completion issues on
> Windows.
So Junio owns the pub/scm/git/git.git tree on kernel.org, and he may
already have access to create new repo's under the pub/scm/git
hierarchy. In which case we might not need to bug the kernel.org
administrators at all.
Also, I'll note that it is possible to set up some repo's such that a
group
On Sat, Mar 25, 2017 at 06:51:21PM +0100, Ævar Arnfjörð Bjarmason wrote:
> In GPLv3 projects only, not GPLv2 projects. The paragraphs you're
> quoting all explicitly mention v3 only, so statements like
> "incompatible in one direction" only apply to Apache 2 && GPLv3, but
> don't at all apply to
On Fri, Mar 10, 2017 at 10:54:19AM -0800, Linus Torvalds wrote:
> - library versioning.
>
>I don't know why, but I've never *ever* met a library developer who
> realized that libraries were all about stable API's, and the library
> users don't want to fight different versions.
Actually, you
On Wed, Dec 28, 2016 at 03:39:30AM -0500, Jeff King wrote:
> >
> > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=4473db1ef24031ff4e26c9a9de95dbe898ed2b97
> >
> > So this does seem like a gpg bug.
>
> I've submitted a bug report to gpg:
>
>
On Sun, Jul 17, 2016 at 03:42:34PM +, brian m. carlson wrote:
> As I said, I'm not planning on multiple hash support at first, but it
> doesn't appear impossible if we go this route. We might still have to
> rewrite objects, but we can verify signatures over the legacy SHA-1
> objects by
On Mon, Jul 11, 2016 at 01:06:17AM -0400, Jeff King wrote:
>
> The documentation claims that "raw-local" does not work. It
> does, but the end result is rather subtle. Let's describe it
> in better detail, and test to make sure it works (namely,
> the epoch time doesn't change, but the zone
On Mon, Jul 11, 2016 at 01:05:13AM -0400, Jeff King wrote:
> The "reflog selector" format changes based on a series of
> heuristics, and that applies equally to both stock "log -g"
> output, as well as "--format=%gd". The documentation for
> "%gd" doesn't cover this. Let's mention the multiple
On Mon, Jul 11, 2016 at 01:02:02AM -0400, Jeff King wrote:
> Yeah, I'd have hoped for %gd, as well. One thing I think we should move
> towards in the long run is giving more readable names to our
> placeholders for git-log, the way for-each-ref and cat-file do (but
> keeping the existing ones for
On Sun, Jul 10, 2016 at 06:05:31PM +0200, Duy Nguyen wrote:
> On Sun, Jul 10, 2016 at 4:26 PM, Theodore Ts'o <ty...@mit.edu> wrote:
> > One other long-term thought. Maybe past a certain point, we should
> > just make it easy to get the data from git-log into a perl or pyth
On Sun, Jul 10, 2016 at 02:16:45AM -0400, Jeff King wrote:
> I wonder if a better approach would be:
>
> 1. In the short term, add specific designators for the fields you'd
> want. One for HEAD@{n} that is unaffected by date, as %gd is (or
> even one for the branch-name and one for
e, instead of when HEAD was moved to that commit.
This allows something like:
git log -g --pretty=format:'%Cred%h%Creset %gd %gs %Cgreen(%gr)%Creset %s'
--abbrev-commit
to provide what (for me) is a much more useful "git reflog" type of
report.
Signed-off-by: Theodore Ts'o <ty...@mit.
GNU find no longers accepts -perm +111, even though the rest of the
world (MacOS, Solaris, BSD) still do. Workaround this problem by
using -executable if the system find utility will accept it.
Signed-off-by: Theodore Ts'o <ty...@mit.edu>
---
guilt | 13 +++--
1 file chang
HEAD@{14}: guilt-push: respect-nobarrier-mount-option-in-nojournal-mode
d08854f HEAD@{15}: guilt-pop: updating HEAD
d08854f HEAD@{16}: guilt-pop: updating HEAD
d08854f HEAD@{17}: guilt-push:
optimize-ext4_should_retry_alloc-to-improve-ENOSPC-performance
Signed-off-by: Theodore Ts'o <ty...@mit
On Fri, Jul 08, 2016 at 01:30:06PM -0700, Junio C Hamano wrote:
>
> I can imagine I'd start hacking on a project that I rarely touch, give up
> resolving a "git pull" from an unconfigured place (hence, some stuff is
> only reachable from FETCH_HEAD), and after 2*N days, come back
> to the
On Fri, Jul 08, 2016 at 10:14:33AM -0700, Junio C Hamano wrote:
>
> It cannot be "anything directly under .git that has all-caps name
> that ends with _HEAD". The ones we write we know are going to be
> removed at some point in time (e.g. "git reset", "git bisect reset",
> "git merge --abort",
On Thu, Apr 14, 2016 at 10:28:50AM -0700, H. Peter Anvin wrote:
>
> Either way, I agree with Ted, that we have enough time to do it
> right, but that is a good reason to do it sooner rather than later
> (see also my note about freezing the cryptographic properties.)
Sure, I think we should do it
On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote:
>
> If SHA-1 is broken (in certain ways), someone *can* replace an
> arbitrary blob. GPG does not help in this case, because the signature
> is over the commit object (which points to a tree, which eventually
> points to the blob),
On Sat, Dec 19, 2015 at 12:30:18PM -0500, Santiago Torres wrote:
> > Now, the crazy behavior where github users randomly and promiscuously
> > do pushes and pull without doing any kind of verification may very
> > well be dangerous.
>
> Yes, we were mostly familiar with this workflow before
someone can indepedently verify this after the fact:
% git show --oneline --show-signature f41683a204ea61568f0fd0804d47c19561f2ee39
f41683a merged tag 'ext4_for_linus_stable'
gpg: Signature made Sun 06 Dec 2015 10:35:27 PM EST using RSA key ID 950D81A3
gpg: Good signature from "Theodore Ts'o <ty...@mit.edu>"
I personally have in my .gitconfig:
[alias]
revert-file = checkout HEAD --
I'm not sure revert-file is the best name, but it's what I've used
because I've been contaminated by the concept/naming of "p4 revert",
which I do use a fair amount to undo local edits for one or more files
when
On Tue, Sep 22, 2015 at 04:11:23PM -0400, Josh Boyer wrote:
> Oh, context would help, yes. In the case of the tree I'm parsing, I
> know for a fact that the commit history is entirely linear and will
> (should) always remain so. E.g.
>
> A - B - C - D - E - F ... {N}
>
> So yes, finding e.g.
On Tue, Jun 23, 2015 at 10:32:08PM -0700, Junio C Hamano wrote:
Regarding loose object files, given that we write to a temporary,
optionally fsync, close and then move to the final name, would we
still see partially written file if we omit the fsync, or would the
corruption be limited to
The main issue is that non-expert users might not realize that they
really need to run git fsck after a crash; otherwise, what might
happen is that although git is only appending, that you might have
some zero-length (or partially written) git object or pack files, and
while you might not notice
On Mon, Jun 22, 2015 at 01:19:59PM +0200, Richard Weinberger wrote:
The bottome lins is that if you care about files being written, you
need to use fsync(). Should git use fsync() by default? Well, if you
are willing to accept that if your system crashes within a second or
so of your
On Sun, Jun 21, 2015 at 03:07:41PM +0200, Richard Weinberger wrote:
I was then shocked to learn that ext4 apparently has a default
setting that allows it to truncate files upon power failure
(something about a full journal vs a fast journal or some such)
s/ext4/all modern file systems/
On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
By allowing multiple authors, you don't have to decide who's the
primary author, as in such situations usually there is no primary at
all. I sometimes deliberately override the author when committing and
add myself just as another
On Mon, Sep 08, 2014 at 05:52:44PM +0400, Sergey Organov wrote:
I didn't intend to make topic branch from the very beginning, and
already made a commit or two on the remote tracking branch bofore I
realized I'd better use topic branch. It'd create no problem as far as I
can see, provided
On Mon, Sep 08, 2014 at 07:47:38PM +0400, Sergey Organov wrote:
except that I wanted to configure upstream as well for the topic-branch,
that looks like pretty legit desire. If I didn't, I'd need to specify
upstream explicitly in the git rebase, and I'd not notice the problem
at all, as the
I'm not going to say what you *should* have done, since it's not clear
whether anything close to what you were doing is a supported workflow.
But I can tell you what I *do* myself. Personally, I vastly distrust
git pull --rebase.
So in general, my pulls are all the equivalent of git pull
On Fri, Aug 15, 2014 at 03:46:29PM -0700, Junio C Hamano wrote:
The latest feature release Git v2.1.0 is now available at the
usual places.
I pulled down git v2.1.0, and when I tried to build it via:
make prefix=/usr/local profile-fast
The build died with this:
cannot open
On Wed, Jun 25, 2014 at 10:42:49AM -0700, Junio C Hamano wrote:
Nico Williams n...@cryptonector.com writes:
On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o ty...@mit.edu wrote:
...
This seems pretty close to what we have with signed tags. When I send
a pull request to Linus, I create
On Mon, Jun 23, 2014 at 10:20:14PM -0500, Nico Williams wrote:
Now, suppose that branches were objects. Then at push time one might
push with a message about the set of commits being pushed, and this
message (and time of push, and pusher ID) would get recorded in the
branch object. At
On Tue, May 13, 2014 at 10:30:36PM +0200, Per Cederqvist wrote:
I recently found myself sitting on a train with a computer in front of
me. I tried to use guilt import-commit, which seemed to work, but
when I tried to guilt push the commits I had just imported I got
some errors. It turned out
On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote:
I agree. The stage area is a very important concept in git, why not
talk git commands that refers to it? Then we could add flags like
--new-files or --deleted-files for better granularity than the current
--all flag.
One
On Fri, Apr 25, 2014 at 04:23:43PM +0200, Philippe Vaucher wrote:
I agree, but I think it's better than index tho. That one is heavily
overloaded and easily confused with other meaning in other softwares.
There is a big difference between being used in a difference sense
than other software
On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
There is evidence for the claim that there won't be those problems. You have
absolutely no evidence there there will.
Felipe,
It's clear that you've not been able to produce evidence that can
convince most of the people on
On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote:
I am not fundamentally opposed. I just do not think it would add
much value to new people at this point, and it will actively hurt
if we shoved barely cooked one in 2.0.
You are probably biased in that you've used Git far
On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote:
On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I have these aliases as well, except br = b, and cp = pi. 'br' is probably
better, but not sure as 'cp' which can be confusing.
If by
On Tue, Feb 25, 2014 at 11:12:10AM -0800, Junio C Hamano wrote:
So, I tend to agree with you, while I do understand where I want to
know about what is in stash is coming from (and that is why we do
have git stash list command).
One thing that would be nice is if there was built-in git stash
One of the uses of the Fixes commit line is so that when we fix a
security bug that has been in mainline for a while, it can be tricky
to determine whether it should be backported in to the various stable
branches. For example, let's suppose the security bug (or any bug,
but one of the contexts
On Fri, Oct 18, 2013 at 06:41:41AM -0500, Felipe Contreras wrote:
And I hazard to guess that the vast majority agree with Junio on this
(based,
again, on email evidence). Not with you.
That is irrelevant, and a fallacy. The vast majority of people thought the
Earth was the center of the
I certainly wouldn't recommend messing with the text of the DCO
without first consulting some lawyers. There should also be some
centralized coordination about any changes in the text and the version
number.
- Ted
--
To unsubscribe from this list:
On Tue, Jun 11, 2013 at 07:10:11PM +0530, Ramkumar Ramachandra wrote:
Presumably, Felipe is the fire hazard that we are talking about, and
nobody else is to blame. He must be removed to prevent future
fires. This is the perception of the regulars, correct?
Then why haven't you removed
On Tue, Jun 11, 2013 at 06:19:23PM -0500, Felipe Contreras wrote:
Fair? Fairness requires to judge each action without biases, nor
double standards. In the case of an open source community it requires
you to listen to the arguments before dismissing them, and consider
the patches before
On Thu, May 23, 2013 at 03:22:50PM +0530, Ramkumar Ramachandra wrote:
Theodore Ts'o wrote:
Right now I do this just by being careful, but if there was an
automatic safety mechanism, it would save me a bit of work, since
otherwise I might not catch my mistake until I do the git push
On Tue, May 21, 2013 at 11:39:21PM -0400, Josef 'Jeff' Sipek wrote:
I applied this one and the guilt: skip empty line after... patch.
Thanks! BTW, it looks like you are not using git am -s to apply
these patches? The reason why I ask is that whatever you're using
isn't removing the [XXX]
is a rewindable branch much like
git's pu branch.
Allow the use of the environment variable GUILT_FORCE_BARE_BRANCH
which disables the new behavior introduced by commit 67d3af63f422.
Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: Per Cederqvist ced...@opera.com
---
guilt | 17 +
1
I just had another idea (although I haven't had a chance to code up
anything yet). Perhaps instead of, or in addition to, a global
setting (i.e., guilt.reusebranch), perhaps we should have a per-branch
setting, such as branch.branch.guiltReuseBranch?
I was actually thinking that it might be
On Wed, May 22, 2013 at 10:58:49AM -0700, Junio C Hamano wrote:
Theodore Ts'o ty...@mit.edu writes:
I was actually thinking that it might be interesting to have a
branch.branch.rewindable, which would change the guilt defaults, and
could also key changes in key git behavior which makes
On Wed, May 22, 2013 at 11:55:00AM -0700, Junio C Hamano wrote:
But in a triangular workflow, the way to make the result reach the
upstream is *not* by pushing there yourself. For developers at
the leaf level, it is to push to their own repository (often on
GitHub), which is different from
The ext4 patch queue has used this format for years, and this change
should not break other patches which look like mail headers and
bodies.
Signed-off-by: Theodore Ts'o ty...@mit.edu
---
guilt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/guilt b/guilt
index 4edd1ad..309437a
is a rewindable branch much like
git's pu branch.
Allow the use of the environment variable GUILT_FORCE_BARE_BRANCH
which disables the new behavior introduced by commit 67d3af63f422.
Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: Per Cederqvist ced...@opera.com
---
guilt | 17 +
1
If the date field has a space in it, such as:
Date: Tue, 14 May 2013 18:37:15 +0200
previously guilt would go belly up:
+ export GIT_AUTHOR_DATE=Tue, 14 May 2013 18:37:15 +0200
/usr/local/bin/guilt: 571: export: 14: bad variable name
Fix this.
Signed-off-by: Theodore Ts'o ty
What if we added the ability to do something like this:
[remote origin]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/heads/master
mergeoptions = --ff-only
This would be an analog to branch.name.mergeoptions,
On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote:
Theodore Ts'o ty...@mit.edu writes:
[remote origin]
url =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/heads/master
mergeoptions = --ff-only
On Tue, Mar 05, 2013 at 02:05:32PM +1300, Gene Thomas [DATACOM] wrote:
The original branch is not 'destroyed', rather the pointer to the previous
tip is within the logs.
Is that the 'git log' log or internal logs? Are you sure? There doesn't
appear to be a way to checkout that tip of
On Tue, Jan 15, 2013 at 06:26:06PM -0800, Jonathan Nieder wrote:
Hi Jeff and other guilty parties,
I collected all the guilt patches I could find on-list and added one
of my own. Completely untested, except for running the regression
tests. These are also available via git protocol from
On Sat, Jan 05, 2013 at 12:27:12AM +0100, Johannes Schindelin wrote:
I was. John Hawley trusted me when I asked for admin privileges to keep
the spam at bay, but a very vocal voice on the mailing list tried to
discredit my work, and in the wake of the ensuing mailing list thread I
got the
On Wed, Dec 05, 2012 at 10:19:43AM +0100, Sebastian Schuberth wrote:
to say it in advance: I do not want to trigger any bogus security
discussion here. Instead, I believe the findings from [1] allow for
an up to 20% faster SHA1 calculation, if my brief reading of the
presentation is correct.
I seem to recall that there was at least some discussion at one point
about adding some extra fields to the commit object in a backwards
compatible way by adding it after the trailing NUL. We didn't end up
doing it, but I could see it being a useful thing nonetheless (for
example, we could
On Tue, Aug 07, 2012 at 01:33:23PM -0600, John 'Warthog9' Hawley wrote:
It's pretty simple: you sent HTML mail to vger.kernel.org, and it
explicitly rejects all HTML e-mail. GMail, particularly from Android,
apparently doesn't have a way to bypass sending HTML mail (it's been a
much maligned
On Fri, Apr 15, 2005 at 02:03:08PM +0200, Johannes Schindelin wrote:
I disagree. In order to be trusted, this thing has to catch the following
scenario:
Skywalker and Solo start from the same base. They commit quite a lot to
their trees. In between, Skywalker commits a tree, where the
78 matches
Mail list logo
