Git and not rebasing branches pushed remotely ?

[Ian Young]

> On 25 Sep 2015, at 20:39, Tom Zeller <tzeller at dragonacea.biz> wrote:
> 
> I believe Git best practice is to not rebase a branch pushed remotely,

The actual thing people frown upon, and which I hope we will strive to avoid, is rewriting public history of any kind.

> so I’ve been pushing to a “personal” branch (i.e. "name/project") in case anyone was curious.

When you say personal branch, I think you actually mean a personal (i.e., non-public) *repository*.

> Are we going to follow that practice, to not rebase branches pushed remotely ?

I don't think we should rewrite public history if we can ever help it.

> If so, for a Git repo to show up in our Gitweb installation, should I name it "name-project" (instead of "name/project”),

Please don't do this, it's misguided. If something shows up in gitweb, it's public. We don't want six transient variants showing up there alongside the real version.

> with the understanding that it may be rebased ? (For example, because I need to rename the JIRA issue in a bunch of comments). My understanding was that “personal” (i.e. "name/project") repos are not visible via Gitweb.

They are not. This is a good thing. You can make them visible to particular committers for review, and I think even make them available through the anonymous protocols. Making them generally visible to anyone just encourages people to clone from them, which we absolutely don't want them to do.

> And, if so, how do we make sure not to rebase branches pushed remotely ?

This is only an issue for things that take a long time to do. For short term things, just do them in the private repository on your workstation and rebase at the end if necessary before pushing to the public repository.

You can work the same way for things that take a long time to land, too, as long as you don't need anyone else to review it or collaborate. You can push to a topic branch in your personal repository if you feel the need to have a backup.

The personal repository system is also a good way to work in those circumstances if there's a reason you don't want to work in the open, but there are significant downsides. The main one is that every time you rewrite history in your personal repository, anyone you've given access to that in the past needs to deal with the consequences.

The more natural option for long running feature development is to do the work in the open in a feature branch which you periodically push to the public repository. That restricts you to changing the history you haven't pushed yet, of course, but that doesn't mean you are completely tied down. Instead, you might review your unpushed changes every day or so, then modify things appropriately (e.g., fixing commit messages, squashing uninformative commits, etc.) before pushing. Periodically you'll find that you need to merge from the parent branch, and at the end you of course merge into the parent branch.

This doesn't preserve the illusion of a single beautiful hand crafted commit landing from out of a clear blue sky, but arguably for long term work you don't want that illusion anyway. This is how people work with Git elsewhere, I don't see any reason we can't.

    -- Ian




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5250 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/dev/attachments/20150926/4084126f/attachment.p7s>