Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You're trying to apply a centralized workflow to a distributed system. You need to think about doing things locally, not centrally. The shared (central) repository is simply the place where you put stuff you want to share with others, or you retrieve the stuff they want to share.</p> <p>Here's essentially what you're asking for. However, I don't think it's the best workflow. See below for a modified version. </p> <pre><code>Create a new local branch (A) that tracks a remote branch (X) git clone &lt;url&gt; my_repo Do some work, make some local commits. work, work work git add . git commit -m "commit of work" A is rebased up to the HEAD of X. We're operating on the same branch we want to rebase from the remote, so we can do it all with one command in this case. git pull --rebase Do some work, make some local commits. work, work work git add . git commit -m "commit of work" Have an offshoot idea, make a new local branch (B) from (A) git checkout -b idea Do some work, make some local commits. work, work work git add . git commit -m "commit of work" B is rebased up to the HEAD of X git rebase origin master </code></pre> <p>But....that whole workflow revolves around the remote as the "source of truth." The more git-way of doing it, IMHO is to think of your local as the source of truth, and just update it with shared content from the central repository. It's the same thing, just approaching it from a different angle.</p> <p>Here's how I'd do your workflow:</p> <p>Create a new local branch (A) that tracks a remote branch (X) git clone my_repo Do some work, make some local commits. work, work work git add . git commit -m "commit of work"</p> <pre><code>A is rebased up to the HEAD of X. We use two commands here, but doing it this way makes it easy for me to view the differences before doing the rebase, if I choose. git fetch git rebase origin/master Do some work, make some local commits. work, work work git add . git commit -m "commit of work" Have an offshoot idea, make a new local branch (B) from (A) git checkout -b idea Do some work, make some local commits. work, work work git add . git commit -m "commit of work" B is rebased up to the HEAD of X git fetch git rebase origin/master </code></pre> <p>Of course both of the scenarios depend upon the fact you didn't' do additional work on your local master branch before rebasing origin/master into your idea branch. If you did, you wouldn't have the commits you did on master locally, and it'd be more effective to do:</p> <pre><code>git fetch git checkout master git rebase origin/master --(make sure master is up-to-date locally) git checkout idea git rebase master (apply idea on top of the updated local master) </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POHow do I make a new local branch track the same remote branch as the local branch it's created from?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USwadesworld
    1. USwadesworld
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COThe team I'm on uses git with a centralized workflow. Needing to get up to date with stuff that others have pushed to the "shared" repo happens multiple times daily. Your suggestion: `git rebase origin/master` works, but it requires that I know & type "origin/master" which is precisely what I don't want to do. I want branch (B) to be a tracking branch of the same remote that (A) is tracking. I have `branch.autosetuprebase` set to yes, so in the case where the branch is tracking, I just type `git pull` and I'm good to go. My question is about ensuring that all branches are tracking by default.
      singulars
      1. PO
      1. USipmcc
    2. COIf you don't want to know or type "origin/master" then you're only hurting yourself in my opinion. If you're going to use git just like SVN, you might as well go back to SVN since that's what makes your team comfortable. The power of git is understanding concepts like origin/master and how you can utilize it. Because of the way git does things, you can do more complex operations and do so safely. But if you don't want to know any of that, there's not much point - might as will stick with subversion.
      singulars
      1. PO
      1. USwadesworld
    3. COBut to answer your specific question, I don't think there's a way to have git automatically setup tracking branches that point to the remote branch from which the local branch was created before the new branch was created. Typically tracking branches point to an identical branch on the remote. If you want them to point to something different, you're going to have to tell git explicitly. And of course you're going to have to remember that your idea branch doesn't point to idea on the remote, it points to "A" on the remote.
      singulars
      1. PO
      1. USwadesworld
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload