Re: Proposal

Hello, Compliment of the day to you. I am Mrs. Elodie, I am sending this brief letter to solicit your partnership to transfer $5.5 million US Dollars into your account for investment in your country. I shall send you more information and procedures when I receive positive response from you.

Re: proposal for how to share other refs as part of refs/tracking/*

On Tue, Jun 13, 2017 at 8:55 AM, Marc Branchaud wrote: > On 2017-06-13 10:41 AM, Marc Branchaud wrote: >> >> >> So I like your refs/tracking proposal, and hope that it aims for mirroring >> a remote's refs, to eventually replace refs/remotes entirely. > > > To be

Re: proposal for how to share other refs as part of refs/tracking/*

On 2017-06-13 10:41 AM, Marc Branchaud wrote: So I like your refs/tracking proposal, and hope that it aims for mirroring a remote's refs, to eventually replace refs/remotes entirely. To be extra-clear: I think a refs/tracking hierarchy that starts with notes and maybe some other bits is a

Re: proposal for how to share other refs as part of refs/tracking/*

On 2017-06-12 06:58 PM, Jacob Keller wrote: Hi, There's no actual code yet, (forgive me), but I've been thinking back to a while ago about attempting to find a way to share things like refs/notes, and similar refs which are usually not shared across a remote. By default, those refs are not

Re: Proposal for missing blob support in Git repos

On 05/03/2017 09:29 PM, Junio C Hamano wrote: Jonathan Tan writes: I see the semantics as "don't write what you already have", where "have" means what you have in local storage, but if you extend "have" to what upstream has, then yes, you're right that this changes

Re: Proposal for missing blob support in Git repos

Jonathan Tan writes: > I see the semantics as "don't write what you already have", where > "have" means what you have in local storage, but if you extend "have" > to what upstream has, then yes, you're right that this changes > (ignoring shallow clones). > > This does

Re: Proposal for missing blob support in Git repos

On 05/02/2017 11:32 AM, Ævar Arnfjörð Bjarmason wrote: On Tue, May 2, 2017 at 7:21 PM, Jonathan Tan wrote: On Mon, May 1, 2017 at 6:41 PM, Junio C Hamano wrote: Jonathan Tan writes: On 05/01/2017 04:29 PM, Junio C

Re: Proposal for missing blob support in Git repos

On Tue, May 2, 2017 at 7:21 PM, Jonathan Tan wrote: > On Mon, May 1, 2017 at 6:41 PM, Junio C Hamano wrote: >> Jonathan Tan writes: >> >>> On 05/01/2017 04:29 PM, Junio C Hamano wrote: Jonathan Tan

Re: Proposal for missing blob support in Git repos

Jonathan Tan writes: > On 05/01/2017 04:29 PM, Junio C Hamano wrote: >> Jonathan Tan writes: >> >>> Thanks for your comments. If you're referring to the codepath >>> involving write_sha1_file() (for example, builtin/hash-object -> >>> index_fd

Re: Proposal for missing blob support in Git repos

On 05/01, Jonathan Tan wrote: > On 05/01/2017 04:29 PM, Junio C Hamano wrote: > >Jonathan Tan writes: > > > >>Thanks for your comments. If you're referring to the codepath > >>involving write_sha1_file() (for example, builtin/hash-object -> > >>index_fd or

Re: Proposal for missing blob support in Git repos

On 05/01/2017 04:29 PM, Junio C Hamano wrote: Jonathan Tan writes: Thanks for your comments. If you're referring to the codepath involving write_sha1_file() (for example, builtin/hash-object -> index_fd or builtin/unpack-objects), that is fine because

Re: Proposal for missing blob support in Git repos

Jonathan Tan writes: > Thanks for your comments. If you're referring to the codepath > involving write_sha1_file() (for example, builtin/hash-object -> > index_fd or builtin/unpack-objects), that is fine because > write_sha1_file() invokes freshen_packed_object() and >

Re: Proposal for missing blob support in Git repos

On 04/30/2017 08:57 PM, Junio C Hamano wrote: One thing I wonder is what the performance impact of a change like this to the codepath that wants to see if an object does _not_ exist in the repository. When creating a new object by hashing raw data, we see if an object with the same name already

Re: Proposal for missing blob support in Git repos

Jonathan Tan writes: > In order to determine the code changes in sha1_file.c necessary, I > investigated the following: > (1) functions in sha1_file that take in a hash, without the user > regarding how the object is stored (loose or packed) > (2) functions in

Re: Proposal for "fetch-any-blob Git protocol" and server design

On 04/21/2017 09:41 AM, Kevin David wrote: Hi Jonathan, Sorry for the delayed response - other work got in the way, unfortunately! No worries! I am envisioning (1a) as described in Jeff Hostetler's e-mail [1] ("a pre-command or hook to identify needed blobs and pre-fetch them before

RE: Proposal for "fetch-any-blob Git protocol" and server design

Hi Jonathan, Sorry for the delayed response - other work got in the way, unfortunately! Kevin -Original Message- From: Jonathan Tan [mailto:jonathanta...@google.com] Sent: Thursday, April 13, 2017 4:13 PM >> I know we're considering server behavior here, but how large do you generally

Re: Proposal for "fetch-any-blob Git protocol" and server design

On 04/12/2017 03:02 PM, Kevin David wrote: Hi Jonathan, I work on the network protocols for the GVFS project at Microsoft. I shared a couple thoughts and questions below. Thanks for your reply! I know we're considering server behavior here, but how large do you generally expect these

RE: Proposal for "fetch-any-blob Git protocol" and server design

nta...@google.com>; Ben Peart <peart...@gmail.com> Cc: git@vger.kernel.org; Mark Thomas <mar...@efaref.net>; Jeff Hostetler <g...@jeffhostetler.com> Subject: Re: Proposal for "fetch-any-blob Git protocol" and server design +cc Ben Peart, who sent "[RFC] Add support for d

Re: Proposal for "fetch-any-blob Git protocol" and server design

+cc Ben Peart, who sent "[RFC] Add support for downloading blobs on demand" to the list recently. This proposal here seems like it has the same goal, so maybe your review could go a long way here? Thanks, Stefan On Tue, Mar 14, 2017 at 3:57 PM, Jonathan Tan wrote: > As

Re: Proposal for "fetch-any-blob Git protocol" and server design

On 03/16/2017 02:17 PM, Junio C Hamano wrote: Yeah, the example was solely to see how the system was to be extended, as one of the selling point of the proposal was: > === Endpoint support for forward compatibility > > This "server" endpoint requires that the first line be

Re: Proposal for "fetch-any-blob Git protocol" and server design

Jonathan Tan writes: > On 03/15/2017 10:59 AM, Junio C Hamano wrote: >> ... >> but I am wondering how you would extend the proposed system to do >> so. Would you add "fetch-size-limited-blob-in-tree-pack" that runs >> parallel to "fetch-blob-pack" request? Would you

Re: Proposal for "fetch-any-blob Git protocol" and server design

On 03/15/2017 10:59 AM, Junio C Hamano wrote: By "SHA-1s for which it wants blobs", you mean that "want" only allows one exact blob object name? I think it is necessary to support that mode of operation as a base case, and it is a good starting point. When you know - you have a "partial"

Re: Proposal for "fetch-any-blob Git protocol" and server design

Jonathan Tan writes: > == Design > > A new endpoint "server" is created. The client will send a message in > the following format: > > > fbp-request = PKT-LINE("fetch-blob-pack") > 1*want > flush-pkt > want = PKT-LINE("want" SP obj-id) >

Re: Proposal for an increased `gitk` cohesion with `git stash`.

Dearest all, am sorry my previous message did not enter the list (cross my fingers this will). I won't be pasting it verbatim because shame on me it leaked zombie processes (but that part got silently dropped out by kind Paul). In case anyone could be interested in the topic, and because a

Re: Proposal for an increased `gitk` cohesion with `git stash`.

Hi Uxio, On Thu, Sep 08, 2016 at 03:41:29PM +0200, Uxío Prego wrote: > Hello, please forgive me for not introducing me. > > +---+ > |Description| > +---+ > > Patch for showing all stashes in `gitk`. > > +---+ > |The problem| > +---+ > > Being `gitk` one of the

Re: proposal: allow git clone for http-hosted bundles

Jeff King writes: > You might do better to stick a shim script in your $PATH to just > intercept the calls to git. Hacky, but it would probably solve your > problem with a minimal amount of code. I recently learned about http://repo.or.cz/git.git/bundles which is a very nicely

Re: proposal: allow git clone for http-hosted bundles

Ho mappu, On Sun, 17 Jul 2016, mappu wrote: > Right now it's possible to git clone a repository over http, and git > clone a bundle from the local filesystem, but it's not possible to git > clone a bundle hosted on http. > > Would it be possible to allow this in the future? Hopefully it's only

Re: proposal: allow git clone for http-hosted bundles

On Sun, Jul 17, 2016 at 04:41:54PM +1200, mappu wrote: > Right now it's possible to git clone a repository over http, and git clone a > bundle from the local filesystem, but it's not possible to git clone a > bundle hosted on http. > > Would it be possible to allow this in the future? Hopefully

Re: proposal for extending smudge/clean filters with raw file access

Junio C Hamano wrote: > > Secondly, and harder to get around, the filename passed to the clean > > filter is not necessarily a path to the actual existing file that is > > being cleaned. > > Either one of us is confused. I was talking about updating the > current "clean" implementation without

Re: proposal for extending smudge/clean filters with raw file access

Junio C Hamano wrote: > The smudge happens to be the last to run, so it is quite true that > it can say "Hey Git, I've written it out already". > > I didn't check all codepaths to ensure that we won't need the > smudged result in core at all, but I am guessing you did so before > making this

Re: proposal for extending smudge/clean filters with raw file access

Joey Hess writes: > Junio C Hamano wrote: >> This side, I do not think we even need a new variant. We can just >> update the code to interact with "clean" so that it the writer to >> the pipe ignores SIGPIPE, detects EPIPE on write(2), says "ah, the >> other end does not need

Re: proposal for extending smudge/clean filters with raw file access

Junio C Hamano wrote: > This side, I do not think we even need a new variant. We can just > update the code to interact with "clean" so that it the writer to > the pipe ignores SIGPIPE, detects EPIPE on write(2), says "ah, the > other end does not need the full input to produce its output". The

Re: proposal for extending smudge/clean filters with raw file access

Joey Hess writes: > The clean filter has to consume the whole file content on stdin; > not reading it all will make git think the clean filter failed. > But, git-annex often doesn't need to read the whole content of a > work-tree file in order to clean it. This side, I do not

Re: proposal for extending smudge/clean filters with raw file access

Joey Hess writes: > I'm using smudge/clean filters in git-annex now, and it's not been an > entirely smooth fit between the interface and what git-annex wants > to do. > > The clean filter has to consume the whole file content on stdin; > not reading it all will make git think

Re: Proposal for git stash : add --staged option

Hi again, just wanted to tell that I have created a solution by doing a few lines of scripting: git-cstash ``` #/bin/sh git commit -m 'temporary, will be stashed soon' git stash --include-untracked git reset HEAD^1 git stash git stash pop stash@{1} ``` Le 2015-04-22 11:25, Johannes

Re: Proposal for git stash : add --staged option

Hi, the ```sh git add config_real.xml git stash -k git reset ``` is not very well suited because the -k option to keep the index. However, the index will still be put inside the stash. So what you propose is equivalent to: ```sh git stash git stash apply stash@\{0\} git checkout

Re: Proposal for git stash : add --staged option

Hi Edgar, On 2015-04-22 10:30, edgar.h...@netapsys.fr wrote: When you have a lot of unstaged files, and would like to test what happens if you undo some of the changes that you think are unecessary, you would rather keep a copy of those changes somewhere. For example Changed but not

Re: Proposal for pruning tags

On 06/05/2014 04:51 PM, Robert Dailey wrote: I've never contributed to the Git project before. I'm a Windows user, so I use msysgit, but I'd be happy to install linux just so I can help implement this feature if everyone feels it would be useful. Right now AFAIK, there is no way to prune

Re: Proposal for pruning tags

On Thu, Jun 5, 2014 at 3:50 PM, Junio C Hamano gits...@pobox.com wrote: I think you need to explain what you mean by prune a lot better than what you are doing in your message to be understood by others. After seeing the above two commands, my *guess* of what you want to do is to remove any

Re: Proposal for pruning tags

Robert Dailey rcdailey.li...@gmail.com writes: ... Having git clean up tags automatically would really help with this, even though you may not feel it's the responsibility of Git. It's more of a usability issue, I agree with Having ... help with this. I did not say at all that it is not

Re: Proposal for pruning tags

Robert Dailey rcdailey.li...@gmail.com writes: I've never contributed to the Git project before. I'm a Windows user, so I use msysgit, but I'd be happy to install linux just so I can help implement this feature if everyone feels it would be useful. Right now AFAIK, there is no way to prune

Re: Proposal: Write git subtree info to .git/config

John Butterfield johnb...@gmail.com writes: Has there been any talk about adding a stub for git subtrees in .git/config? I do not think so, and that is probably for a good reason. A subtree biding can change over time, but .git/config is about recording information that do not change depending

Re: Proposal: Write git subtree info to .git/config

A subtree biding can change over time, but .git/config is about recording information that do not change depending on what tree you are looking at, so there is an impedance mismatch---storing that information in .git/config is probably a wrong way to go about it. I see. How about a .gitsubtrees

Re: Proposal: Write git subtree info to .git/config

by per folder I meant, for each subtree On Thu, Mar 13, 2014 at 5:43 PM, John Butterfield johnb...@gmail.com wrote: A subtree biding can change over time, but .git/config is about recording information that do not change depending on what tree you are looking at, so there is an impedance

Re: [Proposal] Clonable scripts

Hi, On Tue, Sep 10, 2013 at 12:18 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Niels Basjes wrote: As we all know the hooks ( in .git/hooks ) are not cloned along with the code of a project. Now this is a correct approach for the scripts that do stuff like emailing the people

Re: [Proposal] Clonable scripts

On 09/10/2013 02:18 AM, Niels Basjes wrote: As we all know the hooks ( in .git/hooks ) are not cloned along with the code of a project. Now this is a correct approach for the scripts that do stuff like emailing the people responsible for releases or submitting the commit to a CI system.

Re: [Proposal] Clonable scripts

On Mon, 09 Sep 2013 22:48:42 +, Niels Basjes wrote: ... However I can imagine that a malicious opensource coder can create a github repo and try to hack the computer of a contributer via those scripts. So having such scripts is a 'bad idea'. Given that half the repos out there are cloned

Re: [Proposal] Clonable scripts

On 9 September 2013 13:48, Niels Basjes ni...@basjes.nl wrote: If those scripts were how ever written in a language that is build into the git program and the script are run in such a way that they can only interact with the files in the local git (and _nothing_ outside of that) this would be

Re: [Proposal] Clonable scripts

On Mon, Sep 9, 2013 at 11:13 PM, Hilco Wijbenga hilco.wijbe...@gmail.com wrote: On 9 September 2013 13:48, Niels Basjes ni...@basjes.nl wrote: So I propose the following new feature: 1) A scripting language is put inside git. Perhaps a version of python or ruby or go or ... (no need for a

Re: [Proposal] Clonable scripts

Niels Basjes wrote: As we all know the hooks ( in .git/hooks ) are not cloned along with the code of a project. Now this is a correct approach for the scripts that do stuff like emailing the people responsible for releases or submitting the commit to a CI system. More often than not,

Re: Proposal: sharing .git/config

Jeff King wrote: I don't think you can avoid the 3-step problem and retain the safety in the general case. Forgetting implementation details for a minute, you have either a 1-step system: 1. Fetch and start using config from the remote. which is subject to fetching and executing

Re: Proposal: sharing .git/config

On Mon, Mar 18, 2013 at 02:30:23PM +0530, Ramkumar Ramachandra wrote: Jeff King wrote: I don't think you can avoid the 3-step problem and retain the safety in the general case. Forgetting implementation details for a minute, you have either a 1-step system: 1. Fetch and start using

Re: Proposal: sharing .git/config

On Tue, Mar 12, 2013 at 01:01:08AM +0530, Ramkumar Ramachandra wrote: But it was pointed out that you could also just do: $ git config include.ref upstream-config $ git show origin/config ;# make sure it looks reasonable $ git show origin/config .git/upstream-config and so

Re: Proposal: sharing .git/config

Jeff King wrote: On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote: On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify

Re: Proposal: sharing .git/config

Ramkumar Ramachandra artag...@gmail.com writes: I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. Note that you need to carefully pick only

Re: Proposal: sharing .git/config

Thomas Rast wrote: Ramkumar Ramachandra artag...@gmail.com writes: I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. Note that you need to

Re: Proposal: sharing .git/config

On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. There are

Re: Proposal: sharing .git/config

Ramkumar Ramachandra artag...@gmail.com writes: Thomas Rast wrote: Ramkumar Ramachandra artag...@gmail.com writes: There are also other things in .git/config that would be nice to share, like whether to do a --word-diff (why isn't it a configuration variable yet?) Because that would break

Re: Proposal: sharing .git/config

On Tue, Feb 19, 2013 at 9:25 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream sources are, so remotes get set up automatically when I clone. There are

Re: Proposal: sharing .git/config

On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote: On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Hi, I have this itch where I want to share my remotes config between machines. In my fork, I should be able to specify where my upstream

Re: Proposal: branch.name.remotepush

Jonathan Nieder jrnie...@gmail.com writes: Wait, why did the remote rewind? Oh, I am very well aware of that glitch. git push has this hack to pretend as if the pusher immediately turned around and fetched from the remote. It shouldn't have been made to do so unconditionally; instead it

Re: Proposal: branch.name.remotepush

On Thu, Feb 07, 2013 at 10:45:07PM -0800, Junio C Hamano wrote: To support a triangular arrangement well, there may need some thinking on what $branch@{upstream} means. The original intent of the upstream mode specified for push.default is push the result back to what you based your work on,

Re: Proposal: branch.name.remotepush

Junio C Hamano venit, vidit, dixit 08.02.2013 09:16: Jonathan Nieder jrnie...@gmail.com writes: Wait, why did the remote rewind? Oh, I am very well aware of that glitch. git push has this hack to pretend as if the pusher immediately turned around and fetched from the remote. It

Re: Proposal: branch.name.remotepush

Michael J Gruber g...@drmicha.warpmail.net writes: As for the triangle remote, I really think we should clean up the situation regarding push, pushurlinsteadof and the various different and inconclusive output formats of git remote (with or without -v, with or without a remote name) first,

Re: Proposal: branch.name.remotepush

Michael J Gruber g...@drmicha.warpmail.net writes: Junio C Hamano venit, vidit, dixit 08.02.2013 09:16: Jonathan Nieder jrnie...@gmail.com writes: Wait, why did the remote rewind? Oh, I am very well aware of that glitch. git push has this hack to pretend as if the pusher immediately

Re: Proposal: branch.name.remotepush

Junio C Hamano wrote: Jeff King p...@peff.net writes: We have the problem now that new users do not necessarily understand the matching strategy, or why it is useful, and get confused. When we move to simple, we may be switching to a world where the early part of the learning curve is more

Re: Proposal: branch.name.remotepush

Junio C Hamano wrote: [remote origin] url = ... where Ram fetches and pulls from ... pushurl = ... where Ram pushes to ... fetch = refs/heads/*:refs/remotes/* updateTrackOnPush = no Then git fetch (or git pull) will

Re: Proposal: branch.name.remotepush

Michael J Gruber wrote: Junio C Hamano venit, vidit, dixit 08.02.2013 09:16: Jonathan Nieder jrnie...@gmail.com writes: Wait, why did the remote rewind? Oh, I am very well aware of that glitch. git push has this hack to pretend as if the pusher immediately turned around and fetched from

Re: Proposal: branch.name.remotepush

Jonathan Nieder wrote: Ramkumar Ramachandra wrote: And yes, a regular `git push origin refs/for/master` is just retarded. The usual incantation is git push gerrit HEAD:refs/for/master. Is the code review creation push that uses a different branchname from the branch the integrator pulls

Re: Proposal: branch.name.remotepush

Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: [remote origin] url = ... where Ram fetches and pulls from ... pushurl = ... where Ram pushes to ... fetch = refs/heads/*:refs/remotes/*

Re: Proposal: branch.name.remotepush

On 02/07/2013 05:14 PM, Ramkumar Ramachandra wrote: This has been annoying me for a really long time, but I never really got around to scratching this particular itch. I have a very common scenario where I fork a project on GitHub. I have two configured remotes: origin which points to

Re: Proposal: branch.name.remotepush

Ramkumar Ramachandra wrote: Ramkumar Ramachandra wrote: And yes, a regular `git push origin refs/for/master` is just retarded. Actually a git config remote.origin.push refs/heads/*:refs/for/* makes more sense here. Sorry about all that confusion. The first line should be `git push origin

Re: Proposal: branch.name.remotepush

Hi Ram, Ramkumar Ramachandra wrote: And yes, a regular `git push origin refs/for/master` is just retarded. The usual incantation is git push gerrit HEAD:refs/for/master. Is the code review creation push that uses a different branchname from the branch the integrator pulls what seems backward,

Re: Proposal: branch.name.remotepush

Jonathan Nieder jrnie...@gmail.com writes: The usual incantation is git push gerrit HEAD:refs/for/master. Is the code review creation push that uses a different branchname from the branch the integrator pulls what seems backward, or is it the need to specify a refname at all on the command

Re: Proposal: branch.name.remotepush

On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote: This has been annoying me for a really long time, but I never really got around to scratching this particular itch. I have a very common scenario where I fork a project on GitHub. I have two configured remotes: origin

Re: Proposal: branch.name.remotepush

Jeff King p...@peff.net writes: On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote: This has been annoying me for a really long time, but I never really got around to scratching this particular itch. I have a very common scenario where I fork a project on GitHub. I have

Re: Proposal: branch.name.remotepush

On Thu, Feb 07, 2013 at 10:08:48PM -0800, Junio C Hamano wrote: How best to express the triangle is somewhat tricky, but I think it is sensible to say you have origin that points to your upstream (i.e. me), and peff that points to your publishing point, in other words, make it explicit that

Re: Proposal: branch.name.remotepush

Junio C Hamano gits...@pobox.com writes: I think the triangle arrangement where you want to have this is where I fetch from and integrate with, and that is where I publish is more common among the Git users these days. Another thing to know about is that the recent move to change the

Re: Proposal: branch.name.remotepush

Junio C Hamano wrote: I'd actually see this as Gerrit being weird. If it wants to quarantine a commit destined to the master branch, couldn't it just let people push to master and then internally update for/master instead? It is because pushing doesn't update refs/heads/master. Instead, it

Re: Proposal for git stash rename

On 01/04/2013 10:40 PM, Junio C Hamano wrote: Micheil Smith mich...@brandedcode.com writes: This patch implements a git stash rename using a new git reflog update command that updates the message associated with a reflog entry. ... I note that this proposal is now two years old. A work in

Re: Proposal for git stash rename

Greg Hewgill greg at hewgill.com writes: On Sun, Jun 20, 2010 at 10:54:43AM +, ??var Arnfj??r?? Bjarmason wrote: It's good to post a WIP PATCH even if it needs cleanup, just as a point for further discussion. Thanks, point taken. WIP patch follows. This patch implements a git

Re: Proposal for git stash rename

Micheil Smith mich...@brandedcode.com writes: This patch implements a git stash rename using a new git reflog update command that updates the message associated with a reflog entry. ... I note that this proposal is now two years old. A work in progress patch was requested, however, after

Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed

Martin von Zweigbergk martinv...@gmail.com writes: On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote: I am guilty of introducing git reset --soft HEAD^ before I invented commit --amend during v1.3.0 timeframe to solve the issue soft reset originally wanted to. I do

Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed

On Mon, Dec 17, 2012 at 10:34:07PM -0800, Martin von Zweigbergk wrote: On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote: I am guilty of introducing git reset --soft HEAD^ before I invented commit --amend during v1.3.0 timeframe to solve the issue soft reset

Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed

On Wed, Nov 23, 2011 at 12:49 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Philippe Vaucher philippe.vauc...@gmail.com writes: Optional: a new mode would be introduced for consistency: --worktree (or maybe --tree): only updates the worktree but not the index That would be an alias

Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed

On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote: I am guilty of introducing git reset --soft HEAD^ before I invented commit --amend during v1.3.0 timeframe to solve the issue soft reset originally wanted to. I do use commit --amend a lot, but I still appreciate having

Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed

On Wednesday 2012-10-03 21:03, Junio C Hamano wrote: I said that git reset --keep started out as an ugly workaround for the lack of git checkout -B $current_branch. Now we have it, so we can afford to make reset --keep less prominently advertised in our tool set. As I already said back then,

Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed

Phil Hord phil.h...@gmail.com writes: I flagged this for followup in my MUA, but I failed to follow-up after the holidays. I apologize for that, and I really regret it because I liked where this was going. I really regret to see you remembered it, actually. 1) Newbie user clones/pulls a

Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed

Junio C Hamano gits...@pobox.com writes: Phil Hord phil.h...@gmail.com writes: I flagged this for followup in my MUA, but I failed to follow-up after the holidays. I apologize for that, and I really regret it because I liked where this was going. I really regret to see you remembered it,

Re: proposal: delta based git archival

On 4/22/05, Michel Lespinasse [EMAIL PROTECTED] wrote: I noticed people on this mailing list start talking about using blob deltas for compression, and the basic issue that the resulting files are too small for efficient filesystem storage. I thought about this a little and decided I should