Junio C Hamano wrote:
> On Tue, Apr 11, 2017 at 8:33 AM, Jacob Keller wrote:
> >
> > If you're already copying sha1s around you could use those as the
> > --force-with-lease=branch:, no?
> >
> > That's better guarantee than just using --force-with-lease alone.
>
> Absolutely. That was the _only
Jeff King wrote:
> On Tue, Apr 11, 2017 at 02:37:27PM +0200, Stefan Haller wrote:
>
> > Are you talking about the case where the user doesn't say git pull, but
> > instead says "git fetch && git merge --ff @{u}"? Just so that I
> > understand the concern.
>
> Yes, that (which is the main way th
Stefan Haller wrote:
> Then, every command that either integrates the remote tracking branch
> into the local branch, or updates the remote tracking branch to the
> local branch, will update the value of the "lease" entry. The most
> obvious ones are "git pull" and "git push", or course;
I thoug
On Tue, Apr 11, 2017 at 02:37:27PM +0200, Stefan Haller wrote:
> > I agree that probably makes the multiple-operation stuff go away, which
> > is nice. It does raise the question of when the integration point
> > happens, and how we handle alternate paths through which commits may
> > land in a lo
Ævar Arnfjör? Bjarmason wrote:
> Does this proposal require that all the things that can update a ref
> be hooked to maintain these lease values?
It is true that the proposal relies on people using git push and git
pull, not some lower level approximation such as git fetch + git
update-ref. Whet
Jeff King wrote:
> On Sun, Apr 09, 2017 at 10:38:42AM +0200, Stefan Haller wrote:
>
> > I think it's wrong to think about these leases as something that you
> > take before you start a rewindy operation. That's the wrong time to take
> > the lease; by that time, the remote tracking branch may al
Jacob Keller wrote:
> On Sun, Apr 9, 2017 at 4:00 AM, Stefan Haller wrote:
>
> > Maybe I wasn't clear enough about that in my proposal, but I propose to
> > always store the commit hash of the remote tracking branch as a new
> > lease after push and pull, not the local branch. This way it works
On Tue, Apr 11, 2017 at 8:33 AM, Jacob Keller wrote:
>
> If you're already copying sha1s around you could use those as the
> --force-with-lease=branch:, no?
>
> That's better guarantee than just using --force-with-lease alone.
Absolutely. That was the _only_ way the feature was originally designe
On Mon, Apr 10, 2017 at 2:58 AM, Ævar Arnfjörð Bjarmason
wrote:
> On Mon, Apr 10, 2017 at 10:08 AM, Jacob Keller wrote:
>> On Sun, Apr 9, 2017 at 4:00 AM, Stefan Haller wrote:
>>> Jacob Keller wrote:
>>>
Agreed. You "take" a lease whenever you push to the remote or when you
pull from
On Sun, Apr 09, 2017 at 10:38:42AM +0200, Stefan Haller wrote:
> Jeff King wrote:
>
> > > It might be possible to generate these lease tags prior to operations
> > > which modify history and then maybe having a way to list them so you
> > > can select which one you meant when you try to use forc
On Mon, Apr 10, 2017 at 10:08 AM, Jacob Keller wrote:
> On Sun, Apr 9, 2017 at 4:00 AM, Stefan Haller wrote:
>> Jacob Keller wrote:
>>
>>> Agreed. You "take" a lease whenever you push to the remote or when you
>>> pull from the remote and when you pull into the branch. It should
>>> store someth
On Sun, Apr 9, 2017 at 4:00 AM, Stefan Haller wrote:
> Jacob Keller wrote:
>
>> Agreed. You "take" a lease whenever you push to the remote or when you
>> pull from the remote and when you pull into the branch. It should
>> store something that tracks both the branch and remote branch together
>>
Jacob Keller wrote:
> Agreed. You "take" a lease whenever you push to the remote or when you
> pull from the remote and when you pull into the branch. It should
> store something that tracks both the branch and remote branch together
> so that you can generalize it to multiple remotes.
I don't s
Jeff King wrote:
> > It might be possible to generate these lease tags prior to operations
> > which modify history and then maybe having a way to list them so you
> > can select which one you meant when you try to use force-with-lease..
>
> So yeah, I think that is the more interesting directio
On Sun, Apr 9, 2017 at 1:38 AM, Stefan Haller wrote:
> Jeff King wrote:
>
>> > It might be possible to generate these lease tags prior to operations
>> > which modify history and then maybe having a way to list them so you
>> > can select which one you meant when you try to use force-with-lease..
On Sun, Apr 9, 2017 at 1:38 AM, Stefan Haller wrote:
> Jacob Keller wrote:
>
>> What if we added a separate command something like:
>>
>> git create-lease
>>
>> which you're expected to run at the start of a rewind-y operation and
>> it creates a tag (or some other ref like a tag but in a differe
Jacob Keller wrote:
> What if we added a separate command something like:
>
> git create-lease
>
> which you're expected to run at the start of a rewind-y operation and
> it creates a tag (or some other ref like a tag but in a different
> namespace) which is used by force-with-lease?
The probl
On Sat, Apr 8, 2017 at 3:13 PM, Jeff King wrote:
> On Sat, Apr 08, 2017 at 02:54:29PM -0700, Jacob Keller wrote:
>
>> > So the best way to use it is something like:
>> >
>> > git fetch ;# update 'master' from remote
>> > git tag base master;# mark our base point
>> > git reb
On Sat, Apr 08, 2017 at 02:54:29PM -0700, Jacob Keller wrote:
> > So the best way to use it is something like:
> >
> > git fetch ;# update 'master' from remote
> > git tag base master;# mark our base point
> > git rebase -i master ;# rewrite some commits
> > git push --f
On Sat, Apr 08, 2017 at 05:03:06PM +0200, Stefan Haller wrote:
> Jeff King wrote:
>
> > I think Matt's point is just that the default, to use origin/branch, is
> > unsafe. It's convenient when you don't have extra fetches, but that
> > convenience may not be worth the potential surprise.
>
> I
On Sat, Apr 8, 2017 at 2:29 AM, Jeff King wrote:
> On Sat, Apr 08, 2017 at 09:35:04AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> Is it correct that you'd essentially want something that works like:
>>
>> git push --force-with-lease=master:master origin master:master
>
> I don't think that woul
Ævar Arnfjör? Bjarmason wrote:
> On Sat, Apr 8, 2017 at 5:03 PM, Stefan Haller wrote:
>
> > Here's a rough proposal for how I would imagine this to work.
> >
> > For every local branch that has a remote tracking branch, git maintains
> > a new config entry branch.*.integrated, which records the
On Sat, Apr 8, 2017 at 5:03 PM, Stefan Haller wrote:
> Matt McCutchen wrote:
>
>> When I'm rewriting history, "git push --force-with-lease" is a nice
>> safeguard compared to "git push --force", but it still assumes the
>> remote-tracking ref gives the old state the user wants to overwrite.
>> To
Jeff King wrote:
> I think Matt's point is just that the default, to use origin/branch, is
> unsafe. It's convenient when you don't have extra fetches, but that
> convenience may not be worth the potential surprise.
I don't think "surprise" is the right word here. The point of
--force-with-lease
Matt McCutchen wrote:
> When I'm rewriting history, "git push --force-with-lease" is a nice
> safeguard compared to "git push --force", but it still assumes the
> remote-tracking ref gives the old state the user wants to overwrite.
> Tools that do an implicit fetch, assuming it to be a safe oper
W dniu 08.04.2017 o 11:29, Jeff King pisze:
[...]
> Perhaps it would be enough to reset the markers whenever the ref is
> pushed. I haven't thought it through well enough to know whether that
> just hits more corner cases.
I wonder if using a separate remote for pushing (with separate remote-
-tr
On Sat, Apr 08, 2017 at 01:25:43AM -0700, Jacob Keller wrote:
> On Fri, Apr 7, 2017 at 7:15 PM, Matt McCutchen wrote:
> > When I'm rewriting history, "git push --force-with-lease" is a nice
> > safeguard compared to "git push --force", but it still assumes the
> > remote-tracking ref gives the ol
On Sat, Apr 08, 2017 at 09:35:04AM +0200, Ævar Arnfjörð Bjarmason wrote:
> Is it correct that you'd essentially want something that works like:
>
> git push --force-with-lease=master:master origin master:master
I don't think that would do anything useful. It would reject any push
where the r
On Fri, Apr 7, 2017 at 7:15 PM, Matt McCutchen wrote:
> When I'm rewriting history, "git push --force-with-lease" is a nice
> safeguard compared to "git push --force", but it still assumes the
> remote-tracking ref gives the old state the user wants to overwrite.
> Tools that do an implicit fetch,
On Sat, Apr 8, 2017 at 4:15 AM, Matt McCutchen wrote:
> When I'm rewriting history, "git push --force-with-lease" is a nice
> safeguard compared to "git push --force", but it still assumes the
> remote-tracking ref gives the old state the user wants to overwrite.
> Tools that do an implicit fetch,
Matt McCutchen wrote:
> When I'm rewriting history, "git push --force-with-lease" is a nice
> safeguard compared to "git push --force", but it still assumes the
> remote-tracking ref gives the old state the user wants to overwrite.
> Tools that do an implicit fetch, assuming it to be a safe oper
When I'm rewriting history, "git push --force-with-lease" is a nice
safeguard compared to "git push --force", but it still assumes the
remote-tracking ref gives the old state the user wants to overwrite.
Tools that do an implicit fetch, assuming it to be a safe operation,
may break this assumption
32 matches
Mail list logo