www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - shared gitconfig

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sent this to dmd-internals, opening for a broader discussion:

Hello,


I wonder how we can define a few aliases of project-wide usefulness to 
git. For example, I tried today to get the latest and greatest phobos 
into my repo, and got a bunch of conflicts. I searched a while on the 
net to figure what the command for "just get the latest remote into my 
local copy", which is entirely possible but not obvious and not easy to 
find. I got it from here: http://goo.gl/pWvVB and the invocation is:

git pull --rebase -s recursive -X ours

which does work like a charm. So I wanted to define a macro called 
"pull-force" like this:


[alias]
     pull-force = pull --rebase -s recursive -X ours
     ...

This, too, works great.

What I'd want to do next is define the alias such that other 
participants to the dlang project may use it. With time we'd collect a 
good set of macros that help our process.

What is the best way to share a few git config items among all 
participants to dmd, druntime, phobos etc?


Thanks,

Andrei
Jan 06 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 06, 2013 14:50:49 Andrei Alexandrescu wrote:

 Sent this to dmd-internals, opening for a broader discussion:
 
 Hello,
 
 
 I wonder how we can define a few aliases of project-wide usefulness to
 git. For example, I tried today to get the latest and greatest phobos
 into my repo, and got a bunch of conflicts. I searched a while on the
 net to figure what the command for "just get the latest remote into my
 local copy", which is entirely possible but not obvious and not easy to
 find. I got it from here: http://goo.gl/pWvVB and the invocation is:
 
 git pull --rebase -s recursive -X ours
 
 which does work like a charm. So I wanted to define a macro called
 "pull-force" like this:
 

 [alias]
      pull-force = pull --rebase -s recursive -X ours
      ...
 
 This, too, works great.
 
 What I'd want to do next is define the alias such that other
 participants to the dlang project may use it. With time we'd collect a
 good set of macros that help our process.
 
 What is the best way to share a few git config items among all
 participants to dmd, druntime, phobos etc?


To repeat what I just said in dmd-internals:

Maybe some macros would be useful, but I'm kind of inclined to think that 
people should just learn git, especially since many people will need it beyond 
our projects and learning an alias that doesn't exist elsewhere will just 
hamstring you. I think that it would be a better idea to have a page in the 
wiki listing useful commands so that people can learn them properly rather 
than relying on an alias that isn't standard git and which won't exist on any 
other projects.

But with regards to this particular command, I'd argue that you're doing 
something wrong if you need to force a rebase with a pull. How on earth did 
you end up in a situation where you needed to force a rebase like this on 
master or any branch that's in the main repo? Changes should be being done on 
separate branches, not on master. So, master doesn't need to be rebased. And 
generally, branches are your local branches, managed by you and which 
generally are relatively short-lived, so you won't need to do what you're 
describing here for them. If you're making changes on other branches in the 
main repository, I'd expect them to be treated the same as master. You make 
changes on your own, separate branch, push that to your repo on github for a 
pull request and get that merged into the branch in the main repo. So, in no 
case do you end up with any branch on your box being out of sync with the main 
repo. The rebasing that should be needed is when you have to rebase one of 
your local branches with master, because other changes were merged into master 
via pull requests, and the changes in your branch haven't been merged in on 
github yet.

The only time that you'd need to make a change directly on master or any 
branch which is in the main repository is when you actually push upstream from 
your local box instead of going through github, which we're not generally 
supposed to do. I have never needed the command that you just listed.

Maybe, you did something normal that I can't think of, but it seems to me that 
the problem here is your workflow, not the need for a macro.

- Jonathan M Davis
Jan 06 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-06 21:47, Jonathan M Davis wrote:



 But with regards to this particular command, I'd argue that you're doing
 something wrong if you need to force a rebase with a pull.


I agree.

-- 
/Jacob Carlborg
Jan 06 2013
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sunday, 6 January 2013 at 19:50:47 UTC, Andrei Alexandrescu 
wrote:

 Sent this to dmd-internals, opening for a broader discussion:

 Hello,


 I wonder how we can define a few aliases of project-wide 
 usefulness to git. For example, I tried today to get the latest 
 and greatest phobos into my repo, and got a bunch of conflicts. 
 I searched a while on the net to figure what the command for 
 "just get the latest remote into my local copy", which is 
 entirely possible but not obvious and not easy to find. I got 
 it from here: http://goo.gl/pWvVB and the invocation is:

 git pull --rebase -s recursive -X ours


Question: Do you know what exactly does this command do?

Git is a very powerful and flexible system. Unfortunately, it is 
also comparatively more complicated than its competitors, svn and 
hg. Incorrect usage, especially by project maintainers, can 
result in history rewrites, duplicate commits, and lost changes. 
This has already happened multiple times in the past.

Earlier I noticed some discussion regarding how Walter attempted 
to follow a guide on the wiki regarding the release process. The 
problem is that (from what I gathered) he attempted to simply run 
the commands listed there, without understanding each one's exact 
effect and purpose. An observation was raised that the guide was 
incomplete - however, I believe the iteration at that point was 
written as a guideline (a general outline of what needs to be 
done) as opposed to strict step-by-step instructions. When 
stumped with a merge, he elected to use the "git cherry-pick" 
command to copy the commits on top of his HEAD - however, this 
duplicates the commits' contents and results in duplicate commits 
in the repository.

I think you're trying to solve the wrong problem...

Back to your question. Let's look at the command you posted:


 git pull --rebase -s recursive -X ours


 From my understanding, this this is what will happen:

1. Fetch whatever commit objects that are absent from your tree 
but are present in the remote branch, and copy them to your tree. 
So far so good.
2. Rewind your HEAD to the tip of the branch you just pulled.
3. Take each commit that are in your branch's history, but are 
not in the remote's history, and re-apply them on top of the new 
HEAD. This creates new commit objects, with new SHA-1 hashes. 
Anything that builds upon the old SHA-1 hashes (e.g. if you've 
already uploaded these commits anywhere) will break. (--rebase 
rewrites history!)
4. Whenever there is a merge conflict, it will THROW AWAY your 
change and automatically apply the other change.

Was this your intention?

Now, the question you should ask: WHY did you get a merge 
conflict?

Was it a case of you and someone else actually changing the same 
bit of code? Or was it another instance of git abuse and someone 
force-pushing after someone else already pulled the code?

If the merge conflict is genuine, and you don't want to deal with 
the merge, you should abort the merge, save your work as a new 
branch, and reset the current branch to the remote's:

$ git merge --abort
$ git branch branch-name-for-my-work
$ git reset --hard origin/master

(substitute "origin" for the remote name, and "master" for the 
remote branch name).

If you want to throw away any commits that are in your local 
branch but not in the remote branch, just run the third command.

-- Vladimir, and too much coffee
Jan 06 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/6/13 4:03 PM, Vladimir Panteleev wrote:

 On Sunday, 6 January 2013 at 19:50:47 UTC, Andrei Alexandrescu wrote:

 git pull --rebase -s recursive -X ours


 Question: Do you know what exactly does this command do?


I do now after having read about it at the end of several google searches.


 Git is a very powerful and flexible system. Unfortunately, it is also
 comparatively more complicated than its competitors, svn and hg.
 Incorrect usage, especially by project maintainers, can result in
 history rewrites, duplicate commits, and lost changes. This has already
 happened multiple times in the past.


I agree it is important to be fluent with git. I'm an okay user but 
currently unfit for an admin. Probably Walter is at a similar stage. I'm 
doing my best to improve my knowledge in the limited time I have, and 
part of it is discussing git here. So I hope you'll understand why I 
find it contradictory to be reprimanded for doing so with the reproach 
that I should be doing exactly what I'm doing.


 Earlier I noticed some discussion regarding how Walter attempted to
 follow a guide on the wiki regarding the release process. The problem is
 that (from what I gathered) he attempted to simply run the commands
 listed there, without understanding each one's exact effect and purpose.
 An observation was raised that the guide was incomplete - however, I
 believe the iteration at that point was written as a guideline (a
 general outline of what needs to be done) as opposed to strict
 step-by-step instructions. When stumped with a merge, he elected to use
 the "git cherry-pick" command to copy the commits on top of his HEAD -
 however, this duplicates the commits' contents and results in duplicate
 commits in the repository.


I agree we need to develop a better understanding of git. At the same 
time it would be great to learn the meaning of commands from a guide 
that actually works, as opposed to a sketch that doesn't quite.


 I think you're trying to solve the wrong problem...

 Back to your question. Let's look at the command you posted:


 git pull --rebase -s recursive -X ours


  From my understanding, this this is what will happen:

 1. Fetch whatever commit objects that are absent from your tree but are
 present in the remote branch, and copy them to your tree. So far so good.
 2. Rewind your HEAD to the tip of the branch you just pulled.
 3. Take each commit that are in your branch's history, but are not in
 the remote's history, and re-apply them on top of the new HEAD. This
 creates new commit objects, with new SHA-1 hashes. Anything that builds
 upon the old SHA-1 hashes (e.g. if you've already uploaded these commits
 anywhere) will break. (--rebase rewrites history!)
 4. Whenever there is a merge conflict, it will THROW AWAY your change
 and automatically apply the other change.

 Was this your intention?


Yes, that was exactly my intention.


 Now, the question you should ask: WHY did you get a merge conflict?

 Was it a case of you and someone else actually changing the same bit of
 code? Or was it another instance of git abuse and someone force-pushing
 after someone else already pulled the code?


I have no idea. To the best of my understanding I had no meaningful work 
in master proper. The one conflict I looked at was in std/variant.d. It 
was a conflict of an older version of the thing with a newer one (the 
lines in conflict were at the recent apply functionality). I'd written 
no lines of code in the conflict. It's not impossible I might have 
checked out a pull request to look at it. Anyway, my purpose was: 
whatever crap is in my master right now, make it the same as the 
origin's master.


 If the merge conflict is genuine, and you don't want to deal with the
 merge, you should abort the merge, save your work as a new branch, and
 reset the current branch to the remote's:

 $ git merge --abort
 $ git branch branch-name-for-my-work
 $ git reset --hard origin/master

 (substitute "origin" for the remote name, and "master" for the remote
 branch name).


I get these tidbits of commands - git idioms - all the time, and I 
forget them because I don't use them frequently. I don't see why it's a 
crime to want to define some macros for such idioms instead of 
essentially putting that in a text file that I'd be perusing now and then.


 If you want to throw away any commits that are in your local branch but
 not in the remote branch, just run the third command.


That's pretty much what I wanted but was unable to find easily by 
searching the net.


Andrei
Jan 06 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 06, 2013 17:45:29 Andrei Alexandrescu wrote:

 I get these tidbits of commands - git idioms - all the time, and I
 forget them because I don't use them frequently. I don't see why it's a
 crime to want to define some macros for such idioms instead of
 essentially putting that in a text file that I'd be perusing now and then.


If you want to define macros for your personal use, then that's your 
prerogative, but I don't think that it's a good idea to encourage them by 
putting them in the repo's .gitconfig file. And in this particular case, git-
reset is basic enough and so useful (and so frequently needed in my 
experience), that while I can understand someone not knowing about it as 
they're learning, it's the sort of thing that anyone using git on a regular 
basis should know by heart.

My guess would be that part of your problem is the fact that you're 
functioning primarily in the capacity of an admin and reviewer these days 
rather than writing code yourself (or at least, if you're writing much code 
for Phobos and it's related projects, you're not submitting it). And if you're 
not using git aside from dmd/druntime/Phobos/d-programming-language.org, then 
it's much easier to forget the commands.

- Jonathan M Davis
Jan 06 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/6/13 6:02 PM, Jonathan M Davis wrote:

 On Sunday, January 06, 2013 17:45:29 Andrei Alexandrescu wrote:

 I get these tidbits of commands - git idioms - all the time, and I
 forget them because I don't use them frequently. I don't see why it's a
 crime to want to define some macros for such idioms instead of
 essentially putting that in a text file that I'd be perusing now and then.


 If you want to define macros for your personal use, then that's your
 prerogative, but I don't think that it's a good idea to encourage them by
 putting them in the repo's .gitconfig file.


Why? I don't quite buy the argument. You're essentially asking for rote 
memorization. Also, process should only be helped by macros that enforce it.

Andrei
Jan 06 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 06, 2013 18:12:20 Andrei Alexandrescu wrote:

 On 1/6/13 6:02 PM, Jonathan M Davis wrote:

 On Sunday, January 06, 2013 17:45:29 Andrei Alexandrescu wrote:

 I get these tidbits of commands - git idioms - all the time, and I
 forget them because I don't use them frequently. I don't see why it's a
 crime to want to define some macros for such idioms instead of
 essentially putting that in a text file that I'd be perusing now and
 then.


 
 If you want to define macros for your personal use, then that's your
 prerogative, but I don't think that it's a good idea to encourage them by
 putting them in the repo's .gitconfig file.


 
 Why? I don't quite buy the argument. You're essentially asking for rote
 memorization. Also, process should only be helped by macros that enforce it.


I'm arguing that people should actually learn how to use git properly rather 
than creating crutches for themselves. The more you try and do with git 
without learning it properly, the more problems you're likely to run into 
(e.g. by running commands that you don't entirely understand and ending up 
with nasty side effects). So, I think that it's just plain bad practice to 
create such macros. And since those macros won't exist with any other git repo 
unless you copy them over, getting used to them will just create more problems 
for anyone using them, because they'll learn the macro rather than the proper 
command and won't know what to do when they work with other repos.

So, if you want to create macros for yourself, because you want that, then 
that's up to you. But I'm against putting them in the repo's .gitconfig file, 
because I think that it's bad pratice and that it encourages bad practices.

- Jonathan M Davis
Jan 06 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/6/13 3:41 PM, Jonathan M Davis wrote:

 I'm arguing that people should actually learn how to use git properly rather
 than creating crutches for themselves.


False choice.


 The more you try and do with git
 without learning it properly, the more problems you're likely to run into
 (e.g. by running commands that you don't entirely understand and ending up
 with nasty side effects). So, I think that it's just plain bad practice to
 create such macros.


I know how the shell works quite well but that doesn't stop me from 
writing scripts and aliases.

This boils down to advocating one needs to type by hand sequences of 
commands instead of defining higher-level scripts that have a cohesive 
meaning.


Andrei
Jan 07 2013
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 8 January 2013 at 01:54:43 UTC, Andrei Alexandrescu 
wrote:

 On 1/6/13 3:41 PM, Jonathan M Davis wrote:

 I'm arguing that people should actually learn how to use git 
 properly rather
 than creating crutches for themselves.


 False choice.


Yet one should come before the other.


 The more you try and do with git
 without learning it properly, the more problems you're likely 
 to run into
 (e.g. by running commands that you don't entirely understand 
 and ending up
 with nasty side effects). So, I think that it's just plain bad 
 practice to
 create such macros.


 I know how the shell works quite well but that doesn't stop me 
 from writing scripts and aliases.

 This boils down to advocating one needs to type by hand 
 sequences of commands instead of defining higher-level scripts 
 that have a cohesive meaning.


Such as?

Points:
1. If everyone needed to type the same sequences of commands all 
the time, git by itself would be a rather poor tool.
2. Automating commands that destroy (or move in a hard-to-reach 
place) user data has obvious consequences.
3. Your workflow may be different from the typical user's. I 
agree that untypical usage (e.g. a project maintainer's) might 
benefit from some automation.
4. Your workflow might be suboptimal (due to incomplete knowledge 
of git).

Enumerate some actions that you have to resort to typing series 
of commands to perform, and let's examine solutions. I'll reply 
to your original problem with a better solution, as well.
Jan 07 2013
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, January 07, 2013 17:54:40 Andrei Alexandrescu wrote:

 I know how the shell works quite well but that doesn't stop me from
 writing scripts and aliases.
 
 This boils down to advocating one needs to type by hand sequences of
 commands instead of defining higher-level scripts that have a cohesive
 meaning.


If you want to create scripts or aliases for yourself, fine. And other people 
can do the same for whatever they need. But I think that any specific example 
of a git alias for D's repos needs to be examined in detail and have very 
strong arguments for its inclusion.

In my experience, the commands needed to operate on our repos are not 
complicated but rather are very basic git commands that anyone using git on a 
regular basis should know. And the command that you provided as an example 
that you thought needed an alias is a command that no one should even be using 
normally. I think that we need actual, solid examples if we're really going to 
discuss adding any aliases or scripts, and the example that you provided is a 
bad one.

- Jonathan M Davis
Jan 08 2013
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sunday, 6 January 2013 at 22:45:27 UTC, Andrei Alexandrescu 
wrote:

 I do now after having read about it at the end of several 
 google searches.


I found the git documentation to be an excellent resource once 
you're familiar with the basic concept of how git works. For 
that, I found this quite insightful: 
http://eagain.net/articles/git-for-computer-scientists/


 I agree it is important to be fluent with git. I'm an okay user 
 but currently unfit for an admin. Probably Walter is at a 
 similar stage. I'm doing my best to improve my knowledge in the 
 limited time I have, and part of it is discussing git here. So 
 I hope you'll understand why I find it contradictory to be 
 reprimanded for doing so with the reproach that I should be 
 doing exactly what I'm doing.


Sorry, your post came across to me as you advocating that 
everyone used a git command without having understood its exact 
function.


 Yes, that was exactly my intention.


But, why? If both histories contained conflicting changes, Git 
will throw only some away. In some cases, this might result in a 
broken codebase (the result might even compile, but git might've 
thrown away some initialization code (only), and you may not find 
out until it's too late).


 I get these tidbits of commands - git idioms - all the time, 
 and I forget them because I don't use them frequently. I don't 
 see why it's a crime to want to define some macros for such 
 idioms instead of essentially putting that in a text file that 
 I'd be perusing now and then.


I just don't think it's that simple. The outcome of any command 
can be affected by a number of factors, such as:
- Do you have any unstaged changes? Do you want to keep or 
discard them?
- Do you have any staged but uncommitted changes? (ditto)
- Are there any untracked files that may conflict with the 
operation? (ditto)
- Are there any local-only commits? (ditto)
- Which branch are you on?
- Does the branch track a remote-tracking branch? Is it tracking 
the intended one?
- How is the behavior of the commands set up in the user's 
.gitconfig?

So, the question is not as much "How do I get X done?", as it is 
"How do I get to X from Y?"

For example, the commands I posted will only work correctly if 
the current checked-out branch (i.e., HEAD) is "master", 
otherwise it'll move some other branch to match the remote's 
master. A hard reset throws away local changes - someone running 
such a macro found in a repository's .gitconfig may result in 
accidental loss of work.

FWIW, I work with git daily, and haven't found the need to set up 
macros such as you describe. I use a "gg" alias to launch git gui 
for interactive staging and reviewing, and the "git pullrequest" 
script I posted here earlier.


 That's pretty much what I wanted but was unable to find easily 
 by searching the net.


You could always ask on IRC ;)
Jan 06 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/6/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 What I'd want to do next is define the alias such that other
 participants to the dlang project may use it. With time we'd collect a
 good set of macros that help our process.


This is what I use locally in my .bashrc:


alias cd..='cd ..'
alias dir="ls -F"
alias cls='clear'
alias c:='cd /c/'
alias d:='cd /d/'
alias e:='cd /e/'
alias f:='cd /f/'
alias g:='cd /g/'


alias com='git checkout master'


discarding all changes



verify there's no merge conflicts
alias co='git checkout'


alias add='git add'

alias gcn='git checkout -b' #quick create a new branch

I only add stuff there when I realize I'm constantly retyping some long command.
I should probably add 'git rebase -i head~' too.
Jan 07 2013
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sunday, 6 January 2013 at 19:50:47 UTC, Andrei Alexandrescu 
wrote:

 For example, I tried today to get the latest and greatest 
 phobos into my repo, and got a bunch of conflicts. I searched a 
 while on the net to figure what the command for "just get the 
 latest remote into my local copy", which is entirely possible 
 but not obvious and not easy to find.





deleted.

collisions with files that are currently untracked, but are 
tracked in master.
git add --all .


stash.
git stash save "Automatic save before switching to latest master"


"master" branch is currently.
git checkout master


branch.

fast-forward.
git reset --hard origin/master


current branch to tracking branch.
git pull



This script assumes that the branch you want is "master", and 
that the remote is called "origin".

Do not invoke the script directly. Rather, create an alias in 
your .gitconfig which launches the script. This will allow it to 
work correctly even from a subdirectory in the project.

Instructions to recover data from accidental usage of this script:

To find what branch (or commit, with detached HEAD) you were on 
before the switch to master, check the output of `git reflog 
HEAD`. It should look something like this:

eb5121f HEAD {0}: pull: Fast-forward
8e7ed2b HEAD {1}: reset: moving to origin/master
d49acd5 HEAD {2}: checkout: moving from foo to master
ecdc09c HEAD {3}: ...
...

The commit you were on should be below the line the description 
of which starts with "checkout:".

Uncommitted data in your index or working tree will be in the git 
stash. Use `git stash apply` to apply the patch to the current 
working tree.

The script could be improved to be a little more efficient (e.g. 
avoid checking out the old master), or less noisy or reliant on 
the environment (e.g. detecting the name of the remote).
Jan 07 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/7/13 10:56 PM, Vladimir Panteleev wrote:

 On Sunday, 6 January 2013 at 19:50:47 UTC, Andrei Alexandrescu wrote:

 For example, I tried today to get the latest and greatest phobos into
 my repo, and got a bunch of conflicts. I searched a while on the net
 to figure what the command for "just get the latest remote into my
 local copy", which is entirely possible but not obvious and not easy
 to find.





[snip]

This script is bad because it does not do any meaningful error handling 
and offers no good explanation on how to proceed if either step fails. 
If you thought I had this kind of style in mind, I agree that using such 
scripts is a terrible idea.

Andrei
Jan 07 2013
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 8 January 2013 at 07:07:18 UTC, Andrei Alexandrescu 
wrote:

 This script is bad because it does not do any meaningful error 
 handling and offers no good explanation on how to proceed if 
 either step fails.


Indeed - I wanted to avoid using any syntax / commands that 
someone wouldn't use in daily git use.


 If you thought I had this kind of style in mind, I agree that 
 using such scripts is a terrible idea.


However, I can't think of any scenario where a command would fail 
half-way through the script and lead to undesirable consequences, 
assuming the git repository is not corrupted. The recovery 
instructions would still apply.

Therefore, just add "set -e" at the top for the peace of mind.
Jan 08 2013
prev sibling parent reply Ed McCardell <edmccard hotmail.com> writes:
On 01/06/2013 02:50 PM, Andrei Alexandrescu wrote:

 Sent this to dmd-internals, opening for a broader discussion:

 Hello,


 I wonder how we can define a few aliases of project-wide usefulness to
 git. For example, I tried today to get the latest and greatest phobos
 into my repo, and got a bunch of conflicts. I searched a while on the
 net to figure what the command for "just get the latest remote into my
 local copy", which is entirely possible but not obvious and not easy to
 find.


If you use local branches instead of working directly on master then 
getting the latest and greatest is as simple as

   git checkout master
   git pull

Then you can do

   git checkout mybranch
   git rebase master

to get new upstream changes into your local branch(es). You might 
sometimes need to use more complicated versions of the rebase command, 
but no matter how wacky things get with merge conflicts, it will only be 
affecting your local branch. (I often do "git checkout mybranch; git 
checkout -b newmybranch; git rebase master", if I'm worried about 
conflicts; this way I have a new branch to play around with fixing 
conflicts in, and it's easy to just scrap it and switch back to 
known-good versions of master and local branches).

tl;dr: more local branches means less need for arcane git options.

--Ed
Jan 09 2013
parent reply "mist" <none none.none> writes:
 tl;dr: more local branches means less need for arcane git 
 options.

 --Ed


AFAIR you can resist the temptation to have a local master branch 
at all and just run "git pull --rebase upstream/master" where 
upstream is configured to be original D repo.
Jan 10 2013
parent reply Ed McCardell <edmccard hotmail.com> writes:
On 01/10/2013 04:20 AM, mist wrote:

 tl;dr: more local branches means less need for arcane git options.

 --Ed


 AFAIR you can resist the temptation to have a local master branch at all
 and just run "git pull --rebase upstream/master" where upstream is
 configured to be original D repo.


And then you're right back where we started; Andrei's original problem 
was how to just get a local copy of the latest and greatest upstream 
without having merge conflicts, which (if you don't have a separate 
local master) means using "git pull --rebase -s recursive -X ours".

But: "rebase -X ours" does not throw away all of your changes; it keeps 
the ones that can be cleanly merged. So what you end up with is "the 
latest and greatest plus SOME of my local changes", which might not be 
what you wanted.

(Also, git branches are not temptations to be resisted.)

--Ed
Jan 10 2013
parent reply "mist" <none none.none> writes:
 And then you're right back where we started; Andrei's original 
 problem was how to just get a local copy of the latest and 
 greatest upstream without having merge conflicts, which (if you 
 don't have a separate local master) means using "git pull 
 --rebase -s recursive -X ours".

 But: "rebase -X ours" does not throw away all of your changes; 
 it keeps the ones that can be cleanly merged. So what you end 
 up with is "the latest and greatest plus SOME of my local 
 changes", which might not be what you wanted.

 (Also, git branches are not temptations to be resisted.)

 --Ed


"temptation to be resisted" is working on master branch instead 
of feature/bug branch, not git branches ;) Well, if you want to 
have a look at current upstream without merging - why not just 
checkout it in another temporary branch? I do not propose to get 
rid of master at all, just made an observation that it is easy to 
make small fix directly on master when it is hanging around so 
close.
Jan 11 2013
parent Ed McCardell <edmccard hotmail.com> writes:
On 01/11/2013 12:35 PM, mist wrote:

I do not propose to get rid of master at all,
 just made an observation that it is easy to make small fix directly on
 master when it is hanging around so close.


Looks like we're in violent agreement :) Mainly, I was trying to argue 
against the inclusion of Andrei's suggested git script in the official 
repository.

--Ed
Jan 14 2013