Re: [git-users] How to deal with concurrent changes in a project
@John McKown, `git stash` can be "rewerted" with `git stash pop`, so it
cleans up the working directory only temporarily. So it does just what it
says it will do: put your changes in a stash.
On 2 July 2013 14:55, John McKown wrote:
> Dang it, don't do the "git stash" at all, it cleans up the working
> directory. Just do the "git status" and "git reset" parts. When you've
> gotten the index to contain only the files you want to commit (the
> rest will be untracked), then do the git commit and git push. Then
> just do a "git add -A ."
>
> On Tue, Jul 2, 2013 at 7:53 AM, John McKown
> wrote:
> > Caution: Not an expert by any means.
> >
> > What I would do is this. First, I would do a "git stash".
> >
> >
> > Use git stash when you want to record the current state of the working
> > directory and the index, but want to go back to a clean working
> > directory. The command saves your local modifications away and reverts
> > the working directory to match the HEAD commit.
> >
> > The modifications stashed away by this command can be listed with git
> > stash list, inspected with git stash show, and restored (potentially
> > on top of a different commit) with git stash apply. Calling git stash
> > without any arguments is equivalent to git stash save. A stash is by
> > default listed as "WIP on branchname …", but you can give a more
> > descriptive message on the command line when you create one.
> >
> > The latest stash you created is stored in refs/stash; older stashes
> > are found in the reflog of this reference and can be named using the
> > usual reflog syntax (e.g. stash@{0} is the most recently created
> > stash, stash@{1} is the one before it, stash@{2.hours.ago} is also
> > possible).
> >
> >
> > Do a "git status" to find out what is staged to be committed (i.e. is
> > in the index). For each program which is staged in the index which you
> > don't want (a "git add" has been done but not yet committed), do a
> > "git reset HEAD file" to remove the changed, but not committed, file
> > from the index. This does not affect the contents of the file in the
> > working directory (it goes to untracked). When a "git status" shows
> > only the files what you want to commit in the section with the
> > heading: "Changes to be committed:", you can do the "git commit"
> > followed by a "git push". To get back to where you were, do a "git
> > stash pop".
> >
> > I'm 90+% sure this will get you what you want.
> >
> >
> >
> > On Tue, Jul 2, 2013 at 7:33 AM, wrote:
> >>
> >> Hi,
> >>
> >> I'm having difficulty understanding how I should use git when I have
> multiple independent changes in a project. I have a local git repository
> for various windows & linux machines and I work on different parts of the
> project on different machines. The situation I have is that I am part way
> through some changes on one part of the project. On the same machine, I
> have made some quick changes to another part of the project and I would
> like to commit those changes and push them to the origin, _without_ having
> to commit the other changes that I am still working on. Surprisingly, I
> don't seem to be able to do this with git.
> >>
> >> - I can commit the completed changes without committing the uncompleted
> changes ok.
> >>
> >> - If I try to push the changes, git complains that I have unstaged
> changes and I should do a local merge.
> >>
> >> - I can't even seem do a local merge without pulling other changes from
> the origin.
> >>
> >> So now I've ended up with part-finished changes on the master. Not what
> I wanted!
> >>
> >> What should I be doing here?
> >>
> >> --
> >> 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.
> >>
> >>
> >
> >
> >
> >
> > --
> > This is a test of the Emergency Broadcast System. If this had been an
> > actual emergency, do you really think we'd stick around to tell you?
> >
> > Maranatha! <><
> > John McKown
>
>
>
> --
> This is a test of the Emergency Broadcast System. If this had been an
> actual emergency, do you really think we'd stick around to tell you?
>
> Maranatha! <><
> John McKown
>
> --
> 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.
Re: [git-users] How to deal with concurrent changes in a project
Dang it, don't do the "git stash" at all, it cleans up the working
directory. Just do the "git status" and "git reset" parts. When you've
gotten the index to contain only the files you want to commit (the
rest will be untracked), then do the git commit and git push. Then
just do a "git add -A ."
On Tue, Jul 2, 2013 at 7:53 AM, John McKown
wrote:
> Caution: Not an expert by any means.
>
> What I would do is this. First, I would do a "git stash".
>
>
> Use git stash when you want to record the current state of the working
> directory and the index, but want to go back to a clean working
> directory. The command saves your local modifications away and reverts
> the working directory to match the HEAD commit.
>
> The modifications stashed away by this command can be listed with git
> stash list, inspected with git stash show, and restored (potentially
> on top of a different commit) with git stash apply. Calling git stash
> without any arguments is equivalent to git stash save. A stash is by
> default listed as "WIP on branchname …", but you can give a more
> descriptive message on the command line when you create one.
>
> The latest stash you created is stored in refs/stash; older stashes
> are found in the reflog of this reference and can be named using the
> usual reflog syntax (e.g. stash@{0} is the most recently created
> stash, stash@{1} is the one before it, stash@{2.hours.ago} is also
> possible).
>
>
> Do a "git status" to find out what is staged to be committed (i.e. is
> in the index). For each program which is staged in the index which you
> don't want (a "git add" has been done but not yet committed), do a
> "git reset HEAD file" to remove the changed, but not committed, file
> from the index. This does not affect the contents of the file in the
> working directory (it goes to untracked). When a "git status" shows
> only the files what you want to commit in the section with the
> heading: "Changes to be committed:", you can do the "git commit"
> followed by a "git push". To get back to where you were, do a "git
> stash pop".
>
> I'm 90+% sure this will get you what you want.
>
>
>
> On Tue, Jul 2, 2013 at 7:33 AM, wrote:
>>
>> Hi,
>>
>> I'm having difficulty understanding how I should use git when I have
>> multiple independent changes in a project. I have a local git repository for
>> various windows & linux machines and I work on different parts of the
>> project on different machines. The situation I have is that I am part way
>> through some changes on one part of the project. On the same machine, I have
>> made some quick changes to another part of the project and I would like to
>> commit those changes and push them to the origin, _without_ having to commit
>> the other changes that I am still working on. Surprisingly, I don't seem to
>> be able to do this with git.
>>
>> - I can commit the completed changes without committing the uncompleted
>> changes ok.
>>
>> - If I try to push the changes, git complains that I have unstaged changes
>> and I should do a local merge.
>>
>> - I can't even seem do a local merge without pulling other changes from the
>> origin.
>>
>> So now I've ended up with part-finished changes on the master. Not what I
>> wanted!
>>
>> What should I be doing here?
>>
>> --
>> 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.
>>
>>
>
>
>
>
> --
> This is a test of the Emergency Broadcast System. If this had been an
> actual emergency, do you really think we'd stick around to tell you?
>
> Maranatha! <><
> John McKown
--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?
Maranatha! <><
John McKown
--
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] How to deal with concurrent changes in a project
Caution: Not an expert by any means.
What I would do is this. First, I would do a "git stash".
Use git stash when you want to record the current state of the working
directory and the index, but want to go back to a clean working
directory. The command saves your local modifications away and reverts
the working directory to match the HEAD commit.
The modifications stashed away by this command can be listed with git
stash list, inspected with git stash show, and restored (potentially
on top of a different commit) with git stash apply. Calling git stash
without any arguments is equivalent to git stash save. A stash is by
default listed as "WIP on branchname …", but you can give a more
descriptive message on the command line when you create one.
The latest stash you created is stored in refs/stash; older stashes
are found in the reflog of this reference and can be named using the
usual reflog syntax (e.g. stash@{0} is the most recently created
stash, stash@{1} is the one before it, stash@{2.hours.ago} is also
possible).
Do a "git status" to find out what is staged to be committed (i.e. is
in the index). For each program which is staged in the index which you
don't want (a "git add" has been done but not yet committed), do a
"git reset HEAD file" to remove the changed, but not committed, file
from the index. This does not affect the contents of the file in the
working directory (it goes to untracked). When a "git status" shows
only the files what you want to commit in the section with the
heading: "Changes to be committed:", you can do the "git commit"
followed by a "git push". To get back to where you were, do a "git
stash pop".
I'm 90+% sure this will get you what you want.
On Tue, Jul 2, 2013 at 7:33 AM, wrote:
>
> Hi,
>
> I'm having difficulty understanding how I should use git when I have multiple
> independent changes in a project. I have a local git repository for various
> windows & linux machines and I work on different parts of the project on
> different machines. The situation I have is that I am part way through some
> changes on one part of the project. On the same machine, I have made some
> quick changes to another part of the project and I would like to commit those
> changes and push them to the origin, _without_ having to commit the other
> changes that I am still working on. Surprisingly, I don't seem to be able to
> do this with git.
>
> - I can commit the completed changes without committing the uncompleted
> changes ok.
>
> - If I try to push the changes, git complains that I have unstaged changes
> and I should do a local merge.
>
> - I can't even seem do a local merge without pulling other changes from the
> origin.
>
> So now I've ended up with part-finished changes on the master. Not what I
> wanted!
>
> What should I be doing here?
>
> --
> 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.
>
>
--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?
Maranatha! <><
John McKown
--
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] How to deal with concurrent changes in a project
Hello, do I get it right, and you have only two repos, one on the linux and one on the windows machine, and you don't use an intermittent repository, like a git server, Gitorious or Github? If so, you MUST commit or stash your changes in "origin", before pushing your changes there. Or, you may set up the other repository as a remote on "origin", and pull from there (maybe with rebase). Best, Gergely On 2 Jul 2013 14:33, wrote: > Hi, > > I'm having difficulty understanding how I should use git when I have > multiple independent changes in a project. I have a local git repository > for various windows & linux machines and I work on different parts of the > project on different machines. The situation I have is that I am part way > through some changes on one part of the project. On the same machine, I > have made some quick changes to another part of the project and I would > like to commit those changes and push them to the origin, _without_ having > to commit the other changes that I am still working on. Surprisingly, I > don't seem to be able to do this with git. > > - I can commit the completed changes without committing the uncompleted > changes ok. > > - If I try to push the changes, git complains that I have unstaged changes > and I should do a local merge. > > - I can't even seem do a local merge without pulling other changes from > the origin. > > So now I've ended up with part-finished changes on the master. Not what I > wanted! > > What should I be doing here? > > -- > 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.
