No problem, that is actually the English translation of my name and even I
refer to myself as Gregory sometimes :)
As I said in my mail, you don’t have to commit before switching branches.
You can drop your changes completely with git checkout -- . (note the minus
minus dot part; -- instructs Git
Gergely, please pardon my typo as to your name. :-)
--
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 opti
Gregory,
You give me far too much cred as a developer. :-) I've only just started to
dabble with version control. I had to google ClearCase.
Konstantin is much closer to the truth when he suggests:
*"just on Windows you always happened to commit your changes before
switching branches"*. Spot on!
On Wed, 14 Sep 2016 10:33:24 -0700
Michael wrote:
> So I really don't understand the command line for rebase.
>
> What I have: My last two commits on master should have either been on
> develop, or on a branch off develop.
So, that's the case for cherry pick, not rebasing:
$ git checkout dev
So I really don't understand the command line for rebase.
What I have: My last two commits on master should have either been on develop,
or on a branch off develop.
>From my last commit on develop (666e9), I did a version number bump (15003), a
>merge into master (95231) -- those two on a branc
Konstantin Khomoutov ezt írta (időpont:
2016. szept. 14., Sze, 13:48):
> On Tue, 13 Sep 2016 11:28:23 -0700
> Michael wrote:
>
> > > Thank you Konstantin and Gergely!
> > > Very informative reading. I'll try to keep my tree sorted out in
> > > the future. :-)
> > Having gone through the same iss
Do you have an example repository to show the issue?
If folks aren't following instructions then it's time to review the
instructions first / as well.
Why not have the master and skeleton branches as being --orphan to each other
(i.e. do not have a common root). This caan help the re-think.
It
On Tue, 13 Sep 2016 11:28:23 -0700
Michael wrote:
> > Thank you Konstantin and Gergely!
> > Very informative reading. I'll try to keep my tree sorted out in
> > the future. :-)
> Having gone through the same issue myself multiple times before
> figuring out what was going on, perhaps this should
Magnus Therning ezt írta (időpont: 2016. szept. 14.,
Sze, 12:00):
>
> Gergely Polonkai writes:
>
> > Hello,
> >
> > TL;DR: no, your branch is not polluted, your working directory is in a
> > dirty state.
> >
> > A branch is just a pointer to a commit, so if it gets “polluted”, that
> > would mea
Hello all Git users,
We would like to ask you a few questions about your use of the Git
version control system. This survey is mainly to understand who is
using Git, how and why. It would be nice to hear the voice of
various users of Git.
The results will be published to the Git Wiki on the GitSu
Gergely Polonkai writes:
> Hello,
>
> TL;DR: no, your branch is not polluted, your working directory is in a
> dirty state.
>
> A branch is just a pointer to a commit, so if it gets “polluted”, that
> would mean your last commit has changed.
>
> What happened is that your changes in the working
short story:
I set up an programming exercise with two branches:
- master with the skeleton of the exercise
- solution with the completed skeleton
I would like an "automatic" (simple, enforced) synchronization between
both branches.
long story:
I assumed that the teacher workflow was c
12 matches
Mail list logo
