[git-users] git rebase workflow public branch

[Bogdan Valentin Neacsa]

Hello,

I've read some nice things about git rebasing workflow here: 
http://mettadore.com/analysis/a-simple-git-rebase-workflow-explained/

I'm suppose to use this in a project with the following structure:

   develop
  /   \
   dev_frontenddev_backend
 / \ 
dev_devnames  dev_devnames

Basically we all work in our own dev_devname branch which will be rebased 
either against backend or frontend depending on team we are in. No one else 
but dev will push to his own branch, and as soon as a feature is done, a 
pull request is made to parent branch, then you move on on your branch with 
next feature and so on.

We should rebase often from parent branch. Now I've understood how rebase 
works from that link I posted as long as I have a local branch with 
commits, which is at the end merged into parent and dropped. I can't seem 
to understand how this would work with the above case.

Say I rebase from backend, and now push to origin dev_devname . The commit 
history is now on repo. Now when I start new features/continue work when I 
rebase from backend my commit history will change again. Now when I try to 
push to dev_devname I cannot and need to pull from there. But pull now 
gives me conflicts that I need to fix. Is this normal or am I 
missunderstanding the workflow here? 

Thanks,
Bogdan

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [git-users] Re: HELP! stash pop is failing and I can't get my work out

[Joe Cabezas]

actually what are you trying to do?, the subject says something with stash,
and then you talk about merging... seems like i do not undertand the
problem at all...

maybe when you do a stash pop, you have conflicts?, if so

that is a common problem

when you make a stash, actually records in what commit you did that stash,
this guarantees that making pop it that commit wont fail into conflicts...

conflicts happens when you stash, make changes, commit, (pull, etc), and
then you try to stash pop... that can fail for obvious reasons... code
incompatibility etc...

the solution is to checkout to the commit where the stash was created
(using checkout, git reset --hard, or using gitk --all), and then create a
new branch from there

once you have this new branch, you can safely make a stash pop because in
that commit was created..

then you return back to your previous branch and do a merge if needed
git merge master temporalbranch

Afortunately, git provides a single command to do this, if you read the
manual (git help stash) it says...

--
branch branchname [stash]
   Creates and checks out a new branch named branchname starting
from the commit at which the stash was originally created, applies the
   changes recorded in stash to the new working tree and index.
If that succeeds, and stash is a reference of the form
   stash@{revision}, it then drops the stash. When no stash
is given, applies the latest one.

   This is useful if the branch on which you ran git stash save has
changed enough that git stash apply fails due to conflicts. Since the
   stash is applied on top of the commit that was HEAD at the time
git stash was run, it restores the originally stashed state with no
   conflicts.
--

so, anytime you cam make: git stash branch temporalbranch

and then simply... git merge temporalbranch

hope this helps

bye!

-Joe


2013/5/8 Yawar Amin yawar.a...@gmail.com

 Hi,

 On Friday, March 8, 2013 4:06:04 PM UTC-5, Piers H wrote:
  why does git require all these gymnastics just to do a simple merge?
  with SVN it was 1 command, and I never had any issues with it. i don't
  understand.

 You'll need to adjust your workflow a little bit. Git has a different
 philosophy from Subversion, you need to adapt mentally. It's not a great
 hardship.

 Do your local work and commit it. Don't leave any files out of the
 commit(s) if you need them. Commit everything you can.

 Then, do a git pull. If this causes a merge conflict, you can solve it
 like any other merge conflict, in a sane way.

 No need to stash your changes.

 Regards,

 Yawar

  --
 You received this message because you are subscribed to the Google Groups
 Git for human beings group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to git-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[git-users] scope of gc prune and git reflog expire

[Andrew Steady]

Hi,

We are using throwaway integration branches which are pushed, and then 
later deleted and recreated - and this is working well, however the 
discarded branches are leaving dangling commits and trees which I can view 
with this command: git fsck --unreachable --no-reflogs

I could clean them up with 

git reflog expire --expire-unreachable=now --all

git gc --prune=now

or something similar, but I want to understand the scope of these commands. 
E.g. how can I affect the clean up in the remote repository on Github so that 
when others clone they do not get these dangling items? Do I need to somehow 
push this change?

On a related note there are related configurations I would like to set: 
gc.pruneexpire, gc.reflogexpire, gc.reflogexpireunreachable etc. but again not 
sure how to have this take effect at Github.

Any tips appreciated,

Andy

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.