similar to: git : changes to my local repository but not pushed upstream

Sean Silva asked me, "How are you committing across both projects simultaneously?" For example, r167595. http://llvm.org/viewvc/llvm-project?view=rev&revision=167595 For the record, I introduce a how-to. Yeah it's troublesome. I don't do usually. [Prerequisites] * subtree-merged git repo. https://github.com/chapuni/llvm-project * Assume you are working on llvm-project. *

Hello guys, I made the "subtree" all-in-one LLVM, clang, dragonegg &c repository. https://github.com/chapuni/llvm-project * How to play 1) git clone git://github.com/chapuni/llvm-project.git 2) (Optional) Add the line in [remote "origin"], .git/config [remote "origin"] fetch = +refs/notes/commits:refs/notes/commits And "git fetch

You need to create a branch from the original master, if you do git log master then you'll see which commit that is: f735449d679686867e7d3ab70810b09e8cea6366 So create that branch off that and switch to the new branch: git branch keepclassx f735449d679686867e7d3ab70810b09e8cea6366 git checkout keepclassx Then do git log keepclass to see the id of the new commit that you want to put on top of

greened at obbligato.org (David A. Greene) writes: > Updating LLVM - no local changes > -------------------------------- > > To update your clone to the latest LLVM sources, use git pull: > > git pull llvm-upstream That should probably be either git pull or git pull llvm-upstream master since the first is shorter and works if llvm-upstream is the upstream for the

On 24/01/2018 7:04 PM, G?bor Cs?rdi wrote: > You need to create a branch from the original master, if you do > git log master > then you'll see which commit that is: f735449d679686867e7d3ab70810b09e8cea6366 > > So create that branch off that and switch to the new branch: > git branch keepclassx f735449d679686867e7d3ab70810b09e8cea6366 > git checkout keepclassx > >

Good evening, Jay! ...Instructions, ... 1. git clone http://llvm.org/git/XXX.git (assume it "origin") 2. Create git authors file (assume /path/to/file/of/authors) with single line. foad = Jay Foad <jay.foad at gmail.com> Oh yeah, you should define your name and mailto same as described in llvm.org/git with case-sensitive. 3. Edit .git/config manually :p [svn]

https://git.centos.org/summary/websites!centos.org.git >--------------------------------------------------------------- master branch updated (1 commits) >--------------------------------------------------------------- Fabian Arrotin <arrfab at centos.org> Friday, November 3, 2017 16:12 +0000 - Renamed calendar.markdown to calendar.md (that's the file used by nanoc), and

On 25 January 2018 at 06:20, Duncan Murdoch wrote: | On 25/01/2018 2:57 AM, I?aki ?car wrote: | > For what it's worth, this is my workflow: | > | > 1. Get a fork. | > 2. From the master branch, create a new branch called fix-[something]. | > 3. Put together the stuff there, commit, push and open a PR. | > 4. Checkout master and repeat from 2 to submit another patch. | >

Chris Lattner <clattner at apple.com> writes: > On Jul 23, 2011, at 4:34 AM, Matthieu Moy wrote: > >> The flow promoted by Git is precisely to make sure each and every commit >> passes the tests. So, the granularity of "incremental development" is >> really the commit, not how often you merge. > This model is based on the idea of some trusted maintainer

Hi Melanie, Thanks for your reply, but if I understand it well, this implies making changes to the local ‘main’ branch, and push from that, which is what I want to avoid. But still, if I push from ‘main’, how do I fold a number of local commits into a single one, with a single comment, as appropriate for LLVM?. My workflow consists on creating different local branches to avoid changes on the

Rafael Ávila de Espíndola <rafael.espindola at gmail.com> writes: > On 07/05/2011 03:27 PM, David Greene wrote: >> My git-svn fu is not very strong. >> >> In the course of preparing a set of AVX patches, I've committed several >> changes to my local LLVM git clone. I don't want to send all of those >> changes upstream right away. What's the

> On Jul 31, 2016, at 12:06 AM, Justin Lebar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> And if it is, then the "only thing a monorepo gets you" isn't something that you need a monorepo to get. > > This is an *extremely important* point to understand, so let me try to > be really clear about the current state of the world and the state of >

Hi Hiroshi, Thanks for that. I find “rebase” difficult to use. Maybe I don’t understand it, but it always causes a lot ‘conflicts’ that are very hard to fix according to my experience. I have another question though. LLVM requires that reviewed patches are pushed as a /single/ commit with a standardised message, particularly specifying the Differential Revision url as part of the commit message.

On 07/05/2011 03:48 PM, David A. Greene wrote: > Rafael Ávila de Espíndola<rafael.espindola at gmail.com> writes: > >> On 07/05/2011 03:27 PM, David Greene wrote: >>> My git-svn fu is not very strong. >>> >>> In the course of preparing a set of AVX patches, I've committed several >>> changes to my local LLVM git clone. I don't want to

On 01/15/2020 05:03 PM, Reid Kleckner via llvm-dev wrote: > Tom Stellard told me to use `git cherry-pick -x`, and if you look at the release branches, you can see it is used, although the old style is used as well. I'm not sure what script is being used there. > I recommend updating the merge.sh script to use `git cherry-pick -x` and then deleting the merge-git.sh script. -Tom >

On Jul 22, 2011, at 12:33 AM, Matthieu Moy wrote: > John McCall <rjmccall at apple.com> writes: >>> git branch --contains <sha1>, on the other hand, will tell you. >> >> Of course, this doesn't actually help if you've cherry-picked commits >> over to your branch (e.g. because it's a release branch). > > How is that different from SVN?

Hi Duncan! I think there are many users whose first experiences with git where frustrating, and trust me, many people here can relate to your pain. I can certainly say that I can. At first, git makes significant effort to become fluent in seemingly "simple" tasks. I can literally feel your pain right now. But this is the main downside of git: that it can be hard to learn. I overcame

> For example, say github's llvm-mirror was a contributor's fork. The review > process might look like this: > > Contributor: > Please review my patch: > https://github.com/llvm-mirror/llvm/commit/4823be3be1d87632fbd51ce8e51a58ee5e44b115 > > Maintainer: > Adds inline comments with online tool. Then when patch is looking good: > $ git fetch

> And if it is, then the "only thing a monorepo gets you" isn't something that you need a monorepo to get. This is an *extremely important* point to understand, so let me try to be really clear about the current state of the world and the state of the world under the two "move to git" proposals. Today, all commits ultimately end up in SVN. Our SVN is a effectively a

My git-svn fu is not very strong. In the course of preparing a set of AVX patches, I've committed several changes to my local LLVM git clone. I don't want to send all of those changes upstream right away. What's the best way to send just the first of those changes us using git-svn? dcommit appears to send all pending changes. Is there a way of branching/cherry-picking that will