1 |
On Sun, Jul 5, 2015 at 11:31 AM, Duncan <1i5t5.duncan@×××.net> wrote: |
2 |
> C Bergström posted on Sun, 05 Jul 2015 01:17:41 +0700 as excerpted: |
3 |
> |
4 |
>> I super don't like "merge" workflows. |
5 |
>> 1) "merge commits" are confusing at best and normal tools don't display |
6 |
>> and work with them as you'd always expect |
7 |
> |
8 |
> git log --graph, as others have mentioned. |
9 |
|
10 |
we are not talking about the same thing. |
11 |
|
12 |
I want to see the "diff" - not the graph. |
13 |
|
14 |
svn diff -r 1234 |
15 |
git show <hash> |
16 |
|
17 |
show me the "merge" commit in diff format |
18 |
|
19 |
> |
20 |
> Works fine, at the console, is clear enough to follow, and is part of git |
21 |
> itself and commonly used, so is definitely a "normal" tool for those |
22 |
> using git. |
23 |
> |
24 |
> FWIW, to follow kernel developments during the merge window, I'll |
25 |
> actually run git log showing merges-only (generally confined to author |
26 |
> linus, as well, which pretty effectively limits me to only the master |
27 |
> merges). The merge comments give me a summary of what was committed in |
28 |
> that merge, and I can both skip entire merge categories after reading |
29 |
> only the title or merged tree name, where they're not of interest, and |
30 |
> drill down into merges if I find something covered there of particular |
31 |
> interest. |
32 |
> |
33 |
>> 2) merge commits lead to multiple parents, which breaks a clean and |
34 |
>> simple to follow linear history --------- |
35 |
> |
36 |
> Ugh! Development isn't linear if there's more than one person working on |
37 |
> a shared tree and making commits to their respective local trees to be |
38 |
> pushed later, at once, and making it appear linear is, plainly stated, a |
39 |
> lie. It's not clean and simple. It's a lie, and maintaining a lie |
40 |
> arguably always ends up more complex than simply stating the truth. |
41 |
|
42 |
Your truth and my truth are are clearly not the same thing. |
43 |
|
44 |
You want to preserve (for some reason) the original |
45 |
commit+date+original parent. To me, development is not "done" at that |
46 |
point. It's just getting started. It's not done in my mind until it's |
47 |
ready to be pushed. For something simple it doesn't really matter does |
48 |
it? |
49 |
|
50 |
I do see your point - I just think in the gentoo model it's unlikely |
51 |
to be relevant |
52 |
|
53 |
WHY is the original parent so important? If someone is working in foo/ |
54 |
category of ebuilds and you're working in bar/ - the parent commit is |
55 |
in all probability in a different category. The original parent commit |
56 |
probably has no value.. (who cares!! honest question) |
57 |
|
58 |
|
59 |
> |
60 |
> If you're not using one of the biggest and best features of git, its |
61 |
> ability to accurately and clearly portray parallel development and where |
62 |
> branches actually branched and merged, why are you using git in the first |
63 |
> place? |
64 |
|
65 |
Huh? Git is "nice" because it's distributed. Using rebase doesn't take |
66 |
away any of the benefits to that. |
67 |
|
68 |
Simply because it's used 'most everywhere else and thus people |
69 |
> tend to have some familiarity with it? That's not an invalid reason, of |
70 |
> course, but if you have ten thousand nails to nail, and a nail gun |
71 |
> plugged in and ready, why are you insisting on using a screwdriver to |
72 |
> pound them in, instead? If you're going to use a screwdriver, why not |
73 |
> use screws and a screw gun (svn, I guess, its commits are even |
74 |
> sequentially numbered, which ought to be heaven, by your definition!)? |
75 |
|
76 |
This is a passionate reply, but it's not very accurate. nail gun vs |
77 |
screw driver? (really?) |
78 |
|
79 |
|
80 |
> |
81 |
> To be clear, since the policy states rebase if possible, I'd do it, but |
82 |
> I'd be internally grousing about it every single time, and that's not |
83 |
> very conducive to remaining happy at one's job over a period of any |
84 |
> significant length, absolutely critical if that job's a volunteer job. |
85 |
|
86 |
Happiness is a state of mind - if this conflicts so strongly with a |
87 |
relgious view - sure I could see it being such a burden. Is doing git |
88 |
pull --rebase before you push really so bad? |
89 |
|
90 |
> |
91 |
> (I'd probably deal with it by scripting it to the extent possible and do |
92 |
> my best to forget about the horrible misuse of perfectly good tool |
93 |
> resources, tho I'd be cursing every time I went to use git log and |
94 |
> couldn't use it properly due to all the lying going on.) |
95 |
|
96 |
Again I don't see it as "lying" - (you're still working on stuff until |
97 |
you push.. development isn't done) The ability to do micro or |
98 |
incremental commits instead of the svn's forced wait approach is the |
99 |
benefit here. |
100 |
|
101 |
Hopefully you could share those scripts with others. Making this |
102 |
workflow easier on everyone is a great thing. |
103 |
I've seen people alias this and I think there's ways in git config to |
104 |
do this as well. |