On Tue, Jul 02, 2019 at 11:52:35AM -0700, Bryan Turner wrote:
> Sorry, I should have clarified my "--no-track" in my original message
> when I provided the example. I did "--no-track" because if I push
> "bturner-some-bugfix" to a server, I'm likely going to do something
> like "git push -u origin
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 s
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 b
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, and
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 res
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 i
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 _particul
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 questi
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 store
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, i
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 th
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 t
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 capabi
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 magic
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 o
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 GP
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:
>
> https://bugs.gnupg.org/gnupg/issu
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 forci
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 does).
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 form
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 c
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 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 pythons
> >
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 "n"
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 T
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
---
guilt | 13 +++--
1 file changed, 11 insertions(
9625 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
Cc: Jose
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 reposito
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", et
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), and
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 start
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 " [ultimate]
gpg: aka
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 I'
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. th
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 o
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 anot
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, a
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
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
--ff-on
On Tue, Sep 02, 2014 at 07:21:17AM -0400, Theodore Ts'o wrote:
> On Tue, Sep 02, 2014 at 08:20:42AM +0100, Luca Milanesio wrote:
> > Hi Chris,
> > Seattle is a very inconvenient location for most of the people
> > coming from Europe: somewhere in the Bay area would be bet
On Tue, Sep 02, 2014 at 08:20:42AM +0100, Luca Milanesio wrote:
> Hi Chris,
> Seattle is a very inconvenient location for most of the people
> coming from Europe: somewhere in the Bay area would be better and
> less expensive for us.
Well, the fact that Seattle is inconvnient might not matter that
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 test-results/p
On Wed, Jun 25, 2014 at 10:42:49AM -0700, Junio C Hamano wrote:
> Nico Williams writes:
>
> > On Tue, Jun 24, 2014 at 6:09 AM, Theodore Ts'o wrote:
> > ...
> >> This seems pretty close to what we have with signed tags. When I send
> >> a pull requ
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 tur
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 softwa
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.
On
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 t
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 G
On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote:
> On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras
> 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 confusing you re
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 s
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 wh
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 cente
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: s
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 dro
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
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 mistak
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 fr
On Wed, May 22, 2013 at 10:58:49AM -0700, Junio C Hamano wrote:
> Theodore Ts'o writes:
>
> > I was actually thinking that it might be interesting to have a
> > branch..rewindable, which would change the guilt defaults, and
> > could also key changes in key git
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..guiltReuseBranch?
I was actually thinking that it might be interesting
e able to
push patches to the dev branch, which 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"
Cc:
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] s
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
e able to
push patches to the dev branch, which 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"
Cc:
; This is the patch description
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"
---
guilt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, Mar 12, 2013 at 02:30:04PM -0700, Junio C Hamano wrote:
> Theodore Ts'o writes:
>
> > [remote "origin"]
> > url =
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > fetch = +refs/heads/master:refs/
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..mergeoptions, but
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 ti
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 fro
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 th
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 corr
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 potenti
On Tue, Aug 07, 2012 at 05:25:02PM -0400, Eugene Sajine wrote:
>
> Don't want to accept HTML messages - fine. But don't tell me which
> program to use for my email, especially when I'm sending totally valid
> message, so take my plain text message part and use it.
>
The problem is that HTML mess
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 malign
On Sun, Apr 17, 2005 at 12:38:37AM -0400, David A. Wheeler wrote:
> The probability of an accidental overlap for SHA-1 for two
> different files is absurdly remote; it's just not worth worrying about.
>
> However, the possibility of an INTENTIONAL overlap is a completely
> different matter. I thi
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 fu
83 matches
Mail list logo
