Eh, yet another one, sorry:
On 14/07/2017 01:32, Igor Djordjevic wrote:
>
> $ git checkout featureA
> $ git commit
> $ git checkout master
> $ git reset --hard HEAD^
> $ git merge
The last line should stress , as we`re
not merging exact parent commits the previous merge
Just a small update/fixup:
On 14/07/2017 00:39, Igor Djordjevic wrote:
> I guess it would be a kind of alias to doing:
>
> $ git checkout featureA
> $ git add ...
> $ git commit
> $ git checkout master
> $ git reset --hard HEAD^
> $ git merge featureA featureB
>
This sho
Hi astian,
On 12/07/2017 00:27, astian wrote:
> Nikolay Shustov wrote:
>> With Perforce, I can have multiple changelists opened, that group the
>> changed files as needed.
>>
>> With Git I cannot seem to finding the possibility to figure out how to
>> achieve the same result. And the problem is th
On 13/07/2017 23:20, Junio C Hamano wrote:
> Nikolay Shustov writes:
>> My question was about how to robustly handle "multiple pending
>> commits" which in Perforce are represented by concept of pending
>> changelists.
>
> And in Git, they are represented by concept of commits that are not
> yet
Nikolay Shustov writes:
> I am not really try to ignite the holy war between Perforce and Git
> (and why would one???), but if you are interested in the answer on how
> you'd do your scenario in Perforce, it would be: "use shelved
> changelists".
Oh, that was not my intention, either. My intere
For me the roadblock for multiple iterations through merging of the
different parts (S, C, then C+S) is the time that will be spent on
rebuilding the mainline.
That's why I would like to have C+S in the same source tree then run
tests for S, tests for C (if they can be run standalone) and C+S
tests
Thank you, but I am not sure I quite understand the idea.
Could you please elaborate on it for the following example?
I have two Perforce changelists ("A" and "B") that group uncommitted
sets of files (paths to each of files could be different):
changelist A:
file1
file2
changelist B:
file3
file
Stefan Beller writes:
> On Tue, Jul 11, 2017 at 8:45 AM, Nikolay Shustov
>
>> With Git I cannot seem to finding the possibility to figure out how to
>> achieve the same result. And the problem is that putting change sets
>> on different Git branches (or workdirs, or whatever Git offers that
>> ma
Nikolay Shustov writes:
> Thank you for the detailed explanation, it looks like merging the
> commits would be helpful in my case. And I think it is a very good
> analogy that Perforce changelists are like multiple pending committs,
> if Git were supporting such.
>
> What it won't be achieving by
Thank you taking time to think about my issue (I am actually grateful
to everyone in this e-mail thread, who did). I looked into Mercurian
MQ and it doesn't seem to fit what I need - from what I understood, it
speaks about the committed changes and those are not amendable. This
is kinda not what I
Thank you for the detailed explanation, it looks like merging the
commits would be helpful in my case. And I think it is a very good
analogy that Perforce changelists are like multiple pending committs,
if Git were supporting such.
What it won't be achieving by using commits in this schema is the
Thank you, this could work, but if I am adding new file to the
feature/removing the existing file from the feature, aliases usage for
"add" doesn't help much.
I would really need to have the lists of files... and attributes look
more promising.
On Tue, Jul 11, 2017 at 4:20 PM, Lars Schneider
wrot
For starters, let me say that I consider myself a mere advanced
beginner Git user, and I haven`t used Perforce ever before (did some
reading now), but still, for what it`s worth, here are my thoughts,
please bare with me :)
Do feel free to correct me if I miss something.
On 11/07/2017 19:39, L
Nikolay Shustov wrote:
> With Perforce, I can have multiple changelists opened, that group the
> changed files as needed.
>
> With Git I cannot seem to finding the possibility to figure out how to
> achieve the same result. And the problem is that putting change sets
> on different Git branches (or
> On Tue, Jul 11, 2017 at 1:39 PM, Lars Schneider
> wrote:
>>
>>> On 11 Jul 2017, at 17:45, Nikolay Shustov wrote:
>>>
>>> Hi,
>>> I have been recently struggling with migrating my development workflow
>>> from Perforce to Git, all because of the following thing:
>>>
>>> I have to work on seve
Hi,
I will choose a bit of a less diplomatic path here. Instead of trying to
tell you how you can make git fit your needs, I would say that you
shouldn't. I've two arguments:
1.
It's always painful when you try to use a tool in some way it's not
intended or used to work. If you're doing something
Thank you for #3.
As for 1+2, the documentation says:
"Each line in gitattributes file is of form:
pattern attr1 attr2 ...
...
When the pattern matches the path in question, the attributes listed
on the line are given to the path."
My understanding is that to have the bunch of the files in the
On Tue, Jul 11, 2017 at 11:10 AM, Nikolay Shustov
wrote:
> Thank you for the explanation. The example about backend and frontend
> is relevant even though I normally have to deal with more layers at
> the same time.
>
> However, in my case I have the thing that you have already tried to
> address,
Thank you for the explanation. The example about backend and frontend
is relevant even though I normally have to deal with more layers at
the same time.
However, in my case I have the thing that you have already tried to
address, partially: the changes always align with file boundaries BUT
not wit
Thank you for the idea, however I am having troubles with basically
maintaining the uncommitted groups of files: I would prefer the clear
distinction that "those files belong to feature A" and "these files
belong to feature B", before I commit anything. Committing separately
every change for featur
> The way of Git is that a commit (snapshot) by definition describes a
> set of files (The set of all files in the project). So If you need two
> features
> there at the same time, you probably want it in the same commit.
Thank you, but if I wanted these two features to be in the same
commit, I w
> On 11 Jul 2017, at 17:45, Nikolay Shustov wrote:
>
> Hi,
> I have been recently struggling with migrating my development workflow
> from Perforce to Git, all because of the following thing:
>
> I have to work on several features in the same code tree parallel, in
> the same Perforce workspace
Nikolay Shustov writes:
> I have to work on several features in the same code tree parallel, in
> the same Perforce workspace. The major reason why I cannot work on one
> feature then on another is just because I have to make sure that the
> changes in the related areas of the product play togeth
-Original Message-
On July 11, 2017 11:45 AM Nikolay Shustov wrote:
>I have been recently struggling with migrating my development workflow from
>Perforce to Git, all because of the following thing:
>I have to work on several features in the same code tree parallel, in the same
>Perforce
On Tue, Jul 11, 2017 at 8:45 AM, Nikolay Shustov
wrote:
> Hi,
> I have been recently struggling with migrating my development workflow
> from Perforce to Git, all because of the following thing:
>
> I have to work on several features in the same code tree parallel, in
> the same Perforce workspace
Hi,
I have been recently struggling with migrating my development workflow
from Perforce to Git, all because of the following thing:
I have to work on several features in the same code tree parallel, in
the same Perforce workspace. The major reason why I cannot work on one
feature then on another
26 matches
Mail list logo