| 1 |
C Bergström wrote: |
| 2 |
> To start.... I hate git.. I have used it for years now and the |
| 3 |
> multitude of ways that are possible to accomplish nearly the same |
| 4 |
> thing are *annoying* at best.. |
| 5 |
|
| 6 |
I'd be interested to hear a couple of examples of what you mean, |
| 7 |
perhaps in a private mail. Tack på förhand. :) |
| 8 |
|
| 9 |
|
| 10 |
> I super don't like "merge" workflows. |
| 11 |
|
| 12 |
I personally also prefer to rebase, but merge also has strong merits. |
| 13 |
|
| 14 |
> 1) "merge commits" are confusing at best and normal tools don't |
| 15 |
> display and work with them as you'd always expect |
| 16 |
|
| 17 |
I'm sure you are absolutely right about the tools. I never bother |
| 18 |
with anything but the command line git client though, and I think it |
| 19 |
does a good job of dealing with merges. git log --graph |
| 20 |
|
| 21 |
|
| 22 |
> 2) merge commits lead to multiple parents, which breaks a clean and |
| 23 |
> simple to follow linear history |
| 24 |
|
| 25 |
This is either a bug or a feature depending on whether development |
| 26 |
was actually linear. Sometimes it is, but sometimes it isn't. |
| 27 |
|
| 28 |
The benefit of merge commits being so easy is that it allows a |
| 29 |
correct historical representation of what development happened when, |
| 30 |
based on what previous commit. |
| 31 |
|
| 32 |
|
| 33 |
> What I personally prefer is a rebase workflow. |
| 34 |
|
| 35 |
Yes, I too like rebasing. But if there is high enough activity in a |
| 36 |
repository it actually becomes impractical. |
| 37 |
|
| 38 |
|
| 39 |
> The downsides |
| 40 |
> 1) Requires to you rebase before pushing. Which can be slightly more |
| 41 |
> work than just a lazy resolution of the conflicting "merge commit" |
| 42 |
> (depending on if you flatten your commits) |
| 43 |
|
| 44 |
Please be more aware of what you're doing. Rebase actually comes with |
| 45 |
pretty large implications, you are changing the base upon which your |
| 46 |
work applies. |
| 47 |
|
| 48 |
Sometimes this is unproblematic. In those cases, git pull --rebase is |
| 49 |
just more work than git pull. (But there's git config branch.$name.rebase) |
| 50 |
|
| 51 |
The thing about requiring rebase is that things in the base may shift |
| 52 |
without you knowing it. You really have to do a very careful review |
| 53 |
of what has happened between the old and new base commit, to know for |
| 54 |
sure that your stack of commits is still correct at all. |
| 55 |
|
| 56 |
This can be a very heavy operation and it pretty much must be manual! |
| 57 |
|
| 58 |
Sometimes it's really easy to do this manually. The thing is, rebase |
| 59 |
does incur this extra manual operation, and it is non-negotiable. |
| 60 |
|
| 61 |
A history with merges has much richer information about what happened |
| 62 |
when, and actually makes it easier to figure out difficult problems. |
| 63 |
|
| 64 |
|
| 65 |
> 2) May not be the most popular git work-flow. |
| 66 |
> 3) Due to #2 from above - may have detractors and or less people |
| 67 |
> who are familiar with it. |
| 68 |
|
| 69 |
I consider it a much more powerful sword, which thus must be wielded |
| 70 |
much more carefully. |
| 71 |
|
| 72 |
|
| 73 |
> I'm of the mindset that if you're going to keep something under |
| 74 |
> revision - the history should be clear and clean. |
| 75 |
|
| 76 |
I agree that this is ideal, but it's also very easy to think of real |
| 77 |
world situations where it is just not practical, and would either |
| 78 |
result in stalling other developers or increasing the local workload |
| 79 |
before commit/push is possible, neither of which is desirable. |
| 80 |
|
| 81 |
|
| 82 |
I agree that tools can be a big issue. I would not suggest using |
| 83 |
anything other than the git command line program. |
| 84 |
|
| 85 |
|
| 86 |
//Peter |
Archives