Re: [PATCH] Added guilt.reusebranch configuration option.
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
publish, at which point I curse and then start consulting the reflog
to back the state of my tree out, and then reapplying the work I had
to the right tree.
My scenario is a bit different, and I think this safety feature is
highly overrated. It's not that I'll never rewind some branches, but
rewind other branches, but rather I might rewind anything at any
time, but I want immediate information so I can quickly inspect @{1}
to see if that was undesirable. To put it another way, my philosophy
is not auto-deny unintended changes, but rather tell me immediately
about undesirable changes. To this effect, my prompt looks like:
artagnon|push-current-head=:~/src/git$
The = indicates that I'm in sync with upstream, and that there's
nothing to push. When I make some changes, that character changes to
, which means that there are ff changes to push. Finally,
artagnon|push-current-head:~/src/git$
has my immediate attention. means that I've diverged from
upstream. Since the prompt is present all the time, I catch the
divergence just-in-time. Moreover, I push very frequently resetting
the prompt to = periodically.
So, do you still need this rewinding safety thing?
So what I do is something like this:
git push publish ; git push repo ; git push code
While we can definitely make the UI better for this (maybe push
--multiple?), there is no fundamental change: we have to re-initialize
all the refspecs, connect to the remote via the transport layer and
prepare a packfile to send. In other words, it's impossible to make
it any faster than what you get with the above.
where
[remote publish]
url = ssh://gitol...@ra.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
fetch = +refs/heads/*:refs/heads/*
push = next
push = master
push = maint
push = debian
push = +pu
So you're a batched-push person. And the above makes it clear that
you don't want to explicitly differentiate between a push and push -f
(the +pu thing). And this assumes that you never create any new
branches (I branch out all the time), otherwise you'd have rules for
refs/heads/*. Just out of curiosity, do you ever have ref-renaming
requirements (like push = refs/heads/*:refs/heads/tt/*)? We were
discussing that on another thread, but I haven't found an
implementation I'm happy with yet.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added guilt.reusebranch configuration option.
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
publish, at which point I curse and then start consulting the reflog
to back the state of my tree out, and then reapplying the work I had
to the right tree.
My scenario is a bit different, and I think this safety feature is
highly overrated. It's not that I'll never rewind some branches, but
rewind other branches, but rather I might rewind anything at any
time, but I want immediate information so I can quickly inspect @{1}
to see if that was undesirable.
Spekaing of which, what I'd really appreciate is timestamps associated
with the reflog. That's because the most common time when I've
screwed something up is after doing a git rebase -i and so the
reflog has a *huge* number of entries on it, and figuring out which
entry in the reflog is the right one is painful. If could tell at a
glance when each entry of the reflog was created, it would make it a
lot easier to untangle a tree mangled by git rebase -i.
In practice, it means I waste five minutes carefully inspecting a few
dozen entries on the reflog, so it's not a disaster, although I'm
generally cursing the whole time while I'm trying to untangle the
whole mess.
This issue with reflogs not having timestamps isn't primarily about
rewind safety, BTW; it's just one of the things which make consulting
the reflog painful --- and it's much more likely happens after I screw
up a git rebase -i, generally because of what happens when there's a
merge conflict and then I accidentally fold two commits together
unintentionally. The times when I've screwed up a non-rewinding
branch and then needed to recover after discovering the problem when I
try to publish said branch are admittedly rare; maybe once or twice
times in the past twelve months.
So, do you still need this rewinding safety thing?
Meh; I don't *need* it. But then again, I'm an fairly experienced git
user. The fact that I use guilt without the guilt/master safety
feature and have never gotten bitten by it --- in fact I deliberately
publish rewindable branches with a guilt patch series applies speaks
to the fact that I'm pretty experienced at rewindable heads.
The only reason why I suggested it is because I believe it would be
useful for people with less experience, and perhaps it would help make
rewindable branches less scary, and less subject to a lot of the
fearmongering that you see on the blogosphere.
So what I do is something like this:
git push publish ; git push repo ; git push code
While we can definitely make the UI better for this (maybe push
--multiple?), there is no fundamental change: we have to re-initialize
all the refspecs, connect to the remote via the transport layer and
prepare a packfile to send. In other words, it's impossible to make
it any faster than what you get with the above.
Sure, and if I cared I'd make a git alias to automate this, instead of
depending on finger macros.
So you're a batched-push person. And the above makes it clear that
you don't want to explicitly differentiate between a push and push -f
(the +pu thing). And this assumes that you never create any new
branches (I branch out all the time), otherwise you'd have rules for
refs/heads/*.
I create new branches all the time. But they are for my own personal
testing purposes. So it's fairer to say that I rarely *publish* new
branches; I generally stick to the standard set of next, master,
maint, and pu. And part of that is that even publishing this number
of branches is enough to sometimes confuse the e2fsprogs developers
who are pulling from my tree.
So what I've done in the past is to create a whole bunch of feature
branches, and then merge them into the pu branch, and then only
publish the pu branch. And I try to get the feature branches cleaned
up as quickly as I have time, so they can appear on the maint or
master/next branches sooner rather than later.
Just out of curiosity, do you ever have ref-renaming
requirements (like push = refs/heads/*:refs/heads/tt/*)? We were
discussing that on another thread, but I haven't found an
implementation I'm happy with yet.
In general, no, I don't do that, for the reasons stated above --- even
publishing four branches gets to be confusing enough for people who
are looking at my tree.
I'm sure other people and other communities use git differently, so
please insert the standard disclaimer that there's more than one way
to skin a cat.
Regards,
- Ted
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added guilt.reusebranch configuration option.
Theodore Ts'o ty...@mit.edu writes:
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 where they (initially) clone from
in order to bootstrap themselves, and (subsequently) pull from in
order to keep them up-to-date. And then they request the published
work to be pulled by the upstream.
Yep, what I do personally is to call the destination of this publish, i.e.:
[remote publish]
url = ssh://gitol...@ra.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.g
push = +master:master
push = +origin:origin
push = +dev:dev
So my typical work flow when I am ready to submit to Linus is:
git tag -s ext4_for_linus
git push publish
wait for this to propagate from ra.kernel.org to git.kernel.org,
typically ~5 minutes
And at this point I presume that you wish this push automatically
pushed out ext4_for_linus, just like fetch by default grabs tags
that point into the history being fetched?
I think push --follow-tags in the upcoming 1.8.3 would work for
you if that is the case.
git request-pull
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git origin
/tmp/pull
use /tmp/pull as the e-mail body to send to Linus, cc'ing
LKML and linux-e...@vger.kernel.org
But actually, it's much more common that I am doing a git push
publish so that (a) it can get picked up by the daily linux-next tree
(for integration testing even before Linus pulls it into his tree),
and (b) so other ext4 developers so they can either test or develop
against the ext4 tree in progress.
I suppose it would be convenient for git push to push to the
publish target, but I don't get confused about pushing to origin,
since semantically what I am doing is publishing the current state of
the ext4 tree so other people can see it. So git push publish makes
a lot of sense to me.
Noted.
Even in a triangular workflow, @{u} should still refer to the place
you integrate with, i.e. your upstream, not to the place you push
to publish the result of your work.
This branch.branch.rewindable safety however cannot be tied to
@{u}. The bottom boundary you want to be warned when you cross is
the change you pushed out to your publishing repository, and it may
not have reached remotes.origin.branch yet.
Indeed, and in fact for my use case what I promise people is that all
of the commits between origin..master are non-rewindable. It's the
commits betewen master..dev which are rewindable. So for me, I'd
still use the safety feature even for my rewindable branch, but
instead of using remotes/publish/dev the no-rewind point, I'd want
to use remotes/publish/master as the no-rewind point.
Sounds sensible.
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
publish, at which point I curse and then start consulting the reflog
to back the state of my tree out, and then reapplying the work I had
to the right tree.
Yes, exactly.
Yes, that would be convenient. BTW, one of the other things which I
do for e2fsprogs is that I use multiple publishing points, which is
mostly for historical reasons --- it used to be that repo.or.cz wasn't
all that reliable, and the 10-15 minute replication time from
ra.kernel.org to git.kernel.org got really old.
So what I do is something like this:
git push publish ; git push repo ; git push code
where
[remote publish]
url = ssh://gitol...@ra.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
...
[remote repo]
...
I don't know if this is something you'd want git to encourage, or
support explicitly, but I thought I'd mention it.
I think you can have more than one destination URLs to a single
remote you are pushing as long as what are pushed and how are common
to them, that is, something like this:
[remote publish]
; where do we fetch/pull from and how?
url = ssh://gitol...@ra.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
fetch = +refs/heads/*:refs/heads/*
; where do we push to and how?
pushurl = ssh://gitol...@ra.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
pushurl = https://code.google.com/p/e2fsprogs/
pushurl = ssh://repo.or.cz/srv/git/e2fsprogs.git
push = next
push = master
push = maint
push = debian
push = +pu
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added guilt.reusebranch configuration option.
Theodore Ts'o wrote: Spekaing of which, what I'd really appreciate is timestamps associated with the reflog. That's because the most common time when I've screwed something up is after doing a git rebase -i and so the reflog has a *huge* number of entries on it, and figuring out which entry in the reflog is the right one is painful. If could tell at a glance when each entry of the reflog was created, it would make it a lot easier to untangle a tree mangled by git rebase -i. Yeah, I completely agree with this one. I've wished for the reflog to be presented in a nicer ui, with humanized timestamps and colors. Meh; I don't *need* it. But then again, I'm an fairly experienced git user. The fact that I use guilt without the guilt/master safety feature and have never gotten bitten by it --- in fact I deliberately publish rewindable branches with a guilt patch series applies speaks to the fact that I'm pretty experienced at rewindable heads. Oh, and thanks for mentioning guilt: I just learnt about it. The only reason why I suggested it is because I believe it would be useful for people with less experience, and perhaps it would help make rewindable branches less scary, and less subject to a lot of the fearmongering that you see on the blogosphere. My message was a critique. I'm not denying that the feature may be useful; it's just that we should have a good rationalization of the usecase and design something carefully. Sure, and if I cared I'd make a git alias to automate this, instead of depending on finger macros. Yes. My comment was more of question: can --multiple be more than a for loop written in shell? If not, is it worth writing? Are there enough users? Junio mentioned pushurl in the other email: if they're perfect mirrors, won't pushurl suffice? I create new branches all the time. But they are for my own personal testing purposes. So it's fairer to say that I rarely *publish* new branches; I generally stick to the standard set of next, master, maint, and pu. And part of that is that even publishing this number of branches is enough to sometimes confuse the e2fsprogs developers who are pulling from my tree. Just for contrast: I never keep anything locally. I publish as much of my setup as humanly possible so that I'm not tied to one machine. In general, no, I don't do that, for the reasons stated above --- even publishing four branches gets to be confusing enough for people who are looking at my tree. Just publish different branches to different locations? Isn't that why we got triangular workflows? I'm sure other people and other communities use git differently, so please insert the standard disclaimer that there's more than one way to skin a cat. Ofcourse. I believe in being all-inclusive, and not dropping a single feature that has users. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added guilt.reusebranch configuration option.
Theodore Ts'o ty...@mit.edu writes:
Spekaing of which, what I'd really appreciate is timestamps associated
with the reflog. That's because the most common time when I've
screwed something up is after doing a git rebase -i and so the
reflog has a *huge* number of entries on it, and figuring out which
entry in the reflog is the right one is painful. If could tell at a
glance when each entry of the reflog was created, it would make it a
lot easier to untangle a tree mangled by git rebase -i.
Do you mean you want to go back to one specific step in rebase -i,
or you mean you want to go back to the state before rebase -i?
If the latter, one nice thing to know may be that git log -g is
like git log -g HEAD@{0} and inspects the reflog associated with
HEAD, and you can view individual steps of rebase -i. On the
other hand, git log -g @{0} (or git log -g master@{0} if you are
on 'master' branch) will inspect the reflog associated with the
current branch, and rebase -i appears as a single event (i.e. the
tip before rewinding and replaying all the changes is replaced with
the tip after that whole series of replaying). So the latter is
what you want to use if you are interested in the state before the
whole rebase -i operation.
Also you can ask git log -g HEAD@{now} and git log -g @{now}. I
agree with you that git log --oneline -g @{now} is very handy, and
git log --oneline --relative-date -g @{now} is even better, as I
can clearly see where the flurry of recent activities ends and which
reflog entry is the one I was at 20 minutes ago before I started.
This issue with reflogs not having timestamps isn't primarily about
rewind safety,...
I think I may have answered this part with the above.
So what I've done in the past is to create a whole bunch of feature
branches, and then merge them into the pu branch, and then only
publish the pu branch. And I try to get the feature branches cleaned
up as quickly as I have time, so they can appear on the maint or
master/next branches sooner rather than later.
Sounds very similar to somebody else is doing ;-)
Just out of curiosity, do you ever have ref-renaming
requirements (like push = refs/heads/*:refs/heads/tt/*)? We were
discussing that on another thread, but I haven't found an
implementation I'm happy with yet.
In general, no, I don't do that, for the reasons stated above --- even
publishing four branches gets to be confusing enough for people who
are looking at my tree.
I'm sure other people and other communities use git differently, so
please insert the standard disclaimer that there's more than one way
to skin a cat.
Agreed to both counts. Thanks for comments.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added guilt.reusebranch configuration option.
On Wed, May 22, 2013 at 03:01:36PM +0200, Per Cederqvist wrote: When the option is true (the default), Guilt does not create a new Git branch when patches are applied. This way, you can switch between Guilt 0.35 and the current version of Guilt with no issues. At a future time, maybe a year after Guilt with guilt.reusebranch support is released, the default should be changed to false to take advantage of the ability to use a separate Git branch when patches are applied. So, I've been using the always-on prefix code and I do like it. It makes me reasonably happy that other people that work on the same repo won't screw it up. So, with that said, I'm tempted to actually make the default the new-style prefix. If someone (there's at least Ted) wants the old behavior, they'll have the config. IOW, I'm tempted to apply this patch with a minor tweak: change the default to new-style. Signed-off-by: Per Cederqvist ced...@opera.com --- This is an alternative solution to the same problem. I've been running with this code for a while. I don't remember if I sent it to the list before, but if I did it was apparently lost. Sorry if I never sent it. For all I know, I just dropped this patch on the floor by accident :/ Jeff. This version includes some regression tests. (I'm having mail problems. Apologies if you receive this patch twice.) /ceder guilt| 29 +++- regression/scaffold | 1 + regression/t-062.out | 457 +++ regression/t-062.sh | 150 + 4 files changed, 632 insertions(+), 5 deletions(-) create mode 100644 regression/t-062.out create mode 100755 regression/t-062.sh diff --git a/guilt b/guilt index 66a671a..108d4e7 100755 --- a/guilt +++ b/guilt @@ -836,6 +836,9 @@ guilt_push_diff_context=1 # default diffstat value: true or false DIFFSTAT_DEFAULT=false +# default old_style_prefix value: true or false +REUSE_BRANCH_DEFAULT=true + # Prefix for guilt branches. GUILT_PREFIX=guilt/ @@ -847,6 +850,10 @@ GUILT_PREFIX=guilt/ diffstat=`git config --bool guilt.diffstat` [ -z $diffstat ] diffstat=$DIFFSTAT_DEFAULT +# reuse Git branch? +reuse_branch=`git config --bool guilt.reusebranch` +[ -z $reuse_branch ] reuse_branch=$REUSE_BRANCH_DEFAULT + # # The following gets run every time this file is source'd # @@ -911,13 +918,25 @@ else die Unsupported operating system: $UNAME_S fi -if [ $branch = $raw_git_branch ] [ -n `get_top 2/dev/null` ] +if [ -n `get_top 2/dev/null` ] then -# This is for compat with old repositories that still have a -# pushed patch without the new-style branch prefix. -old_style_prefix=true + # If there is at least one pushed patch, we set + # old_style_prefix according to how it was pushed. It is only + # possible to change the prefix style while no patches are + # applied. + if [ $branch = $raw_git_branch ] + then + old_style_prefix=true + else + old_style_prefix=false + fi else -old_style_prefix=false + if $reuse_branch + then + old_style_prefix=true + else + old_style_prefix=false + fi fi _main $@ diff --git a/regression/scaffold b/regression/scaffold index 5c8b73e..acddb07 100644 --- a/regression/scaffold +++ b/regression/scaffold @@ -88,6 +88,7 @@ function setup_git_repo git config log.date default git config log.decorate no git config guilt.diffstat false + git config guilt.reusebranch false } function setup_guilt_repo diff --git a/regression/t-062.out b/regression/t-062.out new file mode 100644 index 000..d00b3f6 --- /dev/null +++ b/regression/t-062.out @@ -0,0 +1,457 @@ +% setup_repo +% git config guilt.reusebranch true +% guilt push -a +Applying patch..modify +Patch applied. +Applying patch..add +Patch applied. +Applying patch..remove +Patch applied. +Applying patch..mode +Patch applied. +% list_files +d .git/patches +d .git/patches/master +d .git/refs/patches +d .git/refs/patches/master +f 22930c6d1f1938f298a4fca51c57e4b47171db21 .git/patches/master/mode +f 413390f3906f16f30b054a4fb86c1e014b964504 .git/patches/master/remove +f 71596bf71b72c2717e1aee378aabefbfa19ab7c8 .git/patches/master/status +f 9c18cc7abe6b87f18503714a80a677b4094eb457 .git/patches/master/add +f bacb4aad8a55fe4e7aa58a9ae169990bb764069f .git/patches/master/series +f bc9ab2e0f5db99d483961e956e814d963f0309f8 .git/patches/master/modify +r 33633e7a1aa31972f125878baf7807be57b1672d .git/refs/patches/master/modify +r 37d588cc39848368810e88332bd03b083f2ce3ac .git/refs/patches/master/add +r ccd56089d1b5305a9d35617cb7f6f4b06ffa68ba .git/refs/patches/master/mode +r ffb7faa126a6d91bcdd44a494f76b96dd860b8b9 .git/refs/patches/master/remove +% git for-each-ref +ccd56089d1b5305a9d35617cb7f6f4b06ffa68ba commit
Re: [PATCH] Added guilt.reusebranch configuration option.
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 interesting to have a branch.branch.rewindable, which would change the guilt defaults, and could also key changes in key git behavior which makes it less likely that a user shoots him or herself in the foot --- i.e., give warnings if he or she has modified the branch in such a way that remotes.origin.branch is no longer contained within the branch head. - Ted -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added guilt.reusebranch configuration option.
On Wed, May 22, 2013 at 10:45:31AM -0400, Theodore Ts'o wrote: 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 interesting to have a branch.branch.rewindable, which would change the guilt defaults, and could also key changes in key git behavior which makes it less likely that a user shoots him or herself in the foot --- i.e., give warnings if he or she has modified the branch in such a way that remotes.origin.branch is no longer contained within the branch head. Interesting! I wonder what git people have to say about this. Jeff. -- We have joy, we have fun, we have Linux on a Sun... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added guilt.reusebranch configuration option.
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 it less likely that a user shoots him or herself in the foot --- i.e., give warnings if he or she has modified the branch in such a way that remotes.origin.branch is no longer contained within the branch head. At least rebase can pay attention to it and might make the world a better place. Your final git push needs to be forced if you rewound beyond remotes.origin.branch so in that sense, there already is a sefety, but it is better to give the user a chance to notice that before the user spends more time to polish the rewound topic to perfection, only to see the push rejected. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added guilt.reusebranch configuration option.
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 it less likely that a user shoots him or herself in the foot --- i.e., give warnings if he or she has modified the branch in such a way that remotes.origin.branch is no longer contained within the branch head. At least rebase can pay attention to it and might make the world a better place. Yeah, rebase was the primary command I was thinking about. The other one would be git commit --amend after the branch had been pushed out. - Ted -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added guilt.reusebranch configuration option.
Theodore Ts'o ty...@mit.edu writes:
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 it less likely
that a user shoots him or herself in the foot --- i.e., give warnings
if he or she has modified the branch in such a way that
remotes.origin.branch is no longer contained within the branch head.
At least rebase can pay attention to it and might make the world a
better place.
Yeah, rebase was the primary command I was thinking about. The other
one would be git commit --amend after the branch had been pushed
out.
It may or may not matter for the kernel folks, but let me pick your
brain while we are on this subject.
The upstream (your remotes.origin.branch) is that on top of
which you build your work. You clone from there to bootstrap
yourself, you add your work (which may include integrating the work
of your contributors, if you are a mid-tier maintainer/integrator
aka a lieutenant) on top of it, and arrange the result to reach the
upstream in some way.
For the simplest (and still widely used) workflow that employs a
central shared repository, the way to make the result to reach the
upstream is by directly pushing into it yourself. In that sense,
the word upstream and the traditional behaviour of git push that
pushes back to the 'origin' (or branch.branch.remote) to update
your upstream (or branch.branch.merge at 'origin') both make
perfect sense.
Also, if you are rebasing, @{u} refers to that place you integrate
with, i.e. your upstream, in the central shared repository
workflow.
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 where they (initially) clone from
in order to bootstrap themselves, and (subsequently) pull from in
order to keep them up-to-date. And then they request the published
work to be pulled by the upstream.
Even in a triangular workflow, @{u} should still refer to the place
you integrate with, i.e. your upstream, not to the place you push
to publish the result of your work.
This branch.branch.rewindable safety however cannot be tied to
@{u}. The bottom boundary you want to be warned when you cross is
the change you pushed out to your publishing repository, and it may
not have reached remotes.origin.branch yet.
We will be introducing remote.pushdefault configuration in the
upcoming 1.8.3 release, so that you can say:
[remote origin]
url = git://g.k.o/pub/scm/linux/kernel/git/torvalds/linux.git/
fetch = +refs/heads/*:refs/remotes/origin/*
[remote ext4]
url = g.k.o:/pub/scm/linux/kernel/git/tytso/ext4.git/
fetch = +refs/heads/*:refs/remotes/ext4/*
[remote]
pushdefault = ext4
and hopefully it would let you do this:
git checkout master
... after working on it ...
git push
As remote.pushdefault is set to ext4, without any extra arguments,
the result will pushed to the ext4 remote. If you are using the
traditional push.default=matching, it may also try to push out dev,
dev-next and other branches you may have in your local repository
and at k.org; if you are using push.default=simple or other single
branch modes like current, upstream, etc, it will only push out
your current branch (i.e. master) to ext4 remote.
You may however be using your local master branch for your
development, and pushing the result out to dev. With only the
remote.pushdefault setting to push to ext4 (instead of origin), you
still would have to say
git push ext4 master:dev
There is another change discussed on the list recently to also let
you configure your local master branch to update dev in your
publishing repository. It may go like this:
[branch master]
push = refs/heads/dev
In any case, refs/remotes/ext4/dev would be the remote tracking
branch (not refs/remotes/origin/anything) that keeps track of what
you pushed out there the last time. And that would be what your new
safety based on branch.master.rewindable = no needs to check
against, not refs/remotes/origin/master which is your master@{u}.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Added guilt.reusebranch configuration option.
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 where they (initially) clone from
in order to bootstrap themselves, and (subsequently) pull from in
order to keep them up-to-date. And then they request the published
work to be pulled by the upstream.
Yep, what I do personally is to call the destination of this publish, i.e.:
[remote publish]
url = ssh://gitol...@ra.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.g
push = +master:master
push = +origin:origin
push = +dev:dev
So my typical work flow when I am ready to submit to Linus is:
git tag -s ext4_for_linus
git push publish
wait for this to propagate from ra.kernel.org to git.kernel.org,
typically ~5 minutes
git request-pull
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git origin /tmp/pull
use /tmp/pull as the e-mail body to send to Linus, cc'ing
LKML and linux-e...@vger.kernel.org
But actually, it's much more common that I am doing a git push
publish so that (a) it can get picked up by the daily linux-next tree
(for integration testing even before Linus pulls it into his tree),
and (b) so other ext4 developers so they can either test or develop
against the ext4 tree in progress.
I suppose it would be convenient for git push to push to the
publish target, but I don't get confused about pushing to origin,
since semantically what I am doing is publishing the current state of
the ext4 tree so other people can see it. So git push publish makes
a lot of sense to me.
Even in a triangular workflow, @{u} should still refer to the place
you integrate with, i.e. your upstream, not to the place you push
to publish the result of your work.
This branch.branch.rewindable safety however cannot be tied to
@{u}. The bottom boundary you want to be warned when you cross is
the change you pushed out to your publishing repository, and it may
not have reached remotes.origin.branch yet.
Indeed, and in fact for my use case what I promise people is that all
of the commits between origin..master are non-rewindable. It's the
commits betewen master..dev which are rewindable. So for me, I'd
still use the safety feature even for my rewindable branch, but
instead of using remotes/publish/dev the no-rewind point, I'd want
to use remotes/publish/master as the no-rewind point.
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
publish, at which point I curse and then start consulting the reflog
to back the state of my tree out, and then reapplying the work I had
to the right tree.
We will be introducing remote.pushdefault configuration in the
upcoming 1.8.3 release, so that you can say.
and hopefully it would let you do this:
git checkout master
... after working on it ...
git push
Yes, that would be convenient. BTW, one of the other things which I
do for e2fsprogs is that I use multiple publishing points, which is
mostly for historical reasons --- it used to be that repo.or.cz wasn't
all that reliable, and the 10-15 minute replication time from
ra.kernel.org to git.kernel.org got really old.
So what I do is something like this:
git push publish ; git push repo ; git push code
where
[remote publish]
url = ssh://gitol...@ra.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
fetch = +refs/heads/*:refs/heads/*
push = next
push = master
push = maint
push = debian
push = +pu
[remote code]
url = https://code.google.com/p/e2fsprogs/
fetch = +refs/heads/*:refs/heads/*
push = next
push = master
push = maint
push = debian
push = +pu
[remote repo]
url = ssh://repo.or.cz/srv/git/e2fsprogs.git
push = next
push = master
push = maint
push = debian
push = +pu
I don't know if this is something you'd want git to encourage, or
support explicitly, but I thought I'd mention it.
- Ted
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
